وكيل المتصفح يمكنه القراءة والنقر والكتابة والتنزيل وربما تشغيل أدوات داخلية. هذه القوة مفيدة فقط إذا كانت لها حدود. الـGuardrails ليست جملة في Prompt تقول «كن حذرًا»؛ هي قيود تقنية في طبقة الأدوات والسياسات والسجل تجعل بعض الأفعال مستحيلة أو مشروطة حتى لو أخطأ النموذج في التقدير.
ابدأ بأقل صلاحية ممكنة
امنح الوكيل الأدوات التي يحتاجها للمهمة الحالية فقط. لو المهمة بحثية، لا يحتاج أدوات حذف أو إرسال. ولو يحتاج ملء نموذج، لا يلزم أن يملك صلاحية إدارة كل Profiles. تقليل سطح الأدوات يقلل أخطاء الاختيار ويجعل السلوك أسهل في المراجعة.
افصل القرار عن التنفيذ الحساس
في العمليات الحساسة اجعل الوكيل يقترح ثم يطلب موافقة أو يمر عبر Policy. مثال: يمكنه تجهيز رسالة بريد لكن الإرسال يحتاج Approval، أو يحدد ملفات للحذف لكن Tool الحذف لا تنفذ قبل تأكيد صريح. هذا الفصل يمنع تحويل خطأ في الاستنتاج إلى أثر فوري.
خطوات عملية
- صنف الأفعال إلى آمنة وقابلة للتراجع وحساسة.
- اسمح بالآمنة تلقائيًا ضمن حدود.
- ضع Gate قبل الأفعال الحساسة.
- اعرض ملخصًا واضحًا لما سيحدث.
- سجل من وافق ومتى.
ضع حدودًا للوقت والتكرار والحجم
الـAgent قد يدخل في Loop أو يكرر محاولة فاشلة بطريقة مكلفة. حدد أقصى عدد Tool calls، Timeout للمهمة، حد Retry لكل خطوة، وحجم أقصى للبيانات التي يمكن قراءتها أو تنزيلها. عند تجاوز الحد تتحول المهمة إلى Failed أو Manual Review بدل الاستمرار بلا نهاية.
قائمة مراجعة
- Max tool calls محدد.
- Retry محدود مع Backoff.
- Timeout للمهمة والخطوة.
- حد للتنزيل والرفع.
- حلقة التكرار تُكتشف من نفس الفعل والمدخلات.
اجعل السجل قابلًا للفهم بعد وقوع المشكلة
Audit log مفيد فقط إذا كان يوضح القرار والأداة والمدخلات المختصرة والنتيجة. لا تحتاج تخزين Chain of Thought؛ تحتاج أثرًا تشغيليًا: لماذا اختيرت Tool حسب الخطة الظاهرة، ماذا نُفذ، وماذا أعادت. هذا يسمح بتحليل الفشل بدون كشف أسرار أو الاعتماد على ذاكرة الجلسة.
سيناريو تطبيقي قبل الاعتماد
لنفترض أن فريقًا يدير عددًا متزايدًا من البروفايلات ويحتاج أن يثبت أن التنظيم والعزل سيظلان واضحين عند التوسع. في موضوع «Guardrails عملية لوكلاء الذكاء الاصطناعي داخل المتصفح»، نفّذ تجربة صغيرة قبل تعميم القرار. ابدأ بـ1- صنف الأفعال إلى آمنة وقابلة للتراجع وحساسة.، 2- اسمح بالآمنة تلقائيًا ضمن حدود.، 3- ضع Gate قبل الأفعال الحساسة.، ثم سجل النتيجة قبل توسيع النطاق. لا تحاول تحسين كل شيء في أول Run؛ المطلوب أولًا إنشاء حالة مرجعية تستطيع العودة إليها ومقارنتها. عندما تنجح التجربة، كررها مرة ثانية بنفس الشروط للتأكد أن النتيجة لم تكن صدفة أو أثر Cache أو حالة مؤقتة.
كيف تقيس نجاح التجربة؟
القياس هنا لا يكون بعدد الأزرار أو البروفايلات التي تم إنشاؤها، بل بمدى ثبات الحالة، سرعة العثور على العنصر الصحيح، وانخفاض أخطاء الخلط أو إعادة العمل. حوّل النقاط الموجودة في المقال إلى مؤشرات قابلة للرصد: Tool غير المتاحة لا يمكن للنموذج إساءة استخدامها.؛ تقسيم الصلاحيات حسب المهمة أفضل من Role واسع ثابت.؛ صلاحية القراءة منفصلة عن صلاحية التغيير.. احتفظ بالقياسات مع timestamp ونسخة التطبيق أو البيئة، لأن مقارنة أرقام من إصدارات أو شروط مختلفة قد تعطي استنتاجًا خاطئًا. وإذا كانت النتيجة رقمية، استخدم أكثر من عينة بدل أفضل أو أسوأ قيمة منفردة.
عند الفشل: ماذا تراجع أولًا؟
إذا ظهرت نتيجة غير متوقعة، ارجع أولًا إلى حدود البروفايل نفسه: التخزين، الملكية، الشبكة، الإضافات، والسجل. تغيير أكثر من طبقة في نفس الوقت يجعل سبب المشكلة مستحيلًا تقريبًا. عند التحقيق استخدم هذه القائمة كحد أدنى: Max tool calls محدد.؛ Retry محدود مع Backoff.؛ Timeout للمهمة والخطوة.؛ حد للتنزيل والرفع.. سجل ما الذي جربته وما الذي لم يتغير بعد التجربة. هذه المعلومة تمنع الفريق من إعادة نفس المحاولات وتساعد على تحديد ما إذا كان الخطأ في الإعداد أو الأداة أو الشبكة أو بيانات المهمة.
متى تعتمد القرار على نطاق أوسع؟
قرار الاعتماد لا يجب أن يعتمد على أن التجربة «عملت مرة». في «Guardrails عملية لوكلاء الذكاء الاصطناعي داخل المتصفح» اعتبر الحل جاهزًا عندما تستطيع إعادة نفس السيناريو بنتيجة متقاربة، ويفهم شخص آخر خطوات الاختبار وحدود النتيجة، وتعرف ماذا ستفعل لو فشلت الحالة الطبيعية. لو لم تتحقق هذه الشروط، احتفظ بالحل كتجربة أو إعداد مبدئي ولا تحوله إلى Default لكل الحسابات أو المهام.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…