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