بحث جالاكسي البحثي: x402 و"لحظة ليفياثان" في اقتصاد الذكاء الاصطناعي

المصدر: Galaxy Research

المؤلف: Lucas Tcheyan، Vikram Singh

العنوان الأصلي: Agentic Payments and Crypto’s Emerging Role in the AI Economy

الترجمة والتنظيم: BitpushNews

مقدمة

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

في تقرير Galaxy Research الصادر في 2024 بعنوان «فهم تقاطعات العملات المشفرة والذكاء الاصطناعي»، اعتبرنا الوكالات الذكية أحد أكثر الاتجاهات الواعدة للنمو، وأشرنا إلى أنها «ملائمة جدًا لسيناريوهات العملات المشفرة — حيث يمكن للمستخدمين (أو الوكالات نفسها) إنشاء محافظ للتعامل مع خدمات أو وكالات أو أشخاص آخرين». في ذلك الوقت، كانت مجالات الوكالات لا تزال في مهدها، ومقيدة بثلاثة عوامل رئيسية: مستوى ذكاء نماذج الذكاء الاصطناعي الأساسية، والبنية التحتية التي تدعم تنفيذ المهام المعقدة، والوضوح التنظيمي المطلوب لتجاوز سيناريوهات Web3 الأصلية.

خلال أقل من عام، أحرزت هذه العوامل الثلاثة تقدمًا مذهلاً:

• ارتفاع مستوى ذكاء الذكاء الاصطناعي بسرعة، مما مكن الوكالات من إجراء «استنتاجات طويلة الأمد» وتنفيذ مهام معقدة بشكل مستقل وموثوق غير مسبوق.
• تطور أدوات الوكالة بشكل كبير، بما في ذلك بروتوكول سياق النموذج (MCP)، وبروتوكول الوكيل إلى الوكيل (A2A)، وبروتوكول المدفوعات الوكيل (AP2)، ومعايير x402 وغيرها من البروتوكولات الأساسية.
• توضيح البيئة التنظيمية بشكل متزايد، خاصة فيما يتعلق بالعملات المستقرة، مما سرع من دمج قنوات الدفع المشفرة مع الأنظمة التقليدية.

كل هذه التطورات فتحت الباب أمام الانتشار الواسع للوكالات الذكية التي تستخدم تقنية البلوكشين لإجراء المدفوعات. أحد أبرز التقدمات التي تدفع هذا الاتجاه هو ظهور معيار x402 والمعايير ذات الصلة بالدفع. تتيح هذه المعايير للوكالات الدفع مباشرة باستخدام العملات المستقرة أو الأصول المشفرة مقابل خدمات البيانات أو الخدمات الأخرى. ولتبسيط الأمور، سنطلق على هذه البروتوكولات مجتمعة اسم «معايير الدفع الوكيلة» (APS: Agentic Payment Standards).

باختصار، تفتح APS للوكالات طريقًا نحو الاقتصاد الرقمي الكامل على الإنترنت. من خلال APS، يمكن للوكالات أن:

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

بالإضافة إلى توسيع الوظائف، تلعب APS دورًا كجسر بين الاقتصاد على السلسلة وخارجها، مما يمكّن أي شركة من البيع لأسرع فئة من المستخدمين على الإنترنت — وهم الوكالات الذكية — ويعزز اعتماد العملات المستقرة في مجال المدفوعات.

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

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

معيار x402

الخلفية

في مايو من هذا العام، أطلقت Coinbase معيار x402، وهو بروتوكول يستخدم HTTP (لغة الاتصال الأساسية بين الخوادم) لتنفيذ المعاملات المشفرة ضمن تفاعلات الويب. سابقًا، كانت المعاملات على الويب تعتمد على مسارات الدفع التقليدية (مثل Visa وMastercard)، لكن x402 فتح الباب للدفع الذكي، مما يسمح باستخدام العملات المستقرة والعملات المشفرة للوصول إلى الخدمات الرقمية.

