چرا افزایش هوشمندی مدل‌ها مشکل خروج زودهنگام عامل‌ها را حل نمی‌کند؟

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

برای سال‌ها، تمرکز صنعت هوش مصنوعی بر «توانایی» بود؛ یعنی یاد بدهیم مدل‌ها چگونه از ابزارها استفاده کنند، در وب جستجو کنند و کد بنویسند. اما حالا که عامل‌ها از چت‌بات‌های تک‌مرحله‌ای (One-shot) به سمت سیستم‌های خودمختار با اجرای طولانی‌مدت حرکت می‌کنند، چالش از «آیا مدل می‌تواند کار را انجام دهد؟» به «آیا می‌داند کی کار تمام شده است؟» تغییر کرده است. این تفاوت شبیه تفاوت بین ماشین لباس‌شویی است که وقتی لباس‌ها تمیز شدند متوقف می‌شود و ماشینی که شش ساعت متوالی می‌چرخد. در مقابل، ماشینی را تصور کنید که چرخه را تمام کرده و خاموش می‌شود، اما متوجه نمی‌شود که ده دقیقه بعد آب شروع به نشت کرده یا بار جدیدی از لباس‌ها رسیده است. هیچ‌کدام از این دو extrem (حد افراط) تحسین‌برانگیز نیستند.

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

چهار وضعیت مختلف از «اتمام کار»

بر اساس تحلیل‌های دقیق رفتاری عامل‌ها، کلمه «تمام شد» در واقع چهار وضعیت عملیاتی متفاوت را پنهان کرده است که سیستم‌ها باید بین آن‌ها تمایز قائل شوند. اگر یک عامل تمام این حالت‌ها را با یک وضعیت داخلی واحد به نام "DONE" نمایش دهد، سیستم فاقد دقت لازم برای خودمختاری واقعی خواهد بود:

• اتمام وظیفه (Task Completion): نتیجه مورد نیاز حاصل شده و شواهد موجود، معیارهای پذیرش (Acceptance Criteria) را برآورده می‌کنند. در این حالت، عامل باید وظیفه را به پایان برساند، به‌جای اینکه به تغییر دادن نتیجه ادامه دهد.
• انسداد منطقی (Reasonable Blockage): کار نمی‌تواند به‌طور منطقی ادامه یابد زیرا عامل فاقد یک مجوز لازم است، یک سرویس در دسترس نیست یا دستورالعمل‌ها با هم تضاد دارند. عامل باید تلاش را متوقف کند، دانش خود را حفظ کند و دلیل انسداد را توضیح دهد، به‌جای اینکه شکست را به‌جای موفقیت جا بزند.
• عدم نیاز به اقدام فوری (No Immediate Action): عامل وضعیت مربوطه را بررسی می‌کند و متوجه می‌شود هیچ شرطی که نیاز به مداخله داشته باشد وجود ندارد. این به معنای اتمام یک وظیفه نیست، بلکه چرخه‌ای است که در آن هیچ اقدامی توجیه‌پذیر نیست.
• مسئولیت جاری (Ongoing Responsibility): بررسی فعلی تمام شده است، اما عامل همچنان مسئول مشاهده رویدادهای مرتبط و واکنش به تغییرات احتمالی در آینده است.

پژوهش‌ها درباره خویشتن‌داری عامل‌ها

مطالعات اخیر در سال ۲۰۲۶ نشان می‌دهد که صرفاً استفاده از مدل‌های «باهوش‌تر»، مشکل توقف را حل نمی‌کند. افزایش توانایی به‌طور خودکار به خویشتن‌داری بهتر تبدیل نمی‌شود. توانایی تکمیل یک وظیفه و توانایی اعمال خویشتن‌داری (Restraint)، دو قابلیت کاملاً مجزا هستند. این جدایی میان توانایی فنی و قضاوت اخلاقی یا عملیاتی، ما را به این فکر می‌اندازد که چگونه هوش مصنوعی می‌تواند به عنوان میکروسکوپی برای تحلیل الگوهای شناختی انسان عمل کند و نقاط کور تفکر ما را در مواجهه با ابزارهای خودمختار آشکار سازد.

