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

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

بسیاری از توسعه‌دهندگان، پاسخ‌های عامل را به عنوان منبع حقیقت می‌پذیرند. اما طبق گزارشی که در ۱۸ آوریل ۲۰۲۶ در وب‌سایت dev.to منتشر شد، شکاف میان آنچه یک عامل انجام می‌دهد و آنچه گزارش می‌کند می‌تواند بسیار عمیق باشد. این موضوع به‌ویژه هنگام تعامل عامل‌ها با ابزارهای پیچیده‌ی سازمانی مثل Jira، Slack، Linear، Figma، Sentry یا Postgres رخ می‌دهد.

مثلاً سناریویی را تصور کنید که در آن از یک عامل می‌خواهید وضعیت یک تیکت پروژه را به «در حال اجرا» (In Progress) تغییر دهد. عامل دستور را صادر می‌کند، سرور آن را می‌پذیرد و تیکت جابه‌جا می‌شود. با این حال، عامل با اطمینان پیام خطای «تعداد گام‌ها بیش از حد بود، عملیات متوقف شد» را برمی‌گرداند. شما تصور می‌کنید ابزار شکست خورده است، در حالی که واقعیت در نرم‌افزار دقیقاً برعکس است.

زمینه‌ی تست‌های زنده

این کشف در حین یکی از کسالت‌بارترین کارهای مهندسی رخ داد: تبدیل ادغام‌هایی که برچسب «تمام شده» داشتند اما هرگز روی حساب‌های واقعی تست نشده بودند، به نسخه‌های زنده. در کدها، این ادغام‌ها برچسب «هنوز تست زنده نشده» (NOT YET LIVE-TESTED) داشتند؛ وعده‌ای که توسعه‌دهنده هنوز عملی نکرده بود.

برای تحقق این وعده، توسعه‌دهنده باید از «مسیر خوش‌بینانه» (Happy Path) — جایی که کد فقط یک‌بار درست کامپایل و اجرا می‌شود — فاصله می‌گرفت. هدف این بود که ببینند آیا ادغام می‌تواند در مواجهه با یک API واقعی در یک روز بد، دوام بیاورد یا خیر.

اصطکاک APIهای واقعی

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

• عدم تطابق توکن: Atlassian اکنون دو نوع توکن API صادر می‌کند: کلاسیک و «محدودشده» (Scoped). پروتکل ادغام به‌طور خاموش فقط نسخه‌ی محدودشده را می‌پذیرفت.
• شکاف‌های تخصیص: حساب تست فاقد دسترسی به Jira بود و فقط Bitbucket و Trello داشت، که این موضوع نیاز به ساخت یک سایت جدید از صفر داشت.
• مجوزهای پنهان: یک کلید دسترسی در پنل مدیریت سازمان به‌طور پیش‌فرض خاموش بود و احراز هویت توکن API را مسدود می‌کرد. پیام خطای دریافتی هم یک عبارت مبهم بود: «با مدیر خود تماس بگیرید»، بدون اینکه اشاره کند مشکل از توکن است یا آن کلید پنهان.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، جزئیات زیرساختی اغلب جایی هستند که مدل‌های هوش مصنوعی بیشترین سردرگمی را تجربه می‌کنند. وقتی محیط آماده شد و عامل خواست تیکت KAN-1 را از وضعیت «به انجام» (To Do) به «در حال اجرا» (In Progress) جابه‌جا کند، منطق داخلی عامل از نتیجه‌ی خارجی فاصله گرفت.

کالبدشکافی یک شکست کاذب

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

