منبع اصلی: واتردراپ کپیتال

خلاصه

مدل‌های بزرگ از ابزارهای پاسخ‌دهنده به سؤالات، به عوامل هوشمندی تبدیل می‌شوند که قادر به برنامه‌ریزی، فراخوانی ابزارها و ارائه نتایج هستند. در همین حال، تسویه‌حساب با استیبل‌کوین‌ها، پروتکل‌های پرداخت مبتنی بر HTTP (HTTP 402) و کیف‌پول‌های هوشمند، شروع به ترکیب شدن برای ایجاد زیرساخت پرداختی طراحی‌شده برای ماشین‌ها کرده‌اند. یک برنامه می‌تواند در زمان اجرا قیمت‌گذاری دریافت کند، مجوز پرداخت را امضا کند و پرداخت ریز را انجام دهد — کاری که تنها چند سال پیش مفهومی بود اما اکنون مسیر فنی قابل‌اجراست.

با این حال، «ماشین‌ها می‌توانند پرداخت کنند» به معنای «ماشین‌ها می‌توانند تراکنش‌ها را کامل کنند» نیست. وقتی یک عامل هوشمند نیاز دارد جستجو، داده، قدرت محاسباتی، تولید محتوا یا خدمات تحلیل حرفه‌ای خریداری کند، همچنان با چالش‌هایی مانند کشف نقطه‌های پایانی، مقایسه قیمت‌ها، انجام پرداخت‌های بین‌پروتکلی، کنترل بودجه، تأیید تحویل و یکپارچه‌سازی تسویه‌حساب روبه‌روست. ریل‌های پرداخت نحوه حرکت ارزش را حل می‌کنند، اما به‌طور خودکار نحوه یافتن عرضه توسط تقاضا یا اطمینان از دریافت دقیق خدمات پس از پرداخت را حل نمی‌کنند.

این بدان معناست که در مرحله بعدی پرداخت عوامل هوشمند، تمرکز رقابتی دیگر ممکن است صرفاً بر ظرفیت پروتکل، سرعت تسویه‌حساب یا تعداد زنجیره‌های پشتیبانی‌شده نباشد، بلکه بر این باشد که آیا زیرساخت واقعی خریدار ماشینی قابل ساخت است یا خیر. این مقاله تلاش می‌کند دلیل تبدیل شدن پرداخت عوامل هوشمند به یک مسیر مستقل را — با شروع از ساختار تقاضا، تکامل پروتکل‌ها، موانع عملیاتی و تقسیم کار بازار — بررسی کند و ارکان ضروریِ ناقص قبل از دستیابی به پذیرش گسترده را شناسایی کند.

مقدمه: عوامل هوشمند بودجه اختیاری محدودی کسب کرده‌اند

در دو سال گذشته، قابلیت‌های عوامل هوشمند بسیار سریع توسعه یافته‌اند. در ابتدا، مدل‌های بزرگ عمدتاً به تولید اطلاعات می‌پرداختند — کاربران سؤال می‌پرسیدند و مدل‌ها متن تولید می‌کردند. سپس فراخوانی ابزارها به مدل‌ها اجازه داد تا صفحات وب را جستجو کنند، پایگاه‌های داده را استعلام کنند، کد را اجرا کنند و نرم‌افزارها را بهره‌برداری کنند. در مرحله بعد، عوامل هوشمند شروع به تجزیه اهداف، تدوین برنامه‌ها و تنظیم اقدامات بر اساس نتایج خارجی در چندین دور اجرایی کردند.

وقتی اهداف اجرایی محدود به ابزارهای رایگان یا سیستم‌های داخلی سازمانی بود، مجوزهای فراخوانی را می‌شد توسط توسعه‌دهندگان از پیش پیکربندی کرد. اما قابلیت‌های باکیفیت در بازارهای باز معمولاً نیازمند پرداخت هستند: داده‌های مالی بلادرنگ به ازای هر فراخوانی قیمت‌گذاری می‌شوند، اسکرپینگ وب از اعتبارات کم می‌کند، قدرت استنتاج و GPU بر اساس مصرف صورتحساب می‌شود و تولید ویدیو و پایگاه‌های داده حرفه‌ای قیمت‌گذاری شفافی دارند. برای اینکه یک عامل هوشمند بتواند به‌صورت مستقل وظیفه‌ای را انجام دهد، لزوماً در زمان اجرا باید به خریدار تبدیل شود.

مدل کسب‌وکار API سنتی برای این نوع خریدار طراحی نشده است. این مدل نیازمند این است که ابتدا فردی به وب‌سایت مراجعه کند، حساب ایجاد کند، کارت بانکی را پیوند دهد، طرحی را انتخاب کند، کلید API را محافظت کند و سپس آن را در محیط برنامه قرار دهد. تصمیمات خرید و فراخوانی‌های واقعی در دو زمان جداگانه انجام می‌شوند: انسان‌ها قبل از انجام وظیفه خرید را انجام می‌دهند و نرم‌افزار فقط مسئول مصرف سهمیه خریداری‌شده است.

یک عامل ممکن است تا زمانی که به مرحله خاصی از اجرای وظیفه برسد، نداند چه چیزی نیاز دارد. نمی‌تواند پیش‌بینی کند که در نهایت از کدام منبع داده استفاده خواهد کرد و نباید از کاربر خواسته شود که برای هر سرویس احتمالی به‌صورت جداگانه حساب باز کند. تأمین آن ویژگی‌های فوری، کم‌ارزش، چندفروشنده، پرتردد و نتیجه‌محور دارد. تجربه طبیعی‌ترین برای آن «اول اشتراک، سپس فراخوانی» نیست، بلکه «کشف سرویس، دریافت قیمت، مجوز پرداخت و دریافت نتیجه» است.

بنابراین پرداخت عوامل هوشمند صرفاً افزودن دکمه پرداخت به چت‌بات نیست. این بدان معناست که نرم‌افزار شروع به داشتن اختیار محدود خرج کردن می‌کند و فرآیند تأمینی متعلق به ماشین‌ها را ایجاد می‌کند. انسان‌ها اهداف، بودجه و مرزهای ریسک را تعیین می‌کنند و عوامل هوشمند در این محدوده‌ها منابع را تخصیص می‌دهند. بدین ترتیب پرداخت از یک اقدام تسویه‌حساب به بخشی از سیستم تصمیم‌گیری عامل تبدیل می‌شود.

۱. چرا پرداخت عوامل هوشمند به یک مسیر مستقل تبدیل خواهد شد

۱.۱ از فراخوانی ابزار به اقدام اقتصادی

تفاوت عوامل هوشمند با اسکریپت‌های خودکار معمولی تنها در توان استدلال نیست. اسکریپت‌ها فرآیندهای از پیش تعیین‌شده را اجرا می‌کنند و منابع و تأمین‌کنندگان مورد نیاز معمولاً در کد نوشته شده‌اند؛ اما عوامل هوشمند مسیرهای خود را بر اساس محیط انتخاب می‌کنند. در یک وظیفه تحقیقاتی مشابه، ممکن است ابتدا نتایج جستجو را خریداری کند، سپس بر اساس نتایج تصمیم بگیرد که آیا نیاز به پایگاه داده صنعتی دارد و در نهایت از مدل دیگری برای تأیید متقابل استفاده کند. هر مرحله از تأمین، تصمیمات بعدی را تغییر می‌دهد.

این مدل «اجرای همزمان با تأمین»، انتخاب اقتصادی را به زمان اجرای نرم‌افزار معرفی می‌کند. یک عامل هوشمند نه‌تنها باید تشخیص دهد که آیا ابزاری موجود است، بلکه باید بداند که آیا خرید آن ارزشمند است: آیا قیمت از بودجه فراتر رفته، آیا سرعت پاسخ‌گویی نیازهای وظیفه را برآورده می‌کند، آیا انجام تاریخی قابل اعتماد است و آیا سرویس جایگزین مناسب‌تر است. مسیریابی ابزارهای سنتی بر تطبیق قابلیت‌ها تمرکز دارد، درحالی‌که تأمین ماشینی باید همزمان با قیمت و ریسک مقابل هم کار کند. در چنین تراکنش‌هایی، طرف تحمل‌کننده ریسک خود عامل هوشمند است: پرداخت ممکن است موفق باشد، اما سرویس ارائه نشود.

بنابراین نیاز اصلی پرداخت عوامل هوشمند، پرداخت خودکار بدون قید و شرط نیست، بلکه واگذار کنترل‌شده قدرت خرید به نرم‌افزار است. کاربران به‌راحتی کل کیف پول خود را به یک عامل هوشمند نمی‌سپارند، اما مایل‌اند برای یک وظیفه مشخص چند دلار بودجه تعیین کنند و اجازه دهند که چند خرید سنتی دلاری انجام دهد. مجوزهای بزرگ ممکن است هنوز نیازمند ساختن اعتماد بلندمدت باشند، اما مجوزهای کوچک اکنون می‌توانند ارزش واقعی ایجاد کنند.

۱.۲ پرداخت‌های میکرو، پرداخت‌های با فراوانی بالا و معاملات با چندین فروشنده تغییری در اقتصاد پرداخت ایجاد می‌کنند

زیرساخت پرداخت اینترنت انسانی برای انجام تراکنش‌های کم‌فراوانی و با ارزش نسبتاً بالا مناسب است. شبکه‌های کارت‌های اعتباری، دروازه‌های پرداخت و سیستم‌های اشتراک‌گذاری همگی هزینه‌های ثابتی دارند؛ بنابراین فروشندگان اغلب تعداد زیادی درخواست را در بسته‌های ماهانه تجمیع می‌کنند. برای درخواست‌های API که ارزش هر کدام تنها چند سنت است، کارمزدها، ریسک بازپرداخت و هزینه‌های نگهداری حساب در سیستم‌های سنتی ممکن است از ارزش خود کالا فراتر رود.

مصرف ماشینی دقیقاً برعکس این وضعیت است. یک عامل (agent) می‌تواند در عرض چند دقیقه برای انجام یک تحویل‌پذیر واحد، خریدهای متعددی از فروشندگان مختلف آغاز کند. ارزش هر تراکنش بسیار پایین است، اما فراوانی درخواست‌ها بالا بوده و تعداد تراکنش‌ها ممکن است از تعداد تراکنش‌های مصرف‌کنندگان انسانی بسیار بیشتر باشد. استیبل‌کوین‌ها و تسویه‌حساب برنامه‌پذیر روی زنجیره، پایه‌ای اقتصادی جدید برای چنین سناریوهایی فراهم می‌کنند: وجوه می‌توانند به‌صورت شبانه‌روزی جریان داشته باشند، مجوزهای پرداخت می‌توانند توسط نرم‌افزار امضا شوند و خدمات می‌توانند مستقیماً به‌ازای هر درخواست قیمت‌گذاری شوند.

مهم‌تر از این، خرید از چندین فروشنده، نحوه رقابت در بازار API را تغییر خواهد داد. مدل‌های اشتراکی تشویق کاربران را به ماندن بلندمدت در یک تأمین‌کننده خاص می‌کنند، در حالی که مدل پرداخت به‌ازای هر استفاده، امکان انتخاب پویا برای هر وظیفه را به عامل‌ها می‌دهد. ارائه‌دهندگان خدمات دیگر صرفاً برای قراردادهای سالانه رقابت نمی‌کنند، بلکه برای پاسخگویی به نیاز لحظه‌ای نیز رقابت می‌کنند. قیمت، عملکرد و سابقه اجرای خدمات ممکن است همه در زمان واقعی بر نتایج مسیریابی تأثیر بگذارند.

۱.۳ استیبل‌کوین‌ها از یک واسطه تبادل به زیرساخت تسویه‌حساب در حال تبدیل شدن هستند

در بازار اولیه ارزهای دیجیتال، تقاضا برای استیبل‌کوین‌ها عمدتاً از معاملات و پناه‌گرفتن سرمایه در برابر ریسک ناشی از نوسانات نرخ ارز ناشی می‌شد. با بلوغ تدریجی زیرساخت‌های صدور، نگهداری، رعایت مقررات و انتقال بین‌زنجیره‌ای، استیبل‌کوین‌ها در حال ورود به حوزه‌های تسویه‌حساب بین‌المللی، مدیریت خزانه‌داری شرکتی و پرداخت‌های بومی اینترنتی هستند. برای پرداخت‌های ماشینی، استیبل‌کوین‌ها مزیت ویژه‌ای دیگر نیز دارند: آن‌ها هم ارز هستند و هم دارایی دیجیتالی که می‌تواند مستقیماً توسط برنامه‌ها اداره شود.

پرداخت‌های کارت اعتباری به هویت دارنده کارت، حساب‌های بانکی و شبکه‌های جغرافیایی وابسته‌اند. خود عامل‌ها هویت فرد طبیعی ندارند و نمی‌توانند به‌طور مستقل فرآیند باز کردن حساب سنتی را طی کنند. با این حال، یک کیف پول تحت محدودیت‌های سیاستی می‌تواند رابط تأمین وجوه عامل باشد: عملیات‌گر موجودی محدودی را وارد می‌کند، سقف درخواست و جلسه را تعیین می‌کند و حق تعلیق و لغو را حفظ می‌کند؛ عامل نیز فقط در محدوده مجاز امضا می‌کند.

این به معنای برتری ذاتی پرداخت‌های روی زنجیره نسبت به تمام پرداخت‌های سنتی نیست. حمایت از مصرف‌کننده، مکانیزم‌های بازپرداخت، حریم خصوصی، مدیریت کلیدها و مسئولیت‌های نظارتی همچنان نیازمند رفع هستند. اما در پرداخت‌های ماشین-به-ماشین، پرداخت‌های کم‌ارزش به‌ازای هر استفاده و خرید خدمات جهانی، استیبل‌کوین‌های برنامه‌پذیر سازگاری واضحی دارند. برای اولین بار، «فراخوانی یک رابط» و «پرداخت برای یک رابط» فرصت فشرده‌شدن در یک تعامل شبکه‌ای را پیدا کرده‌اند.

۲. زیرساخت‌های پرداخت از پیش ظهور یافته‌اند: x402، MPP و تراکنش‌های ذاتی HTTP

۲.۱ تبدیل کد وضعیت ۴۰۲ به یک رابط تجاری

HTTP از دهه‌ها پیش کد وضعیت ۴۰۲ («پرداخت مورد نیاز») را رزرو کرده است، اما تقریباً در ۳۰ سال گذشته جریان کلی برای آن شکل نگرفته است. پروتکل‌های پرداخت ماشینی این معنا را دوباره فعال کرده‌اند: مشتری یک نقطه پایان پولی را درخواست می‌کند، سرور کد ۴۰۲ و شرایط پرداخت قابل خواندن توسط ماشین ارسال می‌کند؛ مشتری گزینه‌ای قابل قبول را انتخاب، امضای لازم یا پرداخت را انجام داده و سپس درخواست را با مجوزهای لازم تکرار می‌کند.

اهمیت این فرآیند در حذف صفحه ثبت‌نام انسانی است. کشف قیمت، الزامات پرداخت و تحویل محتوا همه در لایه پروتکلی رخ می‌دهند که برنامه‌ها قادر به درک آن هستند. برای توسعه‌دهندگان، APIهای پولی دیگر نیازی به ساخت پرتال SaaS کامل اطراف حساب‌ها، طرح‌ها و کلیدها ندارند؛ برای عامل‌ها، خدمات مانند صفحات وب معمولی قابل کشف بوده و در زمان واقعی نیاز به خرید، خریداری می‌شوند.

