وقتی ایجنتهای هوش مصنوعی را به محیط عملیاتی میفرستید، متوجه میشوید که در اغلب موارد درست کار میکنند، اما در درصدی از اجراها با شکست مواجه میشوند. این شکستها معمولاً تصادفی نیستند؛ بلکه ریشه در الگوهای ساختاری تکرارشوندهای دارند که مدلهای زبانی در تعامل با ابزارها و گامهای متوالی استدلال ایجاد میکنند.
مشکل اصلی اینجاست که خطاهای ایجنتی بهندرت به شکل توقف ناگهانی برنامه (Crash) ظاهر میشوند. در بیشتر مواقع خروجی در ظاهر کاملاً معتبر و موجه به نظر میرسد، اما وضعیت واقعی سیستم دگرگون نشده یا عملیات نامربوطی انجام گرفته است. شناخت این دستهها به شما امکان میدهد سیستمهای پایش و گیتهای اعتبارسنجی را بهدرستی در پایپلاین تعبیه کنید.
در این درس با ردهبندی MASFT، دیدگاه مایکروسافت درباره تشدید خطاهای هوش مصنوعی در محیطهای ایجنتی و پنج الگوی پرکاربرد صنعتی آشنا میشوید و یک شناساگر سبک پایتونی برای برچسبگذاری ردگیری محاسبات پیاده میکنید.
چارچوب MASFT (برکلی، 2025) 14 حالت شکست سیستمهای چندایجنت را در 3 دسته طبقهبندی میکند. ردهبندی مایکروسافت نشان میدهد که چگونه شکستهای فعلی هوش مصنوعی در محیطهای ایجنتی تشدید میشوند. دادههای میدانی صنعت نیز روی پنج حالت تکرارشونده همگرا هستند: اقدامات متوهمانه، خزش دامنه، خطاهای آبشاری، از دست رفتن بافتار و سوءاستفاده از ابزار.
اهداف یادگیری
- نام بردن سه دستهی شکست در MASFT و حداقل چهار حالت مشخص در هر دسته.
- توضیح چرایی تشدید حالتهای شکست فعلی هوش مصنوعی (سوگیری، توهم) در سیستمهای ایجنتی.
- توصیف پنج حالت تکرارشونده در صنعت و راهکارهای کاهش اثر آنها.
- پیادهسازی یک شناساگر با کتابخانهی استاندارد پایتون (stdlib) برای برچسبگذاری ردگیری محاسبات ایجنت با برچسبهای حالت شکست.
مسئله
تیمها ایجنتهایی را روانهی محیط عملیاتی میکنند که در 90% از ردگیریهای محاسباتی درست کار میکنند. آن 10% شکست صرفاً نویز تصادفی نیست؛ بلکه در تعداد معدودی دستهی تکرارشونده جای میگیرد. بهمحض اینکه بتوانید نامی روی آنها بگذارید، امکان پایش و رفع آنها را خواهید داشت.
مفاهیم پایه
چارچوب MASFT (برکلی، arXiv:2503.13657)
ردهبندی شکست در سیستمهای چندایجنت (Multi-Agent System Failure Taxonomy). شامل 14 حالت شکست که در 3 دسته خوشهبندی شدهاند. شاخص کاپای کوهن میان ارزیابها (Inter-annotator Cohen's Kappa) برابر با 0.88 است؛ یعنی دستهها با اطمینان بالا از یکدیگر متمایزپذیرند.
ادعای محوری: شکستها ناشی از ایرادهای بنیادین در طراحی سیستمهای چندایجنت هستند، نه صرفاً محدودیتهای مدل زبانی بزرگ (LLM) که بشود با مدلهای پایهی بهتر رفعشان کرد.
ردهبندی مایکروسافت از حالتهای شکست در سیستمهای هوش مصنوعی ایجنتی
- شکستهای فعلی هوش مصنوعی (سوگیری، توهم، نشت داده) در محیطهای ایجنتی تشدید میشوند.
- با خودمختاری ایجنتها، شکستهای تازهای سر برمیآورند: اقدام ناخواسته در مقیاس وسیع، سوءاستفاده از ابزار، انحراف از مأموریت.
- این گزارش فنی (whitepaper) در واقع دفتر ثبت ریسک برای محصولات ایجنتی به شمار میرود.
مشخصهیابی خطاها در هوش مصنوعی ایجنتی (arXiv:2603.06847)
- شکستها از ارکستراسیون، تغییر تدریجی وضعیت درونی و تعامل با محیط ناشی میشوند.
- مسئله صرفاً «کد بد» یا «خروجی نامناسب مدل» نیست.
پیمایش توهمها در ایجنتهای مبتنی بر مدلهای زبانی بزرگ (arXiv:2509.18970)
دو نمود اصلی برای این پدیده وجود دارد:
- انحراف از دنبالکردن دستورالعمل (Instruction-following Deviation): ایجنت از پرامپت سیستم پیروی نمیکند.
- سوءاستفاده از بافتار در افق طولانی (Long-range Contextual Misuse): ایجنت بافتار نوبتهای گفتوگوی اولیه را فراموش میکند یا نادرست بهکار میبندد.
خطاهای زیرنیت (Sub-intention errors): از قلم افتادن گام (Omission)، تکرار بیجا (Redundancy)، بههمریختگی ترتیب گامها (Disorder).
پنج حالت تکرارشونده در صنعت
تحلیلهای میدانی Arize، Galileo و NimbleBrain بین سالهای 2024 تا 2026 روی این پنج مورد همگرا هستند:
- اقدامات متوهمانه (Hallucinated actions): ایجنت ابزاری را فراخوانی میکند که اصلاً وجود ندارد، یا آرگومانهای ساختگی سرهم میکند.
- خزش دامنه (Scope creep): ایجنت دامنهی کار را فراتر از خواستهی کاربر پیش میبرد (ایجاد PRهای اضافی، ارسال ایمیلهای ناخواسته).
- خطاهای آبشاری (Cascading errors): یک فراخوانی اشتباه روی گامهای بعدی اثر زنجیرهای میگذارد. توهمِ یک شناسهی کالای ناموجود (phantom SKU)، چهار فراخوانی API دیگر راه میاندازد؛ نتیجه: یک حادثهی چندسیستمی.
- از دست رفتن بافتار (Context loss): وظایف بلندمدت باعث میشوند محدودیتهای نوبتهای گفتوگوی اولیه از یاد بروند.
- سوءاستفاده از ابزار (Tool misuse): فراخوانی ابزار درست با آرگومانهای غلط، یا فراخوانی یک ابزار کاملاً نامربوط.
خطاهای آبشاری مهلکترین حالت شکست هستند. ایجنتها توانایی تفکیک بین «من نتوانستم» و «این کار نشدنی است» را ندارند؛ در نتیجه برای بستن چرخهی گفتوگو، اغلب پس از دریافت خطاهای 400 پیامی مبنی بر موفقیت جعل میکنند.
راهکار: دروازههای اعتبارسنجی در هر گام
استقرار دروازههای اعتبارسنجی خودکار در تمام مراحل زنجیرهی استدلال، بهطوری که ارجاعدهی مکانی به دادههای واقعی را در برابر وضعیت محیط بسنجند. در عمل:
- دستهبند ایمنی در هر گام (درس 21).
- اعتبارسنجی آرگومانهای فراخوانی ابزار (Tool call) (درس 06).
- بررسی تطبیقی محتوای بازیابیشده با دادههای واقعی شناختهشده (درس 05، CRITIC).
- شناسایی توهم موفقیت با بررسی مجدد وضعیت محیط (آیا فایل واقعاً ساخته شد؟).
اشتباهات رایج در پایش شکستها
- برچسبزدن صرف به خطاهای توقفدهنده (Crash): اغلب شکستهای ایجنت، خروجیهایی با ظاهر کاملاً معتبر تولید میکنند. باید بررسیها را در سطح محتوا انجام داد.
- نبود خط مبنا (Baseline): تشخیص تغییر تدریجی عملکرد به یک «آخرین وضعیت مطلوبِ شناختهشده» نیاز دارد؛ بدون آن نمیتوانید بگویید «اوضاع دارد بدتر میشود».
- هشداردهی افراطی: ارسال هشدار به ازای هر تکشکست، تیم را فرسوده میکند. هشدارها را خوشهبندی کنید و برایشان سقف نرخ بگذارید.
پیادهسازی
فایل code/main.py یک سیستم برچسبگذار حالتهای شکست را با کتابخانهی استاندارد پیادهسازی میکند:
- یک مجموعهدادهی ساختگی از ردگیری محاسبات که پنج حالت اصلی را پوشش میدهد.
- توابع شناساگر به ازای هر حالت شکست (الگوهای امضامانند در فراخوانی ابزارها، خروجیها و اقدامات تکراری).
- یک برچسبگذار که به هر ردگیری محاسبات برچسب میزند و توزیع آماری حالتها را گزارش میدهد.
اجرای آن:
python3 code/main.py
خروجی: برچسبهای تفکیکشده به ازای هر ردگیری محاسبات بههمراه توزیع کل؛ نسخهای ساده و ارزان از همان چیزی که خوشهبندی ردگیری محاسبات در Phoenix نمایش میدهد.
کاربرد در عمل
- Phoenix برای خوشهبندی تغییر تدریجی در محیط عملیاتی (درس 24).
- Langfuse برای بازپخش نشستها و یادداشتگذاری.
- راهحل سفارشی برای شناسایی الگوهای خاص دامنهی کاری شما که پلتفرم رصدپذیری عمومی متوجه آنها نمیشود.
آمادهسازی برای تحویل
فایل outputs/skill-failure-detector.md شناساگرهای حالتهای شکست را متناسب با دامنهی کاری شما میسازد و به مخزن ردگیری محاسبات متصل میکند.
تمرینها
- شناساگری برای «توهم موفقیت» اضافه کنید: حالتی که ایجنت اعلام موفقیت میکند، اما وضعیت سیستم هدف هیچ تغییری نکرده است.
- 100 ردگیری محاسبات واقعی از محصولی را که ساختهاید برچسب بزنید. کدام حالت شکست غالب است؟ هزینهی رفع آن چقدر خواهد بود؟
- معیاری برای «شعاع آبشاری» پیادهسازی کنید: اگر در گام N خطایی رخ دهد، روی چند گام بعدی اثر گذاشته است؟
- 14 حالت شکست چارچوب MASFT را مطالعه کنید. سه مورد مرتبط با محصول خود را برگزینید و برایشان شناساگر بنویسید.
- یکی از شناساگرها را به پایپلاین CI وصل کنید: اگر حداقل 5% از ردگیریهای محاسبات این برچسب شکست را گرفتند، فرایند بیلد را متوقف کنید.
اصطلاحات کلیدی
| اصطلاح | در گفتوگوهای عامیانه | معنای دقیق فنی |
|---|---|---|
| MASFT | «ردهبندی شکست چندایجنت» | دستهبندی 14 حالتهی دانشگاه برکلی |
| خطای آبشاری (Cascading error) | «خرابی زنجیرهای» | یک خطای اولیه در طول N گام بعدی منتشر میشود |
| از دست رفتن بافتار (Context loss) | «فراموشی محدودیتها» | نوبت گفتوگوی طولانی، دادههای نوبتهای اولیه را حذف میکند |
| سوءاستفاده از ابزار (Tool misuse) | «ابزار غلط / آرگومان غلط» | فراخوانی ابزار مجاز اما با اجرای نادرست |
| توهم موفقیت (Success hallucination) | «اعلام اتمام ساختگی» | ایجنت پس از خطای 400 ادعای موفقیت میکند؛ وضعیت سیستم تغییری نکرده است |
| خزش دامنه (Scope creep) | «دستاندازی فراتر از مرز» | ایجنت کاری فراتر از خواستهی کاربر انجام میدهد |
| انحراف از دنبالکردن دستورالعمل (Instruction-following deviation) | «نافرمانی» | نادیده گرفتن پرامپت سیستم یا محدودیتهای کاربر |
| خطاهای زیرنیت (Sub-intention errors) | «باگ در برنامه» | از قلم افتادن، تکرار بیجا یا نامرتب بودن گامها در اجرای طرح |
برای مطالعهی بیشتر
- Cemri et al., MASFT (arXiv:2503.13657) — 14 حالت شکست در 3 دسته
- Microsoft, Taxonomy of Failure Mode in Agentic AI Systems — دفتر ثبت ریسک
- Arize Phoenix — خوشهبندی تغییر تدریجی در عمل
- Anthropic, Building Effective Agents — چه زمانی الگوهای سادهتر بهکلی مانع بروز این حالتهای شکست میشوند
