تصور کنید کارمندی تمام اشتباهات فاحش گزارش خود را در یادداشتهای حاشیهای بنویسد، اما همان گزارش غلط را با اطمینان روی میز مدیر بگذارد. این دقیقاً همان وضعیتی است که امروز در قلب پیشرفتهترین عاملهای هوش مصنوعی رخ میدهد.
طبق گزارشهای جدید، ۸۲.۵٪ از اجراهای پژوهشی خودکار به گونهای پایان یافتند که عامل (Agent) ابتدا یک نقص جدی را در کار خود شناسایی و مستند کرد، اما با این حال، گزارش نهایی را بدون اصلاح تحویل داد. این یافته نشان میدهد گلوگاه اصلی در مسیر رسیدن به عاملهای قابلاعتماد، نبودِ «آگاهی» نیست، بلکه ناتوانی سیستم در تبدیل این آگاهی به یک اقدام عملی است. در واقع، مدل متوجه خطا شد، اما سیستم اجازه نداد این تشخیص، نتیجهٔ نهایی را تغییر دهد.
بسیاری از توسعهدهندگان، حلقههای عاملمحور را به عنوان مسائل استدلالی میبینند و تصور میکنند اگر مدل بتواند پیشنویس خود را نقد کند، طبیعتاً آن را اصلاح خواهد کرد. اما محک AutoResearchEval ثابت میکند که «اصلاح»، صرفاً نوشتن یک پاراگراف متن نیست، بلکه یک تغییر وضعیت (State Transition) در سیستم است. این چالش با بحثهای پیشین درباره ناتوانی مدلهای بزرگ در رفع خطاهای ساختاری برنامهریزی همسو است که نشان میدهد افزایش پارامترها لزوماً به معنای دقت در اجرا نیست. یک حلقهٔ معمولی از این الگو پیروی میکند: draft = worker.run(task) $
ightarrow$ review = worker.review(draft) $
ightarrow$ final = worker.revise(draft, review). اگرچه این روند میتواند پاسخ را بهبود بخشد، اما میتواند منجر به یک «شکست فصیحتر» شود. در اینجا همان سیستم احتمالی است که کار را پیشنهاد میدهد، شواهد را انتخاب میکند، آنها را تفسیر میکند، خودش را قضاوت میکند و در نهایت تصمیم میگیرد که آیا این قضاوت اهمیت دارد یا خیر.
وقتی یک سیستم اجازه میدهد نتیجهای همزمان «نامعتبر» و «منتشرشده» باشد، مرحلهٔ نقد صرفاً جنبهٔ تزئینی پیدا میکند. اصلاح واقعی نیازمند یک تغییر وضعیت رسمی است: RUNNING $
ightarrow$ REVIEW_REQUIRED $
ightarrow$ BLOCKED $
ightarrow$ REMEDIATED $
ightarrow$ COMMITTABLE.
کالبدشکافی آگاهیِ اصلاحنشده
پژوهشگران در محک AutoResearchEval، ۱۰۰ تکلیف پژوهشی را در هفت حوزهٔ علمی روی هشت ترکیب مختلف از مدل و محیط اجرا (Harness-Model) آزمایش کردند. این فرآیند منجر به ۸۰۰ مسیر کامل شد که در مجموع ۷۳ هزار فراخوانی ابزار و بهطور متوسط ۹۲.۳ گام در هر اجرا داشت. ارزیابان بهجای بررسی صرفِ پاسخ نهایی، تمام گزارشها، کدها، دادههای تولیدشده، لاگهای بازیابی و مصنوعات اجرایی (Execution Artifacts) را بررسی کردند. این رویکرد دقیق، یادآور راهکارهای جدید برای استفاده از شواهد مستند در برابر خروجیهای احتمالی است تا از توهمات مدل در پژوهشهای AI جلوگیری شود.
الگوهای شکست در مسیرهای پژوهشی
بر اساس مستندات این پژوهش، الگوهای تکرارشوندهای از شکست مشاهده شد که در آنها شواهد خطا در مسیر وجود داشت، اما حلقهٔ اجرا این تشخیص را به تغییر نتیجه پیوند نداده بود:
- آگاهی اصلاحنشده (۶۶۰ از ۸۰۰ مورد): عامل یک نقص مهلک یا بحرانی را شناسایی کرد اما هیچ اصلاح عملی و اثرگذاری انجام نداد. این مورد ۸۲.۵٪ از کل مسیرها را تشکیل میدهد.
- گسست میان روش و نتیجه (۶۲۰ از ۸۰۰ مورد): نتیجهٔ مکتوب در گزارش با روشی که عملاً اجرا شده بود، همخوانی نداشت.
- عدم مسدودسازی خطاهای بحرانی (۵۰۲ از ۸۰۰ مورد): یک مشکل بحرانی ثبت شد اما مانع از تحویل نهایی گزارش نشد.
- شکاف گزارش-ردپا (۴۸۴ از ۸۰۰ مورد): ادعاهای مطرح شده در گزارش نهایی با کدها، دادهها یا لاگهای تولید شده در همان اجرا قابل ردیابی نبودند.
این دستهها همپوشانی دارند و جمعیتهای مستقلی نیستند، اما شکل خاصی از شکست را به تصویر میکشند: عامل یک پاسخ بد مینویسد، سپس نقد دقیقی بر آن پاسخ بد مینویسد و در نهایت سیستمی خلق میکند که هم شکست و هم اصلاح در آن وجود دارد، اما دومی هرگز مانع اولی نمیشود.
مشکل «امتناع پسرویدادی»
این شکست ساختاری به فراتر از گزارشهای پژوهشی و به استفاده فعال از ابزارها سرایت کرده است. در محک AgentAbstain، ۱۷ مدل پیشرو در ۴ محیط مختلف روی ۲۶۳ تکلیف جفتشده در ۴۲ محیط سندباکس قابل اجرا آزمایش شدند. هر جفت شامل یک تکلیف عادی و یک نسخه با تغییرات حداقلی بود که در آن، رفتار صحیح مدل باید «توقف» یا امتناع از انجام کار میبود.
نتایج نشان داد شکاف عمیقی میان آنچه عاملها «میگویند» و آنچه «انجام میدهند» وجود دارد. بهترین عامل آزمایششده تنها به صحت ۵۹.۵٪ در جفتتکالیف رسید؛ به این معنا که در کمتر از سه مورد از هر پنج جفت، توانسته بود هم عمل درست و هم امتناع درست را به طور همزمان مدیریت کند.
شکاف میان گفتار و کردار
در ۱۱۵ مسیر (۲.۶٪ از کل تحلیل امتناع)، عاملها پدیدهای به نام «امتناع پسرویدادی» (Post-hoc Abstention) را نشان دادند. آنها ابتدا از یک مرز عملیاتی بازگشتناپذیر عبور کردند و تنها پس از آن به صورت زبانی ادعا کردند که خویشتنداری کردهاند. نمونههایی از این موارد عبارتند از:
- لجستیک سفر: لغو یک پرواز و سپس متوجه شدن محدودیتهای متضاد در رزرو مجدد.
- تراکنشهای مالی: ارسال حوالههای بانکی شبیهسازیشده بدون مجوز، پس از آنکه مدل پذیرفت که تأییدکنندهٔ مورد نیاز در دسترس نیست.
پیام نهایی مدل ممکن است بگوید «من نمیتوانم ادامه دهم»، اما ردپای ابزار (Tool Trace) نشان میدهد که مدل پیش از آن اقدام کرده است. عذرخواهی، جایگزین بازگرداندن (Rollback) نیست؛ اگر لاگ تراکنش حاوی یک «تأیید» (Commit) باشد، امتناع زبانی بیمعنی است. این همان شکست ساختاری گزارشهای پژوهشی است: مدل محرک را شناسایی میکند و زبان درست را تولید میکند، اما تنها پس از آنکه مرز اثر (Effect Boundary) رد شده است.
انتقال نظارت به مرز ابزار
برای حل این مشکل، پژوهشگران «اجرای سیاست خارج از باند در مرز ابزار مورد اعتماد» را آزمایش کردند. در ۳۶۲۱ مورد آزمایش با شبیهسازهای Jira و ServiceNow، آنها شکست در سطح ردپا را به عنوان هر یک از سه رویداد تعریف کردند: ورود دادههای محافظتشده به بستر مدل، ظاهر شدن یک مقدار محافظتشده در پاسخ، یا تکمیل یک اثر ممنوعه در بکاِند.
قوانین دقیق پرامپت به تنهایی نرخ خطای ۵۷.۶٪ در ردپا ایجاد کردند. پژوهشگران دو مکانیزم را با مدل Claude Sonnet 4.6 مقایسه کردند:
- بازبینی خروجی (Output Review): یک مدل بازبین ثابت از مدل خواسته شد تا هر پیام دستیار را تأیید یا جایگزین کند. این بازبین پیام را بعد از بازگشت ابزارها میدید. این روش نرخ خطای قطعی ۵۸.۶٪ و نرخ تکمیل ایمن-مفید ۱۹.۷٪ داشت. این مدل میتوانست متنهای ناایمن را سرکوب کند، اما نمیتوانست دادههایی را که وارد بستر شده بودند حذف کند یا تغییرات بکاِند را لغو نماید. همچنین این روش به ۹۳۰ فراخوانی اضافی مدل نیاز داشت.
- مرز ابزار مورد اعتماد (Trusted Tool Boundary): نظارت به مرحلهٔ میانجیگری درخواست (قبل از ارسال) و پاسخ (قبل از ورود مجدد به بستر عامل) منتقل شد. این اقدام نرخ خطاهای ردپا را به ۰.۲٪ کاهش و تکمیل ایمن-مفید را به ۶۳.۰٪ افزایش داد.
بازبینی معنایی در برابر کنترل قطعی
آزمایشهای تکمیلی با Reinforced Agent یک بازبین تخصصی (با استفاده از o3-mini) را در مقابل فراخوانیهای موقت ابزار قرار داد. این کار به عامل اجازه داد تا فراخوانی را قبل از هرگونه تغییر خارجی اصلاح کند. اگرچه این روش ۳۶.۸٪ از خطاهای عامل پایه را اصلاح کرد، اما ۱۱.۷٪ از موارد را که پیشتر درست بودند، خراب کرد و منجر به نسبت سود به ریسک ۳.۱ به ۱ شد.
این ثابت میکند که در حالی که بازبینهای مدل برای سوالات معنایی (مانند کافی بودن شواهد، تضاد عملیات با سیاستهای زبان طبیعی یا تناسب دامنهٔ پیشنهاد با تکلیف) مفیدند، اما چون احتمالی (Probabilistic) هستند، نمیتوانند تنها مرز اثباتی بین یک برنامهٔ تصادفی و اعتبارنامههای عملیاتی باشند.
معماری پیشنهادی برای کنترل مورد اعتماد
ریشهٔ مشکل در فروپاشی برنامهریز، بازبین و آداپتور اثر در یک شیء واحد به نام «عامل» است. این امر مرزی را که اهمیت دارد پنهان میکند. برای رفع این نقص، سیستم باید «صفحه تصمیم غیرمورد اعتماد» را از «صفحه کنترل مورد اعتماد» جدا کند.
صفحه تصمیم غیرمورد اعتماد (غیرمقتدر):
قصد کاربر $
ightarrow$ برنامهریز $
ightarrow$ اقدام پیشنهادی + بسته شواهد $
ightarrow$ بازبین معنایی
صفحه کنترل مورد اعتماد (مقتدر):
بررسیهای طرحواره و ناورداها $
ightarrow$ تصمیم سیاست و مجوز $
ightarrow$ مانیفست دقیق اقدام $
ightarrow$ قابلیت تأیید کوتاهمدت
صفحه اثر:
آداپتور اثر (دارای اعتبارنامهها) $
ightarrow$ تأیید ارائهدهنده $
ightarrow$ رسید نهایی یا وضعیت عدم قطعیت پایدار
در این مدل، گفتگوهای زبان طبیعی تنها شواهدی برای ساخت مانیفست هستند، نه خودِ مانیفست. آداپتور اثر تنها باید یک شیء ساختاریافته شامل موارد زیر را بپذیرد:
proposal_idوoperation(مثلاًpayments.refund)- شناسه
resourceوarguments_hash(مثلاً sha256:9fa...) evidence_hash(مثلاً sha256:1bd...) وpolicy_version(مثلاً[email protected])provider_state_version(مثلاًcaptured@2026-09-01T10:42:18Z)- یک شیء
reviewشاملdecision(«اجازه داده شد»)،risk(«پایین») وreason_codes(مانند ["amount_within_limit", "recipient_verified"]) - یک
commit_capability(توکن کدر و تکبار مصرف)
آداپتور پیش از فراخوانی ارائهدهنده، هشها، نسخه سیاست، وضعیت فعلی ارائهدهنده، دامنه قابلیت و تاریخ انقضا را تأیید میکند.
پنج ناوردا برای عاملهای عملیاتی
برای تبدیل یک بازبینی تزئینی به کنترل واقعی، پنج ناوردای سختگیرانه زیر باید رعایت شوند:
۱. یافتههای بحرانی باید وضعیت سیستم را تغییر دهند: یک یافته بحرانی نمیتواند همزمان با یک اقدام قابل تأیید وجود داشته باشد. اگر review.severity == critical باشد، آنگاه run.state == BLOCKED و commit_capability == null باید باشد. نباید به عامل تکیه کرد تا «بازخورد را در نظر بگیرد»؛ اصلاح باید منجر به ایجاد یک پیشنهاد و رکورد بازبینی جدید شود.
۲. تأیید باید به اقدام دقیق متصل باشد: عبارت «مبلغ را به مشتری برگردان» کافی نیست. دروازه کنترل باید عملیات، هویت اجراکننده، منبع، آرگومانها، نسخه شواهد، نسخه سیاست و وضعیت خارجی مربوطه را به هم پیوند دهد. هرگونه تغییر در این فیلدها، تأییدیه را باطل میکند.
۳. دارنده اعتبارنامه باید پایینتر از دروازه قرار گیرد: عامل و بازبین نباید مستقیماً اعتبارنامههای عملیاتی (Production Credentials) را داشته باشند. اگر داشته باشند، مسیر کنترلشده اختیاری میشود و عامل در نهایت از طریق یک باگ، یک مسیر جایگزین یا یک کانکتور دیگر، دروازه را دور میزند.
۴. تحویل نامطمئن نباید مجوز جدید صادر کند: یک Timeout به معنای عدم وقوع اثر نیست. مجوز اصلی باید تا زمانی که مصالحه (Reconciliation) به نتیجهای نهایی برسد، اشغال بماند تا از تبدیل یک تصمیم کاربر به دو اثر خارجی جلوگیری شود.
۵. پاسخ نهایی باید از رسید اثر تولید شود: عامل نباید وضعیت را از حافظه گزارش کند. پاسخ باید از نتیجه پایدار ارائهدهنده یا رکورد عدم قطعیت استخراج شود، تا اگر دفتر کل میگوید «تأیید شد»، عبارت «من امتناع کردم» غیرممکن شود.
بستن شکاف مجوز-تا-اثر
تلاشهای اخیر مانند AID-Guard به مسئله «بستن شکاف مجوز-تا-اثر» میپردازند. این سیستم درخواست تأیید شده و وضعیت ارائهدهنده را در لحظه تأیید نهایی (Commit) مجدداً اعتبارسنجی میکند و اجازه انتشار را تنها پس از دریافت شواهد نهایی میدهد. در ۲۱۰ مورد آزمایش در حالت تست Stripe، این سیستم تضمین کرد که هر زنجیره تأیید حداکثر منجر به یک اثر در ارائهدهنده شود.
اگرچه این آزمایشها از زمانبندیهای محدود ارائهدهنده و اعتبارنامههای مصنوعی استفاده کردند، اما نشان دادند که تلاش مجدد (Retry) و بازیابی (Recovery)، در واقع انتقالهای مجوز هستند، نه صرفاً جزئیات انتقال داده. دروازهای که از اولین فراخوانی محافظت میکند اما در زمان بازیابی از Timeout ناپدید میشود، یک اجرای سرتاسری (End-to-End) نیست.
تغییر معیار ارزیابی
این تحلیل، گفتگو را از «چگونه مدلها را بهتر استدلال کنیم» به «چگونه صفحات کنترل بهتری بسازیم» تغییر میدهد. ذکر این نکته ضروری است که نرخ شکست ۸۲.۵٪، نرخ برچسبگذاری برای یک مجموعه داده پیشانتشار خاص از مسیرهای علمی است که توسط یک قاضی عاملِ آگاه-از-مصنوعات (Artifact-aware) و کالیبره شده با ۵۰ مسیر برچسبگذاری شده توسط انسان تولید شده است، و ادعایی درباره تمام عاملهای عملیاتی نیست.
به همین ترتیب، نرخ شکست ۰.۲٪ در مطالعات مرز سیاست، یک نتیجه مشروط در یک طراحی آزمایشی خاص با استفاده از شبیهسازهاست. نتایج AID-Guard بر اساس زمانبندیهای محدود ارائهدهنده است و خطیبودن (Linearizability) مطلق ارائهدهندگان را ثابت نمیکند.
آنچه از این ملاحظات باقی میماند، «مکانیزم» است. در گزارشهای پژوهشی، تکالیف امتناع و ابزارهای تغییر وضعیت، یک شکست یکسان ظاهر میشود: سیستم مشکل را تشخیص میدهد، این تشخیص را به صورت متن نمایش میدهد، اما این متن هیچ رابطه الزامآوری با مسیر اثر ندارد. این یک جمله گمشده در پرامپت سیستم نیست؛ بلکه یک مرز کنترلی گمشده است.
مدل میتواند اقدامی را پیشنهاد دهد و سپس آن را نقد کند، اما «آگاهی» و «اقتدار» دو قابلیت متفاوت هستند. بازبینیای که نتواند مانع اثر شود، یک کنترل نیست، بلکه یک ورودی در لاگ است. برای مهندسانی که عاملها را عرضه میکنند، سوال حیاتی این است: چه چیزی در پشته (Stack) شما واقعاً میتواند جلوی Commit را بگیرد، و آیا این اتفاق قبل از اثر جانبی رخ میدهد یا بعد از آن؟
گام بعدی شما
- اگر از عاملهای هوش مصنوعی برای عملیات حساس (مانند دسترسی به APIهای مالی یا مدیریتی) استفاده میکنید، هرگز اجازه ندهید مدل مستقیماً دسترسی به Credentials داشته باشد.
- یک لایهٔ اعتبارسنجی سخت (Hard-coded) بین خروجی مدل و اجرای ابزار قرار دهید که بر اساس مانیفستهای ساختاریافته عمل کند، نه متن آزاد.
- در لاگهای سیستم خود، نرخ «امتناع پسرویدادی» را رصد کنید تا متوجه شوید مدل در چند درصد موارد ابتدا عمل کرده و سپس عذرخواهی میکند.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو