چرا سیستم‌های چندایجنتی شکست می‌خورند؟

خلاصه‌ی مدیریتی

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

• داده‌ی پایه. تحلیل ۱٬۶۴۲ اجرای واقعی روی هفت فریم‌ورک مطرح، ۱۴ مود شکست تکرارشونده را در سه دسته شناسایی کرد، با توافق بین‌ارزیاب کاپای ۰٫۸۸.^۱
• ریشه‌ی شکست‌ها. ۴۴٫۲٪ از مسائل طراحی سیستم، ۳۲٫۳٪ از ناهم‌ترازی بین ایجنت‌ها و ۲۳٫۵٪ از ضعف تأیید و توقف. هیچ دسته‌ای غالب مطلق نیست — یعنی یک راه‌حل واحد وجود ندارد.
• عدد تکان‌دهنده. ChatDev روی محک ProgramDev در همان مطالعه ۳۳٫۳٪ موفقیت ثبت کرد. این عدد فقط در همان محک معنا دارد و با نتایج فریم‌ورک‌های دیگر روی محک‌های متفاوت قابل مقایسه‌ی مستقیم نیست.
• خبر خوب. اصلاح معماری با همان مدل‌ها بهبود ۹٫۴ تا ۱۵٫۶ درصدی داد. یعنی بخش بزرگی از مسئله با پول بیشتر برای مدل حل نمی‌شود، با طراحی بهتر حل می‌شود.
• چارچوب فکری. نظریه‌ی «سوانح عادی» چارلز پرو (۱۹۸۴) توضیح می‌دهد چرا: سیستمی که هم‌زمان پیچیدگی تعاملی و جفت‌شدگی تنگ دارد، شکست را به‌عنوان ویژگی ساختاری تولید می‌کند، نه به‌عنوان نقص.^۲
• هشدار ضدشهودی. پرو نشان داد افزودن لایه‌های ایمنی و افزونگی می‌تواند اوضاع را بدتر کند، چون خودش پیچیدگی اضافه می‌کند. رفلکس «یک ایجنت بازبین اضافه کنیم» دقیقاً همین تله است.

شکست، باگ نیست — ویژگی ساختاری است

دو محور تعریف پرو ساده‌اند:

• پیچیدگی تعاملی — اجزای سیستم به شیوه‌هایی روی هم اثر می‌گذارند که طراح پیش‌بینی نکرده بود. برهم‌کنش‌ها پنهان‌اند و در لحظه قابل فهم نیستند.
• جفت‌شدگی تنگ — بین اجزا لقی وجود ندارد. خروجی هر جزء بلافاصله ورودی جزء بعدی است، فرصتی برای مداخله یا اصلاح نیست.

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

چرا این تشخیص اهمیت عملی دارد

اگر شکست را باگ بدانید، دنبال «آن خطِ خراب» می‌گردید و وقتی پیدایش نمی‌کنید، مدل را عوض می‌کنید. اگر شکست را ساختاری بدانید، سراغ کاهش جفت‌شدگی و پیچیدگی تعاملی می‌روید — یعنی کاری که داده نشان می‌دهد جواب می‌دهد: اصلاح معماری با همان مدل‌ها، بهبود ۹٫۴ تا ۱۵٫۶ درصدی داد.^۱

مدل پنیر سوئیسی: چرا خطاها با هم جمع می‌شوند

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

نمونه‌ی واقعی از یک زنجیره‌ی چهار لایه‌ای:

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

۱۴ مود شکست، در سه دسته

سهم هر دسته از کل شکست‌های ثبت‌شده:

و پرتکرارترین مودهای منفرد، که روی هم ۵۳٫۱٪ از رخدادهای مودهای شکست را می‌سازند:

1. تکرار مرحله — ایجنت کاری را که انجام شده دوباره انجام می‌دهد۱۵٫۷٪
2. ناهم‌خوانی استدلال و کنش — درست فکر می‌کند، اشتباه عمل می‌کند۱۳٫۲٪
3. ناآگاهی از شرط توقف — ایجنت زمان پایان واقعی را تشخیص نمی‌دهد۱۲٫۴٪
4. نقض مشخصات وظیفه — یکی از قیدهای صریح کار نادیده گرفته می‌شود۱۱٫۸٪

نکته‌ی مهم: هیچ دسته‌ای غالب مطلق نیست. یعنی نمی‌توانید با یک اصلاح واحد — مثلاً بهتر کردن پرامپت‌ها — بیشتر مسئله را حل کنید. هر دسته راه‌حل ساختاری متفاوتی می‌خواهد.

دسته‌ی یک: مشخصات و طراحی سیستم

دسته‌ی دو: ناهم‌ترازی بین ایجنت‌ها

دسته‌ی سه: تأیید و توقف وظیفه

اصلاح همین دسته بیشترین بازده مستندشده را داشت: افزودن یک مرحله‌ی تأیید که به‌جای خروجی، هدف سطح‌بالای وظیفه را مبنا می‌گرفت، ۱۵٫۶٪ بهبود مطلق در نرخ موفقیت داد — بدون تغییر هیچ مدلی.^۱

پروفایل شکست هر معماری

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

الگوهای بحث‌محور، دسته‌ی خاص خودشان را دارند

اگر معماری شما بر پایه‌ی بحث یا رأی‌گیری بین ایجنت‌هاست، دو نکته‌ی مستقل از این طبقه‌بندی هم اهمیت دارد. اول اینکه افزایش تعداد راندهای بحث معمولاً عملکرد را پایین می‌آورد در حالی که افزایش تعداد ایجنت‌ها آن را بالا می‌برد^۱۱ — یعنی رفلکس رایج «یک راند دیگر اضافه کنیم» مستقیماً مود ۳٫۱ و مصرف بی‌ثمر توکن می‌سازد. دوم اینکه بخش عمده‌ی سود این معماری‌ها از رأی‌گیری می‌آید نه از خودِ بحث^۱۰، و پیکربندی‌شان به‌شدت به تنظیمات حساس است و بین مدل‌ها و مجموعه‌داده‌ها منتقل نمی‌شود.^۱۲

بررسی مستقلی روی نُه محک هم نشان داد افزایش بودجه‌ی محاسباتی در این معماری‌ها لزوماً به دقت بیشتر ترجمه نمی‌شود^۸ — پس اگر سیستم بحث‌محور شما کند و گران است ولی بهتر نمی‌شود، این رفتار پیش‌بینی‌شده است نه باگ. تحلیل کامل این خانواده در مقاله‌ی مناظره‌ی مدل‌ها آمده.

کِی باید تعمیر را متوقف کرد

• خط پایه‌ی تک‌ایجنتی هم‌سطح یا بهتر است. اگر یک ایجنت با پرامپت قوی و مثال‌های درون‌زمینه‌ای به همان عدد می‌رسد، پیچیدگی اضافه هیچ چیزی نمی‌خرد.^۹
• بیشتر شکست‌هایتان در دسته‌ی دو است. ناهم‌ترازی بین ایجنت‌ها فقط وقتی وجود دارد که چند ایجنت وجود داشته باشد. کاهش تعداد ایجنت‌ها، این دسته را مستقیماً کوچک می‌کند.
• هر اصلاح، مود جدیدی می‌سازد. این علامت کلاسیک پارادوکس افزونگی است: هر لایه‌ای که برای ایمنی اضافه می‌کنید، خودش سطح تعامل تازه‌ای می‌آورد.^۲
• زمان تشخیص علت از زمان توسعه بیشتر شده. وقتی فهمیدن اینکه چرا یک خروجی اشتباه بود، بیشتر از ساختن دوباره‌ی آن قابلیت طول می‌کشد، هزینه‌ی نگهداری از ارزش معماری گذشته است.

راهنمای عیب‌یابی: از نشانه به مود