x402 یکی از محبوب‌ترین پروتکل‌های باز در این مسیر است. این پروتکل چالش‌ها و مجوزهای پرداخت را حول کد وضعیت HTTP 402 سازمان‌دهی می‌کند و به ارائه‌دهندگان خدمات امکان جمع‌آوری پرداخت به‌ازای هر درخواست را می‌دهد. در مقابل، MPP از اکوسیستمی متفاوت شروع شده و روش‌های پرداخت متمرکز بر ماشین مانند «شارژ» و «جلسه» را بررسی می‌کند. طراحی‌های خاص این دو متفاوت است، اما هر دو یک جهت را تأیید می‌کنند: پرداخت‌های ماشینی می‌توانند بخشی از پروتکل کاربردی شوند، نه اینکه نیازمند فرآیند تسویه‌حساب دستی جداگانه خارج از کاربرد باشند.

۲.۲ ماهیت بلندمدت تنوع‌بخشی به زیرساخت‌های پرداخت

صنعت اغلب انتظار دارد که در نهایت تنها یک پروتکل استاندارد، یک شبکه تسویه‌حساب و یک روش پرداخت باقی بماند. اما از دیدگاه فروشنده، تنوع‌بخشی دلایل بلندمدتی دارد. پرس‌وجوهای یک‌باره داده‌ها مناسب پرداخت به‌ازای هر فراخوان هستند، درحالی‌که سرویس‌های استنتاج یا جریانی مداوم ممکن است بهتر با صورتحساب جلسه‌ای سازگار باشند؛ سرویس‌های با ارزش بالا نیازمند تضمین‌ها و سازوکارهای حل اختلاف قوی‌تری هستند، درحالی‌که فراخوان‌های کم‌ارزش بیشتر به سرعت و هزینه حساس‌اند؛ مناطق و شرکت‌های مختلف نیز شبکه‌های رعایت مقررات و تسویه‌حساب متفاوتی را انتخاب می‌کنند.

لایه پروتکلی به‌طور مداوم در حال نوآوری است. فروشندگان ممکن است از بدهی مستقیم، مجوز پیش‌ثبت، اسکرو، پرداخت‌های جریانی یا تسویه‌حساب دسته‌ای استفاده کنند؛ شبکه‌ها نیز در هزینه، قطعیت نهایی، نقدینگی و ابزارهای اکوسیستم تفاوت‌هایی را اعمال می‌کنند. برای فروشندگان، این آزادی انتخاب است. برای خریداران، هر ترکیب جدید سطح ادغامی دیگری را اضافه می‌کند.

ماتریس پیکربندی در شکل زیر برشی از این تنوع است: پروتکل‌ها/روش‌های پرداخت ستون‌ها را تشکیل می‌دهند، زنجیره‌ها سطرها را، و هر انتخاب پیکربندی پرداختی است که نیازمند ادغام جداگانه است و این جدول همچنان در حال گسترش است.

شکل ۱: ماتریس پیکربندی زیرساخت‌های پرداخت در شرایط تجزیه‌شده

بنابراین تجزیه‌شدن لزوماً با بلوغ بازار به‌طور طبیعی ناپدید نمی‌شود. بازار کارت‌های بانکی پس از سال‌ها توسعه به یک سازمان کارتی واحد نرسید و محاسبات ابری نیز به یک ارائه‌دهنده منحصر به‌فرد منجر نشد. بازارهای بالغ معمولاً تفاوت‌ها را حذف نمی‌کنند، بلکه لایه‌های تجمیع، مسیریابی و تسویه‌حساب را بر روی این تفاوت‌ها ایجاد می‌کنند. پرداخت عامل‌ها احتمالاً از همین مسیر تکاملی پیروی خواهد کرد. این شکاف اکنون قابل اندازه‌گیری است. داده‌های دو کاوشگر عمومی (x402scan و mppscan) در ۳۰ روز گذشته (تا تاریخ ۳ سپتامبر ۲۰۲۶) نشان می‌دهد: پروتکل MPP دارای ۶۵۵۹۱ کیف پول خریدار فعال در زنجیره Tempo است، x402 در زنجیره Base دارای ۱۹۴۷۲ کیف پول است و تنها ۳۶۵ کیف پول در هر دو زیرساخت مشاهده شده‌اند که کمتر از ۰٫۶٪ خریداران MPP و ۲٪ خریداران Base x402 را تشکیل می‌دهد؛ در میان این موارد، تنها ۱۱۲ کیف پول در هر دو زیرساخت بیش از ده تراکنش انجام داده‌اند و بخش قابل توجهی از آن‌ها تجمیع‌کننده‌های دو زیرساخت هستند که با کلید یکسان به‌جای خریداران واقعی، به‌نام کاربران پرداخت می‌کنند. خریداران بین زیرساخت‌ها جریان ندارند؛ هر زیرساخت پایه خریداران مستقل خود را جمع‌آوری می‌کند.

۲.۳ ثبت‌نام فروشنده تنها نیمی از تراکنش است

پروتکل‌های پرداخت ابتدا مانع ورود فروشندگان به سیستم دریافت پرداخت را کاهش می‌دهند. وقتی یک نقطه پایان بتواند نقل‌قول‌ها را منتشر کند، مدارک را تأیید کند و خدمات را ارائه دهد، شرایط اولیه تجارت ماشین‌محور را برآورده کرده است. بدین ترتیب، تعداد فزاینده‌ای از ابزارهای توسعه‌دهنده، خدمات داده و رابط‌های محتوا به‌صورت ماشین‌قابل‌خرید درمی‌آیند.

با این حال، وجود عرضه قابل‌پرداخت به معنای جذب خودکار تقاضا نیست. فروشندگان مشکل «چگونه از ماشین‌ها پرداخت دریافت کنم» را حل می‌کنند، اما عامل‌ها همچنان باید به سؤالات «از چه کسی بخرم؟ چه روش پرداختی را انتخاب کنم؟ و پس از پرداخت چگونه تحویل را تأیید کنم؟» پاسخ دهند. اگر هر خریدار مجبور باشد به‌صورت جداگانه هر پروتکل را ادغام کند، وجوه را در شبکه‌های مختلف آماده کند و دفاتر مستقلی را نگهداری کند، پرداخت‌های ماشینی پیچیدگی ادغام APIهای اولیه را تکرار خواهند کرد—تنها با جایگزینی کلیدهای API با کیف‌پول‌ها و سازگان‌دهنده‌های پروتکل.

پذیرش واقعی به کل اصطکاک معامله بستگی دارد، نه صرفاً به اصطکاک مرحله تسویه.

۳. تنگنا واقعی صنعت: معاملات حلقه بسته‌ای ندارند

شکل ۲: فرآیند کامل تأمین ماشینی

۳.۱ مانع اول: کشف خدمات قابل خرید

عامل‌ها به دفترچه‌های خدمات قابل‌خواندن توسط ماشین نیاز دارند. یک دفترچه مؤثر نمی‌تواند فقط شامل نام‌ها و آدرس‌های وب باشد؛ بلکه باید قابلیت‌های نقطه پایان، ورودی‌ها و خروجی‌ها، واحدهای قیمت‌گذاری، پروتکل‌های موجود، تأخیر، محدودیت‌های جغرافیایی و وضعیت به‌روزرسانی را نیز توصیف کند. همچنین نگاشت بین قصد بیان‌شده به زبان طبیعی و پارامترهای API ضروری است؛ در غیر این صورت عامل می‌داند «به داده‌های کلان‌اقتصادی نیاز دارد» اما نمی‌تواند تعیین کند کدام نقطه پایان این وظیفه را انجام می‌دهد.

دفترچه‌های بازارهای آزاد همچنین با مشکلات تکثیر، منقضی‌شدن و ادعاهای نادرست مواجه‌اند. هر فروشنده‌ای می‌تواند ادعای ارائه داده‌های باکیفیت بالا کند، اما عامل‌ها نمی‌توانند روزها را صرف بررسی‌های پیش‌زمینه مثل کارکنان تأمین انسانی کنند. لایه کشف باید به‌طور مداوم بررسی کند که آیا نقاط پایان قابل فراخوانی هستند، آیا نقل‌قول‌ها واقعی‌اند و آیا توصیف‌ها با محتوای بازگشتی مطابقت دارند.

