الوكيل يحتاج إلى "مؤشر الزيت" و"الفرامل": ورقة بحثية تكشف عن "حسابات الوكيل" غير الواضحة

لا شيء

تخيل هذا المشهد:

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

تغلق الكمبيوتر، تتنفس الصعداء. ثم تتلقى فاتورة API.

قد تجعلك الأرقام أعلاه تتنفس بصعوبة — فـ AI Agent الذي يصلح الأخطاء بشكل مستقل، عند استخدام API الرسمي في الخارج، غالبًا ما يستهلك أكثر من مليون توكن في مهمة غير مكتملة، وتكلفتها قد تصل إلى عشرات أو مئات الدولارات.

في أبريل 2026، نشرت ورقة بحثية مشتركة من ستانفورد، MIT، جامعة ميشيغان وغيرها، لأول مرة بشكل منهجي، فتح “صندوق الظلام” الخاص بـ استهلاك AI Agent في مهام البرمجة — أين صرفت الأموال، هل كانت مجدية، هل يمكن التنبؤ بها مسبقًا، وكانت الإجابة مدهشة.

النتيجة الأولى: سرعة استهلاك الوكيل للمال في كتابة الكود، هي 1000 ضعف سرعة الحوار العادي مع الذكاء الاصطناعي

قد يظن الناس أن جعل الذكاء الاصطناعي يكتب لك الكود ويحادثك حول الكود، يجب أن يكلف نفس الشيء تقريبًا، أليس كذلك؟

لكن الورقة تظهر مقارنة:

استهلاك التوكن في مهمة ترميز Agentic، هو حوالي 1000 ضعف استهلاك أسئلة وأجوبة الكود العادية ومهام استنتاج الكود.

ثلاثة أرقام كاملة.

لماذا يحدث ذلك؟ تشير الورقة إلى حقيقة — أن المال لا يُصرف على “كتابة الكود”، بل يُصرف على “قراءة الكود”.

هنا، “القراءة” لا تعني قراءة الإنسان للكود، بل أن الوكيل خلال عمله يحتاج باستمرار إلى تغذية النموذج بكامل سياق المشروع، سجل العمليات التاريخية، رسائل الخطأ، محتوى الملفات. وكلما زادت جولة الحوار، زاد طول السياق؛ والنموذج يُحتسب تكلفته بناءً على عدد التوكن — كلما زدت التغذية، زادت التكلفة.

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

تلخص الورقة هذه الظاهرة في جملة: أن تكلفة تشغيل الوكيل تتزايد أُسّيًا مع زيادة إدخال التوكن، وليس مع إخراج التوكن.

النتيجة الثانية: نفس الخطأ، تشغيله مرتين، يمكن أن يكلف ضعف — وكلما كان الخطأ أغلى، كان أقل استقرارًا

الأمر المزعج أكثر هو العشوائية.

قام الباحثون بتشغيل نفس الوكيل على نفس المهمة 4 مرات، ووجدوا:

بين المهام المختلفة، أكثر مهمة استهلاكًا للمال تتطلب حوالي 7 ملايين توكن أكثر من أرخص مهمة (الشكل 2a)

وفي نفس النموذج، نفس المهمة، في عدة تشغيلات، أعلى استهلاك يمكن أن يكون ضعف أدنى استهلاك (الشكل 2b)

وعند مقارنة نماذج مختلفة لنفس المهمة، يمكن أن يختلف الاستهلاك الأعلى عن الأدنى بمقدار 30 ضعفًا

وأخيرًا، الرقم الأخير مهم جدًا: هذا يعني أن الفرق في التكاليف بين اختيار النموذج الصحيح والخاطئ، ليس “أغلى قليلاً”، بل “بمقدار رقم قياسي”.

الأكثر إيلامًا — أن الإنفاق أكثر لا يعني أداءً أفضل.

اكتشفت الورقة وجود “منحنى على شكل حرف U” عكسي:

