چرا سایت‌ها عامل‌های خرید هوش مصنوعی را مسدود می‌کنند؟

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

در این نوشته توضیح می‌دهیم عامل خرید هوش مصنوعی چیست، چرا سایت‌ها این عامل‌ها را مسدود می‌کنند و هسته مسئله چیست: چرا تشخیص انسان، ربات مخرب و عاملی که با مجوز کاربر عمل می‌کند برای سایت دشوار است. سپس راه‌حل‌هایی را که برای این مسئله پدید می‌آیند بررسی می‌کنیم (عامل‌های امضاشده، Web Bot Auth و پروتکل‌های تازه در سمت پرداخت) و مسیر درست برای فروشندگان و توسعه‌دهندگان عامل را. این نوشته توضیح نمی‌دهد عامل‌ها چگونه از محافظت ربات بگذرند؛ بر پایه معرفی درست ترافیک عامل ساخته شده است.

عامل خرید هوش مصنوعی چیست؟#

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

کار عامل خرید در سه سطح قرار می‌گیرد:

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

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

چرا سایت‌ها عامل‌ها را مسدود می‌کنند؟#

وقتی فروشگاهی اینترنتی ترافیک عامل را متوقف می‌کند، معمولاً نه به دلیل موضعی ویژه در برابر عامل‌ها بلکه به این دلیل است که دفاع‌هایی که سال‌هاست وجود دارند عامل‌ها را هم می‌گیرند.

محافظت ربات. فروشگاه‌های اینترنتی در برابر اسکرپینگ قیمت، احتکار موجودی (افزودن محصولات محدود به سبد تا دیگران نتوانند بخرند)، تصاحب حساب و حمله‌های آزمون کارت از سامانه‌های مدیریت ربات استفاده می‌کنند. این سامانه‌ها درخواست‌ها را با نشانه‌هایی مانند سرعت، شهرت IP، اثر انگشت مرورگر و رفتار امتیاز می‌دهند. عامل خرید اغلب از دیتاسنتر، با مرورگر headless و بسیار سریع‌تر از انسان صفحه باز می‌کند؛ یعنی تقریباً همه نشانه‌هایی را که سامانه‌های محافظت ربات به دنبالشان‌اند دارد. برای نمونه‌ای از شیوه سنجش این نشانه‌ها، Cloudflare Precursor را ببینید.

خطر تقلب پرداخت. سامانه‌های پرداخت با نشانه‌های گوناگون تأیید می‌کنند که کارت را دارنده‌اش به کار می‌برد: دستگاه، موقعیت، عادت‌ها و گام‌های تأیید اضافه مانند ⁦3-D Secure⁩. وقتی عامل می‌کوشد با اطلاعات کارت پرداخت کند، بیشتر این نشانه‌ها با نمایه عادی دارنده کارت نمی‌خوانند. از دید سامانه پرداخت، تصویر شبیه خرید خودکار با کارت دزدی است.

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

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

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

چرا تشخیص انسان، ربات و عامل مجاز دشوار است؟#

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

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

این شکاف با هدر User-Agent پر نمی‌شود، چون این هدر متن ساده است و هر کسی می‌تواند هر مقداری در آن بنویسد. برای اینکه سایت باور کند درخواستی که می‌گوید «⁦KnownShoppingAgent/1.0⁩» واقعاً از عامل همان شرکت آمده، به مدرک تأییدپذیر نیاز دارد. فهرست آدرس‌های IP تا حدی کمک می‌کند، اما آدرس‌ها در زیرساخت ابری مشترک‌اند و تغییر می‌کنند.

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

عامل‌های امضاشده و Web Bot Auth#

روش اصلی که در این جهت پدید می‌آید امضای رمزنگاری‌شده هر درخواست HTTP از سوی عامل است. زیر آن استاندارد HTTP Message Signatures (⁦RFC 9421⁩) از IETF قرار دارد. این استاندارد امضای بخش‌های برگزیده یک پیام HTTP (متد، آدرس، برخی هدرها) با کلید خصوصی و تأیید امضا با کلید عمومی از سوی گیرنده را تعریف می‌کند.

Web Bot Auth نام روشی است که این استاندارد را برای احراز هویت ربات‌ها و عامل‌ها به کار می‌برد. بر اساس مستندات Web Bot Auth از Cloudflare این‌گونه کار می‌کند:

