گزارش بازار: ۲ رویکرد متضاد در پذیرش عامل‌های هوش مصنوعی

تصور کنید دستیاری دیجیتال دارید که نه تنها بهترین قیمت را پیدا می‌کند، بلکه خرید را هم نهایی می‌کند؛ اما حالا آمازون تصمیم گرفته این دستیار را از درگاه خود بیرون بیندازد. در ۲۱ سپتامبر ۲۰۲۶، آمازون (Amazon) دسترسی عامل (Agent) — شبیه به یک کارمند مجازی که می‌تواند به‌جای شما تصمیم بگیرد و عمل کند — Muse متعلق به شرکت متا (Meta) را مسدود کرد. این اقدام سیگنالی از یک سیاست سیستماتیک است تا هر عامل شخص ثالثی که مجوز صریح ندارد، از ورود به فروشگاه آمازون منع شود.

آمازون به‌وضوح اعلام کرده است که هیچ عامل هوش مصنوعی شخص ثالثی اجازه نخواهد داشت بدون مجوز صریح در Amazon.com خرید کند. همچنین این شرکت قصد دارد این مسدودسازی‌ها را به عامل‌های آینده‌ای که توسط گوگل و OpenAI عرضه می‌شوند نیز گسترش دهد.

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

محاصره‌ی آمازون

به گزارش GeekWire، تصمیم آمازون برای مسدود کردن Muse تصادفی یا بر اساس یک تصمیم لحظه‌ای نبود. این شرکت سه تخلف فنی مشخص را ذکر کرد که رفتار Muse را بیشتر به یک تهدید امنیتی شبیه می‌کرد تا یک ابزار کاربردی:

• فقدان شناسایی: Muse بدون هدر User-Agent یا کلید API وارد سایت شد و در واقع خود را جای کاربر انسانی داد. شرایط خدمات آمازون صراحتاً ایجاب می‌کند که عامل‌ها باید یک قطعه متن (snippet) در درخواست‌های HTTP قرار دهند تا خود را به عنوان ابزارهای خودکار معرفی کنند.
• ریسک‌های اعتبارنامه‌ای: Muse با استفاده از اطلاعات خام مشتریان (Credentials) که در یک «ماشین مجازی ایزوله» (sandboxed VM) ذخیره شده بود، وارد حساب‌ها می‌شد. آمازون این کار را نفوذ یک «شخص ثالث افشا نشده» می‌بیند که از طریق حساب‌های مشتریان حرکت می‌کند؛ وضعیتی که ریسک دسترسی عامل به تاریخچه خرید، آدرس‌های ذخیره شده و روش‌های پرداخت را ایجاد می‌کند.
• عدم مذاکره: متا این قابلیت‌ها را بدون هیچ‌گونه تماس یا هماهنگی با آمازون فعال کرد. زمانی که آمازون از متا خواست تا آمازون را از قابلیت‌های خرید Muse خارج کند، متا این درخواست را رد کرد.

کاربرانی که اکنون سعی می‌کنند از Muse در آمازون استفاده کنند، با یک پیام هشدار مواجه می‌شوند که می‌گوید: «دسترسی مداوم توسط یک عامل هوش مصنوعی غیرمجاز، شرایط استفاده از آمازون را نقض می‌کند». این بخشی از یک الگوی گسترده‌تر برای منع دسترسی است؛ آمازون پیش‌تر در مارس ۲۰۲۶ عامل Comet متعلق به Perplexity را از طریق حکم دادگاه و در فصل تعطیلات ۲۰۲۵ قابلیت‌های خرید ChatGPT متعلق به OpenAI را مسدود کرده بود.

انگیزه مالی: محافظت از قلعه‌ی تبلیغات

اگرچه آمازون این موضوع را به عنوان یک مسئله امنیتی جلوه می‌دهد، اما انگیزه‌های مالی بسیار شفاف‌تر و ملموس‌تر هستند. درآمد تبلیغاتی آمازون سال گذشته به ۶۸ میلیارد دلار رسید که تقریباً ۱۰٪ از کل درآمد این شرکت را تشکیل می‌دهد. این درآمد توسط یک تجربه کاربری خاص هدایت می‌شود: پنهان کردن قابلیت مرتب‌سازی بر اساس «قیمت در هر واحد» و مجبور کردن کاربران به دیدن نتایج اسپانسرشده (Sponsored).

