حوكمة أنظمة الوكلاء المتعددين: هوية الوكيل، A2A، وبوابة الوكيل

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

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

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

١. نمط حركة المرور الجديد: استدعاء الوكلاء لبعضهم البعض

بالنسبة لمعظم ما يتعلق بالبوابات حتى الآن، كانت حركة المرور شمال-جنوب: تطبيق يستدعي نموذجًا، ربما عبر أداة. تضيف أنظمة الوكلاء المتعددين حركة مرور شرق-غرب — وكلاء يستدعون وكلاء آخرين. يقوم منسق بتفويض المهام إلى متخصصين؛ يستشير متخصص آخر؛ وتعود النتائج إلى الأعلى. يمنح بروتوكول Agent2Agent (A2A) الذي لا يزال حديث العهد هذا شكلًا قياسيًا، حيث ينشر الوكلاء أوصاف القدرات (بطاقات الوكيل) التي يكتشفها الآخرون، ويتبادلون المهام والرسائل عبر واجهة مشتركة، تمامًا كما قام بروتوكول MCP بتوحيد كيفية وصول الوكلاء إلى الأدوات.

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

٢. هوية الوكيل: لماذا لا يكفي مفتاح خدمة مشترك

كانت المشكلة الأساسية لتوماس هي الهوية. عندما يتحقق كل وكيل من هويته باستخدام مفتاح خدمة مشترك واحد، لا يستطيع النظام حرفيًا التمييز بين وكلائه — مما يعني أنه لا يمكنه تفويضهم بشكل مختلف، ولا يمكنه تحديد التكلفة لكل منهم على حدة، ولا يمكنه إعادة بناء من قام بالفعل.

الحل هو منح كل وكيل هويته الخاصة، التي تصدر وتتحقق منها البوابة، ونشرها في كل استدعاء يقوم به الوكيل — إلى نموذج، إلى أداة، وإلى وكيل آخر. هذه الهوية هي الأساس الذي تعتمد عليه جميع عناصر التحكم اللاحقة: قرارات التفويض، وحدود المعدل، وتحديد التكلفة، وتحديد التتبع، كلها تعتمد على "أي وكيل".

يحمل كل وكيل هويته الخاصة في كل قفزة (توضيحي)

# The gateway issues and verifies a per-agent identity, not a shared key.
ctx = AgentContext(
    agent_id="agent:research",          # this agent's own identity
    on_behalf_of="user:tomas",          # the human principal, preserved end-to-end
    run_id="run_4f9c",                  # correlates every hop of one workflow
    depth=2,                            # how deep in the delegation chain we are
)

# Propagated when this agent delegates to another agent or calls a tool:
gateway.invoke(target="agent:writer", context=ctx, payload=task)

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

٣. تفويض وسياسة A2A: أي وكيل يمكنه استدعاء أي وكيل آخر

تمكّن الهوية التفويض، والأسئلة تكون ملموسة في نظام متعدد الوكلاء. هل يمكن لوكيل البحث استدعاء وكيل الكاتب، أم فقط المنسق؟ هل يمكن لوكيل فرعي استدعاء أدوات خارجية مباشرة، أم فقط من خلال وكيله الأم؟ أي الوكلاء يمكنهم الإنفاق من أي ميزانية؟ تحويل هذه الأمور إلى سياسة كشفرة (policy-as-code) — بنفس نهج Cedar أو OPA من منشورات الحوكمة والتوجيه — يحول الحواف المسموح بها في مخطط الوكلاء إلى شيء صريح وقابل للمراجعة بدلاً من أن يكون ضمنيًا في الشفرة.

تفويض لكل وكيل للمكالمات شرق-غرب (سياسة توضيحية)

# Default-deny: an agent may only invoke agents it is explicitly allowed to.
allow if principal.agent_id == "agent:orchestrator"
      and action == "invoke"
      and resource.agent_id in ["agent:research", "agent:writer", "agent:critic"]

# Sub-agents may NOT invoke the orchestrator — this edge is what created the loop.
deny  if principal.agent_id in ["agent:research", "agent:writer"]
      and resource.agent_id == "agent:orchestrator"

# Only the research agent may reach external search tools.
allow if principal.agent_id == "agent:research"
      and resource.kind == "mcp_tool"
      and resource.name == "web_search"

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

من المفيد أن نكون دقيقين بشأن ما تقرره البروتوكولات وما تتركه لك. الاكتشاف والنقل موحدان؛ لكن نموذج الهوية والسياسة والميزانيات ونقطة التنفيذ ليست كذلك:

