Agent2Agent vs MCP: The 2 Protocols Your 2026 AI Agent Stack Actually Runs On

يعد ربط العميل الذكي بأداة ما مشكلة محلولة بالفعل. ولكن ربط عميل ذكي بآخر، تم تطويره من قِبل جهة تزويد مختلفة وعلى نموذج مختلف، لم يكن محلولاً حتى هذا العام. ويقوم بروتوكولان الآن بتقسيم هذا العمل: Model Context Protocol (MCP)، الذي أصدرته شركة Anthropic في نوفمبر 2024 لتوحيد كيفية وصول العميل الذكي إلى الأدوات والبيانات، وبروتوكول Agent2Agent (A2A)، الذي قدمته Google في أبريل 2025 وتبرعت به لمؤسسة Linux Foundation في منتصف عام 2025. وتجاوزت الجهات الداعمة لـ A2A ما يزيد عن 150 مؤسسة ووصل إلى مرحلة الاعتماد لدى الشركات من الفئة التشغيلية بحلول أبريل 2026، وذلك وفقاً لـ Linux Foundation. ولا تزال معظم الشركات تتعامل مع الاثنين كمعيارين متنافسين. لكنهما ليسا كذلك؛ بل إنهما يقعان في طبقات مختلفة من البنية التكنولوجية، ويتطلب النشر الجاد للعملاء الأذكياء تشغيلهما معاً.

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

لماذا لا يمكن لبروتوكول MCP جعل عميلين ذكيين يتحدثان معاً

يحل MCP مشكلة رأسية: وصول عميل ذكي واحد إلى الأنظمة التي يحتاجها. وتصفه Anthropic بأنه "معيار جديد لربط مساعدي الذكاء الاصطناعي بالأنظمة التي توجد بها البيانات، بما في ذلك مستودعات المحتوى، وأدوات الأعمال، وبيئات التطوير". فكر فيه كالتوصيلات السلكية بين عميل ذكي واحد وأطرافه: نظام إدارة علاقات العملاء (CRM)، وقاعدة بيانات، ومساحة عمل Slack، وواجهة برمجة تطبيقات (API) داخلية. البنية هي عميل-خادم عبر JSON-RPC، حيث يكشف خادم MCP عن مجموعة محددة من الأدوات، والموارد، والمطالبات التي يمكن لأي عميل متوافق استدعاؤها.

كان ذلك التوحيد مهماً لأن البديل كان عبارة عن كود تكامل مخصص لكل اقتران بين أداة ونموذج. وقبل وجود MCP، كان ربط خمسة عملاء أذكياء بعشرة أدوات يعني ما يصل إلى خمسين عملية تكامل مخصصة، وكان كل منها يمثل عبئاً في الصيانة. لكن MCP قام باختزال كل ذلك في واجهة واحدة. وبحلول منتصف عام 2025، كان المجتمع قد بنى الآلاف من خوادم MCP النشطة، واعتمدت كل من OpenAI وMicrosoft وGoogle DeepMind هذا البروتوكول. وأصبح MCP الآن هو الطريقة الفعلية التي يقرأ بها العملاء الأذكياء الملفات، ويستدعون الوظائف، ويسحبون السياق، مع خوادم مبنية مسبقاً لأنظمة مثل Google Drive وGitHub وPostgres وSlack.

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

ما الذي تغير عندما وصل A2A إلى الفئة التشغيلية

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

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

وبحلول الذكرى السنوية الأولى له في أبريل 2026، أبلغت مؤسسة Linux Foundation عن عمليات نشر نشطة في بيئات العمل ضمن سلاسل التوريد، والخدمات المالية، والتأمين، وعمليات تكنولوجيا المعلومات، مع دمج A2A في Microsoft Azure AI Foundry وCopilot Studio، وAWS Bedrock AgentCore، وGoogle Cloud. نتحدث هنا عن عمليات نشر تشغيلية فعلية، وليس مجرد مشاريع تجريبية. وهذا التمييز هو جوهر الموضوع بأكمله. فقد قضى A2A أشهره الأولى كأداة واعدة مدعومة من سبعة شركاء مؤسسين (Amazon Web Services، وCisco، وGoogle، وMicrosoft، وSalesforce، وSAP، وServiceNow). ويدخل عامه الثاني كبنية أساسية توجه الشركات الأموال الحقيقية من خلالها، وهو بالضبط الحد الذي يتوقف عنده البروتوكول عن كونه مجرد فضول بحثي ويبدأ في كونه قرار شراء فعلي للمؤسسات.