در ژوئن ۲۰۲۶، پژوهشگران Han Luo، Bingbing Wen و Lucy Lu Wang مقاله‌ای با عنوان «امتناع عامل‌محور: آیا عامل‌ها می‌دانند چه زمانی به‌جای اقدام، متوقف شوند؟» منتشر کردند. آن‌ها ۱۳ سیستم عامل و دو داربست (Scaffold) را در بیش از ۲۸,۰۰۰ وظیفه شامل خرید وب، محیط‌های ترمینال و پاسخ به سوالات بررسی کردند. آن‌ها دریافتند که تشخیص یک وظیفه غیرممکن و توقف سریع، چالش‌های جداگانه‌ای هستند. یک عامل ممکن است در نهایت متوجه شود که کالایی وجود ندارد، اما این اتفاق تنها پس از چندین جستجوی غیرضروری رخ می‌دهد. نکته حیاتی این بود که مدل‌های قدرتمندتر لزوماً در «امتناع به‌موقع» عملکرد بهتری نداشتند.

به همین ترتیب، مقاله‌ای در جولای ۲۰۲۶ با عنوان «AgentAbstain: آیا عامل‌های LLM می‌دانند چه زمانی اقدام نکنند؟»، ۱۷ مدل پیشرو را در ۴۲ محیط شبیه‌سازی‌شده (Sandbox) با استفاده از ۲۶۳ وظیفه جفت‌شده ارزیابی کرد. هر جفت شامل یک وضعیت بود که عامل باید اقدام می‌کرد و یکی که یک تغییر کنترل‌شده به این معنا بود که باید امتناع ورزد. بهترین مدل تنها به نرخ دقت ۵۹.۵٪ در معیار دقت جفت‌شده رسید، در حالی که ۱۳ مدل از ۱۷ مدل، نمره‌ای زیر ۵۰٪ کسب کردند. این ثابت می‌کند که توانایی استفاده از یک ابزار، کاملاً از قضاوت درباره «عدم استفاده» از آن جدا است.

برای مقابله با این مشکل، در اوت ۲۰۲۶ یک پیش‌نویس پژوهشی با عنوان «توقف مبتنی بر شواهد برای LLMهای ابزار-محور» پیشنهاد شد. این مکانیسم از عامل می‌خواهد یک «گواهی اتمام» ارائه دهد که ادعاهای مورد نیاز را به شواهد موجود در ردپای اجرا (Execution Trace) پیوند دهد. مقادیر استخراج شده باید از طریق یک فرآیند تایید قطعی (Deterministic) قابل بازسازی باشند. این کار مانع از آن می‌شود که مدل صرفاً چون «احساس می‌کند» کار تمام شده، آن را به پایان برساند. با این حال، پژوهشگران اشاره کردند که این روش در محیط‌های محدود و مصنوعی تست شده و نمی‌تواند به‌طور جادویی ثابت کند که هر مشاهده خارجی درست بوده یا مشخصات اولیه وظیفه کامل بوده است.

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

برای ساخت عامل‌های قابل‌اعتماد، توسعه‌دهندگان باید «وضعیت وظیفه» را از «وضعیت زمان اجرا» جدا کنند. یک سیستم ساده از یک وضعیت واحد مانند "RUNNING" یا "COMPLETE" استفاده می‌کند. اما یک معماری مستحکم، این‌ها را به دو بعد تقسیم می‌کند تا نتیجه یک وظیفه با وضعیت کلی سرویس اشتباه گرفته نشود.

بعد اول: نتیجه وظیفه (Task Outcome)

