معمارية التجارة الوكيلية: طبقة قدرات MCP واحدة لأربع قنوات ذكاء اصطناعي

أبرز النقاط

• يمكن لأربع قنوات وصول للذكاء الاصطناعي، هي البوابة الخاصة بالشركة وOpenAI ACP وMeta Muse ووكلاء A2A الخارجيون، أن تتشارك طبقة قدرات MCP واحدة بدلاً من أربع إعادات تنفيذ منفصلة لمنطق التجارة نفسه.
• قاعدة القرار في سطر واحد: أضِف محوّل بروتوكول فقط عندما يختلف البروتوكول الخارجي عن MCP. يحتاج Agentic Commerce Protocol من OpenAI إلى محوّل ACP→MCP، بينما لا يحتاج أي موصّل يتحدث MCP أصلاً إلى محوّل.
• يبقى Magento / Adobe Commerce نظام السجل المرجعي — فلا تعيد ACP وMCP وA2A إنتاج منطق التسعير أو المخزون أو الضرائب أو الطلبات فيه، بل تستدعيه.
• تُضبط أدوات الكتابة بحسب أثرها عند حدود الأداة — تمر عمليات القراءة مثل catalog.search_products بحرية، بينما تتطلب عمليات الكتابة الحساسة مثل order.submit وpayment.authorize موافقة بشرية وخاصية idempotency.

عندما تربط كتالوج التجارة الخاص بك بـ ChatGPT وبـ Meta Muse وبوكلاء الشركات الشريكة، فإن التصميم الساذج يعيد تنفيذ منطق التسعير والمخزون والدفع أربع مرات، مرة لكل منصة. فكل واجهة ذكاء اصطناعي تتحدث بروتوكولاً مختلفاً: قدّمت OpenAI بروتوكول Agentic Commerce Protocol (ACP، طُوّر بالتعاون مع Stripe)، وتتحدث الوكلاء إلى الأدوات عبر Model Context Protocol (MCP)، ويفوّض الوكلاء بعضهم بعضاً عبر A2A. والردّ التلقائي هو بناء حزمة تكامل لكل منصة. هذا الردّ التلقائي هو الخطأ المكلف.

تعرض هذه المقالة معمارية محايدة للمزوّدين للتجارة الوكيلية: طبقة قدرات MCP مؤسسية واحدة في الجهة الجنوبية، وقنوات وصول متعددة للذكاء الاصطناعي في الجهة الشمالية. وتستخدم Magento / Adobe Commerce مثالاً تطبيقياً لنظام السجل التجاري، لكن النمط ينطبق على أي نظام ERP أو OMS أو كتالوج. والنتيجة الجوهرية قاعدة قرار واحدة — لا تضف محوّلاً إلا عندما يجب ترجمة بروتوكول المنصة الخارجية إلى MCP — تحدد بدقة أين يوضع كود التكامل، والأهم من ذلك أين لا يوضع.

الفخ: أربع منصات وأربع إعادات تنفيذ

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

• موقع الشركة الخاص → استدعاءات Magento مخصصة
• OpenAI / ChatGPT → استدعاءات Magento مختلفة
• Meta Muse → استدعاءات Magento مختلفة مرة أخرى
• وكلاء الشركاء → مجموعة أخرى جديدة

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

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

قاعدة القرار: محوّل فقط عند اختلاف البروتوكول

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

التقنية	ما هي	ما الذي تجيب عنه
HTTP / REST / JSON	النقل، ونمط API، وصيغة البيانات	كيف تنتقل البايتات
ACP	التشغيل البيني لتجارة الذكاء الاصطناعي (OpenAI + Stripe)	كيف تتعامل منصة تجارة بالذكاء الاصطناعي مع التاجر
MCP	التشغيل البيني بين الوكيل/التطبيق والأداة	ما الأدوات التي يمكن للوكيل أو التطبيق استدعاؤها
A2A	التشغيل البيني بين الوكلاء	كيف يفوّض وكيل عملاً إلى وكيل آخر

