ملاحظات من بناء أنظمة الوكلاء
أدوات التقييم، وأنماط التنسيق، وتصميم الذاكرة، والإخفاقات التي تقف خلفها — موثّقة بينما التفاصيل لا تزال حاضرة.
من يدقق المدقق: أطر المسؤولية تفترض أثراً ورقياً لا تتركه الوكلاء
أنظمة المسؤولية تفترض سجل قرارات قابلًا للنسب. معماريات الوكلاء الحالية تنتج مسارات لا يمكن إعادة بنائها إلى خطوة واحدة مسؤولة.
OpenShell يعالج العَرَض: أمان الوكيل يحتاج إلى عقود، لا مفاتيح إيقاف
قد يُوقف الاحتواء وقت التشغيل وكيلاً مسيئًا، لكن دون عقد مُعلن مسبقًا للإجراءات المسموح بها، فهو مجرد تحديد للضرر، لا منع له.
ما الذي ينكسر فعلاً عند توسيع سرب وكلاء LLM
تفشل الأنظمة متعددة الوكلاء بسبب آليات التنسيق أكثر مما تفشل بسبب قدرة النموذج. نظرة على الحالة المشتركة وبروتوكولات التسليم ومقايضات التوازي.
وكلاء المتصفح عند الدفع: الموافقة تحتاج إلى سجل، لا تحديث للشروط
فتح الدفع أمام وكلاء المتصفح يحوّل الموافقة إلى عقد تفاوض عليه الآلة. بدون سجل موافقة دائم، لا يوثّق أي أثر ما وافق عليه الوكيل.
قياس التفكيك: لماذا تُعد تكلفة مسار الوكيل مقياسًا للمخطِّط
يُبلَّغ عن تكلفة التشغيل كإجمالي tokens، لكن المتغير المهيمن هو كيفية تفكيك المخطِّط للمهمة. محاسبة عُقد الخطة تحوّل وضع الميزانية إلى مُدخل جدولة.
الاحتواء حدٌّ لا ميزانية: لماذا يحتاج خروج الوكيل إلى نموذج تكلفة
تقيّد بيئات العزل المكان الذي يعمل فيه الوكيل، لا مدى وصوله. اقرن الاحتواء بميزانية خروج لكل تشغيل تقيس الوجهات وحجم الحمولة.
الاحتواء ليس سطح تحكم: قراءة Nvidia OpenShell ضد التيار
الحاويات العازلة تمنع الهروب؛ لكنها لا تحدد ما كان الوكيل مخولاً بمحاولته. سلامة الوكيل تحتاج طبقة صلاحيات فوق بيئة التشغيل، لا مفتاح إيقاف أسرع.
الهوية بلا مهمة: لماذا تظل بيانات الاعتماد لكل وكيل تمنح صلاحيات مفرطة
بيانات الاعتماد المحدودة بالمهمة تُصلح عمر الرمز المميز، لا نطاقه. النطاق ناتج عن كيفية تفكيك المخطط للعمل، مما يجعل التفكيك ضابطًا أمنيًا.
أسطح الأدوات مشكلة تصميم واجهات، لا مشكلة غلاف
غالبًا ما يبدأ سوء استخدام الوكيل للأدوات من الواجهة: واجهات برمجة بشرية ملفوفة بـ JSON تخفي الفشل الجزئي وتفتقر إلى دلالات الأخطاء النهائية. تصميم أسطح موجهة للآلة يعالج ذلك.