مقارنة مباشرة: MCP مقابل A2A

الطريقة الأوضح لاستيعاب الفرق هي المقارنة المباشرة بينهما.

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

ستحتاج إلى كلاهما، وفي وقت أقرب مما تشير إليه خريطة الطريق

السبب في أن هذا الموضوع قد تجاوز الجانب النظري هو وتيرة الاعتماد المتسارعة. وتتوقع Gartner أن تشتمل 40% من تطبيقات الشركات على عملاء ذكاء اصطناعي مخصصين لمهام محددة بحلول نهاية عام 2026، مقارنة بأقل من 5% في عام 2025 (Gartner، أغسطس 2025). هذه قفزة بمقدار ثمانية أضعاف في عام واحد، وهي أسرع من منحنى الاعتماد المبكر للحوسبة السحابية أو الهواتف المحمولة.

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

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

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

ما لا يحله أي من البروتوكولين: الطبقة التي تفشل المشاريع بسببها فعلياً

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

وتوجد ثلاث فجوات تقع فوق طبقة البروتوكول، وهي بالضبط الفجوات التي تتسبب في فشل المشاريع:

• الحوكمة والسياسة. يحدد A2A كيفية تبادل الرسائل بين العملاء الأذكياء، ولكنه لا يحدد ما إذا كان يُسمح لعميل المالية لديك بالموافقة على دفعة بقيمة 2 مليون دولار دون تدخل بشري، أو أي من العملاء يمكنه استدعاء الآخر. هذه السياسة تعيش فوق خط الاتصال، ولن يكتبها لك أي بروتوكول.

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

• الهوية والمصادقة عبر العملاء الأذكياء. تتحقق بطاقات العملاء الموقعة من أن العميل هو من يدعي أنه هو، لكنها لا تدير ما يُسمح لهذا العميل بالقيام به نيابة عن أي إنسان، وبأي صلاحيات واعتمادات، وتحت أي سجل تدقيق. إن الهوية والتفويض وإلغاء الصلاحيات عبر مختلف العملاء هي تخصص بحد ذاته، وهي النقطة التي تتعطل عندها مراجعات الأمان عادة.

هذا ليس مصدر قلق هامشي؛ حيث تتوقع Gartner إلغاء أكثر من 40% من مشاريع الذكاء الاصطناعي القائم على العملاء الأذكياء بحلول نهاية عام 2027، مرجعة ذلك إلى تصاعد التكاليف، وعدم وضوح القيمة المضافة للأعمال، وضوابط المخاطر غير الكافية (Gartner، يونيو 2025). وتعد "ضوابط المخاطر غير الكافية" إشارة مباشرة إلى طبقة الحوكمة. فالمشاريع لا تفشل بسبب عدم قدرة العملاء على الاتصال، بل تفشل لأنه لم يتمكن أحد من حوكمة هؤلاء العملاء، أو مراقبتهم، أو تأمينهم بمجرد اتصالهم. إن مشكلة الاتصال تمثل الـ 20% السهلة، بينما تمثل مشكلة التحكم الـ 80% التي تقرر ما إذا كان المشروع سينجو من التدقيق الأول له أم لا.

أين تقع طبقة التنسيق والتكامل

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

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

القراءة الصادقة لأي رئيس تنفيذي للتكنولوجيا (CTO) يخطط لبناء بنية عملاء أذكياء لعام 2026 هي كالتالي: اعتمد MCP، لأن عملائك يحتاجون إلى طريقة موحدة للوصول إلى الأدوات، وقد اتفقت بالفعل Anthropic وOpenAI وGoogle عليه. واعتمد A2A، لأن عملائك سيحتاجون إلى العمل مع عملاء لم تقم أنت ببنائهم، وتتولى Linux Foundation الآن الإشراف على المعيار الذي يتيح لهم ذلك. ثم وجه جهدك الحقيقي نحو الطبقة التي تعلوهما معاً؛ فهذه هي الطبقة التي تميز بين تشغيل ناجح للعملاء الأذكياء وآخر ينضم إلى نسبة الـ 40% التي تتوقع Gartner إلغاءها، وهي الطبقة الوحيدة التي لا يزال العمل فيها بيدك بالكامل لإنجازه بالشكل الصحيح.