x402 يشير إلى رمز الحالة «HTTP 402 Payment Required»، الذي تم تضمينه في المواصفات الأصلية لبروتوكول الويب. على الرغم من أن رمز الحالة 402 كان موجودًا منذ البداية، إلا أنه ظل غير مستخدم تقريبًا بسبب نقص البنية التحتية الداعمة. بدلاً من ذلك، تم الاعتماد على بنية تحتية للدفع تكملها شركات مثل PayPal وStripe، تعتمد على مسارات الدفع التقليدية. على الرغم من أن هذه البنية ساهمت في تطوير التجارة الإلكترونية وخفضت الاحتكاك في عمليات الدفع، إلا أنها كانت منفصلة عن قدرات الشبكة الأصلية للإنترنت.

المصدر: ورقة بيضاء عن x402

الاختراق الرئيسي الذي حققه x402 هو أن أي شخص (بما في ذلك الإنسان أو الوكيل الذكي) يمكنه الآن دفع مقابل الخدمات عبر الإنترنت بسهولة أكبر. وفقًا لفريق التطوير، يهدف المعيار إلى «تمكين تدفق القيمة بشكل سلس عبر الإنترنت مثل تدفق المعلومات، سواء كان الفاعل فردًا، تطبيقًا، أو وكيلًا ذكيًا». وأوضحوا أن ذلك يتجلى بشكل رئيسي في تبسيط عملية طلب API. كما قال فريق Coinbase بشكل موجز: «دعونا نلغي مفاتيح API».

عملية الدفع

تُعد عملية الدفع باستخدام x402 سهلة الفهم، وتتكون من أربعة مكونات رئيسية:

1. العميل: الوكيل الذكي (أو برنامج المستخدم) الذي يطلق طلب الخدمة.

2. الخادم: مزود الخدمة الذي يرد على طلب 402 ويقدم الموارد المدفوعة في النهاية.

3. المنسق: الذي ينفذ و/أو يتحقق من الدفع.

4. البلوكشين: طبقة التسوية التي تتم فيها عملية نقل العملات المستقرة أو الأصول المشفرة.

المصدر: ورقة بيضاء عن x402

يُرسل الوكيل طلبًا إلى الخادم للحصول على منتج أو خدمة معينة (مثل اشتراك بث أو كتاب إلكتروني)، ويقوم الخادم بالرد بطلب «مطلوب الدفع» (HTTP 402). يتضمن الطلب معلومات مثل المبلغ المطلوب، نوع الرمز المميز المقبول، عنوان المحفظة لإرسال الدفع، وبيانات البلوكشين الذي ستتم عليه المعاملة.

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

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

x402 V2

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

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

هذه التغييرات تُمكن x402 من دعم أنماط أعمال أكثر تعقيدًا، بما في ذلك الاشتراكات، والدفع المسبق، والفوترة حسب الاستخدام، وسير عمل الوكيل متعدد الخطوات.

تقنية الدفع الذكي x402

تتكون تقنية x402 تدريجيًا من مكدس تقني متكامل. سرعة إصدار المشاريع والبنى التحتية تتزايد بشكل أسي، وفيما يلي نلخص أكبر عدد ممكن من المشاريع (وقد لا يكون كاملًا، ولا نؤيد أي منها، وإنما نعرضها كمراجع).

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

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

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

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

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

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

حالات الاستخدام المشفرة الناشئة

كما أشرنا سابقًا، شهدت أنشطة x402 زيادة أولية في أواخر أكتوبر وأوائل نوفمبر، ثم تراجعت تدريجيًا.

المصدر: Artemis Analytics

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

هذه هي جوهر المنتجات غير المرخصة في مجال التشفير. في البداية، تجذب حالات المضاربة المستخدمين، ثم تجذب المطورين، الذين يبدأون في تجربة التقنية وبناء تطبيقات تتجاوز حالات المضاربة. في الواقع، بعد استبعاد جميع المعاملات التي يمكن تصنيفها على أنها ألعاب أو تلاعب (كما تعرف Artemis Analytics بأنها معاملات ذاتية أو تكرارية واضحة)، أظهرت البيانات منذ بداية ديسمبر أن نسبة هذه المعاملات انخفضت إلى أقل من 50%.

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

حاليًا، تهيمن على هذه الخدمات مزودو خدمات API التي تدعم استدعاءات فردية، والتي كانت تتطلب اشتراكات سابقًا. على سبيل المثال، يمكن لوكيل المعاملات الدفعية أن يدفع حسب الطلب لمزود بيانات البلوكشين مثل Nansen أو محللي الذكاء الاصطناعي عبر API، لدعم تحليلات التشفير. بالإضافة إلى الوصول إلى البيانات، تتيح x402 للوكيلات الدفع مقابل خدمات البنية التحتية (مثل موارد الحوسبة) بطريقة قابلة للبرمجة، والتي يصعب تسعيرها أو أتمتتها عبر أنظمة اشتراك أو وسطاء يدويين. وقد أطلق مختبر Nous Research اللامركزي الرائد الدفع عبر x402 للوصول إلى نموذج Hermes 4 الخاص بهم.

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

