حوكمة وكلاء الذكاء الاصطناعي عبر منصات متعددة

لم تقرر معظم الشركات تبني وكلاء الذكاء الاصطناعي عبر خمس منصات. لقد حدث ذلك لهم. وصل Microsoft Copilot مع مجموعة الإنتاجية. أطلقت ServiceNow ميزة Now Assist في قائمة انتظار التذاكر. قامت Salesforce بتفعيل Agentforce داخل نظام إدارة علاقات العملاء (CRM). بدأت منصات البيانات والبرمجيات كخدمة (SaaS) الأخرى في تشغيل الوكلاء بجانب أنظمة السجلات. جلبت كل منصة بيئة تشغيل الذكاء الاصطناعي الخاصة بها — وبصمت، قصة حوكمتها الخاصة التي تتوقف عند حدود المنصة.

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

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

شكل المشكلة

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

وهناك مشكلة خامسة لا تظهر إلا في اللحظة التي يحاول فيها المستخدم فعليًا القيام بـ شيء ما باستخدام وكيل تابع لجهة خارجية: ضريبة الاعتماد.

ضريبة الاعتماد الخفية

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

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

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

كيف يمكن أن يعمل مستوى تحكم متعدد المنصات

نمط معماري يعالج هذه الفجوة مباشرة هو الإدارة على الطبقة المشتركة بين جميع هذه المنصات. كل وكيل، بغض النظر عن المنصة التي تستضيفه، يقوم في النهاية بإجراء استدعاء لنموذج لغوي كبير (LLM) أو استدعاء أداة. اعتراض وإدارة هناك، ويمكنك إدارة نشاط الوكيل الذي يمر عبر طبقة التنفيذ المشتركة تلك — دون مطالبة كل منصة تطبيق بإعادة بناء نفسها.

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

فوق البوابات توجد طبقة رابعة: عدة الوكيل (Agent Harness). عدة الوكيل هي بيئة التشغيل المحيطة بالنموذج اللغوي الكبير (LLM) — حلقة التنسيق التي تخطط، وتستدعي الأدوات، وتدير السياق، وتتحكم في الإجراءات الحساسة عبر الموافقات، وتسجل كل خطوة في تتبع. إنها ما يحول استدعاء النموذج إلى وكيل موثوق به وطويل الأمد.

تقدم TrueFoundry هذا كخدمة مُدارة بدلاً من كونه إطار عمل. بيئة تنفيذ معزولة (sandboxed) تشغل التعليمات البرمجية والمهام طويلة الأمد. بوابات موافقة تتطلب تدخلًا بشريًا توقف استدعاءات الأدوات الحساسة حتى يوافق عليها المستخدم. سجل مهارات ذو إصدارات يحتوي على تعليمات قابلة لإعادة الاستخدام مع التحكم في الوصول المستند إلى الدور (RBAC). والأهم من ذلك — لا توجد مفاتيح API أو بيانات اعتماد مخزنة في تعريفات الوكلاء أبدًا؛ بل توجد في البوابات، حيث تقوم فرق المنصة بتكوين الوصول مرة واحدة ولا يلمس مطورو الوكلاء الأسرار أبدًا.

الأهم من ذلك، لا يقتصر الاكتشاف على الوكلاء الذين قمت ببنائهم على المنصة. الوكلاء الذين يعملون في أماكن أخرى — على Bedrock، LangGraph، خدمة HTTP مخصصة، أو منصة مورد آخر — يتم تسجيلهم في نفس المخزون كوكلاء عن بعد، بنفس البيانات الوصفية ونفس الضوابط. يصبح الأسطول المجزأ خريطة واحدة.

04خمس قدرات تستحق البحث عنها

للفرق التي تقيّم كيفية سد هذه الفجوة، تستحق القدرات الخمس التالية الفحص الدقيق — مع ملاحظة حول ما يتطلبه كل منها عادةً من الناحية التقنية الأساسية.

‍