چندایجنتی یا تک‌ایجنتی؟ سه عددی که تصمیم را می‌گیرند

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

اگر یک جمله از این مقاله بخوانید، این باشد: تعداد ایجنت‌ها یک انتخاب معماری نیست، یک نتیجه است. وقتی سه کمیت زیر را برای کار خودتان اندازه بگیرید، عدد درست خودش بیرون می‌آید — و در اکثر پروژه‌های واقعی کسب‌وکار، آن عدد یک است.

• عدد اول — کسر موازی‌پذیر. اگر ۷۰٪ کار قابل موازی‌سازی باشد، سقف شتاب شما ۳٫۳ برابر است، حتی با بی‌نهایت ایجنت. این قانون امدال است و راه فراری از آن نیست.^۱
• عدد دوم — ضریب هماهنگی. برخلاف امدال، افزودن ایجنت فقط بی‌اثر نمی‌شود؛ از یک نقطه به بعد عملکرد را پایین می‌آورد. قانون مقیاس‌پذیری جهانی، پس از برآورد پارامترهای واقعی سیستم، می‌تواند نقطه‌ی اوج را مدل کند.^۲
• عدد سوم — نرخ موفقیت هر گام. در زنجیره‌ای که موفقیت همه‌ی گام‌ها لازم است، قابلیت اطمینان می‌تواند ضربی افت کند. با فرض استقلال و موفقیت ۹۵٪ در هر گام، ده گام حدود ۶۰٪ موفق می‌شوند.
• واقعیت میدانی نگران‌کننده‌تر است. در τ-bench، GPT-4o در بخش خرده‌فروشی pass^1 برابر ۶۱٫۲٪ داشت، اما pass^8 آن به کمتر از ۲۵٪ رسید.^۳
• نیروی مقابل واقعی است. بررسی ۱۸ مدل پیشرو نشان داد همه با افزایش طول ورودی افت می‌کنند. این «زوال زمینه» یکی از مهم‌ترین دلایل فنی برای بررسی معماری چندایجنتی است.^۴
• پاسخ عملی معمولاً معماری سوم است: یک ایجنت اصلی که تصمیم می‌گیرد و می‌نویسد، به‌علاوه‌ی چند زیرایجنت فقط‌خواننده که موازی جست‌وجو می‌کنند.

چرا این پرسش معمولاً بد پرسیده می‌شود

در طول ۲۰۲۵ و ۲۰۲۶ دو موضع صنعتی شکل گرفت که هر دو با شواهد پشتیبانی می‌شوند:

نکته این است که این دو موضع درباره‌ی دو نوع کار متفاوت صحبت می‌کنند. Anthropic چندایجنتی را برای پژوهش پهنا-محور مناسب می‌داند، اما برای کارهای وابسته و زمینه‌مشترک محدودیت قائل است. Cognition نیز در جمع‌بندی به‌روزتر خود می‌گوید الگوهای مفید معمولاً جایی هستند که چند عامل «هوش و بررسی» اضافه می‌کنند، ولی نوشتن نهایی تک‌رشته‌ای می‌ماند.^۵۶

عدد اول: کسر موازی‌پذیر (قانون امدال)

حالا این را برای کارهای واقعی حساب کنیم. ستون آخر مهم‌ترین ستون این مقاله است:

دو ردیف آخر را نگاه کنید. برای یک ربات فروش که با یک مشتری گفت‌وگو می‌کند، حتی اگر بی‌نهایت ایجنت بیاورید، بیش از ۴۰٪ سریع‌تر نمی‌شوید — چون کار ذاتاً ترتیبی است: باید سؤال را بفهمی، بعد موجودی را چک کنی، بعد قیمت بدهی، بعد سفارش بگیری. هر گام به خروجی گام قبل وابسته است.

عدد دوم: ضریب هماهنگی و نقطه‌ی برگشت

برای تخمین هزینه‌ی هماهنگی می‌توان از «قانون مقیاس‌پذیری جهانی» الهام گرفت؛ مدلی که در مهندسی عملکرد سیستم‌های توزیع‌شده استفاده می‌شود.^۲ این یک مدل تقریبی برای طراحی ایجنت‌هاست، نه قانون تجربیِ اثبات‌شده برای رفتار معنایی LLMها. پارامترهای آن باید از اندازه‌گیری سیستم خودتان برازش شوند و دو جریمه را مدل می‌کنند:

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