السياق والوصول إلى البيانات

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

قدمت Cloudflare مثالًا مبكرًا على كيف يمكن أن يظهر هذا النموذج. بصفتها المزود الرئيسي للبنية التحتية التي تستضيف وتحمي معظم محتوى الإنترنت، أطلقت Cloudflare في 2024 آلية «الدفع مقابل الزحف عند الطلب»، التي تسمح للروبوتات وبرامج الزحف بالدفع مقابل الوصول، بدلاً من حظرها مباشرة.

بعد ذلك، أعلنت Cloudflare عن خطط لدمج هذه البنية التحتية مع معيار x402 (بالتعاون مع Coinbase لتأسيس مؤسسة x402)، مما يمكّن الوكيل من الدفع مباشرة باستخدام مسارات الدفع على الإنترنت. إذا تم توحيد هذا المعيار، فسيحول هذا النهج مشكلة التحكم في الوصول إلى آلية تعتمد على التسعير والسوق. باختصار، أصبح مشكلة قديمة فرصة محتملة لتحقيق الربح.

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

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

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

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

التجارة الإلكترونية

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

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

• مجموعة خدمات التجارة الذكية من Visa (المتوقعة في أوائل 2025) تتيح للمستهلكين إعداد بيانات بطاقة Visa الخاصة بهم في الوكيل الذكي، لاستخدامها في التسوق من طرف إلى طرف، والتكامل مع منصات مثل OpenAI وAnthropic.
• خدمات التجارة الوكيلية من PayPal (المتوقعة في أكتوبر 2025) تسمح للتجار باستخدام واجهات الوكيل مثل ChatGPT لبيع المنتجات، مع الحفاظ على آليات كشف الاحتيال، وحماية المشتري، وسير عمل التاجر.
• بروتوكول التجارة الوكيلية من Stripe (ACP)، الذي تم تطويره بالتعاون مع OpenAI وأُعلن عنه منتصف 2025، يحدد طريقة موحدة لبدء وإتمام عمليات الشراء بين الوكيل والتاجر، مع أقل قدر من التعديلات على تكامل Stripe.
• خدمة الدفع الوكيلية من Mastercard (أبريل 2025) تُحول بيانات العملاء إلى رموز، مما يمكّن أنظمة ذكاء اصطناعي مثل Microsoft Copilot من تنفيذ عمليات شراء مستقلة، مع التركيز المبكر على الاشتراكات، واستبدال الولاء، والمدفوعات القابلة للبرمجة.

في بعض الحالات، يمكن أن تقلل هذه المبادرات من الحاجة إلى بروتوكولات الدفع على السلسلة من خلال توسيع مسارات الدفع التقليدية لتشمل عمليات الوكالات الأصلية، أو قد تكون تكاملية. على سبيل المثال، يُعد بروتوكولان للدفع الذكي الأكثر شهرة حاليًا هما AP2 من Google وACP من Stripe. على الرغم من أن هذين المعيارين ليسا بعد الطريقة الرئيسية، إلا أن x402 يمكن دمجهما لدعم المدفوعات باستخدام العملات المستقرة عبر أي منهما (مثل استخدام A2A بين وكيلين، أو ACP بين تاجر ووكيل).

سنستعرض أدناه جهود Stripe في الدفع الذكي لتوضيح هذا النموذج بشكل أفضل.

جهود Stripe في الدفع الذكي

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

لدعم تفويض الدفع الآمن ضمن هذا الإطار، أدخلت Stripe رموز دفع مشتركة. على الرغم من استخدام كلمة «رمز» (Token)، فإن SPT ليست أصولًا مشفرة، ولا تمثل مسار دفع مستقل. بدلاً من ذلك، فهي تمثل تفويض دفع محدود النطاق، يسمح للوكيل بتفويض التاجر بخصم مبلغ محدود من حسابه باستخدام أي بنية تحتية يختارها. هذا يعني أن التسوية الأساسية يمكن أن تكون بأي شكل، من بطاقة الائتمان، إلى التحويل البنكي، إلى العملات المستقرة.