پنج اصلاح ساختاری با بیشترین اثر

1. بازبینی را به هدف وصل کنید، نه به خروجیبازبین باید مشخصات اصلی وظیفه را ببیند و بپرسد «آیا این خواسته را برآورده می‌کند؟» — نه «آیا این متن منسجم است؟». پرسود‌ترین اصلاح مستندشده: ۱۵٫۶٪ بهبود مطلق.
2. مشخصات را در هر راند دوباره تزریق کنیدقیدها و هدف نباید فقط در پرامپت اولیه باشند. آن‌ها را در هر مرحله دوباره وارد زمینه کنید — این تنها راه مهار مود ۱٫۱ و ۲٫۳ است.
3. وضعیت را بیرون از گفت‌وگو نگه داریدیک دفترچه‌ی وضعیت ساختاریافته که مراحل انجام‌شده و تصمیم‌های گرفته‌شده را ثبت می‌کند. هم تکرار مرحله را مهار می‌کند (۱۵٫۷٪ از رخدادهای مود شکست) هم گم‌شدن تاریخچه را.
4. «پرسیدن» را خروجی معتبر تعریف کنیدتا وقتی توقف برای پرسش، شکست محسوب شود، ایجنت فرض می‌گیرد. یک مسیر رسمی برای برگرداندن سؤال به انسان یا به ایجنت بالادست بگذارید.
5. کنش اعلام‌شده را با کنش انجام‌شده مقایسه کنیدیک بررسی برنامه‌محور — نه مدل‌محور — که چک می‌کند ابزار فراخوانی‌شده با چیزی که ایجنت گفت می‌خواهد انجام دهد یکی است. مود ۲٫۶ را که ۱۴٪ شکست‌هاست مهار می‌کند.

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

مشاهده‌پذیری: چه چیزی را باید لاگ کنید

حداقل چیزی که باید در هر مرحله ثبت شود:

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

ستون آخر مهم‌ترین است و معمولاً غایب: اگر ندانید سیستم چرا ایستاد، نمی‌توانید بین «کار تمام شد» و «بودجه تمام شد» تفکیک کنید — و این دو نتیجه‌ی کاملاً متفاوتی برای کاربر دارند.

هفت اشتباه در رفع اشکال سیستم چندایجنتی

جمع‌بندی

بقیه‌ی این خوشه

پایه‌ها: مهندسی زمینه و مهندسی حلقه. پیاده‌سازی: ربات بله، ربات تلگرام، خدمات اتوماسیون و درباره فیلتور.

پرسش‌های پرتکرار

واژه‌نامه

سوانح عادیNormal Accidents

نظریه‌ی چارلز پرو: در سیستم‌های دارای پیچیدگی تعاملی و جفت‌شدگی تنگ، سوانح ویژگی ساختاری‌اند نه نقص.

پیچیدگی تعاملیInteractive Complexity

وقتی اجزای سیستم به شیوه‌هایی روی هم اثر می‌گذارند که طراح پیش‌بینی نکرده بود.

جفت‌شدگی تنگTight Coupling

نبود لقی بین اجزا؛ خروجی هر جزء بلافاصله ورودی بعدی است و فرصت مداخله نیست.

مدل پنیر سوئیسیSwiss Cheese Model

مدل جیمز ریزن: حادثه وقتی رخ می‌دهد که حفره‌های لایه‌های دفاعی متوالی روی یک خط قرار بگیرند.

تکرار مرحلهStep Repetition

انجام دوباره‌ی کاری که قبلاً انجام شده؛ پرتکرارترین مود شکست با ۱۵٫۷٪.

کتمان اطلاعاتInformation Withholding

ایجنتی اطلاعاتی دارد که دیگری لازم دارد ولی چون پرسیده نشده منتقلش نمی‌کند.

ناهم‌خوانی استدلال و کنشReasoning-Action Mismatch

ایجنت درست استدلال می‌کند و بعد کاری متفاوت انجام می‌دهد.

