الگوی سرپرست در سیستم‌های چندایجنت: راهنمای عملیاتی Orchestrator-Worker

پژوهش‌های پیچیده و جست‌وجوی عمیق پاشنه‌آشیل ایجنت‌های تکی هستند؛ مدلی که چند منبع طولانی را متوالی می‌خواند، خیلی زود دچار سرریز پنجره‌ی بافتار (context window) و فراموشی جزئیات می‌شود. الگوی سرپرست یا رهبر-نیروی کار (Supervisor / Orchestrator-Worker) با شکستن مسئله به پرسش‌های خرد و اجرای موازی ساب‌ایجنت‌ها با بافتارهای تمیز، این چالش را حل می‌کند.

اگر برای راه‌اندازی این سیستم‌ها به مدل‌های تجاری مطرح مانند کلاد یا OpenAI تکیه می‌کنید، توجه داشته باشید که کارت‌های بانکی ایرانی برای پرداخت مستقیم ارزی قابل استفاده نیستند و برخی ارائه‌دهندگان نیز دسترسی از IP ایران را محدود کرده‌اند؛ بنابراین استفاده از واسطه‌ها، گیت‌وی‌های سازگار، یا مدل‌های باز قابل‌اجرا روی سیستم شخصی در مسیر توسعه به کار می‌آید.

یک ایجنت سرپرست برنامه‌ریزی و تفویض کار را انجام می‌دهد؛ ساب‌ایجنت‌های متخصص نیز در بافتارهای موازی وظایف را اجرا می‌کنند و گزارش می‌دهند. این همان الگوی پشت سیستم پژوهشی Anthropic است (Claude Opus 4 در نقش سرپرست و Sonnet 4 در نقش ساب‌ایجنت‌ها) که در ارزیابی‌های پژوهشی داخلی، 90.2+% نسبت به Opus 4 تک‌ایجنتی بهتر عمل کرده است. در پست مهندسی Anthropic آمده که 80 درصد از واریانس بنچمارک BrowseComp صرفاً با میزان مصرف توکن توجیه می‌شود — سیستم چندایجنت عمدتاً از این جهت برنده است که به هر ساب‌ایجنت یک پنجره‌ی بافتار (context window) تازه اختصاص می‌یابد. در این درس، الگوی سرپرست (supervisor pattern) را از پایه‌ای‌ترین مفاهیم می‌سازیم و درس‌آموخته‌های مهندسی از استقرار در محیط عملیاتی در سال 2026 را بررسی می‌کنیم.

مسئله

پژوهش نمونه‌ی بارز وظایفی است که سیستم‌های تک‌ایجنتی در آن شکست می‌خورند. فرض کنید می‌پرسید: «بین سال‌های 2023 تا 2026 چه چیزهایی در سیستم‌های چندایجنت تغییر کرد؟» یک ایجنت واحد پنج مقاله را پشت سر هم می‌خواند، نیمی از بافتار خود را با متن آن‌ها پر می‌کند، و سپس باید درباره‌ی همه‌ی آن‌ها با هم استدلال کند. تا به مقاله‌ی پنجم برسد، مقاله‌ی اول را فراموش کرده است. امکان موازی‌سازی هم ندارد.

الگوی سرپرست این مشکل را حل می‌کند: یک ایجنت سرپرست جست‌وجو را برنامه‌ریزی می‌کند، هر پرسش فرعی را به یک نیروی کار (worker) می‌سپارد و در پایان نتایج را ترکیب می‌کند. هر نیروی کار پنجره‌ی بافتار 200 هزار توکنی مستقل خود را برای یک پرسش محدود در اختیار دارد. سرپرست هرگز مقاله‌های خام را نمی‌بیند — فقط خلاصه‌های نیروهای کار را بررسی می‌کند.

سیستم عملیاتی Research متعلق به Anthropic در ارزیابی‌های پژوهشی داخلی، بازدهی 90.2+% بهتری نسبت به یک Opus 4 تک ثبت کرده است. همین پست اشاره می‌کند که 80 درصد واریانس BrowseComp صرفاً با مصرف توکن توضیح داده می‌شود. بافتار تازه برای هر ساب‌ایجنت سازوکار اصلی این برتری است.

