تصور کنید یک عامل هوش مصنوعی برای تکمیل پروژهاش به یک ابزار تخصصی نیاز دارد و بدون اجازه شما، در کسری از ثانیه با یک عامل دیگر مذاکره کرده و هزینه آن را پرداخت میکند. این دیگر یک سناریوی تخیلی نیست، بلکه با معرفی پروتکل x402 (x402 protocol) به واقعیت تبدیل شده است. این پروتکل در واقع یک افزونه سبک برای HTTP است که پرداختهای خرد (Micropayments) را به ازای هر فراخوانی ممکن میکند.
با این تغییر، تعاملات هوش مصنوعی از اشتراکهای ماهانه و ایستا به یک اقتصاد پویا و غیرمتمرکز تغییر مسیر میدهد؛ جایی که نرمافزارها همزمان خریدار و فروشنده هستند. در این مدل، عاملهای نرمافزاری به عنوان مصرفکنندگان و ارائهدهندگان مستقل عمل میکنند و دیگر نیازی به واسطههای متمرکز برای مدیریت تراکنشها نیست. این رویکرد در واقع پاسخی عملی به این پرسش است که آیا عاملهای هوش مصنوعی میتوانند بدون واسطه خدمات یکدیگر را بخرند یا خیر.
همانطور که در تحلیلهای قبلی ما دربارهی اقتصاد ماشینها اشاره کردیم، جهان به سمت ثبت خدمات بهصورت غیرمتمرکز میرود. در مدلهای قدیمی، توسعهدهندگان به DNSهای ایستا یا درگاههای متمرکز متکی بودند، اما مدل A2A این ساختار را با کاتالوگهای روی زنجیره (On-chain) جایگزین میکند تا عاملها بتوانند بدون داشتن رابطه قبلی با مالک سرویس، قابلیتهای خاص را پیدا کنند. این مدل تکاملیافته از استانداردهایی است که در پروتکل Agent2Agent برای یکپارچهسازی ارتباطات میانعاملی تعریف شده بود.
زمینه: مقایسه A2A با درگاههای API سنتی
یک بازار عامل-به-عامل (A2A) در واقع ترکیبی از یک دفتر ثبت خدمات غیرمتمرکز و یک لایه پرداخت خرد است. این ساختار اجازه میدهد یک عامل (Agent) — شبیه به یک کارمند دیجیتال که میتواند بهطور مستقل تصمیم بگیرد و ابزارها را مدیریت کند — عامل دیگری را بهعنوان یک تابع از راه دور (Remote Procedure Call) فراخوانی کند. برخلاف APIهای سنتی، در اینجا خریدار و فروشنده ممکن است متعلق به اشخاص مختلفی باشند و در محیطهای کاملاً متفاوتی اجرا شوند.
طبق گزارش منتشر شده در dev.to در تاریخ ۷ سپتامبر ۲۰۲۶، تفاوتهای کلیدی این مدل با APIهای سنتی عبارت است از:
- کشف سرویس: جایگزینی DNSهای ایستا یا Service Meshها با کاتالوگهای روی زنجیره یا خارج از زنجیره که حاوی متادیتای مربوط به توافقنامههای سطح خدمات (SLA)، نسخهها و قیمتگذاری هستند.
- احراز هویت: جایگزینی کلیدهای API و پروتکل OAuth با شناسههای غیرمتمرکز (DIDs) مخصوص هر عامل و گواهینامههای قابل تأیید (Verifiable Credentials).
- پرداخت: تغییر از مدلهای فاکتوری یا اشتراکی به پرداختهای خرد به ازای هر فراخوانی که از طریق x402 و با استیبلکوینهایی (معمولاً USDC) تسویه میشوند.
- حکمرانی: انتقال مدیریت از ارائهدهندگان متمرکز به قوانین کنترلشده توسط DAO یا امضاهای چندگانه (Multi-sig) در مورد جداول هزینهها و حذف سرویسها از لیست.
- اعتماد: تکامل از گواهینامههای TLS و شهرت ارائهدهنده به امتیازات اعتبار روی زنجیره (On-chain Reputation) و گواهیهای اختیاری.
جزئیات: زیرساخت فنی
بر اساس مستندات فنی، این معماری برای عملکرد صحیح بر چهار رکن اصلی استوار است:
۱. قرارداد ثبت (Registry Contract): یک قرارداد هوشمند روی لایههای ۲ سازگار با EVM مانند Base. این قرارداد اطلاعاتی شامل شناسه سرویس (به فرمت bytes32)، آدرس مالک، یک URI متادیتا (که به IPFS یا Arweave لینک میشود)، قیمت هر فراخوانی بر حسب wei از توکن تسویه، و پرچمهای مربوط به نسخه یا منسوخ شدن سرویس را ذخیره میکند.
۲. سرویس متادیتا: ذخیرهسازی خارج از زنجیره با استفاده از IPFS، Filecoin یا یک CDN. این سرویس یک سند JSON را نگه میدارد که شامل نام عامل، توصیفات، طرحهای ورودی/خروجی (مثلاً base64 برای تصاویر)، URL نقطه پایانی (Endpoint) و جزئیات x402 مانند آدرس توکن و حداکثر هزینه (maxFee) است.
۳. لایه پرداخت x402: پیادهسازی استاندارد RFC 9450. در این لایه، کلاینت یک هدر Authorization: Bearer <x402-token> اضافه میکند. این توکن حاوی آدرس پرداختکننده، شناسه سرویس، یک Nonce و یک امضای ECDSA روی محتوای درخواست است.
۴. SDK کشف (Discovery SDK): یک کتابخانه سبک که برای خواندن قرارداد ثبت، بازیابی JSON متادیتا، اعتبارسنجی طرح (Schema) و آمادهسازی هدر امضا شدهی x402 استفاده میشود.
برای مثال، یک عامل طبقهبندی تصویر میتواند با قیمت ۰.۰۰۵ USDC به ازای هر فراخوانی ثبت شود. وقتی عامل دیگری به برچسب یک عکس JPEG نیاز دارد، ابتدا قیمت را از دفتر ثبت در شبکه Base استعلام میکند، سپس یک Payload را با کلید خصوصی خود امضا کرده و فراخوانی را از طریق هدر x402 اجرا میکند. ارائهدهنده در نهایت امضا را تأیید کرده و اطمینان حاصل میکند که مبلغ پرداخت شده با قیمت ثبت شده در قرارداد مطابقت دارد و سپس درخواست را اجرا میکند.
تحلیل توازنهای فنی (Trade-offs)
این سازوکار مجموعهای از مزایا و چالشهای خاص را به همراه دارد. در حالی که کشف غیرمتمرکز از سانسور جلوگیری کرده و اجازه میدهد عاملها بدون نیاز به مجوز به شبکه بپیوندند، اما تأخیری بین ۲۰۰ تا ۴۰۰ میلیثانیه برای استعلامهای روی زنجیره در شبکه Base ایجاد میکند. همچنین، هر عملیات خواندن یا نوشتن در دفتر ثبت نیازمند پرداخت Gas است.
در مورد پرداختها و خودمختاری، نکات زیر حائز اهمیت است:
- پرداختهای خرد: پروتکل x402 پرداخت واقعی «به ازای مصرف» را ممکن کرده و هزینههای اداری صدور فاکتور را حذف میکند. با این حال، توسعهدهندگان باید کیف پولها را مدیریت کرده و موجودی آنها را حفظ کنند؛ هرگونه شکست در پرداخت منجر به لغو فوری فراخوانی میشود.
- خودمختاری عاملها: عاملها میتوانند در زمان اجرا (Runtime) بهطور پویا درباره خدمات مذاکره کرده و آنها را ترکیب کنند. ریسک اینجاست که این ترکیب (Composition) باعث انتشار خطاها میشود و عیبیابی لاگهای بین-عاملی سختتر از کدهای یکپارچه (Monolithic) است.
- امنیت: هویت مبتنی بر DID احتمال جعل (Spoofing) را کاهش میدهد، اما اگر کلید خصوصی یک عامل لو برود، مهاجم میتواند خود را جایگزین آن عامل کرده و موجودی کیف پول را تخلیه کند.
- حکمرانی: بهروزرسانی هزینهها توسط DAO اجازه میدهد بازار بدون نیاز به فروشنده مرکزی تطبیق یابد، هرچند فرآیند تصمیمگیری میتواند کند باشد و احتمال ایجاد انشعاب (Fork) در دفتر ثبت وجود دارد.
از منظر فنی، این مدل فرض بنیادی ادغام هوش مصنوعی را تغییر میدهد. ما از کدهای یکپارچه و کلیدهای API متمرکز به سمت «خودمختاری عاملها» حرکت میکنیم. در این جهان، عاملها در زمان اجرا خدمات را بهصورت پویا ترکیب میکنند.
برای توسعهدهندگان، پیچیدگی عملیاتی مدیریت کیف پول، بهایی است که برای ایجاد یک مدل درآمدزایی بدون اصطکاک پرداخت میشود. توانایی عاملهای کوتاهمدت و بدون وضعیت (Stateless) برای تأمین قابلیتهای خاص در لحظه، اکوسیستم هوش مصنوعی منعطفتری نسبت به هر بازار متمرکزی ایجاد میکند.
برای پیادهسازی این سیستم در حال حاضر، شما به محیط web3.py و یک کیف پول دارای USDC روی شبکه اصلی Base (شناسه زنجیره ۸۴۵۳) برای تعامل با قراردادهای ثبت نیاز دارید.
گام بعدی شما
- بررسی مستندات RFC 9450 برای درک عمیقتر ساختار هدرهای پرداخت x402.
- آزمایش تعامل با قراردادهای ثبت روی شبکه تست Base برای کاهش هزینههای Gas.
- مطالعه درباره شناسههای غیرمتمرکز (DID) برای جایگزینی سیستمهای احراز هویت سنتی در پروژههای خود.
اما تأثیر این مدل بر کاهش هزینههای استنتاج در مقیاس کلان حتی جذابتر است — به تحلیل ما درباره بهینهسازیهای لایه استنتاج مراجعه کنید.
گفتگو