كيف تعمل وكلاء الذكاء الاصطناعي المستقلون معًا: جسر A2A لـ Hermes Agent

ماذا يعني هذا لأعمالك

• تتعاون وكلاؤك دون إعادة كتابة. إن Agent2Agent Protocol (A2A) معيار مفتوح يتيح لوكلاء الذكاء الاصطناعي أن يكتشف بعضهم بعضًا، ويفوّض العمل، ويبثّ النتائج فيما بينهم. يتيح جسرٌ رفيع لوكيل موجود أن يتحدّث هذا المعيار دون تغيير داخله — فتبقى الاستثمارات التي أنجزتها قائمة.
• لا احتجاز لدى المورّد. لأن الجسر يقع بين المعيار والوكيل، يمكنك لاحقًا استبدال إطار الوكيل الأساسي دون كسر التكاملات المبنية فوقه. تظل الفرق الأخرى تستدعي نقطة النهاية المعيارية نفسها.
• نظام واحد يخدم عملاء كثيرين أو وحدات أعمال عدّة — مع فصل صارم للبيانات. يُفرَض العزل بين المستأجرين على مستوى قاعدة البيانات، لا في شيفرة التطبيق فحسب، فلا يمكن لخطأ برمجي أن يسرّب بيانات عميل إلى آخر. هذا هو الفارق الذي يجتاز مراجعة أمنية.
• يبقى البشر مسيطرين على الإجراءات الحسّاسة. حين يحتاج الوكيل إلى موافقة — عملية شراء، أو قرار وصول إلى بيانات، أو اعتماد عرض سعر — تظهر الطلبية بوصفها حالة معيارية «بانتظار الموافقة» تعود حتى الشخص أو الوكيل الذي بدأ السلسلة، حتى عبر حدود الأُطر.
• إنه حقيقي ومُختبَر، لا شريحة عرض. كل ذلك مُحزَّم بوصفه نشرًا مفتوح المصدر (docker-a2a-hermes-agent-gateway) مع مجموعة اختبارات آلية تُثبت كل قدرة قبل أن تعتمد عليها.

المشكلة: وكلاء لا يستطيعون التحدّث فيما بينهم

معظم المؤسسات لا تتبنّى «وكيل ذكاء اصطناعي واحدًا»، بل تُراكم عدّة. وكيل تسعير هنا، ووكيل استعلام كتالوج هناك، ووكيل مخزون تملكه فرقة أخرى — تُبنى غالبًا على أُطر مختلفة، وأحيانًا من مورّدين مختلفين، في أوقات مختلفة. تعمل منفردةً، لكن عنق الزجاجة هو جعلها تتعاون: تسليم العمل لآخر، وانتظار نتيجة، وإعادة التحكّم.

حلّ ذلك بتوصيل كل وكيل يدويًا بكل الوكلاء الآخرين بطيء وهشّ، ويزداد سوءًا مع كل وكيل جديد. كما يوقعك في احتجاز صامت: ما إن تُرمَّز التكاملات ترميزًا صلبًا على واجهة مورّد بعينه، حتى يعني استبدال ذلك المورّد إعادة إنجازها جميعًا.

إن Agent2Agent Protocol (A2A) هو المعيار المفتوح الذي يزيل عنق الزجاجة هذا. يعرّف لغةً مشتركة تتيح للوكلاء أن يكتشف بعضهم بعضًا، ويفوّضوا المهام، ويبثّوا التقدّم، ويُبلّغوا عن الإنجاز، أيًّا كان ما بُني عليه كلٌّ منهم. تبنَّ المعيار مرّة، وسيتحدّث كل وكيل جديد لاحقًا اللغة نفسها التي يتحدّثها البقية.

المأزق: وكلاؤك الموجودون لا يتحدّثون A2A أصلًا. فمثلًا Hermes Agent من Nous Research يكشف واجهته الخاصة. وإعادة كتابة وكيل يعمل جيّدًا لإضافة بروتوكول جديد هي تمامًا نوع المشروع المكلف والمحفوف بالمخاطر الذي تريد الفرق تجنّبه.

الجواب هو جسر — طبقة ترجمة صغيرة تتحدّث A2A من الخارج، وتتواصل مع الوكيل بلغته الخاصة من الداخل. لا يتغيّر الوكيل نفسه أبدًا. ومشروع docker-a2a-hermes-agent-gateway مثال عملي مفتوح المصدر لهذا الجسر، مُحزَّم ليعمل كوحدة نشر واحدة.

كيف تتلاءم القطع

هناك ثلاث قطع متحرّكة، وواحدة منها فقط مكشوفة للعالم الخارجي:

