تصميم وكلاء يفشلون بأمان

رسم ثلاثي الأبعاد لنظام رقمي محصور داخل شبكة مترابطة — تصميم وكلاء ذكاء اصطناعي يفشلون بأمان

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

لماذا ينجح العرض التوضيحي ويفشل الإنتاج؟

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

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

ابدأ من الصلاحيات، لا من التوجيهات

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

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

يجب ألّا يقدر الوكيل على فعل شيء لم يسمح به نموذج صلاحياتك أصلًا — بغضّ النظر عمّا يقوله التوجيه.

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

صمّم لنطاق الأثر: ضع البشر عند الحواف الخطرة

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

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

بهذا التصنيف تحصل على وكيل سريع في 90% من عمله، وحذر في الـ10% التي تستحق الحذر. والأهم: حين يخطئ النموذج في تقدير خطورة إجراء، تكون الشبكة الأمنية في طبقة التصنيف نفسها، لا في حسن نية النموذج.

اجعل كل قرار قابلًا للتتبّع

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

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

اجعل التراجع خطة أولى، لا خطة طوارئ

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

قيّم قبل الإطلاق، وراقب بعده

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

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

قائمة تحقق قبل إطلاق أي وكيل

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

الخلاصة

الوكيل الجدير بالثقة ليس الوكيل الذي لا يخطئ، بل الوكيل الذي حين يخطئ يكون خطؤه محصورًا بالصلاحيات، مرئيًا في السجلات، وقابلًا للتراجع بالتصميم. هذه ليست قيودًا على قدرة الوكيل — بل هي بالضبط ما يسمح لك بتوسيع صلاحياته لاحقًا بثقة، خطوة بعد خطوة.

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