قانون «سکوت یعنی رد»؛ راهکار جلوگیری از توقف عامل‌های هوش مصنوعی

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

بسیاری از توسعه‌دهندگان به درگاه‌های تأیید (Approval Gates) — شبیه به یک نگهبان که اجازه ورود به ساختمان را می‌دهد یا نمی‌دهد — تنها به چشم یک بررسی ساده برای کسب اجازه نگاه می‌کنند. اما طبق گزارش نویسنده این تجربه، در محیط‌های عملیاتی واقعی که با پرداخت‌ها، حذف داده‌ها یا معاملات زنده سروکار دارند، سناریوی «عدم پاسخ» رایج‌ترین حالت شکست است. دلیل این امر ساده است: انسان‌ها می‌خوابند، حواسشان پرت می‌شود یا اعلان‌ها را بی‌صدا می‌کنند، در حالی که مجریِ عامل (Agent) معمولاً تک‌رشته‌ای (Single-threaded) است و در حالت انتظار، مانند یک لوله یخ‌زده، تمام صف دستورات پشت سر آن را می‌بندد. این چالش‌ها در مقیاس وسیع‌تر، منجر به شکست درگاه‌های تایید انسانی در مقیاس عامل‌های هوش مصنوعی می‌شود که در تحلیل‌های پیشین به آن پرداختیم.

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

نسخه اول، نبود پاسخ را به معنای «همچنان در انتظار» (Still Pending) تلقی می‌کرد. نتیجه این بود که ربات برای تایید یک تنظیمات غیرمعمول «سطح ۳» در ساعت ۲:۱۴ بامداد متوقف شد و نتوانست گزارش‌های صبحگاهی و مدیریت پوزیشن‌های موجود را اجرا کند. قصد (Intent) ربات با ادب و صبوری منتظر ماند، اما چون مجری مدل در هر لحظه فقط یک قصد را به‌ترتیب پردازش می‌کند، هر چیزی که در صف بود، متوقف شد.

نسخه دوم سعی کرد با ارسال یادآورهای هر ۱۵ دقیقه یک‌بار، مشکل را حل کند. این کار منجر به «خستگی از اعلان» (Notification Fatigue) شد؛ جایی که کاربر با ۲۸ هشدار تکراری درباره یک معامله بیدار می‌شد. این وضعیت ریسک را به شدت بالا می‌برد، زیرا انسانی که نیمه‌بیدار است ممکن است بدون خواندن متن، به‌طور تصادفی گزینه «تأیید» یا «رد» را لمس کند. نویسنده اشاره می‌کند که لحظاتی وجود داشت که واقعاً خطرناک بود، زیرا سعی می‌کرد به یاد آورد که کدام اقدام را با لمس صفحه تایید یا رد کرده است. این ثابت می‌کند کانال‌های اعلانِ مزاحم، در نهایت بی‌صدا (Mute) می‌شوند و یک کانال بی‌صدا، بدتر از نبودِ نظارت است چون توهمِ کنترل ایجاد می‌کند.

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

• مهلت‌های صریح: درخواست شامل قصد کامل، استدلال و یک مهلت متنی واضح است (مثلاً: «تا ساعت ۰۳:۱۴ پاسخ دهید، در غیر این صورت درخواست رد می‌شود. عدم پاسخ = عدم معامله»).
• یادآوری محدود: سیستم دقیقاً یک یادآور در نیمه راه (Halfway mark) ارسال می‌کند و سپس کاملاً سکوت می‌کند.
• رد به عنوان یک عملیات موفق: اتمام مهلت زمانی با برچسب rejected_timeout ثبت می‌شود و در گزارش صبحگاهی می‌آید. این اتفاق یک خطای سیستمی نیست، بلکه یک عملیات موفق تلقی می‌شود.

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

از نظر فنی، این منطق توسط یک کلاس ApprovalGate در حدود ۳۰ خط کد مدیریت می‌شود. مکانیسم اصلی از یک ثابت WAIT برای ۳۶۰۰ ثانیه (یک ساعت) و REMIND_AFTER برای ۱۸۰۰ ثانیه استفاده می‌کند. کد به‌طور صریح بررسی می‌کند که اگر وضعیت UNANSWERED بود، پاسخ Denied("timeout means no") را برگرداند.