عملية دفع الرموز المشتركة

تمكن بروتوكولات ACP وSPT الوكيل من المشاركة في التجارة الإلكترونية مع الحفاظ على الضمانات التي تعتمد عليها الشركات، بما في ذلك كشف الاحتيال، وحل النزاعات، والاسترداد، والامتثال التنظيمي، ودعم العملاء. بالإضافة إلى ذلك، تقدم Stripe حزمة من هذه المكونات ضمن مجموعة التجارة الوكيلية (Agentic Commerce Suite)، لتوفير حل شامل للشركات التي ترغب في دعم عمليات الشراء بواسطة الوكيل دون إعادة تصميم بنية الدفع التحتية.

كيف يتعاون x402 مع ACP

الفرق الرئيسي بين تقنية التجارة الذكية من Stripe وx402 يكمن في النطاق وسياق المعاملة.

• x402 مخصص للدفع بين البرامج. يرى الوكيل سعرًا، يدفع تلقائيًا، ويحصل على حق الوصول إلى الخدمة فورًا. ينطبق ذلك على API، والبيانات، والأدوات الرقمية المستخدمة في سير العمل.
• أما ACP وSPT فمخصصان لشراء سلع أو خدمات مادية. تتسم هذه العمليات بأنها أطول، ويتحمل التاجر مسؤولية الاحتيال والاسترداد، وغالبًا ما تتطلب موافقة المستخدم قبل الدفع.

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

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

في هذا سير العمل، يلعب كل من x402 وACP أدوارًا مختلفة ولكن متكاملة. يقع x402 في بداية عملية الدفع، ويمكّن الموارد خارج نطاق العمليات التجارية التقليدية من الدفع بشكل مستقل.

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

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

الخلاصة

بدلاً من أن تدفع الدفع الذكي نحو انتقال كامل إلى المدفوعات على السلسلة بشكل فوري، من المرجح أن يعزز تدريجيًا، وبشكل كبير، اعتماد تقنية البلوكشين بشكل «صامت» إلى حد كبير في المستقبل. ساهمت العملات المستقرة في تسريع هذا التحول عبر تقليل الاحتكاك مع الأنظمة التقليدية، ووفرت بنية تحتية تُمكن من تجارب جديدة يصعب دعمها عبر قنوات الدفع التقليدية.

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

أثر معايير الدفع الذكي الأكثر مباشرةً والأقل وعيًا هو ليس في المعاملات التجارية، بل في إنتاج البرمجيات. لقد وصلت قدرات نماذج اللغة الحديثة إلى مستوى يجعل مشاركة الإنسان إلى حد كبير غير ضرورية في العديد من المهام غير الإنتاجية. اليوم، لم تعد المشكلة الرئيسية هي الذكاء أو التنفيذ، بل حقوق الوصول: شراء اشتراكات API، إدارة الحسابات، التعامل مع مفاتيح API، ودفع مقابل حزم الخدمات التي يُستخدم جزء كبير منها بشكل محدود. إذا استطاعت معايير الدفع الذكي القضاء على هذه الاحتكاكات — عبر «الدفع عند الطلب»، والدفع الآلي المستند إلى الآلة، بدلاً من الاشتراكات وإدارة المفاتيح اليدوية — فستتمكن من تقليل تكاليف التجربة بشكل جوهري، وتقليل قيمة العمل في البرمجيات الأساسية.

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

مع مرور الوقت، ستتغير الأسئلة من «هل يُستخدم البلوكشين» إلى «كيف وأين يُستخدم». لقد بدأ عمالقة الصناعة بالفعل في دمج قدرات الدفع الذكي، مع تجارب على العملات المستقرة والبنية التحتية على السلسلة، مما يشير إلى أن التسوية على السلسلة ستتعايش تدريجيًا مع البنى التحتية التقليدية. السؤال المفتوح هو: هل ستتركز هذه الأنشطة على سلاسل مرخصة تسيطر عليها كيانات مركزية أو اتحادات، أم ستُجرى على شبكات مفتوحة ولامركزية مثل إيثريوم أو سولانا؟ من المحتمل أن يكون كلاهما موجودًا.

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

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