4. احتواء نطاق التأثير: الحلقات، التوسع الجامح، وحدود المعدل

حتى مع التفويض الجيد، تفشل أنظمة الوكلاء المتعددين بطرق لا تفشل بها المكالمات الفردية، لأن وحدة الضرر هي التتالي. يمكن لإعادة المحاولة التي تعيد التفويض أن تشكل حلقة؛ ويمكن لوكيل يتوسع إلى العديد من الوكلاء الفرعيين أن يضخم طلبًا واحدًا إلى الآلاف؛ ويمكن لوكيل فرعي بطيء أن يعطل سير عمل بأكمله. هذه هي النسخة على نطاق الوكيل من مشكلات "القطيع الصاخب" و"التصعيد الصامت" المألوفة من التوجيه وتجاوز الفشل على طبقة النموذج.

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

ضوابط نطاق التأثير لتشغيل متعدد الوكلاء (تكوين بوابة توضيحي)

run_limits:
  max_delegation_depth: 5          # breaks cycles structurally
  max_total_tokens: 500000         # whole-run budget, force-stop past this
  max_wall_clock_seconds: 600

per_agent:
  invoke_rate_limit: 60/min        # one agent can't call others without bound
  timeout_seconds: 45              # stall detection on a child call
  on_breach: halt_and_alert        # stop the run, page a human

التحول في طريقة التفكير هو التعامل مع تشغيل متعدد الوكلاء كمعاملة محددة بميزانية وعمق، وليس محادثة مفتوحة. ومع تطبيق هذه الحدود عند البوابة، تصبح حلقة توماس الليلية حدًا تم تجاوزه وتنبيهًا في الساعة 2 صباحًا بدلاً من فاتورة بخمسة أرقام في الساعة 9 صباحًا.

5. قابلية المراقبة: تتبع تشغيل متعدد الوكلاء من البداية إلى النهاية

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

يعتمد هذا مباشرة على التتبع من منشور OpenTelemetry الخاص بنا: نفس نموذج الامتداد، مع الوكيل كبعد من الدرجة الأولى والتشغيل كالتتبع الذي يربط الامتدادات معًا. بوابة وكيل TrueFoundry تلتقط تتبعات التنفيذ الشاملة هذه وتتيح لك فحص سجلات كل خطوة لتشخيص الأعطال — مما يحول "الوكلاء أنفقوا الكثير الليلة الماضية" إلى "هذه الحافة شكلت حلقة على عمق أربعة"، وهو الفرق بين اللغز والحل.

6. إسناد التكلفة حسب هوية الوكيل

التكلفة في نظام متعدد الوكلاء لا معنى لها بدون هوية. "تكلفة سير العمل X" لا تخبرك ما إذا كان الإنفاق هو مكالمات التخطيط للمنسق، أو اختيار نموذج مكلف لوكيل فرعي واحد، أو حلقة. إن عزو الرموز والتكلفة إلى الوكيل وسير العمل والتشغيل المحدد — بالاعتماد على الهوية من القسم 2 — هو ما يجعل الإنفاق واضحًا ويمكن تشخيص الخلل.

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

7. الأمان: كيف ينتشر حقن الأوامر عبر الوكلاء

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

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

8. البوابة كمستوى تحكم للوكيل

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

بوابة الوكيل هي مستوى التحكم هذا. بوابة وكيل TrueFoundry تدير وكلاء مستقلين عن الإطار عبر طبقة تنفيذ موحدة ومحكومة: هوية لكل وكيل والتحكم في الوصول المستند إلى الدور (RBAC)، وحصص الرموز والتكلفة لكل وكيل وسير عمل، وإعادة المحاولات، والمهل الزمنية وضمانات ضد الحلقات، والتتبع الشامل، والوصول إلى الأدوات المحكوم بواسطة MCP — لتوحيد حركة مرور النموذج الخاصة بـ بوابة الذكاء الاصطناعي، وحركة مرور الأدوات الخاصة بـ بوابة MCP، وحركة مرور الوكلاء فيما بينهم للأنظمة متعددة الوكلاء في مكان واحد. للحصول على نظرة أعمق لأنماط التنسيق نفسها، يعد دليل تنسيق الأنظمة متعددة الوكلاء من TrueFoundry رفيقًا مفيدًا؛ هذا المنشور يدور حول إدارة هذه الأنظمة بمجرد تشغيلها.

9. الأسئلة الشائعة

