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

نویسنده: Cobo

سریع به سال ۲۰۲۸ می‌رویم؛ شما به عامل هوش مصنوعی شخصی‌تان اجازه می‌دهید مواد لازم برای سوپ را بخرد. این عامل با دقت متوجه می‌شود که هویج‌های سوپرمارکت محلی ۱۰ سنت گران‌تر از میانگین قیمت هستند. برای رسیدن به راهکاری بهینه در مقیاس جهانی، به‌طور خودکار کل زنجیره تأمین کشاورزی آمریکای شمالی را هماهنگ می‌کند و نزدیک است اختلافی تجاری میان چند کشور به راه بیندازد. در نهایت، مواد را به‌موقع به آشپزخانه شما می‌رساند و در مجموع ۲۳ سنت برایتان صرفه‌جویی می‌کند.

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

نمونه واقعی این حکایت اخیراً در ایالات متحده رخ داد.

JC Bahr-de Stefano، سرمایه‌گذار شرکت سرمایه‌گذاری خطرپذیر Better Tomorrow Ventures، به عامل هوش مصنوعی شخصی خود، Instinct، اجازه داد رزروهای رستوران استیک «4 Charles Prime Rib» در نیویورک را زیر نظر بگیرد؛ رستورانی که رزرو کردنش به‌شدت دشوار است. از نگاه JC، قرار بود Instinct مانند یک دستیار انسانی کارآمد عمل کند و هر از گاهی پلتفرم رزرو Resy را تازه‌سازی کند تا از لغوهای احتمالی باخبر شود.

اما تنها چند ساعت بعد، JC از Resy اعلان ممنوعیت دائمی دریافت کرد و همه رزروهای آینده به نام او لغو شدند. JC بعداً تصویری از ایمیل ممنوعیت را با شرحی کنایه‌آمیز در Twitter منتشر کرد: "آفرین، Instinct."

برای فهمیدن دلیل ممنوعیت، JC گزارش‌های عملکرد Instinct را بررسی کرد. تازه آن‌وقت حقیقت روشن شد: تلاش‌های دستیار دیجیتال فراتر از تصور انسان بود. این دستیار نه‌تنها شبانه‌روز و با شدت زیاد، حدود ۲۰۰ بار در ساعت، وضعیت را بررسی می‌کرد، بلکه موجودی رزروهای ۲۱ روز آینده را هم هر ۱۰ دقیقه به‌طور کامل اسکن می‌کرد. در زمان اوج عرضه، ساعت ۹ صبح، حتی فاصله میان درخواست‌ها را به ۰٫۴ ثانیه کاهش داد و به‌مدت دو دقیقه و نیم پی‌درپی به سامانه درخواست فرستاد.

از دید سامانه مقابله با تقلب و مدیریت ریسک Resy، این رفتار نه از سوی مشتری‌ای مستأصل، بلکه شبیه حمله DDoS در مقیاس کوچک یا اسکریپت مهارنشده یک دلال برای خرید بلیت بود. خود JC هم پذیرفت که این ممنوعیت کاملاً منطقی بوده است.

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

از «با من حرف بزن» تا «به‌جای من اقدام کن»

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

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

اما محصولاتی مانند Instinct که Noah Shinn توسعه داده و Meta Muse که طی پنج روز پس از عرضه ۷۳۰٬۰۰۰ بار دانلود شد، شکل دیگری از محصول را نشان می‌دهند که مستقیماً اجرای کارها را به‌عهده می‌گیرد.

کاربران می‌توانند درست مانند پیام دادن به یک دستیار واقعی، وظایفی را به آن‌ها بسپارند: "اشتراک‌های غیرضروری را لغو کن،" "پروازهای لندن را زیر نظر بگیر و اگر قیمت مناسب بود، بلیت بخر،" "کمکم کن در 4 Charles میز رزرو کنم."

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