• COMPLETE: شرایط مورد نیاز برآورده و تایید شده‌اند.
• INCOMPLETE: کار باقی مانده و ادامه آن هنوز منطقی است.
• BLOCKED: یک ورودی، مجوز یا شرط خارجی لازم در دسترس نیست.
• FAILED: تلاش تحت یک شرط شکست تعریف‌شده، به‌طور ناموفقی به پایان رسید.
• NEEDS_REVIEW: سیستم نمی‌تواند بدون ارجاع به انسان (Escalation)، تصمیمی را به‌طور ایمن حل کند.

بعد دوم: حالت سرویس (Service Mode)

• ACTIVE: اجرای یک وظیفه تایید شده یا ادامه کار مفید.
• OBSERVE: نظارت بر تغییرات مرتبط بدون انجام مداخله.
• WAIT: انتظار برای یک رویداد شناخته شده، بررسی زمان‌بندی شده یا وابستگی خارجی.
• STOPPED: خودِ سرویس خاموش یا غیرفعال شده است.

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

تعریف موفقیت و پیشرفت

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

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

علاوه بر این، زمان اجرا (Runtime) نباید به نظر مدل درباره موفقیت خودش اعتماد کند. همان‌طور که در راهنمای Anthropic با عنوان «شفاف‌سازی ارزیابی‌ها برای عامل‌های AI» توصیه شده است، ارزیاب‌های کد-محور قطعی باید نتایج خاص را مدیریت کنند، در حالی که ارزیاب‌های مدل-محور معیارهای ظریف‌تر را بررسی کنند. اگر شرطی توسط یک اسکریپت قابل بررسی است، نظر مدل بی‌ارزش است.

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

خطر «لاگ‌های شلوغ»

یک عامل می‌تواند فعال باشد بدون اینکه پیشرفتی کند. ممکن است یک برنامه را ده بار بازنویسی کند، یک فایل را مکرراً بخواند یا پرس‌وجوهای جستجوی کمی متفاوت صادر کند بدون اینکه وضعیت جهان را تغییر دهد. این وضعیت یک «لاگ شلوغ» (Busy Log) ایجاد می‌کند که نبود پیشرفت را می‌پوشاند.

پیشرفت معنادار باید با «رفع عدم قطعیت» یا «برآورده شدن یک معیار پذیرش» سنجیده شود. این می‌تواند به معنای موارد زیر باشد:

• یک معیار که قبلاً برآورده نشده بود، اکنون برآورده شده است.
• شواهد جدید، یک عدم قطعیت را حل کرده است.
• یک تست شکست‌خورده به وضعیت پاس (Passing) تغییر یافته است.
• یک آرتیفکت تایید شده ایجاد شده است.
• یک مانع برطرف شده است.
• مجموعه اقدامات بعدی ممکن بر اساس اطلاعات جدید تغییر کرده است.

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

مدیریت نظارت و بازگشایی وظایف

برای عامل‌هایی که به‌طور مداوم اجرا می‌شوند، سیستم باید بین «وضعیت تایید شده فعلی» و «وضعیت بدون تغییر» تمایز قائل شود. اگر وضعیت مربوط به یک نتیجه بدون تغییر بماند، تکرار یک بررسی هزینه‌بر ارزش کمی دارد. اما اگر یک وابستگی محلی تغییر کند، تصمیم قبلی درباره یک ماژول واردکننده (Importing Module) ممکن است دیگر معتبر نباشد، حتی اگر سورس کد خود آن ماژول تغییر نکرده باشد.

نظارت (Observation) یک سبک‌سنگین کردن (Trade-off) صریح بین هزینه، پاسخ‌دهی و پوشش است. یک معماری منطقی باید بین وضعیت تایید شده فعلی، وضعیت بدون تغییر، وضعیت نامشخص (جایی که سیستم نمی‌تواند تشخیص دهد آیا نتیجه قدیمی هنوز معتبر است یا خیر) و وضعیت تغییر یافته تمایز قائل شود.

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

