اگر اکنون در حال استقرار عامل‌های خودکار در محیط تولید هستید، باید بدانید که بزرگ‌ترین تهدید شما پیش‌بینی‌ناپذیری مدل نیست، بلکه سرعت انتشار باگ‌های قدیمی است. تصور کنید سیستمی دارید که به‌جای متوقف شدن در برابر یک خطا، آن خطا را با دقت ریاضی در تمام زیرساخت شما تکثیر می‌کند. در ژوئن ۲۰۲۶، در زمان بهره‌برداری کامل، سیستمی متشکل از مجموعه‌ای از عامل‌های خودکار که توسط ارکستراتوری به نام Lain مدیریت می‌شدند، با مجموعه‌ای از شکست‌های مهندسی «خسته‌کننده» مواجه شد. این‌ها توهمات مرموز هوش مصنوعی نبودند، بلکه باگ‌های کتابخانه‌ای مانند Race Conditionها و توکن‌های منقضی‌شده بودند که سریع‌تر از انسانی که بر آن‌ها نظارت می‌کرد، مقیاس یافتند.
به گزارش وب‌سایت dev.to که در ۱۲ جولای ۲۰۲۶ منتشر شد، بررسی گزارش تغییرات (Changelog) ماه ژوئن ۲۰۲۶ در محیط کاری Lain نشان می‌دهد که عامل‌ها همزمان هم علت ایجاد و هم علت رفع تک‌تک حوادث در فضای کاری بوده‌اند. در این گزارش هیچ اثری از «جادوی» هوش مصنوعی دیده نمی‌شود؛ هر ورودی در لیست تغییرات، یک باگ مهندسی استاندارد است: یک Race Condition، یک پیش‌فرض کدگذاری در ویندوز، یک مقدار تنظیمات (Config) با واحد اشتباه، یک توکن OAuth منقضی‌شده یا یک لینک گم‌شده در توضیحات یک ویدیو.
این محیط توسط KittyClaw مدیریت می‌شود؛ یک ارکستراتور متن‌باز مبتنی بر کانبان (Kanban) که در گیت‌هاب (github.com/Ekioo/KittyClaw) تحت لایسنس MIT در دسترس است و ده‌ها عامل تخصصی را هدایت می‌کند. چنین ساختارهای پیچیده‌ای از عامل‌های تخصصی، مشابه آنچه در طرح جامع جریان‌های کاری خودکار Arxitek مشاهده می‌کنیم، نیاز به مدیریت دقیق برای جلوگیری از هرج‌ومرج دارند. فضای کاری شامل بیش از بیست بورد، یک ارکستراتور و ناوگانی از عامل‌های تخصصی از جمله نویسندگان، کامیت‌کنندگان (Committers)، تسترهای QA و یک حقیقت-سنج (Fact-checker) اختصاصی برای هر پروژه است. در حالی که صنعت اغلب بر «جادوی» مدل‌های زبانی بزرگ (LLMs) تمرکز می‌کند، این لاگ‌های تولیدی به عنوان یک یادآوری هوشیارانه عمل می‌کنند که جریان‌های کاری عامل‌محور (Agentic Workflows) همچنان مقید به قوانین مهندسی نرم‌افزار سنتی هستند. تغییر اساسی در اینجا، گذار از مدیریت یک بات واحد به مدیریت یک سیستم توزیع‌شده است که در آن «رشته‌ها» (Threads) همان عامل‌های خودکار هستند.
انتقال به گزارش ماهانه (Monthly Digest)
در بیشتر ایام فصل بهار، سوابق مربوط به «چه چیزی شکست خورد و چه چیزی را تعمیر کردیم» به‌صورت جریانی از پست‌های «ساخت در ملاءعام» (Build-in-public) در شبکه X از طریق حساب @lainagent_ai نگهداری می‌شد. با این حال، این حساب به‌دلیل «رفتار خودکار» (Automated Behavior) علامت‌گذاری (Flag) شد و پست‌ها بازدید خود را از دست دادند. ارکستراتور (Lain) هویت خود را به‌عنوان یک AI اعلام کرده بود و این صداقت توسط تشخیص‌دهنده بات‌ها به‌عنوان «گناه» تفسیر شد.
برای جلوگیری از این است که این مجموعه از لاگ‌های ساخت با مهر زمانی (Timestamp) در یک حساب نامرئی بپوسند، آن‌ها به یک گزارش ماهانه بادوام تبدیل شدند. شماره اول این گزارش مربوط به ژوئن ۲۰۲۶ است و هر حادثه در آن قابل ردیابی به یک تیکت مشخص در بورد و یک پست اصلی در روز وقوع باگ است. فرمت هر داستان ثابت باقی مانده است: چه چیزی شکست خورد، علت ریشه‌ای چه بود، راه حل چه بود و درس قابل انتقال چیست.
کالبدشکافی شکست‌های خاموش
یکی از بحرانی‌ترین شکست‌ها بین ۱۷ تا ۱۹ ژوئن ۲۰۲۶ در پروژه devto-publisher رخ داد؛ همان خط لوله‌ای (Pipeline) که در حال حاضر این مقاله را ارسال می‌کند. عامل‌ها شروع کردند به بازپخش وظایفی که پیش‌تر «انجام شده» (Done) علامت خورده بودند و یک حلقه تکرار (Resume Loop) بی‌امان ایجاد کردند. یک تیکت تمام شده در ستون Terminal قرار می‌گرفت، اما دقایقی بعد، عاملی دوباره آن را اجرا می‌کرد.
در ابتدا یک وصله (Patch) اولیه اعمال شد و علامت ظاهری مشکل به‌طور موقت ناپدید شد. با این حال، این یک نشانه هشداردهنده بود زیرا وصله اول فقط به «ظاهر» حلقه پرداخته بود و نه «علت» وقوع آن. علت ریشه‌ای واقعی در SessionRegistry پیدا شد؛ جایی که وضعیت مشترک برای ردیابی نشست‌های زنده عامل‌ها ذخیره می‌شد. این ثبت‌کننده از یک توالی غیر-اتمیک «بارگذاری-تغییر-ذخیره» (load-modify-save) استفاده می‌کرد: خواندن رجیستری، تغییر یک فیلد و نوشتن مجدد آن. وقتی دو عامل در زمان‌های هم‌پوشان به این توالی دسترسی پیدا می‌کردند، وضعیت روی دیسک برای یک بازه زمانی کوتاه ناقص به نظر می‌رسید. یکی از عامل‌ها این وضعیت نیمه‌نوشتار را می‌خواند، نتیجه می‌گرفت که نشست تمام نشده است و دوباره آن را اجرا می‌کرد. این یک نمونه کلاسیک از Race Condition در عملیات Read-Modify-Write بود که در سیستم‌های چندرشته‌ای (Multi-threaded) رایج است.
در ۱۹ ژوئن، یک باگ متفاوت اما به همان اندازه خاموش، دو پروژه مجزا را به‌طور همزمان هدف قرار داد. فایل‌های JSON که برای هفته‌ها به‌درستی جابه‌جا شده بودند، شروع به تخریب نویسه‌های دارای اکسان فرانسوی (مانند é، è و à) کردند. هیچ هشدار یا استثنایی (Exception) وجود نداشت؛ هر عملیات نوشتن در لاگ‌ها «موفق» اعلام شد، اما داده‌ها به‌هم‌ریخته بودند.
جزئیات فنی: تله کدگذاری ویندوز
- علت ریشه‌ای: در محیط Node.js، متد
fs.writeFileدر سیستم‌عامل ویندوز به‌طور پیش‌فرض از UTF-8 استفاده نمی‌کند. در عوض، به کد-صفحه (Code Page) سیستم بازمی‌گردد که در این مورد خاص cp1252 بود. - نتیجه: رشته‌های حاوی نویسه‌های اکسان در cp1252 نوشته می‌شدند اما هنگام بازخوانی با UTF-8 خوانده می‌شدند. این امر باعث ایجاد متون نامفهوم یا توالی‌های بایتی متغیری می‌شد که در چندین بار رفت‌وبرگشت داده‌ها، به‌صورت خاموش تخریب می‌شدند.
- راه حل: عامل‌ها مجبور شدند در هر نقطه از فراخوانی (Call Site)، صراحتاً عبارت
{ encoding: 'utf8' }را پاس دهند. - مقایسه کد:
- اشتباه:
fs.writeFile(path, JSON.stringify(data));(در ویندوز به‌صورت خاموش cp1252 است). - درست:
fs.writeFile(path, JSON.stringify(data), { encoding: 'utf8' });(همواره UTF-8).
- اشتباه:
ارکستراتور به‌عنوان یک بردار انتشار
خطاهای پیکربندی نیز به‌دلیل ماهیت حافظه عامل‌ها به‌شکلی غیرمنتظره مقیاس یافتند. ارکستراتور Lain به‌اشتباه یک رشته با فرمت cron (برای زمان‌بندی) را به‌جای یک عدد ساده از ثانیه‌ها به‌خاطر سپرد. موتور KittyClaw برای محرک‌های بازه‌ای (Interval Triggers) — که هر N ثانیه یک عامل را برای بررسی بورد فعال می‌کنند — به یک عدد ساده نیاز دارد. چون موتور نتوانست مقدار فرمت cron را تحلیل (Parse) کند، هیچ چیزی را زمان‌بندی نکرد. در نتیجه، اتوماسیون‌ها در چندین پروژه، از جمله پروژه ekioo، به‌سادگی متوقف شدند. هیچ خطا و هیچ لاگی وجود نداشت؛ اتوماسیون فقط هرگز شروع نشد.
از آنجا که Lain عاملی است که مسئول «هماهنگ‌سازی» (Harmonizing) تنظیمات بین پروژه‌هاست، به‌عنوان یک کانال توزیع برای این باگ عمل کرد. این بردار انتشار به این معنا بود که یک باور غلط در حافظه ارکستراتور، با بازدهی کامل در سه بورد مختلف نوشته شد. رفع این مشکل مستلزم اصلاح مقدار به ثانیه در هر بورد آسیب‌دیده بود (یک خط کد برای هر پروژه).
سایر شکاف‌های عملیاتی تولید
- شکست‌های احراز هویت (Auth Failures): در ۲۵ ژوئن، خط لوله انتشار یوتیوب برای bloomii (یک پروژه جانبی اخبار آرام) ساکت شد. علت ریشه‌ای یک انقضای ساده توکن OAuth بود. چون توکن‌های منقضی‌شده هیچ پیام خداحافظی یا خطای خاصی نمی‌فرستند و سیستم «خطای احراز هویت» را به‌عنوان محرکی برای خبر دادن به انسان (Page a human) نمی‌شناخت، خط لوله به سکوت مطلق رسید. یک احراز هویت دستی پس از ایجاد یک تیکت فوری (URGENT) در جریان یک حسابرسی زمان‌بندی‌شده مورد نیاز بود.
- خطاهای پارامتری: در ۲۶ ژوئن، یک پروژه ویدیوهای کوتاه، بخشی را با نورپردازی شدید و ناخواسته (Chiaroscuro) تولید کرد. این یک توهم AI نبود. پارامتر
ref_image— فریم مرجعی که مدل بر اساس آن شرایط را تنظیم می‌کند — به فریم اشتباهی اشاره می‌کرد. چون آن فریم خاص تاریک و غم‌آلود بود، آن نورپردازی به رندر منتقل شد و به بخش‌های بعدی نشت کرد. مدل دقیقاً همان کاری را کرد که به او گفته شده بود؛ فقط دستور اشتباهی دریافت کرده بود. - شکاف‌های تبدیل (Conversion Gaps): یک کانال یوتیوب که توسط عامل‌ها اداره می‌شد، تقریباً ۱۵,۰۰۰ بازدید برای محتوای bloomii جذب کرد، اما این منجر به تنها یک بازدید از سایت شد. عامل‌ها به‌شدت روی معیاری که به آن‌ها داده شده بود (تعداد بازدید) بهینه کرده بودند. با این حال، هیچ قیماً (Funnel) وجود نداشت: نه لینکی در توضیحات ویدیو، نه کامنت پین‌شده و نه هیچ دعوت به اقدامی (Call to Action). توزیع بدون قیماً منجر به یک عملیات بی‌اثر (No-op) با اعداد پوچ اما بالا شد.
نگهداری و تدابیر حفاظتی
فراتر از کرش‌های بزرگ، لاگ ماه ژوئن چندین «برد سریع» (Quick Wins) در مدیریت بدهی فنی را ثبت کرد که از طریق تیکت‌های تک‌مرحله‌ای مدیریت شدند:
- حفاظ‌های Bloomii: یک حفاظ
DELETEقبل از مرحله نظارت (Moderation) اضافه شد تا اطمینان حاصل شود که مسیرهای تخریبی مشروط به اجرای یک بررسی اولیه هستند. همچنین یک حفاظ تک‌خطی D1 پس از هفته‌ها نبودن، پیاده‌سازی شد. - هرس حافظه (Memory Pruning): ۱۳۲ خط از حافظه عامل تولید محتوای kalceo تلفیق و بهینه‌سازی شد. دلیل این کار آن است که عاملی که در هر بار اجرا، نویزهای انباشته‌شده (Accumulated Noise) خود را بازخوانی کند، به‌مرور زمان کندتر و کندذهن‌تر می‌شود. بنابراین، هرس حافظه به‌عنوان یک نگهداری ضروری، مشابه پاکسازی کدهای مرده (Dead Code)، در نظر گرفته می‌شود.
این حوادث دسته‌ای از باگ‌ها به نام «درستیِ خاموش» (Quiet Wrongness) را معرفی می‌کنند. برخلاف کرش‌هایی که هشدار فوری می‌دهند، این شکست‌ها — لغزش‌های کدگذاری، محرک‌های مرده و توکن‌های منقضی‌شده — در داشبوردها «موفق» به نظر می‌رسند. داشبوردها سبز می‌مانند زیرا سکوت و موفقیت از نظر بصری یکسان هستند تا زمانی که یک انسان به‌صورت دستی خروجی را بررسی کند.
اثر مرتبه دوم مقیاس عامل‌ها (Agent Scale)
این داده‌ها نشان می‌دهند که ریسک اصلی در AI عامل‌محور، پیش‌بینی‌ناپذیری مدل نیست، بلکه سرعت انتشار است. هر شکست در ژوئن یک باگ مهندسی کلاسیک بود: یک Race Condition در خواندن-تغییر-نوشتن، یک پیش‌فرض کدگذاری، عدم تطبیق واحدها، یک اعتبارنامه منقضی‌شده، یک پارامتر ورودی اشتباه یا یک مرحله تبدیل گم‌شده. هیچ‌کدام برای وقوع به AI نیاز نداشتند و هیچ‌کدام برای رفع شدن به AI نیاز نداشتند.
آنچه عامل‌ها اضافه کردند، مقیاس بود. وقتی عاملی با دسترسی نوشتن در چندین سیستم، در حین یک مرحله «پاکسازی» یا «هماهنگ‌سازی» اشتباه کند، آن اشتباه را با بازدهی کامل در کل زیرساخت پیاده می‌کند. همان اتوماسیونی که اصلاحات را سریع ارسال می‌کند، اشتباهات را نیز سریع ارسال می‌کند. برای توسعه‌دهندگان، این بدان معناست که «انسان در حلقه» (Human-in-the-loop) باید از تأیید محتوای نهایی به بازرسی همگام‌سازی حافظه و تنظیمات عامل‌ها تغییر مکان دهد.
مانیتورینگ سکوت
درس کلی از ماه ژوئن این است که ثبت خطاهای (Logging) سنتی برای عامل‌ها کافی نیست. چون عامل‌ها خسته نمی‌شوند و متوجه این نمی‌شوند که سیستمی «بیش از حد ساکت» شده است، اپراتور انسانی باید «سگ‌های نگهبان» (Watchdogs) را پیاده کند. استراتژی فعلی «اگر خراب شود متوجه می‌شویم» ناکافی است؛ اولویت جدید پیاده‌سازی نگهبانانی است که روی «سکوت» هشدار دهند — یعنی زمانی که آخرین انتشار موفقیت‌آمیز بیش از حد طولانی پیش را در rearview داشته باشد.
این نگهبان‌های تشخیص سکوت اکنون در صدر لیست کارهای (Backlog) ماه جولای قرار دارند. اگر شما در حال ساخت جریان‌های کاری عامل‌محور هستید، بررسی کنید که آیا استراتژی مانیتورینگ شما صرفاً بر خطاها تکیه دارد یا خیر. اگر چنین است، احتمالاً نسبت به گران‌ترین باگ‌های پشته (Stack) خود کور هستید؛ جایی که سیستم کرش نمی‌کند، بلکه به‌سادگی در انجام عمل شکست می‌خورد.
گام بعدی شما
- استراتژی مانیتورینگ خود را بررسی کنید: آیا فقط منتظر خطا (Error) هستید یا برای «عدم وقوع عمل» (Silence) نیز هشدار دارید؟
- حافظه عامل‌های خود را به‌صورت دوره‌ای هرس کنید تا از کاهش کیفیت پاسخ‌دهی (Intelligence Decay) جلوگیری شود.
- در تمام نقاط تماس با سیستم‌عامل (به‌ویژه در Node.js و ویندوز)، کدگذاری UTF-8 را صراحتاً تعریف کنید.
گفتگو