العربية
  • A2A
  • الذكاء الاصطناعي
  • MCP

A2A مقابل MCP: بروتوكولان يكملان بعضهما البعض لنظام الوكلاء الناشئ

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

Guamian
Guamian
Product & Design

توقف عن إضاعة أسابيع في مصادقة المستخدم
أطلق تطبيقات آمنة بشكل أسرع مع Logto. قم بدمج مصادقة المستخدم في دقائق وركز على منتجك الأساسي.
ابدأ الآن
Product screenshot

إن التبني المتزايد للوكلاء الذكية - الكيانات البرمجية المستقلة أو شبه المستقلة التي تقوم بالتفكير والتنفيذ نيابةً عن المستخدمين - يؤدي إلى ظهور طبقة جديدة في هندسة التطبيقات.

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

A2A: كيف يتفاعل الوكلاء مع بعضهم البعض

MCP: كيف يتفاعل الوكلاء مع الأدوات أو السياق الخارجي

a2a_mcp.png reference: https://google.github.io/A2A/#/topics/a2a_and_mcp

إنهم يعالجون التحدي الأساسي لبناء أنظمة تحتوي على عدة وكلاء، عدة نماذج لغوية كبيرة، ومصادر سياق متعددة - جميعها تحتاج إلى التعاون.

أحد الطرق لتأطيرها: “يوفر بروتوكول MCP التكامل الرأسي (من التطبيق إلى النموذج)، بينما يوفر بروتوكول A2A التكامل الأفقي (من وكيل إلى وكيل)>

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

تُعرِّف هذه المقالة كلا البروتوكولين بطريقة بسيطة وسهلة الفهم وتبرز النقاط الأساسية للمطورين ومنشئي المنتجات الذكية.

ما هو A2A (وكيل لآخر)؟

A2A (وكيل لآخر) هو بروتوكول مفتوح تم تطويره بواسطة Google وأكثر من 50 شريكًا في الصناعة. هدفه هو تمكين التشغيل البيني بين الوكلاء - بغض النظر عمن قام ببنائها، أين يتم استضافتها، أو أي إطار عمل يستخدمونه.

آلية بروتوكول A2A

يستخدم A2A JSON-RPC 2.0 عبر HTTP(S) كآلية اتصال، مع دعم Server-Sent Events (SSE) لبث التحديثات.

نماذج الاتصال بـ A2A

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

السؤال هنا هو، كيف يكتشف الوكلاء بعضهم البعض. كل وكيل يمكنه نشر بطاقة وكيل (وثيقة وصف بيانات JSON، غالباً ما تُستضاف على عنوان URL قياسي مثل /.well-known/agent.json) تصف قدراته ومهاراته ونقاط النهاية لواجهات برمجة التطبيقات ومتطلبات المصادقة.

بقراءة بطاقة وكيل، يمكن للوكيل العميل تحديد شريك مناسب للمهمة المطروحة - في الأساس دليل لما يعرفه الوكيل أو يمكنه فعله. بمجرد اختيار الوكيل المستهدف، يقوم الوكيل العميل بصياغة كائن المهمة ليرسله.

a2a_task.png reference: https://google.github.io/A2A/#/

إدارة المهام

جميع التفاعلات في A2A موجهة نحو أداء المهام. المهمة هي كائن منظم (يحدده مخطط البروتوكول) يتضمن تفاصيل الطلب ويتتبع حالته.

في A2A، يلعب كل وكيل دورًا واحدًا من دورين:

  • الوكيل العميل: يبدأ مهمة
  • الوكيل البعيد: يستقبل المهمة ويعالجها

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

التعاون والتفاوض على المحتوى

يدعم A2A أكثر من مجرد طلبات المهام البسيطة - يمكن للوكلاء تبادل الرسائل الغنية متعددة الأجزاء التي تتضمن نصًا، JSON، صورًا، فيديو، أو محتوى تفاعلي. وهذا يُمكِّن التفاوض على الصيغة بناءً على ما يمكن لكل وكيل التعامل معه أو عرضه.

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

مثال على حالة الاستخدام

إليك مثالاً حقيقياً لكيفية استخدام A2A في سيناريو مؤسسة:

موظف جديد يتم تعيينه في شركة كبيرة. هناك أنظمة وأقسام متعددة متورطة في الإعداد:

  • يحتاج قسم الموارد البشرية إلى إنشاء سجل وإرسال بريد إلكتروني ترحيبي
  • تحتاج تقنية المعلومات لتجهيز جهاز كمبيوتر محمول وحسابات الشركة
  • تحتاج المنشآت لتحضير مكتب وبطاقة الوصول