• α (رقابت) — گلوگاه‌های مشترک: محدودیت نرخ API، ایجنت سرپرستی که باید همه را هماهنگ کند، یک پایگاه‌داده‌ی مشترک.
• β (هم‌بستگی) — هزینه‌ی این که هر ایجنت باید بداند بقیه چه کرده‌اند. این همان چیزی است که با مربع تعداد ایجنت‌ها رشد می‌کند، چون تعداد جفت‌های ارتباطی در یک گروه N نفره برابر N(N−1)/2 است.

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

این جدول یک مثال محاسباتی است، نه اندازه‌گیری عمومیِ α و β برای همه‌ی سیستم‌ها. با این حال نشان می‌دهد چرا در سناریوهای دارای هماهنگی متوسط، نقطه‌ی بهینه می‌تواند در محدوده‌ی چند ایجنت قرار بگیرد؛ توصیه‌ی عملی «۳ تا ۷ زیرایجنت» نیز با گزارش‌های میدانی هم‌راستاست، اما باید روی داده و زیرساخت خودتان اندازه‌گیری شود.^۵ پژوهش مستقلی درباره‌ی پروتکل تصمیم‌گیری نیز نشان داد نوع هماهنگی مهم است: رأی‌گیری در وظایف استدلالی و اجماع در وظایف دانشی عملکرد بهتری داشتند. بنابراین هزینه و کیفیت هماهنگی را نمی‌توان یک مقدار ثابت فرض کرد.^۹

عدد سوم: مالیات قابلیت اطمینان

ردیف وسط یک مثال محاسباتی است، نه برآورد عمومیِ همه‌ی سامانه‌ها. اگر ده گام اجباری و مستقل هرکدام ۹۵٪ موفق باشند، احتمال موفقیت کل حدود ۶۰٪ می‌شود؛ در عمل، هم‌بستگی خطاها، تلاش مجدد، مسیرهای جایگزین و اعتبارسنجی می‌توانند نتیجه را تغییر دهند.

و واقعیت میدانی از این هم بدتر است

محک τ-bench معیاری به نام pass^k معرفی کرد: احتمال اینکه یک ایجنت همان وظیفه را در k اجرای مستقل، هر بار درست انجام دهد. این دقیقاً چیزی است که یک کسب‌وکار به آن نیاز دارد — نه موفقیت گاه‌به‌گاه، بلکه موفقیت قابل اتکا.^۳

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

نیروی مقابل: زوال زمینه

پژوهش «زوال زمینه» (Context Rot) روی ۱۸ مدل شاخص انجام شد و یافته‌ی مرکزی‌اش این بود: مدل‌ها از پنجره‌ی زمینه‌ی خود به‌طور یکنواخت استفاده نمی‌کنند؛ عملکردشان با افزایش طول ورودی به‌طور فزاینده‌ای غیرقابل‌اتکا می‌شود.^۴

چند یافته‌ی مشخص که مستقیماً به تصمیم معماری ربط دارند:

• حتی یک عامل حواس‌پرتی کافی است. افزودن یک متن نامرتبط اما شبیه، دقت را پایین آورد — و شدت این اثر بین عوامل مختلف یکسان نبود.
• شباهت معنایی مهم است. وقتی شباهت بین پرسش و پاسخ کم بود، افت با افزایش طول زمینه تندتر می‌شد.
• حتی کپی‌کردن ساده هم افت می‌کند. در وظیفه‌ی بازتولید متن (۲۵ تا ۱۰٬۰۰۰ کلمه) دقت به‌طور سیستماتیک پایین آمد و مدل‌ها در طول‌های زیاد کم‌تولید کردند.
• یافته‌ی خلاف‌شهود. مدل‌ها روی انبار متنی نامنسجم و تصادفی بهتر عمل کردند تا انبار منطقی و منسجم.

این یافته‌ها یکی از مهم‌ترین استدلال‌های فنی به نفع چندایجنتی را می‌سازند: اگر هر زیرایجنت پنجره‌ی زمینه‌ی کوچک و تمیز خودش را داشته باشد، هیچ‌کدام به ناحیه‌ی زوال نمی‌رسند. این همان سازوکاری است که Anthropic برای توضیح بهبود ۹۰٫۲٪ در ارزیابی داخلیِ پژوهش پهنا-محور خود مطرح می‌کند — زیرایجنت‌ها به‌عنوان فیلترهای هوشمند عمل می‌کنند و فقط عصاره را برمی‌گردانند.^۵

