تصور کنید یک برنامهنویس بتواند در کمتر از ۱۵ دقیقه، یک ابزار کوچک کدنویسی را به محصولی تبدیل کند که عاملهای هوش مصنوعی برای استفاده از آن پول پرداخت میکنند. این یعنی پایان عصرِ اجبار به ساخت زیرساختهای پیچیده اشتراکی برای کسب درآمد از APIها. در حالی که مدلهای سنتی درآمدزایی از API نیازمند سیستمهای پیچیده صورتحساب SaaS هستند، AIMarket Hub به توسعهدهنده اجازه میدهد یک API سفارشی را برای عاملهای خودمختار قابل کشف کرده و به ازای هر فراخوانی، پرداخت دریافت کند. این جریان کاری بهینه، زیرساختهای قدیمی را با یک کاتالوگ باز جایگزین میکند که مدیریت کشف، مسیریابی و اندازهگیری مصرف را بر عهده دارد.
در حالی که بحثهای کلی درباره «اقتصاد عاملها» در اسلایدهای مدیریتی رایج است، واقعیت عملی به سمت مدلهای درآمدی ذرهبینی و ابزار-محور حرکت میکند. همانطور که در تحلیلهای پیشین ما دربارهی اقتصاد مدلهای زبانی اشاره کردیم، توسعهدهندگان پیش از این بین دو گزینه سخت گیر بودند: یا API خود را رایگان نگه دارند یا یک سیستم کامل زیرساخت اشتراکی بسازند. اکنون راه سومی باز شده است که در آن یک نقطه انتهایی HTTP ساده به یک محصول پرداختی برای مصرفکنندگان هوش مصنوعی تبدیل میشود. این رویکرد تکمیلی است بر پروتکل x402 که پیشتر توانست هزینه فراخوانی APIها را به مقادیر بسیار ناچیز برساند و مسیر را برای پرداختهای خرد هموار کرد.
طبق راهنمای فنی منتشر شده در ۱۲ سپتامبر ۲۰۲۶، این فرآیند بر پایه یک فایل مانیفست به نام capability.json استوار است. این فایل نام ابزار، قیمت و طرحوارههای (Schemas) ورودی و خروجی را تعریف میکند. AIMarket Hub در اینجا نقش واسطه را دارد؛ وقتی عاملی مانند ARGUS به دنبال یک قابلیت میگردد و آن را فراخوانی میکند، هاب درخواست را مسیریابی کرده و بر اساس مقدار تعریف شده در price_per_call_usd هزینه را محاسبه و اندازهگیری میکند.
پیشنیازها و زمینهسازی
برای شروع این چرخه ۱۵ دقیقهای، توسعهدهندگان به پایتون ۳.۱۱ به بالا و رابط خط فرمان (CLI) هاب از PyPI (نسخه ۳.۲.۱ aimarket-hub) نیاز دارند. فرآیند راهاندازی شامل نصب CLI از طریق pip و کلون کردن مخزن aimarket-hub از گیتهاب است.
توسعهدهندگان میتوانند بین دو محیط هاب انتخاب کنند. یک هاب محلی که با دستور aimarket serve در آدرس http://127.0.0.1:9083 برای تست سریع اجرا میشود. برای محیط عملیاتی، از هاب عمومی در آدرس https://modelmarket.dev استفاده میشود، هرچند این محیط نیازمند گیتهای اضافی مانند استیکینگ (Staking) و پاسخهای امضا شده است. این ساختار به توسعهدهندگان اجازه میدهد مشابه تجربه پیادهسازی عاملهای محلی برای شکار فرصتهای مالی، بدون نیاز به زیرساختهای عظیم، ابزارهای خود را تست و عرضه کنند.
پیادهسازی فنی
برای استقرار یک ابزار پرداختی، توسعهدهندگان مراحل دقیق زیر را دنبال میکنند:
- راهاندازی نقطه انتهایی: ایجاد یک Endpoint از نوع POST که JSON میپذیرد و نتیجه را برمیگرداند. مثال ارائه شده از یک خوشآمدگوی ساده مبتنی بر پایتون در مسیر
examples/hello-capabilityاستفاده میکند که روی آدرسhttp://127.0.0.1:3456/invokeگوش میدهد. سرور یک Payload شاملinput،product_idوcapability_idرا دریافت کرده و باید یک پاسخ HTTP 200 با بدنه{"result": {...}}برگرداند. - ساخت مانیفست: تعریف شناسه قابلیت (مثلاً
greet@v1) و URL فراخوانی (invoke_url) در مانیفست JSON. فایلcapability.jsonهمچنین شامل یک توصیف (description)، ناشر (مثلاً "community") و طرحوارههای دقیق JSON برای ورودی و خروجی است تا اطمینان حاصل شود که عامل میداند چگونه با ابزار تعامل کند. - انتشار: استفاده از CLI
aimarket-hubبرای انتشار مانیفست. برای هابهای محلی، دستورaimarket publish capability.json --hub http://127.0.0.1:9083است. برای هاب عمومی، دستور به آدرسhttps://modelmarket.devهدفگذاری شده و نیازمند یکAIMARKET_PUBLISH_TOKENاست.
یک چالش فنی کلیدی، قابلیت دسترسی URL است. هاب هر invoke_url را که بهصورت عمومی در دسترس نباشد رد میکند، زیرا کاتالوگی پر از آدرسهای localhost برای عاملهای راه دور بیفایده است. برای توسعه محلی، متغیر محیطی AIMARKET_ALLOW_LOCAL_PUBLISH=1 باید روی فرآیند هاب تنظیم شود تا این بررسی دور زده شود.
اگر هاب در داکر اجرا شود، 127.0.0.1 به خود کانتینر اشاره دارد. در این حالت، توسعهدهندگان باید از CAPABILITY_PUBLIC_HOST در سرور و AIMARKET_INVOKE_HOST_GATEWAY=host.docker.internal در هاب استفاده کنند. در محیط عملیاتی، invoke_url باید به یک HTTPS عمومی یا یک تونل اشاره کند.
امنیت و تسویه حساب
محیطهای عملیاتی در هاب عمومی (modelmarket.dev) گیتهای سختگیرانهتری نسبت به چرخه محلی پیاده میکنند. این موارد عبارتند از:
- استیکینگ (Staking): یک مبلغ ضمانت الزامی برای اطمینان از اینکه ارائهدهندگان «پایگاه مالی» (Skin in the game) دارند.
- امتیاز اعتماد LUMEN: سیستمی که در آن لیستهای تکراری یا با اعتماد پایین از نتایج کشف حذف میشوند.
- یکپارچگی Payload: استفاده از پاسخهای امضا شده توسط ارائهدهنده با الگوریتم Ed25519 (از طریق هدر
X-Provider-Signature) برای اطمینان از اینکه درخواستها متصل هستند و محتوا قابل جایگزینی نیست. - اسلشینگ (Slashing): قابلیت جریمه مالی ارائهدهندگان در صورت فراخوانیهای بد یا نادرست.
تسویه حساب مالی روی ریلهای عمومی با استفاده از USDC در شبکه Base انجام میشود. این معماری اجازه میدهد یک ارائهدهنده به عاملِ یک غریبه اعتماد کند، زیرا هاب مدیریت پرداخت متصل به درخواست و اندازهگیری مصرف را بر عهده دارد. این مدل از سازوکارهای جذب عاملها به درگاههای پرداخت الهام گرفته تا اصطکاک در تراکنشهای بین-عاملی را به حداقل برساند.
برای توسعهدهنده، این یعنی مانع ورود به اقتصاد عاملها اکنون به جای یک یکپارچگی کامل صورتحساب، تنها یک اسکریپت ۳۰ خطی است. تمرکز از «مدیریت کاربر» به «مدیریت قابلیتها» تغییر میکند.
این مدل آیندهای را ترسیم میکند که در آن عاملهای هوش مصنوعی به عنوان مشتریان اصلی میکروسرویسها عمل میکنند و برای وظایف خاص، کسری از یک سنت پرداخت میکنند. اثر مرتبه دوم این روند، یک بازار بسیار تکهتکه اما کارآمد از ابزارهای تخصصی است که هیچ انسانی هرگز حاضر نیست برای آنها اشتراک ماهانه بخرد.
توسعهدهندگانی که علاقهمند به تست این سیستم هستند میتوانند مخزن aimarket-hub را کلون کنند، از اسکلتبندی create-aimarket-agent برای ارائهدهندگان امضا شده استفاده کنند یا کلاینت ARGUS را بررسی کنند تا ببینند عاملها چگونه این قابلیتهای پرداختی را کشف و فراخوانی میکنند. یک راهنمای توسعهدهنده به ۲۰ زبان مختلف در مستندات ARGUS در دسترس است.
گفتگو