بروتوكولات وكلاء الذكاء الاصطناعي: شرح MCP مقابل A2A

الجواب المختصر: MCP مقابل A2A في طبقتين

تعمل بروتوكولات وكلاء الذكاء الاصطناعي في طبقتين منفصلتين: MCP يربط الوكيل بأدواته وبياناته، وA2A يربط وكيلًا بوكيل آخر. MCP هو بروتوكول سياق النموذج (Model Context Protocol). A2A هو بروتوكول التواصل بين الوكلاء (Agent2Agent). البروتوكولان لا يتنافسان، لأن كل واحد منهما يحل مشكلة مختلفة. والنظام الواحد قد يستخدمهما معًا في الطلب نفسه.

هذه قاعدة سهلة للتذكر: إذا كان الطرف الآخر ينفذ عملية ويعيد نتيجة، فهو أداة، وطريقه MCP. وإذا كان الطرف الآخر يحكم على الطلب ويحتاج وقتًا وقد يسألك سؤالًا قبل أن ينتهي، فهو وكيل، وطريقه A2A.

مواد الدورات التدريبية العربية تخلط المصطلح الإنجليزي بالعربي. لذلك نذكر المصطلح العربي مرة واحدة ثم نستخدم الاختصار. ابحث بالاثنين، لأن التوثيق الرسمي للبروتوكولين مكتوب بالإنجليزية.

خريطة الطبقات: من يتكلم مع من؟

الوكيل برنامج يضع نموذجًا لغويًا كبيرًا (LLM، أي Large Language Model) داخل حلقة عمل. يقرأ الوكيل الطلب ويقرر الخطوة التالية ويستدعي أداة، ثم يقرأ النتيجة ويقرر من جديد. إذا لم يتضح لك بعد الفرق بين الوكيل والنموذج، فاقرأ أولًا شرح أنواع وكلاء الذكاء الاصطناعي وطريقة عمل كل نوع.

حول هذا الوكيل توجد أربع طبقات اتصال:

• الإنسان والوكيل: واجهة المحادثة أو التطبيق. هذه الطبقة خارج نطاق البروتوكولين.
• الوكيل والنموذج: يقدم كل مزود نماذج واجهة برمجة تطبيقات (API) خاصة به. هذه الطبقة أيضًا خارج نطاق البروتوكولين.
• الوكيل وأدواته وبياناته: هنا يعمل MCP.
• الوكيل ووكيل آخر: هنا يعمل A2A.

الطبقتان الأخيرتان هما موضوع هذا الدرس. سنشرحهما بمثال واحد من البداية إلى النهاية.

السيناريو: عميلة تطلب استرداد ثمن غسالة

متجر إلكتروني للأجهزة المنزلية يستخدم وكيلين. تكتب العميلة سارة في نافذة الدعم: «وصلتني الغسالة مكسورة. رقم الطلب A-1042. أريد استرداد المبلغ».

وكيل الدعم يتكلم مع العملاء. يستطيع قراءة الطلبات وحالة الشحن، لكنه لا يملك صلاحية تحريك المال.

وكيل الفوترة يملكه فريق المالية. يطبق سياسة الاسترداد، ويتصل بمزود الدفع، ويسجل القيد في نظام المحاسبة.

هذا ما يحدث خطوة بخطوة:

1. يستدعي وكيل الدعم أداة get_order عبر MCP، فيقرأ تفاصيل الطلب وحالة التسليم.
2. يرى أن الطلب سُلّم قبل يومين، وأن العميلة تذكر تلفًا. لكنه لا يقرر المبلغ، لأن ذلك خارج صلاحياته.
3. يرسل طلب الاسترداد إلى وكيل الفوترة عبر A2A.
4. يبدأ وكيل الفوترة العمل، ثم يطلب صورة للتلف قبل الموافقة.
5. يطلب وكيل الدعم الصورة من سارة ويرسلها إلى وكيل الفوترة.
6. يصدر وكيل الفوترة الاسترداد ويعيد إيصالًا.
7. يبلغ وكيل الدعم سارة بالنتيجة.

الخطوة 1 تقع في طبقة الأدوات. الخطوات من 3 إلى 6 تقع في طبقة الوكلاء. لنفصّل كل طبقة على حدة.

