هل ستفتح التجارة الوكيلة طبقة مزدوجة من نظام المدفوعات للمعاملات الأصلية بالذكاء الاصطناعي؟

مع انتقال المعاملات الأصلية بالذكاء الاصطناعي من فكرة إلى تنفيذ، يدفع التسوّق الوكيلي (agentic commerce) إلى إعادة تفكير جوهرية في كيفية عمل أنظمة المدفوعات الرقمية وبنية التسوية.

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

بين سبتمبر 2025 ومارس 2026، انتقل كل لاعب رئيسي في المدفوعات العالمية إلى التسوّق المدفوع بالذكاء الاصطناعي. أطلقت OpenAI وStripe بروتوكول Agentic Commerce Protocol، بينما كشفت Google عن Universal Commerce Protocol لأكثر من 30 شريكًا من شركاء التجزئة وشركات التكنولوجيا المالية (fintech).

وعلى المدة نفسها، أطلقت Visa وMastercard أطرًا موجهة للوكلاء (agent-focused payment frameworks). طوّرت Coinbase معيار x402، وقامت بمسح (clearing) أكثر من 15 مليون معاملة على Base. علاوة على ذلك، شاركت Stripe وTempo في تأليف بروتوكول Machine Payments Protocol وقدّمتَه للتوحيد القياسي (standardisation) لدى IETF.

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

لم تُصمَّم الحزمة الحالية (stack) أبدًا لهذا السياق، وتدرك الصناعة عدم التوافق. ما الذي يظهر بدلًا من ذلك؟ بنية من طبقتين: طبقة علويّة للتنسيق (orchestration) تشمل الاكتشاف والبدء، وطبقة سفلية للتسوية لتحويل القيمة. سيتطور هذان المساران بشكل منفصل، مدفوعًا بحوافز مختلفة.

التنسيق التجاري: كيف تتجمع معاملات الوكلاء

تحدد طبقة التنسيق كيفية أن يجد الوكيل خدمة، ويدير جلسة (session)، ويسلّم إلى الدفع. ظهرت فئتان مختلفتان من حالات الاستخدام، ويؤدي دمجهما إلى مخاطر سوء فهم بنية السوق.

1.1 وكلاء يعملون بالنيابة عن المستهلكين

بالنسبة للوكلاء الذين يشترون نيابة عن البشر، فإن المشكلة الأساسية اليوم ليست ميكانيكا الدفع بل الوصول. تم تحسين معظم منصات التجارة الإلكترونية لتصفح البشر. ومع ذلك، لا ينبغي للوكيل أن يقوم بالتمرير عبر صفحات المنتجات، أو تفسير اللافتات، أو النقر على زر “add to cart”.

بدلًا من ذلك، يحتاج التجار إلى نقاط نهاية (endpoints) منظمة وقابلة للقراءة بواسطة الآلة. ما يزال هذا النوع نادرًا، ما يحد من التفاعلات الأصيلة للوكلاء. تأتي الموجة الأولى من البروتوكولات في هذا القطاع من OpenAI وStripe وGoogle، ولكل منها نهج مختلف تجاه التحكم والانفتاح.

أطلقت OpenAI وStripe بروتوكول Agentic Commerce Protocol (ACP) في سبتمبر 2025. يركز البروتوكول على تفويض دفع آمن عند الدفع: يتم تخزين وسيلة دفع المستخدم في ChatGPT، وعند تأكيد الشراء، تصدر Stripe Shared Payment Token (SPT)، وهي بيانات اعتماد (credential) واحدة الاستخدام (single-use) ومخصصة للتاجر وإجمالي سلة التسوق.

يُسلَّم هذا الرمز إلى التاجر عبر API، حيث يحتفظ التاجر بوضع Merchant of Record كامل، ويعالج الدفع عبر البنية التحتية الحالية لـ Stripe. إن SPT الخاص بـ Stripe هو، حتى وقت كتابة هذا التقرير، أول تنفيذ حيّ (live implementation) لهذا التصميم الخاص بالتفويض، وهو متوافق مع Delegated Payment Spec الخاص بـ OpenAI. يمكن للجهات المزودة لبرمجيات معالجة الدفع PSP الأخرى تنفيذ المواصفة، ما يجعل ACP منفتحًا على مستوى طبقة الدفع.

