مقدمة: الوكيل الذي يريده الجميع، بدون ضجة
الشيء في وكلاء البرمجة هو أن معظمهم يحاول أن يكون رئيسك، ومساعدك التجريبي، ومعالجك النفسي - ثم ينسى ببساطة كتابة التعليمات البرمجية. تسير الأمور كالتالي: أضف اثني عشر مخزنًا متجهيًا، ورش بعض غبار الأوركسترا السحري، واربط متصفحًا، ثم اعتبر الأمر منتهيًا. يبدو رائعًا في العروض التوضيحية. لكنه ينهار في اللحظة التي تطلب منه فيها إصلاح اختبار تكامل متقطع في الساعة 4:52 مساءً يوم الجمعة.
بناء وكيل برمجة خفيف الوزن باستخدام Claude 4.5 هو - ويا للمفاجأة - أمر مباشر في الواقع إذا توقفت عن مطاردة حلم مساعد البرنامج العالمي وبنيت مجرد أداة تقرأ التعليمات البرمجية وتخطط وتعدل وتشغل وتكرر. لا توجد خطبة حول "استبدال الذكاء الاصطناعي بالمطورين". لا توجد مسارات روب جولدبرج. مجرد حلقة ضيقة تفعل الأشياء الواضحة بشكل جيد.
هذا دليل إرشادي للوصول إلى هناك دون جر قسم كامل لعمليات الذكاء الاصطناعي. سنستخدم Claude 4.5 للدماغ، ونظام ملفات وقذيفة للأيدي، وذاكرة صغيرة للتركيز على المدى القصير. هذا كل شيء. خفيف الوزن يعني أنه يمكنك فهمه في جلسة واحدة، وتشغيله محليًا، والوثوق به لأن كل خطوة قابلة للفحص. وهو أمر شبه تخريبي، إذا كنت قد استخدمت أي شيء في هذا المجال مؤخرًا.
لماذا Claude 4.5 مناسب لوكيل الحد الأدنى
يتمتع Claude 4.5 بالمزاج الذي تريده بالفعل للتعليمات البرمجية: حريص على اتباع التعليمات، ولائق بشكل مدهش في قراءة الاختلافات، وغير متحمس بشكل مفرط لتهيئة الأطر التي لم تطلبها. النموذج كفء في التفكير التدريجي دون الحاجة إلى رواية مطالبة كاملة. هذا المزيج - التفكير بالإضافة إلى ضبط النفس - يجعله مثاليًا لحلقة وكيل البرمجة:
- المراقبة: قراءة الملفات الحالية وسجلات الأخطاء والاختبارات.
- التخطيط: اقتراح تعديلات ملموسة مع الأساس المنطقي.
- التنفيذ: تصحيح الملفات وتشغيل الأوامر.
- التفكير: تقييم الإخراج والتكرار أو التوقف.
يمكنك تثبيت هذا على أي مستودع والحصول على قيمة في فترة ما بعد الظهر. الحيلة هي مقاومة الرغبة في تحويله إلى "منصة ذكاء اصطناعي". إذا حافظت على الوكيل خفيف الوزن، فإن Claude 4.5 يقوم بالرفع الثقيل دون أن يعيق طريقك.
البنية الخفيفة الوزن: خمس قطع، بدون دراما
إليك المجموعة الكاملة التي تحتاجها:
- الحلقة الأساسية: عملية واحدة تستدعي Claude 4.5 وتفسر رسائل استخدام الأدوات الخاصة به.
- الأدوات: مجموعة صغيرة - read_file، write_file، list_dir، run_tests (أو run_cmd)، search_code.
- منشئ السياق: تجميع مطالبة قصيرة وموجهة مع بيانات تعريف المستودع والاختلافات الحديثة.
- ذاكرة قصيرة المدى: نافذة محادثة متجددة بالإضافة إلى لوحة مسودة صريحة للخطة والقيود.
- الحواجز الواقية: حدود الرمز المميز والوقت وكتابة الملفات؛ وضع التشغيل الجاف؛ ولقطات الاسترجاع.
هذا كل شيء. يمكنك تشغيله بدون رأس في محطة طرفية أو لفه في واجهة مستخدم بسيطة إذا كان يجب عليك ذلك. السبب في نجاح هذا الأمر ممل: كل إجراء تتم ملاحظته والتحقق منه. يقترح الوكيل تغييرًا، ويعرض الفرق، ويشغل الاختبارات، ويقرأ الإخراج، ويستمر أو يتوقف. لا يوجد لحم غامض في المنتصف.
كيفية بناء الوكيل (دون فقدان الحبكة)
الخطوة 1: تحديد العقد - المطالبة والأدوات
الوكيل الخاص بك جيد بقدر العقد الذي أبرمه مع النموذج. حافظ على مطالبة النظام قصيرة وصارمة وعملية بلا هوادة.
مطالبة النظام، مُقطَّرة:
- أنت وكيل برمجة. مهمتك هي إجراء تغييرات صغيرة وصحيحة على المستودع لإرضاء مهمة المستخدم.
- فكر بصوت عالٍ في لوحة مسودة مخفية؛ اعرض الخطط والاختلافات فقط على المستخدم.
- فضل الاختلافات البسيطة والاختبارات العاملة والتقدم التدريجي.
- عندما تكون غير متأكد، اقترح تجربة وقم بتشغيلها.
- لا تقم أبدًا بتلفيق الملفات أو الأوامر - قم بإدراجها وقراءتها قبل التحرير.
مخطط الأداة (لا تفرط في التفكير فيه):
- read_file(path, offset?, length?)
- write_file(path, content, create_if_missing=false)
- run_cmd(command, timeout=60, cwd=repo_root)
- search_code(query, path=repo_root, max_results=50)
الأشياء الجيدة الاختيارية: git_diff و git_revert(sha) إذا كنت تريد عمليات استرجاع بدون استخدام اليدين. يمكنك تخطي مخزن متجه؛ تعتمد معظم المهام المفيدة على عدد قليل من الملفات في الذاكرة العاملة بالإضافة إلى بحث سريع.
الخطوة 2: حافظ على السياق الهزيل
حشو السياق هو عبادة الشحن لتصميم الوكيل. لا تقم بإلقاء المستودع الأحادي بأكمله في المطالبة. بدلا من ذلك:
- ملخص المستودع: ملخص README فقرة واحدة؛ نقاط الدخول؛ أمر تشغيل الاختبار.
- الملفات النشطة: فقط الملفات التي يخطط الوكيل للمسها - اقرأها على شكل أجزاء حسب الحاجة.
- المهمة: هدف المستخدم، بصياغة واضحة: "إصلاح الاختبار الفاشل FooTest.test_bar في tests/foo_test.py."
- القيود: حدود وقت التشغيل، والقائمة البيضاء لكتابة الملفات، وقواعد النمط، وتوقعات الإصدار الدلالي إن وجدت.
- السجل الحديث: آخر اختلافين ونتائج الاختبار الخاصة بهما. لا شيء آخر.
Claude 4.5 قادر تمامًا على جلب المزيد من السياق عندما يحتاجه عبر search_code و read_file. أعطه الخريطة، وليس الإقليم.
الخطوة 3: الحلقة (المراقبة ← التخطيط ← التنفيذ ← التفكير)
- المراقبة: ابدأ بإدراج الدلائل، وقراءة الاختبار الفاشل، والتعليمات البرمجية قيد الاختبار، وسجل الأخطاء. اطلب من Claude تلخيص أعراض الفشل في نقطتين أو ثلاث نقاط.
- التخطيط: اطلب من Claude اقتراح خطة مع:
- الملفات المراد فحصها أو تحريرها
- الحد الأدنى من الاختلافات التي يجب تجربتها
- أمر اختبار للتحقق من الصحة
- التنفيذ: تطبيق الفرق المقترح عبر write_file. إظهار الفرق حرفيًا. تشغيل الاختبارات.
- التفكير: إرجاع stdout/stderr. اسأل Claude: المتابعة أو التراجع أو التوقف؟ إذا تغيرت الخطة، فاطلب تبريرًا بجملة واحدة يشير إلى الإخراج الفعلي.
- الخروج: توقف عندما تجتاز الاختبارات، أو بعد N من التكرارات، أيهما يأتي أولاً.
هذا برمجة ثنائية مجيدة حيث تحافظ بالفعل على صدق الاقتران.
الخطوة 4: الحواجز الواقية التي تنقذ عطلة نهاية الأسبوع
- القائمة البيضاء للكتابة: السماح بالكتابة فقط داخل src/، lib/، أو المسارات المعتمدة صراحة.
- حد حجم الفرق: تحديد التعديلات بـ 200-500 سطر لكل خطوة. إذا كان أكبر، قم بتقسيمه إلى خطوات فرعية.
- القائمة المسموح بها للأوامر: مشغلات الاختبار، والمدققون اللغويون، وبعض البرامج النصية للمطورين. حظر الشبكة. أنت تريد إمكانية التكرار، وليس تجعيد الغرب المتوحش.
- المهلة الزمنية وإعادة المحاولة: مهلات زمنية قصيرة، إعادة محاولة واحدة كحد أقصى - حلقات إعادة التشغيل التي لا نهاية لها هي المكان الذي تذهب إليه الوكلاء للموت.
- وضع التشغيل الجاف: طباعة الفروق المقترحة ولكن لا تكتبها. عظيم لمراجعة التعليمات البرمجية.
سيلتزم Claude 4.5 بالقواعد إذا جعلتها صريحة. إذا لم تفعل ذلك، فلا تتفاجأ عندما يحاول "المساعدة" عن طريق إعادة تنظيم المستودع بأكمله ليتوافق مع منشور مدونة من عام 2017.
الخطوة 5: الذاكرة المفيدة بالفعل
تحل الذاكرة قصيرة المدى 80٪ من المشكلة. حافظ على:
- لوحة مسودة للفرضية والخطة الحالية.
- قائمة بالملفات التي تم لمسها في هذه الجلسة.
هذا يكفي Claude 4.5 للتفكير بشكل متماسك. يمكن أن تكون الذاكرة طويلة المدى - سجلات المهام والتضمينات - مفيدة لقواعد التعليمات البرمجية المتكررة، ولكن تعامل معها على أنها سكر اختياري. إذا كان وكيلك لا يستطيع إصلاح اختبار بدون فهرس متجه 500 ميجابايت، فهو ليس وكيلًا - بل هو تبعية.
المخطط التفصيلي للتنفيذ الأدنى
من حيث التعليمات البرمجية الزائفة، يمكنك تنفيذ هذا الوكيل في بضع مئات من الأسطر:
- initialize: تحميل بيانات تعريف المستودع والقيود وعميل النموذج
- observe: قراءة الاختبارات والملفات والسجلات الفاشلة
- plan = model.propose_plan(context)
- while not done and steps < MAX:
- diff = model.propose_patch(plan)
- show(diff); maybe approve
- out = run_cmd(plan.test_cmd)
- reflect = model.evaluate(out)
- if reflect == pass: done = true
- else if reflect == rollback: git_revert(last_commit)
- else: plan = model.revise_plan(out)
ستلاحظ الأجزاء المفقودة: لا يوجد وكلاء يديرون الوكلاء، ولا "مندوبين"، ولا "نموذج مخطط" منفصل و "نموذج منفذ". يمكن لـ Claude 4.5 القيام بكلتا الوظيفتين بشكل جيد إذا لم تخربه بجهاز روب جولدبرج.
المطالبة التي لا تحاول جاهدة
تحاول المطالبات السيئة أن تكون ذكية. المطالبات الجيدة مملة ومحددة. إليك هيكلًا عاقلًا لكتلة التعليمات الأساسية الخاصة بك:
- الهدف: اذكر مهمة الترميز الدقيقة ومعايير النجاح.
- السياق: هيكل المشروع ونقاط الدخول وأمر الاختبار.
- القيود: القائمة البيضاء للكتابة، والحد الأقصى لحجم الفرق، ولا توجد شبكة.
- تفضيلات النمط: إصدار اللغة، والمنسق، وقواعد المدقق اللغوي.
- العملية: المراقبة ← التخطيط ← التنفيذ ← التفكير؛ إظهار الفروق؛ تشغيل الاختبارات؛ التكرار حتى N من الخطوات؛ التوقف عند اجتياز الاختبارات.
لن يحتاج Claude 4.5، بهذا الهيكل، إلى سيناريو لعب الأدوار مكون من 100 سطر. إنه يعمل فقط.
مثال عملي: إصلاح اختبار فاشل
لنفترض أن الاختبار يفشل في tests/time_test.py لأن parse_time("09:00") يُرجع 5400 بدلاً من 32400. يجب أن تبدو حلقة الوكيل كالتالي:
- المراقبة: قراءة time.py و time_test.py؛ تشغيل pytest -k parse_time.
- التخطيط: الفرضية - خطأ في حساب الثواني مقابل الدقائق؛ اقتراح تحرير parse_time؛ إضافة حالة حافة الوحدة.
- التنفيذ: تصحيح parse_time، إضافة اختبار للساعات التي تبدأ بصفر؛ تشغيل الاختبارات.
- التفكير: إذا استمرت الاختبارات في الفشل، فاقرأ الخطأ، واضبط الرياضيات أو التعبير النمطي، وأعد التشغيل.
قد يكون التصحيح الناجح الأدنى تغييرًا مكونًا من سطرين. هذا هو الهدف. تعديلات صغيرة، دورات سريعة، تقدم حقيقي.
أين يتفوق الوزن الخفيف على حوض المطبخ
- زمن الوصول: نموذج واحد، حلقة واحدة، لا يوجد عبء إضافي على التنسيق.
- الشفافية: كل خطوة قابلة للتدقيق. يمكنك مقارنته، ويمكنك التراجع عنه، ويمكنك إعادة تشغيله.
- التحكم: تحافظ الحواجز الواقية على الأضرار المحلية. لا يمكن للوكيل أن يتجول في البنية التحتية الخاصة بك.
- التكلفة: عدد أقل من المكالمات، وسياق أقل، ورموز متوقعة.
- تجربة المستخدم: أنت تفهمها. يفهمها زملاؤك في الفريق. لن يكرهك مستقبلك.
والمقايضات:
- الاتساع: لن يقوم وكيل الترميز خفيف الوزن بإعادة هيكلة المستودع الأحادي ذي الخمس لغات في تمريرة واحدة. ولا ينبغي ذلك.
- المبادرة: لن يخترع خرائط طريق متعددة الأسابيع. أنت تعطيه المهام.
- الحالة: بدون طبقة ذاكرة كبيرة، فإنه ينسى التاريخ البعيد عن طريق التصميم. هذه ميزة حتى تكون خطأ.
نقطة Claude 4.5 المثالية لوكلاء الترميز
يتألق Claude 4.5 في:
- قراءة الاختلافات والسجلات والتفكير فيها.
- إنتاج تغييرات متماسكة وبسيطة في التعليمات البرمجية.
- اتباع القيود والوضوح بشأن عدم اليقين.
إنه أقل روعة في:
- تخمين سلوك واجهة برمجة التطبيقات التي لا يمكنه قراءتها.
- تصميم الرقصات الثقيلة للأدوات (غير مطلوب هنا).
- إعادة هيكلة الملفات المتعددة الطويلة دون توجيه بشري للخطوات.
هذه النقطة الأخيرة مهمة. أفضل طريقة للحصول على نتائج قوية ليست جعل الوكيل أكبر - بل هي تصغير المهمة. استخدم عقلك للتحديد، و Claude 4.5 للتنفيذ ضمن هذا النطاق.
كلمة حول تكامل IDE
قاوم الرغبة في دمج هذا مباشرة في لوحة IDE بخمسين مفتاح تبديل. من الأسهل الوثوق بحلقة تعتمد على المحطة الطرفية مع اختلافات نصية عادية وتصحيحها. إذا كنت تريد سكر المحرر، فاجعله غبيًا:
- إظهار الفروق في عرض مقسم.
- مطالبة الموافقة على الكتابة (اختيارية ولكنها حكيمة).
يمكنك الدمج لاحقًا. أولاً، اجعله يعمل.
Sider.AI، المستخدم باعتدال، يساعد بالفعل إذا كنت تريد بيئة واقعية لتشغيل هذا النوع من الحلقات دون إعادة اختراع السقالات، فإن Sider.AI يعمل بالفعل - على الأقل عندما تستخدمه لما هو جيد فيه. فهو يحافظ على المحادثة والاختلافات مرتبة، ويتيح لك تشغيل الأوامر، ولا يجبرك على تناول "إطار عمل وكيل مستقل" ضخم. الحيلة هي الحفاظ على قواعدك الخاصة: مطالبات قصيرة، حلقات ضيقة، اختلافات مرئية. يبتعد Sider عن الطريق، وهو أمر نادر أكثر مما ينبغي. المزالق الشائعة (وكيفية تجنب الظهور بمظهر سخيف)
- السياق المحشو: إذا كانت مطالبتك تبدو وكأنها رسالة فدية، فأنت تفعل ذلك بشكل خاطئ. جلب الملفات حسب الطلب.
- إعادة الهيكلة المبكرة: يقترح الوكيل إعادة تنظيم الوحدات؟ اجعله يجتاز الاختبارات أولاً. أعد الهيكلة لاحقًا.
- الملفات المتوهمة: اطلب list_dir و read_file قبل أي write_file إلى مسار جديد.
- حلقات إعادة التشغيل اللانهائية: حدد الخطوات. اطلب تبريرًا لكل فرضية جديدة.
- فرق عملاق واحد: تقسيم التغييرات. تفشل الاختلافات الأصغر بشكل أسرع ويسهل التفكير فيها.
الأمن والسلامة بدون جنون العظمة
- التنفيذ المحلي: التشغيل في دليل معزول. لا توجد شبكة افتراضيًا.
- عزل التبعية: استخدم venv محليًا أو حاوية. تثبيت الإصدارات.
- الأسرار: الوكيل لا يحتاجها. إذا كان الأمر يتطلب رمزًا مميزًا، فتوقف واسأل.
- التدقيق: الاحتفاظ بكل خطة وفرق وأمر في سجل.
كيف تعرف أنه يعمل
- يتقلص المهلة الزمنية: إصلاحات الأخطاء التي كانت تستغرق ساعة تستغرق الآن عشر دقائق.
- أخطاء أقل في الأصابع السمينة: تصبح الفروق أصغر، وتصبح الاختبارات أكثر اخضرارًا.
- أنت تثق به: تتوقف عن التحليق فوق كل إجراء لأنه لم يحرقك.
- يستخدمه زملاؤك في الفريق: تعريف النجاح هو أن يتبناه الآخرون دون اجتماع.
التوسع، بحذر
إذا كان يجب عليك حقًا التوسع، فافعل ذلك بانضباط:
- مهام فرعية متوازية، وليس عقول متوازية: قسّم العمل، وقم بتشغيل حلقات خفيفة الوزن متعددة في أدلة منفصلة، وادمجها عند اللون الأخضر.
- ذاكرة عرضية، وليس تفريغًا للدماغ: قم بتخزين التصحيحات الناجحة وتعيينات الأعراض للإصلاح. استرجاع جراحيًا.
- تمريرات "أكبر" دورية: احتفظ بجلسة موجهة من قبل الإنسان لإعادة الهيكلة؛ يساعد الوكيل، ولا يقود.
تنفيذ مرجعي بسيط (رسم تخطيطي)
تعليمات برمجية زائفة تشبه Python للتحرك:
- def init(self, repo_root, model):
- self.history = [] # آخر اختلافين ومخرجات الاختبار
- "repo": summarize_repo(self.root),
- "constraints": {"write_whitelist": ["src/", "tests/"], "max_diff_lines": 300, "no_network": True},
- "history": self.history[-2:],
- plan = self.model("propose_plan", self.context(task))
- diff = self.model("propose_patch", {"plan": plan})
- out = run_cmd(plan.test_cmd)
- eval = self.model("evaluate", {"output": out, "plan": plan})
- self.history.append({"diff": diff, "out": tail(out)})
نهاية بحجم الإنسان
تواصل الصناعة وعد بوجود وكلاء مطورين مستقلين. ما نحتاجه بالفعل هو مساعد صادق يقرأ ويخطط ويحرر ويشغل ويتوقف. Claude 4.5 جيد في ذلك، بشرط ألا تدفنه تحت الأطر الموجودة في الغالب لتبرير نفسها. الوزن الخفيف ليس حلاً وسطًا - بل هو الهدف. قم ببناء الحلقة، وأضف الحواجز الواقية، ودع الأداة تفعل الشيء الوحيد الذي فعلته الأدوات دائمًا عندما تبقيها بسيطة: اجعل العمل أصغر.
الخلاصة: الاختصار الممل الذي يفوز
إليك قائمة التحقق الخاصة بك لوكيل ترميز خفيف الوزن مع Claude 4.5:
- حلقة واحدة، نموذج واحد، أدوات صغيرة.
- سياق ضيق: مهمة، عدد قليل من الملفات، المخرجات الأخيرة.
- الحد الأدنى من الاختلافات، والاختبارات المتكررة، والحدود القصوى الصعبة.
- تنفيذ محلي ومعزول؛ لا توجد شبكة.
- سكر المحرر الاختياري؛ غير مطلوب أبدًا.
إذا حولت عينيك، فإنه يبدو بشكل مثير للريبة وكأنه هندسة برمجيات جيدة، ولكن بشكل أسرع. وهذا هو لب الموضوع. أذكى شيء يمكنك القيام به هنا ليس مطاردة "الاستقلالية" - بل هو تدوين الانضباط. كلما قللت ما تطلبه من الوكيل، زاد ما تحصل عليه.
الأسئلة الشائعة
س 1: كيف أبدأ في بناء وكيل ترميز خفيف الوزن باستخدام Claude 4.5؟
حدد مجموعة أدوات صغيرة (قراءة وكتابة وبحث وتشغيل)، واكتب مطالبة نظام صارمة، ونفذ حلقة المراقبة ← التخطيط ← التنفيذ ← التفكير. حافظ على السياق صغيرًا وقدم سجلات وفروق حقيقية - يؤدي Claude 4.5 أداءً أفضل عندما تكون المهمة ضيقة والتغذية الراجعة ملموسة.
س 2: هل أحتاج إلى قاعدة بيانات متجهات أو طبقة ذاكرة لوكيل ترميز Claude 4.5؟
لا. بالنسبة لمعظم المهام، تكفي الذاكرة قصيرة المدى بالإضافة إلى search_code. أضف ذاكرة طويلة المدى فقط إذا قمت بزيارة نفس المستودع بشكل متكرر ويمكنك إثبات أنه يوفر الرموز المميزة دون جعل الوكيل أغبى.
س 3: ما هي الحواجز الواقية الأساسية لوكيل ترميز Claude 4.5؟
القائمة البيضاء للمسارات القابلة للكتابة، والحد من أحجام الفروق، وتقييد الأوامر، وتسجيل كل إجراء. تحافظ هذه الحدود البسيطة على الوكيل قابلاً للتنبؤ وتجعل عمليات التراجع مملة - بطريقة جيدة.
س 4: هل يمكن لوكيل خفيف الوزن التعامل مع إعادة هيكلة الملفات المتعددة؟
نعم، إذا قمت بتقسيم العمل إلى خطوات صغيرة وحافظت على الحلقة ضيقة. يمكن لـ Claude 4.5 إدارة عمليات إعادة الهيكلة، لكنك توجه النطاق؛ وإلا فستحصل على فرق عملاق وهش لن ترغب في مراجعته.
س 5: أين تتناسب Sider.AI مع وكيل ترميز Claude 4.5؟
Sider.AI مفيد كمساحة عمل مرتبة: المحادثات والاختلافات والأوامر في مكان واحد، دون فرض إطار عمل وكيل ثقيل الوزن. استخدمه لتشغيل حلقتك، وليس لإعادة اختراعها. 