الخطوة الأولى: كيف يصل وكيل الدعم إلى الطلب عبر MCP؟

المضيف والعميل والخادم

يعرّف MCP ثلاثة أدوار. المضيف (host) هو التطبيق الذي يشغّل النموذج، وهو هنا تطبيق وكيل الدعم. العميل (client) موصل داخل المضيف، ويتصل كل عميل بخادم واحد. الخادم (server) هو البرنامج الذي يعرض القدرات، وهو هنا خادم صغير يغلّف قاعدة بيانات الطلبات.

تُكتب الرسائل بين العميل والخادم بصيغة JSON-RPC 2.0، أي استدعاء الإجراءات عن بُعد بصيغة JSON. وتنتقل الرسائل بإحدى طريقتين معياريتين. الأولى هي stdio، أي قناتا الإدخال والإخراج القياسيتان. تُستخدم هذه الطريقة عندما يشغّل المضيف الخادم كعملية فرعية على الجهاز نفسه. الثانية هي Streamable HTTP. فيها تُرسل كل رسالة كطلب POST عبر HTTP (بروتوكول نقل النص التشعبي) إلى عنوان واحد. ويعود الرد في صورة كائن JSON أو تدفق SSE، أي أحداث مرسلة من الخادم (Server-Sent Events).

ماذا يعرض خادم MCP؟

يقدم الخادم للعميل أنواعًا محددة من القدرات. وفي مراجعة المواصفة الحالية يقدم العميل للخادم قدرة واحدة:

• الأدوات (Tools): دوال ينفذها النموذج، مثل get_order وget_shipment.
• الموارد (Resources): بيانات تُضاف إلى السياق، مثل ملف سياسة الإرجاع.
• القوالب (Prompts): رسائل جاهزة يختارها المستخدم، مثل قالب «لخّص شكوى العميل».
• طلب معلومات إضافية (Elicitation): قدرة من جهة العميل، يطلب بها الخادم معلومة ناقصة من المستخدم.

يطلب العميل قائمة الأدوات من الخادم بالطريقة tools/list. تأتي كل أداة باسم ووصف ومخطط للمدخلات بصيغة JSON Schema. يقرأ النموذج الوصف ليختار الأداة المناسبة، لذلك يُعد الوصف الواضح جزءًا من جودة الخادم.

كيف تبدو رسالة استدعاء أداة؟

هذه رسالة مبسطة. حذفنا منها حقول _meta التي تحمل إصدار البروتوكول وقدرات العميل مع كل طلب:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "get_order",
    "arguments": { "order_id": "A-1042" }
  }
}

لا يكتب النموذج هذه الرسالة بنفسه. يعلن النموذج أنه يريد الأداة get_order بالمدخل A-1042. يبني العميل داخل المضيف رسالة JSON-RPC ويرسلها، ثم يضع النتيجة في سياق النموذج. يعيد الخادم بيانات الطلب ولا يقرر شيئًا. لهذا السبب نسمي MCP طبقة أدوات: الخادم لا يملك هدفًا خاصًا به، والحكم كله يبقى عند النموذج الذي استدعاه.

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

إذا أردت تشغيل خادم MCP خاص بك بدل الاكتفاء بالشرح، فالخطوات العملية موجودة في دليل تشغيل خوادم MCP على خادم افتراضي خاص.

الخطوة الثانية: كيف يسلّم وكيل الدعم الاسترداد لوكيل الفوترة عبر A2A؟

بطاقة الوكيل: كيف يعرف وكيل ما يستطيعه وكيل آخر؟

قبل أن يرسل وكيل الدعم أي طلب، يقرأ بطاقة الوكيل (Agent Card) الخاصة بوكيل الفوترة. البطاقة ملف JSON ينشره الوكيل على عنوان معروف: https://{domain}/.well-known/agent-card.json. هذه نسخة مختصرة، فيها الحقول الإلزامية وبعض الحقول الاختيارية:

{
  "name": "Billing Agent",
  "description": "Reviews refund requests and issues approved refunds.",
  "version": "1.0.0",
  "supportedInterfaces": [
    {
      "url": "https://billing.example.com/a2a",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    }
  ],
  "capabilities": { "streaming": true, "pushNotifications": false },
  "defaultInputModes": ["text/plain", "application/json"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "issue-refund",
      "name": "Issue refund",
      "description": "Checks a refund request against policy and refunds the payment.",
      "tags": ["refund", "billing"]
    }
  ]
}

