حالت‌های شکست سیستم‌های چندایجنت: چارچوب MAST، تفکر گروهی و خطاهای آبشاری

در سیستم‌های مبتنی بر چند ایجنت، اضافه کردن ایجنت‌های بیشتر لزوماً به بالا رفتن دقت منجر نمی‌شود. بر اساس پژوهش‌های منتشرشده در کنفرانس NeurIPS 2025، این سیستم‌ها در سناریوهای واقعی نرخ شکستی بین 41 تا 86.7 درصد دارند؛ شکست‌هایی که تصادفی نیستند و ریشه‌های ساختاری مشخصی در تعریف وظایف، هماهنگی و اعتبارسنجی دارند.

در معماری مدرن نرم‌افزار، حالت‌های شکست سیستم‌های چندایجنت (Failure Modes) را باید درست مانند متغیرهای اصلی طراحی در نظر گرفت. این درس با معرفی رده‌بندی استاندارد MAST و زیرمجموعه‌ی تفکر گروهی (Groupthink)، ریشه‌های ناکامی ایجنت‌ها را تحلیل می‌کند و ابزارهایی مانند الگوی مدارشکن (Circuit Breaker) و چارچوب STRATUS را برای مهار این خطاها در محیط عملیاتی به کار می‌گیرد.

رده‌بندی مرجع برای سال 2026، چارچوب MAST است (Cemri et al., NeurIPS 2025, arXiv:2503.13657) که از بررسی 1642 ردگیری محاسبات اجرایی در 7 سیستم چندایجنت پیشرفته‌ی متن‌باز به دست آمده و نرخ شکست 41 تا 86.7 درصدی را نشان می‌دهد. سه دسته‌ی ریشه‌ای عبارت‌اند از: مشکلات مشخصات (Specification Problems با 41.77 درصد) — ابهام در نقش، تعریف مبهم وظیفه؛ شکست‌های هماهنگی (Coordination Failures با 36.94 درصد) — اختلال در ارتباطات، ناهماهنگی وضعیت؛ شکاف‌های اعتبارسنجی (Verification Gaps با 21.30 درصد) — نبود اعتبارسنجی، غیبت بررسی‌های کیفی. خانواده‌ی تفکر گروهی (Groupthink با شناسه‌ی arXiv:2508.05687) موارد زیر را به این لیست می‌افزاید: فروپاشی تک‌کشت یا همگنی مدلی (monoculture collapse؛ مدل پایه‌ی یکسان ← خطاهای همبسته)، سوگیری همرنگی با جماعت (conformity bias؛ ایجنت‌ها خطاهای یکدیگر را تقویت می‌کنند)، نقص در نظریه‌ی ذهن، پویایی‌های ناشی از انگیزه‌های متناقض، و خطاهای آبشاری در پایایی سیستم. نمونه‌ای از خطای آبشاری: طوفان‌های تلاش مجدد (retry storms) که در آن شکست در پرداخت بانکی باعث تلاش مجدد در ثبت سفارش می‌شود، این موضوع تلاش مجدد در موجودی انبار را کلید می‌زند و در نهایت سرویس انبارداری زیر بار می‌رود (10 برابر شدن بار در عرض چند ثانیه — نیازمند مدارشکن). مسموم‌سازی حافظه: توهم یک ایجنت وارد حافظه‌ی مشترک می‌شود، ایجنت‌های پایین‌دست آن را به‌عنوان فکت قطعی در نظر می‌گیرند؛ دقت به‌مرور افت می‌کند و ریشه‌یابی مشکل بسیار دردسرساز می‌شود. چارچوب STRATUS (کنفرانس NeurIPS 2025) گزارش می‌دهد که استفاده از ایجنت‌های تخصصی در بخش‌های تشخیص، عیب‌یابی و اعتبارسنجی، موفقیت در مهار خطا را تا 1.5 برابر بهبود می‌دهد. در این درس، به حالت‌های شکست به‌عنوان اهداف مهندسی درجه‌یک نگاه می‌کنیم.

صورت مسئله

سیستم‌های چندایجنت در کارهای واقعی، 41 تا 86.7 درصد مواقع با شکست مواجه می‌شوند (Cemri و همکاران در سال 2025 این موضوع را روی 7 سیستم چندایجنت متن‌باز اندازه‌گیری کردند). این مشکل را نمی‌توان صرفاً با گفتن «چند ایجنت دیگر اضافه کن» دیباگ کرد؛ این شکست‌ها ریشه‌های ساختاری دارند. رده‌بندی MAST دسته‌بندی‌ها را در اختیارتان می‌گذارد. در این درس، هر دسته را به یک الگوی مشخص برای تشخیص، عیب‌یابی و مهار خطا متصل می‌کنیم تا این اعداد دیگر تصادفی و مبهم به نظر نرسند.

