A2A مقابل MCP: اختيار البروتوكول الصحيح لاتصال الوكلاء

معظم أنظمة الوكلاء الإنتاجية تحتاج إلى بروتوكولين، لا واحد. يمنح Model Context Protocol (MCP) الوكيل الوصول إلى الأدوات ومصادر البيانات — سجلات NetSuite، جهات اتصال HubSpot، كتالوجات الموردين، استعلامات Redshift. يمنح Agent2Agent Protocol (A2A) الوكلاء طريقة لتفويض العمل إلى وكلاء آخرين — وكيل تسعير يطلب من وكيل كتالوج قطع بديلة، وكيل مشتريات يطلب من وكيل امتثال التحقق من شهادة GMP. الخلط بين الاثنين يؤدي إلى هياكل هشة: استخدام A2A لاستدعاء قاعدة بيانات، أو استخدام MCP لتنسيق وكيلين مستقلين، ينتج أنظمة تحارب تصميم بروتوكولها الخاص.

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

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

التمييز في سطر واحد

MCP يربط الوكيل بالأدوات. A2A يربط الوكلاء بالوكلاء. MCP هو بروتوكول استدعاء أدوات — يطلب الوكيل مورد أو يستدعي دالة، ويستجيب الخادم ببيانات منظمة. A2A هو بروتوكول تفويض مهام — يرسل الوكيل وحدة عمل إلى وكيل آخر، يستقبل مخرجات متدفقة، ويتتبع المهمة عبر آلة حالة. النمط الإنتاجي، المؤكد عبر أكثر من 150 منظمة A2A وأكثر من 10,000 خادم MCP، هو: A2A بين الوكلاء، MCP بين الوكلاء والأدوات.

أين يناسب كل بروتوكول