مفهوم

الگو

                 ┌──────────────┐
                 │   Lead       │  plans, decomposes,
                 │  (Opus 4)    │  synthesizes
                 └──┬────┬───┬──┘
                    │    │   │
            ┌───────┘    │   └───────┐
            ▼            ▼           ▼
      ┌─────────┐  ┌─────────┐  ┌─────────┐
      │ Worker1 │  │ Worker2 │  │ Worker3 │
      │(Sonnet) │  │(Sonnet) │  │(Sonnet) │
      └─────────┘  └─────────┘  └─────────┘
         fresh       fresh        fresh
         context     context      context

سرپرست هرگز داده‌های خام را نمی‌خواند. نیروهای کار نیز تا پیش از مرحله‌ی ترکیب نتایج توسط سرپرست، خروجی یکدیگر را نمی‌بینند. هر فلش نشان‌دهنده‌ی یک دست‌به‌دست‌کردن وظیفه (handoff) همراه با یک دست‌سازه‌ی (artifact) محدود است.

چرا این الگو برنده است؟

سه سازوکار اصلی:

1. بافتار تازه برای هر ساب‌ایجنت. نیروی کاری که روی «پیشینه‌ی FIPA-ACL» تحقیق می‌کند، 40 هزار توکنی را که سرپرست صرف برنامه‌ریزی کرده با خود یدک نمی‌کشد؛ بلکه یک پنجره‌ی 200 هزار توکنی مستقل برای همان یک پرسش دارد.
2. تخصصی‌سازی از طریق پرامپت. پرامپت سرپرست «تجزیه کن و ترکیب کن» است، نه «پژوهش کن». پرامپت هر نیروی کار نیز محدود و مشخص است: «ببین چه چیزی در X تغییر کرده است». پرامپت‌های متمرکز خروجی‌های متمرکز می‌سازند.
3. موازی‌سازی. نیروهای کار به‌طور هم‌روند اجرا می‌شوند. زمان واقعی اجرا (wall-clock time) تقریباً برابر است با max(worker_times) + plan + synthesis، نه sum(worker_times).

درس‌آموخته‌های مهندسی (Anthropic 2025)

پست Anthropic چند درس از محیط عملیاتی را برمی‌شمارد که در سال 2026 همچنان اهمیت دارند:

• تنظیم میزان پردازش بر اساس پیچیدگی پرسش. پرسش‌های ساده: یک ایجنت، 3 تا 10 فراخوانی ابزار (tool call). پرسش‌های پیچیده: بیش از 10 ایجنت. سرپرست باید این حجم را برآورد کند، نه کاربر فراخواننده.
• ابتدا کلان، سپس خرد. ابتدا پرسش را به پرسش‌های فرعی کلان خرد کنید؛ سپس اگر پاسخی نیاز به عمق بیشتری داشت، نیروهای کار بیشتری را برای آن پرسش فرعی بسازید.
• استقرار رنگین‌کمانی (Rainbow deployments). ایجنت‌ها طولانی‌مدت اجرا می‌شوند و دارای وضعیت (stateful) هستند. استقرار سنتی آبی-سبز (blue-green) جواب نمی‌دهد. Anthropic از استقرار رنگین‌کمانی استفاده می‌کند: مسیر پیش‌روی تدریجی نسخه‌های جدید هم‌زمان با تخلیه و خروج نسخه‌های قدیمی.
• غلبه‌ی مصرف توکن. سیستم چندایجنت حدوداً 15 برابر حالت تک‌ایجنتی توکن مصرف می‌کند. این الگو را تنها زمانی اجرا کنید که ارزش کار، هزینه‌اش را توجیه کند.

چرخش به سمت گراف بومی

کتابخانه‌ی LangGraph در ابتدا پکیج langgraph-supervisor را همراه با تابع کمکی سطح‌بالای create_supervisor عرضه کرد. در سال 2025، توصیه‌ی LangChain به سمت پیاده‌سازی مستقیم الگوی سرپرست از طریق فراخوانی ابزار تغییر یافت؛ چون فراخوانی ابزار کنترل بیشتری روی آنچه سرپرست می‌بیند (مهندسی بافتار) فراهم می‌کند. آن کتابخانه هنوز کار می‌کند، ولی مستندات فعلی فرم مبتنی بر فراخوانی ابزار را پیشنهاد می‌دهند.