1. گرداننده عامل یک جفت کلید می‌سازد و کلید عمومی را به‌صورت فهرست کلید در دامنه خودش، در /.well-known/http-message-signatures-directory منتشر می‌کند.
2. عامل به هر درخواست سه هدر می‌افزاید: Signature-Input (بخش‌هایی که امضا پوشش می‌دهد، شناسه کلید، زمان ساخت و انقضا و یک nonce)، Signature (خود امضا) و Signature-Agent (آدرس فهرست کلید).
3. سایت یا CDN جلوی آن امضا را تأیید می‌کند: فهرست کلید را می‌خواند، امضا را با کلید عمومی بررسی می‌کند و مطمئن می‌شود امضا منقضی نشده است.
4. درخواست تأییدشده به عاملی شناخته‌شده نسبت داده می‌شود. بر این پایه سایت می‌تواند به درخواست اجازه دهد، سرعتش را محدود کند یا دسترسی‌اش را به برخی مسیرها محدود کند.

ویژگی مهم این روش این است که تأیید به آدرس IP وابسته نیست: عامل از هر سروری اجرا شود، امضا به همان گرداننده اشاره می‌کند. خود فهرست کلید هم امضا شده است و این جعل هویت گرداننده با فهرستی ساختگی را دشوارتر می‌کند.

از 1 ژوئیه 2026، Cloudflare عامل‌هایی را که خود را این‌گونه رمزنگارانه معرفی می‌کنند در دسته‌بندی ربات‌های تأییدشده مدیریت می‌کند. در عمل یعنی صاحبان سایت می‌توانند در قواعد محافظت ربات خود مسیر جداگانه‌ای برای عامل‌های تأییدشده باز کنند.

پروتکل‌های تازه در سمت پرداخت#

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

• Visa Trusted Agent Protocol: بر اساس اعلام Visa، پروتکلی که Visa در اکتبر 2025 اعلام کرد بر استاندارد HTTP Message Signatures ساخته شده، با Web Bot Auth هم‌راستاست و همراه Cloudflare توسعه یافته است. هدفش این است که فروشندگان بتوانند عامل‌های شناخته‌شده از سوی Visa را که با نیت خرید عمل می‌کنند از خودکارسازی مخرب جدا کنند.
• Agentic Commerce Protocol (ACP): مشخصات بازی که OpenAI و Stripe نگه‌داری می‌کنند. بر اساس صفحه پروژه، جریان خرید میان خریدار، عامل، فروشنده و ارائه‌دهنده پرداخت را استاندارد می‌کند؛ عامل رابط پرداخت را به کاربر نشان می‌دهد و فروشنده زیرساخت و پردازش پرداخت خودش را حفظ می‌کند.
• Agent Payments Protocol (AP2): پروتکلی که Google همراه شرکایش اعلام کرد می‌خواهد اختیار پرداخت عامل از سوی کاربر را با سندهای مجوز امضاشده رمزنگارانه منتقل کند. بدین ترتیب فروشنده و شرکت پرداخت می‌توانند تأیید کنند که تراکنش در محدوده‌ای است که کاربر تأیید کرده است.

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

چه کسی چه چیزی را حل می‌کند؟#

فروشندگان چه می‌توانند بکنند؟#

مسدود کردن کامل یا باز گذاشتن کامل ترافیک عامل ممکن است برای فروشنده درست نباشد. روش گام‌به‌گام سالم‌تر است:

1. ترافیک را بسنجید. ببینید چه بخشی از ترافیک خودکاری که به سایتتان می‌رسد موتور جست‌وجو، خزنده‌های شناخته‌شده هوش مصنوعی و خودکارسازی با هویت نامعلوم است.
2. سیاست خود را بنویسید. تصمیم بگیرید کدام عامل‌ها به کدام صفحه‌ها (کاتالوگ، سبد، پرداخت) برسند. باز نگه داشتن صفحه‌های کاتالوگ و گره زدن پرداخت به پروتکل‌های تأییدشده نقطه آغاز رایجی است.
3. robots.txt و شرایط خود را به‌روز کنید. ترجیحات خود درباره عامل‌ها را هم به شکل ماشین‌خوان و هم روشن در شرایط استفاده بیان کنید. شیوه نوشتن فایل را در فایل robots.txt چیست و چگونه آن را بخوانیم؟ توضیح داده‌ایم.
4. عامل‌های امضاشده را بشناسید. تنظیماتی را که سرویس مدیریت ربات برای عامل‌های تأییدشده ارائه می‌دهد به کار ببرید؛ ترافیک عامل با هویت تأییدشده را جدا از ترافیک با هویت نامعلوم ارزیابی کنید.
5. داده ساخت‌یافته ارائه دهید. داده Schema.org در صفحه‌های محصول و در صورت داشتن، فیدهای رسمی محصول به عامل‌ها اجازه می‌دهند بدون اسکرپ کردن صفحه به اطلاعات درست برسند.
6. پروتکل‌های عامل شرکای پرداخت خود را دنبال کنید. اگر ارائه‌دهنده پرداخت شما از این پروتکل‌ها پشتیبانی کند، مدیریت تراکنش‌های برآمده از عامل در جریانی جدا از قواعد تقلب ممکن می‌شود.

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

