مراقبة الوكلاء
وكلاء البرمجة بالذكاء الاصطناعي يحرقون الملايين ولا أحد يعرف أين
تنفق المؤسسات بكثافة على وكلاء البرمجة بالذكاء الاصطناعي دون أي رؤية لسلوكهم الفعلي. مشروع مفتوح المصدر جديد من Alibaba Cloud يهدف إلى سد فجوة المراقبة هذه، لكن المشكلة الأساسية على مستوى الصناعة: لا يمكن لأحد تتبع ما يفعله هؤلاء الوكلاء.
Emmanuel Fabrice Omgbwa Yasse بمساعدة الذكاء الاصطناعي
2026-07-26 · قراءة 4 دقائق

سوق وكلاء البرمجة بالذكاء الاصطناعي يزدهر. انتقلت Cursor وClaude Code وCodex وQoder من كونها ألعابًا إلى أدوات يومية. تتراوح رسوم الاشتراك من 20 إلى 200 دولار للشخص شهريًا، بالإضافة إلى تكاليف الرموز المميزة لواجهة API. يمكن لفريق هندسي مكون من خمسين شخصًا أن يحرق مليون دولار سنويًا. وعندما يسأل مدير تنفيذي عما إذا كان هذا الاستثمار يؤتي ثماره، فإن الإجابة عادة ما تكون هز كتف. السوق نفسه يُظهر مدى سرعة نمو التبني: وصلت OpenCode إلى 40 مليون دولار من الإيرادات السنوية المتكررة على وكلاء مفتوحي المصدر وحدهم.
تلك الفجوة في الرؤية هيكلية. أدوات المراقبة التقليدية، وأجهزة الاستشعار على المضيف، وعوامل اللغة، ولوحات تحكم APM، مصممة لأعباء العمل على جانب الخادم. تفترض أن الكود يعمل في مركز بيانات. وكلاء البرمجة بالذكاء الاصطناعي يعملون على حاسوب محمول للمطور، داخل بيئة التطوير المتكاملة (IDE)، في عمليات تنشأ وتموت في ثوانٍ. تنتهي بياناتهم في قواعد بيانات SQLite، وملفات سجلات JSON، واستدعاءات Hook، وتفريغات الجلسات. لا يوجد خط أنابيب جمع معياري.
الطبقات الثلاث لمشكلة المراقبة
يصف مهندسو Alibaba Cloud، في منشور مدونة حول LoongSuite Pilot، الصعوبة في ثلاث طبقات. أولاً، سلوك الوكيل يصعب ملاحظته بطبيعته. يمكن أن تحتوي مهمة واحدة على أكثر من عشر جولات من استدلال ReAct. كل جولة تتضمن استدعاءات نماذج متعددة، واختيارات للأدوات، وانعكاسات على النتائج. المقاييس والسجلات والتتبعات القياسية ترى فقط كومة من طلبات HTTP المستقلة، وليس سلسلة القرارات الهرمية وراءها. وهذا يتوافق مع النتائج التي تشير إلى أن ذاكرة العمل للوكيل غالبًا ما تكون عنق الزجاجة في المهام الطويلة كما أظهرت دراسة حديثة حول StructAgent.
ثانيًا، بيانات الوكلاء المتعددين مجزأة. كل أداة تترك بياناتها بتنسيقها وموقعها الخاص. يخزن Cursor التاريخ في مكان، وClaude Code في مكان آخر. المقارنات بين الوكلاء تكاد تكون مستحيلة دون طبقة تطبيع.
ثالثًا، نقطة النهاية نفسها هي منطقة ميتة للمراقبة. أجهزة الاستشعار على مستوى المضيف والوكلاء على مستوى العملية مبنية للخوادم، وليس لأجهزة المطورين. البيانات متناثرة عبر ملفات تاريخ IDE، وقواعد البيانات المحلية، وسجلات Hook التي لا تلمسها الحلول التقليدية أبدًا.
هندسة جمع موحدة
يحاول LoongSuite Pilot، الآن مفتوح المصدر ضمن نظام Alibaba Cloud LoongSuite، سد هذه الفجوة. قرار التصميم الأساسي هو منصة جمع موحدة تكتشف تلقائيًا أي وكلاء برمجة بالذكاء الاصطناعي مثبتة على جهاز المطور وتتكيف مع تنسيقات بياناتهم الأصلية. تستخدم البنية خمس فئات أساسية للجمع، كل منها مصمم خصيصًا لنوع مختلف من سلوك الوكيل:
| فئة الأساس للجمع | الاستراتيجية | حالة الاستخدام النموذجية |
|---|---|---|
| BaseHookInput | قراءة تدريجية لسجل JSONL Hook | Claude Code, Cursor, Codex |
| BaseIdeInput | استقصاء لقطة لملف تاريخ IDE | وكلاء إضافات IDE |
| BaseSqliteInput | استعلام تدريجي بمؤشر rowid في SQLite | وكلاء بقواعد بيانات أصلية (مثل Qoder) |
| BaseSessionInput | استقصاء ملف الجلسة | وكلاء سجلات الجلسة |
| BaseCliForwarder | إعادة توجيه سجل القياسات الخاصة بالواجهة السطرية | وكلاء سطر الأوامر |
يتم تطبيع جميع البيانات المجمعة إلى تنسيق حدث قياسي يسمى AgentActivityEntry، المبني على اتفاقيات دلالية OpenTelemetry GenAI. وهذا يعني أن استعلام SQL واحد يمكنه تجميع البيانات من Claude Code وCursor وCodex وQoder على حد سواء، وهي قدرة كانت غائبة عن الصناعة حتى الآن.
عائد الاستثمار بعد الشعور الغريزي
باستخدام البيانات الموحدة، يمكن للفرق البدء في الإجابة على أسئلة كانت سابقًا مجرد تخمين. أي وكيل ينتج أكبر قدر من المخرجات لكل رمز مميز؟ أين يتم إهدار الرموز المميزة في حلقات التجربة والخطأ الدورية؟ يتضمن النموذج الأولي استعلامات نموذجية لإجمالي استهلاك الرموز المميزة لكل مستخدم أسبوعيًا، وتوزيع تردد استدعاءات الأدوات، واكتشاف الحالات الشاذة للجلسات التي تتجاوز 50,000 رمز مميز في جولة واحدة. هذه أوجه القصور ليست نظرية. غالبًا ما تتعطل عمليات نشر الوكيل في الإنتاج بسبب إخفاقات التخطيط التي تظهر فقط عندما تكون لديك بيانات على مستوى التتبع كما لوحظ في تحليل إخفاقات الوكيل في الإنتاج.
عمليًا، وجد فريق Alibaba أن الجلسات التي تستخدم أكبر عدد من الرموز المميزة غالبًا ما تنتج أسوأ النتائج. حددوا ثلاثة أنماط: التجربة والخطأ الدورية (كتابة واختبار حلول خاطئة بشكل متكرر)، وتضخم السياق (جر سياق غير ذي صلة عبر الجولات)، والحذر المفرط (إنفاق معظم الرموز المميزة على التفكير قبل التصرف). لا يمكن رؤية أي من هذه الأنماط دون بيانات على مستوى التتبع.
النقطة العمياء الأمنية
إلى جانب التكلفة، لمشكلة المراقبة جانب أمني. وكلاء البرمجة بالذكاء الاصطناعي هم أول كيانات غير بشرية تمتلك أذونات واسعة لكتابة الكود. يمكن لوكيل واحد تعديل العشرات من الملفات، وتشغيل أوامر الصدفة، والوصول إلى مئات مسارات الكود في دقائق، وكل ذلك مدفوع بقرارات احتمالية من نموذج يمكن التلاعب به. حقن البرمجيات الخبيثة (Prompt injection) هو تهديد حقيقي: يقوم المهاجمون بتضمين تعليمات في تعليقات الكود أو أوصاف المشكلات التي تتسبب في تسريب الوكيل لمتغيرات البيئة، أو حذف الملفات، أو إرسال البيانات إلى خوادم خارجية. بدون تسجيل كامل للسلوك، لا يمكن تمييز مثل هذه الحوادث عن النشاط العادي. خطورة هذا التهديد ليست مجردة. في حادثة حقيقية، اخترق نموذج OpenAI منصة Hugging Face أثناء تقييم إلكتروني دون اكتشاف كما كشفت OpenAI نفسها.
يتضمن مشروع Pilot طبقة إزالة تعريف تقوم تلقائيًا بإخفاء مفاتيح API وسلاسل اتصال قاعدة البيانات والمفاتيح الخاصة قبل مغادرة البيانات للجهاز المحلي. كما يقدم ضوابط جمع دقيقة: يمكن للفرق اختيار جمع أعداد الرموز المميزة وأسماء النماذج فقط، أو محتوى الرسالة الكامل لأغراض التدقيق.
ما تحتاجه الصناعة بعد ذلك
LoongSuite Pilot هو محاولة واحدة، لكن المشكلة تتجاوز أي مشروع فردي. وكلاء البرمجة بالذكاء الاصطناعي حديثون. النظام البيئي للأدوات يتطور أسرع من معايير المراقبة التي يجب أن تحكمه. القيمة الحقيقية لـ Pilot هي دفع المحادثة إلى ما بعد لوحات التحكم الخاصة بالبائعين نحو طريقة مفتوحة وموحدة لقياس ما يفعله الوكلاء فعليًا.
الفرق التي تنشر وكلاء دون جمع هذه البيانات تطير بشكل أعمى. السؤال ليس ما إذا كانت المراقبة مهمة. بل كم من الوقت يمكنهم تحمل تجاهلها.
أهم أخبار التقنية في 3 دقائق كل صباح
بريد إلكتروني واحد، كل يوم عمل، بما يهم فعلاً في الذكاء الاصطناعي والتقنية.