بر اساس یک بحث گسترده با ۱۵۲ امتیاز در Hacker News، عامل‌های هوش مصنوعی اساساً این مدل درآمدی را تهدید می‌کنند. یک عامل برچسب «اسپانسرشده» را نمی‌بیند و دچار «کلیک‌های تکانشی» (impulse-click) نمی‌شود. در عوض، این عامل‌ها صرفاً بر اساس قیمت، نظرات و مشخصات فنی بهینه‌سازی می‌کنند؛ یعنی دقیقاً همان داده‌هایی که آمازون پول می‌گیرد تا آن‌ها را در اولویت‌های پایین قرار دهد. از دیدگاه پلتفرم، یک عامل مشتری نیست، بلکه فیلتری است که سودآورترین بخش تجربه خرید را حذف می‌کند.

جایگزین Shopify

Shopify شرطی کاملاً متضاد بسته است و Muse را با Shop Pay ادغام کرد. به‌جای اینکه اجازه دهد عامل جای کاربر را بگیرد و در وب‌سایتی که برای انسان طراحی شده بچرخد، از معماری «پرداخت توکن‌محور» استفاده می‌کند. در این سیستم، یک توکن پرداخت محدود (scoped payment token) صادر می‌شود که ویژگی‌های زیر را دارد:

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

توبیاس لوتکه، مدیرعامل Shopify، این رویکرد را به عنوان تبدیل عامل هوش مصنوعی به یک «سطح پرداخت» (checkout surface) دیگر توصیف می‌کند؛ مشابه دکمه «خرید» در اینستاگرام یا یک لینک در ایمیل. این استراتژی تجاری توسط اعداد سخت پشتیبانی می‌شود: Shop Pay بیش از ۴۰۰ میلیارد دلار حجم معاملات ناخالص شتاب‌یافته را در طول عمر خود پردازش کرده است. علاوه بر این، جف هوفمایستر، مدیر مالی Shopify، گزارش داد که جست‌وجوی مبتنی بر هوش مصنوعی، احتمال رسیدن مستقیم به صفحات محصول را ۲.۵ برابر افزایش داده و نرخ تبدیل (conversion) را تقریباً ۸۰٪ بهبود بخشیده است. برای فروشندگان Shopify، ترافیک هدایت شده توسط عامل‌ها به‌مراتب کارآمدتر از گشت‌وگذار انسانی است.

جنگ پروتکل‌ها: ۶ استاندارد، صفر اجماع

این شکاف بین دو غول فناوری، نشانه‌ای از یک مشکل بزرگتر است: هیچ استاندارد جهانی برای اینکه یک عامل هوش مصنوعی چگونه ثابت کند اجازه دارد به‌نام یک انسان عمل کند، وجود ندارد. تا سپتامبر ۲۰۲۶، شش پروتکل رقیب این پشته‌ی کاری را تعریف می‌کنند:

• ACP (Agent Commerce Protocol): مورد حمایت OpenAI و Stripe؛ مدیریت کشف محصول و سازماندهی جریان پرداخت.
• UCP (Universal Commerce Protocol): مورد حمایت گوگل؛ تمرکز بر کشف محصول و مقایسه در پلتفرم‌های مختلف.
• AP2 (Agent Payments Protocol): تلاش مشترک گوگل و شبکه‌های پرداخت؛ تمرکز بر الزامات رمزنگاری و رسیدهای دیجیتال امضاشده از قصد کاربر.
• MCP (Model Context Protocol): توسعه‌یافته توسط Anthropic؛ مدیریت کشف ابزارها و فراخوانی آن‌ها برای عامل‌ها. این پروتکل در راستای رقابت شدید میان Anthropic و OpenAI برای تصاحب لایه‌ی اجرای مهارت‌ها و ابزارها طراحی شده است.
• A2A (Agent-to-Agent): مورد حمایت گوگل؛ مدیریت ارتباطات بین‌عاملی و تفویض اختیار.
• TAP (Trusted Agent Protocol): مورد حمایت Visa؛ تمرکز بر تأیید هویت عامل و مجوز پرداخت.

حل مسئله‌ی تأیید هویت

دو چارچوب جدید سعی دارند آنچه Auth0 «مسئله تأیید هویت عامل» می‌نامد را حل کنند؛ یعنی فرآیند اثبات اینکه یک عامل ثبت شده است، توسط انسان مجاز شده و در چارچوب یک دستور محدود عمل می‌کند.

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

در مقابل، AP2 گوگل «ماندات‌های رمزنگاری‌شده» (cryptographic mandates) را معرفی می‌کند. دستگاه کاربر یک توکن «قصد» (intent token) امضا شده تولید می‌کند که عامل هنگام پرداخت آن را ارائه می‌دهد. این امر از نظر ریاضی ثابت می‌کند که انسان آن خرید خاص را تأیید کرده است؛ به این معنی که فروشنده نیازی به اعتماد به خودِ عامل ندارد، بلکه تنها به اثبات رمزنگاری اعتماد می‌کند.