• موفقیت‌های اولیه: عامل ابتدا تیکت را خواند و از Jira لیست تغییرات ممکن (Transitions) را خواست. هر دو فراخوانی موفق بود؛ رفتاری محتاطانه که در یک عامل (Agent) — شبیه دستیاری که قبل از هر اقدامی اول دفترچه راهنما را چک می‌کند — انتظار می‌رود.
• خطای نوع داده: عامل سعی کرد تغییر وضعیت را اعمال کند اما شناسه (ID) را به‌صورت عدد (Number) فرستاد، در حالی که API رشته (String) می‌خواست. این یک خطای رایج است که معمولاً به دلیل تکیه بر طرح‌های (Schema) ناقصی رخ می‌دهد که فقط در پیام‌های خطا دیده می‌شوند.
• اصلاح خطا: عامل خودش را اصلاح کرد، شناسه را به‌صورت رشته فرستاد و یک پاسخ موفقیت‌آمیز ۲۱ کاراکتری دریافت کرد. این پاسخ کوتاه و موجز بود، دقیقاً همان شکلی که یک پاسخ موفقیت واقعی در Jira دارد و نه یک بدنه خطا. تیکت رسماً جابه‌جا شده بود.
• محدودیت نوبت: برای جلوگیری از حلقه‌های بی‌نهایت و هزینه‌های سرسام‌آور استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، مثل خودِ آشپزی و نه دوره‌ی آموزش آشپزی — عامل‌ها محدودیت سخت‌گیرانه‌ای در تعداد «نوبت‌ها» (Turns) دارند. اگر این محدودیت دقیقاً هم‌زمان با موفقیت آخرین اقدام رخ دهد، عامل گزارش شکست می‌دهد چون نوبتی برای پردازش پیام موفقیت باقی نمانده است.
• مکانیزم ارفاق: برخی سیستم‌ها هنگام پیشرفت عامل، «فضای اضافی» می‌دهند. در اینجا، یک دوره‌ی ارفاق تک‌مرحله‌ای (One-shot) فعال شده بود که توسط فراخوانی‌های اولیه (فقط خواندنی) تحریک شده بود. چون این ارفاق فقط یک‌بار بود، وقتی اقدام نهایی (نوشتن) موفق شد، دیگر ذخیره‌ای باقی نمانده بود.

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

وقتی حفاظ‌ها، صحت را مجازات می‌کنند

فراتر از محدودیت نوبت، لایه‌های ایمنی که برای شناسایی توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که وجود ندارد، مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند — طراحی شده‌اند، می‌توانند داده‌های درست را مسدود کنند. در مورد دوم، عامل لیستی کاملاً دقیق از URLهای تیکت را مستقیماً از پاسخ API کپی کرد.

اما عامل لیست را با کاراکترهای تحت‌اللفظی \n به‌جای شکست خط واقعی نوشت. یک لایه‌ی ایمنی مجزا که وظیفه‌اش شناسایی URLهای ساختگی بود (که هرگز توسط ابزار برگردانده نشده‌اند)، با این فرمت به‌هم‌ریخته دچار مشکل شد. سیستم تصمیم گرفت این URLها جعلی هستند چون با فرمت تمیزی که انتظار داشت مطابقت نداشتند.

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

راهکار و شکاف تأیید

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

با این حال، توسعه‌دهنده به توصیفات خودِ راهکار اعتماد نکرد. تأیید نهایی مستلزم یک فرآیند دو مرحله‌ای بود:

۱. ممیزی لاگ‌ها: مشاهده رفتار درست مکانیزم در لاگ‌های داخلی هنگام تکرار درخواست.
۲. بررسی مستقل: پرسش مستقیم از Atlassian — کاملاً خارج از محیط عامل — برای اینکه وضعیت واقعی تیکت KAN-1 چیست. این یک بررسی ساده و مستقل در برابر وضعیت فعلی و واقعی تیکت بود.

توافق دو منبع مستقل، تنها شکل «تأییدشده‌ای» است که می‌توان به آن اعتماد کرد؛ یک جمله‌ی مطمئن، فارغ از فرمت آن، هرگز کافی نیست.

پیام گسترده‌تر

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

در حالی که شرکت‌هایی مثل Apple در WWDC استدلال می‌کنند که عامل‌های محلی با قابلیت فراخوانی ابزار، آینده‌ی مک هستند، یک تمایز حیاتی پدیدار می‌شود. ساخت عاملی که بتواند ابزارها را فراخوانی کند، کاری ساده است (یک کار روزمره یا Tuesday است). بخش دشوار، ساخت عاملی است که گزارش‌هایش از آن فراخوانی‌ها «کالیبره» شده باشد. این چالش‌ها نشان می‌دهد که برای استقرار عملیاتی، نیاز به استانداردهای جدیدی است؛ مشابه آنچه در پروتکل‌های جدید برای افزودن قابلیت‌های تولیدی به سیستم‌های عامل AI بررسی شده است تا تعاملات بین‌عاملی دقیق‌تر شود.

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

گام بعدی شما

• اگر از عامل‌های هوش مصنوعی برای تغییر داده‌ها در سیستم‌های سازمانی استفاده می‌کنید، هرگز به پیام «شکست» مدل اعتماد نکنید و وضعیت را مستقیماً در نرم‌افزار چک کنید.
• در طراحی سیستم‌های عامل‌محور، برای لایه‌های ایمنی (Guardrails) انعطاف‌پذیری در فرمت (Formatting Tolerance) ایجاد کنید تا پاسخ‌های درست به دلیل خطاهای ظاهری رد نشوند.
• بودجه‌ی نوبت‌های استنتاج را به‌جای عدد ثابت، بر اساس پیشرفت واقعی عامل (Progress-based Budget) تنظیم کنید.

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