اندازه‌گیری هزینه بی‌عملی

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

• نرخ اتمام زودهنگام (Premature Completion Rate): هر چند وقت یک‌بار عامل در حالی که الزامات برآورده نشده‌اند، متوقف می‌شود.
• نرخ اقدام غیرضروری (Unnecessary Action Rate): هر چند وقت یک‌بار سیستم را تغییر می‌دهد در حالی که هیچ مداخله‌ای توجیه‌پذیر نبود (تمایز بین بازرسی بی‌ضرر و اقدام ریسکی).
• نرخ بازگشایی نادرست (False Reopening Rate): هر چند وقت یک‌بار رویدادهای نامرتبط باعث شروع مجدد یک وظیفه تکمیل‌شده می‌شوند.
• نرخ بازگشایی از دست رفته (Missed Reopening Rate): هر چند وقت یک‌بار یک تغییر مرتبط نمی‌تواند یک نتیجه قدیمی را باطل کند.
• تأخیر در توقف (Delayed Stopping): تعداد تعاملات غیرضروری پیش از آنکه عامل در نهایت متوقف شود، همان‌طور که در مقاله ژوئن ۲۰۲۶ Agentic Abstention بررسی شد.
• نرخ اتمام تایید نشده (Unverified Completion Rate): هر چند وقت یک‌بار سیستم بدون شواهد کافی، موفقیت را گزارش می‌کند.
• هزینه به ازای نتیجه تایید شده (Cost per Verified Outcome): مقدار محاسبات و توکن مصرف شده برای رسیدن به نتیجه‌ای که واقعاً شرایط را برآورده می‌کند.
• پوشش نظارت (Observation Coverage): سیستم با چه اطمینانی تغییرات مرتبط را شناسایی می‌کند بدون اینکه فعالانه مداخله کند.

حفاظ‌ها و محدودیت‌های سخت

چارچوب‌های عملیاتی باید شامل محدودیت‌های سخت (Hard Limits) باشند تا از اجرای خارج از کنترل (Runaway Execution) جلوگیری شود. مستندات Microsoft درباره «حلقه‌های عامل» (Agent Looping) به توسعه‌دهندگان هشدار می‌دهد که حلقه‌های خودمختار را محدود کنند زیرا شرایط اتمام ممکن است شکست بخورند و مدل‌ها ممکن است متوقف شوند. زمان اجرا باید محدودیت‌هایی را برای حداکثر گام‌ها، زمان سپری شده، فراخوانی‌های ابزار، هزینه توکن و چرخه‌های متوالی بدون پیشرفت معنادار اعمال کند.

با این حال، این‌ها «حفاظ‌های ایمنی» هستند، نه شواهدی برای اتمام. اگر یک عامل به حداکثر تلاش‌های خود برسد، وظیفه "COMPLETE" نیست؛ بلکه به‌دلیل اتمام بودجه، "BLOCKED" یا "FAILED" است. زمان اجرا باید یک دلیل نهایی صادقانه برگرداند — مانند "NEEDS_REVIEW: نتیجه خارجی قابل تایید نبود" — به‌جای اینکه «توقف فرآیند» را با «موفقیت وظیفه» اشتباه بگیرد.

مرز شواهد

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

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

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

گام بعدی شما

• در طراحی عامل‌های خود، وضعیت «اتمام وظیفه» را از «وضعیت سرویس» تفکیک کنید تا از حلقه‌های تکرار جلوگیری شود.
• به‌جای تکیه بر نظر مدل برای تایید موفقیت، از ارزیاب‌های کد-محور (Deterministic Graders) استفاده کنید.
• برای هر عامل، یک سقف سخت برای تعداد گام‌ها و هزینه توکن تعریف کنید و خروجی «توقف به‌دلیل بودجه» را از «موفقیت» متمایز کنید.

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