البعد	MCP	A2A
ما يربطه	وكيل ← أداة، مصدر بيانات، API	وكيل ← وكيل
وحدة العمل	استدعاء أداة (طلب/استجابة)	مهمة (دورة حياة ذات حالة)
جهة البروتوكول	Anthropic (مواصفات مفتوحة، نهائية 2026-07-28)	Google (مواصفات مفتوحة، Linux Foundation، 150+ منظمة)
النقل	STDIO، Streamable HTTP (SSE مهمل، إيقاف خلال 12 شهراً)	JSON-RPC 2.0 عبر HTTP، تدفق SSE
الاكتشاف	الخادم يسجل الأدوات؛ العميل يكتشف	Agent Card في /.well-known/agent-card.json
الحالة	بلا حالة (مواصفات 2026-07-28)؛ الحالة في العميل	آلة حالة المهمة: submitted ← working ← input-required ← completed/failed/canceled
التدفق	نتائج الأدوات استجابات فردية	message/stream لتسليم الرموز والقطع في الوقت الفعلي
الإنسان في الحلقة	ليس مفهوم من الدرجة الأولى	INPUT_REQUIRED حالة مهمة من الدرجة الأولى
المصادقة	لكل خادم؛ OAuth 2.1 في المواصفات، رموز bearer في الممارسة	لكل وكيل؛ Agent Card يعلن مخططات المصادقة، البوابة تتعامل مع التنفيذ
الاعتماد	10,000+ خادم، 4 SDK من الفئة الأولى (TypeScript، Python، Go، C#)	150+ منظمة، حوكمة Linux Foundation

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

الأسئلة الخمسة التي تحدد التقسيم

1. هل الجانب الآخر يفكر أم يستجيب؟

خادم NetSuite MCP لا يفكر. يستقبل استدعاء أداة (get_customer، search_items)، يستعلم API، ويرجع JSON منظمة. الوكيل الذي استدعاه يقوم بالتفكير. وكيل تسعير A2A يفكر — يستقبل مهمة ("قيّم هذه العروض الثلاثة مقابل التسعير التاريخي وموثوقية المورد")، يشغل استدلال النموذج الخاص به، قد يستدعي أدوات MCP الخاصة به، ويرجع توصية مع التفكير المرفق.

إذا كان الجانب الآخر مصدر بيانات أو API، استخدم MCP. إذا كان الجانب الآخر وكيل ذاتي بنموذجه الخاص وأدواته الخاصة واتخاذ قراراته الخاصة، استخدم A2A. الاختبار العملي: هل الشيء الذي تستدعيه لديه prompt خاص به؟ إذا نعم، A2A. إذا لا، MCP.

2. هل تحتاج إلى مخرجات متدفقة؟

استدعاءات أدوات MCP هي طلب/استجابة. يعالج الخادم الطلب ويرجع نتيجة واحدة. لا توجد حالة وسيطة، لا تدفق رمز برمز، لا قطع جزئية. هذا مناسب للاستعلام عن قاعدة بيانات أو جلب سجل — تريد النتيجة الكاملة، لا تدفق أجزاء.

A2A يدعم message/stream، الذي يسلم تباينات الرموز والقطع عند إنتاجها. وكيل تسعير يستغرق 30 ثانية لتقييم ثلاثة عروض يمكنه بث تفكيره أثناء العمل، بحيث يمكن للوكيل المستدعي (والإنسان المراقب) رؤية التقدم، اكتشاف الأخطاء مبكراً، والإلغاء إذا انحرف التفكير. إذا كان سير عملك ينتج مخرجات بمرور الوقت وتحتاج للتصرف بناءً على نتائج جزئية، A2A هو البروتوكول الذي يدعم ذلك أصلياً.

3. هل هناك بوابة موافقة بشرية؟

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

A2A يعرف INPUT_REQUIRED كحالة مهمة من الدرجة الأولى. عندما يصل الوكيل إلى قرار يحتاج موافقة بشرية — تخويل شراء، موافقة عرض، قرار وصول بيانات — ينقل المهمة إلى INPUT_REQUIRED. الوكيل المستدعي (أو المشغل البشري خلفه) يرى حالة بروتوكول قياسية، لا تفاصيل خاصة بإطار العمل. عندما يستجيب الإنسان، تستأنف المهمة. إذا كان سير عملك يتضمن بوابات موافقة تعبر حدود الوكلاء، A2A ينقل تلك البوابات بشفافية. جسر A2A لـ Hermes Agent يربط طلبات الموافقة الأصلية لـ Hermes بحالة INPUT_REQUIRED لـ A2A، بحيث يمكن لسلسلة تفويض الوكلاء أن تتضمن نقطة فحص بشرية بغض النظر عن إطار العمل الذي يعمل عليه كل وكيل.

4. كم يستغرق العمل وقتاً؟

استدعاءات أدوات MCP مصممة للعمليات القصيرة المتزامنة — الاستعلام عن API، جلب سجل، تشغيل حساب. مواصفات 2026-07-28 جعلت MCP بلا حالة صراحةً، مما يعني أن الخادم لا يحتفظ بسياق المحادثة بين الاستدعاءات. الحالة تعيش في العميل (الوكيل)، لا في الخادم. هذا هو التصميم الصحيح للأدوات: خادم NetSuite لا ينبغي أن يتذكر أنك استعلمت عن عميل قبل خمس دقائق.

مهام A2A مصممة للعمل الأطول مع إدارة دورة حياة صريحة. تنتقل المهمة عبر submitted ← working ← completed (أو failed، canceled، input-required). آلة الحالة جزء من البروتوكول. تقييم تسعير يستغرق دقيقتين، فحص امتثال يستغرق ساعة، أو مهمة بحث متعددة الوكلاء تستغرق يوماً — هذه تناسب نموذج مهمة A2A. تم تأكيد Astra من OpenAI في 1 أغسطس، وهو مبني لمهام تعمل على مشاكل لساعات أو أيام. نمط تنسيق Astra متعدد الوكلاء يرتبط مباشرةً بدورة حياة مهمة A2A، لا بنموذج استدعاء الأدوات بلا حالة لـ MCP.

5. هل تستدعي نظاماً واحداً أم تنسق وكلاء متعددين؟

إذا كان وكيلك يحتاج للتحدث مع NetSuite، HubSpot، و BigCommerce، فهذه ثلاثة خوادم MCP. كل خادم يكشف أدوات؛ الوكيل يستدعيها حسب الحاجة. الوكيل يقوم بالتنسيق — يقرر أي أداة يستدعي، متى، وبأي ترتيب. خوادم MCP لا تعرف عن بعضها.

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

متى تستخدم كليهما: النمط الإنتاجي

النمط الإنتاجي، المؤكد بواسطة دليل tyk.io للمؤسسات ومرئي عبر 150+ منظمة A2A، هو بنية ذات طبقتين:

كل وكيل متخصص هو نقطة نهاية A2A (يكشف Agent Card، يقبل المهام، يبث النتائج). كل وكيل متخصص يستخدم أيضاً MCP للاتصال بمصادر بياناته الخاصة. وكيل المنسق никогда لا يتحدث مع NetSuite مباشرة — يفوض إلى وكيل التسعير، الذي يستخدم MCP للاستعلام عن NetSuite. هذا الفصل يبقي سطح أدوات كل وكيل محوكماً وقابلاً للتدقيق، بينما تتولى طبقة A2A التنسيق بين الوكلاء.

تنفيذ مرجع جسر A2A لـ Hermes Agent يوضح هذا النمط: بوابة تتعامل مع سطح بروتوكول A2A (Agent Card، توزيع JSON-RPC، تدفق SSE، آلة حالة المهمة)، ومعالجات قابلة للتوصيل تترجم دلالات مهمة A2A إلى API الأصلي لكل إطار عمل. إضافة إطار عمل وكيل جديد تعني كتابة فئة معالج واحدة — البروتوكول، البوابة، وآلة الحالة هي بنية تحتية مشتركة. يمكن للبوابة نفسها التوجيه إلى Hermes Agent، OpenClaw، أو أي معالج مستقبلي دون تغيير سطح عميل A2A.

متى يكفي وكيل واحد

ليس كل نظام يحتاج A2A. بحث Princeton NLP وجد أن وكيل واحد يماثل أو يتفوق على نظام متعدد الوكلاء في 64% من مهام المعيار — بتكلفة 2× لتكوين الوكلاء المتعددين. إذا كان سير عملك وكيل واحد يستعلم عن NetSuite، يصيغ عرضاً، ويقدمه للموافقة، تحتاج MCP (للاتصال بـ NetSuite) وبوابة موافقة على مستوى التطبيق. لا تحتاج A2A.

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

مواصفات MCP 2026-07-28 النهائية: ما تغير لهذا القرار

نُشرت مواصفات MCP كنهائية في 28 يوليو 2026. جميع SDKs الأربعة من الفئة الأولى (TypeScript، Python، Go، C#) تتحدث 2026-07-28. المواصفات جعلت MCP بلا حالة صراحةً — الخوادم لا تحتفظ بحالة الجلسة بين الاستدعاءات. سياسة إهمال SSE لمدة 12 شهراً نشطة: نقل Streamable HTTP يحل محل SSE، ولعمليات نشر SSE الحالية حتى يوليو 2027 للترحيل.

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

ملاحظة عن تداخل النقل

كلا البروتوكولين يستخدم HTTP و SSE، مما قد يسبب ارتباكاً حول ما إذا كانا يتنافسان. لا يتنافسان — تداخل النقل سطحي. MCP يستخدم HTTP لاستدعاءات الأدوات (طلب ← استجابة) ويتحول من SSE إلى Streamable HTTP للإشعارات التي يبدأها الخادم. A2A يستخدم JSON-RPC 2.0 عبر HTTP لتوزيع المهام و SSE لمخرجات المهام المتدفقة. النقل هو سباكة؛ دلالات البروتوكول مختلفة. MCP يحمل استدعاءات الأدوات. A2A يحمل دورات حياة المهام. يمكنك تشغيل كليهما عبر نفس البوابة — التنفيذ المرجعي يفعل ذلك بالضبط، حيث تتعامل البوابة مع HTTP و SSE لكلا البروتوكولين بينما تترجم طبقة الجسر إلى API الأصلي لكل إطار عمل.

ما يعنيه هذا لبنيتك

إذا كنت تبني نظام وكلاء B2B — أتمتة RFQ، سير عمل المشتريات، دعم العملاء مع رسوم بيانية معرفية، تنسيق خطوط بيانات — قرار البروتوكول يتبع شكل سير العمل:

• وكيل واحد، مصادر بيانات متعددة ← MCP فقط. الوكيل يستخدم وحدات MCP للاتصال بـ NetSuite، HubSpot، BigCommerce، وكتالوجات الموردين. A2A غير مطلوب.
• وكلاء متعددون، نفس المالك، نفس البنية التحتية ← MCP للأدوات، تنسيق على مستوى التطبيق للعمل بين الوكلاء. اعتبر A2A إذا أصبح منطق التنسيق معقداً بما يكفي لتبسيطه آلة حالة على مستوى البروتوكول.
• وكلاء متعددون، ملاك مختلفون أو بنية تحتية مختلفة ← A2A للتفويض بين الوكلاء، MCP لوصول كل وكيل إلى الأدوات. هذا هو النمط الإنتاجي لأنظمة الوكلاء الموزعة.
• مهام طويلة الأمد مع بوابات موافقة بشرية ← A2A لدورة حياة المهمة وحالة INPUT_REQUIRED، MCP لاستدعاءات الأدوات داخل كل مهمة. بوابة الموافقة تعبر حدود الوكلاء كانتقال حالة A2A، لا ككود تطبيق مخصص.

تأكيد OpenAI لـ Astra في 1 أغسطس يجعل نمط الوكلاء المتعددين طويل الأمد اتجاه تصميم النموذج الحدودي. Astra مبني لمهام تعمل على مشاكل لساعات أو أيام، منسقاً وكلاء متعددين على فترات ممتدة. رصة البروتوكول التي تدعم هذا النمط هي A2A للتنسيق و MCP لوصول الأدوات — بنية البروتوكولين التي تصفها هذه المقالة.

---

موزع متوسط الحجم يحتاج وكيل تسعير يتحدث مع وكيل كتالوج يتحدث مع وكيل امتثال — كل واحد مدعوم بنموذج مختلف، كل واحد مملوك لفريق مختلف، كل واحد يتصل بأنظمة مختلفة عبر وحدات MCP. A2A يعطي هؤلاء الوكلاء بروتوكول مشترك للتفويض والتدفق. MCP يعطي كل وكيل وصولاً محوكماً لمصادر بياناته. نمط الجسر يتيح لـ Hermes Agent، OpenClaw، وأي إطار عمل آخر المشاركة في شبكة A2A دون إعادة كتابة internals الخاصة بهم.

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

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