عندما يحمل وكيل الذكاء الاصطناعي بيانات اعتماده الخاصة ويتصل مباشرة بالخدمات الخارجية، فإنه يتصرف كمتعاقد يمتلك بطاقة ائتمان للشركة دون وجود مشرف، بدلاً من كونه برنامجاً مخصصاً للموظفين. لا يمكنك رؤية ما لمسه، أو من وافق على الوصول، أو لماذا كلفت محادثة واحدة عشرة أضعاف تكلفة محادثة أخرى. تتشتت السجلات عبر عشرات الخدمات، وتتضاعف التساؤلات.
أي أداة استدعى الوكيل فعلياً؟ من منحه الإذن للوصول إلى تلك القاعدة البيانات؟ لماذا استهلكت عملية التشغيل يوم الثلاثاء أربعين ألف توكن بينما استخدمت عملية يوم الاثنين خمسة فقط؟ كم أنفقنا حقاً؟
بدون وجود طبقة تحكم مركزية تقع بين المستخدمين والنماذج والخدمات، ستظل هذه التساؤلات دون إجابة. أنت بحاجة إلى مستوى تحكم موحد يسجل كل اتصال لمرة واحدة، ولا يكشف إلا عن المجموعة الضيقة من الوظائف التي يحتاجها الوكيل حقاً، ويسجل كل عملية تنفيذ بالكامل. يستعرض هذا المقال مختبراً متقدماً يستخدم deco Studio كطبقة تحكم محلية. ستقوم بإعداده، وتوصيل خادم Model Context Protocol آمن، وكشف وظيفة واحدة مسموح بها فقط، ومراقبة ما يحدث عندما يحاول الوكيل تجاوز حدوده.
مشكلة بيانات الاعتماد المشتتة
تخيل إعداد فريق عمل نموذجي. يقوم أحد المطورين بربط وكيل بواجهة برمجة تطبيقات (API) للبحث باستخدام مفتاح شخصي. ويقوم مطور آخر بربط الوكيل نفسه بقاعدة بيانات الإنتاج لأن العرض التجريبي بدا غير ضار. ويضيف ثالث أداة للبحث عن الفواتير حتى يتمكن الوكيل من "المساعدة في الفواتير". كل اتصال من هذه الاتصالات غير مرئي للآخرين. أصبح لدى الوكيل الآن وصول مباشر إلى البحث، وبيانات الإنتاج، والسجلات المالية، ولكن ليس لدى الفريق قائمة موحدة بما هو قيد التشغيل الفعلي.
عندما تعيش بيانات الاعتماد داخل الوكيل، تنهار الحوكمة. لا يمكنك إلغاء الوصول مركزياً لأن المفتاح موجود في ذاكرة الوكيل أو في ملف البيئة المحلية الخاص به. لا يمكنك تدقيق الاستخدام لأن الخدمة الخارجية لا ترى سوى استدعاء API من عميل آلي مجهول. تظهر مفاجآت التكلفة بعد أيام في فاتورة السحابة، وبحلول ذلك الوقت، لا يتذكر أحد أي أمر (prompt) تسبب في هذا الارتفاع المفاجئ.
بناء طبقة التحكم الخاصة بك في deco Studio
يقوم deco Studio بحل هذه المشكلة من خلال العمل كمركز محلي. يمكنك تشغيله على جهازك الخاص، ليصبح المكان الوحيد الذي توجد فيه الإعدادات. بدلاً من تشتيت مفاتيح API وتعاريف الأدوات عبر الوكلاء، تقوم بتسجيل الاتصال مرة واحدة داخل Studio. ثم تقرر بالضبط الوظائف التي يمكن لكل وكيل رؤيتها.
فكر في الأمر كتركيب لوحة تحويل هاتفية؛ حيث تمتد جميع الأسلاك إلى غرفة واحدة، وأنت تختار أي الخطوط تتصل بأي أقسام، وتحتفظ بسجل لكل مكالمة.
ابدأ بتشغيل deco Studio محلياً. وبمجرد تشغيله، ستقوم بمركزية الإعدادات. يجب على كل وكيل يريد استخدام أداة ما أن يطلب ذلك من طبقة التحكم، وليس من الخدمة الخارجية مباشرة. يؤدي هذا فوراً إلى إنشاء نقطة تفتيش حيث يمكنك المراقبة والتصفية والتسجيل.
توصيل خادم MCP آمن
في هذا المختبر، ستقوم بتوصيل خادم Model Context Protocol. يعد MCP معياراً مفتوحاً للسماح للنماذج بالتفاعل مع الأدوات الخارجية، لكن المعايير لا تضمن السلامة. الخطوة الحاسمة هنا هي الانتقائية؛ فأنت لا تكشف بشكل أعمى عن كل نقطة نهاية (endpoint) يوفرها الخادم. بدلاً من ذلك، تقوم بتسجيل الخادم في deco Studio، ثم تكشف عن وظيفة واحدة مسموح بها فقط لوكيل الاختبار الخاص بك.
على سبيل المثال، قد يوفر خادم MCP الخاص بك عشر وظائف: قراءة ملف، كتابة ملف، استعلام قاعدة بيانات، جلب بيانات من الشبكة، وغيرها. تختار عملية واحدة غير ضارة، ربما آلة حاسبة في بيئة معزولة (sandboxed) أو عملية بحث للقراءة فقط مقابل بيانات اصطناعية، وتكشف عن تلك العملية وحدها. تصبح الوظائف التسع الأخرى غير مرئية للوكيل، وإذا طلبها الوكيل، فسترد طبقة التحكم بالرفض القاطع.
هذا هو تطبيق "مبدأ الحد الأدنى من الصلاحيات" بشكل آلي. لا يتلقى الوكيل القدرة من خلال تعليمات مهذبة، بل من خلال حدود برمجية.
اختبار الحدود
قم بإنشاء وكيل اختبار ووجهه نحو طبقة تحكم deco Studio الخاصة بك. أعطه مهمة تتطلب الوظيفة الوحيدة المسموح بها. راقبه وهو ينجح. ستظهر السجلات داخل Studio طلب النموذج، وتوجيه استدعاء الأداة عبر طبقة التحكم، وتنفيذ الوظيفة، وتدفق النتيجة مرة أخرى إلى النموذج. يمكنك قراءة المسار بأكمله في تتبع واحد مستمر.
الآن امنح الوكيل مهمة ثانية تتطلب وظيفة استبعدتها عمدًا. قد يحاول الوكيل إيجاد طريقة منطقية للالتفاف على القيد، أو قد يهلوس بوجود الأداة. وفي كلتا الحالتين، ستصل الاستدعاء إلى مستوى التحكم (control plane)، حيث ترفضه القائمة المسموح بها (allowlist)، وتفشل عملية التنفيذ. هذا الفشل هو دليلك على أن الحدود مفروضة برمجياً وليست مجرد نظرية.
افعل ذلك باستخدام مهام اصطناعية أولاً. ابنِ قاعدة بيانات وهمية مليئة بملفات تعريف المستخدمين التي تم إنشاؤها. اترك الوكيل يستعلم منها. تحقق من القائمة المسموح بها ومن عمليات الرفض. فقط بعد أن تثق في هذه الحدود، يجب أن تفكر حتى في توجيه الوكيل نحو أنظمة الإنتاج. إن الاندفاع نحو البيانات الحقيقية قبل التحقق من "الجدار" هو الطريقة التي تتسرب بها الأسرار.
قراءة المسار الكامل لعملية التشغيل
يتيح لك deco Studio فحص كل طبقة من طبقات التنفيذ. سترى طلب النموذج الخام: التلقين (prompt)، ونافذة السياق، والتنسيق. سترى استدعاء الأداة الذي قرر النموذج القيام به. سترى مسار هذا الاستدعاء عبر مستوى التحكم، وتنفيذ الوظيفة، وعودة البيانات (payload). وأخيرًا، سترى كيف يستهلك النموذج تلك النتيجة لتشكيل إجابته.
توفر هذه الرؤية إجابات على أسئلة التدقيق الأساسية. ستعرف أي أداة تم تشغيلها لأن مستوى التحكم قد سجل ذلك. ستعرف من منح الوصول لأن سجلات التكوين موجودة في سجل محلي واحد. وستعرف سبب ارتفاع تكلفة عملية التشغيل لأنك تستطيع حساب الرموز (tokens).
حساب ما يهم
لكل عملية تشغيل، تتبع أربعة مقاييس محددة. أولاً، رموز (tokens) الإدخال والإخراج. هذه الرموز هي المحرك الرئيسي لتكاليف النموذج، وأنت بحاجة إلى أعداد دقيقة، وليس مجرد تقديرات تقريبية. ثانياً، افصل بين زمن استجابة النموذج وزمن استجابة الأداة. فالوقت بين طلبك واستجابة النموذج يختلف عن الوقت الذي تستغرقه الخدمة الخارجية للرد على استدعاء الأداة. الخلط بين الاثنين يؤدي إلى تشخيص خاطئ لبطء النظام. ثالثاً، احسب التكلفة بناءً على أسعار المزود المعتمدة. لا تخمن؛ بل تحقق من ورقة أسعار المزود الخاص بك وطابقها مع الرموز التي تم قياسها. رابعاً، قارن بين الاستدعاءات الناجحة والاستدعاءات غير المصرح بها والمرفوضة. يشير ارتفاع عدد عمليات الرفض إلى أن الوكيل الخاص بك يحاول اختبار الحدود أو أن القائمة المسموح بها غير متوافقة مع الاحتياجات المشروعة.
تحول هذه الأرقام عمليات الوكيل من اشتراك "صندوق أسود" إلى نظام قابل للملاحظة. يمكنك من خلالها وضع الميزانية، والتحسين، والتفسير.
الفرق بين التحكم المحلي والتنفيذ المحلي
إليك درس قد يضلل حتى البنائين الحذرين. إن تشغيل deco Studio على جهازك يمنحك تحكماً محلياً في التكوين، ولكنه لا يضمن التنفيذ المحلي للنموذج نفسه. إذا قمت بتكوين الوكيل لاستدعاء مزود خارجي مثل OpenAI أو Anthropic أو أي واجهة برمجة تطبيقات (API) مستضافة، فإن طلباتك ستغادر جهازك. يدير Studio البوابة، ولكن البيانات لا تزال تعبر الشبكة.
تتبع هذه الحدود دائماً. اعرف أي أجزاء من خط الأنابيب (pipeline) تبقى على الجهاز المحلي (localhost) وأي أجزاء تنتقل إلى خادم شخص آخر. إذا كانت بياناتك حساسة، فإن التحكم المحلي في طبقة الأدوات ليس كافياً. ستحتاج أيضاً إلى معرفة مكان حدوث استدلال النموذج (model inference). لا تخلط بين راحة لوحة التحكم المحلية وواقع النموذج البعيد.
التعليمات ليست تفويضاً
أحد الاختصارات الخطيرة هو محاولة تأمين الوكيل من خلال التلقين (prompting). إن إخبار النموذج بـ "لا تستدعي وظيفة الحذف أبداً" ليس ضابطاً أمنياً، بل هو مجرد اقتراح. يمكن للنماذج أن تسيء تفسير التعليمات، أو تتعرض لاختراق الحماية (jailbreak)، أو ببساطة ترتكب أخطاء منطقية. الأمن الحقيقي يكمن عند الحدود البرمجية.
استخدم القوائم المسموح بها (allowlists) داخل deco Studio لتحديد الوظائف التي يمكن استدعاؤها بدقة. افرض تلك القيود باستخدام عمليات تحقق من جانب الخادم (server-side checks) داخل مستوى التحكم. يجب أن يكتشف الوكيل قدراته بالطريقة التي يكتشف بها المستخدم أذونات الملفات: من خلال الاصطدام بحد صارم، وليس من خلال قراءة ملاحظة ودية. الأمن ينتمي إلى البنية التحتية، وليس إلى اللغة الطبيعية.
ابدأ صغيراً، وابقَ متشككاً
ابنِ مستوى التحكم الخاص بك خطوة بخطوة. خادم MCP واحد. وظيفة واحدة مكشوفة. مهمة اصطناعية واحدة. تحقق من نجاح الوكيل حيث ينبغي له النجاح وفشله حيث يجب عليه الفشل. اقرأ التتبع (trace). أكد أعداد الرموز (tokens). ثم أضف الأداة التالية.
التحكم ليس مفتاحاً تضغط عليه، بل هو عادة إثبات الحدود قبل الوثوق بها. يمنحك deco Studio المستوى المحلي لممارسة تلك العادة. استخدمه لتحويل سرب من الوكلاء المستقلين إلى نظام مدار، وقابل للملاحظة، ومحدد الحدود.
المصدر: Controlling AI Agents in deco Studio: Tools, Permissions, and Cost
مجتمع تعليمي اختياري: GyaanSetu AI على تلغرام