ملاحظات من بناء أنظمة الوكلاء
أدوات التقييم، وأنماط التنسيق، وتصميم الذاكرة، والإخفاقات التي تقف خلفها — موثّقة بينما التفاصيل لا تزال حاضرة.
سجلات الخروج: تسجيل إلى أين ذهب الوكيل، لا ما أرسله فقط
فحص المحتوى يرى الحمولات، لا الوجهات. سجل الخروج يوثّق إلى أين ذهب الوكيل، وبأي ترتيب، ومدى novelty كل قفزة.
التنفيذ المتين ليس استدلالاً متيناً: تخزين حالة الوكيل دون فقدان القصد
حفظ مؤشر خطوة الوكيل ليس حفظاً لحالة مهمته. الأنظمة التي تخزّن نقطة استئناف التنفيذ دون القصد تستأنف في مسارات طليقة وغير متماسكة.
القاضي مكوّن: إدارة إصدارات خطوط LLM-as-Judge كأي تبعية أخرى
لا يكون LLM-as-judge موثوقًا إلا عندما يُثبَّت نموذج القاضي والـ prompt والـ rubric ومعاملات فك الترميز وتُختبر انحدارًا كأثر من الدرجة الأولى.
تقييمات الوكيل هي إعادة تشغيل الحوادث: بناء مجموعة انحدار من آثار الإنتاج
يجب تنمية مجموعات تقييم الوكيل من المسارات الإنتاجية الملتقطة وإعادات تشغيل الحوادث، لا من مهام متخيلة، لأن الإخفاقات المهمة تُكتشف ولا تُصمم.
التنفيذ المتين هو متطلب البنية التحتية الحقيقي للوكلاء طويلة التشغيل
التمويل وتحولات المنتجات حول التنفيذ المتين تشير إلى المشكلة الصعبة الفعلية في بنية الوكلاء التحتية: إعادة التشغيل الحتمية والآثار المتكافئة لعمليات تمتد ساعات وتتضمن آثارًا جانبية خارجية.
وكلاء البرمجة يسرّبون عبر المستودعات، لا عبر الأوامر النصية
كشف 13,000 صورة داخلية عبر وكلاء البرمجة هو فشل في نظافة المستودع ونطاق الوكيل: الوكلاء يرثون كامل تاريخ نسخة العمل وسطح الأسرار، لذا وحدة الاحتواء هي حدود المستودع، لا التعليمات.
حوادث الوكيل مشكلة قياس عن بُعد قبل أن تكون مشكلة سياسات
تقارير الوكلاء المارقين تصف إخفاقات في التحكم لم تكن مرئية إلا بعد وقوعها. الإصلاح الأول هو سجل دائم للنية والخروج والقرار.
وكلاء التسوق يحتاجون إلى طبقة تسوية، لا طبقة خصومات
التجارة القائمة على الوكلاء تصل عبر التداول، وإتمام الشراء، وواجهات برمجة التطبيقات المقاسة. القطعة المفقودة هي طبقة تسوية ونزاعات تسجل أي وكيل تصرف، وبأي تفويض، ومن يتحمل الخسارة.
الدفع ليس استدعاء أداة: لماذا تُخلّ وكلاء المتصفح بترخيص التجارة
يمكن لوكلاء المتصفح تشغيل مسارات الدفع، لكن الشراء حدث موافقة. يطرح هذا المقال اعتمادات إنفاق محدودة النطاق وعقد دفع موجّه للوكلاء.