مسیر درست برای توسعه‌دهندگان عامل#

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

مسیر درست از این گام‌ها می‌گذرد:

• عامل خود را معرفی کنید. User-Agent دارای توکن محصول تعریف‌شده و آدرس تماس به کار ببرید؛ در صورت امکان درخواست‌هایتان را با Web Bot Auth امضا کنید.
• یکپارچه‌سازی‌های رسمی را در اولویت بگذارید. اگر فروشنده API، فید محصول یا پروتکل خرید پشتیبانی‌شده دارد، به‌جای اسکرپ کردن صفحه‌ها آن‌ها را به کار ببرید.
• از robots.txt و شرایط پیروی کنید. مسیرهایی را که سایت به روی عامل‌ها بسته، حتی از سوی کاربر، به زور باز نکنید.
• تأیید کاربر را بخشی از فرایند کنید. پیش از گام‌های برگشت‌ناپذیری مانند پرداخت از کاربر تأیید صریح بگیرید؛ بگذارید سقف هزینه را کاربر تعیین کند نه عامل.
• سرعت را محدود کنید. برای خرید یک کاربر لازم نیست در چند ثانیه ده‌ها صفحه باز کنید.
• شکست را بپذیرید. اگر سایتی عامل شما را مسدود کرد، روشن به کاربر بگویید و جایگزین پیشنهاد دهید؛ برای دور زدن مسدودسازی تلاش نکنید.

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

اشتباهات رایج#

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

راهنمای انتخاب#

پرسش‌های متداول#

چرا عامل‌های خرید هوش مصنوعی به صفحه بررسی برمی‌خورند؟#

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

Web Bot Auth چیست؟#

روشی است که به ربات‌ها و عامل‌ها اجازه می‌دهد با امضای رمزنگاری‌شده درخواست‌های HTTP هویت خود را ثابت کنند. استاندارد ⁦RFC 9421⁩ یعنی HTTP Message Signatures را به کار می‌برد. عامل کلید عمومی‌اش را در دامنه خودش منتشر می‌کند و سایت یا CDN امضای هر درخواست را با آن کلید تأیید می‌کند.

آیا عامل امضاشده در هر سایتی کار می‌کند؟#

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

آیا عامل من با پروکسی از مسدودسازی می‌گذرد؟#

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

آیا فروشندگان باید ترافیک عامل را کامل مسدود کنند؟#

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

آیا این پروتکل‌ها در ترکیه به کار می‌روند؟#

بیشتر این پروتکل‌ها تازه‌اند و دامنه و پشتیبانی منطقه‌ای‌شان سریع تغییر می‌کند. برای فروشنده یا توسعه‌دهنده در ترکیه، مطمئن‌ترین راه پرسیدن مستقیم از ارائه‌دهنده پرداخت و CDN خودتان است که از کدام پروتکل‌های تأیید عامل و پرداخت پشتیبانی می‌کنند.

خلاصه#

عامل‌های خرید هوش مصنوعی در سایت‌ها مسدود می‌شوند چون سامانه‌های محافظت ربات نمی‌توانند عاملی را که برای کاربر کار می‌کند از خودکارسازی مخرب جدا کنند و سامانه‌های پرداخت نمی‌توانند تأیید کنند عامل با اختیار دارنده کارت عمل می‌کند. راه‌حل پنهان کردن عامل نیست بلکه معرفی تأییدپذیر آن است: درخواست‌های امضاشده با Web Bot Auth بر پایه ⁦RFC 9421⁩، چارچوب‌های عامل شناخته‌شده مانند Visa Trusted Agent Protocol و پروتکل‌های خرید و مجوز پرداخت مانند ACP و AP2 در این جهت پیش می‌روند. فروشندگان باید ترافیک عامل را بسنجند و سیاست تعیین کنند و توسعه‌دهندگان عامل باید بر یکپارچه‌سازی‌های رسمی و تأیید کاربر تکیه کنند. برای تأیید نمایش قیمت و محتوا از موقعیت‌های گوناگون در چارچوب قواعد، نگاهی به صفحه راه‌حل پایش قیمت بیندازید.