Anthropic تعلّم Claude بناء التطبيقات لساعات: ثلاثة وكلاء وأربعة معايير

نشرت Anthropic تحليلًا هندسيًا لكيفية بناء harness لجلسات برمجة طويلة ومستقلة. أمضى المؤلف، Prithvi Rajasekaran من فريق Labs، عدة أشهر في معالجة مهمتين مترابطتين: جعل Claude ينتج تصميم واجهات أمامية قويًا، وجعله يبني تطبيقات كاملة دون تدخل بشري. والنتيجة بنية من ثلاثة وكلاء هي planner–generator–evaluator، تنتج في جلسات تمتد ساعات منتجات full-stack غنية. والمبدأ مأخوذ من الشبكات التوليدية التنافسية (GAN).

أين ينهار الوكيل المنفرد

استخدم الإصدار السابق من harness وكيلًا مهيِّئًا يقسّم المواصفات إلى مهام، ووكيل برمجة ينفذ ميزة واحدة في كل مرة. وبلغ هذا الإصدار سقفه لسببين.

السبب الأول: في المهام الطويلة يفقد النموذج تماسكه كلما امتلأ السياق. وتظهر على بعض النماذج أيضًا «قلق السياق»، فتبدأ بإنهاء العمل قبل أوانه حين تشعر باقتراب الحد الأقصى. والضغط (compaction)، أي تلخيص الجزء القديم من المحادثة في موضعه، لا يمنح صفحة بيضاء، ولذلك يبقى القلق. لهذا احتاج Sonnet 4.5 إلى إعادة ضبط كاملة للسياق مع نقل منظم للحالة. وثمن هذا الحل: تعقيد أكبر في التنسيق، واستهلاك أعلى للتوكنات، وزمن استجابة أطول.

السبب الثاني: التقييم الذاتي. فالوكيل الذي يُطلب منه تقييم عمله يمتدحه بثقة، حتى حين يرى الإنسان أنه عمل متوسط. ويظهر ذلك بوضوح في التصميم خاصة، إذ لا يوجد اختبار ثنائي مثل اختبار الوحدة. وفصل «المنفِّذ» عن «الحَكَم» لا يعالج التساهل بالكامل، فالمقيّم يبقى LLM ويميل إلى النصوص الصادرة عن LLM. لكن ضبط مقيّم مستقل ومتشكك أسهل بكثير من تعليم المولّد أن ينتقد نفسه.

التصميم: أربعة معايير بدل «جميل»

سؤال «هل التصميم جميل؟» يعطي تقييمات غير مستقرة، أما «هل يتبع مبادئنا في التصميم الجيد؟» فيمكن تقييمه. صاغ Rajasekaran أربعة معايير وعرضها على الوكيلين معًا:

• Design quality: تماسك المزاج والهوية، لا مجرد مجموعة تفاصيل.
• Originality: قرارات إبداعية واعية بدل القوالب والإعدادات الافتراضية للمكتبات و«AI slop» مثل التدرجات البنفسجية على بطاقات بيضاء.
• Craft: التسلسل الهرمي للخطوط، والمسافات، والتباين. وهنا Claude قوي أصلًا.
• Functionality: سهولة الاستخدام بصرف النظر عن الجماليات.

أُعطي الوزن الأكبر للجودة والأصالة، لأن النموذج كان يقدّم فيهما نتائج باهتة. وعُيِّرت قدرة المقيّم بأمثلة few-shot مع شرح للدرجات، حتى لا تتذبذب التقييمات. وبُنيت الحلقة على Claude Agent SDK. وحصل المقيّم على Playwright MCP، فكان يتنقل بنفسه في الصفحة الحية، ويلتقط لقطات الشاشة، ويكتب النقد. واستغرق التشغيل الواحد من 5 إلى 15 تكرارًا وما يصل إلى أربع ساعات.

ومن اللافت أن صياغة المعايير أثّرت في النتيجة أكثر من المتوقع. فعبارة «أفضل تصاميم بمستوى المتاحف» كانت تحصر الأعمال في أسلوب بصري محدد. ولم يكن التحسن خطيًا تمامًا، وكثيرًا ما فضّل المؤلف تكرارًا وسيطًا على النسخة النهائية. وفي مثال موقع متحف هولندي، خرجت النسخة التاسعة بصفحة هبوط داكنة أنيقة. وفي النسخة العاشرة تخلى النموذج عنها وصمم غرفة ثلاثية الأبعاد بأرضية شطرنجية باستخدام CSS perspective، مع لوحات على الجدران وتنقل عبر فتحات الأبواب.

ثلاثة وكلاء لتطبيقات full-stack

في تطوير التطبيقات تولّى QA ومراجعة الشيفرة دور مقيّم التصميم. وقلّص Opus 4.5 «قلق السياق» إلى حد كبير، فأُلغيت عمليات إعادة الضبط: تسير الجلسة دون انقطاع، ويتولى الضغط التلقائي في SDK احتواء نمو السياق.

يحوّل planner طلبًا من 1–4 جمل إلى مواصفات منتج كاملة. وأُبقي عمدًا على مستوى المنتج والبنية عالية المستوى، لأن أي خطأ في التفاصيل التقنية الدقيقة كان سينتقل بالتتابع إلى التنفيذ. ويعمل generator على شكل سبرنتات، ميزة واحدة في كل مرة، باستخدام React وVite وFastAPI وSQLite (ثم PostgreSQL لاحقًا)، مع git وفحص ذاتي قبل التسليم إلى QA. أما evaluator فينقر عبر Playwright MCP على التطبيق قيد التشغيل كما يفعل المستخدم، ويفحص واجهة المستخدم وAPI وحالة قاعدة البيانات. ويقيّم الأخطاء والمعايير: عمق المنتج، والوظائف، والتصميم، وجودة الشيفرة. ولكل معيار حد صارم، والإخفاق في أي معيار يعني إخفاق السبرنت.

قبل كل سبرنت يتفق المولّد والمقيّم على «عقد»: ما الذي يُعدّ جاهزًا، وذلك قبل كتابة أي شيفرة. وهذا العقد جسر بين قصص المستخدم عالية المستوى والتنفيذ القابل للتحقق.

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