پاسخ کوتاه: سیستم چندایجنتی یعنی چند مدل زبانی که هر کدام نقش، ابزار و حافظه‌ی خود را دارند و برای حل یک مسئله با هم کار میکنند — گاهی با تقسیم کار، گاهی با مناظره، گاهی با مذاکره. این معماری در کارهای «پهنا-محور» و قابلموازیسازی برتری چشمگیر دارد، اما حدود ۱۵ برابر توکن مصرف میکند و در کارهای وابسته‌به‌هم معمولاً بدتر از یک ایجنت تکی عمل میکند.
خلاصه‌ی مدیریتی (TL;DR)
- چندایجنتی جادو نیست، یک مبادله (trade-off) است: پهنای جستجو و موازی‌سازی را می‌خرید، انسجام زمینه (context) و پول را می‌دهید.
- عدد کلیدی موافقان: Anthropic گزارش کرد معماری ارکستریتور-کارگر با Claude Opus 4 به‌عنوان سرپرست و Sonnet 4 به‌عنوان کارگر، ۹۰٫۲٪ بهتر از تک‌ایجنتِ Opus 4 عمل کرده — روی وظایف پژوهشی پهنا-محور.
- عدد کلیدی مخالفان: بررسی ۱٬۶۴۲ اجرای واقعی روی ۷ فریم‌ورک متن‌باز، نرخ شکست ۴۱ تا ۸۶٫۷ درصدی نشان داد — و ۴۴٪ این شکست‌ها از طراحی سیستم می‌آمد، نه از ضعف مدل.
- مناظرهی مدل‌ها (Debate) به‌تنهایی معجزه نمی‌کند: در مقایسه‌ی سیستماتیک، مناظره به‌طور قابل‌اتکا از روش‌های ساده‌تری مثل self-consistency بهتر نبود؛ فقط بسیار حساس‌تر به تنظیمات بود.
- قاعده‌ی عملی ۲۰۲۶: ایجنت بیشتر معمولاً بهتر است، راندِ گفت‌وگوی بیشتر معمولاً بدتر.
- پیش‌فرض درست: با یک ایجنت تکرشتهای شروع کنید. تا وقتی یک گلوگاه واقعی و اندازه‌گیری‌شده ندارید، چندایجنتی نسازید.
سیستم چندایجنتی دقیقاً چیست؟
سیستم چندایجنتی (Multi-Agent System) معماری‌ای است که در آن چند ایجنت هوش مصنوعی — هر کدام با نقش، دستور سیستمی، مجموعه ابزار و گاهی مدل پایه‌ی متفاوت — روی یک هدف مشترک کار میکنند و از طریق پیام با هم تبادل اطلاعات دارند. تفاوت اصلی‌اش با یک ایجنت تکی، توزیع تصمیمگیری است، نه صرفاً توزیع کار.
سه چیز را باید از هم جدا کرد، چون در فارسی مدام قاطی میشوند:
| الگو | چه کسی تصمیم می‌گیرد | مثال |
|---|---|---|
| گردش‌کار (Workflow) | برنامه‌نویس. مسیر از پیش ثابت است و مدل فقط جاهای خالی را پر میکند. | زنجیره‌ی «خلاصه کن ← ترجمه کن ← بفرست» |
| ایجنت تکی (Single-Agent) | یک مدل، در یک حلقه. خودش تصمیم می‌گیرد کدام ابزار را کِی صدا بزند و کِی متوقف شود. | یک ایجنت پشتیبانی که تا حل مسئله در حلقه می‌ماند |
| چندایجنتی (Multi-Agent) | چند مدل، هر کدام حلقه و زمینهی خودشان. تصمیم توزیع شده است. | سرپرست + سه پژوهشگر موازی + یک ویراستار |
اگر با مفهوم «حلقه» آشنا نیستید، پیش از ادامه مهندسی حلقه (Loop Engineering) را بخوانید — چندایجنتی در واقع چند حلقه‌ی موازی یا تودرتوست، و بدون فهم حلقه‌ی تکی، معماری چندایجنتی معنا نمی‌دهد.
چهار معماری اصلی چندایجنتی
در عمل چهار الگوی معماری تکرار میشود: ترتیبی (زنجیره‌ای)، ارکستریتور-کارگر (سرپرست و زیردست)، سلسله‌مراتبی (چند لایه سرپرست) و شبکه‌ای (هر ایجنت با هر ایجنت). انتخاب درست بین این چهار، بیشتر از انتخاب مدل روی نتیجه‌ی نهایی اثر می‌گذارد.
۱. ترتیبی (Sequential / Pipeline)
خروجی هر ایجنت ورودی بعدی است. ساده‌ترین و قابل‌پیش‌بینی‌ترین حالت — و در بیشتر پروژه‌های واقعی کسب‌وکار، تنها چیزی که واقعاً لازم دارید. عیبش این است که خطای مرحله‌ی اول تا انتها تکثیر میشود.
۲. ارکستریتور-کارگر (Orchestrator-Worker)
یک ایجنت سرپرست مسئله را تحلیل میکند، آن را به زیرمسئله‌های مستقل می‌شکند، چند کارگر را موازی اجرا میکند و در پایان نتایج را ترکیب میکند. این همان معماری‌ای است که Anthropic برای سیستم پژوهش خود انتخاب کرد و بیشترین شواهد موفقیت را دارد — به شرطی که زیرمسئله‌ها واقعاً مستقل باشند.
۳. سلسله‌مراتبی (Hierarchical)
ارکستریتور-کارگر در چند لایه. یک سرپرست کل، چند سرپرست میانی و کارگرها. برای سازمان‌های بزرگ و دامنه‌های چندتخصصی طراحی شده، اما هر لایه یک نقطه‌ی جدید برای گم‌شدن اطلاعات اضافه میکند.
۴. شبکه‌ای / گروهی (Network, Swarm, Group Chat)
هر ایجنت می‌تواند با هر ایجنت دیگری حرف بزند. انعطاف بالا، پیش‌بینی‌پذیری پایین. الگوهای مناظره و مذاکره معمولاً در همین دسته می‌نشینند. برای محیط تولیدی (production) پرریسک‌ترین گزینه است، مگر با محدودیت سختِ تعداد راند و بودجه.
هرچه وابستگی زیرمسئله‌ها به هم بیشتر باشد، باید به سمت معماری‌های سادهتر و متمرکزتر بروید. موازی‌سازی فقط وقتی سود میدهد که کارها واقعاً از هم مستقل باشند — و اکثر کارهای برنامه‌نویسی این‌طور نیستند.
چهار الگوی همکاری بین ایجنتها
معماری می‌گوید ایجنتها چطور به هم وصل‌اند؛ الگوی همکاری می‌گوید با هم چه میکنند. چهار الگوی رایج: تقسیم کار، مناظره (بحث روی یک مسئله‌ی مشترک)، مذاکره (چانه‌زنی با منافع متضاد)، و بازبینی (یکی تولید میکند، دیگری نقد). هر کدام برای نوع متفاوتی از مسئله ساخته شده‌اند.
| الگو | منافع ایجنتها | خروجی | بهترین کاربرد |
|---|---|---|---|
| تقسیم کار | همراستا | ترکیب قطعات | پژوهش پهنا-محور، جمع‌آوری داده |
| مناظره (Debate) | همراستا، دیدگاه متفاوت | یک پاسخ مشترک | کاهش توهم، مسائل استدلالی، داوری |
| مذاکره (Negotiation) | متضاد | یک توافق | قیمت‌گذاری، تخصیص منابع، تجارت ایجنتی |
| بازبینی (Critic) | نامتقارن | نسخهی اصلاح‌شده | تولید کد، محتوا، کنترل کیفیت |
دو الگوی وسط — مناظره و مذاکره — جذاب‌ترین و در عین حال بدفهم‌ترین بخش این حوزه‌اند. هر کدام مقاله‌ی مستقل خودشان را در این خوشه دارند:
از «نسازید» تا «چه چیزی واقعاً جواب میدهد»
Anthropic روی پژوهش پهنا-محور از چندایجنتی نتیجه‌ی قوی گرفت. Cognition در ۲۰۲۵ نسبت به شکستن زمینه هشدار داد، اما در آوریل ۲۰۲۶ موضعش را دقیق‌تر کرد: چند ایجنت می‌توانند همزمان اطلاعات و بازبینی فراهم کنند، به شرطی که نوشتن و تصمیم نهایی تکرشتهای بماند.
موضع Anthropic: بشکن و موازی کن
تیم مهندسی Anthropic سیستم پژوهش Claude را با معماری ارکستریتور-کارگر ساخت: یک ایجنت سرپرست استراتژی می‌چیند و چند زیرایجنت همزمان جنبه‌های مختلف را می‌کاوند. نتایجی که منتشر کردند:
منطق پشت این عدد ساده است: در یک پژوهش پهنا-محور، هر زیرایجنت پنجره‌ی زمینهی مستقل خودش را دارد. یعنی سیستم عملاً چند برابر یک مدل تکی «فضای فکر» در اختیار می‌گیرد. زیرایجنت‌ها به‌عنوان فیلترهای هوشمند عمل میکنند: انبوه اطلاعات را می‌بلعند و فقط عصاره را به سرپرست برمی‌گردانند.
اما خودِ همین گزارش، مرزها را هم صریح اعلام کرد. چندایجنتی بد عمل میکند وقتی: همه‌ی ایجنتها به زمینهی مشترک نیاز دارند، کارها وابستگی متقابل زیاد دارند، یا هماهنگی لحظه‌ای لازم است. و این جمله‌ی کلیدی: «بیشتر کارهای برنامه‌نویسی، آن‌قدر که به نظر می‌رسد قابل موازی‌سازی نیستند.»
به‌روزرسانی Cognition در ۲۰۲۶: همکاری، اما با نوشتن تکرشتهای
مقاله‌ی «چندایجنتی نسازید» در ژوئن ۲۰۲۵ روی دو خطر درست دست گذاشت: ایجنت‌های موازی تصمیمهای ضمنی متفاوتی درباره‌ی سبک، لبه‌های مسئله و الگوهای اجرا میگیرند؛ و اگر زمینهی مشترک ناقص باشد، خروجی‌ها در پایان قابل ترکیب نیستند.
اما Cognition در آوریل ۲۰۲۶ تجربه‌ی تازه‌اش را منتشر کرد: حالا از چندایجنتی در تولید استفاده میکند، ولی در یک محدوده‌ی مشخص. الگوهای موفق جایی هستند که چند عامل «هوش» و بازبینی اضافه میکنند، در حالی که نوشتن و تغییر نهایی تکرشتهای می‌ماند. زیرایجنت‌های فقط‌خواننده، جست‌وجوی کد و حلقه‌ی تولیدکننده–بازبین از نمونه‌های عملی این الگو هستند.
در مقابل، ازدحام ایجنت‌هایی که همزمان روی یک خروجی واحد می‌نویسند هنوز شکننده است. نتیجه‌ی عملی همان قاعده‌ای است که این مقاله پیشنهاد میکند: خواندن و نقد را موازی کنید؛ مالکیت خروجی را توزیع نکنید.
آشتی دادن دو موضع
| ویژگی کار | چندایجنتی موازی | تک‌ایجنت + فشرده‌سازی |
|---|---|---|
| زیرمسئله‌ها مستقل‌اند | ✅ برنده | کند |
| خروجی‌ها باید با هم سازگار باشند | ❌ تناقض تولید میکند | ✅ برنده |
| کار «فقط خواندن» است (پژوهش، جست‌وجو) | ✅ برنده | کند |
| کار «نوشتن» است (کد، محتوای واحد) | ❌ پرریسک | ✅ برنده |
| حجم اطلاعات از یک پنجره‌ی زمینه بیشتر است | ✅ برنده | نیاز به فشرده‌سازی |
| بودجه‌ی توکن محدود است | ❌ حدود ۱۵ برابر | ✅ برنده |
قاعده‌ی عملی: خواندن را موازی کن، نوشتن را نه. اگر ایجنتها فقط اطلاعات جمع میکنند، چندایجنتی برنده است. اگر قرار است هر کدام تکه‌ای از یک خروجی واحد را بنویسند، تکرشتهای برنده است.
هزینه‌ی واقعی: چرا چندایجنتی گران است
یک ایجنت معمولی حدود ۴ برابر یک مکالمه‌ی چت ساده توکن مصرف میکند. یک سیستم چندایجنتی حدود ۱۵ برابر. یعنی پیش از هر تصمیم معماری، باید بپرسید آیا ارزش خروجی این ضریب را توجیه میکند یا نه — چون این هزینه در هر بار اجرا تکرار میشود، نه یک بار.
سه لایه هزینه وجود دارد که معمولاً فقط اولی دیده میشود:
- توکن. هر زیرایجنت دستور سیستمی، تعریف ابزارها و بخشی از زمینه را از نو دریافت میکند. این تکرار، نه محاسبه‌ی مفید.
- تأخیر. موازی‌سازی زمان دیوارِ ساعت را کم میکند، اما راندهای هماهنگی آن را برمی‌گردانند. هر راند مناظره یعنی یک رفت‌وبرگشت کامل ضربدر تعداد ایجنتها.
- نگهداری. اشکالزدایی یک سیستم چندایجنتی به‌مراتب سخت‌تر است. خطا در راند سوم ایجنت دوم، در لاگ‌ها شبیه یک پاسخ کاملاً معقول به نظر می‌رسد.
پژوهش ۲۰۲۵ روی پروتکلهای تصمیمگیری نشان داد افزایش تعداد ایجنتها عملکرد را بالا می‌برد، اما افزایش تعداد راندهای گفت‌وگو آن را پایین می‌آورد. یعنی رایج‌ترین کاری که تیم‌ها برای «بهتر کردن» مناظره میکنند — اضافه کردن راند — دقیقاً همان کاری است که نباید بکنند.
چک‌لیست تصمیم: آیا واقعاً به چندایجنتی نیاز دارید؟
پیش‌فرض درست، تک‌ایجنت است. فقط وقتی به چندایجنتی بروید که حداقل سه مورد از پنج شرط زیر برقرار باشد — و پیش از آن، یک نسخهی تک‌ایجنتی ساخته و گلوگاهش را اندازه گرفته باشید. ساختن چندایجنتی بدون خط پایه‌ی اندازه‌گیری‌شده، بهینه‌سازی زودهنگام است.
| # | شرط | چطور تست کنید |
|---|---|---|
| ۱ | کار به زیرمسئله‌های واقعاً مستقل شکسته میشود | می‌توانید زیرمسئله‌ها را به سه نفر مختلف بدهید بدون اینکه لازم باشد با هم حرف بزنند؟ |
| ۲ | حجم اطلاعات از یک پنجره‌ی زمینه بیرون می‌زند | خط پایه‌ی تک‌ایجنتی را اجرا کنید؛ آیا واقعاً به سقف زمینه می‌خورد یا فقط کند است؟ |
| ۳ | ارزش خروجی، ضریب ۱۵ برابری توکن را توجیه میکند | هزینه‌ی هر اجرا × تعداد اجرا در ماه را حساب کنید، نه هزینه‌ی یک اجرا |
| ۴ | خروجی نهایی «مجموعه‌ای از یافته‌ها»ست، نه یک متن/کد یکپارچه | اگر خروجی باید سبک و لحن واحد داشته باشد، شرط برقرار نیست |
| ۵ | شرط توقف و سقف بودجه‌ی روشن دارید | سقف مرحله + محدودیت زمان + تشخیص گیر افتادن + سقف هزینه — هر چهار مورد |
۱. هنوز نسخهی تک‌ایجنتی ندارید. ۲. دلیل اصلی‌تان «چون مدرن‌تر است» یا «چون همه دارند می‌سازند» است. ۳. نمی‌توانید در یک جمله بگویید هر ایجنت دقیقاً چه چیزی را نمی‌داند که ایجنت دیگر می‌داند.
چرا سیستم‌های چندایجنتی شکست می‌خورند
بزرگ‌ترین مطالعه‌ی میدانی این حوزه، ۱٬۶۴۲ اجرای واقعی روی ۷ فریم‌ورک متن‌باز مطرح را تحلیل کرد و نرخ شکست ۴۱ تا ۸۶٫۷ درصدی یافت. مهمتر از خود عدد، این یافته است: بیشتر شکست‌ها ریشه در طراحی سیستم دارند نه ضعف مدل — چون با همان مدل‌ها و فقط اصلاح معماری، موفقیت ۹٫۴ تا ۱۵٫۶ درصد بالا رفت.
پژوهشگران ۱۴ مود شکست را در سه دسته سامان دادند؛ مقاله‌ی عیب‌یابی خوشه هر مود را با نشانه و راهحل عملی باز میکند:
دسته‌ی دوم از همه گویاتر است. «کتمان اطلاعات» یعنی ایجنتی چیزی می‌داند که ایجنت دیگر لازم دارد، ولی چون کسی از او نپرسیده، آن را منتقل نمی‌کند. این دقیقاً همان چیزی است که Cognition پیش‌بینی کرده بود: مشکل چندایجنتی، هوش مدل‌ها نیست، نظریه‌ی ذهن آن‌هاست — اینکه بفهمند دیگری چه چیزی را نمی‌داند.
اگر سیستم چندایجنتی شما نتیجه‌ی بدی میدهد، پیش از عوض کردن مدل، این سه را چک کنید: آیا هر ایجنت دقیقاً می‌داند چه چیزی از او خواسته شده؟ آیا ردِ کامل تصمیم‌ها بین ایجنتها جریان دارد؟ آیا لایه‌ی تأیید مستقل و واقعی دارید یا فقط یک ایجنت که می‌گوید «به نظر خوب است»؟
پروتکل‌ها: MCP، A2A و AP2
سه پروتکل مهم، نقش‌های متفاوتی دارند: MCP برای اتصال ایجنت به ابزار و داده، A2A برای ارتباط بین ایجنت‌های مستقل، و AP2 برای ثبت اختیار و مسیر حسابرسی پرداخت‌های عامل‌محور. این‌ها مکملاند و جای طراحی امنیت، کنترل دسترسی و سیاست هزینه را نمی‌گیرند.
| پروتکل | چه چیزی را وصل میکند | وضعیت ۲۰۲۶ |
|---|---|---|
| MCP (Model Context Protocol) | ایجنت ← ابزار، داده، سرویس | استاندارد عملی صنعت؛ پشتیبانی گسترده |
| A2A (Agent2Agent) | ایجنت ← ایجنت (حتی از دو سازمان مختلف) | نسخهی ۱٫۰ زیر چتر Linux Foundation؛ ۱۵۰+ سازمان |
| AP2 (Agent Payments Protocol) | ایجنت ← تراکنش مالی | نسخهی ۰٫۲؛ واگذارشده به FIDO Alliance در آوریل ۲۰۲۶ |
A2A در آوریل ۲۰۲۶ یک‌سالگی‌اش را با ارقام قابل توجهی جشن گرفت: رشد از ۵۰ به بیش از ۱۵۰ سازمان پشتیبان، بیش از ۲۲ هزار ستاره‌ی گیت‌هاب، SDK در پنج زبان (Python، JavaScript، Java، Go، دات‌نت)، و «کارت ایجنت امضاشده» (Signed Agent Card) برای احراز هویت رمزنگاری‌شده‌ی ایجنتها. ادغام در Azure AI Foundry، Copilot Studio و Amazon Bedrock AgentCore انجام شده و AWS، سیسکو، گوگل، IBM، مایکروسافت، Salesforce، SAP و ServiceNow پشت آن ایستاده‌اند.
این پروتکل‌ها یعنی ایجنت شما دیگر لازم نیست همه‌چیز را خودش بداند. می‌تواند از یک ایجنت تخصصی دیگر — داخل یا خارج سازمان — سرویس بگیرد. برای یک ربات فروش روی بله یا تلگرام، این یعنی امکان اتصال به موجودی انبار، سیستم حسابداری و درگاه پرداخت بدون نوشتن یکپارچه‌سازی اختصاصی برای هر کدام.
فریم‌ورک‌ها: با چه ابزاری بسازیم
در ۲۰۲۶ پنج گزینه‌ی جدی وجود دارد: LangGraph برای کنترل دقیق گراف، CrewAI برای سرعت راه‌اندازی نقش‌محور، AutoGen/AG2 برای گفت‌وگوی گروهی، OpenAI Agents SDK برای سادگی و n8n برای تیم‌هایی که کدنویسی کمتری می‌خواهند. انتخاب بین این‌ها بیشتر به «چقدر کنترل می‌خواهید» برمی‌گردد تا به قابلیت‌ها.
| ابزار | مدل ذهنی | مناسب برای | هزینه‌ی یادگیری |
|---|---|---|---|
| LangGraph | گراف حالت‌دار با گره و یال | سیستم تولیدی با نیاز به کنترل دقیق، بازگشت به حالت قبل، انسان در حلقه | بالا |
| CrewAI | تیمی از نقش‌ها با وظایف | نمونه‌سازی سریع، گردش‌کار نقش‌محور | پایین |
| AutoGen / AG2 | گفت‌وگوی گروهی بین ایجنتها | پژوهش، مناظره، الگوهای تعاملی | متوسط |
| OpenAI Agents SDK | ایجنت + تحویل کار (handoff) | سیستم‌های سبک، شروع سریع | پایین |
| n8n | گردش‌کار بصری | تیم‌هایی با منابع فنی محدود، اتصال به سرویس‌های موجود | خیلی پایین |
هیچ‌کدام از این فریم‌ورک‌ها مسئله‌ی اصلی — طراحی درست وظیفه و جریان زمینه — را حل نمی‌کنند. همان مطالعه‌ی میدانی نشان داد نرخ شکست بالا در همین فریم‌ورک‌های مطرح ثبت شده است. ابزار، معماری بد را نجات نمی‌دهد.
آیا با مدلهای زبانی لوکال هم میشود؟
از نظر فنی بله — و برای کسب‌وکارهای ایرانی که با محدودیت دسترسی و حساسیت داده روبه‌رو هستند، جذاب‌ترین گزینه است. اما شواهد پژوهشی نشان میدهد تنظیماتی که روی مدلهای بزرگ جواب میدهند، لزوماً به مدلهای کوچکتر منتقل نمیشوند. یعنی نمی‌توانید معماری را کپی کنید و انتظار همان نتیجه را داشته باشید.
در مطالعه‌ی مقایسه‌ای استراتژی‌های مناظره، پژوهشگران دیدند تنظیمات بهینه‌ی هایپرپارامتر به‌خوبی به GPT-4 منتقل میشود، اما همان انتقال برای Mixtral 8x7B جواب نمی‌دهد. دلیلش روشن است: مناظرهی سالم به توانایی ذاتی استدلال و پایبندی به دستور نیاز دارد. مدلی که در تنهایی نمی‌تواند استدلال منسجم بسازد، در گروه هم فقط سریعتر به اشتباه می‌رسد.
یافته‌ی مکمل و مهمتر از مطالعه‌ی کنترل‌شده‌ی ۲۰۲۵: عامل تعیین‌کننده‌ی موفقیت مناظره، قدرت استدلال ذاتی و تنوع گروه است — نه ترتیب صحبت، نه نمایش میزان اطمینان، نه ساختار مناظره. یعنی سه مدل لوکالِ متفاوت (مثلاً از سه خانواده‌ی مختلف) به‌مراتب مفیدتر از سه نمونه از یک مدل واحد هستند.
همان مطالعه یک رفتار نگران‌کننده را مستند کرد: وقتی اکثریت ایجنتها روی یک پاسخ غلط هم‌نظر میشوند، فشار گروه مانع از آن میشود که ایجنتِ درست روی موضع خود بماند. یعنی مناظره می‌تواند پاسخ درست را حذف کند. این تنها با تنوع واقعی مدل‌ها و پرامپت‌های ضدجریان مهار میشود.
راهکار عملی برای شروع با منابع محدود: بهجای سه ایجنت همزمان، یک ایجنت تولیدکننده و یک ایجنت منتقد بسازید. الگوی بازبینی (Critic) بیشترین سود را با کمترین هزینه میدهد و در برابر ضعف مدل پایه مقاوم‌تر از مناظرهی چندنفره است.
بازار و پذیرش: عدد پشت هیجان
گارتنر پیش‌بینی کرده است تا پایان ۲۰۲۶ حدود ۴۰٪ اپلیکیشن‌های سازمانی، ایجنت‌های وظیفه‌محور داشته باشند؛ در مقابل، بیش از ۴۰٪ پروژه‌های ایجنتیک ممکن است تا پایان ۲۰۲۷ به‌دلیل هزینه، ارزش تجاری نامشخص یا کنترل ریسک ناکافی لغو شوند. این‌ها پیش‌بینی بازارند، نه نتیجه‌ی قطعی.
این دو عدد را کنار هم بگذارید و تصویر واقعی به دست می‌آید: پذیرش سریع است، اما بقا نیست. IDC رشد ۱۰ برابری استفاده در شرکت‌های G2000 تا ۲۰۲۷ و رشد ۱۰۰۰ برابری فراخوان‌های API مرتبط با ایجنت را پیش‌بینی میکند.
موج اصلی هنوز نرسیده و فاصله‌ی زمانی به نفع شماست. اما درسِ آن ۴۰٪ لغو‌شده روشن است: پروژه‌هایی می‌مانند که از یک مسئله‌ی مشخص و قابل‌اندازه‌گیری شروع کرده‌اند، نه از یک معماری جذاب. یک ربات که یک کار را درست انجام میدهد، از یک ارکستر پنج‌ایجنتی که هفته‌ای دو بار خروجی متناقض میدهد ارزشمندتر است.
نقشه‌ی خوشه: از اینجا کجا برویم
این صفحه نقشه‌ی کلی خوشه است. چهار مقاله‌ی تکمیلی منتشرشده، تصمیم معماری، مناظره، عیب‌یابی و مذاکره‌ی ایجنتها را عمیق‌تر بررسی میکنند:
و اگر تازه وارد این حوزه شده‌اید، ترتیب پیشنهادی مطالعه از پایه: مهندسی زمینه ← مهندسی حلقه ← همین صفحه ← مقاله‌ی متناسب با مسئله‌تان.
می‌خواهید بدانید کسب‌وکار شما به کدام معماری نیاز دارد؟
در یک جلسه‌ی مشاوره‌ی رایگان، مسئله‌ی شما را بررسی می‌کنیم و صادقانه می‌گوییم که آیا اصلاً به سیستم چندایجنتی نیاز دارید یا یک ربات ساده کار را راه می‌اندازد.
پرسش‌های پرتکرار
خیر. در کارهای پهنا-محور و قابلموازیسازی مثل پژوهش، برتری چشمگیری دارد (تا ۹۰٫۲٪ بهبود در گزارش Anthropic). اما در کارهایی که خروجی باید یکپارچه و سازگار باشد — مثل نوشتن کد یا یک متن واحد — معمولاً بدتر عمل میکند، چون ایجنتها فرضهای متناقض میگیرند.
طبق گزارش مهندسی Anthropic، یک ایجنت معمولی حدود ۴ برابر یک مکالمه‌ی چت ساده توکن مصرف میکند و یک سیستم چندایجنتی حدود ۱۵ برابر. این ضریب در هر بار اجرا تکرار میشود، پس محاسبه را باید روی حجم ماهانه انجام داد نه یک اجرا.
در مناظره، ایجنتها منافع همراستا دارند و دنبال یک پاسخ درستِ مشترک میگردند؛ اختلافشان بر سر روش است. در مذاکره، ایجنتها منافع متضاد دارند (مثل خریدار و فروشنده) و خروجی یک توافق است نه یک پاسخ. این دو معیار ارزیابی کاملاً متفاوتی دارند: دقت در برابر کیفیت توافق.
معمولاً خیر. پژوهش ۲۰۲۵ روی پروتکلهای تصمیمگیری نشان داد افزایش تعداد ایجنتها عملکرد را بهتر و افزایش تعداد راندها آن را بدتر میکند. راندهای اضافه معمولاً به همگرایی زودهنگام روی یک پاسخ (درست یا غلط) و مصرف بیثمر توکن منجر میشوند.
بله، اما با احتیاط. تنظیماتی که روی مدلهای بزرگ جواب میدهند لزوماً به مدلهای کوچکتر منتقل نمیشوند. توصیهی عملی: از مدلهای متفاوت استفاده کنید (تنوع گروه مهمتر از تعداد است) و بهجای مناظرهی چندنفره با الگوی سادهتر «تولیدکننده + منتقد» شروع کنید.
شایعترین دلیل، نبود زمینهی مشترک است. هر کنش یک تصمیم ضمنی در خود دارد؛ وقتی ایجنتها ردِ کامل تصمیمهای یکدیگر را نمیبینند، فرضهای ناسازگار میگیرند و نتیجه قابل ترکیب نیست. راهحل: کل ردِ اجرا را به اشتراک بگذارید، نه فقط پیام نهایی.
MCP ایجنت را به ابزار و داده وصل میکند (رابطهی عمودی)، و A2A ایجنت را به ایجنت دیگر — حتی از سازمانی دیگر (رابطهی افقی). A2A در آوریل ۲۰۲۶ زیر چتر Linux Foundation به نسخهی ۱٫۰ رسید و بیش از ۱۵۰ سازمان از آن پشتیبانی میکنند. این دو مکملاند، نه رقیب.
در اکثریت قریببهاتفاق موارد خیر. یک ایجنت تکرشتهای با ابزارهای درست (موجودی، سفارش، پرداخت) هم سریعتر است، هم ارزانتر، هم قابل اشکالزدایی. چندایجنتی وقتی معنا پیدا میکند که کارهای واقعاً مستقل و موازی داشته باشید — مثلاً پایش همزمان چند کانال فروش.
واژه‌نامه
- ایجنت (Agent)
- مدل زبانی که در یک حلقه اجرا میشود، ابزار صدا می‌زند و خودش تصمیم می‌گیرد کِی متوقف شود.
- ارکستریتور-کارگر (Orchestrator-Worker)
- معماری‌ای که در آن یک ایجنت سرپرست، مسئله را می‌شکند و به چند کارگر موازی می‌سپارد و نتایج را ترکیب میکند.
- مناظرهی چندایجنتی (Multi-Agent Debate)
- الگویی که در آن چند مدل روی یک مسئله‌ی مشترک پاسخ میدهند، پاسخ یکدیگر را نقد میکنند و به یک جواب واحد می‌رسند.
- مذاکره‌ی ایجنتی (Agent Negotiation)
- الگویی که در آن ایجنت‌هایی با منافع متضاد چانه می‌زنند تا به توافق برسند.
- اجماع در برابر رأی‌گیری (Consensus vs Voting)
- دو پروتکل تصمیمگیری گروهی؛ اجماع نیاز به توافق چند ایجنت دارد، رأی‌گیری فقط اکثریت را می‌شمارد.
- پنجره‌ی زمینه (Context Window)
- حجم اطلاعاتی که یک مدل همزمان می‌تواند در نظر بگیرد. سقف آن، محرک اصلی رفتن به سمت چندایجنتی است.
- فشرده‌سازی زمینه (Context Compression)
- خلاصه‌کردن تصمیم‌ها و رویدادهای کلیدی یک اجرای طولانی، به‌عنوان جایگزین شکستن کار به چند ایجنت.
- شرط توقف (Halt Condition)
- قاعده‌ای که مشخص میکند حلقه کِی باید متوقف شود؛ ترکیبی از سقف مرحله، محدودیت زمان، تشخیص گیر افتادن و سقف بودجه.
- MCP
- Model Context Protocol — استاندارد اتصال ایجنت به ابزار، داده و سرویس.
- A2A
- Agent2Agent — استاندارد گفت‌وگوی ایجنت با ایجنت، حتی بین دو سازمان متفاوت.
- AP2
- Agent Payments Protocol — استاندارد انجام تراکنش مالی توسط ایجنت.
- سرکوب اقلیت (Majority Suppression)
- پدیده‌ای که در آن فشار توافق گروهی، ایجنتِ دارای پاسخ درست را وادار به عقب‌نشینی میکند.
منابع
- Anthropic Engineering — How we built our multi-agent research system
- Walden Yan, Cognition — Don't Build Multi-Agents
- Walden Yan, Cognition — Multi-Agents: What's Actually Working (2026)
- Cemri et al. — Why Do Multi-Agent LLM Systems Fail? (NeurIPS 2025)
- Du et al. — Improving Factuality and Reasoning in Language Models through Multiagent Debate (ICML 2024)
- Smit et al. — Should we be going MAD? A Look at Multi-Agent Debate Strategies for LLMs (ICML 2024)
- Voting or Consensus? Decision-Making in Multi-Agent Discussions (ACL 2025 Findings)
- Can LLM Agents Really Debate? A Controlled Study of Multi-Agent Debate in Logical Reasoning
- Linux Foundation — A2A Protocol Surpasses 150 Organizations (آوریل ۲۰۲۶)
- MIT News — Multi-AI collaboration helps reasoning and factual accuracy in LLMs
- Google — AP2 v0.2 و واگذاری پروتکل به FIDO Alliance (آوریل ۲۰۲۶)
- Gartner — پیش‌بینی ایجنت‌های وظیفه‌محور در اپلیکیشن‌های سازمانی
- Gartner — پیش‌بینی لغو بیش از ۴۰٪ پروژه‌های ایجنتیک تا پایان ۲۰۲۷
- IDC — Agent Adoption: The IT Industry’s Next Great Inflection Point