تقليدياً، تُدار هذه الخطوات يدوياً أو من خلال التكامل المحكم بين الأنظمة الداخلية.

بدلاً من واجهات برمجة التطبيقات المخصصة بين كل نظام، يكشف كل قسم عن وكيله الخاص باستخدام بروتوكول A2A:

وكيلالمسؤولية
hr-agent.company.comإنشاء سجل الموظف، إرسال المستندات
it-agent.company.comإنشاء حساب بريد إلكتروني، طلب الكمبيوتر المحمول
facilities-agent.company.comتخصيص مكتب، طباعة بطاقة الوصول

نظام متعدد الوكلاء - دعونا نسميه OnboardingPro (مثل onboarding-agent.company.com) - ينسق سير العمل بأكمله في إعداد الموظف.

  1. الاكتشاف: يقرأ كل وكيل.well-known/agent.json لفهم القدرات والمصادقة.
  2. تفويض المهام:
    • يرسل مهمة createEmployee إلى وكيل الموارد البشرية.
    • يرسل مهامي setupEmailAccount و orderHardware إلى وكيل قسم تقنية المعلومات.
    • يرسل مهامي assignDesk و generateBadge إلى وكيل المنشآت.
  3. تحديثات البث: يقوم الوكلاء ببث تقدم العمل باستخدام الأحداث المرسلة من الخادم (مثل "تم شحن الكمبيوتر المحمول"، "تم تخصيص المكتب").
  4. جمع القطع الأثرية: يتم إرجاع النتائج النهائية (مثل بطاقة PDF، رسائل التأكيد بالبريد الإلكتروني، بيانات اعتماد الحساب) كقطع أثرية A2A.
  5. إكمال: OnboardingPro يُخطر مدير التوظيف عند اكتمال إعداد الموظف.

ما هو MCP (بروتوكول سياق النموذج)؟

MCP (بروتوكول سياق النموذج)، الذي تم تطويره بواسطة Anthropic، يعالج مشكلة مختلفة: كيفية توفير التطبيقات الخارجية سياقًا منظمًا وأدواتًا لوكيل يعتمد على نموذج لغوي أثناء التنفيذ.

بدلاً من تمكين الاتصال بين الوكلاء، يركز MCP على نافذة السياق - ذاكرة العمل للنموذج اللغوي الكبير. هدفه هو:

  • حقن الأدوات والمستندات، أو دوال API، أو حالة المستخدم بشكل ديناميكي في جلسة استنتاج النموذج
  • السماح للنماذج بالاتصال بالدوال أو استرجاع المستندات بدون ترميز الاستعلام أو المنطق

الهندسة الرئيسية لـ MCP

لفهم MCP، يجب أولاً فهم الهندسة العامة - كيف تعمل جميع الأجزاء معًا.

مضيف MCP: "الذكاء الاصطناعي الذي تتحدث إليه"

فكِّر في مضيف MCP كتطبيق الذكاء الاصطناعي نفسه - مثل Claude Desktop أو مساعد البرمجة الخاص بك.

إنه الواجهة التي تستخدمها - المكان الذي تقوم فيه بالكتابة أو التحدث.

يريد جلب الأدوات والبيانات التي تساعد النموذج على تقديم إجابات أفضل.

عميل MCP: "الوصلة"

عميل MCP هو الجزء البرمجي الذي يربط مضيف الذكاء الاصطناعي الخاص بك (مثل Claude) بالعالم الخارجي. يشبه لوحة التبديل - يدير الاتصالات الفردية الآمنة مع خوادم MCP المختلفة. عندما يريد الذكاء الاصطناعي الوصول إلى شيء ما، يمر عبر العميل.

من المفيد التفكير في أدوات مثل ChatGPT، Claude chat أو Cursor IDE كـ مضيفي MCP - يقدمون الواجهة التي تتفاعل معها. خلف الكواليس، يستخدمون عميل MCP للاتصال بأدوات ومصادر بيانات مختلفة عبر خوادم MCP.

mcp_diagram.png refrence: https://modelcontextprotocol.io/introduction

خادم MCP: "مزوّد الأدوات"

خادم MCP هو برنامج صغير ومركّز يكشف عن أداة أو قدرة محددة - مثل:

  • البحث في الملفات على جهاز الكمبيوتر الخاص بك
  • البحث عن البيانات في قاعدة بيانات محلية
  • استدعاء API خارجي (مثل الطقس، المالية، التقويم)

يتبع كل خادم بروتوكول MCP، وبالتالي يمكن للذكاء الاصطناعي فهم ما يمكن فعله وكيفية الاتصال به.

