تصور کنید یک عامل هوش مصنوعی برای تکمیل مأموریتش، نیاز دارد از ابزاری استفاده کند که صاحبش برای هر بار استفاده، مبلغی اندک می‌خواهد. در دنیای فعلی، این عامل نمی‌تواند خودش «پول» پرداخت کند و باید به کارت اعتباری برنامه‌نویسش تکیه کند، اما پروتکل x402 این بن‌بست را می‌شکند.
این استاندارد جدید، کد وضعیت ۴۰۲ (Payment Required) در پروتکل HTTP را که سال‌ها بلااستفاده مانده بود، به یک مکانیسم پرداخت فعال تبدیل می‌کند. به این ترتیب، یک عامل (Agent) — شبیه به یک کارمند دیجیتال که می‌تواند به‌طور مستقل تصمیم بگیرد و ابزارها را مدیریت کند — می‌تواند هزینه هر بار استنتاج (Inference) — یعنی همان لحظه‌ای که مدل واقعاً جواب تولید می‌کند، مثل خودِ آشپزی و نه دوره‌ی آموزش آشپز — یا دریافت داده را دقیقاً در لحظه پرداخت کند. این رویکرد اجازه می‌دهد تا پرداخت برای یک استنتاج واحد LLM یا یک فراخوانی فید داده، دقیقاً مشابه پرداخت برای منابع پردازشی (Compute) انجام شود و نیاز به سهمیه‌های پیش‌پرداخت یا اشتراک‌های مدیریت‌شده توسط انسان را از بین ببرد.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی اقتصاد مدل‌های زبانی اشاره کردیم، وابستگی به کلیدهای API متصل به کارت‌های اعتباری، بزرگ‌ترین مانع برای استقلال واقعی سیستم‌های عامل‌محور است. این موضوع در بررسی جامع‌تر ما درباره حذف دخالت انسان از تسویه حساب‌های عامل‌ها مورد تحلیل قرار گرفته است. اگر یک عامل نیاز داشته باشد عاملی دیگر را استخدام کند یا از یک ابزار شخص ثالث استفاده نماید، نمی‌تواند به‌راحتی و در لحظه برای آن سرویس «پرداخت» کند. طبق گزارش منتشر شده در dev.to، مدل‌های سنتی توسعه‌دهندگان را مجبور می‌کنند یا مبالغ کلانی را به‌صورت پیش‌پرداخت برای سهمیه‌های حجیم تهیه کنند یا منطق پیچیده‌ی اشتراکی را درون کد عامل بگنجانند. x402 با تبدیل پرداخت به یک جزء اول등급 از چرخه درخواست/پاسخ، این مشکل را حل می‌کند.
برای درک بهتر، فرایند را این‌گونه تصور کنید: عاملی یک API هواشناسی را فراخوانی می‌کند. به‌جای بررسی اشتراک ماهانه، سرور صرفاً چند سنت برای همان درخواست خاص مطالبه می‌کند. این یعنی تغییر مدل صورت‌حساب از «سطل‌های ماهانه» درشت‌دانه به «تراکنش‌های ذره‌بینی» برای هر فراخوانی مجزا.
گردش کار فنی x402
این سازوکار از طریق توالی خاصی از هدرهای HTTP و کدهای وضعیت عمل می‌کند که معنای HTTP/1.1 را گسترش می‌دهد:
- محرک: وقتی کلاینت بدون مدرک پرداخت کافی درخواست یک منبع را می‌دهد، سرور وضعیت
402 Payment Requiredرا برمی‌گرداند. - درخواست: سرور هدر
Payment-Requestرا ارسال می‌کند. این هدر شامل جزئیاتی چون مبلغ، نوع ارز، گیرنده پرداخت و یک کد یک‌بار مصرف (Nonce) است تا از حملات تکرار (Replay Attacks) جلوگیری شود. - اثبات: کلاینت یک مدرک پرداخت تهیه می‌کند — مانند یک تراکنش امضا شده یا رسید از یک پردازشگر پرداخت — و درخواست را با هدر
Paymentکه حاوی این مدرک است، مجدداً ارسال می‌کند. - تأیید: سرور پس از اعتبارسنجی امضا و کد یک‌بار مصرف، وضعیت
200 OKرا برگردانده و درخواست را پردازش می‌کند.
جزئیات پیاده‌سازی
بر اساس مستندات dev.to، این سیستم می‌تواند با استفاده از Node.js و Express در سمت سرور و با بهره‌گیری از استیبل‌کوین USDC روی شبکه Base L2 به‌عنوان لایه تسویه پیاده شود. برای جلوگیری از تأخیرهای شبکه بلاک‌چین که می‌تواند عملکرد API را مختل کند، از تأییدیه‌های امضا شده EIP-712 برای اعتبارسنجی خارج از زنجیره (Off-chain) استفاده می‌شود تا سرعت پاسخ‌دهی حفظ شود.
اجزای کلیدی این پیاده‌سازی عبارت‌اند از:
- مدیریت Nonce: سرور یک کد تصادفی ۱۶ بایتی (Hex) تولید می‌کند. در مثال ارائه شده، این کدها در یک Map با انقضای ۵ دقیقه‌ای ذخیره می‌شوند تا از درخواست‌های قدیمی و منقضی شده جلوگیری شود.
- ساختار EIP-712: مدرک پرداخت یک پیام امضا شده روی یک دامنه خاص است (
name: 'x402', version: '1') و شامل انواع داده‌هایی چون Nonce، مبلغ و آدرس توکن است. - یکپارچگی با USDC: سیستم از قرارداد USDC روی شبکه Base با آدرس
0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913استفاده می‌کند و برای محاسبات از دقت ۶ رقم اعشار آن بهره می‌برد. - اعتبارسنجی: سرور با استفاده از تابع
ethers.verifyTypedDataآدرس امضاکننده را بازیابی کرده و اطمینان حاصل می‌کند که با گیرنده مورد انتظار مطابقت دارد.
چرا معماری بومی HTTP اهمیت دارد؟
پروتکل x402 با حفظ استانداردهای HTTP، خاصیت «بدون وضعیت» (Stateless) را حفظ می‌کند. عامل‌ها هر فراخوانی HTTP را یک تعامل مجزا می‌بینند و افزودن هدر پرداخت، نیازی به مدیریت نشست (Session) یا ذخیره توکن‌های پیچیده فراتر از Nonce ندارد. این یعنی گیت‌وی‌های API، پروکسی‌ها و Service Meshها می‌توانند داده‌های پرداخت را به‌طور خودکار منتقل کنند و صورت‌حساب را در لبه شبکه (Network Edge) با مدل «اعتماد صفر» (Zero-trust) مدیریت نمایند.
علاوه بر این، این سیستم نسبت به نوع پول بی‌تفاوت است. اگرچه در مثال از USDC استفاده شده، اما همین منطق برای پرداخت‌های فیات از طریق Stripe، USDC روی Base یا حتی دفاتر داخلی اختصاصی شرکت‌ها صادق است. تنها شرط، توافق عامل و سرور بر سر روش اعتبارسنجی است.
این سطح از جزئیات اجازه می‌دهد قیمت‌گذاری تا حد ۰.۰۰۳ دلار به‌ازای هر توکن (Token) — تکه‌های کوچکی از متن، مثل برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — کاهش یابد که دقیقاً با هزینه واقعی استنتاج مطابقت دارد. این رویکرد با جداسازی اعتبارسنجی پرداخت از پلتفرم صورت‌حساب ارائه‌دهنده، وابستگی به یک فروشنده خاص (Vendor Lock-in) را از بین می‌برد.
برای توسعه‌دهندگان، این به معنای ساخت عامل‌های «خودکفا» است که حتی هنگام خواب درآمد کسب می‌کنند. یک عامل می‌تواند قابلیت‌های خود را به‌عنوان یک سرویس HTTP عرضه کند و از سایر عامل‌ها برای هر تعامل هزینه بگیرد و بدین ترتیب یک اقتصاد ماشین-به-ماشین (Machine-to-Machine Economy) ایجاد کند.
این چرخش، فرض بنیادی اقتصاد هوش مصنوعی را تغییر می‌دهد. ما از دنیای «اشتراک‌های SaaS» به دنیای «پرداخت‌های کاربردی اتمی» می‌رویم. در این مدل، عامل دیگر صرفاً مصرف‌کننده یک سرویس نیست، بلکه به یک بازیگر مالی تبدیل می‌شود که می‌تواند بودجه و جریان‌های درآمدی خود را مدیریت کند.
برای پیاده‌سازی فعلی، توسعه‌دهندگان می‌توانند از کتابخانه ethers.js برای اعتبارسنجی امضا و web3.py برای امضای پرداخت در سمت کلاینت استفاده کنند. جریان کار کلاینت شامل دریافت Nonce از پاسخ ۴۰۲، امضای ساختار EIP-712 با یک کلید خصوصی و ارسال مجدد درخواست با امضای حاصله است.
گام بعدی شما
- اگر توسعه‌دهنده API هستید، بررسی کنید که آیا می‌توانید کد ۴۰۲ را برای مدل‌های پرداخت خرد در لایه گیت‌وی خود پیاده کنید.
- کتابخانه ethers.js را برای یادگیری نحوه امضای داده‌های ساختاریافته (Typed Data) مطالعه کنید.
- مدل‌های درآمدی «پرداخت به‌ازای هر توکن» را به‌جای اشتراک‌های ماهانه در پروژه‌های عامل‌محور خود تست کنید.
اما زیرساخت‌های پرداخت این تحول تنها بخشی از ماجراست؛ اثر این مدل بر کاهش هزینه‌های استنتاج در مقیاس کلان را در گزارش بعدی بررسی خواهیم کرد.
گفتگو