يحل ACP وMCP مشكلتين مختلفتين، ولذلك فإن محوّل ACP مطلوب فعلاً — فهو يترجم دلالات التجارة في ACP (جلسات الدفع، وحالة الطلب، وصيغ التغذية) إلى استدعاءات أدوات MCP. وA2A متميز أيضاً: يفوّض وكيل خارجي مهمة عبر A2A، وتوجّهها بوابة إلى Agent Core لديك، الذي يستدعي بدوره MCP. أما المنصة التي يستهلك نموذج موصّلاتها MCP أصلاً فلا تحتاج إلى أي محوّل — إذ تصل إلى طبقة القدرات مباشرة.

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

• البوابة الخاصة → Agent Core → MCP
• OpenAI / ChatGPT → ACP → محوّل ACP → MCP
• Meta Muse → Muse Connector → MCP (بلا محوّل — فالموصّل يتحدث MCP)
• وكيل خارجي → A2A → بوابة A2A → Agent Core → MCP

كل شيء يلتقي عند MCP. وهذا الالتقاء هو التصميم كله:

المعمارية في عرض واحد:

خادم MCP Commerce Server هو الحد القابل لإعادة الاستخدام

طبقة القدرات هي خادم MCP يكشف مجموعة صغيرة ومستقرة من أدوات التجارة — catalog.search_products وpricing.get_price وinventory.check وcart.create وcart.add_item وorder.submit وorder.get_status. تستخدم كل قناة الأدوات نفسها. فـ Agent Core في البوابة الخاصة، ومحوّل ACP، وMuse Connector، والوكلاء الخارجيون القادمون عبر A2A، جميعها تستدعي catalog.search_products — ولا ينفذ كل منها بحث المنتجات بنفسه.

والأهم أن MCP هو واجهة القدرات، وليس نموذج بيانات الأعمال. فخلف الأدوات تقف خدمات التجارة القياسية — نموذج مستقل عن البروتوكول يضم Product وVariant وPrice وInventory وCart وOrder — ومحوّل Magento يربط هذا النموذج القياسي بواجهات Adobe Commerce البرمجية. وعندما تتغير صيغة تغذية المنتجات لدى OpenAI أو مخطط الدفع في ACP، لا يتغير سوى محوّل ACP. وعندما تتغير واجهة Magento البرمجية، لا يتغير سوى محوّل Magento. وتبقى الأدوات في المنتصف مستقرة. وهذا هو الانضباط البنيوي نفسه لـوحدة MCP المحكومة: أدوات محددة الأنواع، وعقد مستقر، وخصوصيات المزوّد معزولة عند الأطراف.

وتُصنَّف الأدوات بحسب الأثر، وفي هذا التصنيف تكمن الحوكمة. فعمليات القراءة (catalog.search وpricing.get وinventory.check) منخفضة المخاطر وتمر بحرية. وعمليات الكتابة (cart.add_item) تغيّر الحالة لكنها قابلة للتراجع. أما عمليات الكتابة الحساسة (order.submit وpayment.authorize وrefund.create) فتحرّك الأموال أو تنشئ التزامات — وتتطلب موافقة بشرية ومفاتيح idempotency لمنع تكرار الطلبات وتسجيل تدقيق، تُفرض عند حدود الأداة بصرف النظر عن القناة التي استدعتها. وطبقة الحوكمة الخاصة بالموصّل (المصادقة، وصلاحيات المستخدمين، وبوابات الموافقة البشرية) تقع أمام خادم MCP وليس بدلاً عنه.

لماذا لا يحتاج Meta Muse إلى محوّل بينما يحتاجه ACP

أوضح تجسيد لقاعدة القرار هو التباين بين منصتي الذكاء الاصطناعي الخارجيتين. فـ ACP من OpenAI وMCP بروتوكولان مختلفان، ولذلك يحمل مسار ACP محوّلاً يترجم دلالات التجارة في ACP إلى استدعاءات أدوات MCP. أما نموذج موصّل يقدّم تكامله بوصفه نقطة نهاية MCP فيستهلك طبقة القدرات مباشرة — وحد الحوكمة هو نموذج المراجعة والصلاحيات لدى الموصّل، لكن لا توجد طبقة ترجمة ثانية تُبنى أو تُصان. وإضافة طبقة كهذه «لأن Muse منصة مختلفة» ستكون دين تكامل بلا وظيفة.