این امر کشف خدمات را از جستجوی سنتی متمایز می‌کند. موتورهای جستجو برای ارتباط اطلاعات بهینه‌سازی می‌شوند، درحالی‌که دفترچه‌های تأمین ماشینی باید علاوه بر آن برای قابلیت معامله‌پذیری نیز بهینه‌سازی شوند: تطابق قابلیت‌ها، پذیرفتنی بودن قیمت‌ها، سازگان‌پذیری پرداخت‌ها و توانایی فروشندگان در تحویل کالا یا خدمات.

۳.۲ مانع دوم: درک و مقایسه نقل‌قول‌ها

در ظاهر، APIهای مشابه می‌توانند همگی بر اساس هر فراخوانی قیمت‌گذاری شوند، اما در عمل نقل‌قول‌ها به‌سختی قابل مقایسه‌اند. یکی بر اساس هر درخواست، دیگری بر اساس هر آیتم نتیجه؛ یکی استنتاج مدل را در قیمت لحاظ کرده، دیگری پرداخت اضافی می‌طلبد؛ و سرویس‌های دیگر بر اساس طول ورودی، زمان اجرا یا نتایج موفق به‌صورت پویا صورتحساب می‌گیرند.

عامل نمی‌تواند ساده‌لُعاً نقطه پایانی با کمترین قیمت اسمی را انتخاب کند. باید هزینه کل، احتمال تحویل، تأخیر و کیفیت نتیجه را در نظر بگیرد. اگر یک رابط ارزان به‌طور مکرر شکست بخورد، هزینه‌های تکرار و تأخیر در انجام وظیفه ممکن است قیمت موثر آن را افزایش دهد. بنابراین نقل‌قول‌ها باید در کنار سطح خدمات، عملکرد تاریخی و زمینه وظیفه ارزیابی شوند.

نقل‌قول‌های قابل‌خواندن توسط ماشین همچنین باید دوره اعتبار و مبلغ نهایی را مشخص کنند. در محیط قیمت‌گذاری پویا، آنچه عامل امضا می‌کند باید تعهدی محکم باشد، نه یک بازه قیمتی مبهم. اپراتورها همچنین باید ساختار هزینه‌ها را بدانند، از جمله هزینه‌های خدمات، هزینه‌های شبکه و هزینه‌های مسیریابی، تا بتوانند بودجه‌های معتبری تعیین کنند.

۳.۳ دروازه سوم: توزیع وجوه و نقدینگی متقاطع

اگر عاملی نیاز داشته باشد که همزمان خدمات را در چندین زنجیره و چندین پروتکل خریداری کند، ساده‌ترین راه‌حل، پیش‌بُردن موجودی در هر شبکه است. اما این کار سرمایه کوچکی را به بخش‌های متعددی تقسیم می‌کند. وجوه در شبکه‌هایی که در حال حاضر استفاده نمی‌شوند، بیکار می‌مانند، درحالی‌که شبکه‌های پربازدید ممکن است موجودی کافی نداشته باشند؛ تکمیل موجودی نیازمند پل‌زدن، تبدیل، هزینه گاز و عملیات امنیتی است.

برای یک کاربر انفرادی، این امر از قبل خسته‌کننده است. برای یک سازمان که تعداد زیادی عامل را مدیریت می‌کند، این مشکل تشدید می‌شود: هر عامل باید چه میزان موجودی نگه دارد؟ کی مسئول تکمیل موجودی است؟ چگونه از هزینه‌کردن نادرست وجوه جلوگیری شود؟ و چگونه دارایی‌ها و هزینه‌ها در شبکه‌های مختلف تجمیع شوند؟ بدون یک لایه تأمین واحد وجوه، هرچه راه‌های پرداخت بیشتر شوند، پیچیدگی مالی بیشتر می‌شود.

در ایده‌آل، آنچه عامل می‌بیند یک بودجه قابل‌صرف است، نه موجودی‌های متعدد در شبکه‌های مختلف. سیستم زیرین مسئولیت انتخاب مسیرهای تسویه، مدیریت نقدینگی و ارائه نقل‌قول‌های شفاف را بر عهده دارد. این اصل مشابه استفاده از یک کارت توسط مسافر در کشورهای مختلف است: کاربر به سقف اعتبار کلی و نرخ ارز توجه دارد و نیازی به بازکردن حساب محلی در هر مقصد ندارد.

۳.۴ دروازه چهارم: اجازه‌دهی مبتنی بر سیاست

نگرانی‌ای که بیشترین احتمال را برای فعال‌سازی پرداخت‌های خودکار دارد، این است که آیا عامل بدون کنترل هزینه خواهد کرد. راه‌حل این نیست که صرفاً بین «ممنوعیت کامل» و «اجازه‌دهی کامل» انتخاب شود، بلکه ایجاد سیاست‌های چندلایه است.

سقف هر معامله از ضرر ناشی از یک اشتباه تکی جلوگیری می‌کند، بودجه جلسه کل هزینه یک وظیفه را محدود می‌کند، لیست سفید یا سیاه فروشندگان طرف مقابل را کنترل می‌کند، قوانین دسته‌بندی محدودیت‌هایی بر روی اقلام قابل خرید اعمال می‌کنند و محدودیت‌های نرخ از فراخوانی‌های غیرعادی در بازه زمانی کوتاه جلوگیری می‌کنند. معاملات پرخطر یا باارزش می‌توانند نیز تأیید دستی را فعال کنند. سیاست‌ها باید توسط اپراتورها تعیین شوند و عامل‌ها تنها در محدوده‌های تعیین‌شده عمل می‌کنند—آن‌ها نمی‌توانند محدودیت‌ها را خودسرانه افزایش دهند.

کیف پول نباید صرفاً عملیات امضا را انجام دهد. بلکه باید با وظایف، هویت و سوابق حسابرسی ترکیب شود تا به این پرسش‌ها پاسخ دهد: «کدام عامل این پرداخت را برای چه وظیفه‌ای و تحت چه سیاستی تأیید کرده است؟» در غیر این صورت، بنگاه تنها مجموعه‌ای از هش‌های تراکنش‌های زنجیره‌ای خواهد داشت که نمی‌تواند الزامات کنترل‌های داخلی و تخصیص هزینه‌ها را برآورده کند.

۳٫۵ مرحله پنج: تسویه موفق لزوماً معادل ارائه خدمات نیست

بلوکچین در اثبات انتقال وجوه از یک آدرس به آدرس دیگر بسیار قوی است، اما ذاتاً نمی‌تواند اثبات کند که یک API محتوای صحیحی بازگردانده است. یک تراکنش ممکن است به‌طور کامل تسویه شود، اما سرور ممکن است قطع شود، وضعیت خطایی بازگرداند یا داده‌هایی ارسال کند که با آنچه اعلام شده مطابقت ندارد. برای عوامل، این مورد یک حالت نادر نیست—بلکه هسته ریسک خرید است.

در تجارت الکترونیک سنتی، پرداخت و تحویل از طریق لجستیک، نظرات و بازپرداخت‌ها به هم متصل می‌شوند؛ اما خدمات ماشینی هیچ لجستیک فیزیکی ندارند—تحویل ممکن است تنها یک پاسخ موقت HTTP باشد. اگر سیستم‌های پرداخت تنها مسیر وجوه را ثبت کنند و فروشندگان تنها پاسخ‌های خود را ثبت کنند، بازار فاقد دیدگاه واحدی از تکمیل سفارش است که فروشندگان و پروتکل‌ها را پوشش دهد.

