‏کِی subagentها رو تو حلقه‌ی اصلی ایجنت ادغام کنیم؟

تو این مقاله، تیم Applied AI شرکت Anthropic می‌گه تو چند پروژه‌ی سازمانی، یه ایجنت تکی با skill (یعنی بسته‌های دستورالعمل که فقط موقع نیاز کامل بارگذاری می‌شن) معمولاً از هر دو طرح دیگه بهتر بوده: هم از «یه پرامپت برای همه‌چیز» و هم از طرح subagent (یعنی ایجنت‌های جدا با context خودشون، زیر دست یه هماهنگ‌کننده). هم کیفیت بهتر بوده، هم هزینه و تأخیر کمتر. مثلاً یه شرکت دیده دوجین ایجنت متخصص تو ایجنت مشتریش، هم لحن برند رو ناهماهنگ کرده بود و هم کندش کرده بود.

به گفته‌ی نویسنده‌ها، مشکل اصلی اینه که معماری ایجنت کپی چارت سازمانی می‌شه (همون قانون Conway). هر تیم ایجنت خودش رو می‌سازه و یه تیم مرکزی یه orchestrator روش می‌ذاره. نتیجه‌ش می‌شه از دست رفتن جزئیات تو رد و بدل کردن context، صدها subagent تکراری بی‌صاحب، و یه «Frankenprompt» که هر تیم یه جمله بهش اضافه کرده. evalهای پراکنده هم هر کدوم فقط زیرکار خودشون رو می‌سنجن. یه مشتری بعد از رفتن سراغ حلقه‌ی تکی، تقریباً ۲ برابر سرعت اجرا گرفته.

راه‌حل پیشنهادی progressive disclosureـه، یعنی ایجنت اول فقط توضیح کوتاه skillها و ابزارها رو می‌بینه و هر کدوم رو موقع لزوم کامل بار می‌کنه (ابزارها از طریق tool search). این‌طوری context شلوغ نمی‌شه و نتایج همه‌ی مرحله‌ها تو یه context می‌مونه، پس ایجنت می‌تونه ربطشون رو بفهمه. Anthropic می‌گه از Opus 4.5 به بعد مدل‌ها خیلی بیشتر از انتظار تو یه حلقه از پسِ کار برمیان. خودشون هم پرامپت سیستمی Claude Code رو برای مدل‌های جدید بیش از ۸۰ درصد کوتاه کردن.

البته subagent هنوز جای خودش رو داره: وقتی حلقه‌ی تکی به‌خاطر شلوغی context افت عملکرد قابل‌اندازه‌گیری داره، وقتی چندتا کار باید موازی با context تازه انجام بشه، یا وقتی ایجنت تو انتخاب ابزار گیج می‌شه. اگه سراغش رفتی، کار رو بر اساس context تقسیم کن، نه بر اساس نوع مسئله. وگرنه یه «بازی تلفن» راه می‌افته که هر دست‌به‌دست شدن دقت رو کم می‌کنه.

مسیر مهاجرت پیشنهادی مرحله‌ایه. اول یه eval مشترک بساز، حتی با ۱۰ نمونه‌ی طلایی. بعد subagentها رو به شکل ابزار صدا بزن و در آخر یکی‌یکی تبدیلشون کن به skill و MCP tool و با eval مقایسه کن. نویسنده‌ها تأکید می‌کنن فقط به نمره‌ی کل نگاه نکن، ببین کدوم تسک‌ها عوض شدن. تو یه تست، ادغام یه subagent تأخیر رو کم کرد ولی یه فرایند رو خراب کرد، و این خرابی فقط تو یکی از دو اجرا دیده شد. پس هر تسک رو بیشتر از یه بار اجرا کن.

برای همکاری تیم‌ها، پیشنهاد اینه که تیم‌ها به جای ایجنت، صاحب skill و ابزار بشن و یه تیم مرکزی کوچیک صاحب پرامپت سیستمی و کیفیت کلی باشه. ابزارها بهتره بر اساس نیت کاربر گروه‌بندی بشن، چون بالای ۳۰ تا ۵۰ تعریف ابزار، انتخاب ابزار افت می‌کنه. Anthropic یه migration kit و چندتا skill مثل /claude-api build-eval، prompt-audit، hillclimb و cost-optimize هم برای همین کار منتشر کرده.

نکات کلیدی:

• تو مقایسه‌های Anthropic، یه ایجنت با skill اغلب از طرح subagent بهتر و ارزون‌تر بوده.
• یه مشتری با حلقه‌ی تکی تقریباً ۲ برابر سرعت اجرا گرفته.
• پرامپت سیستمی Claude Code برای مدل‌های جدید بیش از ۸۰ درصد کوتاه شده.
• subagent برای کار موازی، شلوغی context یا تداخل دستورالعمل‌ها هنوز مناسبه.
• بالای ۳۰ تا ۵۰ تعریف ابزار، دقت انتخاب ابزار پایین میاد.
• برای شروع مهاجرت، یه eval با ۱۰ نمونه‌ی طلایی کافیه.