مستوى التكلفة، والدقة، يتبعان نمطًا منخفض التكاليف، حيث الدقة منخفضة (ربما بسبب نقص الاستثمار)؛ متوسط التكاليف غالبًا ما يكون الأعلى؛ أما التكاليف العالية، فهي لا تزداد، بل تنخفض، وتدخل “منطقة التشبع”.

لماذا يحدث ذلك؟ تقدم الورقة تفسيرًا من خلال تحليل العمليات المحددة للوكيل —

في العمليات ذات التكاليف العالية، يقضي الوكيل وقتًا كبيرًا في “العمل المتكرر”.

وجد الباحثون أن حوالي 50% من عمليات مراجعة وتعديل الملفات في العمليات ذات التكاليف العالية تتكرر — بمعنى أن الوكيل يقرأ نفس الملف مرارًا وتكرارًا، ويعدل نفس السطر، كأنه يدور في غرفة، يدوخ أكثر، ويزداد الدوخة.

المال لا يُصرف على حل المشكلة، بل على “الضياع”.

النتيجة الثالثة: كفاءة النماذج تختلف بشكل كبير — GPT-5 هو الأكثر كفاءة، وبعض النماذج تستهلك 1.5 مليون توكن أكثر

اختبرت الورقة أداء 8 نماذج متقدمة على معيار SWE-bench Verified (500 مشكلة حقيقية من GitHub). عند تحويلها إلى دولارات، النماذج ذات الكفاءة العالية في استهلاك التوكن يمكن أن توفر عشرات الدولارات لكل مهمة. وإذا طبقنا ذلك على تطبيقات الشركات — التي تنفذ مئات المهام يوميًا — فإن الفرق يصبح حقيقيًا وماليًا.

والمثير أكثر: أن كفاءة التوكن هي “طبيعة” النموذج، وليست ناتجة عن المهمة.

قارن الباحثون بين جميع المهام التي نجح فيها جميع النماذج (230 مهمة) وتلك التي فشلت فيها جميعها (100 مهمة)، ووجدوا أن ترتيب النماذج لا يتغير تقريبًا.

وهذا يدل على أن بعض النماذج بطبيعتها “ثرثارة”، ولا علاقة لذلك بصعوبة المهمة.

ووجدت الدراسة أن النماذج تفتقر إلى “وعي بوقف التكاليف”.

عند مواجهة مهمة صعبة لا يمكن حلها، من المفترض أن يتوقف الوكيل مبكرًا، بدلاً من استهلاك المزيد من التوكنات. لكن الواقع أن النماذج تستهلك المزيد من التوكنات في المهام الفاشلة — فهي لا “تعترف” بالفشل، بل تواصل الاستكشاف، وإعادة المحاولة، وإعادة قراءة السياق، كسيارة بدون مؤشر مستوى الوقود، تقود حتى تتوقف.

النتيجة الرابعة: الإنسان يظن أن المهام الصعبة مكلفة، والوكيل قد لا يراها كذلك — الإدراك غير متطابق

قد تتساءل: على الأقل، يمكنني تقدير التكاليف بناءً على مدى صعوبة المهمة، أليس كذلك؟

استخدمت الورقة خبراء بشريين لتقييم صعوبة 500 مهمة، ثم قارنوا ذلك مع استهلاك التوكن الفعلي للوكيل —

النتيجة: الارتباط ضعيف جدًا.

بعبارات بسيطة: المهام التي يراها الإنسان صعبة جدًا، قد يكون الوكيل قادرًا على إنجازها بسهولة وبتكلفة منخفضة؛ والمهام التي يراها الإنسان سهلة، قد تستهلك الكثير من التوكنات.

وذلك لأن البشر وAI “يرون” الصعوبة بشكل مختلف:

البشر ينظرون إلى: التعقيد المنطقي، صعوبة الخوارزمية، حاجز فهم العمل

أما الوكيل، فينظر إلى: حجم المشروع، كمية الملفات التي يجب قراءتها، طول مسار الاستكشاف، مدى تكرار التعديلات على نفس الملف

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

وهذا يؤدي إلى واقع محرج: من الصعب على المطورين تقدير تكاليف تشغيل الوكيل بناءً على الحدس.

النتيجة الخامسة: حتى النماذج لا تستطيع تقدير تكاليفها بدقة