نکته‌ای که نیازمند احتیاط است این است که ثبت یک پاسخ، معادل اثبات کیفیت آن نیست. اما همبستگی پرداخت با پاسخ حداقل می‌تواند حالت‌های اولیه را تشخیص دهد: «پرداخت شده و نتیجه دریافت شده»، «پرداخت شده اما خدمات انجام نشده» و «تسویه نشده». این اولین لایه واقعیت برای ساختن اعتبار تراکنش‌های ماشینی است.

۳٫۶ مرحله شش: تطبیق یکپارچه و تعریف مسئولیت

یک وظیفه منفرد ممکن است شامل ده‌ها خرید ریز باشد. اگر هر تراکنش در کیف‌پول‌ها، پروتکل‌ها و سیستم‌های پشتی‌بان فروشندگان مختلف پراکنده باشد، کاربران نمی‌توانند درک کنند که چرا هزینه نهایی محصول چنین مقداری شده است. بنگاه‌ها همچنین نیازمند تخصیص هزینه‌ها به پروژه‌ها، تیم‌ها، مشتریان و مراکز هزینه‌ای هستند و باید شواهد قابل حسابرسی را نگهداری کنند.

دفتر کل یکپارچه باید همزمان نیت خرید، فروشندگان، نقل‌قول‌ها، سیاست‌های مجاز، نتایج تسویه، وضعیت پاسخ و دلایل شکست را ثبت کند. این دفتر کل نه‌تنها برای مالی، بلکه برای بهینه‌سازی عوامل نیز کاربرد دارد. سیستم می‌تواند تحلیل کند که کدام منابع داده به‌طور مکرر شکست می‌خورند، کدام مسیرها هزینه‌برترند و ترکیب خرید معمول برای نوع خاصی از وظیفه چیست.

هنگامی که پرداخت در زنجیره استدلال جاسازی می‌شود، هزینه به سیگنالی بازخوردی برای تصمیمات مدل تبدیل می‌شود. بدون تطبیق یکپارچه، عوامل تنها می‌توانند پاسخ‌ها را بهینه‌سازی کنند، نه فرآیند اقتصادی کسب پاسخ‌ها. بخش عمده‌ای از ارزش بلندمدت «پرداخت عوامل» دقیقاً از این قابلیت مشاهده‌پذیری ناشی می‌شود.

۴. از پروتکل پرداخت به لایه خرید ماشینی

۴٫۱ انتزاع اصلی آینده «پرداخت» نیست، بلکه «خرید» است

پرداخت عملی است که پس از مشخص شدن شیء و قیمت انجام می‌شود، درحالی‌که خرید فرآیند کاملی از تقاضا تا پذیرش را پوشش می‌دهد. ارائه تابع pay() به یک عامل تنها به آن اجازه انتقال وجوه به یک آدرس شناخته‌شده را می‌دهد؛ اما ارائه قابلیت buy() به این معناست که سیستم می‌تواند تقاضا را دریافت کند، خدمات را کشف کند، گزینه‌ها را مقایسه کند، پرداخت را انجام دهد و نتایج قابل اثباتی ارائه دهد.

این تفاوت تعیین‌کننده تقسیم کار در صنعت است. پروتکل‌ها پیام‌های استاندارد پرداخت را فراهم می‌کنند، کیف‌پول‌ها امضاهای دیجیتال و دارایی‌ها را مدیریت می‌کنند، شبکه‌های تسویه ارزش را منتقل می‌کنند، دایرکتوری‌ها عرضه را تجمیع می‌کنند و لایه خرید این اجزا را در قالب یک وظیفه واحد سازمان‌دهی می‌کند. هر یک از این اجزا مهم است، اما هیچ‌کدام به‌تنهایی نمی‌توانند یک تراکنش کامل را نمایند.

لایه خرید ماشینی باید باز بماند. این لایه نباید از تمام فروشندگان انتقال به یک پروتکل مشترک را اجباری کند و نباید از طریق یک دایرکتوری بسته تعیین کند که چه کسانی قابل خرید هستند. مدل پایدارتر این است که با ریل‌های پرداخت متعددی سازگار باشد، هزینه‌های مسیریابی را در نقل‌قول‌ها افشا کند و به عوامل اجازه دهد بر اساس سیاست‌ها به‌صورت خودمختار انتخاب کنند.

۴٫۲ تجمیع خریداران ممکن است از تجمیع فروشندگان مهم‌تر باشد

پلتفرم‌های اینترنتی معمولاً ابتدا عرضه را تجمیع می‌کنند و سپس مصرف‌کنندگان را جذب می‌کنند. در بازارهای ماشینی، عرضه به‌صورت گسترده در قالب APIها وجود دارد؛ آنچه کمبود دارد، یک خریدار استاندارد است که قادر به خریدهای مداوم باشد. یک عامل مجهز می‌تواند تقاضای پراکنده و تصادفی را به جریان تراکنش‌های پایدار تبدیل کند.

تجمیع خریداران همچنین شفافیت خدمات کم‌مصرف (Long-tail) را افزایش می‌دهد. توسعه‌دهندگان انسانی تمایل دارند از برندهای بزرگ و آشنا استفاده کنند، زیرا هزینه زمانی ارزیابی تأمین‌کنندگان جدید بالاست؛ اگر عوامل بتوانند قابلیت‌ها، قیمت و سیگنال‌های تکمیل سفارش را به‌صورت استاندارد بخوانند، می‌توانند برای هر وظیفه مناسب‌ترین خدمات را انتخاب کنند. این ممکن است هزینه جذب مشتری برای فروشندگان جدید را کاهش دهد و همچنین فروشندگان برقرار شده را وادار به رقابت بر اساس عملکرد واقعی کند.

اما نقاط ورود خریداران می‌توانند قدرت جدیدی از پلتفرم ایجاد کنند. هرکسی که دایرکتوری پیش‌فرض، رتبه‌بندی و مسیرهای پرداخت را کنترل کند، ممکن است بر تخصیص ترافیک تأثیر بگذارد. بنابراین، صنعت به قوانین شفاف رتبه‌بندی، هزینه‌های توضیح‌پذیر و سوابق تراکنش‌های قابل انتقال نیاز دارد. تجمیع می‌تواند اصطکاک را کاهش دهد، اما نباید پروتکل‌های باز را به کانال‌های بسته تبدیل کند.

۴٫۳ ساختن شهرت بر اساس داده‌های واقعی تراکنش

خریداران ماشینی بسیار سریع تصمیم می‌گیرند و نمی‌توانند بر روی بررسی‌های دقیق و طولانی متکی باشند. آنها نیازمند سیگنال‌های مقابل در همان زمانی هستند که نقل‌قول ارائه می‌شود. امتیازدهی‌ها و نظرات کاربران سنتی می‌توانند مرجعی باشند، اما به‌راحتی توسط حجم جعلی، حساب‌های سیبیل و اشخاص وابسته دستکاری می‌شوند. اگر نظرات نیازی به پرداخت واقعی نداشته باشند، هزینه حمله بسیار پایین است. تحقیقات تجربی اخیر درباره ERC-8004 — اولین لایه اعتماد زنجیره‌ای بدون مجوز برای عوامل — این موضوع را تأیید می‌کند [۶]. در مشخصات این پروتکل به‌وضوح آمده است که «پرداخت‌ها با این پروتکل مستقل هستند» — یعنی نظرات به‌طور پیش‌فرض لزوماً به هیچ تراکنش پرداخت واقعی‌ای مرتبط نیستند و اثبات پرداخت تنها یک فیلد اختیاری است. نتیجه این است که در اتریوم، BSC و Base (تا ۱۳ می ۲۰۲۶)، به‌ترتیب ۷۳٫۵٪، ۵۹٫۲٪ و ۹۰٫۶٪ از نظردهندگان رفتار هماهنگ سیبیل نشان داده‌اند.

