- تعمل MCP على توحيد كيفية اكتشاف وكلاء الذكاء الاصطناعي للأدوات والموارد والمطالبات واستدعائها، وفصل الوكلاء عن واجهات برمجة التطبيقات الملموسة.
- تحدد A2A كيفية اكتشاف الوكلاء المستقلين لبعضهم البعض، وتبادل المهام، ومشاركة البيانات عبر HTTP و JSON-RPC.
- إن الجمع بين MCP للوصول إلى الأدوات و A2A للتعاون بين الوكلاء يتيح بنى متعددة الوكلاء قابلة للتوسع عبر الفرق والموردين.
- إن تطبيق هذه التقنيات في العالم الحقيقي يثير تحديات جديدة في التصميم السريع، والأمن، وتوحيد الهوية، والحوكمة، والتي يجب على الأطر والبوابات معالجتها.
لم تعد برامج الذكاء الاصطناعي مجرد روبوتات دردشة متطورة تجيب على الأسئلة في نافذة واحدة. إنها تتحول إلى أنظمة موزعة قادرة على قراءة وكتابة التعليمات البرمجية، واستدعاء واجهات برمجة التطبيقات، والتنسيق مع خدمات أخرى، بل والتفاوض مع وكلاء آخرين لإنجاز العمل. بمجرد الانتقال من "مساعد ذكي واحد" إلى "شبكة من الوكلاء"، تبرز مشكلة جوهرية: كيف تتواصل كل هذه الأجزاء مع بعضها البعض دون الوقوع في الفوضى؟
هذه هي بالضبط الفجوة التي يحاول بروتوكول MCP (بروتوكول سياق النموذج) وبروتوكول A2A (بروتوكول من وكيل إلى وكيل) سدها. يركز نموذج MCP على كيفية اتصال الوكيل بالأدوات والبيانات والسياق، بينما يركز نموذج A2A على كيفية تواصل الوكلاء وتعاونهم فيما بينهم. يتشابه النموذجان في المبدأ، لكنهما يعملان على مستويات مختلفة. في هذه المقالة، سنتعمق في وظيفة كل منهما، وكيف يكمل كل منهما الآخر، وكيف يُستخدمان بالفعل في الأنظمة الحقيقية، وماذا يعني ذلك لمستقبل أدوات البرمجة وهياكل الوكلاء المتعددين.
ما هو برنامج MCP في الواقع العملي؟
في جوهرها، تعد MCP طريقة قياسية لعرض الأدوات والموارد والمطالبات لوكيل الذكاء الاصطناعي حتى يتمكن الوكيل من استدعائها بأمان وبشكل متسق. بدلاً من توصيل كل أداة مباشرة بكل وكيل باستخدام رمز ربط مخصص، فإنك تعرض تلك الأدوات خلف خادم MCP، وتسمح لعملاء MCP (الوكلاء) باكتشافها واستدعائها من خلال بروتوكول موحد.
تتبع MCP بنية واضحة للعميل والخادم: يقوم تطبيق مضيف (مثل محرر نصوص أو واجهة سطر أوامر أو بيئة تشغيل وكيل) بتضمين عميل MCP، ويفتح هذا العميل اتصالات مباشرة مع خادم MCP واحد أو أكثر. كل خادم عبارة عن عملية خفيفة الوزن تعرض مجموعة من الإمكانيات - عادةً أدوات وموارد للقراءة فقط ومطالبات قابلة لإعادة الاستخدام.
إن الإلهام قريب جدًا من بروتوكول خادم اللغة (LSP). لقد بسط بروتوكول LSP مشكلة "المحرر ↔ ميزات اللغة" بحيث لم نكن بحاجة إلى كتابة عمليات تكامل مخصصة بين كل محرر وكل لغة برمجة. فإذا قمت بتنفيذ خادم لغة مرة واحدة، يمكن لأي محرر متوافق مع LSP التواصل معه. ويأخذ بروتوكول MCP الفكرة نفسها ويطبقها على الأدوات والسياق الخاص بـ LLMs: قم بتنفيذ أداة مرة واحدة كخادم MCP، ويمكن لأي وكيل مُدرك لبروتوكول MCP استخدامها.
من وجهة نظر النقل، فإن نظام MCP مرن ولكنه يتمتع برؤية واضحة بما يكفي ليكون عمليًا. يستخدم هذا البروتوكول JSON-RPC 2.0 كصيغة للرسائل، ويدعم عدة وسائل نقل: الإدخال/الإخراج القياسي للعمليات المحلية (مثالي لتطبيقات سطح المكتب والتطوير المحلي)، وHTTP أو SSE للخوادم البعيدة (مثالي لـ Cloud Run أو عمليات النشر المعبأة في حاويات). كما يحدد البروتوكول كيفية اكتشاف العميل للإمكانيات وكيفية وصف الأدوات باستخدام مخطط JSON، بحيث يمكن لـ LLM تحديد متى وكيف يتم استدعاؤها.
الأهم من ذلك، أن MCP لا يحاول توجيه تفكير وكيلك. لا يقرر متى ينبغي استدعاء أداة ما، أو كيفية ربط الأدوات ببعضها. MCP هي طبقة الربط: فهي توفر الأدوات والموارد والمطالبات بطريقة منظمة وقابلة للاكتشاف، تاركةً عملية اتخاذ القرار لإطار عمل الوكيل أو المخطط أو هندسة المطالبات.
المكونات الأساسية لبرنامج إدارة المحتوى: الأدوات والموارد والموجهات
تتمحور خوادم MCP حول ثلاثة عناصر أساسية: الأدوات والموارد والمطالبات. تكفي هذه المفاهيم الثلاثة لتغطية معظم احتياجات الوكلاء في العالم الحقيقي دون تحويل البروتوكول إلى إطار عمل كامل للتنسيق.
الأدوات عبارة عن إجراءات منفصلة يمكن للوكيل تشغيلها. يفكر "get_weather"،"search_inventory"،"book_flight"،"run_sql_query"أو"get_exchange_rateيتم تعريف كل أداة باسم ووصف سهل القراءة ومخطط إدخال. هذا المخطط هو ما يسمح لـ LLM بفهم المعلمات التي يجب تمريرها، كما أنه يحمي نظامك الخلفي من خلال التحقق من صحة الوسائط قبل التنفيذ.
تمثل الموارد بيانات للقراءة فقط يمكن للخادم تقديمها عند الطلب. الملفات، والسجلات، وصفوف قواعد البيانات، ومقتطفات التوثيق، وملفات الإعدادات – أي معلومة يُفضل نمذجتها على أنها "جلب هذا الشيء" بدلاً من "تشغيل هذه الدالة". قد تكون الموارد كبيرة، لذا يُحدد MCP طرقًا لتقسيمها إلى صفحات وبثها، وهو أمر بالغ الأهمية عند إدخال سياق إلى نموذج ذي نافذة محدودة.
تُعدّ المطالبات قوالب قابلة لإعادة الاستخدام يمكن للخوادم عرضها للعملاء. بدلاً من تضمين سلاسل نصية طويلة وهشة داخل برنامجك، يمكنك مركزتها كرسائل MCP. يعرض الخادم هذه الرسائل مع أسمائها وأوصافها وقيم المعلمات، ويقوم البرنامج بتعبئة هذه القيم أثناء التشغيل. هذه الطريقة فعّالة للغاية عندما يحتاج العديد من البرامج إلى مشاركة نفس أنماط التواصل مع أداة معينة أو اتباع قواعد السلامة والامتثال على مستوى الشركة.
عندما يتصل عميل بخادم، فإنه يقوم بخطوة اكتشاف القدرات. يستجيب الخادم بقائمة من الأدوات والموارد والمطالبات، كل منها مزود ببيانات وصفية مفصلة. ثم تُغذى هذه القائمة إلى نموذج التعلم الموجه بالتعلم (عادةً في شكل مُلخص) حتى يتمكن النموذج من الاستدلال: "يمكنني استخدام get_exchange_rate للإجابة على هذا السؤال المتعلق بتحويل العملات، ولا ينبغي لي محاولة اختلاق الإجابة.
ولأن كل هذا تصريحي، يمكن إضافة قدرات جديدة أو إزالتها دون المساس بالمنطق الأساسي للوكيل. أضف أداة جديدة إلى الخادم، وأعد نشرها، وسيتمكن كل عميل MCP يتصل بها من رؤيتها عند التفاوض التالي على الإمكانيات. هذه هي لحظة "توصيل جهاز USB إضافي" لأدوات الذكاء الاصطناعي.
مثال عملي على برنامج إدارة دورة حياة المنتج: أداة تحويل العملات
يُعد عرض توضيحي لوكيل العملة من مجموعة أدوات تطوير الوكلاء (ADK) من جوجل مثالاً مثالياً على MCP أثناء العمل. يبدأ الأمر ببناء خادم MCP صغير يعرض أداة واحدة، get_exchange_rateمدعومًا بواجهة برمجة تطبيقات فرانكفورتر العامة. على القرص، هو مجرد برنامج بايثون صغير يستخدم fastmcp.
يُعرّف الخادم الأداة باستخدام وسائط مُحددة النوع لـ currency_from, currency_to و currency_dateبالإضافة إلى تسجيل قوي ومعالجة الأخطاء. عندما يستدعي الوكيل هذه الوظيفة، يتصل الخادم بفرانكفورتر عبر بروتوكول HTTP، ويتحقق من صحة الاستجابة، ثم يُعيد حمولة JSON تحتوي على سعر الصرف أو كائن خطأ. لا يوجد في هذا أي شيء خاص بالذكاء الاصطناعي؛ فـ MCP تُوحّد فقط كيفية وصف هذه الوظيفة واستدعائها.
محليًا، يمكنك تشغيل الخادم بأمر بسيط، وهو يستمع على http://localhost:8080. يتصل عميل اختبار منفصل، يستخدم أيضًا بروتوكول MCP، ويكتشف get_exchange_rate ويؤدي ذلك إلى استدعاء لتحويل الدولار الأمريكي إلى اليورو. يُظهر سجل النظام استدعاء الأداة، وطلب HTTP الصادر، والاستجابة الناجحة، وبيانات JSON المُعادة. من وجهة نظر وكيلك، فقد سأل ببساطة "ما الأدوات المتوفرة لدي؟" ثم "يرجى استدعاء هذه الأداة".
إن نشر نفس الخادم على Cloud Run لا يغير الوضع كثيراً. يمكنك تحويل خادم MCP إلى حاوية، ثم نشره باستخدام --no-allow-unauthenticated لذا يتطلب الأمر مصادقة مدعومة من IAM، ثم فتح نفق آمن من جهازك المحلي باستخدام أمر وكيل Cloud Run. محليًا، لا يزال عميل MCP الخاص بك يعتقد أنه يتصل بـ http://127.0.0.1:8080; يقوم الخادم الوكيل بمعالجة المصادقة وعمليات نقل البيانات عبر الشبكة بشفافية.
يُعد هذا النمط فعالاً في الفرق: يمكنك تشغيل خادم MCP مركزي للأدوات المشتركة مثل أسعار العملات، وواجهات برمجة التطبيقات الداخلية، أو قواعد البيانات الخاصة. يمكن لكل وكيل مطور في المؤسسة الاتصال بهذا الخادم عبر وسيلة نقل آمنة بدلاً من شحن غلاف خاص به مختلف قليلاً وغير مكتمل الصيانة حول نفس واجهة برمجة التطبيقات.
بناء وكلاء على منصة MCP: من الأدوات الفردية إلى سير العمل الكامل
يصبح MCP مثيرًا للاهتمام حقًا عندما تقوم بتضمينه في إطار عمل وكيل مثل ADK من Google. في مثال وكيل العملات، تُستخدم مجموعة أدوات تطوير التطبيقات (ADK) لإنشاء وكيل متخصص في إدارة دورة حياة التطبيقات (LLM) تقتصر مهمته على الإجابة عن أسئلة حول أسعار الصرف باستخدام أداة MCP. وتُخبر تعليمات النظام الخاصة بالوكيل حرفيًا: "هدفكم الوحيد هو استخدام..." get_exchange_rate أداة".
يقوم برنامج ADK بتوصيل هذه التعليمات، والنموذج المختار (على سبيل المثال gemini-2.5-flash) و MCPToolset مثال يشير إلى عنوان URL لخادم MCP. منذ ذلك الحين، عندما يسأل المستخدم "كم يساوي 250 دولار كندي بالدولار الأمريكي؟"، يقوم الوكيل بالتفكير فيما إذا كان يحتاج إلى استدعاء أداة، ويملأ معلمات الأداة، ويرسل الطلب من خلال MCP، ثم يكتب استجابة سهلة الاستخدام باستخدام JSON المُعاد.
وينطبق النمط نفسه على عوامل أكثر تعقيداً بكثير. بدلاً من واجهة برمجة تطبيقات عملة واحدة، يمكنك ربط عدة خوادم: خادم لقواعد البيانات الداخلية، وآخر لبرامج SaaS الخارجية، وثالث للبحث عن المستندات، بالإضافة إلى خادم يعرض مطالبات قابلة لإعادة الاستخدام أو مسارات RAG. لا يهم MCP ما إذا كانت هذه الخوادم تعمل محليًا، أو على Cloud Run، أو في Kubernetes، أو خلف شبكة VPN، طالما أن النقل مدعوم والمصادقة مُهيأة بشكل صحيح.
كما يضيف ADK منظورًا يركز على الوكيل أولاً، وهو ما يتجنبه MCP عمدًا. يتعامل هذا النظام مع الوكلاء كمكونات برمجية قابلة للتكوين: يمكنك تعريف وكلاء قائمين على لغة إدارة التعلم، ووكلاء يعتمدون على أدوات متقدمة، ووكلاء تقييم، ومنسقين، جميعهم قادرون على استخدام لغة MCP مباشرةً. والنتيجة هي أن عملية "بناء وكيل" تصبح أقرب إلى "بناء خدمة مصغرة" وأقل شبهاً بـ"تعديل موجه أوامر لا نهائي في دفتر ملاحظات".
ما هو A2A؟ ولماذا لا يكفي MCP وحده؟
إذا كان MCP يتعلق بتوصيل العوامل بالأدوات، فإن A2A يتعلق بتوصيل العوامل بعوامل أخرى. بمجرد وجود عدة وكلاء يتقن كل منهم مهمة معينة، ستحتاج إلى وسيلة تمكنهم من التواصل وتبادل المهام والحفاظ على التنسيق أثناء سير العمل. هذا هو المجال الذي صُممت منصة A2A لحله.
A2A، الذي أطلقته Google Cloud وهو الآن تحت مظلة مؤسسة Linux، هو معيار مفتوح للتوافق بين الوكلاء. يستخدم هذا النظام تقنيات مألوفة (HTTP(S) وJSON-RPC 2.0 وSSE للبث المباشر)، ولكنه يغلّفها بنموذج مجال يفهم الوكلاء والمهارات والمهام والمنتجات والقدرات. وبدلاً من "استدعاءات الأدوات"، ستحصل على لغة تعاون عالية المستوى.
تتمحور فكرتا A2A الأساسيتان حول بطاقات الوكلاء والمهام. بطاقة الوكيل هي مستند JSON - يمكن العثور عليها عادةً على /.well-known/agent.json يصف ذلك ما يمكن أن يفعله الوكيل، وكيفية الوصول إليه، ونوع المصادقة التي يتطلبها، وأنماط الإدخال/الإخراج التي يدعمها. المهام هي وحدات العمل التي يمكن لوكيل إرسالها إلى آخر، ولها دورة حياة محددة جيدًا ونتائج منظمة.
في تفاعل A2A، يتولى أحد الوكلاء دور "وكيل العميل" بينما يعمل الآخر كـ "وكيل بعيد". يكتشف العميل بطاقة الوكيل البعيد، ويقرر ما إذا كان هذا هو الشريك المناسب للمهمة، ثم يُنشئ طلب مهمة. يستلم الوكيل البعيد المهمة، ويستخدم نظام إدارة التعلم الخاص به وأدواته الداخلية (غالبًا عبر منصة إدارة المحتوى) لتنفيذها، ثم يُرسل تحديثات التقدم والنتائج النهائية.
هذا التصميم يجعل A2A بطبيعته اتصالاً من نقطة إلى نقطة، وغير متزامن، ومتوافقاً مع الشبكة. تعتمد تطبيقات بايثون داخليًا على أطر عمل ASGI مثل Starlette (عبر A2AStarletteApplication) و uvicorn، مع تدفق البيانات وتحديثات المهام عبر JSON-RPC و SSE. هذا يعني أن المهام يمكن أن تعمل لثوانٍ أو ساعات دون حظر أي طلب HTTP، وهو أمر ضروري لسير العمل متعدد الوكلاء في العالم الحقيقي.
مثال على نموذج A2A: عرض وكيل "مرحباً" وما بعده
يُظهر نموذج A2A "HelloWorldAgent" الآليات بشكل مبسط. أنت تحدد AgentExecutor فئة فرعية تُنفذ execute في هذه الطريقة، تقوم بإضافة رسالة نصية واحدة - "مرحباً من A2A!" - إلى قائمة الأحداث كنتيجة للمهمة. يصبح الإلغاء غير فعال في هذه الحالة البسيطة، ولكن هذه الآلية موجودة لأحمال العمل الحقيقية.
بعد ذلك تقوم بإنشاء AgentSkill وصف ما يمكن لهذا الوكيل فعله. في المثال، المهارة hello يحمل اسمًا ووصفًا ومجموعة من العلامات واستعلامات المستخدم التمثيلية. ثم يتم تجميع هذه المهارة في AgentCard بالإضافة إلى اسم الوكيل وإصداره وعنوان URL الخاص به وقدراته وأنماط الإدخال/الإخراج المدعومة.
وأخيرًا، تقوم بتوصيل كل شيء بـ A2AStarletteApplication مع DefaultRequestHandler وقم بتشغيله باستخدام برنامج uvicorn. أما بالنسبة للعالم الخارجي، فلديك الآن وكيل A2A كامل الأهلية يستمع إليك http://localhost:9000يمكن لأي عميل يدعم A2A جلب البيانات /.well-known/agent.json، افهم ما يقدمه هذا الوكيل، وأرسل إليه المهام.
في عمليات النشر الأكثر واقعية، يتوسع النمط نفسه ليشمل سيناريوهات التنسيق مثل حجز السفر أو الإعداد أو أتمتة الدعم. قد يكتشف "وكيل السفر" ويتواصل مع "وكيل رحلات طيران" و"وكيل فنادق" و"وكيل تأجير سيارات"، حيث يعمل كل منهم من خلال نقطة نهاية A2A خاصة به، ويخفي أدواته الداخلية وعقود واجهة برمجة التطبيقات الخاصة بمورديه. ولا يرى وكيل السفر سوى المهام والمهارات والبيانات.
وهنا يبرز دور مبدأ فصل الاهتمامات في نظام A2A. يمكن لكل وكيل في المراحل اللاحقة اختيار نماذجه وأطره وأدواته الخاصة - وكيل فندق مبني باستخدام ADK و MCP، ووكيل طيران مبني باستخدام مجموعة أدوات أخرى، ووكيل تأجير سيارات موجود في البنية التحتية للشريك - ومع ذلك لا يزال بإمكان الجميع التعاون بسلاسة من خلال واجهة A2A.
دمج MCP و A2A في بنية واحدة
على الورق، يبدو التقسيم أنيقًا - MCP للأدوات، وA2A للوكلاء - ولكن في الواقع العملي تتلاشى الحدود بسرعة. غالباً ما تسعى الأنظمة الحقيقية إلى إخفاء بروتوكول A2A خلف بروتوكول MCP، أو دمج بروتوكول MCP داخل بروتوكول A2A، أو الجمع بينهما في نفس العملية. بل إن نماذج A2A الرسمية تغلف اتصال A2A كأدوات MCP مُتاحة من خادم واحد، بحيث يرى نظام إدارة دورة حياة التطبيق (LLM) "مجموعة أدوات MCP واحدة" بدلاً من مجموعتي بروتوكولات متوازيتين.
يتمثل أحد الأنماط الشائعة في التعامل مع MCP على أنه الأسلاك الداخلية لكل وكيل و A2A على أنها الشبكة الخارجية بين الوكلاء. داخل الوكيل، يستدعي نظام إدارة دورة حياة التطبيق (LLM) أدوات إدارة دورة حياة التطبيق (MCP) للوصول إلى قواعد البيانات أو واجهات برمجة التطبيقات أو مخازن المستندات. أما خارجه، فيتواصل نظام التنسيق مع هذا الوكيل عبر بروتوكول A2A، حيث يُسند إليه المهام ويقرأ البيانات المُسترجعة. من وجهة نظر نظام التنسيق، يُعد الوكيل خدمةً مُغلقة ذات واجهة بسيطة وواضحة.
أما النمط العكسي - وهو إبراز A2A كأدوات MCP - فهو جذاب من وجهة نظر التكامل. يمتلك العديد من مزودي خدمات إدارة دورة حياة التطبيقات (LLM) أدوات متطورة لدعم منصة إدارة التطبيقات (MCP): أدوات تطوير، وعروض توضيحية لواجهة المستخدم، ومجموعات تطوير برمجية (SDKs)، وأدلة أمنية. من خلال توفير خيار "الاتصال بالوكيل البعيد X" كأداة MCP واحدة، يمكنك تمكين LLM من بدء تفاعل A2A بأقل قدر من الإعدادات. يكفي تسجيل خادم MCP واحد، ولكن في الخلفية، يمكن لهذا الخادم إدارة المهام عبر شبكة A2A بأكملها.
وهذا بالضبط ما توضحه بعض مستودعات الأمثلة: بدلاً من توصيل كل وكيل A2A عن بعد مباشرة بالنموذج، يوفر خادم MCP مجموعة مضغوطة من الأدوات التي تتحدث A2A بنفسها. هذا يكسر النموذج الذهني الساذج ("يجب أن يكون MCP و A2A منفصلين تمامًا") ولكنه يبسط التكامل العملي بشكل كبير ويحافظ على سطح واجهة LLM الخاص بك صغيرًا ومنسقًا بشكل جيد.
كما لا يوجد ما يمنعك من استخدام MCP و A2A بشكل منفصل حيثما يكون ذلك منطقياً. لن تحتاج العديد من المشاريع إلا إلى بروتوكول MCP لربط وكيل واحد بعدد محدود من الأدوات. بينما ستعتمد مشاريع أخرى، خاصةً عند ربط الموردين أو الفرق الداخلية، بشكل كبير على بروتوكول A2A للتنسيق بين مختلف أقسام المؤسسة، مع استخدام بنيتها التحتية الداخلية بدلاً من MCP. والأهم من ذلك، أن هذه البروتوكولات لا تتنافس، بل تُكمّل بعضها بعضاً.
قابلية التشغيل البيني، والأطر، و"الهيكل الكبير" المفقود
لا تضمن البروتوكولات وحدها إمكانية التشغيل البيني إذا قام الجميع بتضمينها في بنى تحتية عالية المستوى مختلفة تمامًا. يمكنك التحدث بطلاقة تامة عن MCP و A2A ومع ذلك ينتهي بك الأمر بمجموعة كبيرة من أنماط الوكلاء غير المتوافقة فيما بينها والتي يعيد كل منها ابتكار التخطيط والذاكرة ومعالجة الأخطاء والحوكمة.
الخطوة التالية المحتملة في النظام البيئي هي طبقة من الأطر المبنية على MCP و A2A والتي تعمل على توحيد ليس فقط الأسلاك، ولكن الهيكل الأكبر. فكّر في كيفية ظهور أطر عمل الويب بالاعتماد على بروتوكول HTTP، أو كيفية بناء أنظمة إدارة قواعد البيانات العلائقية (ORMs) بالاعتماد على لغة SQL. بدأنا نرى هذا مع ADK، ومنسقات مثل LangGraph، والمنصات المُدارة مثل Vertex AI Agent Engine، وبوابات الذكاء الاصطناعي التي تفهم كلا البروتوكولين.
بمجرد أن تتقارب الصناعة على عدد قليل من الأنماط العملية - "هذه هي الطريقة التي تقوم بها بتنظيم سير عمل متعدد الوكلاء عبر A2A وMCP"، "هذه هي الطريقة التي تعرض بها أدوات الفرق خلف MCP" - سيبدأ القلق بشأن ما إذا كان ينبغي أن يكون شيء ما خلف MCP أو A2A في التلاشي. معظم المطورين سيختارون إطار عمل، ويقومون بتوصيل خادم أو اثنين، ويحصلون على إعدادات افتراضية معقولة.
المشكلة الأكثر تعقيداً وبطئاً هي الهندسة السريعة والتوافق التشغيلي السريع. حتى مع وجود بروتوكولات مثالية، فإن ربط الأنظمة عبر بروتوكولي MCP وA2A يسمح فعلياً بتسريب وتداخل التعليمات البرمجية العشوائية - كتعليمات النظام، ووصف الأدوات، وإرشادات الأمان - عبر الحدود. إذا كانت هذه التعليمات غير متوافقة، أو زائدة عن الحاجة، أو متناقضة تماماً، فسيتأثر أداء النظام سلباً قبل ظهور أي مخاوف أمنية.
من الناحية العملية، يمكن أن تؤدي التعليمات والإرشادات المصممة بشكل سيئ عبر مجموعة MCP + A2A إلى زمن استجابة هائل وهلوسة وعدم استقرار. قد يكون كل وكيل مُهيأً بشكل جيد محليًا، ولكن عند دمجهم، قد تصبح مسارات العمل غير سلسة: حيث تُعطى الأدوات أولويات خاطئة، وتُهدر فترات السياق، وتُخالف توقعات المستخدمين. يمكن لـ A2A تنسيق المهام، ويمكن لـ MCP عرض الأدوات، لكن لا يُلزمك أي منهما بالحفاظ على اتساق التوجيهات.
ولهذا السبب تميل الفرق التي قامت بالفعل بشحن منتجات LLM على نطاق واسع إلى التعامل مع الهندسة السريعة على أنها مصدر قلق هندسي من الدرجة الأولى، وليست تعديلاً في اللحظة الأخيرة. غالباً ما ينظر أصحاب المصلحة في الأعمال إلى التنبيهات على أنها حل سحري لكل شيء؛ بينما يتجاهلها المهندسون أحياناً باعتبارها تفصيلاً ثانوياً مقارنةً بالبرمجة. لكن الحقيقة تكمن في الوسط: فالتنبيهات لن تُحسّن نظاماً سيئاً، ولكن التنبيهات غير المُتقنة قد تُدمر بنيةً متينةً تماماً.
الأمن والهوية والحوكمة عبر MCP و A2A
بمجرد أن تبدأ في السماح للوكلاء بالتصرف نيابة عن البشر عبر حدود MCP و A2A، تصبح الهوية والتفويض بسرعة من المشاكل المركزية. قد يمر طلب واحد عبر عدة طبقات من التفويض: يتحدث المستخدم إلى وكيل التنسيق، الذي يستدعي أداة عبر MCP، والتي تستدعي داخليًا خوادم MCP أخرى أو وكلاء A2A الذين يتطلبون بيانات اعتماد منفصلة.
تظهر سيناريوهات ملموسة في كل مكان: يُعرّض تطبيق SaaS خادم MCP الذي يتطلب رموز OAuth؛ ويستهلك وكيل الموارد البشرية الداخلي، الذي يعمل خلف نظام A2A، هويات LDAP الخاصة بالشركة؛ وتستخدم أداة تحليلات خارجية نظام تسجيل دخول موحد خاص بها. يتوقع المستخدم تسجيل الدخول مرة واحدة وإنجاز المهام، ولكن في الواقع، يجب ربط أنظمة هوية متعددة.
تشير وثائق جوجل الخاصة بـ A2A صراحةً إلى اتحاد الهويات المتعددة باعتباره تحديًا أساسيًا. قد يتفاعل المستخدم U مع الوكيل A الذي يتطلب هوية النظام A (مثلاً، LDAP المؤسسي)، بينما يحتاج الوكيل A داخلياً إلى تفويض المهمة إلى الوكيل B الذي يتطلب هوية النظام B (مثلاً، موفر SaaS خارجي). يجب أن تدعم البروتوكولات نقل هذه الهويات وتحديد نطاقها دون إجبار المستخدمين على إعادة المصادقة يدوياً في كل خطوة.
تتكيف منصات توفير الهوية وOAuth/OIDC بسرعة مع هذا الواقع الجديد. بإمكان بنى تحتية مثل Logto وAuth0 أو مزودي الهوية الداخليين إصدار رموز مميزة يستخدمها العملاء في مكالمات MCP وA2A. السؤال المطروح ليس ما إذا كان هذا ممكنًا - فهو ممكنٌ بلا شك - بل كيف نوحد الأنماط بحيث لا تتحول أداةٌ تُبنى اليوم إلى عبء أمني أو إداري غدًا.
بالإضافة إلى المصادقة، من المرجح أن تنتقل إمكانية المراقبة وإنفاذ السياسات إلى "بوابات الوكلاء" المشتركة. تستطيع هذه البوابات إنهاء حركة مرور MCP وA2A، وتوحيد سجلات البيانات، وفرض حدود على معدل الطلبات، وربط هويات المستخدمين والوكلاء، بل وحتى تحديد الأدوات أو الوكلاء المتاحين في سياقات محددة. يبدو الأمر أشبه ببوابات واجهة برمجة التطبيقات (API)، ولكنها مُصممة خصيصًا لحركة مرور الذكاء الاصطناعي بدلًا من بروتوكول HTTP العادي.
بالنظر إلى الصورة الأوسع، فإن MCP و A2A تعيدان تشكيل طريقة تفكيرنا بهدوء في تكامل البرامج وأدوات البرمجة. بالنسبة للمطورين، يمكن لمساعد البرمجة المتصل ببروتوكول MCP وبروتوكول ACP (بروتوكول العميل والوكيل لبيئات التطوير المتكاملة) اكتشاف الأدوات، والاتصال بخوادم اللغات، والتكامل مع أنظمة التحكم في الإصدارات، والتواصل مع وكلاء المبرمجين الآخرين - كل ذلك عبر بروتوكولات قياسية. أما بالنسبة للمؤسسات، فيمكن لأنظمة الوكلاء المتعددين العمل معًا بسلاسة بين الفرق والموردين دون الحاجة إلى إعادة برمجة كل شيء لكل حالة استخدام جديدة.
التحول طويل الأمد هو من "التطبيقات المبرمجة" إلى "أنظمة الوكلاء". كما مكّنت تقنيتا USB وHTTP من ربط أي أجهزة وخدمات، تهدف تقنيتا MCP وA2A إلى جعل الأدوات والوكلاء قابلة للتوصيل. وسيكون الفائزون هم الفرق التي تتعامل مع هذه البروتوكولات لا كشعارات براقة، بل كبنية تحتية أساسية لكيفية تواصل أنظمتها وتعاونها وتطورها بمرور الوقت.