رویکرد مهندسی در محیط عملیاتی (پروداکشن) سال 2026 این است که حالت‌های شکست را به‌عنوان ورودی‌های طراحی در نظر بگیرید. معماری شما زمانی «به‌اندازه‌ی کافی خوب» است که بتوانید به تک‌تک دسته‌های MAST اشاره کنید و راهکار مهاری را که برای آن پیاده کرده‌اید نام ببرید.

مفاهیم پایه

دسته‌بندی‌های MAST

مشکلات مشخصات (41.77 درصد از شکست‌ها): وظیفه‌ی ایجنت به‌اندازه‌ی کافی دقیق تعریف نشده است. مثال‌ها:

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

راهکارهای مهار:

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

شکست‌های هماهنگی (36.94 درصد): اختلال در ارتباطات یا ناهماهنگی در وضعیت.

مثال‌ها:

• دو ایجنت وضعیت مشترک را بدون همگام‌سازی به‌روزرسانی می‌کنند.
• پیامی میان ایجنت‌ها گم می‌شود (شکست صف پیام، اتمام مهلت زمانی یا تایم‌اوت).
• انحراف وضعیت (State drift): ایجنت A فکر می‌کند کار تمام شده؛ ایجنت B هنوز مشغول اجراست.

راهکارهای مهار:

• وضعیت مشترک نسخه‌بندی‌شده با همزمانی خوش‌بینانه (optimistic concurrency).
• تأییدیه‌ی صریح (Ack) برای پیام‌های حیاتی (تلاش مجدد تا زمان دریافت تأییدیه).
• چک‌پوینت‌های دوره‌ای برای همگام‌سازی وضعیت؛ تشخیص زودهنگام انحراف وضعیت.

شکاف‌های اعتبارسنجی (21.30 درصد): نبود بررسی مستقل روی خروجی‌ها.

مثال‌ها:

• یک ایجنت ادعای موفقیت می‌کند؛ هیچ بخشی خروجی را بررسی نمی‌کند.
• زنجیره‌ای از ایجنت‌ها که هر کدام به خروجی ایجنت پیشین اعتماد می‌کنند.
• نبود پوشش تست روی رفتارهای ترکیبی نوظهور (emergent behaviors).

راهکارهای مهار:

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

خانواده‌ی تفکر گروهی (arXiv:2508.05687)

پنج شکست مرتبط با یکدیگر، زمانی رخ می‌دهند که رفتار ایجنت‌ها همگن شود یا از هم تقلید کنند:

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

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

نقص در نظریه‌ی ذهن (ToM): ایجنت‌ها نمی‌توانند باورها و فرضیات یکدیگر را مدل‌سازی کنند؛ در نتیجه هماهنگی از هم می‌پاشد (درس 18).

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

خطاهای آبشاری در پایایی سیستم: الگوی خطای یک بخش، الگوهای خطا را در بخش‌های وابسته فعال می‌کند.

نمونه‌ای از خطای آبشاری — طوفان تلاش مجدد

یک الگوی رخداد پرتکرار و کلاسیک در سال 2026:

payment service fails 10% of requests
   ↓
order agent retries payment (exponential backoff but naive)
   ↓
each retry is a new order-inventory check
   ↓
inventory service sees 2x normal load
   ↓
inventory service starts timing out
   ↓
every order retries inventory check
   ↓
inventory service sees 10x normal load
   ↓
cluster goes down

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

مدارشکن جزو معدود الگوهای مهار شکست در سیستم‌های چندایجنت است که می‌توانید آن را مستقیماً و بدون هیچ تغییری از سیستم‌های توزیع‌شده قرض بگیرید.

مسموم‌سازی حافظه (مرور دوباره)

از درس 13 به یاد داریم: توهم یک ایجنت وارد حافظه‌ی مشترک می‌شود و به یک فکت تبدیل می‌گردد؛ ایجنت‌های پایین‌دست استدلال‌های بعدی‌شان را بر پایه‌ی همین داده‌ی مسموم می‌سازند. با واژگان MAST، این یک شکاف اعتبارسنجی در لایه‌ی حافظه‌ی مشترک به شمار می‌رود.

نشانه‌ی اصلی این مشکل، افت تدریجی دقت است. خبری از کرش کردن سیستم نیست؛ بلکه با یک انحراف نرم و تدریجی روبه‌رو می‌شوید که ریشه‌یابی‌اش به‌شدت طاقت‌فرساست.

