مايكروسوفت وبيركلي تنشران TokenEconomizer: الوكلاء يبرمجون بتكلفة أقل بنسبة 18–31%

ترتفع فاتورة وكلاء البرمجة بوتيرة أسرع مما قد يبدو. فتشغيل Claude Code أو Codex مرة واحدة على مهمة غير بسيطة يتضمن عشرات الخطوات، وفي كل خطوة يعيد النموذج قراءة السياق المتراكم. لذلك، يجذب أي وعد بخفض النفقات من دون تغيير النموذج اهتمام الفرق التي أصبحت الرموز لديها بندا مستقلا في الميزانية.

وهذا بالضبط ما تعد به مايكروسوفت وUC Berkeley، إذ نشرتا TokenEconomizer، وهي أداة لخفض تكلفة الوكلاء.

ما الذي تم الإعلان عنه

وفقا لمنشور على X، اختبر الفريق الأداة على 277 مهمة من SWE-Bench. وشمل الاختبار خمس توليفات من الوكلاء والنماذج. وانخفض متوسط تكلفة التنفيذ بنسبة 18.4–30.9% بحسب التوليفة. وقد وُضع الرقم الأعلى، 30.9%، في العنوان، لكنه يمثل أفضل حالة، وليس ضمانا لأي حزمة تقنية.

العبارة المحورية هي «من دون المساس بالنموذج». فالتحسين يعمل من الخارج: لا يتطلب تدريبا إضافيا، ولا استبدال النموذج بخيار أرخص، ولا الوصول إلى أوزانه. وبالنسبة إلى من يستخدمون نماذج مغلقة عبر API، فهذه هي الرافعة الواقعية الوحيدة: لا يمكنكم التحكم في سعر الرمز، لكن يمكنكم التحكم جزئيا في عدد الرموز المستهلكة.

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

لماذا يهم ذلك عمليا

في سيناريوهات الوكلاء، لا تتكون التكلفة من طلب واحد، بل من سلسلة كاملة. فالسياق ومخرجات الأدوات والمحاولات المتكررة كلها تُحتسب تكلفتها مرة بعد أخرى. وتوفير 20–30% في مثل هذا التدفق ليس تحسينا شكليا. بالنسبة إلى فريق ينفق عدة آلاف من الدولارات شهريا على الوكلاء، سيكون الفارق ملموسا؛ أما بالنسبة إلى شركة ناشئة يقوم منتجها أساسا على وكيل برمجة، فقد يغير ذلك اقتصاديات الوحدة.

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

ما الذي ينبغي التحقق منه

أولا، المقاييس. يتحدث المنشور عن التكلفة، لكنه لا يذكر شيئا عن نسبة المهام التي جرى حلها. فإذا تحقق التوفير على حساب تراجع الجودة، فلا توجد مكاسب فعلية. ويجب التحقق مما إذا كان معدل الحل الناجح قد بقي عند مستواه السابق.

ثانيا، قابلية نقل النتائج إلى الواقع. تتكون SWE-Bench من مهام مصاغة بعناية ومأخوذة من مستودعات مفتوحة المصدر شائعة. أما مستودعكم الأحادي الخاص، ذو سجل الالتزامات الفوضوي، فله طبيعة مختلفة؛ وقد تتحول نسبة 18–31% فيه إلى 10% أو، على العكس، إلى 35%.

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

ما الذي ينبغي فعله

الخطة العملية بسيطة. استنسخوا المستودع وشغلوه على 20–30 مهمة نموذجية لديكم، مرة مع تفعيل الأداة ومرة من دونها، ثم قارنوا التكلفة ونسبة الحلول الناجحة. وإذا تحقق حتى نصف التوفير المعلن، فسيعوض التطبيق تكلفته خلال أيام قليلة. وإن لم يحدث ذلك، فستخسرون بضع ساعات فقط، وستحصلون على بياناتكم الخاصة بدلا من الاعتماد على نسب الآخرين.