إضافة TokenEconomizer من Microsoft تخفّض تكلفة تشغيل وكلاء البرمجة بنسبة 18,4–30,9%

نشرت Microsoft على GitHub إضافة TokenEconomizer التي تقلّل استهلاك الرموز (tokens) لدى وكلاء البرمجة. وتعمل الإضافة مع أربع أدوات: Claude Code وCodex وCopilot CLI وPi. وبحسب اختبارات الأداء المعروضة، ينخفض متوسط تكلفة تشغيل الوكلاء بنسبة 18,4–30,9%، دون أن تتراجع جودة النتيجة. ولا تغيّر الإضافة النموذج نفسه، بل تعمل حول الوكيل وتزيل ما يُدفع ثمنه بلا طائل.

ما الذي يحفظه TokenEconomizer وما الذي يعطّله

تتعلّم الإضافة من سجل الجلسات السابقة في مستودع بعينه. ويذكر وصف المشروع ثلاث آليات.

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

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

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

جدير بالذكر أن الآليات الثلاث تعتمد جميعها على بيانات مستودع بعينه. وكلما تراكمت الجلسات، زادت المادة المتاحة للتعلّم. ولا تفرض الإضافة قواعد عامة «لكل المشاريع».

أين تحتاج الأرقام إلى تحقق

يتعلّق النطاق 18,4–30,9% بمتوسط تكلفة تشغيل الوكلاء. ويدل التفاوت البالغ نحو 12 نقطة مئوية على أن النتيجة تتوقف على الظروف. ولا تتضمن الرسالة الأصلية بيانات عن المهام والمستودعات التي أُجري عليها القياس، ولا عن النماذج المستخدمة، ولا عن طريقة تقييم الجودة. وعبارة «دون خسارة في الجودة» تحتاج بدورها إلى توضيح: أي مقياس اعتُمد، وعلى أي مجموعة من المهام، وما هامش التسامح. والأجدر البحث عن إجابات هذه الأسئلة في مستودع المشروع.

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

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

لمن يستحق التجربة

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

ومن اللافت أيضًا أن Microsoft أنشأت الإضافة لعدة وكلاء متنافسين في آن واحد، منهم Claude Code وCodex، وليس لأداتها Copilot CLI وحدها. فتوفير الرموز لم يعد مهمة مطوّر بعينه، بل أصبح طبقة مستقلة فوق الوكلاء: إذ لا يتوقف الاستهلاك على النموذج فقط، بل على طريقة تعامل الوكيل مع السياق والأدوات.

النصيحة العملية بسيطة. قبل اعتماد الإضافة في الفريق، شغّلها على مستودعك وقارن مؤشرين: تكلفة الجلسة، ونسبة المهام المحلولة من المحاولة الأولى. فإذا انخفض الأول بوضوح وبقي الثاني على مستواه، فقد تأكدت أرقام Microsoft في حالتك. والشيفرة المصدرية والوثائق متاحتان في مستودع microsoft/TokenEconomizer على GitHub.