حالت‌های شکست

• توهم سرپرست در برنامه‌ریزی. اگر سرپرست پرسش‌های فرعی نامربوطی تولید کند که پرسش اصلی را پوشش ندهند، نیروهای کار پژوهشی بسیار دقیق را روی هدفی اشتباه انجام خواهند داد.
• کاوش بیش از حد نیروهای کار. بدون دامنه‌ی صریح (explicit scope)، نیروهای کار از پرسش فرعی محول‌شده فراتر می‌روند و مرحله‌ی ترکیب را به بیراهه می‌کشانند.
• تعارض در ترکیب. دو نیروی کار فکت‌های متناقضی برمی‌گردانند. سرپرست یا باید دوباره سؤال بپرسد (اضافه‌کردن یک نوبت دیگر) یا صراحتاً به این اختلاف اشاره کند. بدترین حالت شکست، انتخاب بی‌سر‌و‌صدای یکی از طرفین است؛ چون کاربر هرگز متوجه وقوع اختلاف نظر نمی‌شود.

چه زمانی الگوی سرپرست اشتباه است؟

• وظایف ترتیبی. اگر گام 2 دقیقاً به خروجی گام 1 نیاز دارد، موازی‌سازی فایده‌ای ندارد. از یک پایپ‌لاین استفاده کنید (Sequential در CrewAI یا گراف خطی LangGraph).
• پرسش‌های ساده. تک‌ایجنت آن‌ها را سریع‌تر و ارزان‌تر انجام می‌دهد. پیش از ساختن نیروهای کار، از بررسی «تنظیم توان» توسط سرپرست کمک بگیرید.
• قطعیت کامل. سرپرست از تفویض مبتنی بر تصمیم مدل زبانی استفاده می‌کند. اگر بازرسی و بازپخش بیش از تطبیق‌پذیری اهمیت دارد، گراف‌های ایستا گزینه‌ی بهتری هستند.

ساخت سیستم

فایل code/main.py یک سرپرست با سه نیروی کار موازی را با استفاده از threading پیاده می‌کند. سرپرست پرسش را به پرسش‌های فرعی خرد می‌کند، نیروهای کار به‌طور هم‌روند روی هر پرسش فرعی کار می‌کنند و در نهایت سرپرست داده‌ها را ترکیب می‌کند. نیازی به مدل‌های زبانی واقعی نیست — نیروهای کار به صورت اسکریپتی نوشته شده‌اند تا دریافت اطلاعات و خلاصه‌سازی را شبیه‌سازی کنند.

ساختار کلیدی:

• متد Lead.plan(query) پرسش را به 3 پرسش فرعی تقسیم می‌کند.
• متد Worker.run(sub_q) یک خلاصه‌ی شبیه‌سازی‌شده برمی‌گرداند (در محیط عملیاتی می‌تواند هر ایجنت مجهز به ابزاری باشد).
• متد Lead.run(query) نیروهای کار را در تردها راه می‌اندازد، منتظر اتمام کارشان می‌ماند و نتایج را ترکیب می‌کند.

اجرا:

python3 code/main.py

خروجی برنامه شامل طرح کلی، ردگیری محاسبات (trace) نیروهای کار موازی همراه با زمان شروع و پایان، و ترکیب نهایی است. در خروجی مزیت زمان واقعی اجرا را می‌بینید: سه نیروی کار 0.3 ثانیه‌ای در حدود 0.35 ثانیه اجرا می‌شوند، نه 0.9 ثانیه.

کاربرد عملی

فایل outputs/skill-supervisor-designer.md پرسش کاربر را می‌گیرد و یک طرح کامل برای الگوی سرپرست تحویل می‌دهد: پرامپت سیستمی سرپرست، نقش‌های نیروهای کار، قواعد خرد کردن پرسش به پرسش‌های فرعی، و قالب ترکیب نهایی. پیش از ساخت هر سیستم ایجنتی با ماهیت پژوهشی، از این فایل استفاده کنید.