آیا پنجره‌ی زمینه‌ی بزرگ‌تر مسئله را حل می‌کند؟

استدلال «صبر می‌کنیم پنجره‌ها بزرگ‌تر شوند، بعد همه‌چیز را در یک ایجنت می‌ریزیم» دو خطا دارد:

1. خطای کیفی. ظرفیت اسمی با ظرفیت مؤثر یکی نیست. مدل ممکن است ۱ میلیون توکن را بپذیرد ولی کیفیت پاسخش از ده‌ها هزار توکن به بعد افت کند.
2. خطای اقتصادی. هزینه‌ی ورودی خطی با طول زمینه رشد می‌کند. زمینه‌ی بزرگ در هر فراخوان تکرار می‌شود، پس یک تصمیم معماری «ارزان» به یک هزینه‌ی جاری تبدیل می‌شود.

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

معماری سوم: تک‌ایجنت با زیرایجنت‌های فقط‌خواننده

منطقش مستقیماً از سه بخش قبل بیرون می‌آید:

قاعده‌ی طلایی که از این تحلیل بیرون می‌آید و در کل این خوشه تکرار می‌شود:

یک نکته‌ی معماری که اغلب فراموش می‌شود: اگر زیرایجنت‌های شما باید از مرز سازمان بیرون بروند و با ایجنت شرکت دیگری حرف بزنند، پروتکل استانداردی برای همین وجود دارد و در ۲۰۲۶ به بلوغ رسیده.^۱۲ در این حالت ضریب هم‌بستگی شامل تأخیر شبکه و احراز هویت هم می‌شود.

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

جدول تصمیم کامل

هزینه: سه لایه‌ای که فقط یکی‌اش دیده می‌شود

نکته‌ی مهم درباره‌ی لایه‌ی اول: بررسی مستقلی روی نُه محک نشان داد افزایش بودجه‌ی محاسباتی لزوماً به دقت بیشتر ترجمه نمی‌شود — یعنی توکن بیشتر، به‌خودی‌خود خرید کیفیت نیست.^۱۰

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

تصویر کلان بازار هم همین را تأیید می‌کند: پیش‌بینی می‌شود تا پایان ۲۰۲۶ حدود ۴۰٪ اپلیکیشن‌های سازمانی ایجنت وظیفه‌محور داشته باشند، اما تا ۲۰۲۷ حدود ۴۰٪ پروژه‌های ایجنتیک لغو شوند — با سه دلیل نام‌برده: هزینه‌ی افسارگسیخته، بازگشت سرمایه‌ی نامشخص، و ضعف حاکمیت.^۱۱

چک‌لیست نُه پرسشی پیش از تصمیم

پنج سناریوی واقعی و پاسخشان

مسیر مهاجرت: از یک به چند، بدون فاجعه

1. خط پایه‌ی تک‌ایجنتی + پرامپت قوییک ایجنت با ابزارهای درست و پرامپتی که مثال دارد. پژوهش نشان داده ایجنت تکی با پرامپت قوی اغلب به همان نتیجه‌ی معماری‌های پیچیده می‌رسد.^۸ اینجا مجموعه‌ی ارزیابی‌تان را بسازید — بدون آن، بقیه‌ی پله‌ها معنا ندارند.
2. فشرده‌سازی زمینهاگر به ناحیه‌ی زوال زمینه خوردید، پیش از شکستن به چند ایجنت، تاریخچه را خلاصه کنید. ارزان‌ترین راه‌حل ممکن، و انسجام را حفظ می‌کند.
3. یک زیرایجنت فقط‌خوانندهسنگین‌ترین کار جست‌وجو را به یک زیرایجنت بسپارید که فقط یافته‌ی فشرده برمی‌گرداند. β هنوز صفر است چون فقط یک زیرایجنت دارید.
4. چند زیرایجنت موازی فقط‌خوانندهحالا β بالا می‌رود ولی هنوز پایین است، چون زیرایجنت‌ها با هم حرف نمی‌زنند. سقف عملی: ۳ تا ۷، طبق محاسبه‌ی بخش ۰۴.
5. چندایجنتی کامل با نوشتن توزیع‌شدهفقط اگر پله‌ی چهارم واقعاً کافی نبود. اینجا باید ردِ کامل تصمیم‌ها بین ایجنت‌ها جریان داشته باشد و لایه‌ی تأیید مستقل ضروری است.^۷

هفت اشتباه در انتخاب معماری

جمع‌بندی

ادامه‌ی این خوشه

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

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

واژه‌نامه

کسر موازی‌پذیرParallelizable Fraction

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

قانون امدالAmdahl's Law

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

قانون مقیاس‌پذیری جهانیUniversal Scalability Law

مدلی که علاوه بر رقابت بر سر منابع، جریمه‌ی درجه‌دوم هم‌بستگی را هم حساب می‌کند و نقطه‌ی بیشینه‌ی مقیاس را می‌دهد.

ضریب هم‌بستگیCoherency Coefficient (β)

هزینه‌ی اینکه هر ایجنت باید بداند بقیه چه کرده‌اند؛ با مربع تعداد ایجنت‌ها رشد می‌کند.

مالیات قابلیت اطمینانReliability Tax

افت ضربی موفقیت در یک زنجیره؛ با نرخ p در هر گام و N گام برابر p به توان N.

pass^k

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

زوال زمینهContext Rot

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

فشرده‌سازی زمینهContext Compression

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

زیرایجنت فقط‌خوانندهRead-only Subagent

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

ارکستریتور-کارگرOrchestrator-Worker

معماری‌ای که در آن یک ایجنت سرپرست مسئله را می‌شکند، به کارگرهای موازی می‌سپارد و نتایج را ترکیب می‌کند.

منابع

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

1. Amdahl's Law — سقف شتاب موازی‌سازی.Gene Amdahl, 1967مرجع
2. How to Quantify Scalability — The Universal Scalability Law — فرمول USL و نقطه‌ی بیشینه.Neil J. Gunther, Performance Dynamicsمهندسی عملکرد
3. τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains — تعریف pass^k و افت GPT-4o در بخش خرده‌فروشی از ۶۱٫۲٪ به کمتر از ۲۵٪.Yao et al. — ICLR 2025داوری‌شده
4. Context Rot: How Increasing Input Tokens Impacts LLM Performance — بررسی ۱۸ مدل.Chroma Researchپژوهش صنعتی
5. How we built our multi-agent research system — ۹۰٫۲٪، ~۱۵× توکن، مرزهای کاربرد.Anthropic Engineeringصنعتی
6. Multi-Agents: What’s Actually Working — زیرایجنت‌های فقط‌خواندنی، زمینه‌ی تمیز و نوشتن نهایی تک‌رشته‌ای.Walden Yan, Cognitionصنعتی
7. Why Do Multi-Agent LLM Systems Fail? — ۱۴ مود شکست، نرخ شکست ۴۱ تا ۸۶٫۷٪.Cemri et al. — NeurIPS 2025داوری‌شده
8. Rethinking the Bounds of LLM Reasoning: Are Multi-Agent Discussions the Key? — ایجنت تکی با پرامپت قوی.2024arXiv
9. Voting or Consensus? Decision-Making in Multi-Agent Discussions — رأی‌گیری برای استدلال و اجماع برای وظایف دانشی.ACL 2025 Findingsداوری‌شده
10. Multi-LLM-Agents Debate — Performance, Efficiency and Scaling Challenges — بررسی روی ۹ محک.ICLR 2025 Blogpostsگزارش پژوهشی
11. پیش‌بینی حضور ایجنت‌های وظیفه‌محور در اپلیکیشن‌های سازمانی و پیش‌بینی لغو بیش از ۴۰٪ پروژه‌های ایجنتیک تا پایان ۲۰۲۷ — هزینه، ارزش نامشخص و کنترل ریسک.Gartner — 2025تحلیل بازار
12. A2A Protocol Surpasses 150 Organizations — بلوغ پروتکل ارتباط ایجنت‌ها.Linux Foundation — آوریل ۲۰۲۶استاندارد
13. Model Context Protocol — استاندارد اتصال ایجنت به ابزار و داده.مستندات رسمیاستاندارد