مصادر البيانات المحلية: "ملفاتك وخدماتك الخاصة"

بعض خوادم MCP تتصل بالأشياء الموجودة على جهازك الخاص - مثل:

  • المستندات والمجلدات
  • مشروعات البرمجة
  • قواعد البيانات أو التطبيقات المحلية

هذا يتيح للذكاء الاصطناعي البحث أو الاسترجاع أو الحوسبة دون تحميل بياناتك إلى السحابة.

الخدمات عن بُعد: "واجهات برمجة التطبيقات والأدوات عبر الإنترنت"

تتصل خوادم MCP الأخرى بالإنترنت - تتحدث إلى:

  • واجهات برمجة التطبيقات (مثل Stripe، Notion، GitHub)
  • أدوات SaaS
  • قواعد بيانات الشركة في السحابة

لذا يمكن للذكاء الاصطناعي ، على سبيل المثال: "استدعاء خادم GitHub واسترجاع قائمة طلبات السحب المفتوحة."

الآن يدعم MCP الاتصال بـ خوادم MCP البعيدة. وهذا يعني أن عميل MCP يمكنه اكتساب قدرات أكثر قوة. نظريًا،

مع مجموعة مناسبة من خوادم MCP، يمكن للمستخدمين تحويل كل عميل MCP إلى "تطبيق لكل شيء"

MCP_MCPSever.png reference: https://a16z.com/a-deep-dive-into-mcp-and-the-future-of-ai-tooling/

جمع كل شيء معًا

الآن دعونا نستخدم مخططًا لرؤية كيف يعمل كل شيء معًا.

  1. تطلب شيئًا معقدًا من الذكاء الاصطناعي
  2. يطلب الذكاء الاصطناعي (المضيف) المساعدة من العميل
  3. يقوم العميل باستدعاء الخادم MCP الصحيح - ربما الذي يفحص الملفات أو يستخدم API
  4. يرسل الخادم البيانات أو ينفذ وظيفة
  5. النتيجة تتدفق إلى النموذج للمساعدة في إكمال المهمة

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

فئةA2A (وكيل لآخر)MCP (بروتوكول سياق النموذج)
الهدف الأساسيتمكين تبادل المهام بين الوكلاءتمكين النماذج اللغوية الكبيرة من الوصول إلى الأدوات الخارجية أو السياق
مصمم لـالاتصال بين الوكلاء المستقلينتعزيز قدرات الوكيل الواحد أثناء الاستنتاج
التركيزسير العمل متعدد الوكلاء، التنسيق، التفويضاستخدام الأدوات الديناميكي، تعزيز السياق
نموذج التنفيذالوكلاء يرسلون/يستقبلون المهام والقطع الأثريةتختار النماذج اللغوية الكبيرة الأدوات وتنفيذها ضمنيًا أثناء التفكير
الأمانOAuth 2.0، مفاتيح API، النطاقات التصريحيةيُتعامل معها على طبقة تكامل التطبيقات
دور المطوربناء وكلاء يكشفون عن المهام والقطع الأثرية عبر نقاط النهايةتعريف الأدوات والسياق المنظم الذي يمكن للنموذج استخدامه
شركاء النظام البيئيGoogle، Salesforce، SAP، LangChain، إلخ.Anthropic، مع اعتماد ناشئ في واجهات مستخدم النماذج القائمة على الأدوات

كيف تعمل معًا

بدلاً من أن تكون بدائل، فإن A2A و MCP يكملان بعضهما البعض. في العديد من الأنظمة، سيتم استخدام كلاهما معًا.

مثال على عملية العمل

  1. يقدم المستخدم طلبًا معقدًا في واجهة وكيل مؤسسة.
  2. يستخدم الوكيل المنظم A2A لتفويض المهام الفرعية للوكلاء المتخصصين (مثل التحليلات، الموارد البشرية، المالية).
  3. يستخدم أحد هؤلاء الوكلاء MCP داخلياً لاستدعاء وظيفة بحث، استرجاع مستند، أو حساب شيء باستخدام نموذج.
  4. يتم إرجاع النتيجة كقطعة أثرية عبر A2A، مما يتيح التعاون بين الوكلاء مع الوصول إلى الأدوات بشكل وحدات.

هذه الهندسة تفصل الاتصال بين الوكلاء (A2A) عن استدعاء القدرة الداخلية للوكيل (MCP) - مما يجعل النظام أسهل للتكوين، التوسع، والأمان.

الخاتمة

A2A يتعلق بـ تواصل الوكلاء مع وكلاء آخرين عبر الشبكة - بأمان، بشكل غير متزامن، ويركز على المهام.