ويمتد الاختبار نفسه إلى كل واجهة ذكاء اصطناعي مستقبلية. اطرح سؤالاً واحداً: هل تستطيع هذه المنصة استهلاك MCP مباشرة؟ إن كانت الإجابة نعم، فإنها تتصل بالخادم القائم وتعيد استخدام كل أداة. وإن كانت لا، فأضف محوّل بروتوكول واحداً بالضبط — ولا شيء غيره. وبهذا تبقى القنوات الأربع (والخامسة والسادسة) منخفضة التكلفة.

ما بعد التجارة: الطبقة نفسها تصبح منصة وكلاء مؤسسية

التجارة مجال MCP واحد فقط. فـ Agent Core نفسه يستطيع استدعاء خادم MCP للتجارة وخادم MCP لإدارة علاقات العملاء (CRM) وخادم MCP لتخطيط الموارد (ERP)، ويؤلف طلباً مثل «ابحث عن منتجات متوافقة مع مشتريات هذا العميل السابقة، بأقل من 500 دولار، ومتوفرة في المخزون، وأعدّ توصية» عبر التجارة وCRM في خطة واحدة. وللتفويض الخارجي، يتيح A2A — الذي تجاوز 150 مؤسسة في عامه الأول — لوكيل المشتريات في شركة شريكة أن يفوّض وكيل المبيعات لديك، الذي يستدعي طبقة MCP لديك، دون منح الشريك وصولاً مباشراً إلى الأنظمة الداخلية. ومعمارية التجارة وحزمة MCP + A2A المؤسسية الأوسع هما المعمارية نفسها بنطاقين مختلفين.

بناء تمثيلي

أراد تاجر متوسط الحجم يعمل على Adobe Commerce أن يصبح قابلاً للبيع داخل ChatGPT وMeta Muse دون فريق منصة. بنينا أولاً خدمات التجارة القياسية ومحوّل Magento، وكشفنا ست أدوات تجارة عبر MCP، وربطنا Agent Core في البوابة الخاصة بها. ثم جاءت OpenAI: محوّل ACP مع محوّل تغذية المنتجات، يعيدان استخدام الأدوات نفسها تماماً في الأسفل. وكان Meta Muse أرخص القنوات جميعاً — فقد وُثّق خادم MCP Commerce Server القائم (نقطة النهاية، والمصادقة، والأدوات، وتصنيف القراءة/الكتابة، وموافقات الكتابة الحساسة) وقُدّم عبر مراجعة الموصّلات، دون كتابة أي محوّل خاص. طبقة قدرات واحدة؛ وكانت كل قناة جديدة مسار وصول لا إعادة بناء.

قراءات ذات صلة

• Commerce Protocols for AI Agents: UCP, ACP, AP2, and MCP — How the Stack Fits Together — مشهد البروتوكولات الذي تقوم عليه هذه المعمارية، وأي بروتوكول يملك أي جزء من المعاملة
• A2A vs MCP: Choosing the Right Protocol for Agent Communication — التمييز بين وكيل-إلى-وكيل ووكيل-إلى-أداة الذي يحدد موضع بوابة A2A وطبقة MCP
• MCP Module Code Standard — النمط البنيوي لأدوات MCP المحكومة والمحددة الأنواع التي تجعل طبقة القدرات قابلة لإعادة الاستخدام

إن بناء طبقة تجارة وكيلية على منظومتك — Adobe Commerce أو ERP أو CRM — يبدأ بتسمية القدرات القياسية مرة واحدة، لا لكل منصة على حدة.

Request a scoped build. استكشاف لمدة أسبوع. تحصل على جرد للأنظمة وخريطة لسير العمل ونطاق ثابت — سواء بنيت معنا أم لا.