مدفوعات وكلاء الذكاء الاصطناعي: سباق معايير x402 في عام ٢٠٢٦

يمكن لوكلاء الذكاء الاصطناعي الآن الدفع مقابل الأشياء بأنفسهم. في ١٤ يوليو ٢٠٢٦، أعلنت مؤسسة Linux Foundation عن تشغيل x402 Foundation بـ ٤٠ عضواً، لإدارة معيار مفتوح يسمح للوكيل بتسوية عملية دفع عبر HTTP بسيط.^١ وهو واحد من خمسة مخططات دفع للوكلاء متنافسة على الأقل في السوق حالياً.

ملخص

بروتوكول x402 — الذي ساهمت به Coinbase لمؤسسة Linux Foundation — يعيد تفعيل رمز حالة HTTP 402 Payment Required الذي ظل خاملاً لفترة طويلة، بحيث أن وكيل الذكاء الاصطناعي الذي يصل إلى API أو خدمة مدفوعة يتلقى استجابة 402، ويقوم بتسوية الرسوم، ثم يعيد محاولة الطلب، دون الحاجة إلى تسجيل حساب أو إدخال يدوي للبطاقة.^١٢ وقد انطلقت المؤسسة الحاكمة الجديدة في ١٤ يوليو ٢٠٢٦ بـ ٤٠ عضواً، بما في ذلك الأعضاء المميزون Visa و Mastercard و Stripe و Google و AWS و Coinbase.^١

لكن x402 ليس وحده. فقد تم إطلاق Agent Payments Protocol (AP2) من Google في سبتمبر ٢٠٢٥، وظهر Agentic Commerce Protocol (ACP) من OpenAI و Stripe في نفس الشهر، كما أطلقت كل من Mastercard و Visa مخططات وكلاء لشبكات البطاقات في أبريل ٢٠٢٥.^٣٤٥٦ وتقدر McKinsey أن التجارة الوكيلية قد تدفع مبيعات عالمية تتراوح بين ٣ تريليون إلى ٥ تريليون دولار بحلول عام ٢٠٣٠.^٧ وتتداخل هذه المعايير بقدر ما تتنافس — وقد قامت معظم شبكات البطاقات الكبرى بتحوطها من خلال الانضمام إلى عدة معايير في وقت واحد.

ما ستتعلمه

• ماهية بروتوكول x402 وكيف يقوم الوكيل بالدفع من خلاله فعلياً
• ما الذي غيره إطلاق x402 Foundation في ١٤ يوليو ٢٠٢٦
• كيف يقارن x402 بـ AP2 و ACP و Mastercard Agent Pay ومخطط Visa
• أساسيات حواجز الحماية — التفويضات، ومعرفات الوكلاء الموثقة، وسقوف الإنفاق — التي تهم المطورين
• ما إذا كان السوق يتجه نحو التقارب أو التجزئة

لماذا يهم هذا الآن

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

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

المخاطر كبيرة. تشير أبحاث McKinsey إلى أن التجارة الوكيلية ستصل إلى ٣ تريليون إلى ٥ تريليون دولار عالمياً بحلول عام ٢٠٣٠، مع ما يصل إلى تريليون دولار في إيرادات التجزئة المنسقة في الولايات المتحدة وحدها.^٧ هذا سوق يتم توصيله قبل وجود معظم القواعد.

ما هو x402 فعلياً

x402 هو معيار دفع مفتوح يدمج المعاملة مباشرة في طلب HTTP. وهو يعيد استخدام رمز الحالة 402 Payment Required، الذي تم حجزه للاستخدام المستقبلي في مواصفات HTTP الأصلية ولكنه ظل خاملاً لعقود.^١٢

التدفق بسيط. يطلب الوكيل مورداً — نقطة نهاية API مدفوعة، على سبيل المثال. يستجيب الخادم بـ 402 وتفاصيل الدفع. يقوم الوكيل بتسوية الرسوم من محفظة مصرح بها مسبقاً ويعيد محاولة الطلب نفسه، والذي ينجح الآن. لا حاجة لإنشاء حساب، ولا تدفق شراء مفتاح API، ولا حاجة لبشر يكتبون رقم البطاقة.^١

قدمت Coinbase معيار x402 في ورقة بيضاء في مايو ٢٠٢٥ وصممته ليكون محايداً تجاه طريقة الدفع: فهو يدعم كل شيء بدءاً من البطاقات التقليدية وصولاً إلى العملات المستقرة.^١٢ من الناحية العملية، تمت التسويات المبكرة بشكل كبير باستخدام العملات المستقرة — USDC على شبكة Base التابعة لـ Coinbase — لأنها تُسوى في ثوانٍ وبجزء بسيط من السنت، وهو ما يناسب المدفوعات الصغيرة عالية التردد وبسرعة الآلة بشكل أفضل من شبكات البطاقات.