أليس A2A لا يزال في مراحله الأولى؟ لماذا تتم حوكمته الآن؟

لا يزال A2A حديث العهد كنمط تبني للمؤسسات — على الرغم من أن البروتوكول لديه الآن مواصفات رسمية للإصدار 1.0 — وستستمر تقاليد النظام البيئي في التطور، لذا تعامل مع التفاصيل على أنها مؤقتة. لكن الحاجة إلى الحوكمة لا تنتظر حتى يستقر التبني: في اللحظة التي يفوض فيها وكلاؤك بعضهم البعض، بأي آلية، سيكون لديك حركة مرور داخلية بلا هوية أو قيود. الضوابط هنا — هوية لكل وكيل، التفويض، حدود نطاق التأثير، التتبع — تنطبق سواء تحدث الوكلاء عبر A2A، أو التفويض الأصلي لإطار عمل، أو HTTP عادي.

بماذا يختلف هذا عن منشور طبقة الوكيل المُدار؟

دعا ذلك المنشور إلى فصل منطق الوكيل عن بيئة التشغيل — حيث يتم تشغيل رمز الوكيل وكيفية نشره. هذا المنشور يتعلق بحوكمة الاتصال بين الوكلاء بمجرد تشغيلهم: الهوية في كل قفزة، من يمكنه استدعاء من، احتواء التواليات، وتتبع التنفيذ. طبقات ذات صلة، مشاكل مختلفة — فصل بيئة التشغيل يتعلق بالوكيل كوحدة قابلة للنشر؛ هذا يتعلق بالوكيل كمشارك في الشبكة.

ما هو الضابط الوحيد الذي كان سيمنع الانفتاح غير المحكوم؟

اثنان، يعملان معًا. قاعدة تفويض تمنع الوكلاء الفرعيين من إعادة استدعاء المنسق كانت ستقطع الحلقة هيكليًا عند القفزة الأولى؛ وحد لعمق التفويض وحد لمعدل الاستدعاء لكل وكيل كانا سيمسكان بأي حلقة تسللت عبر السياسة. لا يتطلب أي منهما فهم نية سير العمل — بل يحددان شكله — وهذا هو السبب في أنها تنتمي إلى البوابة بدلاً من منطق كل وكيل.

هل يحتاج كل وكيل حقًا إلى هويته الخاصة؟

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

بوابة أم إطار عمل لحوكمة الأنظمة متعددة الوكلاء؟

إطار العمل يبني سير العمل؛ والبوابة تحكمه. الهوية، التفويض، حدود المعدل والعمق، التتبع، ونسبة التكلفة هي قضايا متقاطعة يجب أن تكون متسقة عبر كل وكيل وإطار عمل تقوم بتشغيله، وهذا بالضبط ما توفره لوحة تحكم واحدة وما لا يمكن أن يضمنه التنفيذ لكل إطار عمل.

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

المراجع

• TrueFoundry — بوابة الوكيل (هوية الوكيل، الحصص، التتبع، ضمانات الحلقات)
• TrueFoundry — ما هو تنسيق الأنظمة متعددة الوكلاء؟
• بروتوكول Agent2Agent (A2A) — بطاقات الوكيل ومراسلة الوكيل للوكيل
• لدينا بوابة الوكيل، حقن المطالبات، إسناد التكلفة، و OpenTelemetry لنماذج اللغة الكبيرة منشورات.

Northwind وTomás هما مثالان توضيحيان. توضيح يستحق الذكر صراحةً: بروتوكول Agent2Agent (A2A) هو بروتوكول اتصال مفتوح، بينما بوابة وكيل TrueFoundry هي منتج TrueFoundry وتطبيق مستوى التحكم الخاص بها لإدارة سير عمل الوكلاء — وهما شيئان مختلفان، وتستخدم هذه المقالة A2A كمصطلح قياسي لحركة المرور التي تديرها البوابة. يتم تلخيص قدرات بوابة وكيل TrueFoundry من وثائق المنتج العامة اعتبارًا من يونيو 2026 وستتطور؛ وقد تكون بعض الميزات في مرحلة المعاينة. لا يزال A2A حديثًا كنمط تبني للمؤسسات وستستمر اتفاقيات نظامه البيئي في التطور، لذا يتم وصف تفاصيل البروتوكول هنا بمستوى عالٍ ويجب تأكيدها مقابل المواصفات الحالية. عينات التعليمات البرمجية والسياسات توضيحية للأنماط الموثقة، وليست منسوخة من تطبيق مرجعي.

‍