تم إطلاق ChatGPT Instant Checkout في سبتمبر 2025 للمستخدمين في الولايات المتحدة، لكن تم إيقافه في مارس 2026 بعد وصوله إلى تحويل شبه صفري. منذ ذلك الحين، انتقلت OpenAI إلى نموذج اكتشاف: يعرض ChatGPT المنتجات الآن ويعيد توجيه المستخدمين إلى مواقع التجار أو تطبيقاتهم لإتمام الدفع. يستمر ACP بدور أضيق، ويعمل على تشغيل تطبيقات مخصصة داخل ChatGPT لعدد صغير من كبار التجار.

يجب على التجار التقدم للانضمام، وتتحكم OpenAI فيما يظهر وما ترتيبه. ومع ذلك، يمنح هذا النموذج المُنتقى OpenAI تحكمًا من النهاية إلى النهاية في تجربة الاستخدام داخل المساعد، مع تفويض التسوية إلى معالجات طرف ثالث مثل Stripe.

يمثل Universal Commerce Protocol (UCP) الخاص بـ Google استراتيجية متباينة. أُعلن عنه بواسطة Sundar Pichai في مؤتمر NRF في 11 يناير 2026، وتم تطويره بالتشارك مع Shopify وEtsy وWayfair وTarget وWalmart، وتمت المصادقة عليه من أكثر من 20 شريكًا بما في ذلك Adyen وAmerican Express وBest Buy وMastercard وVisa وStripe وThe Home Depot.

