منبع: این نوشته برداشت و تحلیل فارسی نکست ادمین از مطلب Building agents: When to fold subagents into your main agent loop است که Diane Sarkis از تیم Applied AI شرکت Anthropic در ۲۲ اکتبر ۲۰۲۶ منتشر کرده.
خلاصه در یک نگاه
- خیلی از ایجنت‌های سازمانی امروز از یک «هماهنگ‌کننده» و چند یا چند ده «زیرایجنت» متخصص ساخته شده‌اند. تجربه‌ی Anthropic در پروژه‌های مشتریانش نشان می‌دهد بسیاری از این‌ها اگر به یک حلقه‌ی واحد تبدیل شوند، بهتر جواب می‌دهند، ارزان‌تر تمام میشوند و سریع‌ترند.
- راز این حلقه‌ی واحد «افشای تدریجی» است: دانش هر حوزه در قالب مهارت (skill) و ابزارها با جستوجوی ابزار (tool search) فقط وقتی وارد زمینهی مدل میشوند که لازم‌اند. پس پرامپت سیستم باد نمی‌کند.
- در مقایسه‌ای که یکی از مشتریان انجام داد، حلقه‌ی واحد تقریباً دو برابر سریع‌تر از نسخه‌ی چندایجنتی بود.
- زیرایجنت حذف نمی‌شود؛ برای کار موازی، بررسی مستقل (verifier) و وقتی زمینه واقعاً بیش از حد شلوغ می‌شود هنوز بهترین انتخاب است.
- مسیر پیشنهادی مهاجرت تدریجی است: یک ارزیابی کوچک بسازید، هر بار فقط یک زیرایجنت را ادغام کنید، و فقط اگر نسخه‌ی ادغام‌شده بدتر شد آن را نگه دارید.
زیرایجنت چیست و کجا واقعاً به کار می‌آید؟
زیرایجنت یک نمونه‌ی جدا از مدل است با پنجره‌ی زمینه، دستورالعمل و ابزارهای خودش. یک ایجنت دیگر (هماهنگ‌کننده) کاری را به آن می‌سپارد و خلاصه‌ی نتیجه را پس می‌گیرد. این الگو بد نیست؛ خود Anthropic در سیستم پژوهشی چندایجنتی‌اش از آن استفاده میکند. جاهایی که زیرایجنت واقعاً می‌درخشد:
- کار موازی و مستقل: چند مسیر پژوهش که هرکدام زمینهی تازه می‌خواهند و بعد از تمام شدن دور ریخته میشوند.
- بررسی مستقل: یک «بازبین» که بدون دیدن استدلال سازنده، خروجی را جعبه‌سیاه چک میکند.
- مجوزهای جدا: وقتی بخشی از کار باید با دسترسی محدودتر انجام شود.
مقاله سه نشانه‌ی مشخص برای ماندن روی زیرایجنت می‌دهد: افت قابل اندازهگیری کیفیت به‌خاطر شلوغی زمینه در حلقه‌ی واحد، نیاز به اجرای موازی با زمینه‌های تازه، یا اینکه ایجنت واحد در انتخاب ابزار گیج می‌شود یا پرامپتش دستورهای متناقض دارد.
مشکل: وقتی معماری ایجنت شکل چارت سازمانی را می‌گیرد
در شرکت‌های بزرگ معمولاً هر تیم صاحب یک قابلیت است و طبیعی‌ترین کار این است که هر تیم ایجنت خودش را بسازد و یک تیم پلتفرم، هماهنگ‌کننده‌ای بالای همه بگذارد. این دقیقاً همان «قانون کانوی» است: ساختار سیستم، ساختار ارتباطی سازمان را تکرار میکند. نتیجه معمولاً این مشکلات است:
- مدیریت زمینه: همیشه باید تصمیم گرفت کدام اطلاعات به کدام ایجنت برسد، و در رفت‌وبرگشت‌ها جزئیات گم میشوند.
- تکثیر بی‌حساب زیرایجنت‌ها: صدها ایجنت هم‌پوشان بدون استاندارد و صاحب روشن.
- پرامپت وصله‌پینه‌ای: هر تیم چند جمله به پرامپت سیستم اضافه میکند تا قواعد با هم تناقض پیدا کنند و ایجنت دیگر صدای یکدستی نداشته باشد.
- ارزیابی‌های جزیره‌ای: هر تیم ارزیابی کار خودش را بهینه میکند و هیچ‌کس مسئول تجربه‌ی کامل کاربر نیست؛ مدیران هم بر اساس نمره‌هایی تصمیم می‌گیرند که تصویر کامل را نشان نمی‌دهند.
- تأخیر: هر زیرایجنت یک حلقه‌ی مدل کامل است. یکی از مشتریان یک ایجنت پشتیبانی با ده‌ها متخصص داشت که هم یکدست نگه‌داشتنش سخت بود و هم کاربر را منتظر می‌گذاشت.
مقاله یک الگوی رایج طراحی را هم مثال می‌زند: طبقه‌بند نیت، خط لوله‌ی استدلال چندمرحله‌ای ثابت، دسته‌بندی کاربران، شاخه‌های جدای پیشنهاد و در نهایت یک هماهنگ‌کننده‌ی چندایجنتی. وقتی این طرح‌ها بررسی میشوند، معمولاً بیشتر این ساختار کاری را انجام می‌دهد که مدل‌های امروز دیگر لازم ندارند کسی برایشان انجام دهد. جایگزین پیشنهادی ساده است: یک پرامپت سیستم روشن، چهار یا پنج ابزار ساده‌ی داده، و چند محدودیت محکم روی خروجی.
جایگزین: یک حلقه، با افشای تدریجی
ایده‌ی اصلی این است که به جای تقسیم کار بین چند ایجنت، دانش را تقسیم کنیم. هر تیم روش کارش را به شکل یک مهارت می‌نویسد. مدل در حالت عادی فقط یک توضیح یک‌خطی از هر مهارت می‌بیند و متن کامل را فقط وقتی بار میکند که به آن نیاز دارد. ابزارها هم با بارگذاری تأخیری و جستوجوی ابزار همین رفتار را دارند. به گفتهی مقاله، این رویکرد به سه دلیل جواب می‌دهد:
- زمینهی مشترک جواب بهتری می‌سازد. وقتی نتیجه‌ی چند کار در یک پنجره کنار هم باشد، مدل می‌تواند ارتباطشان را ببیند. این از خلاصه‌هایی که زیرایجنت‌ها پس می‌فرستند بهتر است و انتقال‌های کم‌جزئیات هم حذف میشوند.
- افشای تدریجی جلوی باد کردن زمینه را می‌گیرد. این همان دلیل اصلی‌ای بود که تیم‌ها کار را بین زیرایجنت‌ها تقسیم می‌کردند. Anthropic می‌گوید پرامپت سیستم Claude Code را برای مدل‌های جدیدتر بیش از ۸۰٪ کوتاه کرده و بخشی از آن با همین بار کردن تدریجی مهارت‌ها و ابزارها بوده است.
- مدل‌ها توانمندتر شده‌اند. از Opus 4.5 به بعد، مدل‌ها در یک حلقه خیلی بیشتر از انتظار تیم‌ها از عهده برمی‌آیند؛ پیشرفت کارشان را گزارش می‌دهند و کار خودشان را چک می‌کنند. ساختارهای سفت چندایجنتی حتی گاهی جلوی استفاده از توان مدل جدید را می‌گیرند.
این طراحی بی‌هزینه نیست. پرامپت سیستم باید با دقت نگه‌داری شود، توضیح مهارت‌ها و ابزارها باید طوری نوشته شود که دقیقاً در لحظه‌ی درست فعال شوند، و مدیریت زمینه، حافظه و یادداشت‌برداری باید آگاهانه باشد. پیشنهاد سازمانی مقاله هم روشن است: یک تیم کوچک مرکزی صاحب پرامپت سیستم و کیفیت کل مسیر باشد و هر مهارت، ابزار یا ارزیابی تازه پیش از انتشار از زیر دست آن رد شود.
حلقه‌ی پیشنهادی، دور به دور
معماری هدف یک مدل و یک پنجره‌ی زمینه است که در یک حلقه‌ی باز ابزار صدا می‌زند. در دور اول مدل برنامه‌اش را در زمینه می‌نویسد و با رسیدن هر نتیجه آن را اصلاح میکند. در هر دور، چند فراخوانی ابزار را با هم صادر میکند؛ harness آن‌ها را موازی اجرا میکند و نتیجه‌ی خام را به همان مدل برمی‌گرداند. مدل تصمیم می‌گیرد ابزار بیشتری صدا بزند، از کاربر سؤال کند یا جواب بدهد. حلقه با پاسخ نهایی یا تمام شدن بودجه می‌ایستد و در صورت نیاز یک بررسی هدف یا verifier بعد از پاسخ اجرا می‌شود.
سؤال مهم این است که هر منطق کجا باید برود:
| نوع منطق | کجا قرار می‌گیرد |
|---|---|
| ترتیب قدم‌ها و روش انجام کار در هر حوزه | مهارت |
| محدودیت‌های سخت (اعتبارسنجی، تأیید پیش از نوشتن) | داخل ابزار |
| جست‌وجوهای وسط گفت‌وگو، مثل حافظه | ابزار |
| بودجه‌ی دور و هزینه، دروازه‌های نوشتن | harness |
| کارهای ارزان و تقریباً همیشه لازم، مثل شناسایی موجودیت‌ها | کد، پیش از حلقه |
| کار مکانیکی مثل ساختن payload یا parse کردن استریم | کد، داخل ابزار |
| بازنویسی برنامه بر اساس کاتالوگ قواعد | دیگر لازم نیست؛ مدل هر قدم را خودش تصمیم می‌گیرد |
اگر هنوز چند ایجنت لازم است
مقاله توصیه میکند با ساده‌ترین الگوی کارآمد شروع کنید، مثلاً سازنده و بازبین (generator-verifier) یا هماهنگ‌کننده و زیرایجنت. نکته‌ی کلیدی این است که کار را بر اساس زمینه تقسیم کنید، نه بر اساس نوع مسئله. هر زیرایجنت باید تکه‌کاری بگیرد که به بقیه‌ی سیستم کمتر وابسته است و نتیجه‌ی جمع‌وجوری برگرداند؛ مثل یک مسیر پژوهش مستقل، یک مؤلفه با رابط تمیز یا بررسی جعبه‌سیاه. تقسیم بر اساس نوع مسئله به بازی «تلفن خراب» می‌رسد: با هر دست‌به‌دست شدن، بخشی از دقت از دست می‌رود.
مهاجرت در چهار قدم
۱. اول ارزیابی
بدون ارزیابی نمی‌شود فهمید ادغام کمک کرده یا ضرر زده. ساختار پیشنهادی یک مجموعه‌ی مشترک سرتاسری است که تیم مرکزی صاحبش است، به‌علاوه‌ی مجموعه‌های کوچکی که هر تیم همراه مهارتش منتشر میکند. برای شروع ده نمونه‌ی طلایی کافی است. پیام نهایی با یک روبریک نمره می‌گیرد. تا وقتی هماهنگ‌کننده هست، دقت مسیریابی را بسنجید؛ بعد از ادغام، اینکه مهارت یا ابزار درست بار شده یا نه. اگر بازپخش محیط سخت است، زمان رویدادهای مهم را ثبت کنید تا بعداً به ارزیابی هدفمند تبدیل شوند.
۲. انتخاب کاندیدا
از پرمصرف‌ترین زیرایجنت‌ها شروع کنید. متخصص‌هایی که خروجی هم را زنجیره‌وار مصرف می‌کنند، روی یک داده کار می‌کنند یا معمولاً با هم صدا زده میشوند، بهترین کاندیدای ادغام‌اند. اگر بخش قابل‌توجهی از ترافیک واقعی همیشه از متخصص الف به متخصص ب می‌رود، این دو احتمالاً باید یکی شوند.
۳. زیرایجنت به‌عنوان ابزار
یک قدم میانی امن: ایجنت اصلی زیرایجنت را مثل یک ابزار صدا می‌زند و گفت‌وگو با کاربر را خودش نگه می‌دارد. انتقال کامل گفت‌وگو (handoff) فقط وقتی لازم است که زیرایجنت واقعاً باید مستقیم با کاربر حرف بزند. این قدم یک قالب پاسخ مشترک، امکان چک کردن نتیجه با داده‌ی واقعی و یک نمرهی پایه به شما می‌دهد، بی‌آنکه زیرایجنت‌ها بازنویسی شوند. ولی هنوز هر متخصص پرامپت، زمینه، صاحب و ارزیابی خودش را دارد، هر فراخوانی خلاصه‌ی کم‌جزئیات برمی‌گرداند و هر کدام یک حلقه‌ی مدل تودرتو و تأخیر بیشتر است.
۴. تبدیل به مهارت و ابزار
هر بار یک زیرایجنت: پرامپتش مهارت می‌شود و فراخوانی‌های APIاش ابزار MCP. بعد نمرهی ارزیابی را با و بدون آن مقایسه کنید و فقط به نمرهی کل نگاه نکنید؛ ببینید کدام کارها از قبول به رد یا برعکس رفته‌اند. مقاله یک مثال آموزنده دارد: در یک ایجنت پشتیبانی نمونه، ادغام یک زیرایجنت تأخیر را کم کرد، اما فرایندی را که قبلاً درست کار می‌کرد شکست. ایجنت اصلی با ابزار جستوجوی سفارش خودش جواب داد و دیگر سراغ متخصص ارسال برای تاریخ تحویل نرفت. این خطا فقط در یکی از دو اجرا دیده شد؛ برای همین توصیه این است که برای هر زنجیره‌ی ایجنتی که در محیط واقعی با هم اجرا میشوند و برای هر قانونی که نباید شکسته شود یک کار در ارزیابی بگذارید و هر کار را بیش از یک بار اجرا کنید.
چند تیم، یک ایجنت
در مدل جدید تیم‌ها به جای «صاحب ایجنت» بودن، صاحب مهارت‌ها و ابزارها میشوند و تیم کوچک مرکزی پرامپت سیستم و کیفیت کل را نگه می‌دارد.
- ابزارهای MCP برای وقتی است که ایجنت باید کاری انجام دهد، داده‌ی زنده بخواند یا خروجی با قالب ثابت بدهد. ابزارها را بر اساس نیت کاربر گروهبندی کنید، نه یکی برای هر API؛ به گفتهی مقاله، دقت انتخاب ابزار معمولاً بعد از حدود ۳۰ تا ۵۰ تعریف ابزار در پرامپت افت میکند. اگر ابزاری به خروجی ابزار دیگری وابسته است، خودش آن را چک کند و پیامی برگرداند که مدل بتواند بر اساسش عمل کند. مجوزها هم همین‌طور: هر ابزار چک کند کاربر فعلی چه چیزی را اجازه دارد ببیند و در غیر این صورت یک رد ساده برگرداند. این‌طوری یک حلقه می‌تواند به کاربرانی با سطح دسترسی متفاوت خدمت بدهد.
- مهارت‌ها جای «روش کار» تیم‌اند: قدم‌ها، قواعد و قضاوت‌هایی که قبلاً در پرامپت زیرایجنت بود. هر تیم یک مسئول مستقیم داشته باشد که مهارت‌هایش را تمیز، غیرتکراری و همراه با ارزیابی نگه دارد.
- پایگاه دانش برای مرجع‌هایی است که فقط گاهی لازم‌اند، مثل سیاست‌ها، تعریف شاخص‌ها و مشخصات محصول. آن‌ها را پشت یک ابزار جست‌وجو بگذارید یا به‌عنوان فایل مرجع داخل مهارت قرار دهید، نه اینکه کد خودش آن‌ها را بازیابی کند و در پرامپت بچسباند.
Anthropic همراه این مقاله یک کیت مهاجرت هم منتشر کرده که چند مهارت API را پشت هم اجرا میکند: ساخت ارزیابی، ممیزی پرامپت برای پیدا کردن دستورهایی که برای مدل‌های قدیمی نوشته شده‌اند، بهبود تکرارشونده‌ی توضیح مهارت‌ها و ابزارها در برابر ارزیابی، و پیدا کردن فرصت‌های کاهش هزینه مثل کش پرامپت و انتخاب مدل.
برای تیم‌های ما چه معنایی دارد؟
این بخش برداشت خود ماست. بیشتر تیم‌هایی که در ایران روی ایجنت کار می‌کنند هنوز در مرحله‌ی اول‌اند و خبر خوب این است که لازم نیست اشتباه شرکت‌های بزرگ را تکرار کنند:
- با یک حلقه شروع کنید. پیش از ساختن هماهنگ‌کننده و پنج متخصص، ببینید یک مدل با یک پرامپت تمیز و چند ابزار خوب‌طراحی‌شده چقدر جلو می‌رود. پیچیدگی را فقط وقتی اضافه کنید که ارزیابی نشان بدهد لازم است.
- ارزیابی را قبل از معماری بسازید. ده سناریوی واقعی از مشتری‌ها، یک روبریک ساده و اجرای هر سناریو دو یا سه بار. بدون این، هر تصمیم معماری حدس است.
- ابزار را برای مدل طراحی کنید، نه برای API. «پیگیری سفارش» یک ابزار است؛ لازم نیست سه endpoint داخلی را جدا در اختیار مدل بگذارید. پیام خطای ابزار هم باید برای مدل قابل فهم و قابل اقدام باشد.
- مجوز را در ابزار چک کنید. به جای یک ایجنت برای مدیر و یکی برای کاربر عادی، ابزارها خودشان سطح دسترسی را بررسی کنند.
- اگر مدل را عوض می‌کنید، پرامپت را هم بازبینی کنید. چه با Claude کار کنید چه با مدل‌های دیگری که در دسترس‌اند، قواعدی که برای جبران ضعف یک مدل قدیمی نوشته شده‌اند، روی مدل جدید فقط کندی و خشکی می‌آورند.
پرسش‌های پرتکرار
آیا یعنی زیرایجنت دیگر کاربردی ندارد؟
نه. برای کارهای موازی با زمینهی تازه، بررسی مستقل خروجی، جدا کردن مجوزها و وقتی شلوغی زمینه بهطور قابل اندازهگیری کیفیت را پایین میآورد، زیرایجنت هنوز گزینهی درستی است. حرف مقاله این است که زیرایجنت نباید پیشفرض باشد.
مهارت (skill) با پرامپت سیستم چه فرقی دارد؟
پرامپت سیستم همیشه در زمینه است. از مهارت فقط یک توضیح کوتاه در زمینه می‌ماند و متن کامل آن، که روش انجام یک کار مشخص است، فقط وقتی بار می‌شود که مدل تشخیص بدهد به آن نیاز دارد. پس می‌شود ده‌ها مهارت داشت بی‌آنکه پرامپت باد کند.
چند ابزار برای یک ایجنت زیاد است؟
به گفتهی مقاله، دقت انتخاب ابزار معمولاً بعد از حدود ۳۰ تا ۵۰ تعریف ابزار در پرامپت افت میکند. راهحل، گروهبندی ابزارها بر اساس نیت کاربر و استفاده از جستوجوی ابزار با بارگذاری تأخیری است.
از کجا بفهمیم ادغام یک زیرایجنت ضرر زده؟
با ارزیابی سرتاسری، قبل و بعد از ادغام. علاوه بر نمرهی کل، تکتک کارهایی را که نتیجهشان عوض شده ببینید و هر کار را بیش از یک بار اجرا کنید؛ بعضی خطاها فقط در بخشی از اجراها دیده میشوند.
این توصیهها فقط برای Claude است؟
مثالها و ابزارهای کمکی مقاله مخصوص پلتفرم Claude است، ولی اصل حرف، یعنی اندازهگیری، تغییر یک چیز در هر بار، و نگه داشتن چیزی که در ارزیابی بهتر است، برای هر مدل توانمندی که از فراخوانی ابزار پشتیبانی میکند صدق میکند.
منبع
Diane Sarkis، Building agents: When to fold subagents into your main agent loop، Claude by Anthropic، ۲۲ اکتبر ۲۰۲۶. عددها و ادعاهای فنی این نوشته از همین منبع است؛ نمودارها را نکست ادمین بر اساس توضیحات آن بازطراحی کرده و بخش «برای تیم‌های ما چه معنایی دارد؟» تحلیل خود ماست.
