Anthropic تنصح بالتخلص من نصف الوكلاء الفرعيين: حلقة واحدة أثبتت أنها أسرع بمرتين

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

لماذا يحاكي الوكلاء الفرعيون الهيكل التنظيمي؟

يبدو الاستنتاج الرئيسي قريبًا من قانون كونواي: بنية الوكيل تكرر بنية الشركة. فكل فريق يبني وكيله الفرعي، ويضع فريق المنصة فوقها منسّقًا (orchestrator). ومن ثم تتراكم مشكلات متوقعة:

• يضيع السياق عند انتقاله بين الوكلاء؛
• تظهر مئات الوكلاء الفرعيين المتداخلين، بلا معايير ولا مالك؛
• يتحول موجّه النظام إلى «موجّه فرانكنشتاين»، إذ يضيف إليه كل فريق جملة؛
• تصبح تقييمات evals المحلية لكل فريق أساسًا لقرارات الإدارة، مع أنها لا تعكس جودة النظام ككل؛
• تزداد التأخيرات، لأن كل انتقال بين الوكلاء استدعاء مستقل للنموذج.

من زاوية اقتصاديات الرموز (tokens)، الصورة بسيطة. فكل تسليم للتحكم يعني إعادة سرد السياق وتكرار التعليمات وجولة استدلال (inference) إضافية. وأنت تدفع ثمن ذلك كله مرتين: مالًا ووقتَ استجابة.

حلقة واحدة بدل أوركسترا

يبدو المخطط الموصى به متواضعًا: حلقة واحدة، ونافذة سياق واحدة، وحدود صارمة لعدد الخطوات وللميزانية. ثم أربعة أساليب هندسية:

• الكشف التدريجي. لا يرى النموذج سوى أوصاف قصيرة للمهارات والأدوات، ويحمّل النصوص الكاملة عند الحاجة. وبهذه الطريقة قلّصت Anthropic موجّه النظام في Claude Code بأكثر من 80%.
• تجميع الأدوات بحسب نوايا المستخدم لا بحسب API. بعد 30–50 وصفًا للأدوات يبدأ اختيار الأداة بالتدهور، ولذلك فإن ثلاثين غلافًا رفيعًا حول طرائق REST أسوأ من عشر أدوات تطابق المهام الفعلية.
• التحقق من الصلاحيات داخل الأدوات. إذا لم تتوافر صلاحية الوصول، تعيد الأداة إلى النموذج رفضًا واضحًا. وعندئذ تخدم حلقة واحدة مستخدمين بمستويات وصول مختلفة، ولا حاجة إلى وكلاء منفصلين لكل دور.
• ملكية مركزية للجودة. يتولى فريق واحد صغير موجّه النظام والجودة النهائية بالكامل. أما بقية الفرق فتملك المهارات والأدوات، لا الوكلاء.

ومع ذلك لم تُحظر الوكلاء الفرعيون. فـ Anthropic تذكر ثلاث حالات يكون فيها استخدامهم مبررًا:

• وجود تدهور قابل للقياس بسبب تضخم السياق؛
• الحاجة إلى مهام متوازية بسياق جديد؛
• ارتباك الوكيل بين الأدوات والتعليمات المتناقضة.

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

الترحيل: من الأمثلة إلى المهارات

تصف المقالة تسلسل الخطوات بدقة نسبية:

• أولًا، جمع الأمثلة. يكفي حتى 10 أمثلة، فهي ستكون مجموعة المقارنة قبل التغيير وبعده.
• دمج الوكلاء الفرعيين الأكثر استخدامًا والأشد ترابطًا.
• استدعاء الوكلاء المتبقين بوصفهم أدوات، لا وكلاء مستقلين.
• تحويلهم إلى مهارات واحدًا تلو الآخر، ومقارنة النتيجة بالأمثلة المرجعية بعد كل خطوة.

ولهذا الغرض نشرت Anthropic على GitHub مجموعة migration kit تتضمن مهارة تساعد على اجتياز العملية.

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

والقصة هنا دالّة على الصناعة بأكملها. ففي العام الماضي كانت المنسّقات والأنظمة متعددة الوكلاء الاتجاه الرئيسي، أما الآن فتُعاد صياغتها بوصفها إرثًا قديمًا (legacy). ويشير كاتب الملخص في Telegram إلى أن OpenAI توصلت إلى استنتاجات مشابهة في منشورها عن مهندسيها Forward Deployed Engineers.