MCP يتعلق بـ حقن القدرات المنظم في جلسة النموذج، مما يسمح للنماذج اللغوية الكبيرة بالتفكير في الأدوات والبيانات بشكل سياقي.

عند استخدامها معًا، فإنها تدعم أنظمة متعددة الوكلاء قابلة للتركيب والتي تكون قابلة للتمديد والتشغيل البيني.

كيف يمكن أن تشكل البنية التحتية الأساسية MCP + A2A مستقبل أسواق منتجات الوكلاء

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

تغيير التفاعل بين الإنسان والحاسوب

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

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

الآن، مع وكلاء البرمجة المتصلة MCP، يمكن تجريد الكثير من هذا التعقيد. يمكن للمطورين اكتشاف الأدوات واستخدامها بشكل أكثر طبيعية من خلال المطالبات الحوارية. التكامل مع واجهات برمجة التطبيقات يصبح جزءًا من تدفق البرمجة نفسه - غالباً بدون الحاجة إلى واجهة مستخدم منفصلة أو إعداد يدوي. (فكر فقط في مدى تعقيد لوحات تحكم AWS أو Microsoft يمكن أن تكون.). يصبح التفاعل أكثر سلاسة - يتركز أكثر حول توجيه السلوك بدلاً من تجميع الميزات.

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

بدلاً من استخدام واجهات المستخدم للتغلب على التحديات التقنية (مثل "هذا صعب جدًا للبرمجة، لنقم بإنشاء لوحة تكوين"), نحن الآن بحاجة إلى:

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

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

استخدمت خدمة مطور ومنتج API كمثال لأظهر كيف يمكن أن يتغير تفاعل المستخدم - ولكن ينطبق الأمر نفسه على برامج الأعمال. لفترة طويلة، كانت أدوات العمل معقدة وصعبة الاستخدام. التفاعل بلغة طبيعية لديه القدرة على تبسيط العديد من تدفقات العمل تلك.

نماذج المنتجات الوكيل وتأثيرها على SaaS

بدأنا نرى عددًا متزايدًا من خوادم MCP تظهر. تخيل Airbnb يوفر خادم MCP للحجز، أو خرائط Google يكشف خادم MCP للخريطة. يمكن للوكيل (كعميل MCP) الاتصال بالعديد من هذه الخوادم في وقت واحد - مما يفتح تدفقات عمل كانت تتطلب في السابق تكاملات مخصصة أو تطبيقات متداخلة بشكل محكم.

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

  1. التصميم من المستندات

    تقوم بكتابة PRD في Notion. يقرأ وكيل Figma المستند تلقائيًا ويُنشئ إطارًا هيكليًا يوضح المفاهيم الأساسية - دون الحاجة إلى نقل يدوي.

  2. البحث عن المنافسين، من البداية إلى النهاية

    تطلب تحليل منافس. مجموعة من الوكلاء يبحثون في الويب، ويسجلون في الخدمات ذات الصلة نيابةً عنك (بمصادقة آمنة)، يجمعون النتائج، ويُعيدونها منظمة بالفعل في مساحة العمل Notion الخاصة بك.

التحديات مع حدود المصادقة والصلاحية

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

إلى الآن، هناك عدة سيناريوهات محددة تتعلق بالارتفاع الجديد في اتصالات الوكلاء مع الوكلاء و MCP.

  1. الوكيل مقابل تطبيقات SaaS و WebsiteApp
  2. عميل MCP (وكيل) مقابل خادم MCP
  3. المستخدم مقابل الوكيل
  4. الوكيل مقابل الوكيل

حالة استخدام مثيرة للاهتمام هي الاتحادية المتعددة الهويات التي ذكرتها Google:

على سبيل المثال، المستخدم U يعمل مع الوكيل A الذي يتطلب معرف نظام A. إذا كان الوكيل A يعتمد بعد ذلك على الأداة B أو الوكيل B الذي يتطلب معرف نظام B، فقد يحتاج المستخدم إلى توفير هويات لكل من نظام A ونظام B في طلب واحد. (افترض أن نظام A هو هوية LDAP للمؤسسة ونظام B هو هوية مقدم SaaS).

Logto هو مزود OIDC و OAuth، ومناسب جيدًا لمستقبل تكاملات الذكاء الاصطناعي.

بفضل بنيتها التحتية المرنة، نقوم حاليًا بتوسيع قدراتها ونشرنا سلسلة من البرامج التعليمية لمساعدة المطورين على البدء بسرعة.

هل لديك أسئلة؟

اتصل بنا — أو استفد واستكشف ما يمكنك بناءه مع Logto اليوم.