يتم مواءمة UCP بشكل صريح مع بروتوكول مدفوعات الوكلاء الخاص بـ Google (AP2)، ومع معيار Agent2Agent (A2A)، ومع Model Context Protocol (MCP. إن دفع قابلية التوافق هذا هو محاولة مقصودة لاحتلال موقع الصدارة من ناحية الفهرسة والوصول. تعمل Google Pay كوسيلة دفع افتراضية، وتم الإعلان عن PayPal كخيار قادم.

من الناحية التقنية، تعمل UCP عبر ما يُعرف باسم UCP profile، وهو بيان قدرات (capability manifest). ينشر التجار مستند JSON منظمًا على /.well-known/ucp ضمن نطاقهم (domain)، يحدد طرق النقل وإمكانات الدفع عند نقطة الشراء (checkout capabilities) ومعالجات المدفوعات المدعومة. يقرأ الوكلاء هذه البيانات المعلنة مباشرة دون وسطاء.

تعكس البنية (architecture) الأولويات الاستراتيجية لـ Google. لدى Google اهتمام ضئيل بوساطة المعاملات، إذ سيؤدي ذلك إلى ضغط على الهامش، وتزايد المسؤولية والتدقيق التنظيمي. بدلًا من ذلك، تريد Google رؤية كاملة لويب التجارة. تضع UCP Gemini كطبقة اكتشاف أساسية لتسوق الوكلاء، بينما تظل شبه غير مرئية عند التسوية.

التباين مع ACP حاد. ACP هو بيئة مُنتقاة (curated) حيث تعمل OpenAI كحارس بوابة (gatekeeper)، ويجب على التجار التقدم للانضمام، ويتم تحسين التدفق داخل ChatGPT. تعمل UCP كمكتبة كتالوج مفتوحة: ينشر التجار أنفسهم، ويمكن لأي وكيل متوافق أن يستهلك الملفات التعريفية (profiles)، وتتحكم Google في سطح الاكتشاف لكنها لا تتحكم في الدفع نفسه.

الاحتكاك في الإعداد (Onboarding friction) أقل، وقد يكون الوصول أوسع تحت UCP، لكن التجار يتلقون دعمًا مباشرًا أقل. عمليًا، يبادل ACP الانفتاح مقابل التحكم، بينما يبادل UCP التحكم مقابل اتساع الفهرس والتوحيد على مستوى البروتوكول.

1.2 وكلاء يجرون معاملات مع وكلاء آخرين

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

لا توجد قوانين حماية للمستهلكين أو حقوق رد رسوم بطاقة (card chargeback rights) يمكن الاعتماد عليها. علاوة على ذلك، قد لا يكون الطرفان قد تفاعلا من قبل، ومع ذلك يجب أن يتبادلا القيمة بأمان. هذه هي المشكلة التي تحاول معايير Ethereum الجديدة معالجتها.

تم اقتراحها في 10 مارس 2026 من فريق dAI التابع لـ Ethereum Foundation بالتعاون مع Virtuals Protocol، ويُنشئ ERC-8183 كل معاملة بوصفها وظيفة من ثلاثة أطراف (three-party job). يكلف Client العمل، يقدم Provider التنفيذ، ويقوم Evaluator بإصدار شهادة على الاكتمال.

تُحتجز الأموال في escrow بعقود ذكية (smart-contract escrow) ولا تُفرج إلا عندما يوقّع Evaluator على الاكتمال. لا يحتاج Client ولا Provider إلى تقييم موثوقية الطرف الآخر؛ العقد يفرض النتيجة آليًا (mechanically). بالتوازي، يحدد ERC-8004 طبقة الهوية التي تدعم هذه الآلية.

ضمن ERC-8004، يسجل الوكلاء على السلسلة (on-chain) ويبنون درجة سمعة (reputation score) من سجل المعاملات. يؤدي ذلك إلى إشارة موثوقية قابلة للحمل (portable credibility signal) تستمر عبر التفاعلات. التصميم قوي من حيث المبدأ؛ لكن ما يزال تعثر (bootstrapping) اعتماد واسع النطاق هو الاختناق (bottleneck) العملي.

اليوم، تتركز معظم الاستخدامات الفعلية داخل منصة Virtuals Protocol. يقوم وكيل تنسيقي (orchestrator agent) يُسمى Butler بتفكيك المهام المعقدة إلى sub-jobs وتوجيهها إلى وكلاء متخصصين. لم يشارك مجتمع المطورين الأوسع حتى الآن على نطاق مماثل. يُعد ERC-8183 عمليًا محاولة لجعل هذا النمط مفتوحًا وبدون إذن (permissionless).

تتبع نقطة هيكلية واحدة مباشرة. يمكن للتجارة الإلكترونية بالتجزئة أن تعمل بثقة على مسارات البطاقات (card rails)، لأن المشترين البشر ما زالوا ضمن الحلقة. بالمقابل، فإن التجارة “وكيل-لوكيل” البحتة (pure agent-to-agent commerce) من المرجح أن تتطلب تسوية stablecoin، إذ تصبح رسوم البطاقات غير اقتصادية عند أحجام تذاكر صغيرة جدًا وتكرارات مرتفعة.

بروتوكولات التسوية: من الذي ينقل الأموال فعليًا

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

2.1 Delegated Payment Spec وSPT (Stripe)

يُوسّع Delegated Payment Spec الخاص بـ Stripe البنية التحتية للبطاقات بدلًا من استبدالها. عندما يفوض عميل وكيلًا، تقوم Stripe بتوفير (provisions) SPT يقوم الوكيل بتخزينه. عند وقت المعاملة، يعرض الوكيل هذا الرمز ذي صلاحية محدودة والذي له حد أقصى للمبلغ على التاجر.

ثم تجري التسوية عبر مكدس البطاقات الحالي لدى Stripe. من الخلفية، تتصل Stripe بـ Visa Intelligent Commerce وMastercard Agent Pay، اللذان يصدران رموز الشبكة الموجهة للوكلاء (agentic network tokens). يرى التجار سطح تكامل واحدًا بغض النظر عن شبكة البطاقات الموجودة تحت ذلك.

هذا النموذج مناسب جيدًا للمشتريات بالتجزئة القياسية وللكثير من مدفوعات الوكلاء إلى الوكلاء ذات القيمة المرتفعة، حيث تبقى chargebacks وغيرها من وسائل حماية المستهلكين أمورًا مرغوبة. لكنه غير مناسب بشكل سيئ لأنماط المدفوعات الدقيقة عالية التكرار مثل تدفقات الدفع آلة-إلى-آلة (machine-to-machine streaming payments).

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

2.2 Visa Intelligent Commerce وMastercard agentic tokens

أعادت كل من Visa وMastercard هيكلة طبقات الترميز (tokenisation) لديها للتعامل مع المدفوعات التي يبتدئها الوكلاء. تم استبدال أرقام البطاقات الحقيقية برموز مشفرة ديناميكية تتضمن بيانات وصفية (metadata) عن الوكيل المُفوض، بدءًا من الهوية إلى حدود الإنفاق ونوافذ الصلاحية.

كما يتم تحديد التجار المسموح لهم ضمن البيانات الوصفية للرمز، ما يتيح تحكمًا دقيقًا في الأماكن التي يمكن للوكلاء الدفع فيها. تبقى التسوية نفسها على مسارات البطاقات الموروثة (legacy card rails)، ما يحافظ على مسارات تكامل مألوفة ويتجنب بنية تحتية جديدة بالكامل.

تحركت كلتا الشبكتين بعيدًا عن مرحلة إثبات المفهوم (proof-of-concept). قامت Mastercard بمعالجة أول معاملة لوكيل محددة الهوية بالكامل في سبتمبر 2025، بالتعاون مع Commonwealth Bank في أستراليا. أكملت Visa نشرات أولية عبر الأسواق الأوروبية عبر برنامجها Agentic Ready.

يبدو أن البنية التحتية قادرة، لكن أرضية الرسوم (fee floor) تمثل قيدًا هيكليًا. لا تستطيع أي من الشبكتين دعم مدفوعات أقل من دولار بكفاءة عند الكثافة التي قد يطلبها مستقبل تجارة الوكلاء. علاوة على ذلك، تفرض طبقات التنظيم والامتثال قيودًا إضافية على التجريب في الطرف شديد الصغر من طيف المبالغ.

2.3 x402 (Coinbase)

في المقابل، ينطلق x402 من HTTP بدلًا من البطاقات. يعتمد على كود الحالة 402 “Payment Required”، الموجود في مواصفة HTTP منذ 1997 لكنه لم يُستخدم تقريبًا. عندما يطلب وكيل موردًا مدفوعًا، يرد الخادم برسالة 402 تحتوي على معاملات الدفع (payment parameters).

يقوم الوكيل بتوقيع تفويض (authorisation)، ويقوم Facilitator بإكمال تسوية on-chain ذرّية (atomic) في USDC أو غيرها من الرموز المدعومة، عادةً خلال نحو ثانيتين. لا توجد عملية إعداد حساب (account setup)، ولا توزيع مفاتيح API (API key distribution)، ولا تطبيق متطلبات KYC على مستوى البروتوكول. تقع الحوكمة لدى x402 Foundation، التي أُنشئت بواسطة Coinbase وCloudflare.

بحلول نهاية 2025، كانت x402 قد عالجت أكثر من 100 مليون معاملة عبر Base وSolana وPolygon. ومع ذلك، قدّر محللون في Artemis، في فبراير 2026، أن جزءًا كبيرًا من هذا الحجم يعكس التعامل مع الذات (self-dealing) واختبار البنية التحتية أكثر من كونه تجارة حقيقية.

يبلغ حجم الدفع السنوي (annualised payment volume) للبروتوكول نحو 600 مليون دولار، لكن التركّز ومشاكل جودة-الحجم (quality-of-volume issues) أمور جوهرية. ومع ذلك، لا يواجه x402 أرضية رسوم هيكلية؛ فقد صُمم صراحةً للمدفوعات الدقيقة (micropayments). الفجوة الأساسية ليست في التصميم التقني، بل في عمق تبنّي (adoption) التجارة الواقعية وكثافتها.

2.4 Nanopayments (Circle)

بروتوكول Nanopayments الخاص بـ Circle متوافق عمدًا مع x402، باستخدام HTTP 402 كمحفّز (trigger) مع إضافة طبقة تسوية مجمعة (batched settlement). بدلًا من تسوية كل دفعة على السلسلة (on-chain) بشكل فردي، يقوم المشترون بتمويل حساب Circle Gateway مسبقًا ويوقّعون رسائل EIP-3009 خارج السلسلة (off-chain) لكل معاملة.

إن التسوية المجمعة دوريا إلى blockchain تُوزّع تكلفة الغاز (gas cost) عبر العديد من المدفوعات، ما يجعل عمليات التحويل الصغيرة مثل $0.000001 قابلة للحياة اقتصاديًا. يتم دفع الغاز فعليًا مرة واحدة عند الإيداع بدلًا من دفعه لكل معاملة، وهي تحسين حاسم لحالات الاستخدام شديدة التكرار (ultra-high-frequency).

المقابل هو أن كلا الطرفين يجب أن يودعا في Circle Gateway، ما يخلق شبكة شبه مغلقة ضمن البنية الحالية. تم إطلاق Nanopayments على testnet في مارس 2026 عبر 12 سلسلة مدعومة. علاوة على ذلك، نموذج الرسوم جذاب للتدفقات المكثفة للمدفوعات الدقيقة إذا استطاعت Circle تقليل احتكاك الإعداد.

2.5 MPP Machine Payments Protocol (Tempo وStripe)

MPP، الذي شاركت Tempo وStripe في تأليفه (co-authored)، هو الأكثر طموحًا من بين تصاميم التسوية الخمسة. يستخدم HTTP 402 كمحفّز (trigger) ويسمح للتجار والوكلاء بالاختيار بين عدة مسارات تسوية ضمن إطار موحّد.

لم يعد المطورون بحاجة إلى ربط البنية التحتية لـ stablecoin أو fiat بشكل ثابت وقت البناء. بدلًا من ذلك، يمكن للوكيل أن يقرر في وقت التشغيل أي مسار يستخدمه بناءً على احتياجات المعاملة. تشمل الخيارات المتاحة تسوية stablecoin من Tempo، ومدفوعات Stripe SPT، ورموز شبكات البطاقات، ومدفوعات Bitcoin Lightning مدعومة بواسطة Lightspark.

الأهم: يقدم MPP بدائية “session” مشابهة لـ OAuth. يُفوض الوكيل مرة واحدة ويموّل حسابًا مسبقًا، ثم يتمتع بتسوية آلية فورية للتفاعلات اللاحقة دون وجود معاملة on-chain لكل دفعة.

تم تقديم المواصفة الأساسية إلى IETF باعتبارها تنفيذًا مرجعيًا لـ HTTP 402. عند الإطلاق في 18 مارس 2026، كان Payment Directory على mainnet قد دمج بالفعل أكثر من 100 خدمة. ومع ذلك، ما تزال أنماط التبنّي في مراحلها المبكرة.

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

واقع السوق: بروتوكولات تتقدم قبل النشر

3.1 أين يقف السوق

رغم إطلاق البروتوكولات بسرعة خلال الأشهر الستة الماضية، لا يزال الزخم التجاري محدودًا. في التسوية، تتصدر x402 من حيث عدد المعاملات، لكن حجم التجارة اليومية الفعلية يدور قرب $28,000. في التنسيق، تم إغلاق Instant Checkout التابع لـ ACP بعد تحويلات شبه معدومة.

تُظهر معايير جديدة مثل ERC-8183 وMPP نمطًا مشابهًا: السرد (narrative) يتقدم على النشر الفعلي. وصل القطاع إلى نقطة انعطاف حيث يوجد جزء كبير من بنية البروتوكول، لكن التطبيق التجاري المُوسَّع لم يبدأ بعد.

يتمثل الاختناق المركزي في التجزؤ على طبقة التنسيق. يواجه التجار معايير متعددة مستقلة، لكل منها SDKs مختلفة، وتدفقات تحقق (authentication flows) وقواعد امتثال مختلفة. ومع ذلك، يؤدي ذلك إلى رفع تكاليف التكامل وتثبيط التجريب.

تاريخيًا، تم حل هذا النوع من التجزؤ بواسطة طبقة تجميع (aggregation layer) توحّد الوصول عبر المعايير المتنافسة. قد تكون هذه الدورة مختلفة. يتم تحفيز المنصات التي لديها تدفق وكيل ذي معنى، بما في ذلك OpenAI وGoogle وMicrosoft، للحفاظ على أسطح مغلقة بدلًا من تسليم المستخدمين إلى جهات أخرى.

تتطور المنطق نفسه إقليميًا. تعمل الصين وجنوب شرق آسيا وكوريا واليابان على تطوير نظم بيئية مغلقة على شكل حلقات، ترتكز على super-apps أو منصات مهيمنة. والنتيجة الأكثر احتمالًا هي مجموعة من الأنظمة المغلقة الإقليمية المتوازية بدلًا من معيار عالمي مفتوح واحد.

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

3.2 أين تكمن الفرص على المدى القريب

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

في جانب التسوية، يتباين التجزؤ على طبقة التنسيق بشدة مع ضغط التوحيد على طبقة الدفع. كل وكيل، بغض النظر عن المنصة، يواجه في النهاية المشكلة نفسها: كيفية الدفع بكفاءة للطرفيات عبر مسارات مختلفة (rails).

لا يستطيع المطورون عمليًا الحفاظ على تكاملات دفع منفصلة لكل سطح قد تعمل عليه وكلاءهم. ومع زيادة تعدد المنصات، تتصاعد الضغوط الاقتصادية نحو تكامل دفع واحد موحّد يختزل تعقيد المسارات الكامنة.

وهذا يحدد متطلب منتج ملموس لوكالة متعددة المسارات (multi rail wallet) للوكلاء. ستستمر مسارات البطاقات مثل SPT ورموز Visa agentic tokens وMastercard agentic tokens في دعم التجارة التقليدية مع التجار. ستُرسِّخ مسارات stablecoin مثل x402 وMPP session payments APIs على السلسلة (on-chain) وتحويلات وكيل-لوكيل.

هاتان الفئتان موجودتان بالفعل ولن تتقاربا على مسار واحد في الأجل القريب. يقع عبء المرونة على جانب الوكيل، وليس على جانب التاجر. يختار التجار المسارات التي يدعمونها، وهي قرارًا نسبيًا ثابتًا وقابلًا للتحكم.

ثم تقوم الشركات بتزويد وكلائها بـ stablecoins وبطاقات مفوَّضة (delegated cards). يدفع الوكيل باستخدام أي مسار يقبله الطرف المقابل. تصبح المحفظة التي تتعامل بسلاسة مع كليهما، ضمن تكامل واحد، طبقة التمكين للوكلاء ذوي الاستخدام العام الذين يعملون عبر منظومات متنوعة.

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

تجارة الوكلاء إلى الوكلاء: فرصة غير مطوّرة

توجد الفرصة الثانية على مستوى طبقة التطبيقات في تجارة وكيل-إلى-وكيل. اليوم، ما يزال معظم نشاط A2A محصورًا داخل مسارات عمل (workflows) أصلية في عالم التشفير: الوكلاء يستعلمون بيانات على السلسلة، ويتفاعلون مع بروتوكولات DeFi، وينفذون معاملات blockchain.

لم يتوسع السوق بعد إلى خدمات واسعة في العالم الواقعي. ومع ذلك، من منظور بروتوكولي، يمكن للوكلاء بالفعل أن يكلّفوا بتنفيذ مهام مثل تحليل البيانات، وتوليد المحتوى، والبحث القانوني أو مراجعة الكود، مع الدفع لكل استدعاء (per-call basis).

الجزء الناقص هو منظومة المطورين. لا تزال أدوات بناء الخدمات لا تقوم بتغليف العروض كـ APIs قابلة للدفع من الوكلاء وبسعرة دقيقة مبنية على الاستخدام (fine-grained, usage-based pricing). وهذه هي الفجوة الحقيقية، وهي حاليًا واحدة من أقل المناطق إثارة للجدل (least contested) داخل هذه البنية.

هذه المساحة مقيدة بمشكلة البدء البارد (cold-start). تتطلب أنظمة الهوية مثل ERC-8004 كثافة كبيرة من المعاملات لتوليد درجات ثقة موثوقة. الوكلاء بدون سجل يفتقرون إلى وزن سمعة (reputational weight)، ما يحد من الأطراف القابلة للاستعداد للتعامل معهم.

توقعت Microsoft حوالي 1.3 مليار وكيل نشط بالذكاء الاصطناعي بحلول 2028. قاعدة اليوم المثبتة (installed base) أصغر بكثير بأوامر من حيث الحجم. لن تُغلق الفجوة تلقائيًا؛ إنها تحديدًا ما يبقي المنافسة على المدى القريب منخفضة ويجعل اتخاذ مواقع مبكرة جذابًا.

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

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

سواء اتسع اقتصاد A2A خارج نطاق التشفير، وما إذا كان HTTP 402 سيصبح طبقة تسعير عامة للبرمجيات، هي في الواقع نفس السؤال. كلاهما يعتمد على أن تصبح الوكلاء فاعلين اقتصاديين اعتياديين، وأن يتعاملوا على نطاق واسع مقابل أدلة خدمات غنية لكل استدعاء (per-call service directories).

الخلاصة: مكدس من طبقتين والبدائيات المفقودة

بالنظر إلى المستقبل، سيستمر تسوّق الوكلاء في التطور على مسارين منفصلين. ستعتمد الوكلاء الموجهون للمستهلكين الذين يشترون سلعًا لصالح البشر غالبًا على مسارات البطاقات، وسيتقدمون بوتيرة أطر تفويض المؤسسات (enterprise authorisation frameworks) وثقة المستخدمين في أسطح دفع جديدة.

بالتوازي، فإن مكدس بروتوكول التسوّق الوكيلي (agentic commerce protocol stack) للمدفوعات من برمجية إلى برمجية جاهز تقنيًا بالفعل على مسارات stablecoin. وهو الآن ينتظر نشر وكلاء وخدمات تتطلب تسوية برمجية عالية التكرار وعلى نطاق واسع.

تتمثل الحالة النهائية الأكثر احتمالًا في مكدس من طبقتين يتطور بالتوازي: طبقة تنسيق تحكم الاكتشاف والبدء، وطبقة تسوية تحكم تحويل القيمة. بالنسبة للبنّائين، تُعد أولوية استراتيجية هي اتساع التكامل عبر كلتا الطبقتين.

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

محفّز الوصول إلى نطاق تجاري ليس بروتوكولات أفضل. بل هو لحظة قيام المؤسسات بتفويض صلاحيات الإنفاق إلى وكلاء مع مسارات تدقيق قابلة للاحتساب (auditable trails)، وضوابط ميزانية، ومسؤولية واضحة عن عمليات الشراء التي حدث توجيهها بشكل خاطئ. عندما يُعبر هذا العتبة، تصبح موقفان بنيويان مهمان.

أولًا، محفظة لوكيل متعدد المسارات تدعم المدفوعات بـ stablecoin والبطاقات ضمن تكامل واحد. ثانيًا، دليل خدمات قابل للوصول لكل استدعاء (per-call service directory) يسمح للمطورين دون خلفية تشفيرية بكشف APIs لمشتري الوكلاء. كلاهما فرص مفتوحة اليوم، وكلاهما يصبحان ضروريين بمجرد تشغيل وكلاء الإنفاق على نطاق واسع.