1. الباب الأمامي (البوابة). يدخل كل شيء عبر نقطة وصول واحدة مُحكَمة. تقرّر من يُسمح له بالدخول، وإلى أي عميل ينتمي الطلب، وبأي سرعة يمكن للمُستدعين أن يمضوا، وكيف يُعاد بثّ التقدّم الحيّ. لا شيء غير ذلك متاح مباشرةً.
2. المُترجِم (الجسر). يستقبل الطلبات بمعيار A2A المفتوح ويحوّلها إلى ما يفهمه وكيلك فعليًا، ثم يحوّل الجواب مرة أخرى. هذه هي القطعة الوحيدة التي تعرف شيئًا عن الوكيل المحدّد، وهو تحديدًا سبب إمكان استبدال الوكيل لاحقًا.
3. الوكيل وسجلّ عمله. يقوم وكيلك الموجود بالاستدلال الفعليّ. وكل ما يفعله يُدوَّن — كل مهمّة وكل رسالة — مع فصله فصلًا صارمًا حسب العميل.

ولأن الباب الأمامي والسجلّ مستقلّان عن الوكيل نفسه، يمكنك إبقاء البوابة داخل سحابتك الخاصة وتوجيهها إلى وكيل يعمل في مكان آخر، أو إلى قاعدة بيانات مُدارة من اختيارك. لا شيء يُجبر الثلاثة على أن تكون في المكان نفسه.

تبنَّ المعيار دون إعادة كتابة وكلائك

أثمن خاصية هنا هي أن وكيلك لا يتغيّر أبدًا. فالمُترجِم يتولّى كل عمل التحدّث بالمعيار نيابةً عنه.

ولهذا نتيجتان تجاريّتان مباشرتان:

• تحمي الاستثمار الذي أنجزته. الفريق الذي بنى وكيل التسعير لا يتوقّف لإعادة هندسته من أجل بروتوكول جديد، بل يضيف جسرًا ويمضي.
• تتجنّب الاحتجاز في الاتجاهين. يعتمد المُستدعون على المعيار المفتوح وحده، لا على مورّد وكيلك. وإن استبدلت الوكيل لاحقًا — نموذج أفضل، مزوّد أرخص، بناء داخليّ — تغيّر المُترجِم، وتبقى كل التكاملات المبنية فوقه تعمل دون مساس. وبالعكس، يمكن لبوابة واحدة أن تكون واجهةً لعدّة وكلاء مختلفين في آنٍ واحد: يُوجَّه العمل كثيف الاستدلال إلى أحدها، وخطوات سير العمل الروتينية إلى آخر، ويبدو الجميع متطابقًا للمُستدعي. يصير اختيار المحرّك تفصيلًا تنفيذيًّا تتحكّم فيه، لا التزامًا يقيّدك.

اخدم عملاء كثيرين أو وحدات أعمال عدّة — بفصل بيانات يجتاز التدقيق

يمكن للنشر نفسه أن يخدم مستأجرين كثيرين — عملاء مختلفين، أو وحدات أعمال داخلية مختلفة — من نظام واحد قيد التشغيل. يحصل كلٌّ منهم على وكلائه، وسجلّ مهامه، ومخزن رسائله الخاصة.

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

أبقِ البشر مسيطرين على الإجراءات الحسّاسة

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

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

شغّله حيث يجب أن تقيم بياناتك

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

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

مُثبَت قبل أن تعتمد عليه

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

القيمة العمليّة هي خفض المخاطر: لست مضطرًّا لتصديق كلام أحد بأن التكامل يعمل. فهو يُبرهَن، على نحو قابل للتكرار، عند كل تغيير.

ما يتطلّبه تشغيله فعليًا في الإنتاج

الصدق بشأن كلفة التشغيل جزء من الحجّة التجارية. وهذه بعض الحقائق التي يجدر التخطيط لها:

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

لا شيء من هذه عائق. إنها المسؤوليّات العاديّة لتشغيل نظام حقيقيّ، وذكرها مسبقًا هو سبيل تجنّب المفاجآت بعد الإطلاق.

ما يتيحه هذا

مجتمعةً، يقدّم نمط الجسر ثلاثة أمور يصعب حقًّا تجميعها من الصفر:

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

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

3. استقلاليّة محكومة عبر الحدود. تنتقل بوابات الموافقة البشرية مع العمل، فتحظى الإجراءات الحسّاسة بإنسان في الحلقة مهما بلغ عدد الوكلاء — أو عدد الأُطر — التي مرّ بها الطلب.

التنفيذ العمليّ مفتوح المصدر وموثَّق بالكامل: يوجد الجسر ودليل تكامله في مستودع a2a_daemon_engine (انظر دليل تكامل Hermes)، وقد وُثِّق الباب الأمامي المُحكَم في مستودع SilvaEngine Gateway. والنشر الكامل مُحزَّم في docker-a2a-hermes-agent-gateway.

قراءات ذات صلة

• MCP + A2A: البروتوكولان وراء كل نظام ذكاء اصطناعي وكيليّ في الإنتاج — كيف يقتسم المعياران المفتوحان العمل: يربط MCP الوكلاء بالأدوات، ويربط A2A الوكلاء بعضهم ببعض
• دمج A2A مع أُطر الوكلاء الموجودة: عرض توضيحيّ بـ Hermes Agent — نمط الجسر العامّ وكيف ينطبق فيما وراء Hermes
• معيار شيفرة وحدات MCP — الانضباط الذي يُبقي تكاملات الوكلاء جاهزة للإنتاج مع تكاثرها

---

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

اطلب بناءً محدّد النطاق

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