ملاحظات من بناء أنظمة الوكلاء
أدوات التقييم، وأنماط التنسيق، وتصميم الذاكرة، والإخفاقات التي تقف خلفها — موثّقة بينما التفاصيل لا تزال حاضرة.

التسوية مقابل التصريح: ما تكشفه التداولات الوكيلية عن حدود الأفعال
الوكلاء الذين يُمنحون نقدًا للتداول غالبًا ما يشترون ويبيعون بشكل متكرر: الفشل ليس في الاستراتيجية بل في غياب حد التسوية بين النية والمركز المسجل.

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

سجلات الخروج: تسجيل إلى أين ذهب الوكيل، لا ما أرسله فقط
فحص المحتوى يرى الحمولات، لا الوجهات. سجل الخروج يوثّق إلى أين ذهب الوكيل، وبأي ترتيب، ومدى novelty كل قفزة.

حوادث الوكيل مشكلة قياس عن بُعد قبل أن تكون مشكلة سياسات
تقارير الوكلاء المارقين تصف إخفاقات في التحكم لم تكن مرئية إلا بعد وقوعها. الإصلاح الأول هو سجل دائم للنية والخروج والقرار.

OpenShell يعالج العَرَض: أمان الوكيل يحتاج إلى عقود، لا مفاتيح إيقاف
قد يُوقف الاحتواء وقت التشغيل وكيلاً مسيئًا، لكن دون عقد مُعلن مسبقًا للإجراءات المسموح بها، فهو مجرد تحديد للضرر، لا منع له.

الاحتواء ليس سطح تحكم: قراءة Nvidia OpenShell ضد التيار
الحاويات العازلة تمنع الهروب؛ لكنها لا تحدد ما كان الوكيل مخولاً بمحاولته. سلامة الوكيل تحتاج طبقة صلاحيات فوق بيئة التشغيل، لا مفتاح إيقاف أسرع.

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

ميزانيات الخروج للوكيل: المعدل ليس هو المدى
حدود المعدل تقيّد سرعة تصرف الوكيل، لا إلى أين يتجه. يجب أن يكون التحكم في الخروج ميزانية للوجهات والقدرات، تُفرض عند الوسيط وتُسوّى بعد كل تشغيل.

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