الوكيل الذكي يختلف عن chatbot لأنه لا يكتفي بإعطاء اقتراح؛ يمكنه أن يبحث، يكتب، يرسل، يعدّل، ويستدعي أنظمة أخرى. كل أداة جديدة تضيف فائدة، لكنها تضيف أيضاً سطح مخاطر جديد. لذلك يجب أن يبدأ تصميم الـAgent من نموذج الصلاحيات قبل نموذج الذكاء.
اكتب عقد صلاحيات قبل كتابة الـPrompt
حدد بوضوح: ما الأنظمة التي يستطيع الوكيل قراءتها؟ ما الحقول التي يراها؟ ما العمليات التي ينفذها؟ ما الحد المالي أو التجاري؟ وما الحالات التي تستوجب تصعيداً؟ هذا العقد يجب أن يكون مفهوماً لفريق التقنية وصاحب العملية معاً.
مثلاً وكيل المبيعات قد يقرأ بيانات lead، يقترح رسالة، ويحدد موعداً، لكنه لا يغيّر السعر أو يرسل عقداً ملزماً دون موافقة. كلما كانت الحدود صريحة، أصبح الاختبار أسهل.
استخدم مبدأ أقل صلاحية
لا تستخدم حساب مدير عام للربط لأن هذا «أسهل». أنشئ حساب خدمة محدوداً، وامنحه scopes دقيقة، وافصل بين بيئة الاختبار والإنتاج. وإذا كان الوكيل لا يحتاج حذف سجل فلا تمنحه صلاحية الحذف.
كل خطوة مهمة تحتاج Trace
سجل المدخل، القرار، الأداة المستدعاة، المعاملات، النتيجة، وهوية المستخدم أو العملية التي بدأت المهمة. الهدف ليس تخزين التفكير الداخلي للنموذج، بل الاحتفاظ بسجل تشغيلي يسمح بمعرفة ماذا حدث ولماذا من منظور النظام.
ضع حدوداً للوقت والميزانية
الوكلاء قد يدخلون في loops أو يستدعوا أدوات أكثر من المتوقع. ضع حد أقصى للخطوات، timeout، وميزانية tokens أو تكلفة لكل مهمة. إذا تجاوز الوكيل الحدود، يتوقف ويطلب تدخلاً بدلاً من الاستمرار بلا نهاية.
اختبر الفشل عمداً
قدّم للوكيل بيانات ناقصة، تعليمات متعارضة، ملفاً يحتوي prompt injection، أو API لا يستجيب. راقب هل يتوقف بأمان أم يخمن. اختبارات failure mode أكثر قيمة من عشرات العروض الناجحة لأنها تكشف ما سيحدث في الإنتاج.
التقييم يجب أن يكون متعدد الأبعاد
قِس دقة النتيجة، اكتمال المهمة، عدد الأدوات المستدعاة، التكلفة، الزمن، ونسبة التصعيد للبشر. أضف تقييمات أمنية منفصلة: هل تجاوز الصلاحيات؟ هل كشف بيانات غير لازمة؟ هل نفذ أمراً غير مصرح به؟
التوسع التدريجي أفضل من الاستقلال الكامل
ابدأ بوضع Copilot يقترح فقط، ثم انتقل إلى التنفيذ بعد موافقة، ثم اسمح بتنفيذ تلقائي للحالات منخفضة المخاطر. هذا السلم يبني ثقة حقيقية ويعطيك بيانات تساعدك على تحديد أين يستحق الاستقلال وأين لا يستحق.
افصل بين Agent Identity وUser Identity
يجب أن تعرف الأنظمة هل العملية نفذها مستخدم بشري أم وكيل نيابة عنه. لا تجعل كل الأفعال تظهر تحت حساب الموظف نفسه؛ استخدم هوية خدمة واضحة مع ربطها بالمستخدم الذي بدأ الطلب. هذا يسهل التحقيق في الأخطاء ويمنع الالتباس في سجلات الأنظمة.
في العمليات الحساسة، سجل أيضاً نسخة السياسة التي حكمت القرار. إذا تغيرت القواعد بعد أسبوع، تستطيع الرجوع لمعرفة لماذا سُمح بالفعل وقت التنفيذ.
ضع سياسة للتغييرات على الـTools
عندما تضيف API جديداً للوكيل، تعامل معه كتغيير إنتاجي حقيقي. راجع الصلاحيات، أضف اختبارات، وحدد failure cases قبل التفعيل. أخطر لحظة ليست دائماً تغيير النموذج؛ أحياناً تكون إضافة أداة تمنحه قدرة تنفيذية لم تكن موجودة.
استخدم قائمة allowlist للعمليات، ولا تسمح للوكيل بتكوين طلبات حرة نحو أي endpoint. كلما كانت واجهات الأدوات ضيقة ومحددة، قل احتمال السلوك غير المتوقع.
كوّن لجنة تشغيل صغيرة لا لجنة بيروقراطية
الحوكمة لا تحتاج اجتماعاً شهرياً ضخماً. يكفي مالك العملية، ممثل تقني، ومسؤول بيانات أو أمن للحالات المهمة. يجتمعون حول مؤشرات واضحة: الأخطاء، حالات التصعيد، التغييرات المقترحة، والحوادث. الهدف سرعة تعلم آمنة، لا تعطيل التطوير.
بهذا الشكل يصبح الوكيل منتجاً تشغيلياً له مالك وحدود ومقاييس، وليس تجربة ذكية تعمل في الظل بلا مسؤولية واضحة.
حوّل الفكرة لمسار عمل قابل للقياس
لو عندك تحدٍ مشابه داخل شركتك، اكتب العملية الحالية والنتيجة التي تريد الوصول لها، ونستخدمها كنقطة بداية لتشخيص عملي.
ناقش الحالة مع فريق ميكا
