توسيع أداة الوكيل وإمكانية التحكم في النظام

الموقف الشائع هو تقييم نظام الوكيل. أول شيء تنظر إليه هو “عدد الأدوات التي يمكنها قبولها”.

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

المشكلة هي أن كونك قوياً لا يعني أن تكون قابلاً للسيطرة.

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

هناك العديد من الأدوات، والحل هو النطاق القابل للتشغيل؛ والحل الذي يمكن السيطرة عليه هو ما إذا كان من الممكن احتواء النتائج

حل “الأدوات القابلة للتعديل” هو أن الوكيل لم يعد يقدم اقتراحات فحسب، بل يمكنه التأثير بشكل مباشر على النظام الحقيقي.

هذه مسألة توسيع القدرات، وليست قضية وهمية.

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

• ماذا فعلت بالضبط هذه المرة؛
• قم بهذه الحركة بدلًا من خطوة أخرى أكثر أمانًا؛
• ما مدى اتساع التأثير إذا ارتكبت خطأً؟
• عندما يفشل في المنتصف، هل سيتوقف النظام، أو يعيد المحاولة، أو يترك نصف مجموعة من الآثار الجانبية؟
• في المرة القادمة التي يأتي فيها طلب مماثل، هل سيتخذ مسارًا مختلفًا تمامًا؟

بمعنى آخر، مع زيادة عدد الأدوات، يتحول التعقيد من “مشكلات صحة النص” إلى “مشكلات القدرة على التنبؤ بسلوك النظام”.

وهذان النوعان من المشاكل ليسا بنفس الحجم.

عادةً ما يكون النموذج الذي يمكنه الإجابة على الأسئلة فقط بمثابة ضجيج معرفي إذا ارتكب أخطاء؛ إذا تمكن الوكيل من ضبط أكثر من اثنتي عشرة أداة، فبمجرد عدم وجود قيود، إذا ارتكب أخطاء فسيكون بمثابة ضجيج عمل، وإذا ارتكب أخطاء فسيكون ضجيجًا للنظام.

غالبًا ما تكون الدولة هي ما يخرج عن نطاق السيطرة أولًا.

تقوم العديد من الفرق بإفساد العميل، ويكون رد الفعل الأول هو أن النموذج غير مستقر. في الواقع، هناك العديد من المشاكل تكمن خارج النموذج.

على سبيل المثال، عملية مشتركة:

• يقوم الوكيل أولاً بفحص نظام أمر العمل ويحصل على المهام المطلوب معالجتها؛
• ابحث في قاعدة المعرفة مرة أخرى للعثور على طرق التخلص التاريخية؛
• ثم اتصل باستعلام قاعدة البيانات؛
• إرسال رسالة أخرى إلى مجموعة الواجب؛
• إضافة سجل التصرف النهائي.

تعتبر كل خطوة من خطوات هذا الارتباط “معقولة”، ولكن طالما أن الحالة المتوسطة غير محددة بوضوح، فسيواجه النظام هذه المشكلات بسرعة:

• تم تغيير حالة أمر العمل إلى قيد المعالجة، ولكن لم يتم إرسال الإشعار؛
• تم تنفيذ استعلام قاعدة البيانات، ولكن لم يتم تسجيل النتائج في السجل النهائي؛
• تم إرسال الرسالة إلى المجموعة لكن الخطوات اللاحقة باءت بالفشل، ولكن العالم الخارجي ظن أن الأمر قد تم معالجته؛
• بعد اقتطاع نافذة السياق، ليس من المؤكد الإجراءات التي تم تنفيذها من قبل عند استمرار الجولة الثانية من التنفيذ.

هذه ** النظام يفتقر إلى آلية تقارب الحالة **.

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

يبدو هذا رائعًا في العرض التوضيحي، لكن من الصعب تنفيذه في الإنتاج.

حدود الأذونات غير واضحة، ويمكن للوكيل أن يتغير بسهولة من “القدرة على القيام بالأشياء” إلى “القيام بالكثير من الأشياء”

هناك سوء فهم شائع آخر وهو اعتبار الوصول إلى الأدوات بمثابة مخزون من القدرات.

قم بتوصيله بالمتصفح ومنحه إمكانية الوصول إلى أي خلفية؛ عند الاتصال بـ Shell، يمكن تشغيل معظم الأوامر افتراضيًا؛ عند الاتصال بنظام المراسلة، يمكنك إخطار أي مجموعة بشكل استباقي بشكل افتراضي؛ اتصل بقاعدة البيانات وامنح أذونات القراءة والكتابة المختلطة.

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