إطلاق مؤسسة x402

الخبر الأساسي يتعلق بالحوكمة، وليس البروتوكول نفسه. في ١٤ يوليو ٢٠٢٦، أعلنت Linux Foundation عن الإطلاق التشغيلي لمؤسسة x402 واكتمال مساهمة Coinbase في البروتوكول.^١ كانت المؤسسة قد أشارت إلى نيتها في التأسيس في أبريل ٢٠٢٦؛ وبحلول الإطلاق التشغيلي، انضمت ٤٠ منظمة.^١

تبدو قائمة الأعضاء المميزين وكأنها هدنة بين المنافسين: Adyen، وAmazon Web Services، وAmerican Express، وCircle، وCloudflare، وCoinbase، وFiserv، وGoogle، وMastercard، وMonad Foundation، وMoonPay، وRipple، وShopify، وSolana Foundation، وStellar Development Foundation، وStripe، وVisa.^١

"أصبحت وكلاء الذكاء الاصطناعي والأنظمة الآلية مشاركين نشطين في الاقتصاد العالمي، ومع ذلك كانوا يفتقرون إلى طريقة أصلية وآمنة لإجراء المعاملات،" قال جيم زملين، الرئيس التنفيذي لـ Linux Foundation، واصفاً الإطلاق بأنه خطوة للحفاظ على "طبقة الدفع في الإنترنت" محايدة وخالية من الارتباط بمورد معين.^١ نقل x402 تحت حوكمة Linux Foundation هو الممارسة المعتادة للمصادر المفتوحة: فالإشراف المحايد هو الطريقة التي يكتسب بها البروتوكول الثقة من المنافسين الذين لن يتبنوا أبداً مخططاً مملوكاً لمنافس لهم.

المعايير الأخرى: AP2 و ACP وشبكات البطاقات

x402 هو مدخل واحد في مجال مزدحم. وتتخذ المعايير الأخرى مناهج معمارية مختلفة لنفس المشكلة — وهي إثبات أن الوكيل مفوض بإنفاق أموال المستخدم.

المعيار	الداعم	تاريخ الإطلاق	النهج
x402	Coinbase ← Linux Foundation	البروتوكول مايو ٢٠٢٥؛ المؤسسة ١٤ يوليو ٢٠٢٦	استجابة HTTP 402 تحفز عملية الدفع؛ من البطاقات إلى العملات المستقرة١٢
AP2 (بروتوكول مدفوعات الوكلاء)	Google	١٦ سبتمبر ٢٠٢٥	ثلاث "تفويضات" موقعة (النية، العربة، الدفع) كوثائق اعتماد قابلة للتحقق من W3C٣
ACP (بروتوكول التجارة الوكيلية)	OpenAI + Stripe	٢٩ سبتمبر ٢٠٢٥	معيار مفتوح لعمليات الدفع التي يبدأها الوكيل؛ Apache 2.0٤
Agent Pay	Mastercard	٢٩ أبريل ٢٠٢٥	"رموز وكيلية" (Agentic Tokens) توسع خدمة ترميز MDES الخاصة بـ Mastercard٥
Intelligent Commerce	Visa	٣٠ أبريل ٢٠٢٥	فتح شبكة Visa للوكلاء باستخدام بيانات اعتماد مرمزة، والتحقق من الهوية، وضوابط الإنفاق؛ أضاف بروتوكول الوكيل الموثوق (أكتوبر ٢٠٢٥) التحقق من الوكيل من جانب التاجر٦

يظهر هنا معسكران من التصميم. شبكات البطاقات — Mastercard و Visa، اللتان أعلنتا في غضون يوم واحد من بعضهما في أواخر أبريل ٢٠٢٥ — تعملان على توسيع أنظمة ترميز البطاقات والهوية الحالية لتشمل الوكلاء، مع إبقاء المعاملات على المسارات التي تسيطران عليها بالفعل.^٥٦ أما البروتوكولات المفتوحة — x402 و AP2 و ACP — فتحاول تحديد طبقة محايدة يمكن لأي وسيلة دفع الربط بها.