پایه‌ای قابل اعتمادتر، سوابق نتایج مرتبط با تماس‌های پرداخت‌شده واقعی است: تعداد تسویه‌های انجام‌شده توسط یک نقطه پایانی سرویس، نرخ موفقیت پاسخ، زمان تأخیر رایج و درصد بالای عدم پاسخ پس از پرداخت. این شاخص‌ها هنوز نمی‌توانند کیفیت محتوا را به‌طور کامل نشان دهند، اما نسبت به ادعاهای خوداظهاری، به حقایق قابل تأیید نزدیک‌ترند.

با انباشته‌شدن داده‌ها، ممکن است بازار سیستم اعتباربندی سلسله‌مراتبی توسعه یابد: سطح اول وضعیت عینی تراکنش‌ها، سطح دوم شاخص‌های سرویس قابل تکرار و سطح سوم ارزیابی کیفیت برای وظایف خاص است. عامل‌ها می‌توانند قوت مورد نیاز شواهد را بر اساس مبلغ و ریسک انتخاب کنند: برای پرس‌وجوی داده‌ای با هزینه چند سنتی می‌توان از سیگنال‌های آماری استفاده کرد، اما برای خریدهای ارزشمند، تضمین‌ها، حسابرسی‌ها یا حل اختلاف لازم است.

۴.۴ استراتژی بودجه‌بندی به توانایی مهمی برای عامل‌ها تبدیل خواهد شد

امروزه عامل‌ها عمدتاً بر اساس کیفیت پاسخ، نرخ تکمیل وظیفه و دقت فراخوانی ابزارها ارزیابی می‌شوند. اما پس از ورود به محیط‌های پرداختی، شاخص‌های اقتصادی نیز باید افزوده شوند: هزینه صرف‌شده برای دستیابی به کیفیت مشابه، تکمیل وظیفه در چارچوب بودجه، زمان مناسب برای خرید داده‌های گران‌تر و نحوه تعادل بین سرعت، هزینه و قابلیت اطمینان.

این امر جهت‌گیری‌های جدیدی برای آموزش و ارزیابی ایجاد می‌کند. عامل‌ها نه‌تنها یاد می‌گیرند «کدام ابزار می‌تواند به سؤال پاسخ دهد»، بلکه می‌آموزند «آیا خرید این ابزار با توجه به ارزش وظیفه فعلی، مقرون‌به‌صرفه است؟». ممکن است ابتدا از سرویس‌های کم‌هزینه برای فیلتر کردن استفاده کنند، سپس برای نتایج کلیدی از تأییدکننده‌های باکیفیت‌تر استفاده نمایند؛ یا هنگام نزدیک شدن به اتمام بودجه، فراخوانی‌ها را کاهش دهند یا اجازه اضافی از کاربر درخواست کنند.

در این معنا، پرداخت عامل‌ها یک افزونه مالی جدا از قابلیت‌های مدل نیست، بلکه بخشی از هوش تصمیم‌گیری است. یک عامل واقعاً بالغ نه‌تنها باید از منابع استفاده کند، بلکه باید منابع را قیمت‌گذاری کند.

۵. مسیرهای احتمالی تکامل پرداخت عامل‌ها

۵.۱ مرحله اول: ابزارهای توسعه‌دهنده و سرویس‌های دیجیتال پیشرو هستند

اولین سناریوهای گسترده، احتمالاً همچنان کاملاً دیجیتال و مربوط به جستجو، داده، اسکرپینگ از طریق پروکسی، استنتاج مدل‌ها، اجرای کد، ذخیره‌سازی و تولید محتوا خواهند بود. این سرویس‌ها خود از طریق API ارائه می‌شوند، هزینه حاشیه‌ای تأمین آن‌ها کم است، پرداخت و پاسخ در یک جلسه شبکه‌ای انجام می‌شود و نیازی به لجستیک پیچیده ندارند.

مبالغ معمول در این مرحله بسیار کوچک است و کاربران بر راحتی توسعه و نرخ تکمیل وظیفه تمرکز دارند. بازار به‌سرعت پروتکل‌ها را اعتبارسنجی می‌کند، اما حجم تراکنش‌ها ممکن است بسیار پراکنده باشد. بسیاری از فراخوانی‌ها همچنان توسط کلیدهای API و اشتراک‌های سنتی مدیریت می‌شوند و پرداخت‌های ماشینی عمدتاً برای نیازهای موقت، خریدهای بین‌فروشنده و سرویس‌های کم‌طرف (long-tail) که نمی‌توان آن‌ها را پیش‌اکتفا به‌عنوان حساب باز کرد، استفاده می‌شوند.

۵.۲ مرحله دوم: بودجه‌های سازمانی و همکاری چندعاملی

هنگامی که سازمان‌ها شروع به استقرار چندین عامل می‌کنند، مدیریت بودجه از کیف پول شخصی به سیستم‌های حساب سطح سازمانی ارتقا می‌یابد. سازمان‌ها باید بودجه را بین نقش‌های مختلف تخصیص دهند، دسته‌بندی‌های قابل خرید را کنترل کنند، آستانه‌های تأیید را تعیین نمایند و هزینه‌ها را در سیستم‌های مالی ثبت کنند. تسویه داخلی نیز می‌تواند بین عامل‌ها ایجاد شود: عامل‌های تحقیقاتی داده می‌خرند، عامل‌های تحلیلی قدرت محاسباتی می‌خرند و عامل‌های اجرایی سرویس‌های خارجی را فراخوانی می‌کنند.

در این مرحله، امنیت و انطباق اهمیت بیشتری از نوآوری پرداخت دارد. سازمان‌ها به مدیریت کلیدها، جداسازی مجوزها، نظارت بر تراکنش‌ها، بررسی فروشندگان و ردیابی حسابرسی اهمیت می‌دهند. تنها زیرساخت‌هایی که بتوانند با فرآیندهای مالی موجود یکپارچه شوند، می‌توانند از مرحله آزمایشی به تولید واقعی منتقل شوند.

۵.۳ مرحله سوم: گسترش از سرویس‌های دیجیتال به اقتصاد واقعی

بلیط هواپیما، هتل‌ها، لجستیک، تبلیغات و خدمات حرفه‌ای ممکن است همه به اهداف خرید عامل‌ها تبدیل شوند، اما تراکنش‌های دنیای واقعی نیازمند احراز هویت، بازپرداخت، مالیات و رسیدگی به اختلافات پیچیده‌تری هستند. استیبل‌کوین‌ها تنها بخشی از مسئله تسویه را حل می‌کنند و نمی‌توانند حقوق مصرف‌کننده و قراردادهای تجاری را جایگزین کنند.

بنابراین، صنعت نباید «پرداخت خودمختار» را به‌اشتباه به‌معنای حذف تمام واسطه‌ها تفسیر کند. برعکس، با افزایش ارزش تراکنش، تضمین‌ها، بیمه، اعتبار و داوری مجدداً ظاهر می‌شوند — اما باید به سرویس‌هایی تبدیل شوند که ماشین‌ها بتوانند آن‌ها را فراخوانی کنند. پشته آینده پرداخت عامل‌ها ممکن است همزمان شامل پروتکل‌های پرداخت باز و اتصال به سیستم‌های مالی سنتی باشد، نه اینکه یک مسیر جایگزین دیگری شود.

۵.۴ مرحله چهارم: از مسیریابی بین پروتکلی به اجرای بین بازاری

در بلندمدت، آنچه عامل‌ها خریداری می‌کنند، صرفاً یک پاسخ API نیست، بلکه یک نتیجه است. کاربر ممکن است درخواست «تولید گزارش صنعتی معتبر» را بدهد و سیستم به‌صورت خودکار سرویس‌های جستجو، پایگاه‌های داده، ترجمه، مدل‌ها و تأیید را ترکیب کند. تراکنش‌های متعددی در لایه زیرین انجام می‌شوند، درحالی‌که کاربر تنها بودجه کلی، منابع شواهد و تحویل نهایی را می‌بیند.

