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

تصور کنید سیستمی را مدیریت می‌کنید که سه هفته است هر ۵ دقیقه یک‌بار گزارش «موفقیت» می‌دهد، اما در واقعیت حتی یک تراکنش ساده را هم انجام نداده است. این کابوس برای یک توسعه‌دهنده مستقل که عملیات معاملاتی خود را به عامل‌های هوش مصنوعی سپرده بود، به واقعیت تبدیل شد. وضعیت «موفقیت» (Success) در Windows Task Scheduler برای سه هفته گزارش می‌شد، در حالی که فرآیند زیربنایی هوش مصنوعی در هر چرخه کرش می‌کرد. این شکست، یک نقطه کور خطرناک در قابلیت مشاهده (Observability) فعلی هوش مصنوعی را برجسته می‌کند: شکاف میان فرآیندی که صرفاً «اجرا می‌شود» و عاملی که واقعاً «به هدفش می‌رسد».

بسیاری از برنامه‌نویسان برای نظارت بر کارهای پس‌زمینه به کدهای خروجی (Exit Codes) یا سوئیچ‌های ایمنی (Dead-man's switches) تکیه می‌کنند. این ابزارها فقط پاسخ می‌دهند که آیا یک شغل زنده است یا خیر، اما نمی‌توانند تشخیص دهند که آیا آن شغل واقعاً در حال انجام عملکرد مورد نظر خود است یا نه. برای یک عامل (Agent) بدون نظارت انسانی — شبیه به کارمندی که پشت میز نشسته و حضورش ثبت شده اما هیچ کاری انجام نمی‌دهد — چراغ سبز وضعیت می‌تواند یک توهم کامل باشد.

همان‌طور که در بحث‌های گذشته ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد کورکورانه به خروجی‌های سیستمی در محیط‌های خودکار ریسک‌های بزرگی دارد. به گزارش منتشر شده در dev.to در ۲۳ اوت ۲۰۲۶، این توسعه‌دهنده که یک شرکت تک‌نفره را اداره می‌کند و از Claude Code برای نوشتن و نگهداری کدها استفاده می‌کند، با دو نوع شکست متمایز در ربات‌های معاملاتی خود مواجه شد. این ربات‌ها به‌صورت ۲۴ ساعته و هر ۵ دقیقه یک‌بار، API یک بروکر را بررسی (Poll) می‌کردند.

حادثه داده‌های قدیمی

اولین مورد، یک نسخه «ملایم» از خطای نظارتی بود. یکی از ربات‌ها دارای یک سیستم قطع‌کننده (Circuit Breaker) بود که طراحی شده بود تا در صورت عبور ضررهای مجازی (Paper Losses) از یک آستانه خاص، تمام پوزیشن‌ها را به‌اجبار ببندد و عملیات را متوقف کند.

در این مورد خاص، سیستم قطع‌کننده به‌درستی عمل کرد: ضررها از خط قرمز عبور کردند و پوزیشن بسته شد؛ موضوعی که از طریق API خودِ بروکر تأیید شد. با این حال، این بسته شدن هرگز در فایل تاریخچه معاملات (Trade History File) نوشته نشد.

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

مکانیزم «کرش خاموش»

حادثه دوم بسیار شدیدتر و خطرناک‌تر بود. رباتی برای بیش از سه هفته، هر ۵ دقیقه یک‌بار کد خروجی موفق (۰) ارسال می‌کرد. اما در واقعیت، ربات به‌دلیل یک خطای احراز هویت (Authentication Error) مدیریت‌نشده از سوی API بروکر، در هر چرخه شکست می‌خورد.

• نوع شکست: فرآیند داخلی پایتون در تقریباً هر چرخه کرش می‌کرد.
• توهم موفقیت: لایه بیرونی یا Wrapper فرآیند، خطا را می‌گرفت و با وظیفه‌شناسی گزارش می‌داد که خودِ Wrapper اجرا شده و خارج شده است، و بدین ترتیب سیگنال «موفقیت» را به زمان‌بند (Scheduler) ارسال می‌کرد.
• مقیاس خطا: در طول سه هفته با چرخه‌های ۵ دقیقه‌ای، بیش از ۸۰۰۰ تلاش صورت گرفت و بیش از ۱۸۰۰۰ خطای Traceback در فایل لاگ انباشته شد.
• نتیجه: در تمام این بازه زمانی، صفر معامله واقعی ثبت شد، اما دیدگاه زمان‌بند نسبت به جهان هرگز قرمز نشد.

این توسعه‌دهنده تنها با خواندن دستی فایل‌های لاگ خام متوجه فاجعه شد، زیرا هیچ سیستم نظارتی هشدار (Alert) را فعال نکرده بود. این وضعیت نمونه‌ای بارز از مکانیزم‌های خودترمیمی است که گاهی خطاهای حیاتی را پنهان می‌کنند و باعث ایجاد شکست‌های نامرئی در سیستم‌های هوش مصنوعی می‌شوند.

ابزارهای فعلی مشاهده‌پذیری LLM برای توسعه فعال طراحی شده‌اند — یعنی ردیابی تماس‌های API برای اینکه بفهمند چرا یک پرامپت هزینه زیادی داشت یا خروجی بی‌معنی داد — نه برای نظارت بر کارهای پس‌زمینه بدون نظارت. مانیتورهای سنتی Uptime فقط تأیید می‌کنند که فرآیند Wrapper در حال ارسال Ping است، که اگر عامل داخل Wrapper مرده باشد، این بررسی بی‌فایده است.

این یعنی برای توسعه‌دهندگان مستقل یا تیم‌های کوچک، استک فعلی هوش مصنوعی فاقد یک لایه نظارتی «معنایی» (Semantic) است. شما ممکن است نرخ پایداری ۱۰۰٪ را ببینید، در حالی که عامل شما ۲۰ روز است که در اجرای حتی یک معامله شکست خورده است. این تغییر در شکل شکست‌ها نشان می‌دهد که «پایداری» (Uptime) دیگر معیار مناسبی برای «عملکرد» (Performance) در جریان‌های کاری عامل‌محور نیست. صنعت به ابزارهایی نیاز دارد که تفاوت بین «خروج فرآیند با کد ۰» و «تکمیل موفقیت‌آمیز یک وظیفه ساختاریافته توسط عامل» را درک کنند.

برای حل این مشکل، این توسعه‌دهنده اکنون در حال ساخت یک لایه نظارتی آگاه به زمان‌بندی (Schedule-aware) به‌طور خاص برای عامل‌های بدون نظارت است. هدف این سیستم شناسایی شکاف بین سلامت فرآیند و تکمیل وظیفه است و می‌خواهد از چک‌های ساده مثل «HTTP 200» یا «exit 0» فراتر رود.

گام بعدی شما

• اگر ربات، اسکرپر یا خط لوله‌ای (Pipeline) را روی زمان‌بندی اجرا می‌کنید، همین امروز لاگ‌های خام (Raw Logs) را بررسی کنید و به چراغ‌های سبز داشبورد اعتماد نکنید.
• برای عامل‌های خود، معیاری تعریف کنید که «خروجی واقعی» (مثلاً ثبت یک تراکنش) را چک کند، نه فقط بسته شدن برنامه.
• از ابزارهای مانیتورینگ معنایی استفاده کنید که محتوای لاگ را برای یافتن الگوهای خطا تحلیل می‌کنند.

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