دو جزئیات حیاتی در این پیاده‌سازی وجود دارد:

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

علاوه بر این، نویسنده تأکید می‌کند که درگاه تأیید یک «سند تصمیم‌گیری» است، نه یک مرز امنیتی. امنیت واقعی توسط سقف‌های بودجه (Budget Caps)، محدودیت‌های ریسک (Exposure Limits) و یک «کلید مرگ» (Dead-man switch) تأمین می‌شود که اگر ضربان قلب (Heartbeat) ربات افت کرد، تمام تأییدات معلق را رد کند. درگاه تصمیم می‌گیرد که آیا اقدامی رخ دهد، اما سقف‌ها تصمیم می‌گیرند که «چقدر» رخ دهد. در اینجا باید به این نکته توجه داشت که هزینه‌های پنهان نگهداری زیرساخت‌های تایید AI می‌تواند پیچیدگی‌های عملیاتی را به شدت افزایش دهد.

ثبت این رد شدن‌ها، یک مجموعه داده رایگان برای عیب‌یابی مدل جهانِ (World Model) عامل فراهم می‌کند. برای مثال، نویسنده متوجه شد که ربات بیش از حد تنظیمات عادی را «غیرمعمول» می‌بیند، که نشان‌دهنده یک باگ در پیکربندی آستانه نوسانات (Volatility Threshold) بود. این رد شدن‌ها نویز نبودند، بلکه سیستم داشت باگ پیکربندی را نشان می‌داد. دو معیار اصلی برای سلامت این درگاه وجود دارد:

• حجم درخواست‌ها: درخواست‌های سطح ۳ باید نادر باشند (مثلاً هفته‌ای یک‌بار). اگر روزانه تکرار شوند، یعنی آستانه‌های بالادستی و سقف‌ها اشتباه تنظیم شده‌اند و درگاه صرفاً در حال جذب سرریز است. درگاهی که مدام سوال می‌پرسد، در معرض «تأیید کورکورانه» (Rubber-stamping) قرار می‌گیرد که وضعیت شکست نهایی هر سیستم تأییدی است.
• نرک اختلاف نظر: اگر انسان‌ها به‌طور مکرر رد شدن‌های ناشی از تایم‌اوت را لغو و دستی تایید کنند، یعنی منطق ربات با واقعیت فاصله دارد.

نظارت بر این سیستم باید به‌درستی دسته‌بندی شود. نویسنده در ابتدا رد شدن‌های تایم‌اوت را به عنوان «هشدار» (Warning) ثبت می‌کرد که باعث فعال شدن صفحات مانیتورینگ سلامت می‌شد. اما رد شدن ناشی از تایم‌اوت، در واقع سیستم است که طبق طراحی عمل می‌کند. این مورد باید در یک گزارش روتین باشد، نه یک هشدار. هشدارها فقط زمانی باید فعال شوند که درگاه اصلاً نتواند با انسان ارتباط برقرار کند.

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

• اقدامات برگشت‌پذیر: عامل به‌تنهایی عمل کرده و همه چیز را ثبت می‌کند.
• اقدامات روتین و محدود: عامل به‌تنهایی عمل می‌کند اما ابتدا یک رسید (Receipt) ارسال می‌کند.
• اقدامات غیرمعمول یا برگشت‌ناپذیر: عامل یک‌بار می‌پرسد، یک‌بار یادآوری می‌کند و سکوت یعنی «نه».

برداشت بنیادی برای هر پشته‌ی عاملی این است که «تایم‌اوت یعنی نه» و یک «نه»، یک نتیجه درجه اول است، نه یک خطای سیستمی.

گام بعدی شما

• اگر در حال ساخت عامل‌های عامل‌محور (Agentic) هستید، وضعیت Pending را حذف کرده و برای هر درخواست یک TTL (زمان مرگ) تعریف کنید.
• در پیام‌های ارسالی برای کاربر، صراحتاً ذکر کنید که عدم پاسخ منجر به چه نتیجه‌ای می‌شود تا کاربر دچار اضطراب یا توهم کنترل نشود.
• نرخ rejected_timeout را به عنوان یک متریک برای کالیبراسیون مدل استدلالی ربات خود رصد کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.