ضوابط وكلاء الذكاء الاصطناعي: بوابات الموافقة والتحكم في نطاق التأثير

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

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

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

صنّف الإجراءات حسب مدى الضرر الذي يمكن أن تسببه

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

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

كن صادقاً بشأن الحالات المتوسطة. طلب POST الذي ينشئ مسودة قابل للعكس. طلب POST الذي ينشئ مسودة ويرسلها عبر البريد الإلكتروني ليس كذلك. يمكن أن تقع مكالمتان تبدوان متشابهتين في شيفرتك على جانبي الخط. صنّف حسب النتائج، وليس حسب فعل HTTP.

أدخل عنصراً بشرياً في حلقة الإجراءات المدمرة

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

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

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

امنح الوكيل وضع التشغيل التجريبي

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

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

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

حدد نطاق الانفجار

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

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

هذه الحدود هي أيضاً شبكة الأمان الخاصة بك عندما يفشل حاجز واقٍ أكثر دقة. الوكيل الذي يتجاوز البوابة لا يزال لا يستطيع تجاوز نطاقه. لمعرفة ما إذا كان الحد الأقصى يعمل، عليك مراقبته، لذا تتبع الأعداد التي تغذي كل حد، والمكالمات لكل إجراء، والإنفاق لكل مهمة، ومعدلات الأخطاء بالقرب من السقف، بالطريقة التي كنت ستفعل بها مع مراقبة API على أي خدمة إنتاج. OWASP تسمي الخطر الأساسي مباشرة. "الوكالة المفرطة" تقع ضمن قائمة OWASP Top 10 لتطبيقات نماذج اللغة الكبيرة، وكل حد هنا هو وسيلة لمنح أقل منها.

كيف تختبر الحاجز الواقي

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

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

تبدو الحلقة كالتالي:

1. قم بمحاكاة نقطة النهاية المدمرة. أنشئ محاكاة لواجهة برمجة تطبيقات الإرسال أو الحذف أو الدفع بحيث لا يتم لمس الواجهة الحقيقية أبداً. تسجل المحاكاة ما تستقبله وتعيد أي استجابة تخبرها بها.
2. شغّل الوكيل على الإجراء الخطير. قم بتوجيهه عبر السيناريو الذي يجب أن يشغل الحاجز الواقي: تذكرة التصعيد، طلب الحذف، الطلب ذو القيمة العالية.
3. تحقق من المسار، وليس النتيجة. تأكد من أن محاكاة نقطة النهاية المباشرة لم تتلق أي مكالمات وأن طلب الموافقة قد تم تشغيله بدلاً من ذلك، مع الحمولة الصحيحة. شرط النجاح هو "الوكيل طلب" بدلاً من "الوكيل أرسل".
4. اختبر الاتجاه الآخر أيضاً. قم بتشغيل إجراء آمن وتأكد من أنه مر مباشرة دون موافقة لا داعي لها. البوابة التي تمنع كل شيء معطلة مثل تلك التي لا تمنع شيئاً.

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

أين يتناسب Apidog (وأين لا يتناسب)

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

ما يمتلكه Apidog هو طبقة API التي تحميها تلك الحواجز الواقية، وهو المكان الذي يحدث فيه الاختبار. يمكنك محاكاة نقاط النهاية ذات التأثير الجانبي (الإرسال، الحذف، الشحن) بحيث يمكن لوكيلك إجراء تدريب على إجراء خطير دون أي عواقب حقيقية. تقوم ببرمجة تلك المحاكاة لإرجاع الاستجابات التي ستقدمها خدمة مباشرة، بما في ذلك الإخفاقات. وتتحقق مما أرسله الوكيل: أن المكالمة المباشرة لم تحمل أي حركة مرور، وأن طلب الموافقة قد خرج، وأن الحمولة متطابقة. هذا هو التوافق الصادق. يختبر Apidog واجهات برمجة التطبيقات التي يستدعيها وكيلك ويحاكي تلك المدمرة حتى تتمكن من إثبات أن الوكيل يسلك مسار الموافقة.

أسئلة مكررة

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

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

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

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

ابدأ بالإجراء الأكثر تدميراً لديك

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

قم بتنزيل Apidog لمحاكاة نقاط النهاية المدمرة، وبرمجة الاستجابات، والتأكد من أن وكيلك يسلك مسار الموافقة بدلاً من المسار المباشر.