دیدگاه جامعه: امنیت یا انحصار؟

جامعه فناوری به‌شدت دوقطبی شده است، همان‌طور که در یک رشته‌بحث با ۹۸۹ امتیاز در r/technology و یک بحث با ۱۶۱ نظر در HN دیده می‌شود. گروه «حق با آمازون است» استدلال می‌کند که «ماشین مجازی ایزوله» متا ناکافی است. چون عامل با استفاده از کوکی‌های کاربر می‌چرخد و هر آنچه کاربر می‌بیند را می‌بیند، هرگونه نفوذ به عامل، دسترسی کامل مهاجم به حساب کاربر را فراهم می‌کند. این ترس در یک رشته‌بحث با ۳,۴۰۱ امتیاز در r/technology که شکست‌های اولیه عامل‌ها را مستند کرده، بازتاب یافته است.

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

زاویه دید مخالف: حمله مرد میانی

یک استدلال قوی وجود دارد که آمازون درست می‌گوید، اما به دلایل درست. عاملی که ناشناس می‌چرخد و اعتبارنامه‌های کاربر را بدون مکانیزم تأیید محدوده (scope) ذخیره می‌کند، یک «عامل» نیست، بلکه یک حمله «مرد میانی» (Man-in-the-Middle) است که توسط یک تیم محصول مدیریت می‌شود. امتناع متا از مذاکره یا توقف فعالیت پس از درخواست آمازون، نشان‌دهنده عدم جدیت در مورد مجوزدهی است. برای اینکه به عامل‌ها اعتماد شود، آن‌ها باید ابتدا قابل اعتماد رفتار کنند.

گام بعدی برای سازندگان

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

• پیاده‌سازی شناسایی صحیح: درخواست‌های HTTP عامل شما باید شامل یک رشته User-Agent شناسنامه‌دار باشد. عامل خود را به عنوان یک ابزار خودکار معرفی کنید تا به عنوان بدافزار علامت‌گذاری نشوید.
• طراحی برای مجوز توکن‌محور: از اعتبارنامه‌های خام فاصله بگیرید. مدل‌های Shopify و Stripe را مطالعه کنید که از جریان‌های مبتنی بر ماندات و قصد تراکنش‌های امضا شده رمزنگاری‌شده استفاده می‌کنند.
• برنامه‌ریزی برای مسدود شدن: انتظار داشته باشید هر پلتفرمی که با تبلیغات درآمدزنی می‌کند، عامل‌هایی را که محتوای اسپانسرشده را دور می‌زنند، مسدود کند. جریان‌های جایگزین (fallback) بسازید که به‌جای شکست خاموش، کاربر را به‌طور محترمانه به یک لینک مستقیم هدایت کنند.
• اولویت‌بندی پروتکل‌های پرداخت: با وجود شش پروتکل، ادغام آن‌ها اجتناب‌ناپذیر است. توسعه خود را به سمت پروتکل‌هایی ببرید که توسط شبکه‌های پرداخت (مانند Visa TAP و AP2) حمایت می‌شوند، زیرا آن‌ها روابط تجاری لازم برای گسترش پذیرش را دارند.
• طراحی برای دو مشتری: وب‌سایتی که با عامل تعامل دارد را به عنوان یک سطح درجه اول در نظر بگیرید. عامل‌ها به API نیاز دارند، نه استخراج داده از صفحه (screen-scraping).

جنگ دسترسی در واقع جنگ هویت است

شکاف آمازون در مقابل Shopify، فاز بعدی تجارت الکترونیک را تعریف می‌کند. وقتی یک انسان روی «اکنون بخر» کلیک می‌کند، پلتفرم یک نشست (session) فعال دارد و از طریق Chargeback راهکاری برای بازگشت وجه دارد. وقتی یک عامل کلیک می‌کند، این تضمین‌ها از بین می‌روند، مگر اینکه زیرساخت اعتماد برای ارائه آن‌ها ساخته شده باشد.

شرکت‌های Experian، Visa، Stripe، گوگل و OpenAI در رقابت برای تصاحب این لایه اعتماد هستند. پاسخ آمازون یک بازی محافظه‌کارانه است: مسدود کردن تا زمانی که زیرساخت‌ها به سطح لازم برسند. پاسخ Shopify یک بازی تهاجمی است: ساخت زیرساخت در دل Shop Pay و باز کردن درها. جنگ بر سر این نیست که آیا عامل‌ها برای ما خرید خواهند کرد یا خیر — آن‌ها همین حالا هم این کار را می‌کنند. جنگ بر سر این است که چه کسی کلیدهای پرداخت را در دست دارد: پلتفرم، عامل، یا کاربر.