تضع MCP Apps وA2UI واجهات تفاعلية داخل محادثات الوكلاء، لكنهما يعملان بطريقتين متعاكستين. تقارن هذه المقالة بين العرض والأمان ودعم المضيفين والتكلفة، ثم تقدم جدول قرار يربط كل معيار بالمهام التي يتعامل معها بأفضل شكل.
أنتج وكيلك الإجابة الصحيحة، ومع ذلك يظهر على شكل كتلة نصية طويلة. معياران مفتوحان يعالجان هذه المشكلة الآن، وهما يختلفان في كل شيء تقريبًا. MCP Apps تشحن تطبيق ويب صغيرًا يعمل داخل iframe معزول. أما A2UI فترسل مخطط JSON وتترك المضيف يرسمه بمكوناته الأصلية. الأول يمنح الخادم التحكم في البكسلات، والثاني يمنح هذا التحكم للعميل.
تنظر هذه المقارنة في العرض والأمان ودعم المضيفين والتكلفة اليومية، ثم تنتهي بجدول قرار يمكنك تطبيقه على وكيلك اليوم. كل ادعاء عن المواصفتين مأخوذ من توثيق MCP الرسمي وموقع مشروع A2UI ومدونة Google للمطورين، وقد تم التحقق منه في أكتوبر 2026.
الفرق سهل الشرح. MCP Apps تتعامل مع الواجهة بوصفها مورداً يسلّمه الخادم. أما A2UI فتتعامل معها بوصفها بيانات يصفها الوكيل. كل ما يلي في هذه المقالة ينبع من هذا الفرق الجوهري الواحد.
بدأت MCP Apps كاقتراح باسم SEP-1865 في نوفمبر 2025. كتبه كل من Anthropic وOpenAI ومشرفو مشروع MCP-UI المجتمعي، مستندين إلى MCP-UI وإلى Apps SDK من OpenAI. في يناير 2026 أصبحت أول امتداد رسمي لبروتوكول سياق النموذج (Model Context Protocol)، ولها مواصفات خاصة مؤرخة 2026-01-26 في مستودع ext-apps.
تعيد الآلية استخدام عنصرين أساسيين في MCP، هما الأداة والمورد:
_meta.ui.resourceUri، الذي يشير إلى مورد ui://.text/html;profile=mcp-app.postMessage، باستخدام لهجة من JSON-RPC فيها طرق ui/ مثل ui/initialize.
بما أن الحمولة كود ويب عادي، فأنت تختار الإطار الذي تريده. يوفر مستودع ext-apps قوالب بداية تعمل مع React وVue وSvelte وPreact وSolid وJavaScript الخام. وصنف App من @modelcontextprotocol/ext-apps هو غلاف مساعد وليس شرطًا. يمكنك تنفيذ بروتوكول postMessage بنفسك إن أردت اعتماديات أقل.
A2UI، واختصارها Agent-to-User Interface، معيار مفتوح من Google أُطلق بترخيص Apache 2.0 في ديسمبر 2025. لا يرسل الوكيل HTML، بل يبث JSON تصريحيًا يسمي المكونات وبياناتها. يحتفظ العميل بـكتالوج من المكونات التي يثق بها، ويتحقق من كل رسالة مقابل هذا الكتالوج، ثم يحول النتيجة إلى شجرة واجهة أصلية.
يلخص شعار Google الفكرة: آمنة كالبيانات، ومعبّرة كالكود. المواصفة في الإصدار v0.9.1، والإصدار v1.0 في مرحلة المرشح حتى أكتوبر 2026. تتوفر أدوات عرض تعمل مع Angular وFlutter وLit، وتستخدم Google بالفعل A2UI في Opal وGemini Enterprise وFlutter GenUI SDK. تُنقل الحمولات بنوع MIME هو application/a2ui+json.
💡 النموذج الذهني: MCP Apps هي "أن تشحن موقعًا مصغرًا". أما A2UI فهي "أن ترسل مخططًا وتترك المضيف يبنيه من قطع معتمدة".
مع MCP Apps، يقرر الخادم شكل كل شيء. المضيف يوفر الإطار والعزل وجسر الرسائل فقط. وهذا يمنحك منصة الويب الكاملة: مخططات D3، ومشاهد WebGL، وعارضات PDF، والخرائط، وكرة CesiumJS الأرضية، ومشاهد Three.js. وهذه أمثلة حقيقية في مستودع ext-apps، إلى جانب مخصص ميزانية، وخريطة حرارية لمجموعة، وأداة مراقبة للنظام.
الثمن هو انحراف بصري. لا يرث الـ iframe نظام تصميم المضيف تلقائيًا، لذلك قد يبدو تطبيقك كجسم غريب داخل الدردشة. كما يحمل وزن صفحة متصفح كاملة: سكربتاتها الخاصة وذاكرتها الخاصة وزمن تحميلها.
مع A2UI، يقرر العميل شكل كل شيء. يقول الوكيل "بطاقة فيها عنوان ومخطط وزرّان"، فيرسم العميل بطاقته ومخططه وزريه الخاصة. يأتي التصميم من المضيف، فتتطابق النتيجة مع التطبيق المحيط سواء على الويب أو الموبايل أو سطح المكتب، دون الحاجة إلى webview.
الصيغة مناسبة أيضًا لنماذج اللغة. فهي صغيرة ومنظمة ومصممة للبث، لذلك يستطيع النموذج إصدار واجهة خطوة بخطوة بينما يراقب المستخدم تشكلها. القيد هو الكتالوج: إذا لم يملك العميل مكونًا لما تريده، فلا يمكنك اختراعه داخل الحمولة.
إليك المقارنة في نظرة واحدة:
| البعد | MCP Apps | A2UI |
|---|---|---|
| الحمولة | حزمة HTML عند عنوان URI من نوع ui:// | رسائل JSON |
| من يرسم | مضيف الذكاء الاصطناعي، داخل iframe معزول | العميل، من كتالوج معتمد |
| من يتحكم في المظهر | مطوّر التطبيق | تطبيق المضيف |
| تدفق الإجراءات | يطلب التطبيق استدعاءات أدوات يتوسط فيها المضيف | يتحقق العميل من الإجراءات المعلنة ويوجهها |
| البث | يمكن بث مدخلات الأداة إلى تطبيق محمّل مسبقًا | مبني للتوليد التدريجي |
| المنصات | الويب أولًا | الويب والموبايل وسطح المكتب |
| الحالة | امتداد MCP رسمي | تقوده Google، Apache 2.0، المواصفة v0.9.1 |
يقف خلف التصميمين نموذجا تهديد مختلفان تمامًا. يعزل أحدهما الكود، بينما يرفض الآخر قبول الكود أصلًا.
يعمل التطبيق داخل iframe معزول، لذا لا يستطيع الوصول إلى DOM الصفحة الأم، ولا قراءة ملفات تعريف الارتباط أو التخزين المحلي للمضيف، ولا إعادة توجيه الصفحة الأم. تعبر كل حركة البيانات حدّ postMessage، ويقرر المضيف ما يمر عبره. ويقوم الدفاع على عدة طبقات:
ui:// منذ البداية، يستطيع المضيف جلب القالب مسبقًا ومراجعته قبل تشغيل أي أداة._meta.ui.csp المصادر الخارجية التي يجوز للتطبيق التحميل منها._meta.ui.permissions.
تتجاوز A2UI سؤال الصندوق المعزول لأنها لا تنفذ أي شيء أصلًا. لا يقبل أداة العرض سوى JSON موثّق، ولا يقبل إلا المكونات الموجودة في الكتالوج. تسمي Google ذلك الأمان القائم على القدرات: يرسم العميل المكونات الموثوقة فقط ولا شيء غيرها.
لكن هذا لا يجعل A2UI آمنة تلقائيًا. يستطيع زر في الكتالوج أن يطلق إجراءً، لذلك يجب على العميل أن يفوّض كل إجراء معلن ويتحقق من كل حمولة. تحمي القائمة المسموح بها الواجهة، ولا تحمي منطق عملك.
ينقل كلا المعيارين المحتوى من الوكيل إلى الشاشة، لذلك يرث كلاهما نقاط ضعف الوكيل. قد يُقنع نموذج يقرأ صفحة ويب معادية بعرض نموذج مزيف مقنع، سواء كان النموذج داخل iframe أو على بطاقة من الكتالوج. اعتبر استدعاءات الأدوات التي تطلقها أي واجهة مولّدة مدخلات غير موثوقة: تحقق من الأذونات على الخادم، وقيّد التوكنات بأضيق نطاق، واطلب تأكيدًا لأي شيء ينفق مالًا أو يغيّر بيانات.
يُعد دعم المضيفين أقوى حجة لصالح MCP Apps الآن. تسرد الوثائق الرسمية Claude وClaude Desktop وVS Code GitHub Copilot وMicrosoft 365 Copilot وGoose وPostman وMCPJam وArchestra.AI، كما يعرضها ChatGPT أيضًا. يحتفظ مشروع MCP بمصفوفة للعملاء، وهي مهمة: دعم واجهة التطبيق أضيق من دعم أدوات MCP الأساسية. قد يستدعي عميل أدواتك لكنه يتجاهل مورد ui:// الخاص بك.
إذا بنيت مضيفًا بنفسك، فأمامك مساران. توفر حزمة @mcp-ui/client مكونات React، ويتولى وحدة App Bridge في SDK العرض المعزول، وتمرير الرسائل، وتفويض استدعاءات الأدوات، وفرض السياسات.
يعتمد دعم A2UI على أداة العرض التي يشحنها عميلك، لا على قائمة منتجات دردشة. تختار Angular أو Flutter أو Lit، وتعرّف كتالوجك، وتوصل ناقلًا. يحمل بروتوكول A2A رسائل A2UI بين الوكلاء، ويعلن AG-UI، بروتوكول CopilotKit، توافقًا من اليوم الأول. ويمكن أن يعمل A2UI فوق MCP أيضًا: تصل الحمولات عبر resources/read للشاشات الثابتة أو tools/call للشاشات الديناميكية، ضمن مخطط عناوين a2ui://.
اختر حسب المهمة، لا حسب العلامة التجارية. يوضح هذا الجدول الطريقة التي تميل بها الفرق إلى توزيع العمل:
| السيناريو | الخيار الأنسب | السبب |
|---|---|---|
| تكامل المنتج مع المصادقة وحالة الحساب | MCP Apps | الخادم يتولى الصلاحيات والحالة |
| تدفقات الموافقة على الإنفاق أو تغييرات البيانات | MCP Apps | تطلق سطحًا مستقرًا ومختبرًا |
| الوسائط الغنية والخرائط و3D ومستعرضات PDF | MCP Apps | منصة ويب كاملة داخل iframe |
| استكشاف البيانات مع تخطيطات متغيرة | A2UI | الوكيل يختار المخطط أو الجدول أو البطاقة |
| التقارير المولّدة | A2UI | تخطيطات مرنة وبيانات متغيرة |
| واجهة واحدة عبر الويب والجوال | A2UI | الحمولة نفسها، والتصيير الأصلي |
| تطابق وثيق مع نظام تصميم | A2UI | ينطبق تخصيص المضيف للمظهر |
اخترها عندما تملك بالفعل منتجًا ويبيًا وتريده داخل الدردشة. يحتفظ خادمك بالمنطق، وتتحكم في كل بكسل، ويمكنك إعادة استخدام مكونات React الموجودة لديك. واخترها أيضًا عندما تهم سرعة النماذج الأولية: ملف HTML واحد يكفي للشحن.
اختره عندما لا تُعرف الشاشة مسبقًا. الوكيل الذي يجيب على "أرني الربع الأخير" بجدول اليوم ومخطط الغد يناسبه كتالوج أفضل بكثير من صفحة مبنية يدويًا لكل حالة. واختره أيضًا عندما يكون عميلك أصليًا، أو عندما لن يوافق فريق الأمان لديك على سكربتات طرف ثالث داخل الدردشة.
الاختيار ليس حصريًا. تصف مدونة Google للمطورين، المنشورة في 17 يونيو 2026، ثلاثة أنماط للتكامل، وهي تغيّر معنى "اختر واحدًا".
a2ui://. لا حاجة إلى iframe.بالنسبة لمعظم الفرق، يصلح التقسيم حسب المهمة. ضع الأسطح المستقرة عالية المخاطر مثل الموافقات والإعدادات وعروض الحساب في MCP Apps. ضع الأسطح المرنة المولّدة مثل التقارير والملخصات في A2UI. قدّم الاثنين من خادم MCP نفسه كي يحتفظ وكيلك باتصال واحد. يمثل النمط 3 مخرج الطوارئ لديك عندما يفتقر المضيف إلى أداة تصيير.
راجع التقسيم كل ربع سنة. إذا بدأت شاشة مولّدة تحتاج إلى مخططات مخصصة لا يستطيع الكتالوج رسمها، فتلك الشاشة تجاوزت A2UI وتنتمي إلى MCP App. وإذا ظل تطبيق MCP يُعاد بناؤه مع كل شكل جديد للبيانات، فهو مرشح ليصبح كتالوجًا بدلًا من ذلك.
كتابة حمولات A2UI يدويًا تصبح مرهقة، ونموذج لغوي يعيد JSON صارمًا شريك صياغة طبيعي. صُمم GPT 5 Structured على PicassoIA لهذا تحديدًا: تعرّف مخطط JSON، وكل استجابة تلتزم به.
model: gpt-5، أو gpt-5-mini، أو gpt-5-nano.instructions. اذكر المكونات التي يقبلها عميلك، مع خصائصها.prompt، مثلًا "ملخص طلب فيه جدول بالعناصر وزر تأكيد."json_schema على مخطط الرسائل من مواصفة A2UI. استخدم json_schema بدلًا من simple_schema، لأن النسخة البسيطة لا تدعم الكائنات المتداخلة.reasoning_effort على minimal للمسودات السريعة. أما للتخطيطات الكثيفة، فارفعه وزِد max_output_tokens، لأن التفكير المرتفع قد يستنزف الميزانية ويعيد استجابة فارغة.💡 تعامل مع مخرجات النموذج كمسودة. يبقى مدقق أداة العرض لديك البوابة النهائية، تمامًا كما يقصد نموذج الأمان في A2UI.
تريد مقارنة مسودات من نماذج أخرى؟ Claude Sonnet 5 وGemini 3.5 Flash متاحان على PicassoIA أيضًا، فيمكنك تشغيل الكتالوج والأمر النصي نفسهما عبر كل منهما والاحتفاظ بالنتيجة الأنظف.
أيًا كان المعيار الذي تختاره، تحتاج شاشات وكيلك إلى صور: مصغرات المنتجات، واللافتات الرئيسية، وصور الرؤوس للتقارير. تعرض MCP Apps الصور عبر HTML عادي. وتعرضها A2UI عبر أي مكون صور يعرّفه كتالوجك. في الحالتين تحتاج إلى الصور أولًا.
يجمع PicassoIA مولّدات الصور في مكان واحد. تتوفر Seedream 5 Pro وFlux 2 Pro وImagen 4 وPicassoIA Image كلها في مجموعة تحويل النص إلى صورة، فيمكنك تشغيل أمر نصي واحد عبر عدة نماذج والاحتفاظ بالنسخة التي تناسب تخطيطك. كما يعرض PicassoIA مولّداته عبر اتصالات MCP، فيستطيع وكيل يتحدث البروتوكول المذكور أعلاه أن يطلب الصور مباشرة.
افتح المجموعة، واكتب أمرًا نصيًا لبطاقتك أو لافتتك التالية، ثم ولّد بضع نسخ. اختر شاشة واحدة من وكيلك، وأعطها صورة حقيقية، وانظر كم يتسارع الجانب البصري ليلحق بالمنطق.
اختر لغتك