يعد AP2 من Google الأكثر هيكلة بين النهج المفتوحة. فهو يمثل كل عملية شراء على شكل ثلاثة تفويضات موقعة تشفيرياً — تفويض النية (ما طلبه المستخدم)، وتفويض العربة (ما جمعه الوكيل)، وتفويض الدفع (ما يتم تحصيله) — حيث يتم حمل كل منها كوثيقة اعتماد قابلة للتحقق من W3C.^٣ والنتيجة هي سلسلة قابلة للتدقيق من تعليمات المستخدم إلى عملية الخصم النهائية، وهو أمر بالغ الأهمية عندما يكون المشتري عبارة عن برنامج.

والأهم من ذلك، أن هذه الأنظمة ليست متنافية. فكل من Mastercard و Visa عضوان متميزان في مؤسسة x402، وتقوم Mastercard بدمج عملها في عرض "Agent Pay for Machines" الذي يتوافق مع x402.^١ كما أن Google، التي ينافس بروتوكول AP2 الخاص بها بروتوكول x402 من الناحية المفاهيمية، هي أيضاً عضو متميز في x402.^١ لقد انضمت عمالقة البطاقات إلى كل شيء تقريباً — وهو تحوط يشير إلى أنه لا أحد متأكد بعد من المعيار الذي سينتصر.

ماذا يعني هذا لمطوري الوكلاء

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

هوية وكيل مُحققة. تقوم Visa بالتحقق من هوية الوكيل من خلال بروتوكول الوكيل الموثوق (Trusted Agent Protocol)؛ حيث يقوم AP2 بتوقيع التفويضات باستخدام مفتاح المستخدم أو الوكيل.^٣٦ تحتاج نقطة نهاية الدفع إلى معرفة أي وكيل يقوم بالاتصال وبناءً على سلطة مَن — وهي نفس مشكلة الهوية التي تعالجها الصناعة بشكل منفصل من خلال مخططات لمنح الوكلاء هوية تشفيرية.

تفويضات وصلاحيات محددة النطاق. تقوم تفويضات النية والعربة (Intent and Cart Mandates) في AP2 بتشفير ما سُمح للوكيل بشرائه بالضبط، بحيث يمكن للتاجر رفض أي عملية دفع تخرج عن تعليمات المستخدم.^٣ هذا هو المعادل في الدفع لنطاق OAuth والتفويض المدار من قبل المؤسسة التي تعمل بروتوكولات أدوات الوكلاء على تعزيزها بالتوازي.

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

الخلاصة العملية: تعامل مع معيار الدفع كخلفية (backend) قابلة للتوصيل، وليس كرهان أساسي. ابنِ منطق إنفاق وكيلك — الهوية، التفويضات المحددة، الحدود القصوى، بوابات الموافقة — كطبقة تتحكم فيها أنت، واجعل بروتوكول التسوية الموجود بالأسفل قابلاً للاستبدال. مع وجود أكثر من خمسة معايير مفعلة وشبكات البطاقات التي تتحوط عبر جميعها، فإن الرهان على فائز واحد في البنية التحتية هو الخطوة الأكثر مخاطرة المتاحة.

تقارب أم تفتت؟

القراءة المتفائلة هي التقارب. وضع x402 تحت مظلة مؤسسة Linux، مع وجود Visa وMastercard وGoogle وStripe جميعاً على الطاولة، يعكس كيف تستقر معايير البنية التحتية المتنازع عليها عادةً — من خلال هيئة محايدة يمكن لجميع المنافسين التعايش معها. تشير العضويات المتداخلة إلى أن الصناعة تريد التشغيل البيني، وليس معركة "الفائز يأخذ كل شيء"، وهو ما يتردد صداه في التوجه الأوسع نحو التشغيل البيني للوكلاء الذي يظهر في التشريعات أيضاً.

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

في الوقت الحالي، يمتلك x402 القصة الأكثر مصداقية في الحوكمة المحايدة، ويمتلك AP2 أنظف نموذج تدقيق، وتمتلك شبكات البطاقات القدرة على التوزيع. هذا ليس سوقاً مستقراً — بل هو الفصل الافتتاحي.

الخلاصة

يمثل إطلاق مؤسسة x402 اللحظة التي انتقلت فيها مدفوعات الوكلاء من مرحلة التجربة إلى مرحلة البنية التحتية. ولكن مع وجود x402 و AP2 و ACP ومخططين لشبكات البطاقات جميعهم متاحون — وقيام أكبر شركات الدفع بالتحوط عبر عدة معايير في وقت واحد — فإن المعيار الذي سيفوز لم يُحسم بعد. قم ببناء هوية وكيلك، وحدود الإنفاق، وبوابات الموافقة كطبقة تملكها أنت، واجعل بروتوكول التسوية الموجود بالأسفل قابلاً للاستبدال حتى يحدد السوق اتجاهه.