بما أن البشر غير قادرين على التقدير، فهل يمكن للذكاء الاصطناعي أن يتوقع ذلك بنفسه؟

صمم الباحثون تجربة دقيقة: جعلوا الوكيل “يفحص” قاعدة الكود قبل أن يبدأ في إصلاح الخطأ، ثم يتوقع كم من التوكنات سيستهلك — بدون تنفيذ الإصلاح فعليًا.

ماذا كانت النتيجة؟

فشلت جميع النماذج.

أفضل أداء كان من Claude Sonnet-4.5 في التنبؤ بعدد التوكنات، بنسبة ارتباط 0.39 (من 1.0). ومعظم النماذج كانت بين 0.05 و0.34، وGemini-3-Pro كانت الأدنى عند 0.04 — تقريبًا تخمين عشوائي.

والأسوأ أن جميع النماذج كانت تقدر استهلاكها بشكل منخفض جدًا — أي أنها تظن أنها ستستهلك أقل بكثير مما فعلت في الواقع. في الشكل 11، تظهر النقاط على الرسم البياني أن النماذج تعتقد أنها ستنفق أقل، لكنها تنفق أكثر، خاصة عندما لا تقدم أمثلة.

والسخرية أن التوقعات نفسها تتطلب تكلفة — فحتى التنبؤ يستهلك توكنات.

توقعات Claude Sonnet-3.7 وSonnet-4 كانت تكلف أكثر من ضعف مهمة التوكنات نفسها. بمعنى، أن تجعلها “تقدر السعر” قبل العمل، يكلف أكثر من العمل نفسه.

تخلص الورقة إلى أن:

النماذج المتقدمة حاليًا غير قادرة على التنبؤ بدقة بعدد التوكنات التي ستستهلكها. عند الضغط على زر “تشغيل الوكيل”، الأمر أشبه بفتح صندوق غامض — لا تعرف المبلغ حتى تظهر الفاتورة.

وهذا “الخلل” يكشف عن مشكلة أعمق في الصناعة

قد تتساءل: ماذا تعني هذه الاكتشافات للشركات؟

1. “نموذج الاشتراك الشهري” يتعرض للتمزق بسبب هذه الظاهرة

تشير الورقة إلى أن اشتراكات مثل ChatGPT Plus كانت ممكنة لأنها تعتمد على استهلاك توكنات متوقع نسبيًا، لكن مهام الوكيل تخرق هذا الافتراض — فمهمة واحدة قد تتسبب في استهلاك كمية هائلة من التوكنات بسبب حلقات التكرار.

وهذا يعني أن التسعير على أساس الاشتراك قد لا يكون مستدامًا، وأن التسعير حسب الاستخدام (Pay-as-you-go) هو الخيار الأكثر واقعية على المدى الطويل. لكن، مشكلة هذا الخيار هو أن الاستخدام غير متوقع.

2. كفاءة التوكن يجب أن تكون معيارًا ثالثًا عند اختيار النموذج

عادة، تختار الشركات النموذج بناءً على: القدرة (هل يمكنه إنجاز المهمة) والسرعة (هل ينفذ بسرعة). لكن الورقة تقدم بعدًا ثالثًا مهمًا: الكفاءة في استهلاك التوكن (كمية التوكنات اللازمة لإنجاز المهمة).

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

3. الوكيل يحتاج إلى “مؤشر مستوى الوقود” و"مكابح"

تُشير الورقة إلى اتجاه مستقبلي مهم — سياسات استخدام الأدوات مع وعي بالميزانية (Budget-aware tool-use policies). ببساطة، تزويد الوكيل بـ"مؤشر مستوى الوقود": عندما يقترب استهلاك التوكنات من الحد المسموح، يتوقف عن الاستكشاف غير المجدي، بدلاً من استهلاك المزيد بلا فائدة.

حاليًا، معظم أطر الوكيل لا تتضمن هذه الآلية.

مشاكل “إهدار المال” في الوكيل، ليست خطأ برمجي، بل تحدٍ هيكلي في المجال

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

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

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