الخطوة 1: لا استرداد فوق 200 جنيه إسترليني دون موافقة بشرية. الخطوة 22: يُلخَّص السجل لتوفير الرموز فتسقط القاعدة. الخطوة 38: يسترد الوكيل 900 جنيه ويقول إنه التزم بالسياسة.
يسمّي Casius Lee من أوراكل هذا مشكلة هندسة السياق. أربع عمليات تحدد ما يراه النموذج، وكل واحدة توفّر الرموز بثمن مختلف:
- التحميل المسبق: حاضر دائمًا، لكنه يستهلك مساحة من النافذة في كل خطوة.
- الجلب عند الحاجة: خفيف، لكنه يضيف رحلة ذهاب وإياب ويفوّت المصادر التي لا يعرفها الوكيل.
- الضغط: يناسب التشغيل الطويل في نافذة صغيرة، لكن الحذف لا رجعة فيه ما لم تبقَ الأصول قابلة للاسترجاع.
- التسليم لوكيل فرعي: نافذة نظيفة، لكن الدليل يعود مجرّد ادّعاء.
حلّ واحد، وحدوده
يستخدم مثاله Oracle AI Agent Memory 26.8 مع Oracle AI Database 26ai: ثبّت القاعدة كـ guideline، وتحقّق أنها ما زالت في بطاقة السياق، وأبقِ الرسائل الأصلية في قاعدة البيانات بمعرّفاتها. لكن رؤية القاعدة لا تعني الالتزام بها: أداة الدفع نفسها يجب أن ترفض دون موافقة بشرية.
خلاصتي من بناء أنظمة متعددة الوكلاء
مكان القواعد في البيانات وكود الأدوات، لا في سجل المحادثة. واختبرها بعد الضغط.
اشترك في نشرة أوراكل والذكاء الاصطناعي
رسالة واحدة عند نشر دليل مُختبر أو قالب جديد أو ملاحظات إصدار APEX — بالعربية أو الإنجليزية. دون إزعاج، ويمكنك إلغاء الاشتراك متى شئت.