新时代 لدفع وكيل الذكاء الاصطناعي: كيف يبني x 402 و AP 2 و ERC- 8004 معًا أساس الاقتصاد الآلي؟

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

هذه العقبات أدت إلى ظهور جيل جديد من البروتوكولات—x 402، Agent Payments Protocol (AP 2)، وERC-8004—والتي تبني أساسًا موثوقًا لتبادل القيمة في الاقتصاد الآلي القادم. في هذا المقال، سنستعرض المبادئ التقنية، وسيناريوهات التطبيق، والوضع البيئي لهذه البروتوكولات الثلاثة، ونكشف كيف تشكل معًا مشهد الدفع في اقتصاد وكلاء الذكاء الاصطناعي المستقبلي.

![] ( https://img-cdn.gateio.im/social/moments-f 8 a 84661 da 3 b 3223 c 824 ab 2 c 2 cadc 3 f 7)

( x 402: بروتوكول دفع داخل السلسلة أصلي لـ HTTP

تم تطوير x 402 بواسطة Coinbase، ويكمن ابتكاره الأساسي في تفعيل رمز الحالة HTTP 402 غير المستغل (“PaymentRequired”)، حيث يتم تضمين منطق الدفع بشكل أصلي في تدفق طلبات واستجابات صفحات الويب، مما يحقق “الدفع عند استدعاء واجهة البرمجة”، ويتم التسوية عبر عملة مستقرة أو عملات مشفرة أخرى، لحل مشكلة الاحتكاك العالي في الدفع التقليدي.

) # شرح البروتوكول

نظرًا لأن x 402 مبني على رمز الحالة HTTP 402، فهو بروتوكول مفتوح يعتمد على بنية العميل/الخادم. العميل هو المشتري للخدمة أو السلعة، والخادم هو البائع. وبناءً على هذه البنية، توفر Coinbase خدمة الوسطاء ### Facilitators ### للبائعين، لتبسيط عملية التحقق وتسوية المدفوعات بين المشترين والبائعين.

نأخذ كمثال خادم Canza (الذي يقدم معلومات تداول عبر الذكاء الاصطناعي) والمتصدر في x 402 scan. يبدأ المستخدم بإرسال طلب من العميل للوصول إلى خدمة Canza المدفوعة.

![] ( https://img-cdn.gateio.im/social/moments- 4 f 562918407 b 8 c 6 d 44 d 85 aaf 72 de 30 b 6)

بعد ذلك، يستخدم خادم Canza استجابة HTTP 402 لتعريف متطلبات الدفع: يجب على العميل تقديم X-PAYMENTHeader والدفع عبر USDC على سلسلة Base. كما هو موضح في الصورة التالية:

![] ( https://img-cdn.gateio.im/social/moments- 72 db 5 ed 3693 dcad 8223 f 342 f 1 be 14558)

يقوم العميل بتحليل محتوى 402 ResponseJSON، ثم تذكير المحفظة المستخدم بالتوقيع على رسالة TransferWithAuthorization (يتم تنفيذها عبر ERC-3009). تسمح هذه الرسالة للموقع بتفويض عنوان EOA أو عنوان العقود الآجلة لطرف ثالث لإجراء تحويل بدون رسوم غاز من عنوان الموقع. في هذا المثال، سنفوض عنوان استلام Canza 0x4e9bCe2547A9491b09ed092c433B19888e665edB لتحويل USDC من محفظتنا.

![] ( https://img-cdn.gateio.im/social/moments-ced 25702 a 668725 f 0 d 611 e 908 bfaebb 0)

بعد توقيع المستخدم للرسالة، يستخدم العميل ترميز base64 لإرسال X-PAYMENTHeader مع Payload، ويتولى الوسطاء ( Facilitators ) التحقق من Payload عند استلامه من قبل خادم Canza، ثم تتم تسوية الدفع على السلسلة. بعد تأكيد الدفع من قبل خادم Canza، يحصل المستخدم على الخدمة المطلوبة.

يمكن تلخيص سير عمل بروتوكول x 402 كما يلي:

![] ( https://img-cdn.gateio.im/social/moments-aa 24950 f 66 af 54874 bd 099 ad 64 a 9 dbe 8)

من الجدير بالذكر أن بروتوكول x 402 يدعم الدفع عبر عدة سلاسل (Base، Avalanche، وغيرها من سلاسل EVM، وSolana) باستخدام عدة أصول مشفرة (يجب أن تدعم ERC-3009، والافتراضي هو USDC)، ويكفي أن يقوم الخادم بالإعداد المناسب:

![] ( https://img-cdn.gateio.im/social/moments- 9 bef 6355 fe 7269 cc 5 ac 08 f 119377 c 363)

( Agent Payments Protocol (AP 2): نظام دفع موثوق لبيئة الوكلاء

AP 2 هو إطار دفع مفتوح مبني على بروتوكول التواصل بين الوكلاء (A2A) وتوسعة Model Context Protocol (MCP). يهدف بشكل أساسي إلى حل ثلاث مشكلات رئيسية في تجارة الوكلاء: التحقق من الموافقة (إثبات حصول الوكيل على إذن المستخدم)، الأصالة (ضمان أن التداول يعكس احتياجات المستخدم الحقيقية)، والمسؤولية في التداول (تحديد المسؤولية في حال النزاع)، لتحقيق تداول آمن بين AIAgent وأي تاجر متوافق مع الامتثال.

تدور عملية عمل بروتوكول AP 2 حول مفهوم التفويض الرقمي ) Mandates ###، وهي عقود رقمية مقاومة للتلاعب وموقعة بالتشفير، وتعمل كدليل قابل للتحقق على تعليمات المستخدم. وتنقسم إلى ثلاثة أنواع:

1. تفويض النية ( Intent Mandate )

مناسب للتداول الآلي في غياب المستخدم. يقدم المستخدم تعليمات مسبقة للوكيل مع شروط واضحة، مثل “شراء تذكرة حفلة موسيقية بميزانية لا تتجاوز 500 ريال”.

![] ( https://img-cdn.gateio.im/social/moments-a 370234 d 3 d 86 da 6913 cc 5 e 3338930569)

2. تفويض سلة التسوق ( Cart Mandate )

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

![] ( https://img-cdn.gateio.im/social/moments- 720852 d 4 fe 6 f 0636 e 2 d 64271993973 ab )

3. تفويض الدفع ( Payment Mandate )

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

![] ( https://img-cdn.gateio.im/social/moments- 810 a 9480851 e 7 e 4 ef 2 a 7 ae 46 e 7 eb 4 e 24)

( ERC-8004: نظام التعريف والسمعة اللامركزي لوكلاء الذكاء الاصطناعي

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

تم تصميم ERC-8004 حول ثلاثة سجلات تسجيل خفيفة الوزن، كل سجل مسؤول عن جانب مختلف من نموذج الثقة:

1. سجل الهوية (Identity Registry)

يتم تنفيذه بناءً على معيار ERC-721، مع توسيع وظيفة URIStorage، مما يسمح بتوافق هوية الوكيل مع نظام NFT الحالي.

![] ) https://img-cdn.gateio.im/social/moments- 7251 bc 0031726 b 9 d 8 d 1 acee 3 c 5257 ff 6###

يسجل كل وكيل الذكاء الاصطناعي نفسه عبر دالة register، ويحصل على agentId فريد (أي tokenId الخاص بـ ERC-721). عند التسجيل، يجب على الوكيل تقديم tokenURI يشير إلى ملف التسجيل الخاص به (Agent Registration File)، والذي يتبع تنسيق JSON موحد ويحتوي على اسم الوكيل، ووصفه، ونقطة النهاية، ونموذج الثقة المدعوم.

2. سجل السمعة (Reputation Registry)

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

![] ( https://img-cdn.gateio.im/social/moments- 3 f 55 c 5102 f 78 dd 664 faf 90 fceff 7 f 016)

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

3. سجل التحقق (Validation Registry)

يوفر HOOK عام لطلب وتسجيل نتائج التحقق المستقل، ويدعم آليات تحقق متعددة مثل الرهن الاقتصادي (إعادة تنفيذ المهمة من قبل المدققون)، وإثباتات التشفير (إثبات TEE، والتحقق zkML، وغيرها). يسمح هذا التصميم بتعايش آليات تحقق مختلفة في نفس البيئة حسب متطلبات الأمان.

واجهة عقد سجل التحقق بسيطة نسبيًا، وتحتوي بشكل أساسي على دالتين: ValidationRequest لتقديم طلب التحقق، وValidationResponse لتسجيل نتيجة التحقق.

يعد ERC-8004 بروتوكول طبقة الهوية لبيئة وكلاء الذكاء الاصطناعي. يوفر هوية قابلة للتحقق، ونظام سمعة، وآلية تسجيل لوكلاء الذكاء الاصطناعي داخل السلسلة، وهو أساس بناء الثقة في الاقتصاد الآلي.

تشكل x 402، وAP 2، وERC-8004 معًا نظام دفع متكامل لوكلاء الذكاء الاصطناعي: ERC-8004 يحل مشكلة هوية الوكيل، x 402 يحل مشكلة “كيفية استخدام العملات المشفرة في المدفوعات الصغيرة عالية التكرار”، وAP 2 يوفر إطارًا آمنًا وموحدًا لبروتوكول الدفع x 402، ويحدد حدود السلوك الاقتصادي المستقل لوكلاء الذكاء الاصطناعي، مما يتيح لهم معالجة المعلومات، وامتلاك الأصول، والتصرف بها، والمشاركة الفعلية في تبادل القيمة التجارية، وبالتالي نشوء شكل جديد من الاقتصاد يقوده الذكاء الاصطناعي بشكل مستقل.