عصر جديد لمدفوعات AI Agent: كيف يبني x402 وAP2 وERC-8004 معًا أساس الاقتصاد الآلي

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

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

x402: بروتوكول دفع على السلسلة أصلي لـ HTTP

تم إطلاق x402 من قبل Coinbase، وتكمن ابتكاره الأساسي في تفعيل رمز الحالة HTTP 402 غير المستغل بالكامل على الإنترنت ("Payment Required")، حيث يتم تضمين منطق الدفع بشكل أصلي في تدفق طلب-استجابة صفحة الويب، مما يحقق "الدفع عند استدعاء API"، ويتم التسوية باستخدام العملات المستقرة أو العملات المشفرة الأخرى، لحل مشكلة الاحتكاك العالي في الدفع التقليدي.

شرح البروتوكول بالتفصيل

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

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

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

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

بعد ذلك، يوقع المستخدم الرسالة، ويستخدم العميل X-PAYMENT Header المشفر بـ base64 لتقديم Payload، وعند استلام Canza للـ Payload، يقوم الوسيط (Facilitator) بالتحقق منه، ويقوم بتسوية الدفع على البلوكشين لصالح الخادم. بعد تأكيد الدفع من قبل خادم Canza، يقدم Canza الخدمة المطلوبة للمستخدم.

من خلال المثال أعلاه، يمكن تلخيص سير عمل بروتوكول x402 كما يلي:

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

Agent Payments Protocol (AP2): نظام دفع موثوق لبيئة الـ Agent

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

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

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

ينطبق على المعاملات الآلية عندما لا يكون المستخدم حاضرًا. يقدم المستخدم تعليمات تشغيل مسبقة للـ AI Agent، تتضمن شروطًا واضحة، مثل "شراء تذكرة حفلة موسيقية بميزانية لا تتجاوز 500 يوان".

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

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

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

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

ERC-8004: نظام هوية وسمعة لامركزي لـ AI Agent

ERC-8004 هو حل هوية لامركزي لـ AI Agent على Ethereum، يهدف إلى حل مشاكل التحقق من هوية AI Agent، وموثوقية سجل السلوك، وقابلية التحقق. بخلاف AP2، يركز ERC-8004 على بناء الثقة بين AI Agents، وليس فقط بين المستخدم وAI Agent والتاجر.

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

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

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

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

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

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

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

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

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

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

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

يشكل x402 وAP2 وERC-8004 معًا نظام دفع متكامل لـ AI Agent: يحل ERC-8004 مشكلة هوية AI Agent، ويحل x402 مشكلة "كيفية إجراء مدفوعات صغيرة عالية التردد بالعملات المشفرة"، بينما يوفر AP2 إطارًا آمنًا وموحدًا لبروتوكول الدفع x402، ويحدد حدود السلوك الاقتصادي المستقل لـ AI Agents، مما يتيح لهم معالجة المعلومات، وامتلاك وإدارة الأصول، والمشاركة فعليًا في تبادل القيمة التجارية، وبالتالي يولد شكلًا اقتصاديًا جديدًا مدفوعًا ذاتيًا من قبل الآلات.

استنادًا إلى خبرة Beosin في البحث الأمني وإدارة المخاطر في مجال AI Agent + Web3، توفر منصة تحليل مكافحة غسيل الأموال Beosin KYT التابعة لـ Beosin، والتي تراقب المعاملات على مدار الساعة، حلول امتثال AML على السلسلة شاملة وموثوقة للعديد من البورصات، وشركات Web3، والمؤسسات المالية. يمكن لـ AI Agent دمج Beosin KYT API، لإجراء تقييم شامل للمخاطر على عنوان الطرف المقابل قبل الدفع/المعاملة على السلسلة، وفهم سجل معاملاته السابقة والمخاطر المحتملة، وتجنب التورط في أصول مشفرة من محافظ خاضعة للعقوبات، أو عناوين عالية المخاطر معروفة، أو مسارات معاملات مشبوهة.

Beosin KYT

حاليًا، جمعت Beosin KYT أكثر من 4.7 billions من علامات العناوين، وتدعم الاستعلام عن 57 سلسلة عامة (مثل Base، Solana) وتحليل أكثر من 120 بروتوكول عبر السلاسل، مما يوفر دعمًا قويًا لأمان وامتثال مدفوعات ومعاملات الأصول المشفرة. لمزيد من المعلومات، يرجى زيارة:

عند تقديم الخدمات لمستخدمي بروتوكول x402 عبر العقود الذكية، يجب على المشاريع إجراء تدقيق أمني شامل للعقود، لزيادة الأمان إلى أقصى حد وتجنب خسارة الأموال. في السابق، أكملت Beosin تدقيقات أمنية لعدة مشاريع AI Agent + Web3 (مثل Inferium AI، Cult World، Tars AI)، وشملت التدقيق أمان كود العقد الذكي، وصحة منطق التنفيذ التجاري، وتحسين Gas لكود العقد، واكتشاف وإصلاح الثغرات، وغيرها من الجوانب، لدعم التطور الآمن لبيئة AI Agent + Web3.