انحراف وظیفهTask Derailment

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

تأیید نادرستIncorrect Verification

بررسی با معیار اشتباه؛ خطرناک‌ترین حالت چون اعتماد کاذب می‌سازد.

شرط توقف مرکبComposite Halt Condition

ترکیب سقف مرحله، محدودیت زمان، تشخیص گیر افتادن و سقف بودجه — هر چهار مورد با هم.

نرخ موفقیت مکرر

احتمال اینکه سیستم همان وظیفه را در چند اجرای مستقل هر بار درست انجام دهد.

منابع

اعداد این مقاله از مقاله‌ی داوری‌شده‌ی مرجع این حوزه و مراجع کلاسیک ایمنی سیستم گرفته شده‌اند. طبقه‌بندی ۱۴ مود عیناً از همان مقاله است.

1. Why Do Multi-Agent LLM Systems Fail? — طبقه‌بندی ۱۴ مود، ۱٬۶۴۲ ردِ اجرا روی ۷ فریم‌ورک، کاپای ۰٫۸۸، و آزمایش‌های مداخله.Cemri et al. — NeurIPS 2025داوری‌شده
2. Normal Accidents: Living with High-Risk Technologies — پیچیدگی تعاملی، جفت‌شدگی تنگ، و پارادوکس افزونگی.Charles Perrow, 1984مرجع
3. Swiss Cheese Model of Accident Causation — هم‌راستایی حفره‌های لایه‌های دفاعی.James Reason, 2000مرجع
4. How we built our multi-agent research system — درس‌های عملیاتی، مشاهده‌پذیری و مدیریت وضعیت.Anthropic Engineeringصنعتی
5. τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains — معیار موفقیت مکرر و افت آن با تکرار اجرا.Yao et al. — ICLR 2025داوری‌شده
6. Don't Build Multi-Agents — تصمیم‌های ضمنی متناقض و ضرورت اشتراک ردِ کامل.Walden Yan, Cognitionصنعتی
7. Context Rot: How Increasing Input Tokens Impacts LLM Performance — پشتوانه‌ی مود گم‌شدن تاریخچه.Chroma Researchپژوهش صنعتی
8. Multi-LLM-Agents Debate — Performance, Efficiency and Scaling Challenges — بودجه‌ی محاسباتی بیشتر لزوماً دقت بیشتر نمی‌آورد.ICLR 2025 Blogpostsداوری‌شده
9. Rethinking the Bounds of LLM Reasoning: Are Multi-Agent Discussions the Key? — ایجنت تکی با پرامپت قوی به‌عنوان خط پایه.2024arXiv
10. Debate or Vote: Which Yields Better Decisions in Multi-Agent LLMs? — چرا افزودن لایه‌ی بحث لزوماً کمک نمی‌کند.NeurIPS 2025 Spotlightداوری‌شده
11. Voting or Consensus? Decision-Making in Multi-Agent Discussions — ایجنت بیشتر بهتر، راند بیشتر بدتر.ACL 2025 Findingsداوری‌شده
12. Should we be going MAD? A Look at Multi-Agent Debate Strategies for LLMs — حساسیت شدید به تنظیمات و دشواری بهینه‌سازی.Smit et al. — ICML 2024داوری‌شده
13. Can LLM Agents Really Debate? — سرکوب اقلیت و نقش تنوع گروه.2025arXiv
14. Model Context Protocol — استاندارد اتصال ایجنت به ابزار و داده.مستندات رسمیاستاندارد
15. A2A Protocol Surpasses 150 Organizations — بلوغ لایه‌ی ارتباط بین ایجنت‌ها.Linux Foundation — آوریل ۲۰۲۶استاندارد
16. Failure Mode and Effects Analysis (FMEA) — روش کلاسیک تحلیل مودهای شکست که الگوی این طبقه‌بندی است.مرجع مهندسی قابلیت اطمینانمرجع