راهکار مهار: لاگ فقط‌افزودنی (append-only)، ثبت منشأ و سندیت، و مدل اعتبارسنج بدون دسترسی نوشتن؛ مواردی که به‌طور کامل در درس 13 بررسی کردیم.

چارچوب STRATUS — ایجنت‌های تخصصی برای تشخیص خطا

پژوهش STRATUS (در NeurIPS 2025) نشان می‌دهد که اگر سه ایجنت زیر را مستقر کنید، نرخ موفقیت در مهار خطا 1.5 برابر بهتر می‌شود:

• ایجنت تشخیص (Detection): الگوهای نشانه‌ای را رصد می‌کند (اختلاف‌نظر بالا، پرش ناگهانی تعداد تلاش‌های مجدد، افت تدریجی دقت).
• ایجنت عیب‌یابی (Diagnosis): با داشتن نشانه‌ها، ریشه‌ی احتمالی خطا را بر اساس رده‌بندی MAST استنتاج می‌کند.
• ایجنت اعتبارسنجی (Validation): پس از اعمال راهکار مهار، بررسی می‌کند که آیا نشانه‌های خطا برطرف شده‌اند یا خیر.

این رویکرد، در واقع متدولوژی پاسخ به رخداد در مهندسی پایایی سایت (SRE) است که روی سیستم‌های چندایجنت پیاده‌سازی شده است. هر سه نقش می‌توانند ایجنت‌های LLM با پرامپت‌های تخصصی باشند.

ممیزی حالت‌های شکست

یکی از بهترین شیوه‌های کاری در سال 2026، ممیزی فصلی (و به ازای هر نسخه‌ی اصلی) حالت‌های شکست است:

1. نمونه‌گیری از ردگیری‌ها: حدود 1000 ردگیری محاسبات اجرایی واقعی را گردآوری کنید.
2. دسته‌بندی: خطاهای هر ردگیری را بر اساس دسته‌های MAST و تفکر گروهی نگاشت کنید.
3. محاسبه‌ی نرخ شکست به تفکیک دسته: کدام دسته‌ها در سیستم شما دست بالا را دارند؟
4. رتبه‌بندی راهکارهای مهار: رفع کدام مشکل بیشترین حجم شکست‌ها را از بین می‌برد؟
5. انتخاب 2 تا 3 راهکار مهار: آن‌ها را پیاده‌سازی کنید و در فصل بعد ممیزی را دوباره تکرار کنید.

نظم و استمرار در این فرایند، از جزئیات راهکارها مهم‌تر است. بدون ممیزی، خطاها در هیاهوی سیستم گم می‌شوند و هرگز به شکل سیستماتیک حل نخواهند شد.

شکست‌های خاموش سیستم

خطرناک‌ترین دسته‌ی شکست، شکست خاموش در درستی عملکرد (correctness) است. سیستمی که با سروصدا می‌شکند (کرش، خطا، هشدار)، به‌راحتی پایش می‌شود. اما سیستمی که خروجی‌های به‌ظاهر درست ولی کاملاً اشتباه تولید می‌کند، با لاگ‌های خطا قابل شناسایی نیست. به همین دلیل است که شکاف‌های اعتبارسنجی با وجود اینکه تنها 21.30 درصد از کل آمار خطاها را تشکیل می‌دهند، پرهزینه‌ترین نوع شکست به ازای هر رخداد به حساب می‌آیند.

برای این بخش سرمایه‌گذاری کنید روی:

• بررسی‌های انسانی مبتنی بر نمونه‌گیری؛
• تست‌های رگرسیون بر پایه‌ی مجموعه‌داده‌های مرجع (Golden datasets)؛
• بررسی متقابل خروجی‌های مهم میان چند ایجنت.

شکست آنی در برابر شکست تدریجی

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

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

پیاده‌سازی عملی

فایل code/main.py موارد زیر را پیاده‌سازی می‌کند:

• FailureTaxonomy — رخدادهای شبیه‌سازی‌شده را به دسته‌های MAST و تفکر گروهی نگاشت می‌کند.
• CircuitBreaker — الگوی کلاسیک که با فراتر رفتن نرخ خطا از آستانه، مدار را باز می‌کند.
• RetryStormSimulator — خطای آبشاری را نشان می‌دهد و مدارشکن را فعال یا غیرفعال می‌کند.
• DetectionAgent — یک الگوی اسکریپت‌نویسی‌شده به سبک STRATUS برای تطبیق نشانه‌ها.

اجرا:

python3 code/main.py

خروجی مورد انتظار:

• طوفان تلاش مجدد بدون مدارشکن: خطاهای بخش موجودی انبار منفجر می‌شوند (شبیه‌سازی‌شده).
• با مدارشکن: محدود شدن خطا در سقف آستانه؛ ارائه‌ی پاسخ‌ها در حالت افت قابلیت یا تنزل‌یافته (degraded-mode).
• ایجنت تشخیص، الگو را شناسایی می‌کند و دسته‌ی MAST آن را گزارش می‌دهد.

کاربرد در عمل

فایل outputs/skill-mast-auditor.md یک ممیزی حالت‌های شکست مبتنی بر MAST را روی یک سیستم چندایجنت اجرا می‌کند: ردگیری‌ها ← دسته‌بندی ← رتبه‌بندی راهکارهای مهار.

استقرار در پروداکشن

انضباط در مدیریت حالت‌های شکست در محیط عملیاتی:

• ممیزی MAST به‌صورت فصلی: نه سالانه؛ با رشد سیستم، دسته‌بندی خطاها هم جابه‌جا می‌شوند.
• مدارشکن در همه‌جا: روی هر فراخوانی خروجی به هر سرویس وابسته. آستانه‌ی باز شدن پیش‌فرض را روی نرخ خطای 5 تا 10 درصدی تنظیم کنید.
• مجموعه‌داده‌های مرجع: کوچک، باکیفیت و ممیزی‌شده با دست. تست‌های رگرسیون را هفتگی روی این داده‌ها اجرا کنید.
• سه‌گانه‌ی STRATUS: ایجنت‌های تشخیص، عیب‌یابی و اعتبارسنجی را برای مانیتورینگ پروداکشن به کار بگیرید. کار را فقط با ایجنت تشخیص آغاز کنید و هر زمان نشانه‌ها شلوغ و پرنویز شدند، عیب‌یابی را به آن بیفزایید.
• بودجه‌ی شکست: یک SLO صریح برای نرخ شکست به تفکیک هر دسته تعریف کنید. عبور از این بودجه باید انتشار نسخه‌های جدید را متوقف کند.

تمرین‌ها

1. اسکریپت code/main.py را اجرا کنید. بررسی کنید که مدارشکن چگونه جلوی طوفان تلاش مجدد را می‌گیرد. آستانه‌ی خطا را تغییر دهید و موازنه‌ی حاصل (tradeoff) را بررسی کنید.
2. یک شاخص تقریبی برای شکست تدریجی پیاده کنید: نرخ توافق میان 3 ایجنت موازی. هر زمان این نرخ افت شدیدی داشت، یک هشدار صادر کنید. با همبسته کردن تدریجی خروجی‌های ایجنت، انحراف تک‌کشت را شبیه‌سازی کنید.
3. مقاله‌ی Cemri و همکاران (arXiv:2503.13657) را بخوانید. یکی از 7 سیستم چندایجنت آن‌ها را انتخاب کرده و 3 دسته‌ی اصلی خطای آن را استخراج کنید. این موارد چه ارتباطی با پیش‌بینی‌های مدل کلی MAST دارند؟
4. مقاله‌ی تفکر گروهی (arXiv:2508.05687) را مطالعه کنید. مشخص کنید کدام‌یک از این پنج الگو در محیط عملیاتی سخت‌تر از بقیه تشخیص داده می‌شود؟ یک متریک تقریبی برای مانیتور آن پیشنهاد دهید.
5. یک سه‌گانه‌ی تشخیص، عیب‌یابی و اعتبارسنجی به سبک STRATUS برای یک سیستم چندایجنت که می‌شناسید طراحی کنید. ایجنت تشخیص دنبال چه نشانه‌هایی می‌گردد؟ ایجنت عیب‌یابی چه راهکارهایی را پیشنهاد می‌دهد؟ ایجنت اعتبارسنجی چطور کارکرد درست آن‌ها را تأیید می‌کند؟

اصطلاحات کلیدی

برای مطالعه‌ی بیشتر

• Cemri et al. — Why Do Multi-Agent LLM Systems Fail? — رده‌بندی MAST، کنفرانس NeurIPS 2025
• Groupthink failures in multi-agent LLMs — همگنی مدلی، همرنگی با جماعت و رده‌بندی پنج‌گانه‌ی خانواده‌ی تفکر گروهی
• STRATUS — specialized agents for MAS incident response — مقاله‌ی کنفرانس NeurIPS 2025 (تشخیص + عیب‌یابی + اعتبارسنجی)
• Release It! — stability patterns (Nygard) — مرجع کلاسیک و استاندارد برای الگوی مدارشکن
• Anthropic — Multi-agent research system — نکات و تجربیات عملی پیرامون حالت‌های شکست در محیط عملیاتی