فرق من الوكلاء بتكلفة 155 دولارًا بدلًا من 510 دولارات: Cohere تكتشف أين يكون التفويض مُجديًا

الوكلاء انتقلوا إلى بيئة الإنتاج

خلال العام الماضي، خرجت فرق الوكلاء المبرمجين من وضعية العروض التجريبية المثيرة للاهتمام إلى مشاريع صناعية حقيقية. فقد كتب 16 وكيل Claude مُترجمًا للغة C بحجم 100 ألف سطر من الكود، قادرًا على بناء نواة Linux، بتكلفة بلغت نحو 2000 جلسة و20 ألف دولار من استهلاك واجهة برمجة التطبيقات (API). وأطلق فريق Cursor مئات الوكلاء الذين كتبوا بشكل مشترك متصفح ويب بأكثر من مليون سطر من الكود في أسبوع واحد. ونقل مشروع Bun قاعدة الكود من لغة Zig إلى Rust في 11 يومًا، باستخدام 64 وكيل Claude عملوا بالتوازي.

أفرز كل من هذه المشاريع كودًا عاملًا، لكنها اختلفت في طريقة التنظيم: فقد تم تجميع المُترجم بواسطة وكلاء متساوين دون منظّم مركزي، يختطفون المهام عبر ملفات القفل (lock-files)؛ أما Cursor فطبّقت تسلسلًا هرميًا — حيث قسّم المخططون العمل بشكل تكراري إلى مهام فرعية لمئات العاملين؛ وحدد Bun أدوارًا ثابتة: منفّذ واحد، ومراجعان ناقدان، ومُصلح واحد لكل مهمة.

مقارنة هذه المشاريع لن تقول شيئًا عن القرارات التي كان لها وزن حقيقي ولا عن تكلفتها. ونشرت Factory دراسة عن نظامها الخاص المكوّن من ثلاثة أدوار (منظّم ← منفّذ ← مُدقّق في حلقة متكررة): في مهمة واحدة (استعادة مكتبة GDAL)، ضاعف فريقها نتيجة وكيل واحد، لكن بتكلفة أعلى بـ 14 مرة ووقت أطول بـ 13 مرة.

أين يتم التفويض أهم من عدد الوكلاء

بنت Cohere منصة اختبار مُحكّمة قائمة على mini-SWE-agent: يعمل كل وكيل عبر واجهة bash في مساحة عمل مشتركة، ويوزّع القائد المهام عبر أداة delegate_agent، ولا يرى العاملون سوى مهمتهم الفرعية الخاصة. وتمت دراسة خمسة متغيرات:

1. أين يستخدم القائد العاملين: يأمر التوجيه (prompt) الأدنى بإدارة الفريق فقط؛ بينما يضيف التوجيه المُهيكل (P-I-V) مراحل واضحة — التخطيط، والتنفيذ، والتحقق. 2. كيف ينتظر القائد: متزامن (ينتظر حتى يُقدّم الجميع تقاريرهم) أو غير متزامن (يستمر في العمل بنفسه، مع فحص التحديثات عند الطلب). 3. أي النماذج تُستخدم في أي الأدوار: فرق متجانسة (جميعهم على Sol) في مقابل فرق غير متجانسة (القائد على Sol، والعاملون على Luna). 4. حجم الفريق: يقرر القائد بنفسه عدد العاملين اللازمين، أو يتم تثبيت الحجم عند 2 أو 4 أو 8 أو 16. 5. التواصل: عبر القائد (الوضع الافتراضي) أو مباشرة بين الوكلاء.

أُجريت الاختبارات على معيار ProgramBench — 200 برنامج، من الأدوات (jq، ripgrep) إلى الأنظمة المعقدة (SQLite، FFmpeg، مُفسِّر PHP). لا يرى الوكيل سوى الملف التنفيذي العامل وتوثيق البرنامج الأصلي، وعليه أن يكتشف السلوك عبر الهندسة العكسية ويكتب تنفيذًا جديدًا. ويعتمد التقييم على نسبة اختبارات السلوك التي نجح فيها.

التخطيط يحقق ربحًا أكبر بمقدار 2×

تفوّق فريق قوي من وكلاء Sol على وكيل واحد بفارق 9.7 نقطة (61.8% مقابل 52.1%)، لكن بتكلفة أعلى بـ 4 إلى 7 مرات. ويوفّر القائد غير المتزامن الوقت: فمع توجيه PIV، ينتهي العمل بسرعة أكبر بنسبة 19.5% مع تحقيق نفس النتيجة.

الاكتشاف الأساسي: عندما فوّض القائد التخطيط فقط (حيث يستكشف وكلاء Luna البرنامج، ويحددون السلوك، ويضعون مخططًا)، حقق دقة بنسبة 63.6% بتكلفة 249 دولارًا. وهذا يساوي تمامًا نصف الـ 510 دولارات التي يُنفقها فريق يُفوّض المراحل الثلاث، مع خسارة لا تتجاوز 0.4 نقطة فقط (63.2% مقابل 63.6%). أما التنفيذ والتحقق فقد حققا نتائج أقل بوضوح — بين 58% و71% باستخدام نفس الـ 16 وكيلًا.

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

وعلى سبيل المثال في أداة dsq: حقق وكيل واحد بتوجيه PIV نسبة 60%، بينما حقق الفريق الذي يُفوّض التخطيط فقط نسبة بين 76% و79%، وتفوّقت كل واحدة من تشغيلاته الست على كل تشغيل فردي. وأعطى تفويض التنفيذ أو التحقق في الظروف نفسها نسبة بين 58% و71%.

وأكد معيار Commit0-Lite الثانوي (16 مكتبة بايثون مع إزالة التنفيذ، لكن مع توثيق واختبارات كاملة) هذه النتيجة: فعندما تُعطى المواصفات بشكل صريح، تبقى مرحلة التخطيط حاسمة الأهمية.