این امر مسیریابی پرداخت را به اجرای بازار تبدیل می‌کند. سیستم باید اهداف پیچیده را به سبد خریدهایی تقسیم کند، فروشندگان ناموفق را پویا جایگزین کند و بین کل هزینه و کیفیت بهینه‌سازی انجام دهد. سازگاری پروتکلی تنها پایه است؛ مزیت رقابتی واقعی از درک نیاز، داده‌های تراکنشی و بازخورد اجرایی ناشی می‌شود.

۶. ریسک‌ها و پرسش‌های باز

پرداخت عاملی پتانسیل خلاقانهٔ بسیار گسترده‌ای دارد، اما محدودیت‌های دنیای واقعی را نمی‌توان نادیده گرفت. اولین مورد امنیت است. تزریق پِرامپت ممکن است عامل‌ها را به خرید خدمات مخرب وادارد، حملات زنجیره تأمین ممکن است آدرس‌های دریافتی را جایگزین کند و سیاست‌های ناقص ممکن است منجر به پرداخت‌های تکراری عظیم شوند. اقدامات پرداخت باید از محتوای غیرقابل اعتماد جدا شده و با محدودیت، شبیه‌سازی، لغو و تشخیص ناهنجاری مجهز شوند.

دومین مورد حریم خصوصی است. سوابق تدارکات نشان‌دهندهٔ وظایف انجام‌شده توسط عامل است و داده‌های عمومی بلاکچین ممکن است هویت کاربر را با قصد تجاری‌اش مرتبط کند. سیستم‌ها باید نشت متادیتاهای حساس را به حداقل برسانند و بین الزامات حسابرسی و حریم خصوصی تعادل برقرار کنند.

سومین مورد مسئولیت است. هنگامی که عامل خریدی اشتباه انجام دهد، فروشنده تحویل ندهد یا تبدیل پروتکلی شکست بخورد، کی باید ضرر را متقبل شود؟ برای تراکنش‌های کم‌ارزش می‌توان ریسک خودکار را پذیرفت، اما تراکنش‌های پرارزش نیازمند مرزهای شفاف مسئولیت هستند. شبکه پرداختی بدون مکانیزم اختلاف‌حل‌کردن نمی‌تواند مستقیماً وارد تجارت پرارزش شود.

چهارمین مورد مقررات است. صدور استیبل‌کوین‌ها، کنترل کیف‌پول‌ها، انتقالات بین‌المللی و پرداخت‌های فروشنده تحت قوانین مختلف حوزه‌های قضایی قرار دارند. ماشین‌ها اجراکننده‌اند، نه ذینفعان مسئولیت حقوقی. زیرساخت باید قادر باشد هر تراکنش خودمختار را به اپراتور مشخص، سیاست اجازه‌دهنده و منبع وجوه بازگرداند.

پنجمین مورد پایداری تجاری است. درآمد ریزپرداخت‌ها به‌راحتی توسط هزینه‌های شبکه، نقدینگی و کارمزدهای کنترل ریسک کاهش می‌یابد. اگر پلتفرم‌ها تجربه را از طریق افزایش‌های پنهان یارانه دهند، اعتماد خریداران را تضعیف می‌کنند. کارمزدها باید شفاف باشند و مدل کسب‌وکار سالمی باید از طریق مقیاس، کارایی مسیریابی و خدمات ارزش‌افزوده ایجاد شود.

این مسائل بخش را نفی نمی‌کنند؛ بلکه نشان می‌دهند که پرداخت عاملی تنها با یک پروتکل کامل نخواهد شد. در نهایت، زیرساختی ترکیبی برای پرداخت، هویت، مجوزها، کشف، اعتبار و تسویه خواهد شد.

۷. سلات: تجهیز سمت خرید برای تجارت ماشین‌محور

«سلات» از واژهٔ مالایی «تنگه» گرفته شده است، مانند تنگه مالاکا (سلات ملاکا). قرن‌هاست که صرف‌نظر از بندر مبدأ کالاها یا بازار مقصد، جریان اصلی تجارت شرق و غرب از این آب‌راه عبور می‌کرده است. سلات قصد دارد این تنگه را در تجارت ماشین‌محور ایجاد کند: صرف‌نظر از اینکه فروشنده در کدام ریلی لنگر انداخته، تقاضای عامل می‌تواند از اینجا عبور کند.

سلات شرکتی هوش مصنوعی‌محور است که از سمت خرید وارد پرداخت‌های ماشینی می‌شود. سلات لایهٔ سمت خرید برای تجارت ماشین‌محور است. هدف اصلی آن ایجاد ریل پرداخت جدیدی نیست که فروشنده‌ها مجبور به مهاجرت شوند، بلکه امکان انجام تدارکات توسط عامل‌ها روی ریل‌های موجود را فراهم می‌کند. این شرکت بر دو مسئلهٔ اصلی تمرکز دارد: اول، پراکندگی پیکربندی‌های پرداخت که در آن ریل‌ها، پروتکل‌ها، زنجیره‌ها و اعتبارنامه‌ها همگی متفاوت‌اند و برای هر فروشنده نیاز به یک ادغام جدید است؛ و دوم، عدم وجود سنجش ریسک طرف مقابل، چرا که تسویهٔ موفق لزوماً به معنای تحویل خدمات نیست.

شکل ۳: نمودار شماتیک لایهٔ سمت خرید سلات

برای رفع پراکندگی، CLI سلات تفاوت‌های پروتکل‌ها، طرح‌های پرداخت و شبکه‌های تسویه را در لایهٔ زیرساخت نگه می‌دارد و اجازه می‌دهد عامل‌ها با یک دستور واحد تدارکات متقاطع ریلی را انجام دهند. کشف، ارائه قیمت، اجازه‌دهی، پرداخت، ثبت وضعیت تحویل و تسویه همه در فرآیند تدارکات یکسان گنجانده شده‌اند و هر تماس نیز در همان دفترکل ثبت می‌شود.

• یک خزانه با استفاده از N ریل پرداخت

عامل‌ها موجودی USDC را به‌صورت خودمختار نگه می‌دارند و نیازی به پیش‌شارژ بر اساس زنجیره یا نگهداری مشتری‌های مجزا برای پروتکل‌های مختلف ندارند.

• کاتالوگ یکپارچهٔ نقطه‌های پایانی

CLI سلات چهار ثبت‌گاه سرویس شخص ثالث — سرکل، MPP، Apify و pay.sh — را به‌همراه کاتالوگ داخلی سلات ادغام کرده و امکان کشف و مقایسهٔ بیش از ۴۰۰۰ نقطهٔ پایانی سرویس را بر اساس قصد بلادرنگ فراهم می‌کند.

• سقف‌های سخت هزینه‌کردن

اپراتورها می‌توانند سقف هر تراکنش و بودجه جلسه را تعیین کرده و در هر زمان مجوز هزینه‌کردن را معلق کنند؛ عامل‌ها نمی‌توانند سقف‌ها را خودسرانه افزایش دهند.

• عدم نیاز به مهاجرت فروشنده

فروشنده‌ها می‌توانند ریل‌های پرداخت مورد علاقه‌شان را حفظ کرده و بدون ثبت‌نام مجدد در سلات توسط عامل‌ها کشف و خریداری شوند.

در سمت تأمین بودجه، سلات با هر کیف‌پول عاملی سازگار است، از جمله کیف‌پول‌های عاملی سرکل و متامسک. سلات هر خرید را بر اساس نقل‌قول‌های بلادرنگ از طریق ریل‌های پرداختی مانند x402 و MPP مسیریابی می‌کند.

۷.۱ ERC-8004: اصول اولیهٔ صحیح، سیگنال‌های مشکوک

ERC-8004 سه نوع ثبت‌نام—هویت، اعتبار و تأیید—را تعریف می‌کند و به خریداران اجازه می‌دهد نظراتی دربارهٔ فروشندگان ارسال کنند. جهت کلی درست است، اما به‌صورت صریح پرداخت را از اعتبار جدا می‌کند: بازخوردها لازم نیست از تراکنش‌های واقعی ناشی شوند و ارائهٔ اثبات پرداخت اختیاری است.

