تصور کنید وب‌سایتی دارید که هر روز هزاران درخواست از عامل‌های هوش مصنوعی دریافت می‌کند، اما هیچ درآمدی از آنها نمی‌برید. اکنون دریافت هزینه به‌ازای هر درخواست (Request) برای یک عامل (Agent) به واقعیت فنی تبدیل شده است. در ۱۰ اکتبر ۲۰۲۶، یک توسعه‌دهنده سیستمی را تشریح کرد که به‌جای مسدود کردن بات‌ها، از یک درگاه پرداخت مستقیم با استفاده از کد وضعیت HTTP 402 (Payment Required) و استیبل‌کوین USDC استفاده می‌کند.
اکثر وب‌سایت‌ها در حال حاضر با خزنده‌های هوش مصنوعی مانند یک مسئله صفر و یکی برخورد می‌کنند: یا آنها را کاملاً مسدود می‌کنند یا اجازه می‌دهند رایگان داده‌ها را استخراج کنند. این وضعیت یک مشکل ساختاری در درآمدزایی ایجاد می‌کند. وقتی یک عامل صفحه‌ای را فراخوانی می‌کند، پهنای باند و منابع سرور را مصرف می‌کند، اما هرگز روی تبلیغات کلیک نمی‌کند یا از لینک‌های همکاری استفاده نمی‌کند. در واقع، مالک سایت هزینه بازدید را می‌پردازد، اما مدل‌های درآمدی که برای انسان‌ها طراحی شده‌اند، هیچ سودی ثبت نمی‌کنند.
طبق گزارش منتشر شده در dev.to، شناسایی سنتی بات‌ها یک نبرد شکست‌خورده است؛ زیرا رشته‌های User-Agent ادعاهستند، نه واقعیت. هر کلاینتی می‌تواند هویت خود را جعل کند تا از لیست‌های مسدودسازی عبور کند و خزنده‌ها به‌طور منظم نام‌های خود را تغییر داده یا حذف می‌کنند. بر اساس این گزارش، هر چیزی که بر پایه این بنیاد ساخته شود، صرفاً یک «حدس» است که در لباس یک «تصمیم» ارائه شده است. تنها راهکار صادقانه این است که روی خودِ درخواست قیمت بگذاریم، فارغ از اینکه چه کسی یا چه چیزی آن را ارسال می‌کند.
چرخش از شناسایی به قیمت‌گذاری
در این مدل، طبقه‌بندی بات‌ها فقط در جایی که به آن تعلق دارد، یعنی در بخش تحلیل‌های آماری (Analytics) باقی می‌ماند. توسعه‌دهنده ثبت می‌کند که آیا یک درخواست خودکار به نظر می‌رسد یا خیر تا گزارش‌های مربوطه را تهیه کند، اما این طبقه‌بندی هرگز باعث اعطای یا رد دسترسی نمی‌شود.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی اقتصاد داده در عصر مدل‌های زبانی اشاره کردیم، مدل‌های درآمدی باید با ماهیت مصرف‌کننده تغییر کنند. با قیمت‌گذاری درخواست، سرور نیاز به جنگ ابزارهای شناسایی را از بین می‌برد. قیمت متعلق به «منبع» است، نه «بازدیدکننده». این یعنی مبلغ یکسانی به انسان، خزنده و عامل اعلام می‌شود و این قیمت پیش از هرگونه احرازی قابل مشاهده است. این رویکرد در واقع مکمل ابزارهایی است که داده‌های وب‌سایت‌های تجاری را به منابع ساختاریافته برای مدل‌های زبانی تبدیل می‌کنند تا بهره‌وری استخراج داده افزایش یابد.
سازوکار پرداخت
این سیستم با انتقال محتوای محافظت‌شده به یک نقطه انتهایی (Endpoint) خاص عمل می‌کند. وقتی یک عامل منبعی را درخواست می‌کند (مثلاً از طریق GET /functions/paid-link?slug=example-resource)، سرور محتوا را برنمی‌گرداند. در عوض، یک پاسخ HTTP 402 حاوی یک پیشنهاد پرداخت ارسال می‌کند.
این پیشنهاد شامل الزامات فنی دقیقی است:
- طرح (Scheme): روش پرداخت (مثلاً "exact").
- شبکه (Network): بلاک‌چین مورد نظر (مثلاً eip155:8453).
- مبلغ (Amount): هزینه دقیق به توکن (مثلاً ۱,۰۰۰,۰۰۰ واحد).
- دارایی (Asset): آدرس قرارداد توکن مورد استفاده.
- گیرنده (PayTo): آدرس کیف پول دریافت‌کننده.
- توضیحات (Description): برچسبی برای شناسایی منبع.
عاملی که برای این قرارداد طراحی شده، پیشنهاد را می‌خواند و یک مجوز برای آن درخواست خاص امضا می‌کند. سپس این امضا را در هدر payment-signature بازمی‌گرداند و دوباره درخواست می‌دهد. این سطح از اتوماسیون در تعاملات ماشینی، یادآور فرآیندهای تبدیل متن به کد است که به افراد غیرمتخصص اجازه می‌دهد بات‌های پیچیده بسازند و مرزهای توسعه نرم‌افزار را جابه‌جا می‌کند.
نکته حیاتی این است که این مجوز، به معنای تسویه حساب نیست و فقط قصد پرداخت را ثابت می‌کند. سرور باید رسید روی زنجیره (On-chain) را شخصاً تأیید کند. تراکنش باید موفق باشد و انتقال باید دقیقاً با فرستنده، گیرنده، مبلغ و نانس (nonce) مجوز درخواست مطابقت داشته باشد. هرگونه ریدایرکت یا پرچم موفقیت که در بدنه پاسخ (Body) ارسال شود، هرگز به عنوان دلیل پرداخت پذیرفته نمی‌شود.
حل مشکل «پرداخت مضاعف»
جریان‌های پرداخت اغلب در بدترین حالت شکست می‌خورند: کلاینت مطمئن نیست که پول واقعاً جابه‌جا شده است یا خیر. برای جلوگیری از پرداخت دوباره‌ی عامل‌ها برای یک منبع، سیستم هر مجوز را هش (Hash) کرده و ذخیره می‌کند.
اگر تلاش دومی با همان مجوز صورت گیرد، سرور یک تداخل (Conflict) به همراه هش تراکنش اصلی و یک مسیر بازیابی ارسال می‌کند. این مسیر بازیابی، مالکیت کیف پولی که ابتدا پرداخت کرده را بررسی کرده و بدون نیاز به پرداخت مجدد، دسترسی را می‌دهد. توسعه‌دهنده تأکید می‌کند که عبارت «دوباره پرداخت نکنید» مهم‌ترین جمله در این محصول است.
حفاظ‌های عملیاتی
پیاده‌سازی این سیستم نیازمند عبور از پنج مانع فنی خاص بود تا تضمین شود که سیستم صادقانه عمل می‌کند:
- ردیابی درآمد: داشبورد بین «ارزش مدل‌شده» و «رسیدهای تأییدشده» تفکیک قائل می‌شود. یک قیمت اعلام شده یا یک مجوز امضا شده، درآمد نیست. تنها انتقالی که با یک رسید موفق روی زنجیره مطابقت داشته باشد، درآمد محسوب می‌شود. همچنین واحدهای شبکه تست (Test-net) صراحتاً به عنوان فاقد ارزش پولی برچسب‌گذاری می‌شوند. تسویه‌های تأیید نشده به جای اینکه در مجموع درآمد ادغام شوند، به عنوان «تأیید نشده» باقی می‌مانند.
- پنجره‌های انقضا: مجوزها دارای برچسب‌های زمانی
validAfterوvalidBeforeهستند. اگر خریدار بیش از حد در صفحه پرداخت بماند، پنجره بسته می‌شود. سرور پیش از تماس با زیرساخت‌های تسویه، این پنجره را بررسی می‌کند تا از ارسال پرداخت‌هایی که نمی‌توانند تسویه شوند، جلوگیری کند. - جداسازی شبکه: شبکه‌های تست و شبکه‌های اصلی (Mainnets) به عنوان محصولات مجزا مدیریت می‌شوند. حالت شبکه در هر رکورد نوشته می‌شود و منابع تست نمی‌توانند پرداخت‌های شبکه اصلی را بپذیرند تا خطاهای حسابداری رخ ندهد.
- دسترسی در برابر شرایط: سیستم فایل
robots.txtرا از قیمت‌گذاری جدا نگه می‌دارد. اجازه خزیدن مربوط به «دسترسی» است، در حالی که پاسخ 402 مربوط به «شرایط» آن دسترسی است. نقطه انتهایی پرداخت‌شده از دسترس خزنده‌های رایگان خارج شده و پرداخت کردن به معنای داشتن حق خزیدن در کل سایت نیست. - تحویل مشروط به پرداخت: نقطه انتهایی یک مسیر تحویل است، نه یک API رایگان. اگر کلاینت پیشنهاد را رد کند، سرور چیزی جز چند بایت پاسخ از دست نمی‌دهد.
این تغییر، وب را از جنگ شناسایی دور می‌کند. به‌جای مدیریت لیست‌های مسدودسازی پیچیده یا مدل‌سازی انتساب، سرور صرفاً درخواست پرداخت می‌کند. اگر عامل پرداخت کند، محتوا ارائه می‌شود؛ در غیر این صورت، هیچ‌کدام از طرفین زمان خود را تلف نمی‌کنند.
برای کاربران انسانی، این سیستم جایگزین درگاه‌های سنتی نمی‌شود. توسعه‌دهنده همچنان برای فایل‌های تجارت الکترونیک از Stripe استفاده می‌کند، زیرا اکثر مردم کارت اعتباری را به امضای تراکنش‌های بلاک‌چین ترجیح می‌دهند. تسویه کریپتویی به‌طور خاص برای پرداخت‌کنندگان ماشینی و دارندگان توکن طراحی شده است، نه به عنوان یک استراتژی پرداخت جهانی. علاوه بر این، این یک سیستم پرداخت (Payout) نیست؛ تسویه در یک کیف پول عمومی انجام می‌شود و هیچ مرحله‌ای برای واریز بانکی یا مدیریت مالیاتی ندارد.
این سازوکار آینده‌ای را ترسیم می‌کند که در آن «وب باز» باز می‌ماند، اما هزینه مصرف خودکار درونی می‌شود. با رشد ترافیک عامل‌ها، توانایی درآمدزایی از «خواندن» (Read) به اندازه درآمدزایی از «کلیک» اهمیت خواهد یافت.
توسعه‌دهندگان علاقه‌مند می‌توانند جزئیات کامل سازوکار و پیاده‌سازی را در payperai.ai/ai-link-monetization و صفحه موضوعی payperai.ai/monetize-ai-agent-traffic بررسی کنند.
گام بعدی شما
- اگر مالک محتوا هستید، بررسی کنید که چه مقدار از ترافیک شما توسط عامل‌های هوش مصنوعی تشکیل شده و آیا مدل‌های تبلیغاتی فعلی شما برای آنها کارآمد است یا خیر.
- توسعه‌دهندگان می‌توانند مستندات پیاده‌سازی این مدل را در payperai.ai بررسی کنند تا با استانداردهای جدید پرداخت‌های ماشینی آشنا شوند.
- دنبال کنید که آیا مرورگرها یا کیف پول‌های هوشمند، لایه‌هایی برای مدیریت خودکار این پرداخت‌های خرد (Micropayments) اضافه می‌کنند یا خیر.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو