افزودن agent همیشه throughput را زیاد نمی‌کند. وقتی کار وابسته، مبهم یا کوچک است، tokenهای هماهنگی، contextهای تکراری، review و merge می‌توانند از سود موازی‌سازی بیشتر شوند. این درس پنج topology را با هزینه و شواهد مقایسه می‌کند.
## اهداف یادگیری
پس از درس می‌توانی بین single agent، parallel workers، orchestrator–worker، evaluator–optimizer و competing implementations انتخاب کنی؛ هزینهٔ token و هماهنگی را تخمین بزنی؛ sequential degradation را تشخیص دهی؛ و topology را با ریسک و evidence توجیه کنی.
## جایگاه در چرخه
بعد از ownership درس ۳۶، topology فقط شکل کنترل است. ورودی، dependency graph، budget و معیار پذیرش است؛ خروجی، تصمیمی شامل topology، owner، stop condition، ارتباط، integration و هزینه است. نام topology تضمین کیفیت نیست.
*شکل: چهار الگوی single agent، workerهای موازی، orchestrator–worker و evaluator–optimizer را مقایسه می‌کند؛ متن جایگزین: جریان‌های کنترل و بازخورد در چهار topology. تصویر فعلی fan-in مرحلهٔ ادغام را به‌صورت مستقل رسم نمی‌کند؛ fan-in و merge در درس l38 به‌صورت متنی و اجرایی تعریف می‌شوند.*
## پنج انتخاب
**Single agent** برای یک تغییر کوچک، وابسته یا نیازمند context واحد مناسب است. هزینهٔ هماهنگی کم و trace ساده است، اما ظرفیت و استقلال کمتر می‌شود. در یک bug timezone که schema، test و service به هم وابسته‌اند، این انتخاب اغلب بهتر است.
**Parallel workers** برای taskهای مستقل با output جدا مناسب است: سه adapter اعلان می‌توانند هم‌زمان contract ثابت را مصرف کنند. coordinator فقط contract و evidence را توزیع و نتیجه‌ها را جمع می‌کند.
**Orchestrator–worker** یک orchestrator taskها را می‌شکند، assign می‌کند، status می‌گیرد و fan-in را هدایت می‌کند. برای graph بزرگ سودمند است، اما orchestrator خودش token و failure point است و نباید owner رفتار domain و داور نهایی هم باشد.
**Evaluator–optimizer** یک implementer خروجی می‌دهد و evaluator مستقل آن را با rubric می‌سنجد؛ optimizer فقط با feedback قابل‌ردیابی اصلاح می‌کند. برای quality یا test oracle مناسب است، نه برای تصمیم policy مبهم. evaluator باید از context و فرض‌های implementer تا حد ممکن تازه باشد.
**Competing implementations** چند راه‌حل را مستقل می‌سازند و یک owner با معیار ثابت انتخاب می‌کند. این روش برای ambiguity فنی پرریسک مفید است، اما هزینهٔ token، زمان، duplicate work و discarded output بالاست. برای یک adapter ساده، سه implementation رقیب معمولاً اتلاف است.
## هزینه و sequential degradation
هزینهٔ واقعی فقط token مدل نیست:
total = worker tokens + orchestration + repeated context
+ contract/review + merge/rework + runtime resourcesاگر taskها زنجیره‌ای باشند، worker دوم تا خروجی اول صبر می‌کند؛ اگر context را دوباره برای همه بفرستیم، parallelism فقط token اضافه تولید می‌کند. اگر merge conflict یا test flaky رخ دهد، `sequential degradation` رخ داده است: نمودار موازی است ولی مسیر critical و زمان پذیرش از single agent بدتر می‌شود. برای تصمیم، زمان تا accepted merge، defect، review burden، budget و evidence را اندازه بگیرید؛ تعداد agent، LOC یا token به‌تنهایی ارزش نیست.
راهنمای کوتاه
اگر یک dependency زنجیره‌ای یا یک file owner دارید: single. اگر ≥۲ task مستقل، output جدا و contract ثابت دارید: parallel. اگر graph نیازمند routing و retry کنترل‌شده است: orchestrator–worker. اگر معیار کیفیت روشن ولی خروجی ممکن است ضعیف باشد: evaluator–optimizer. اگر تصمیم معماری چند گزینهٔ واقعی دارد و budget اجازه می‌دهد: competing؛ در غیر این صورت یک spike کوچک.
مثال عددی کوچک
فرض کنید سه adapter مستقل داریم. یک single agent در ۱۸ دقیقه با ۱۸ واحد هزینهٔ نمادین آن‌ها را می‌سازد. سه worker موازی هرکدام ۷ واحد خرج می‌کنند؛ هماهنگی و contract review برابر ۶ واحد و fan-in برابر ۵ واحد است. هزینهٔ موازی‌سازی `3×7 + 6 + 5 = 32` واحد است و زمان ایده‌آل ۱۲ دقیقه می‌شود. اگر احتمال conflict یا rework را ۲۰٪ و هزینهٔ مورد انتظار آن را ۱۰ واحد بگیریم، هزینهٔ مورد انتظار ۳۴ واحد می‌شود؛ پس برای این مثال parallel سریع‌تر است اما ارزان‌تر نیست. اگر یک فایل shared باعث ۱۵ دقیقه rework شود، زمان پذیرش به حدود ۲۷ دقیقه می‌رسد و sequential degradation رخ می‌دهد.
برای کار زنجیره‌ای دیگری فرض کنید migration، service و test به‌ترتیب ۸، ۱۰ و ۶ دقیقه‌اند. سه worker نمی‌توانند واقعاً هم‌زمان شروع کنند؛ orchestrator حداقل ۲۴ دقیقهٔ مسیر بحرانی، context تکراری و review اضافه می‌کند. single agent با ۲۴ دقیقه کار و یک review پنج‌دقیقه‌ای ممکن است هم سریع‌تر و هم قابل‌ردیابی‌تر باشد. این اعداد benchmark یا ادعای عمومی نیستند؛ ورودی ساختگی برای آموزش مدل تصمیم‌اند. در پروژهٔ واقعی، زمان wall-clock، retry، defect، merge conflict و هزینهٔ اجرا را از evidence ثبت‌شده اندازه بگیرید.
ریسک نیز باید کنار هزینه بیاید. parallel adapterها ریسک domain مشترک کمی دارند، اما ریسک ناسازگاری contract و cleanup دارند. competing implementations ریسک انتخاب راه‌حل ضعیف را کم می‌کند، ولی ریسک duplicate work و معیار انتخاب مبهم را بالا می‌برد. evaluator مستقل ریسک پذیرش کد ضعیف را کاهش می‌دهد، اما اگر rubric فقط «خوب به نظر می‌رسد» باشد، بازخورد آن قابل دفاع نیست. یک جدول تصمیم باید برای هر topology مسیر بحرانی، ریسک غالب، budget، مالک توقف و evidence لازم را ثبت کند.
## سناریوی booking-platform
برای سه notification adapter مستقل، parallel workers انتخاب می‌شود. برای `reschedule` transaction و migration، single agent با verifier تازه مناسب است. برای بررسی schema دو implementation رقیب فقط وقتی توجیه دارد که latency و concurrency trade-off حل‌نشده باشد. orchestrator نباید از workerها بخواهد هم‌زمان `packages/contracts` را تغییر دهند.
## آزمایشگاه
**ورودی:** پنج task، dependency graph، budget نمادین `EXAMPLE_BUDGET_DO_NOT_CHARGE`، contract و rubric. برای هر topology یک تصمیم یک‌صفحه‌ای بنویس: why now، inputs، outputs، owner، budget، stop، failure/recovery و evidence.
printf '%s\n' 'topology=parallel' 'workers=3' 'budget=EXAMPLE_BUDGET_DO_NOT_CHARGE' > topology-plan.txt
git diff --check**خروجی مورد انتظار:** انتخاب parallel فقط برای adapterها، single برای transaction، evaluator برای review و رد competing برای کار کم‌ریسک؛ همراه با برآورد هزینه و critical path. **Recovery:** اگر workerها overlap نشان دادند، fan-out را متوقف و task را به integration owner برگردان. اگر evaluator و implementer نتیجه‌های متناقض دارند، rubric را immutable نگه دار و status را `DECIDE` کن؛ budget را برای retry نامحدود افزایش نده.
## خطاهای رایج
- استفاده از orchestrator برای پوشاندن decomposition ضعیف.
- parallel کردن taskهای دارای migration یا contract مشترک.
- evaluator همcontext و هم‌فرض با implementer.
- انتخاب competing implementations برای تغییر trivial.
- ندیدن هزینهٔ context تکراری و merge.
- گزارش token به‌جای accepted merge و defect.
## Verification
- [ ] dependency و critical path قبل از topology مشخص است.
- [ ] انتخاب با استقلال، ریسک و budget توجیه شده است.
- [ ] token، هماهنگی، review، merge و runtime cost دیده شده‌اند.
- [ ] stop condition و recovery وجود دارد.
- [ ] sequential degradation با زمان و evidence قابل تشخیص است.
- [ ] diagram با alt و caption استفاده شده است.
## تمرین و Rubric
برای پنج کار booking-platform topology انتخاب کن. Rubric: single برای کار زنجیره‌ای، parallel فقط برای adapterهای مستقل، orchestrator با مالک fan-in، evaluator با rubric مستقل، competing فقط برای ambiguity پرهزینه؛ هزینهٔ هماهنگی و recovery هرکدام ثبت شده و token/LOC معیار اصلی قرار نگرفته است.
## جمع‌بندی
Topology باید از dependency و معیار پذیرش بیاید. parallel workers ظرفیت را افزایش می‌دهند فقط وقتی ownership و interface آماده است؛ evaluator کیفیت را می‌سنجد؛ orchestrator هزینه و نقطهٔ شکست دارد؛ competing implementation گران است. زمان تا merge پذیرفته‌شده معیار تصمیم است.
## منابع مستقیم
- [Anthropic — Building effective agents](https://www.anthropic.com/engineering/building-effective-agents) — الگوهای single و orchestrated؛ نتایج به task وابسته‌اند.
- [Anthropic — Multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system) — **سطح شواهد: گزارش میدانی فروشنده؛** تعمیم به coding بدون آزمایش محلی مجاز نیست؛ رکورد آن در `sources.md` ثبت شده است.
- [Cursor Subagents](https://cursor.com/docs/subagents.md) — **سطح شواهد: مستند رسمی محصول؛** رفتار Surface محصول را توضیح می‌دهد، نه برتری عمومی topology، و رکورد آن در `sources.md` ثبت شده است.
- [GitHub Copilot custom agents](https://docs.github.com/en/copilot/concepts/agents/copilot-cli/about-custom-agents) — **سطح شواهد: مستند رسمی محصول؛** قابلیت محصول است و الگوی orchestrator–worker را به‌تنهایی اثبات نمی‌کند؛ رکورد آن در `sources.md` ثبت شده است.
- [MAST benchmark preprint](https://arxiv.org/abs/2503.13657) — **سطح شواهد: preprint پژوهشی؛** روش و داده‌ها مستقل از این دوره‌اند و استاندارد production نیستند؛ رکورد آن در `sources.md` ثبت شده است.
به زبان ساده
Topology را از dependency و هزینهٔ پذیرش انتخاب کن، نه از تعداد Agent. Parallel برای خروجی‌های مستقل، Single برای زنجیرهٔ وابسته و Evaluator–optimizer برای rubric روشن مناسب‌تر است.
مثال واقعی
در سناریوی فرضی دوره، سه notification adapter مستقل موازی می‌شوند، اما transaction و migration reschedule یک مسیر ترتیبی با verifier تازه دارند؛ این انتخاب از ownership می‌آید.