پژوهش‌های تجربی روی اکوسیستم اجرایی نشان می‌دهد که در Base، ۹۳٫۸٪ از نظردهندگان هرگز پرداخت x402 انجام نداده‌اند، اما ۹۴٫۹٪ از بازخوردها را ارائه کرده‌اند؛ بخش عمده‌ای از این بازخوردها نیز رفتار هماهنگ سیبیل را نشان می‌دهند [۶]. ثبت‌نام‌ها ادعاها را ثبت می‌کنند، اما آنچه خریداران واقعاً نیاز دارند، نتایج هستند.

۷.۲ اعتبار مرتبط با داده‌های تراکنش واقعی آنچه خریداران نیاز دارند است

راه‌های پرداخت می‌توانند تسویهٔ وجوه را تأیید کنند، اما نمی‌توانند بدانند خدمات چه چیزی بازگردانده است؛ فروشندگان تنها پاسخ‌های خود را می‌بینند، نه کل بازار؛ ثبت‌نام‌ها می‌توانند نقاط پایانی را فهرست کنند، اما نمی‌توانند اثبات کنند که بازخوردها از خریدهای واقعی ناشی شده‌اند.

لایهٔ خریدار که خریدها را اجرا می‌کند، بهترین موقعیت را برای اتصال دو انتهای تراکنش دارد: هر خرید انجام‌شده از طریق SELAT، نقطهٔ پایانی پرداخت‌شده، مقدار تسویه‌شده و متادیتای وضعیت تحویل پس از پرداخت (۲xx، ۴xx، ۵xx) را ثبت می‌کند. این رکوردها به‌طور مداوم بر اساس فروشنده و راه پرداخت انباشته می‌شوند و بنیان داده‌ای «نمودار تسویه–تحویل» را تشکیل می‌دهند.

تمایز دقیقی لازم است: رکوردهایی که پرداخت و وضعیت تحویل را به هم پیوند می‌زنند، معادل اثبات مستقل از کیفیت تحویل یا دقت نقل قول نیستند. اما این رکوردها بنیانی را فراهم می‌کنند که اعتبار مبتنی بر ثبت‌نام فاقد آن است—یعنی داده‌های نتیجه‌محور که به فراخوان‌های پرداخت‌شدهٔ واقعی پیوند خورده‌اند.

۷.۳ کسب اعتبار طرف مقابل پیش از تراکنش‌ها

درست همان‌طور که در X دربارهٔ طراحی مکانیزمی اعتماد شبیه به Google PageRank برای اینترنت نسل چهارم بحث می‌شد، SELAT قبلاً «شاخص قابلیت تراکنش» را بر پایهٔ نمودار تسویه–تحویل راه‌اندازی کرده بود تا داده‌های اعتبار طرف مقابل را مبتنی بر نتایج تراکنش‌های واقعی در اختیار عامل‌ها قرار دهد.

این شاخص همراه با نقل قول‌ها ارائه می‌شود و نیازی به توقف عامل‌ها برای بررسی جداگانهٔ فروشندگان ندارد. این شاخص ریسک را نشان می‌دهد بدون اینکه دروازه‌ای برای بازار ایجاد کند: نقاط پایانی همچنان قابل کشف و خرید هستند و عامل‌ها تصمیم می‌گیرند بر اساس بودجه، اهمیت وظیفه و ترجیح ریسک خود.

عامل‌ها وقت ندارند تا داستان‌های برند را بخوانند. آنها قبل از پرداخت باید بدانند: عملکرد این نقطهٔ پایانی در تراکنش‌های واقعی چگونه است؟ اعتبار در تجارت ماشینی باید از ادعاها، بلکه از نتایج ناشی شود.

شکل ۳: سیگنال‌های قابلیت تراکنش در مرحلهٔ نقل قول

در حال حاضر، رابط خط فرمان SELAT برای محیط‌های اجرا عامل شامل Claude Code، Codex، Cursor، Gemini CLI، OpenClaw، Hermes و Grok Bot سازگانده شده است.

۸. خلاصه: اقتصاد ماشینی نیازمند بیش از صرفاً راه‌های پرداخت سریع‌تر است

پرداخت عامل در مرحله‌ای است که به‌راحتی بیش‌ازحد تخمین زده یا کم‌تر از حد تخمین زده می‌شود. بیش‌ازحد تخمین زده می‌شود، چون انجام فنی یک پرداخت پایدارسکوین لزوماً به معنای دستیابی عامل به خودمختاری تجاری بالغ نیست؛ و کم‌تر از حد تخمین زده می‌شود، چون همین‌که نرم‌افزار بتواند قابلیت‌های خارجی را در محدودیت‌های مشخصی خریداری کند، روش‌های سازمانی، مدل‌های قیمت‌گذاری و مرزهای رقابتی اقتصاد ماشینی را تغییر خواهد داد.

پروتکل‌های پرداخت از پیش ثابت کرده‌اند که ماشین‌ها می‌توانند نقل قول‌ها را دریافت و تسویه را انجام دهند. گام کلیدی بعدی، گسترش یک پرداخت منزوی به یک فرآیند تأمین کامل است: توانایی عامل‌ها در یافتن خدمات مناسب، درک هزینه‌های واقعی، پرداخت در راه‌های مختلف در چارچوب بودجه، تأیید تحویل و تبدیل هر تراکنش به رکوردی قابل حسابرسی و قابل یادگیری.

اقتصاد ماشینی آینده تنها یک زنجیره، یک پروتکل یا یک کیف پول نخواهد داشت. تأمین چندمنبعی برای مدت طولانی ادامه خواهد یافت و زیرساخت‌های واقعاً ارزشمند به خریداران در پیمایش این پیچیدگی کمک خواهند کرد. پرداخت عامل باید راه‌های پرداخت، عرضه، پرداخت‌های پیش‌فرض و مکانیزم‌های اعتماد را ترکیب کند تا ظرفیت فنی را به تقاضای واقعی تبدیل کند.

وقتی نرم‌افزار شروع به عمل به عنوان خریدار می‌کند، پرداخت تنها اولین گامی است که می‌برد. اما سؤال مهم‌تر همواره این بوده است: آیا می‌تواند یک تراکنش واقعاً مفید را به‌صورت کنترل‌پذیر، شفاف و قابل تأیید انجام دهد؟

منابع

[۱] Circle، «ساخت اقتصاد عاملی باز»، ۲۰۲۶. https://www.circle.com/blog/building-the-open-agentic-economy

[۲] سلات، «ریسک طرف مقابل در پرداخت‌های عامل‌محور: نیمهٔ اندازه‌گیری‌نشده»، ۲۰۲۶. https://selat.ai/insights/counterparty-risk-agentic-payments

[۳] ابر گوگل، «قدرت‌بخشی به تجارت هوشمند با پروتکل جدید پرداخت‌های عاملی (AP2)»، ۲۰۲۵. https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol

[۴] بنیاد x402، «x402: استاندارد پرداختی باز و بومی اینترنت». https://github.com/x402-foundation/x402

[۵] پروتکل پرداخت‌های ماشینی، «MPP: پروتکل پرداخت ماشینی مبتنی بر HTTP 402». https://mpp.dev/

[۶] شیونگ و همکاران، «آیا عامل‌های بی‌اعتماد قابل اعتمادند؟ مطالعه‌ای تجربی از اکوسیستم عامل‌های هوش مصنوعی غیرمتمرکز ERC-8004»، arXiv، ۲۰۲۶. https://arxiv.org/abs/2606.26028

[۷] وب‌سایت رسمی سلات: https://www.selat.ai

این مقاله توسط نویسنده‌ای ارسال شده و دیدگاه‌های بلوک‌بیتس را منعکس نمی‌کند.