وكيلي استدعى واجهة برمجية فاشلة خمس مرات—والمشكلة لم تكن في الكود

ظهر عطل في الإنتاج. كان وكيلي يكرر نفس استدعاء الواجهة البرمجية خمس مرات متتالية. فتحت الكود أولاً—تلك العادة القديمة المتجذرة. منطق إعادة المحاولة سليم. تدفق الدوال طبيعي. ولا رسالة خطأ واحدة في السجلات.

الكود لم يملك إجابة. لم تتضح لي الصورة إلا حين فتحت السجل التتبعي.

كود الوكيل وعاء فارغ

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

فرق تشغّل وكلاء مبنية على LangGraph تردد العبارة ذاتها باستمرار: “لا يمكنك الحكم على جودة الوكيل من خلال مراجعة الكود.”

• نفس الكود، نفس المدخلات، وأنماط استدعاء أدوات مختلفة في كل مرة
• خلافاً لدالة كـ handleSubmit()، منطق التفرع غير موجود أصلاً في الكود
• اختبار GPT-5.2 بالاستعلام ذاته عشر مرات يعطي ثباتاً في ترتيب استدعاء الأدوات بنسبة 40% تقريباً
• تقع الأخطاء دون أي خلل في الكود، مما يجعل إعادة إنتاجها أمراً مستحيلاً

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

السجلات التتبعية هي الكود المصدري الجديد

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

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

• مقارنة السجلات قبل وبعد تعديل المحث تكشف فوراً الفرق في جودة الاستدلال
• في LangSmith، تحميل سجل من نقطة بعينها إلى بيئة التجربة يعمل كنقطة توقف برمجية
• سجل واحد يمكنه أن يكشف لك اللحظة بالضبط التي انحرف فيها استدلال الوكيل—وهو ما لا يستطيع أي قدر من السجلات النصية أن يحققه

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

الاختبار يتغير من جذوره

في البرمجيات التقليدية، تختبر قبل النشر وتنتهي من الأمر. الوكلاء غير حتميين، لذا يجب أن تواصل التقييم في بيئة الإنتاج.

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

الفرق التي تبنّت التقييم المبني على السجلات التتبعية شهدت تحسناً ملموساً في معدلات نجاح المهام. النمط ثابت: السجلات تكشف أنماط الفشل التي لا يستطيع أي مجموعة اختبارات قبل النشر أن تتنبأ بها.

• ابنِ خط أنابيب تقييم آلي يأخذ عينات من سجلات الإنتاج أسبوعياً
• الاختبار قبل النشر وحده لا يضمن الجودة في الأنظمة غير الحتمية
• المراقبة بدون سجلات تتبعية كالاكتفاء بالتحقق من أن الخادم يعمل
• يمكن للوكيل أن “يعمل بصورة طبيعية” بينما ينفذ مهاماً خاطئة تماماً—السجلات التتبعية وحدها تكشف هذا

التعاون وتحليلات المنتج تحدث أيضاً على السجلات

مراجعة الكود تحدث على GitHub. وأين تحدث مراجعة حكم الوكيل؟

منصات الرصد والمراقبة تتولى هذا الدور. الفرق تعلّق على السجلات التتبعية، وتتشارك نقاط قرار بعينها، وتراجع استدلال الوكيل بالطريقة ذاتها التي كانت تراجع بها طلبات السحب. نموذج التعاون نفسه يتحول.

تحليلات المنتج تسير على النهج ذاته. حين يقول مقياس ما إن “30% من المستخدمين غير راضين”، لا يمكنك إيجاد السبب دون فتح السجلات التتبعية. قد يُتمّ الوكيل المهام بنجاح وفق مقاييسه الخاصة، بينما يفوته تماماً ما أراده المستخدم فعلاً.

• أدوات تحليلات المنتج كـ Mixpanel وأدوات التشخيص تتقارب نحو السجلات التتبعية كركيزة مشتركة
• تحليل أنماط استدعاء أدوات الوكيل يمكنه استخلاص الميزات التي يحتاجها المستخدمون فعلاً

خلاصة القول

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

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