اگر امروز یک سرویس تخصصی برای عامل‌های هوش مصنوعی می‌سازید، احتمالاً تصور می‌کنید سخت‌ترین بخش کار، کدنویسی یا مدیریت پرداخت‌هاست؛ اما واقعیت تلخ‌تر است. یک API آماده برای تولید، در بازه ۸ هفته‌ای آزمایش خود، دقیقاً ۰.۰۰ دلار از کاربران خارجی درآمد داشت. این سرویس که با نام token-risk.com شناخته می‌شود، یک رابط برنامه‌نویسی کاربردی (API) است که گزارش‌های ساختاریِ قطعی (Deterministic) از ریسک توکن‌های ERC-20 و آدرس‌های کیف پول در شبکه Base ارائه می‌دهد. مدل درآمدی آن به‌صورت پرداخت به ازای هر فراخوانی (Pay-per-call) است: عامل‌ها مبلغ ۰.۰۱ دلار USDC را بابت هر درخواست پرداخت می‌کنند و نکته کلیدی این است که هیچ نیاز به ثبت‌نام یا دریافت کلید API (API Key) نیست.
این آزمایش در زمانی رخ می‌دهد که کل صنعت در حال انتقال به سمت اقتصادهای «ماشین-به-ماشین» (Machine-to-Machine) است. این رویکرد در واقع تکامل همان مدل «خرید USDC به‌جای اشتراک» است که به دنبال حذف کلیدهای API برای تسهیل دسترسی عامل‌های خودمختار بود. در حالی که انسان‌ها از درگاه‌های پرداخت سنتی استفاده می‌کنند، عامل‌های هوش مصنوعی به لایه‌ای متفاوت نیاز دارند؛ استانداردهایی مانند x402 که در آن عامل بتواند پرداخت‌ها را به‌صورت خودمختار و بدون نیاز به کارت اعتباری مدیریت‌شده توسط انسان یا جریان‌های ثبت‌نام طولانی، تسویه کند. این گزارش یک روایت صادقانه است که در آن هر عدد واقعی است و تراکنش‌های تسویه در شبکه Base برای تأیید عمومی در دسترس هستند. توسعه‌دهنده از ابتدا یک معیار توقف سخت‌گیرانه تعیین کرده بود: اگر پس از هشت هفته از زمان عرضه، تعداد فراخوانی‌های پرداخت‌شده توسط کاربران خارجی صفر باقی بماند، او دیگر زمانی را صرف این پروژه نخواهد کرد.
به نقل از گزارشی که در ۲۳ ژوئیه ۲۰۲۶ از طریق وب‌سایت dev.to منتشر شد، زیرساخت فنی این پروژه کاملاً درست کار می‌کرد، اما مدل کسب‌وکار به‌دلیل اصطکاک در توزیع شکست خورد. توسعه‌دهنده با بررسی x402scan متوجه شد که در مجموع ۱۵ تراکنش رخ داده که حجم آن‌ها ۰.۱۵ دلار بوده است. اما عددی که اهمیت واقعی دارد — یعنی خریداران خارجی — روی صفر باقی ماند. هر دو آدرس خریدار متعلق به خودِ توسعه‌دهنده بوده‌اند: یکی کلاینت تستی برای بررسی حلقه پرداخت (Payment Loop) و دیگری کیف پول AgentCash که برای آزمایش‌های کشف (Discovery) استفاده شده بود. برای جلوگیری از ایجاد «ترافیک جعلی» (Wash Traffic) که در این اکوسیستم رایج است، توسعه‌دهنده دفتر حسابی از آدرس‌های تحت کنترل خود maintained کرد تا اطمینان حاصل کند که عدد نهایی به‌صورت خود-ممیزی (Self-audited) صفر است. در واقع، هر سنت از آن ۰.۱۵ دلار صرفاً از یکی از کیف پول‌های توسعه‌دهنده به کیف پول دیگر منتقل شده بود.
شکست‌های فنی «نامرئی»
با وجود پاس کردن تمام تست‌های واحد (Unit Tests)، تمام بررسی‌های نوع (Typecheck) و تست‌های دود-آزمایی کانتینرها (Container Smoke Tests)، این سرویس با دو اتفاق بحرانی در محیط تولید روبرو شد که تنها تراکنش‌های با پول واقعی می‌توانستند آن‌ها را آشکار کنند. این مشکلات در مرزهایی وجود داشتند که تست‌های استاندارد قادر به دیدن آن‌ها نیستند.
- سرریز متاداده (Metadata Overflow): برای بهبود قابلیت کشف، توسعه‌دهنده متاداده‌های سرویس را با طرح‌های (Schemas) واضح‌تر و توضیحات غنی‌تر ارتقا داد. این کار باعث شد طول یک رشته متنی از ۵۵ کاراکتر به ۷۱۷ تا ۷۵۶ کاراکتر برسد. از آنجایی که تسهیل‌کننده پرداخت (Payment Facilitator) یک محدودیت سخت ۵۰۰ کاراکتری بر روی الزامات پرداخت اعمال می‌کند، تسهیل‌کننده تمام پرداخت‌ها را به‌طور بی‌صدا (Silently) رد می‌کرد. هیچ تستی قرمز نشد و هیچ سیستم کرش نکرد، زیرا این محدودیت در سمت ارائه‌دهنده قرار داشت. راه حل این مشکل، افزودن یک گارد طول (Length Guard) در زمان بوت شدن در قالب پرداخت بود که از طریق یک تسویه پرداخت‌شده واقعی در شبکه Base (تراکنش 0xf3d2504961...481b8e08) تأیید شد. چون این گارد در قالبی قرار دارد که هر Endpoint از روی آن ساخته می‌شود، هیچ نقطه انتهایی در آینده این خطا را تکرار نخواهد کرد.
- عدم تطبیق پروتکل (Protocol Mismatches): پس از پایان TLS در لبه (Edge)، URL منبع به‌صورت http:// تبلیغ می‌شد. لایه کشف CDP این مورد را با دلیل خاصی رد کرد: «زمانی که نوع پروتکل http است، منبع باید با 'https://' شروع شود». پس از اینکه توسعه‌دهنده یک مبدأ عمومی (Public Origin) صریح که HTTPS را در شبکه اصلی بدون هیچ جایگزینی (Fallback) می‌طلبید تنظیم کرد، سرویس مدت کوتاهی پس از تسویه بعدی در کاتالوگ CDP Bazaar ظاهر شد.
- شکاف شواهدی (The Evidence Gap): یک مسیر (Route) در بازه زمانی کوتاهی دوباره شکست خورد. اما تا زمانی که توسعه‌دهنده شروع به بررسی کرد، لاگ‌های سرور برای آن بازه زمانی دقیق از چرخه خارج شده و پاک شده بودند. این موضوع باعث شد توسعه‌دهنده تنها با یک فرضیه پیش‌رو باشد، بدون اینکه راهی برای اثبات علت ریشه‌ای (Root Cause) داشته باشد.
بحران شناسایی و کشف
برای اینکه بفهمیم آیا یک عامل می‌تواند به‌صورت خودمختار سرویس را پیدا کند، توسعه‌دهنده پرکاربردترین کلاینت x402 یعنی AgentCash را روی یک فضای کاری (Workspace) جدید نصب کرد. با استفاده از یک توکن «تله» (Honeypot) شناخته شده که در آن پاسخ «درست» کاملاً واضح است، سه سطح از راهنمایی (Hinting) با اندازه n=1 تست شد:
- پرامپت سرد («آیا این توکن امن است؟»): عامل پرس‌وجو را با استفاده از honeypot.is، BaseScan و فراخوانی‌های خام RPC حل کرد. با وجود اینکه ابزار token-risk نصب و آماده بود، عامل هرگز از آن استفاده نکرد.
- پرامپت گرم («تو AgentCash داری — این توکن را چک کن»): عامل از AgentCash استفاده کرد و برای سه سرویس دیگر پول واقعی پرداخت کرد. با وجود اینکه token-risk در کاتالوگ بود، فراخوانی نشد.
- پرامپت نام‌دار («از token-risk از طریق agentcash استفاده کن»): عامل با یک «تداخل نام‌گذاری» (Naming Collision) روبرو شد که توسعه‌دهنده پیش‌بینی نکرده بود. عامل سرویس دیگری با نام مسیر (Route Name) کاملاً یکسان پیدا کرد و سعی کرد به آن پرداخت کند.
تنها پس از یک اصلاح صریح («نه آن یکی، منظورم token-risk.com است»)، عامل توانست مبدأ درست را شناسایی کند، آن را فراخوانی نماید و پرداخت را تسویه کند (تراکنش 0x8ac953da...98ed81). گزارشی که عامل دریافت کرد، دقیقاً با تمام اسکن‌های قبلی مطابقت داشت. موتور پردازشی هر بار که اجرا شد درست بود؛ شکست در «یافت شدن» و «انتخاب شدن» از میان ده‌ها هزار ورودی کاتالوگ بود، از جمله مواردی که نام‌های یکسانی داشتند.
محدودیت‌های محصول
توسعه‌دهنده همچنین یک سقف فنی برای نقطه انتهایی (Endpoint) ریسک کیف پول شناسایی کرد. هنگامی که این سرویس در برابر دو نقطه متضاد — یک کیف پول با سال‌ها تاریخچه روی زنجیره (On-chain) و کیف پولی که تنها پنج دقیقه پیش ساخته شده بود — تست شد، گزارش‌های دریافتی بایت-به-بایت یکسان بودند.
جزئیات: ساختاری در مقابل رفتاری
- وضعیت فعلی: در حال حاضر، نقطه انتهایی فقط «ساختاری» (Structural-only) است. تمرکز آن بر شناسایی قرارداد، وضعیت تأیید (Verification) و الگوهای مالکیت است.
- شکاف موجود: این سرویس فاقد سیگنال‌های رفتاری است تا بتواند یک کیف پول باتجربه را از یک کیف پول کاملاً جدید تشخیص دهد.
- انتخاب استراتژیک: توسعه بیشتر سیگنال‌های رفتاری در پشتِ «تقاضای واقعی» قرار گرفته است؛ به این معنا که به جای ساخت تخمینی و حدسی، منتظر درخواست کاربران می‌ماند تا توسعه یابد.
مسیر پیش رو
این شکست یک تغییر حیاتی در استک (Stack) عامل‌های هوش مصنوعی را برجسته می‌کند. گلوگاه در اواسط سال ۲۰۲۶ دیگر کد یا ریل‌های پرداخت نیست — هر دو حل شده‌اند و امروز USDCهای واقعی را تسویه می‌کنند. در عوض، مشکل اصلی «کشف و ابهام‌زدایی» (Discovery and Disambiguation) است.
این چالش‌های مدل‌های پولی در حالی رخ می‌دهد که برخی توسعه‌دهندگان برای حذف هزینه‌ها، مسیر جایگزینی مدل‌های وزن‌باز را در برابر APIهای پولی دنبال می‌کنند تا به هزینه صفر نزدیک شوند. یک عامل باید بداند سرویس وجود دارد، تصمیم بگیرد که این سرویس ابزار مناسب برای آن قصد (Intent) است و آن را به‌درستی از یک کاتالوگ شلوغ انتخاب کند. توسعه‌دهنده لایه کشف فعلی را به «یاهو در سال ۱۹۹۸» تشبیه می‌کند. برای سازندگان، این بدان معناست که مهندسی یک محصول کاربردی تنها نیمی از نبرد است؛ باقی آن یک مشکل توزیع است.
اصلاحات در پیاده‌سازی
برای کاهش این مشکلات، توسعه‌دهنده چندین تغییر خاص را اعمال کرده است:
- مدیریت خطا: فراخوانی‌های پرداخت‌شده روی یک میزبان غیررسمی (Non-canonical host) اکنون کد وضعیت ۴۲۱ را دریافت می‌کنند که حامل URL رسمی است. این کار باعث می‌شود درخواست به‌جای اینکه از یک مسیر پرداخت متقاطع (Cross-host) تست‌نشده عبور کند، با صدای بلند رد شود؛ زیرا کلاینت‌های x402 تضمینی ندارند که در میانه جریان پرداخت، ریدایرکت‌ها (Redirects) را دنبال کنند.
- شناسایی: سرویس اکنون با URL کامل مبدأ شناسایی می‌شود و هرگز از نام ساده استفاده نمی‌شود.
- بازخورد جامعه: یک مورد (Issue) مربوط به اصطکاک در کشف سرویس در مخزن گیت‌هاب نگهداران کلاینت در آدرس
https://github.com/Merit-Systems/agentcash-skills/issues/24ثبت شده است. - پروتکل استقرار: اجرای یک «پروب پرداخت» (Paid Probe) در شبکه اصلی اکنون به یک آیتم دائمی در چک‌لیست پس از استقرار (Post-deploy checklist) تبدیل شده است (یک ضربان قلب یا Heartbeat، نه یک تست ساده)، به طوری که لاگ‌ها بلافاصله قبل از هر اقدام دیگری ثبت می‌شوند.
اگر شما در حال ساخت سرویس‌های x402 هستید و فراخوانی‌های پرداخت‌شده خارجی از عامل‌هایی دریافت می‌کنید که تحت کنترل شما نیستند، توسعه‌دهنده می‌خواهد بداند چه چیزی باعث «پیدا شدن» آن سرویس‌ها شده است. برای سازندگان عامل‌ها، سؤال این است که چه چیزی باعث می‌شود آن‌ها به سرویسی اعتماد کنند و آن را بدون حضور انسان در حلقه (Human-in-the-loop) فراخوانی کنند. این سرویس همچنان در token-risk.com فعال است و یک نمونه گزارش رایگان در مسیر /samples/index.json در دسترس است. توسعه‌دهنده پس از بسته شدن بازه هشت هفته‌ای، گزارشی تکمیلی منتشر خواهد کرد و صادقانه با اعداد مواجه خواهد شد.
گام بعدی شما
- اگر توسعه‌دهنده سرویس x402 هستید، روی «نام‌گذاری منحصر‌به‌فرد» و «URL رسمی» تمرکز کنید تا در کاتالوگ‌ها گم نشوید.
- بررسی کنید که آیا متاداده‌های شما با محدودیت‌های کاراکتری تسهیل‌کنندگان پرداخت سازگار است یا خیر.
- برای تست واقعی، از کیف پول‌های مجزا استفاده کنید تا اثر «ترافیک جعلی» (Wash Traffic) نتایج شما را مخدوش نکند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو