Anthropic تكشف كيف تجعل Claude يبرمج لأيام: قائمة من 200+ مهمة بصيغة JSON

نشرت Anthropic تحليلًا هندسيًا لكيفية إبقاء الوكلاء المبنيين على Claude Agent SDK في حالة عمل مستقرة عبر نوافذ سياق عديدة. نقطة الانطلاق أنه حتى Opus 4.5، عند تشغيله في حلقة بموجّه عالي المستوى واحد مثل «ابنِ نسخة مماثلة من claude.ai»، لا يصل بتطبيق الويب إلى جودة الإنتاج (production). ضغط السياق (compaction) يساعد، لكنه لا يحل المشكلة. يقترح كاتب النص Justin Young مخططًا يقوم على دورين، وسجل git، وملف تقدّم. وقد صُمّم على غرار عمل المهندسين الذين يسلّمون الورديات بعضهم لبعض دون ذاكرة شخصية عمّا سبق.

أين ينهار الوكلاء طويلو الأمد

رصد فريق Anthropic ثلاثة إخفاقات متكررة. الأول: يحاول الوكيل إنجاز كل شيء دفعة واحدة، فيصطدم بحد السياق في منتصف التنفيذ، ويترك للجلسة التالية وظيفة نصف منجزة وغير موثقة. وعلى الخلف أن يخمّن ما حدث، ويقضي وقتًا في استعادة الحد الأدنى من قابلية التشغيل. ضغط السياق لا يعالج ذلك، لأنه لا ينقل دائمًا تعليمات واضحة إلى الجلسة التالية.

يظهر الإخفاق الثاني قرب منتصف المشروع. ينظر نسخة جديدة من الوكيل حولها، فترى أن الكثير قد بُني بالفعل، وتعلن أن العمل اكتمل. أما الثالث فيتعلق بالتحقق: يعلّم Claude الوظيفة على أنها منجزة بعد اختبارات الوحدة (unit tests) أو طلبات curl إلى خادم التطوير، مع أن السيناريو الشامل (end-to-end) في المتصفح لا يعمل.

كيف صُمّم هيكل التشغيل

تتلقى الجلسة الأولى موجّهًا مستقلًا وتعمل كمُهيِّئ. الموجّه النظامي ومجموعة الأدوات والغلاف البرمجي المحيط بالوكيل متطابقة عند «الوكيلين»، والفرق الوحيد هو رسالة المستخدم الافتتاحية. ينشئ المُهيِّئ سكربت init.sh لتشغيل خادم التطوير، وملف claude-progress.txt الذي يحوي سجلًا بالإجراءات، وأول commit في git. وأهم ما يكتبه قائمة المتطلبات. في حالة نسخة claude.ai بلغت القائمة أكثر من 200 بند، مثل «يفتح المستخدم محادثة جديدة، ويكتب طلبًا، ويضغط Enter، ويرى ردّ الذكاء الاصطناعي». جميع البنود معلَّمة في البداية على أنها فاشلة.

أبرز معالم المخطط:

• صيغة قائمة الميزات: JSON بالحقول category وdescription وsteps وpasses. أما مع Markdown فكان النموذج يعيد الكتابة بوتيرة أعلى بوضوح.
• صلاحيات وكيل البرمجة: يمكنه تعديل الحقل passes فقط. وصياغة الموجّه صارمة: لا يجوز حذف الاختبارات أو تعديلها.
• حجم العمل: ميزة واحدة في كل دورة.
• إنهاء الجلسة: commit في git برسالة وصفية، وتسجيل في ملف التقدّم، ما يتيح التراجع عن التعديلات الفاشلة.
• بدء الجلسة: pwd، وقراءة git log وملف التقدّم، واختيار الميزة غير المنجزة الأعلى أولوية، وتشغيل init.sh، وإجراء اختبار شامل أساسي.

الاختبار وحدود المقاربة

فحص البداية بسيط: يشغّل الوكيل الخادم، ويفتح محادثة جديدة عبر Puppeteer MCP، ويرسل رسالة وينتظر الرد. إذا كان التطبيق معطوبًا، يُصلَح الخلل قبل بدء أي عمل جديد، وإلا فإن الميزة التالية ستزيد الوضع سوءًا. وعندما يُطلب من النموذج صراحةً الاختبار عبر أتمتة المتصفح كما يفعل الإنسان، فإنه يكتشف أخطاء لا تظهر في الشيفرة، وترتفع جودة النتيجة بوضوح، بحسب Anthropic. ويوفّر ذلك التوكنات أيضًا: فالوكيل لا يحتاج في كل مرة إلى معرفة كيفية تشغيل التطبيق والتحقق منه.

تبقى قيود. فعبر Puppeteer MCP لا يرى Claude النوافذ المنبثقة الأصلية للمتصفح مثل alert، ولذلك جاءت الوظائف التي تعتمد عليها أكثر عرضة للأخطاء. كما أن قدرة النموذج على الرؤية وإمكانات الأدوات لا تتيحان اكتشاف كل فئات الأخطاء.

ما الذي يمكن نقله إلى مشروعك

يمكن نقل الحد الأدنى العملي إلى أي خط أنابيب وكلاء من الآن. أنشئ موجّهًا افتتاحيًا مستقلًا لتجهيز البيئة. احفظ المتطلبات في ملف مقروء آليًا بحالة منطقية (boolean)، وامنع الوكيل من تعديل الصياغات. اشترط commit وتسجيلًا في السجل في نهاية كل جلسة. ابدأ كل جلسة بـ git log وتشغيل قصير للتطبيق. وأضف أدوات أتمتة المتصفح إذا كنت تختبر الويب.

يبقى سؤالان مفتوحين. لا يزال من غير الواضح هل وكيل برمجة عام واحد أفضل من مجموعة وكلاء متخصصين: مختبِر، وضمان جودة (QA)، ووكيل لتنظيف الشيفرة. كذلك فإن النتائج مستمدة من تطوير ويب متكامل (full-stack)، وكل ما تفترضه Anthropic أن جزءًا من الدروس قد ينتقل إلى البحث العلمي أو النمذجة المالية. هذه فرضية، وليست نتيجة مقاسة.