آماده‌سازی برای استقرار

چک‌لیست پیش از استقرار الگوی سرپرست در محیط عملیاتی:

• جفت‌سازی مدل‌ها. سرپرست روی مدلی از رده‌ی استدلال بالا (کلاس Opus یا رده‌ی o3). نیروهای کار روی مدلی سریع‌تر و ارزان‌تر (Sonnet یا o4-mini).
• تایم‌اوت نیروی کار. هر نیرویی که زمان اجرای آن از 2 برابر میانه‌ی زمان معمول بیشتر شود متوقف می‌شود؛ سرپرست یا با دامنه‌ای محدودتر دوباره آن را می‌سازد یا بدون آن کار را ادامه می‌دهد.
• سقف توکن برای هر نیروی کار. تعیین یک حد سخت (مثلاً 10 برابر ورودی مورد انتظار در مرحله‌ی ترکیب)، جلوی هدررفت بودجه توسط یک نیروی کار مهارنشدنی را می‌گیرد.
• مشاهده‌پذیری. برنامه‌ی سرپرست، فراخوانی‌های ابزار هر نیروی کار و فرایند ترکیب را ردگیری کنید. این کار پایه‌ی اصلی هرگونه اشکال‌زدایی پس از اجراست.
• استقرار رنگین‌کمانی. ایجنت‌های طولانی‌مدت و دارای وضعیت، به جای جابه‌جایی آنی نیاز به انتقال تدریجی نسخه دارند.

تمرین‌ها

1. فایل code/main.py را اجرا کنید؛ سپس سرپرست را طوری تغییر دهید که به جای 3 نیرو، 5 نیروی کار بسازد. تأثیر آن را روی زمان واقعی اجرا بررسی کنید. در این دمو، در چه تعداد نیروی کار، اورهد ساخت ترد از مزیت موازی‌سازی بیشتر می‌شود؟
2. یک تایم‌اوت برای نیروی کار پیاده کنید: هر نیرویی را که اجرای آن بیش از 0.5 ثانیه طول کشید متوقف کنید و از سرپرست بخواهید نتایج باقی‌مانده را ترکیب کند. برای تشخیص متوقف شدن یک نیرو به چه ابزار مشاهده‌پذیری‌ای نیاز دارید؟
3. یک مرحله‌ی تشخیص تعارض به ترکیب سرپرست اضافه کنید: اگر دو نیروی کار پاسخ‌های متناقضی دادند، سرپرست به جای انتخاب یکی از آن‌ها، این اختلاف را صراحتاً قید کند. چطور می‌توانید این تعارض را بدون فراخوانی یک مدل زبانی تشخیص دهید؟
4. پست مهندسی سیستم Research شرکت Anthropic را بخوانید. سه مورد از راهکارهایی را که این دموی ساده برای رسیدن به محیط عملیاتی باید در پیش بگیرد فهرست کنید.
5. تابع create_supervisor (قدیمی) در LangGraph را با رویکرد جدید مبتنی بر فراخوانی ابزار مقایسه کنید. کدام روش کنترل بهتری روی ورودی‌های سرپرست می‌دهد؟ چرا Anthropic به جای بافتار خام نیروهای کار، صراحتاً فقط پاسخ‌های فرعی را وارد مرحله‌ی ترکیب می‌کند؟

اصطلاحات کلیدی

مطالعه‌ی بیشتر

• وبلاگ مهندسی Anthropic — ساخت سیستم پژوهشی چندایجنت — مرجع اصلی محیط عملیاتی برای الگوی سرپرست
• جریان‌های کاری و ایجنت‌های LangGraph — پیاده‌سازی سرپرست با فراخوانی ابزار که اکنون فرم پیشنهادی است
• مرجع سرپرست در LangGraph — تابع کمکی قدیمی که هنوز در محیط عملیاتی سال 2026 استفاده می‌شود
• دفترچه‌ی راهنمای OpenAI — هماهنگ‌سازی ایجنت‌ها: روتین‌ها و دست‌به‌دست‌کردن — نسخه‌ای از الگوی سرپرست بر پایه‌ی دست‌به‌دست‌کردن وظایف