وهذا أمر خطير لأن خطر الوكيل هو أنه سيستدعي أداة ذات آثار جانبية عالية في سياق معقول محليًا ولكنه خاطئ عالميًا.

على سبيل المثال:

• كان يجب أن أتحقق من الحالة، ولكن بدلاً من ذلك قمت بتنفيذ البرنامج النصي للإصلاح؛
• كان من المفترض الرد على المستخدم الحالي فقط، ولكن تم إرسال الإشعار إلى المجموعة؛
• يجب أن يقرأ البيانات فقط، ولكن تم استدعاء واجهة التحديث؛
• يجب أن يستمر فقط بعد المراجعة البشرية، ولكن تم تغيير “الإجراء المقترح” مباشرة إلى “الإجراء المنفذ”.

ولذلك، فإن التركيز في تصميم حدود الإذن هو فصل الإجراءات ذات التأثير الجانبي العالي عن الاستدلال عالي عدم اليقين.

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

مع تنظيم المزيد من الأدوات، لم يعد الفشل مجرد “خطأ”، بل حالة شبه مكتملة.

وبطبيعة الحال، تفشل أنظمة البرمجيات العادية أيضًا، لكن فشل أنظمة الوكيل ينطوي على مشكلة إضافية: غالبًا ما يكون فشلًا نصف كامل عبر الأدوات والأنظمة والحدود الدلالية.

على سبيل المثال:

1. قم أولاً بإنشاء مهمة معالجة في Jira؛
2. انتقل إلى Slack لإرسال الإشعار؛
3. اضبط واجهة برمجة التطبيقات الداخلية لسحب السجل مرة أخرى؛
4. وأخيرًا، قم بكتابة الملخص مرة أخرى إلى قاعدة المعرفة.

ماذا يجب أن يفعل النظام إذا فشلت الخطوة الثالثة؟

• التراجع عن مهمة جيرا؟ -هل تريد حذف الإشعار الذي تم إرساله للتو؟
• تم الاحتفاظ بالمهمة ولكن تمت مقاطعة معالجة العلم؟
• السماح وكيل آخر يتولى؟

النهج الأكثر حظرًا هنا هو فهم “التعامل مع الفشل” على أنه سؤال النموذج مرة أخرى.

لأن العديد من حالات الفشل هي بالفعل آثار جانبية. ما هو مطلوب حقا هو:

• ما هي الخطوات التي يمكن إعادة تجربتها؟
• ما هي الخطوات التي يجب أن تكون عاجزة؟
• ما هي الخطوات التي لا يمكن الاستمرار فيها إلا بعد التأكيد اليدوي؟
• ما هي الإجراءات الخارجية التي يجب أن تترك أثراً للتدقيق؟
• بعد انقطاع الارتباط، أين سيتم إعادة الاتصال به في المرة القادمة التي يتم استعادته فيها؟

إذا لم يتم تعريفها، فسيبدو أن الوكيل يقوم بالتشغيل الآلي، ولكنه في الواقع يقوم بإنشاء عمل يدوي لاحق.

يكمن جوهر إمكانية التحكم في “هل ستتقارب؟”

أنا أميل أكثر فأكثر إلى اعتبار نظام الوكيل بمثابة نظام سير عمل يتمتع بقدرات تفكير منطقية، وليس بوابة شاملة يمكنها الدردشة.

وهذا يعني أنه عند تصميمه، فإن أول شيء يجب الإجابة عليه هو:

• ما إذا كانت المهمة قد بدأت بشكل واضح، أو قيد المعالجة، أو في انتظار التأكيد، أو مكتملة، أو في حالة الفشل؛
• ما هي الأدوات المسموح استدعاؤها في كل ولاية؛
• ما هي النتائج التي يمكن تقديمها مباشرة وما هي النتائج التي يجب مراجعتها؛
• بعد فقدان السياق، هل يمكن للنظام التعافي من الحالة الخارجية بدلاً من الاعتماد على استدعاء النموذج؛
• ما إذا كانت هناك سجلات مسؤولة للمدخلات والمخرجات والتنفيذ لكل إجراء.

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

معيار الحكم البسيط للغاية هو: **إذا قمت بتغيير النموذج مؤقتًا إلى مستوى أضعف، فسوف تنخفض كفاءة النظام فقط؛ إذا تمت إزالة جهاز الحالة وحدود الأذونات وآلية التراجع، فلن يتمكن النظام من الاتصال بالإنترنت على الفور. **

وهذا يدل على أن الأساس الحقيقي هو قدرة النظام على التقارب.