Muse متعلق به Meta این قابلیت را به پلتفرم‌های جریان اصلی می‌آورد. این محصول فقط در پنج روز به ۷۳۰٬۰۰۰ بار دانلود رسید. Muse به‌طور عمیق در Instagram و WhatsApp ادغام شده است: غذاها را در Reels تشخیص می‌دهد و فهرست خرید می‌سازد، برنامه‌های مهمانی را از چت‌های گروهی می‌خواند، منوها را خودکار مدیریت می‌کند، دعوت‌نامه می‌فرستد و هزینه‌ها را تقسیم می‌کند.

هم‌زمان، Meta قابلیت Muse Connectors را در دسترس قرار داده است تا توسعه‌دهندگان ثالث بتوانند Gmail، Calendar، Notion، Spotify و رابط‌های تجارت الکترونیکی را در قالب ابزارهای استاندارد عامل‌ها بسته‌بندی کنند. با اجازه کاربر، Muse می‌تواند بر اساس دستوری مبهم به زبان طبیعی، کارها را میان سرویس‌ها هماهنگ کند: چت‌های گروهی را بخواند و شام را برنامه‌ریزی کند، زمان‌های خالی را با Calendar تطبیق دهد و خرید را از طریق پلتفرم‌های رزرو انجام دهد. Muse Connector اساساً با استفاده از پروتکل‌های ساختاریافته، دامنه اقداماتی را که عامل‌ها می‌توانند به آن‌ها دسترسی داشته باشند و انجام دهند، پیوسته گسترش می‌دهد.

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

وقتی مدل‌های مدیریت ریسک پلتفرم با عامل‌های هوش مصنوعی روبه‌رو می‌شوند

اگر به تجربه JC برگردیم، سامانه مدیریت ریسک Resy اشتباه قضاوت نکرد؛ بلکه صرفاً منطق استانداردی را اجرا کرد که اینترنت طی بیست سال گذشته شکل داده است: از CAPTCHA و اثرانگشت دستگاه گرفته تا محدودیت نرخ درخواست بر اساس IP، همه سامانه‌های امنیتی مدت‌ها بر این فرض دوگانه تکیه داشته‌اند که پشت پایانه یا یک انسان واقعی قرار دارد یا رباتی با اسکریپت‌های مخرب.

عامل‌های شخصی این توازن را کاملاً برهم می‌زنند.

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

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

اگر ممنوعیت عامل رزرو از سوی Resy صرفاً دفاع معمول یک پلتفرم در برابر ترافیک غیرعادی بود، ممنوعیت فراگیر اخیر Amazon علیه Meta Muse این اصطکاک فنی را به رقابتی زیست‌بومی میان پلتفرم‌ها تبدیل می‌کند.

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

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

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

OAuth در تعریف دسترسی برنامه‌ها توانمند است و Rate Limit برای محدود کردن تعداد درخواست‌ها مناسب است، اما هیچ‌یک نمی‌تواند به سه پرسش عمیق‌تر درباره زمینه پاسخ دهد: این عامل نماینده چه کسی است؟ آیا با وفاداری خواسته فعلی کاربر را اجرا می‌کند؟ آیا پلتفرم حاضر است این رفتار نیابتی را بپذیرد؟

حتی اگر مشکلات احراز هویت در آینده حل شوند، تناقض‌ها همچنان باقی خواهند ماند. Resy می‌تواند تأیید کند که «این عاملِ مجاز JC است» و Amazon می‌تواند تشخیص دهد که «این Muse است که کاربر به آن مجوز داده»، اما پلتفرم همچنان باید انتخاب کند: آیا اجازه می‌دهد شمار نامحدودی از عامل‌های خستگی‌ناپذیر با واکنش‌های میلی‌ثانیه‌ای، منطق فراخوانی منابع را کاملاً از نو بسازند—به‌ویژه وقتی این منابع از قبل بسیار کمیاب‌اند؟

وقتی الگوی «اولویت با کسی است که زودتر برسد» از کار می‌افتد

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

دلیل حفظ تعادل در این سازوکار «اولویت با کسی است که زودتر برسد»، تکیه آن بر یک آستانه ضمنی از زمان و تلاش است: توجه و توان جسمی انسان محدود است.

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

اما وقتی همه به یک عامل هوشمند مجهز باشند، این حائل فیزیکی از میان خواهد رفت.

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

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

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

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

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