يحدد الحقل skills ما يستطيع الوكيل فعله. ويحدد الحقل supportedInterfaces أين يُرسل الطلب وبأي طريقة ربط. أما الحقل capabilities فيبين هل يدعم الوكيل بث التحديثات والإشعارات. في البطاقة الحقيقية تضيف أيضًا securitySchemes لتعلن طريقة التحقق من الهوية المطلوبة، مثل OAuth 2.0 أو مفتاح API. وهذا يعني أن وكيل الدعم يحتاج هوية خاصة به يقدمها لوكيل الفوترة، وهو موضوع إعطاء وكيل الذكاء الاصطناعي هوية مستقلة.

تحدد المواصفة ثلاث طرق ربط معيارية: JSON-RPC 2.0، وgRPC (إطار لاستدعاء الإجراءات عن بُعد)، وHTTP مع JSON. وتسمح أيضًا بطرق ربط مخصصة.

المهمة: وحدة العمل في A2A

يرسل وكيل الدعم رسالة بالطريقة SendMessage. يرد وكيل الفوترة إما برسالة سريعة، أو ينشئ مهمة (Task) لعمل يحتاج وقتًا. لكل مهمة معرّف خاص بها. ويجمع الحقل contextId المهام والرسائل المرتبطة بالمحادثة نفسها.

تمر المهمة بحالات تحددها المواصفة:

• TASK_STATE_SUBMITTED: استُلمت المهمة.
• TASK_STATE_WORKING: الوكيل يعمل عليها.
• TASK_STATE_INPUT_REQUIRED: الوكيل يحتاج معلومة قبل أن يكمل.
• TASK_STATE_AUTH_REQUIRED: الوكيل يحتاج تحققًا إضافيًا من الهوية.
• TASK_STATE_COMPLETED: انتهت بنجاح.
• TASK_STATE_FAILED: فشلت.
• TASK_STATE_CANCELED: أُلغيت.
• TASK_STATE_REJECTED: رفض الوكيل تنفيذها.

الحالات الأربع الأخيرة نهائية. في السيناريو تنتقل المهمة من TASK_STATE_WORKING إلى TASK_STATE_INPUT_REQUIRED، لأن سياسة المالية تطلب صورة للتلف. يطلب وكيل الدعم الصورة من سارة، ثم يرسلها في رسالة جديدة ضمن المهمة نفسها. تعود المهمة إلى TASK_STATE_WORKING، ثم تنتهي بالحالة TASK_STATE_COMPLETED.

كيف يعرف وكيل الدعم أن الحالة تغيرت؟ يمكنه أن يسأل عن المهمة دوريًا بالطريقة GetTask. ويمكنه أن يفتح تدفق تحديثات بالطريقة SendStreamingMessage أو SubscribeToTask. ويمكنه أيضًا أن يسجل عنوانًا يستقبل عليه الإشعارات، إذا كانت البطاقة تعلن pushNotifications بالقيمة true.

الرسائل والأجزاء والمخرجات

لكل رسالة في A2A دور، فهي إما من المستخدم أو من الوكيل. وتتكون الرسالة من أجزاء (Parts). قد يكون الجزء نصًا أو ملفًا أو بيانات منظمة. تذهب صورة التلف كجزء من نوع ملف. وتُسمى النتيجة النهائية للمهمة مُخرجًا (Artifact). في مثالنا، المُخرج إيصال استرداد بصيغة JSON فيه المبلغ ورقم العملية.

الوكيل الآخر صندوق مغلق

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

لماذا لا نجعل وكيل الفوترة أداة MCP بسيطة؟

هذا سؤال معقول. يمكنك أن تعرض أداة issue_refund على وكيل الدعم عبر MCP. وهذا يعمل عندما يكون الاسترداد عملية واحدة بقواعد ثابتة، مثل «استرد أي طلب قيمته أقل من 50 دولارًا».

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

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

ما وضع البروتوكولين حاليًا؟

هذه المعلومات تتغير، لذلك نؤرخها. كلها صحيحة حتى 2 أكتوبر 2026، كما تظهر في المواقع الرسمية للمشروعين:

• MCP: تحمل آخر مراجعة للمواصفة على modelcontextprotocol.io التاريخ 2026-07-28. المشروع مسجل باسم «Model Context Protocol a Series of LF Projects, LLC»، أي أنه يعمل ضمن إطار مؤسسة Linux. في هذه المراجعة أصبح كل طلب مستقلًا بذاته، فهو يحمل داخله إصدار البروتوكول وقدرات العميل. وكانت المراجعات الأقدم تبدأ جلسة بمصافحة initialize. التفاصيل في شرح MCP عديم الحالة وما الذي تغير فيه.
• A2A: آخر إصدار للمواصفة على a2a-protocol.org هو 1.0.0. يذكر الموقع أن Google طورت البروتوكول في الأصل ثم تبرعت به لمؤسسة Linux. وتديره لجنة توجيه تقنية تضم ممثلين عن AWS وCisco وGoogle وIBM Research وMicrosoft وSalesforce وSAP وServiceNow.
• ACP: هو بروتوكول تواصل الوكلاء (Agent Communication Protocol) من IBM. تقول صفحة المشروع لدى IBM Research إن ACP أصبح جزءًا من A2A تحت مؤسسة Linux، وتقدم دليلًا للانتقال. إذا عرضت مادة دراسية ACP كبروتوكول ثالث منفصل، فقد كُتبت قبل هذا الدمج.

قبل أن تعتمد على أي رقم إصدار هنا، افتح الموقعين الرسميين وتحقق من التاريخ.

متى يكفي وكيل واحد مع MCP؟ هندسة الوكيل الفردي

هندسة الوكيل الفردي تعني وكيلًا واحدًا يصل إلى كل أدواته عبر MCP، دون وكلاء آخرين. وهذا هو الخيار الصحيح للبداية في أغلب المشاريع. يكفيك وكيل واحد في هذه الحالات:

• يملك فريق واحد كل الأدوات وكل القرارات.
• المهام قصيرة: سؤال، ثم استدعاء أداة أو عدة أدوات، ثم جواب.
• لا يوجد حد ثقة داخل النظام، فكل البيانات يجوز للوكيل نفسه أن يراها.
• تريد تتبع الأخطاء في سجل واحد.

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

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

متى يستحق الوكيل الثاني وA2A التعقيد الإضافي؟

انتقل إلى نظام متعدد الوكلاء مع A2A عندما يتحقق شرط واحد على الأقل من هذه الشروط:

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

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

يحسم سؤال واحد أغلب الحالات: هل يحتاج الطرف الآخر أن يحكم على الطلب، أم أن ينفذه فقط؟ الحكم يعني وكيلًا وA2A. والتنفيذ يعني أداة وMCP.

أخطاء شائعة عند الخلط بين البروتوكولين

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

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

الثقة العمياء بأوصاف الأدوات. تعتبر المواصفة نفسها هذه الأوصاف غير موثوقة إذا لم يكن الخادم موثوقًا. يدخل الوصف سياق النموذج، لذلك قد يوجّه نص مكتوب بنية سيئة قرارات الوكيل.

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

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

الأسئلة الشائعة (FAQ)

ما الفرق بين MCP وA2A باختصار؟

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

هل يستبدل A2A بروتوكول MCP؟

لا. يعمل البروتوكولان في طبقتين مختلفتين، ويستخدمهما النظام الواحد معًا في العادة. مثال ذلك وكيل دعم يقرأ الطلبات عبر خادم MCP، ثم يسلّم الاسترداد لوكيل فوترة عبر A2A. ووكيل الفوترة نفسه يصل إلى مزود الدفع عبر MCP.

هل ما زال بروتوكول ACP من IBM منفصلًا عن A2A؟

حتى 2 أكتوبر 2026، تقول صفحة مشروع ACP لدى IBM Research إن ACP أصبح جزءًا من A2A تحت مؤسسة Linux، وتقدم دليلًا للانتقال إلى A2A. المواد التي تعرض ACP كبروتوكول ثالث منافس كُتبت قبل هذا الدمج. تحقق من الصفحة الرسمية قبل أن تعتمد على هذه المعلومة، لأن وضع المشاريع يتغير.

متى أحتاج نظامًا متعدد الوكلاء بدل وكيل واحد؟

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