مثال مضاد شائع: معاملة الوكيل كمنسق عالمي

ستنمو العديد من المنصات الداخلية في النهاية لتصبح شيئًا مشابهًا جدًا لـ “منصة الذكاء الاصطناعي المتوسطة”:

• الاتصال بأي نظام.
• أريد قبول أي طلب؛
• حاول إكمال جميع الإجراءات تلقائيا؛
• اعتقدت أنه طالما أنني جعلت الكلمات السريعة أكثر تفصيلاً، فيمكنني قمع المخاطر.

أكبر مشكلة في هذا المسار هي أن تعقيده الهامشي ضعيف للغاية.

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

• التحقق من السجلات.
• الحكم على الشذوذ.
• اتخاذ قرار بشأن التراجع؛
• إرسال الإخطارات.
• تغيير الحالة.
• إنشاء مراجعة.
• تحديث قاعدة المعرفة.

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

في النهاية، ما يلتهم وقت الفريق حقًا هو في كثير من الأحيان:

• سيتم تنفيذ هذه الخطوة من تلقاء نفسها؛
• نفس المشكلة أخذت مسارات مختلفة اليوم وأمس؛
• تم تغيير النظام الخارجي ولكن السجلات الداخلية لم تواكبه.
• بعد الحادث يصعب استعادة ما اعتمد عليه العميل في ذلك الوقت.

ويهدف هذا إلى تسليم الكثير من الإجراءات عالية عدم اليقين إلى عملية تفكير تفتقر إلى الحدود. **

النهج الأكثر استقرارًا هو وضع الأتمتة في طبقات بدلاً من تكديس الأدوات بشكل مسطح.

إذا كنت تريد حقًا جعل نظام العميل قابلاً للتحكم، فإنني أوصي بتقسيمه وفقًا للمخاطر والآثار الجانبية:

1. طبقة منخفضة المخاطر: الاستعلام والملخص

أولاً، دع الوكيل يقوم بالقراءة والاسترجاع والتلخيص والصياغة.

حتى لو لم يكن الحكم على هذا النوع من الإجراءات مثاليًا، فإنه عادة لا يغير الحالة الخارجية بشكل مباشر، وهو أكثر ملاءمة لزيادة المبلغ أولاً.

2. طبقة المخاطر المتوسطة: إجراء من خطوة واحدة مع قيود

على سبيل المثال، يمكنك فقط تغيير حقل في حالة أمر عمل محددة، ويمكنك فقط الرد على الجلسة الحالية، ويمكنك فقط تنفيذ العمليات في القائمة المسموح بها الصريحة.

المفتاح هنا هو ضغط مساحة العمل لتكون ضيقة بما يكفي لجعل تكلفة الأخطاء مقبولة.

3. طبقة عالية المخاطر: الموافقة الصريحة وتنفيذ التراجع

عندما يتعلق الأمر بحذف البيانات، والعمليات المجمعة، والكتابة عبر الأنظمة، والإشعارات الصادرة، وتنفيذ البرنامج النصي لبيئة الإنتاج، يجب وضع آليات المراجعة البشرية والتدقيق والتراجع في المقدمة، بدلاً من تركها للمعالجة بعد ذلك.

يعرف الوكيل الناضج حقًا ما يجب القيام به تلقائيًا، وما يمكن اقتراحه فقط، وما لا ينبغي فعله بشكل مباشر أبدًا.

الحدود القابلة للتطبيق

تتناول هذه المقالة بشكل رئيسي:

• وكيل داخلي متصل بأدوات متعددة؛
• عامل قائم على العمليات وله آثار جانبية خارجية حقيقية؛
• سيناريوهات التنسيق التي تتضمن عمليات عبر الأنظمة مثل الرسائل وأوامر العمل وقواعد البيانات والبرامج النصية والمتصفحات وما إلى ذلك.

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

تنشأ المشكلة الحقيقية عندما يبدأ النظام في تغيير الحالة الخارجية مباشرة. في ذلك الوقت، كنا نواجه بالفعل تصميمًا مقيدًا على نمط النظام الموزع.

ملخص

يمكن للوكيل استدعاء المزيد من الأدوات، مما سيجعل النظام أكثر فائدة بالفعل.

لكن “أكثر فائدة” و"أكثر قابلية للتحكم" ليسا كلمتين في نفس الاتجاه.

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

وبخلاف ذلك، كلما زاد عدد الأدوات المرتبطة، أصبح النظام أشبه بمسؤول تنفيذي يتمتع بقدرات قوية ولكن من الصعب التنبؤ بها.