سلسلة بوابة الوكيل (الجزء 2 من 7) | سجل الخدمات للعصر الوكيلي

في بنية الخدمات المصغرة (microservices)، نستخدم DNS للعثور على الخدمات. إذا احتجت إلى خدمة الفواتير، أستدعي billing.svc.cluster.local. الأمر بسيط لأن العلاقة ثابتة: الخدمة أ تستدعي الخدمة ب.

في بنية الوكلاء، العلاقات ديناميكية. لا تريد أن يقوم "وكيل المدير" الخاص بك بتضمين اتصال ثابت بـ finance-agent-v1. بل تريده أن يسأل: "ابحث لي عن إمكانية يمكنها الاستعلام عن إيرادات الربع الثالث."

أحيانًا تكون هذه الإمكانية أداة (Tool) (استعلام SQL مباشر عبر خادم MCP).

وأحيانًا تكون هذه الإمكانية وكيلًا آخر (Agent) (محرك استدلال يحلل مخرجات SQL).

لحل هذه المشكلة، تقدم TrueFoundry سجل MCP والوكلاء الموحد. إنه كتالوج واحد يتعامل مع الأدوات و الوكلاء كأصول قابلة للاكتشاف والتشغيل البيني.

1. طبقة التجريد الموحدة

إن سجل وكلاء الذكاء الاصطناعي يعمل كطبقة تجريدية موحدة. يستوعب موارد متباينة — نصوص بايثون البرمجية، وكلاء LangGraph، قواعد بيانات Postgres، واجهات برمجة تطبيقات SaaS — ويعرضها جميعًا كـ قدرات.

بالنسبة للمنسق، تبدو "قاعدة البيانات" و"وكيل المحلل المبتدئ" متطابقين: كلاهما مجرد نقاط نهاية تقبل مخطط JSON وتعيد نتيجة.

الشكل 1: نموذج بيانات إدخال سجل الوكيل

2. نموذج "الوكيل كأداة" (عبر MCP)

أكبر عائق أمام التعاون متعدد الوكلاء هو عدم تطابق الواجهات. وكيل LangGraph يتحدث "تحديثات الحالة"؛ وكيل CrewAI يتحدث "المهام".

تقوم TrueFoundry بتوحيد هذا باستخدام بروتوكول سياق النموذج (MCP).

عند تسجيل وكيل في البوابة، فإن الـ سجل يغلفه تلقائيًا في واجهة MCP. هذا يعني أن "وكيل المحلل المالي" المتطور الخاص بك يبدو تمامًا كاستدعاء دالة قياسي لبقية النظام.

• الواقع الداخلي: وكيل بايثون معقد مزود بذاكرة وتخطيط و3 وكلاء فرعيين.
• الواجهة الخارجية: تعريف أداة MCP.

هذا يسمح لـ"وكيل المدير" باستدعاء "وكيل فرعي" بنفس سهولة استدعائه لآلة حاسبة — مما يبسط التنسيق إلى بروتوكول واحد.

الشكل 2: مثال الوكيل كأداة

3. الاكتشاف الدلالي: إيجاد القدرة، وليس مجرد الهوية

كيف يعرف الوكيل الأداة التي يجب استخدامها؟ لا ينبغي أن يحتاج إلى معرفة الاسم.

الـ السجل يستخدم تضمينات المتجهات لربط نية اللغة الطبيعية بالقدرات التقنية.

• نية الوكيل: "أحتاج إلى التحقق مما إذا كان الخادم سليمًا."
• استعلام السجل: يفحص أوصاف جميع خوادم ووكلاء MCP المسجلة.
• المطابقة الدلالية:
  
  • prometheus-mcp (أداة): "استعلام المقاييس من بروميثيوس" (النتيجة: 0.92)
  • sre-bot-v1 (وكيل): "تشخيص وإصلاح مشكلات البنية التحتية" (النتيجة: 0.88)

تعيد البوابة كلا الخيارين. يمكن للوكيل المتصل بعد ذلك أن يقرر: هل أحتاج إلى مقياس خام (أداة)، أم تشخيص (وكيل)؟

4. التوجيه القائم على الثقة: "أحضر لي الـ الخبير الموثوق به "

في مؤسسة لا مركزية، قد يكون لديك خمسة "وكلاء برمجة" مختلفين منشورة من قبل فرق مختلفة. أي واحد يجب أن تستخدم؟

سيسرد السجل الثابت جميعها فقط. سجل TrueFoundry يحتفظ بالحالة. يتصل بـ ai gateway observability طبقة لتتبع

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

• coder-agent:v1 (معدل النجاح: 88%، زمن الاستجابة: 2 ثانية)
• coder-agent:v2-canary (معدل النجاح: 95%، زمن الاستجابة: 5 ثوانٍ)

يمكنك تهيئة سياسات التوجيه مباشرة في السجل:

"لتغييرات كود الإنتاج، وجّه فقط إلى الوكلاء الذين لديهم درجات إخلاص تتجاوز 90% في آخر تشغيل تقييم."

هذا يضمن أن طبقة التنسيق لديك لا تتصل فقط بـ الوكلاء المتاحين ، بل بـ الأكفاء منهم.

5. التحكم في الطوبولوجيا: جدار حماية الهيكل التنظيمي

مع توسعك إلى مئات الوكلاء وآلاف أدوات MCP، فإنك تخاطر بـ "شبكة متشابكة" حيث يمكن لكل وكيل استدعاء كل أداة. هذا كابوس أمني.

يفرض السجل طوبولوجيا الرسم البياني. إنه يعمل بمثابة "الهيكل التنظيمي" لقوتك العاملة الرقمية.

• قاعدة: يُسمح لروبوت الدعم العام باستدعاء Documentation-MCP.
• قاعدة: روبوت الدعم العام مرفوض الوصول إلى وكيل الرواتب.

يتم هذا التحقق عند طبقة الاكتشاف. عندما يسأل روبوت الدعم "من يمكنه مساعدتي في كشوف المرتبات؟"، يعيد السجل ببساطة "لم يتم العثور على نتائج." لا يمكنك مهاجمة ما لا يمكنك رؤيته.

الخلاصة

يُعد السجل الموحد لـ MCP والوكلاء العمود الفقري للمؤسسة المعرفية. من خلال التعامل مع الوكلاء والأدوات كمواطنين متساوين وقابلين للاكتشاف — وتغليفهم في طبقة أمان ومراقبة موحدة — تتيح لك TrueFoundry إنشاء سير عمل معقدة وموثوقة من مكونات بناء متباينة.