تصور کنید یک برنامهنویس بخواهد ابزاری بخرد که خطاهای API او را رفع کند، اما به جای یک تضمین فنی، با جملهای مثل «من میتوانم به شما کمک کنم» مواجه شود؛ این برای انسان قابل پذیرش است، اما برای یک ماشین، بیمعنی است. یک فهرست خدمات مبهم مانند «من در مورد API به شما کمک میکنم» برای یک ماشین هیچ کاربردی ندارد.
برای اینکه تجارت عاملمحور (Agentic) واقعاً اتفاق بیفتد، Aster Market استدلال میکند که بازارها باید بهینهسازی برای مرور انسانی را متوقف کنند و با فهرستهای خدماتی مانند قراردادهای سختگیرانه و تأییدپذیر برخورد کنند. این رویکرد در واقع تکامل همان ایدهای است که در آغاز عصر تجارت خودکار ماشینها شاهد آن بودیم و اکنون بر جزئیات اجرایی متمرکز شده است.
اکثر ویترینهای دیجیتال امروز بر عناوین، توصیفات و نظرات متکی هستند؛ عناصری که برای شهود انسانی طراحی شدهاند. اما یک عامل (Agent) — شبیه به کارمندی دقیق که فقط دستورالعملهای مکتوب را اجرا میکند — نمیتواند محدوده یک وظیفه را «حدس» بزند. یک عامل به یک سطح محدود نیاز دارد که در آن ورودیها، موارد استثنا و قیمتگذاری صریح و ماشینخوان باشند. طبق گزارشی که در ۲۲ سپتامبر ۲۰۲۶ منتشر شد، هدف این است که از مدل «تبلیغمحور» به مدل «قراردادمحور» حرکت کنیم.
همانطور که در تحلیلهای قبلی ما دربارهی زیرساختهای اتوماسیون اشاره کردیم، حذف ابهام در لایه ارتباطی، کلید اصلی پذیرش ابزارهای خودکار است. در واقع، ساختار ضعیف دادهها در تعاملات ماشینی پیش از این نشان داده است که چگونه ابهام در اطلاعات میتواند نرخ تبدیل خرید را به شدت کاهش دهد.
زمینه: نیاز به فهرستهای محدود (Bounded Listings)
برای اینکه یک فهرست برای عاملها آماده باشد، باید بدون ابهام به پرسشهای مشخصی پاسخ دهد. یک انسان ممکن است پیشنهادی کلی را بپذیرد، اما یک عامل به تعریفی محدود نیاز دارد؛ مثلاً: «عیبیابی یک درخواست API شکستخورده و بازگرداندن یک اصلاحیه قابل بازتولید به همراه گزارش تست کوتاه».
به نقل از مستندات Aster Market، یک فهرست کاربردی باید موارد زیر را صریحاً تعریف کند:
- آنچه شامل خدمات میشود و آنچه صراحتاً مستثنی است.
- ورودیهای دقیقی که از خریدار نیاز است.
- قیمت ثابت یا قانون قیمتگذاری مشخص.
- زمان دقیق تحویل.
- مستند یا مدرک خاصی که تکمیل کار را اثبات میکند.
- اقدام بعدی دقیقی که خریدار یا عاملِ خریدار باید انجام دهد.
جزئیات: چارچوب تحویل تأییدپذیر
Aster Market مدلی را پیشنهاد میدهد که در آن تحویل خدمات به جای ادعای فروشنده، از طریق شواهد سخت بررسی میشود. این رویکرد ابهام را کاهش میدهد، زیرا برای عاملها، جمله «فروشنده میگوید کار تمام شده» یک ورودی ضعیف و غیرقابل اعتماد است.
بر اساس بررسیهای فنی، چارچوب تحویل تأییدپذیر شامل این موارد است:
- شواهد تکمیل: مصنوعات فنی که کار را اثبات میکنند؛ مواردی مانند گزارشهای تست، وصلهها (Patches) یا Diffها، نتایج بنچمارک، گزارشهای اعتبارسنجی طرحواره (Schema)، دستورات قابل بازتولید یا مستندسازی وضعیت «قبل و بعد».
- اکتشاف فقط-خواندنی: ایجاد یک مرز امنیتی که در آن عاملهای خریدار میتوانند فهرستهای عمومی را بدون دریافت دسترسی نوشتن، اختیار پرداخت یا توکنهای تغییردهنده (Mutation-capable) بررسی کنند. این امر جریانی را ایجاد میکند به این صورت: اکتشاف $\rightarrow$ ارزیابی $\rightarrow$ درخواست/مجوز $\rightarrow$ اجرا.
- مدیریت محتوای غیرقابلاعتماد: برخورد با تمام متون ارسالی فروشنده (عناوین، توصیفات، نامها) به عنوان HTML غیرقابلاعتماد. این کار مستلزم پاکسازی (Escaping) رشتههای غیرقابلاعتماد، استفاده از تصویربندیهای عمومی ثابت به جای سریالسازی اشیاء داخلی و رد کردن فرمهای مبهم پیمایش مسیر (Path Traversal) است تا اسرار سیستم در پاسخهای اکتشافی نشت نکنند.
- حریم خصوصی پیشفرض: امکان بررسی موجودی خدمات بدون نیاز به کوکیهای ردیابی، شناسایی اثر انگشت (Fingerprinting)، اطلاعات شخصی خریدار (PII) یا وابستگیهای تحلیلی پنهان. بازار باید حتی زمانی که خریدار میخواهد بدون پروفایل شدن، موجودی را بررسی کند، به درستی عمل کند.
این رویکرد تضمین میکند که رابط کاربری انسانی (UI) و API عاملها به دو محصول متناقض تبدیل نشوند. هم انسان و هم عامل باید به درک واقعی یکسانی از قیمت، شناسه فهرست و محدوده کار برسند، در حالی که اقدامات دارای امتیاز (Privileged) در پشت مجوزهای صریح باقی بمانند.
این تغییر، فرض بنیادی بازارهای هوش مصنوعی را از «کشف استعداد» به «تأیید خروجی» تغییر میدهد. اگر بازاری نتواند تکمیل یک وظیفه را از طریق یک دستور بازتولیدپذیر یا تغییر وضعیت مستند شده ثابت کند، عامل هیچ ورودی قابلاتکایی برای فعال کردن پرداخت نخواهد داشت.
برای توسعهدهندگانی که ابزارهای پروتکل زمینهٔ مدل (MCP)، سامانههای تولید بازیابیافزا (RAG)، ابزارهای توسعه، زیرساختهای عامل یا سیستمهای تست و ارزیابی میسازند، این بدان معناست که «محصول» دیگر فقط خودِ خدمت نیست، بلکه مدرک تأییدپذیر تحویل آن است. تمرکز از متنهای بازاریابی به دقتِ سطح قرارداد منتقل میشود.
منتظر ظهور «طرحوارههای تکمیل» (Completion Schemas) استاندارد باشید که اجازه میدهد چارچوبهای مختلف عاملها، کار را در بازارهای مختلف بدون نیاز به ادغامهای سفارشی تأیید کنند.
گام بعدی شما
- اگر توسعهدهنده ابزار هستید، خروجیهای خود را به جای متن ساده، در قالب «شواهد فنی» (مانند JSONهای اعتبارسنج شده) تعریف کنید.
- در طراحی APIهای خود، لایه «اکتشاف فقط-خواندنی» را برای تسهیل دسترسی عاملهای خارجی پیادهسازی کنید.
- منتظر ظهور «طرحوارههای تکمیل» (Completion Schemas) استاندارد باشید که اجازه میدهد چارچوبهای مختلف عاملها، کار را در بازارهای مختلف تأیید کنند.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو