هماهنگ‌سازی تیم‌هایی از نشست‌های Claude Code

تیم‌های ایجنت به تو امکان می‌دهند چند نمونه‌ی Claude Code را که با هم کار می‌کنند هماهنگ کنی. یک نشست نقشِ سرتیمِ (team lead) را بازی می‌کند، کار را هماهنگ می‌کند، وظایف را تخصیص می‌دهد و نتیجه‌ها را جمع‌بندی می‌کند. هم‌تیمی‌ها (teammates) مستقل کار می‌کنند، هرکدام در پنجره‌ی کانتکستِ خودش، و مستقیماً با هم ارتباط برقرار می‌کنند.

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

این صفحه این‌ها را پوشش می‌دهد:

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

کِی از تیم‌های ایجنت استفاده کنیم

تیم‌های ایجنت بیشترین اثر را در وظایفی دارند که کاوشِ موازی ارزشِ واقعی اضافه می‌کند. برای سناریوهای کامل مثال‌های موردِ استفاده را ببین. قوی‌ترین موارد این‌ها هستند:

پژوهش و بازبینی: چند هم‌تیمی می‌توانند هم‌زمان جنبه‌های مختلفِ یک مسئله را بررسی کنند، سپس یافته‌های یکدیگر را به اشتراک بگذارند و به چالش بکشند
ماژول‌ها یا قابلیت‌های جدید: هر هم‌تیمی می‌تواند بخشِ جداگانه‌ای را بدونِ تداخل با دیگری برعهده بگیرد
اشکال‌زدایی با فرضیه‌های رقیب: هم‌تیمی‌ها نظریه‌های مختلف را به‌صورتِ موازی آزمایش می‌کنند و سریع‌تر به پاسخ همگرا می‌شوند
هماهنگیِ بین‌لایه‌ای: تغییراتی که frontend، backend و تست‌ها را در بر می‌گیرند، که هرکدام را یک هم‌تیمیِ متفاوت برعهده دارد

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

مقایسه با ساب‌ایجنت‌ها

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

Diagram comparing subagent and agent team architectures. Subagents are spawned by the main agent, do work, and report results back. Agent teams coordinate through a shared task list, with teammates communicating directly with each other.

	ساب‌ایجنت‌ها	تیم‌های ایجنت
کانتکست	پنجره‌ی کانتکستِ خود؛ نتیجه‌ها به فراخواننده برمی‌گردند	پنجره‌ی کانتکستِ خود؛ کاملاً مستقل
ارتباط	فقط نتیجه‌ها را به ایجنتِ اصلی گزارش می‌دهند	هم‌تیمی‌ها مستقیماً با هم پیام رد و بدل می‌کنند
هماهنگی	ایجنتِ اصلی همه‌ی کار را مدیریت می‌کند	فهرستِ وظایفِ مشترک با خودهماهنگی
بهترین برای	وظایفِ متمرکز که فقط نتیجه اهمیت دارد	کارِ پیچیده که نیازمندِ بحث و همکاری است
هزینه‌ی توکن	کمتر: نتیجه‌ها به کانتکستِ اصلی خلاصه می‌شوند	بیشتر: هر هم‌تیمی یک نمونه‌ی جداگانه‌ی Claude است

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

فعال‌سازیِ تیم‌های ایجنت

تیم‌های ایجنت به‌صورتِ پیش‌فرض غیرفعال‌اند. با تنظیمِ متغیرِ محیطیِ CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS روی 1، یا در محیطِ شِل یا از طریقِ settings.json، آن‌ها را فعال کن:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

اولین تیمِ ایجنتت را شروع کن

پس از فعال‌سازیِ تیم‌های ایجنت، به Claude بگو یک تیمِ ایجنت بسازد و وظیفه و ساختارِ تیمی را که می‌خواهی به زبانِ طبیعی توصیف کن. Claude تیم را می‌سازد، هم‌تیمی‌ها را راه‌اندازی می‌کند و بر اساسِ پرامپتت کار را هماهنگ می‌کند.

این مثال خوب کار می‌کند چون سه نقش مستقل‌اند و می‌توانند مسئله را بدونِ انتظار برای یکدیگر کاوش کنند:

I'm designing a CLI tool that helps developers track TODO comments across
their codebase. Create an agent team to explore this from different angles: one
teammate on UX, one on technical architecture, one playing devil's advocate.

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

ترمینالِ سرتیم همه‌ی هم‌تیمی‌ها و کاری که می‌کنند را فهرست می‌کند. از Shift+Down برای چرخش بینِ هم‌تیمی‌ها و پیام‌دادنِ مستقیم به آن‌ها استفاده کن. پس از آخرین هم‌تیمی، Shift+Down به سرتیم برمی‌گردد.

اگر می‌خواهی هر هم‌تیمی در پِینِ تقسیم‌شده‌ی (split pane) خودش باشد، انتخابِ یک حالتِ نمایش را ببین.

کنترلِ تیمِ ایجنتت

آن‌چه می‌خواهی را به زبانِ طبیعی به سرتیم بگو. او بر اساسِ دستورالعمل‌هایت هماهنگیِ تیم، تخصیصِ وظیفه و واگذاری را انجام می‌دهد.

انتخابِ یک حالتِ نمایش

تیم‌های ایجنت از دو حالتِ نمایش پشتیبانی می‌کنند:

درون‌فرآیندی (in-process): همه‌ی هم‌تیمی‌ها درونِ ترمینالِ اصلیت اجرا می‌شوند. از Shift+Down برای چرخش بینِ هم‌تیمی‌ها استفاده کن و تایپ کن تا مستقیماً به آن‌ها پیام بدهی. در هر ترمینالی کار می‌کند، بدونِ راه‌اندازیِ اضافه.
پِین‌های تقسیم‌شده (split panes): هر هم‌تیمی پِینِ خودش را می‌گیرد. می‌توانی خروجیِ همه را یکجا ببینی و روی یک پِین کلیک کنی تا مستقیماً تعامل کنی. نیازمندِ tmux یا iTerm2 است.

پیش‌فرض "auto" است که اگر از قبل درونِ یک نشستِ tmux باشی یا ترمینالت iTerm2 باشد از پِین‌های تقسیم‌شده استفاده می‌کند، و در غیرِ این‌صورت درون‌فرآیندی. تنظیمِ "tmux" حالتِ پِینِ تقسیم‌شده را فعال می‌کند و بر اساسِ ترمینالت به‌صورتِ خودکار تشخیص می‌دهد از tmux یا iTerm2 استفاده کند. برای بازنویسی، teammateMode را در ~/.claude/settings.json تنظیم کن:

{
  "teammateMode": "in-process"
}

برای اجبارِ حالتِ درون‌فرآیندی برای یک نشستِ تکی، آن را به‌عنوانِ یک پرچم پاس بده:

claude --teammate-mode in-process

حالتِ پِینِ تقسیم‌شده نیازمندِ یا tmux یا iTerm2 با it2 CLI است. برای نصبِ دستی:

tmux: از طریقِ مدیرِ بسته‌ی سیستمت نصب کن. برای دستورالعمل‌های مختصِ پلتفرم tmux wiki را ببین.
iTerm2: it2 CLI را نصب کن، سپس Python API را در iTerm2 → Settings → General → Magic → Enable Python API فعال کن.

مشخص‌کردنِ هم‌تیمی‌ها و مدل‌ها

Claude تعدادِ هم‌تیمی‌ها را بر اساسِ وظیفه‌ات تصمیم می‌گیرد، یا می‌توانی دقیقاً آن‌چه می‌خواهی را مشخص کنی:

Create a team with 4 teammates to refactor these modules in parallel.
Use Sonnet for each teammate.

هم‌تیمی‌ها به‌صورتِ پیش‌فرض انتخابِ /modelِ سرتیم را به ارث نمی‌برند. برای تغییرِ مدلی که وقتی پرامپت مشخصش نمی‌کند استفاده می‌شود، Default teammate model را در /config تنظیم کن. Default (leader’s model) را انتخاب کن تا هم‌تیمی‌ها از مدلِ فعلیِ سرتیم پیروی کنند.

الزامِ تأییدِ طرح برای هم‌تیمی‌ها

برای وظایفِ پیچیده یا پرریسک، می‌توانی هم‌تیمی‌ها را ملزم کنی پیش از پیاده‌سازی طرح بریزند. هم‌تیمی در حالتِ planِ فقط‌خواندنی کار می‌کند تا سرتیم رویکردش را تأیید کند:

Spawn an architect teammate to refactor the authentication module.
Require plan approval before they make any changes.

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

سرتیم تصمیماتِ تأیید را خودمختار می‌گیرد. برای اثرگذاری بر قضاوتِ سرتیم، در پرامپتت معیار بده، مثل «only approve plans that include test coverage» یا «reject plans that modify the database schema».

مستقیماً با هم‌تیمی‌ها حرف بزن

هر هم‌تیمی یک نشستِ کامل و مستقلِ Claude Code است. می‌توانی به هر هم‌تیمی مستقیماً پیام بدهی تا دستورالعمل‌های بیشتری بدهی، پرسش‌های پیگیری بپرسی، یا رویکردشان را تغییر دهی.

حالتِ درون‌فرآیندی: از Shift+Down برای چرخش بینِ هم‌تیمی‌ها استفاده کن، سپس تایپ کن تا برایشان پیام بفرستی. Enter را بزن تا نشستِ یک هم‌تیمی را ببینی، سپس Escape تا نوبتِ فعلی‌اش را قطع کنی. Ctrl+T را بزن تا فهرستِ وظایف را بازوبسته کنی.
حالتِ پِینِ تقسیم‌شده: روی پِینِ یک هم‌تیمی کلیک کن تا مستقیماً با نشستش تعامل کنی. هر هم‌تیمی نمای کاملی از ترمینالِ خودش دارد.

تخصیص و برداشتنِ وظایف

فهرستِ وظایفِ مشترک کار را در سراسرِ تیم هماهنگ می‌کند. سرتیم وظایف را می‌سازد و هم‌تیمی‌ها روی آن‌ها کار می‌کنند. وظایف سه حالت دارند: در انتظار، در حالِ انجام، و کامل‌شده. وظایف می‌توانند به وظایفِ دیگر هم وابسته باشند: یک وظیفه‌ی در انتظار با وابستگی‌های حل‌نشده تا کامل‌شدنِ آن وابستگی‌ها نمی‌تواند برداشته شود.

سرتیم می‌تواند وظایف را صراحتاً تخصیص دهد، یا هم‌تیمی‌ها می‌توانند خودشان بردارند:

سرتیم تخصیص می‌دهد: به سرتیم بگو کدام وظیفه را به کدام هم‌تیمی بدهد
خودبرداشتن: پس از تمام‌کردنِ یک وظیفه، یک هم‌تیمی خودش وظیفه‌ی بعدیِ تخصیص‌نیافته و آزاد را برمی‌دارد

برداشتنِ وظیفه از قفلِ فایل استفاده می‌کند تا از شرایطِ رقابتی (race condition) جلوگیری شود وقتی چند هم‌تیمی هم‌زمان تلاش می‌کنند یک وظیفه را بردارند.

خاموش‌کردنِ هم‌تیمی‌ها

برای پایان‌دادنِ زیبا به نشستِ یک هم‌تیمی، با نامش به او اشاره کن. مثلاً، با هم‌تیمی‌ای به‌نامِ researcher:

Ask the researcher teammate to shut down

سرتیم یک درخواستِ خاموش‌سازی می‌فرستد. هم‌تیمی می‌تواند تأیید کند و زیبا خارج شود، یا با توضیح ردش کند.

پاک‌سازیِ تیم

وقتی کارت تمام شد، از سرتیم بخواه پاک‌سازی کند:

Clean up the team

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

اعمالِ دروازه‌های کیفیت با hookها

از hookها برای اعمالِ قواعد وقتی هم‌تیمی‌ها کار را تمام می‌کنند یا وظایف ساخته یا کامل می‌شوند استفاده کن:

TeammateIdle: وقتی یک هم‌تیمی نزدیکِ بیکارشدن است اجرا می‌شود. با کدِ خروجِ 2 خارج شو تا بازخورد بفرستی و هم‌تیمی را به کار نگه داری.
TaskCreated: وقتی یک وظیفه در حالِ ساخته‌شدن است اجرا می‌شود. با کدِ خروجِ 2 خارج شو تا از ساخت جلوگیری کنی و بازخورد بفرستی.
TaskCompleted: وقتی یک وظیفه در حالِ کامل‌علامت‌خوردن است اجرا می‌شود. با کدِ خروجِ 2 خارج شو تا از تکمیل جلوگیری کنی و بازخورد بفرستی.

تیم‌های ایجنت چطور کار می‌کنند

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

Claude چطور تیم‌های ایجنت را شروع می‌کند

دو راه برای شروعِ تیم‌های ایجنت وجود دارد:

تو درخواستِ تیم می‌دهی: به Claude وظیفه‌ای بده که از کارِ موازی سود می‌برد و صراحتاً یک تیمِ ایجنت بخواه. Claude بر اساسِ دستورالعمل‌هایت یکی می‌سازد.
Claude تیم را پیشنهاد می‌دهد: اگر Claude تشخیص دهد وظیفه‌ات از کارِ موازی سود می‌برد، ممکن است ساختِ یک تیم را پیشنهاد دهد. پیش از پیش‌رفتن، تأیید می‌کنی.

در هر دو حالت، تو در کنترل می‌مانی. Claude بدونِ تأییدِ تو تیم نمی‌سازد.

معماری

یک تیمِ ایجنت از این‌ها تشکیل شده:

جزء	نقش
سرتیم	نشستِ اصلیِ Claude Code که تیم را می‌سازد، هم‌تیمی‌ها را راه‌اندازی می‌کند و کار را هماهنگ می‌کند
هم‌تیمی‌ها	نمونه‌های جداگانه‌ی Claude Code که هرکدام روی وظایفِ تخصیص‌داده‌شده کار می‌کنند
فهرستِ وظایف	فهرستِ مشترکِ کارها که هم‌تیمی‌ها برمی‌دارند و کامل می‌کنند
صندوقِ پیام (Mailbox)	سیستمِ پیام‌رسانی برای ارتباطِ بینِ ایجنت‌ها

برای گزینه‌های پیکربندیِ نمایش انتخابِ یک حالتِ نمایش را ببین. پیام‌های هم‌تیمی‌ها به‌صورتِ خودکار به سرتیم می‌رسند.

سیستم وابستگی‌های وظایف را خودکار مدیریت می‌کند. وقتی یک هم‌تیمی وظیفه‌ای را کامل می‌کند که وظایفِ دیگر به آن وابسته‌اند، وظایفِ مسدودشده بدونِ دخالتِ دستی آزاد می‌شوند.

تیم‌ها و وظایف به‌صورتِ محلی ذخیره می‌شوند:

پیکربندیِ تیم: ~/.claude/teams/{team-name}/config.json
فهرستِ وظایف: ~/.claude/tasks/{team-name}/

Claude Code وقتی یک تیم می‌سازی هر دوی این‌ها را خودکار تولید می‌کند و همان‌طور که هم‌تیمی‌ها می‌پیوندند، بیکار می‌شوند یا می‌روند آن‌ها را به‌روز می‌کند. هر دو دایرکتوری فقط تا وقتی تیم فعال است وجود دارند: وقتی تیم پاک‌سازی می‌شود یا نشست پایان می‌یابد حذف می‌شوند. پیکربندیِ تیم وضعیتِ زمانِ اجرا مثل شناسه‌های نشست و شناسه‌های پِینِ tmux را نگه می‌دارد، پس آن را دستی ویرایش نکن یا از پیش ننویس: تغییراتت در به‌روزرسانیِ بعدیِ وضعیت بازنویسی می‌شوند.

برای تعریفِ نقش‌های قابلِ‌استفاده‌ی مجددِ هم‌تیمی، به‌جایش از تعریفِ ساب‌ایجنت‌ها استفاده کن.

پیکربندیِ تیم یک آرایه‌ی members شاملِ نام، شناسه‌ی ایجنت و نوعِ ایجنتِ هر هم‌تیمی دارد. هم‌تیمی‌ها می‌توانند این فایل را بخوانند تا سایرِ اعضای تیم را کشف کنند.

هیچ معادلِ سطحِ‌پروژه‌ای برای پیکربندیِ تیم وجود ندارد. فایلی مثل .claude/teams/teams.json در دایرکتوریِ پروژه‌ات به‌عنوانِ پیکربندی شناخته نمی‌شود؛ Claude آن را یک فایلِ معمولی تلقی می‌کند.

استفاده از تعریفِ ساب‌ایجنت‌ها برای هم‌تیمی‌ها

هنگامِ راه‌اندازیِ یک هم‌تیمی، می‌توانی به یک نوعِ ساب‌ایجنت از هر محدوده‌ی ساب‌ایجنت ارجاع بدهی: پروژه، کاربر، پلاگین، یا تعریف‌شده در CLI. این به تو امکان می‌دهد یک نقش را یک‌بار تعریف کنی، مثلِ security-reviewer یا test-runner، و هم به‌عنوانِ ساب‌ایجنتِ واگذارشده و هم به‌عنوانِ هم‌تیمیِ تیمِ ایجنت دوباره از آن استفاده کنی.

برای استفاده از تعریفِ یک ساب‌ایجنت، هنگامِ درخواست از Claude برای راه‌اندازیِ هم‌تیمی، با نامش به آن اشاره کن:

Spawn a teammate using the security-reviewer agent type to audit the auth module.

هم‌تیمی به allowlistِ tools و modelِ آن تعریف پایبند است، و بدنه‌ی تعریف به‌عنوانِ دستورالعملِ اضافی به سیستم‌پرامپتِ هم‌تیمی پیوست می‌شود نه این‌که جایش را بگیرد. ابزارهای هماهنگیِ تیم مثلِ SendMessage و ابزارهای مدیریتِ وظیفه همیشه برای یک هم‌تیمی در دسترس‌اند، حتی وقتی tools سایرِ ابزارها را محدود می‌کند.

دسترسی‌ها

هم‌تیمی‌ها با تنظیماتِ دسترسیِ سرتیم شروع می‌کنند. اگر سرتیم با --dangerously-skip-permissions اجرا شود، همه‌ی هم‌تیمی‌ها هم همین‌طور. پس از راه‌اندازی، می‌توانی حالت‌های تک‌تکِ هم‌تیمی‌ها را تغییر دهی، اما نمی‌توانی هنگامِ راه‌اندازی حالت‌های هر-هم‌تیمی را تعیین کنی.

کانتکست و ارتباط

هر هم‌تیمی پنجره‌ی کانتکستِ خودش را دارد. وقتی راه‌اندازی می‌شود، یک هم‌تیمی همان کانتکستِ پروژه را که یک نشستِ معمولی بارگذاری می‌کند: CLAUDE.md، سرورهای MCP و skillها. همچنین پرامپتِ راه‌اندازی را از سرتیم دریافت می‌کند. تاریخچه‌ی گفتگوی سرتیم منتقل نمی‌شود.

هم‌تیمی‌ها چطور اطلاعات را به اشتراک می‌گذارند:

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

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

مصرفِ توکن

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

مثال‌های موردِ استفاده

این مثال‌ها نشان می‌دهند تیم‌های ایجنت چطور وظایفی را که کاوشِ موازی ارزش اضافه می‌کند مدیریت می‌کنند.

اجرای یک بازبینیِ کدِ موازی

یک بازبینِ تنها معمولاً هر بار به‌سمتِ یک نوع مسئله گرایش پیدا می‌کند. تقسیمِ معیارهای بازبینی به دامنه‌های مستقل یعنی امنیت، کارایی و پوششِ تست همه هم‌زمان توجهِ کامل بگیرند. این پرامپت به هر هم‌تیمی یک عدسیِ متمایز می‌دهد تا با هم تداخل نکنند:

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

هر بازبین از همان PR کار می‌کند اما فیلترِ متفاوتی اعمال می‌کند. سرتیم پس از تمام‌شدنِ هر سه، یافته‌ها را در سراسرشان جمع‌بندی می‌کند.

بررسی با فرضیه‌های رقیب

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

Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses. Have them talk to
each other to try to disprove each other's theories, like a scientific
debate. Update the findings doc with whatever consensus emerges.

ساختارِ بحث، مکانیکِ کلیدی اینجاست. بررسیِ ترتیبی از لنگرانداختن (anchoring) رنج می‌برد: وقتی یک نظریه کاوش شد، بررسیِ بعدی به‌سمتِ آن سوگیری می‌کند.

با چند بررسی‌کننده‌ی مستقل که فعالانه تلاش می‌کنند یکدیگر را رد کنند، نظریه‌ای که جان به‌در می‌برد بسیار محتمل‌تر است که ریشه‌ی واقعیِ مسئله باشد.

بهترین شیوه‌ها

به هم‌تیمی‌ها کانتکستِ کافی بده

هم‌تیمی‌ها کانتکستِ پروژه را خودکار بارگذاری می‌کنند، شاملِ CLAUDE.md، سرورهای MCP و skillها، اما تاریخچه‌ی گفتگوی سرتیم را به ارث نمی‌برند. برای جزئیات کانتکست و ارتباط را ببین. جزئیاتِ مختصِ وظیفه را در پرامپتِ راه‌اندازی بگنجان:

Spawn a security reviewer teammate with the prompt: "Review the authentication module
at src/auth/ for security vulnerabilities. Focus on token handling, session
management, and input validation. The app uses JWT tokens stored in
httpOnly cookies. Report any issues with severity ratings."

اندازه‌ی مناسبِ تیم را انتخاب کن

هیچ حدِ سختی برای تعدادِ هم‌تیمی‌ها وجود ندارد، اما محدودیت‌های عملی صدق می‌کنند:

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

برای بیشترِ ورک‌فلوها با ۳ تا ۵ هم‌تیمی شروع کن. این، کارِ موازی را با هماهنگیِ قابلِ‌مدیریت متعادل می‌کند. مثال‌های این راهنما از ۳ تا ۵ هم‌تیمی استفاده می‌کنند چون این بازه در انواعِ مختلفِ وظیفه خوب کار می‌کند.

داشتنِ ۵ تا ۶ وظیفه به‌ازای هر هم‌تیمی همه را بدونِ جابه‌جاییِ بیش‌از‌حدِ کانتکست بهره‌ور نگه می‌دارد. اگر ۱۵ وظیفه‌ی مستقل داری، ۳ هم‌تیمی نقطه‌ی شروعِ خوبی است.

فقط وقتی مقیاس را بالا ببر که کار واقعاً از کارِ هم‌زمانِ هم‌تیمی‌ها سود می‌برد. سه هم‌تیمیِ متمرکز اغلب از پنج هم‌تیمیِ پراکنده بهتر عمل می‌کنند.

وظایف را به اندازه‌ی مناسب تعیین کن

خیلی کوچک: سربارِ هماهنگی از سود بیشتر است
خیلی بزرگ: هم‌تیمی‌ها بدونِ بازرسی خیلی طولانی کار می‌کنند و ریسکِ تلاشِ هدررفته را بالا می‌برند
درست‌اندازه: واحدهای خودبسنده که خروجیِ روشنی تولید می‌کنند، مثلِ یک تابع، یک فایلِ تست، یا یک بازبینی

منتظرِ تمام‌شدنِ کارِ هم‌تیمی‌ها بمان

گاهی سرتیم به‌جای انتظار برای هم‌تیمی‌ها، خودش شروع به پیاده‌سازیِ وظایف می‌کند. اگر این را دیدی:

Wait for your teammates to complete their tasks before proceeding

با پژوهش و بازبینی شروع کن

اگر تازه با تیم‌های ایجنت آشنا می‌شوی، با وظایفی شروع کن که مرزهای روشن دارند و به نوشتنِ کد نیاز ندارند: بازبینیِ یک PR، پژوهش درباره‌ی یک کتابخانه، یا بررسیِ یک باگ. این وظایف ارزشِ کاوشِ موازی را بدونِ چالش‌های هماهنگی‌ای که با پیاده‌سازیِ موازی می‌آید نشان می‌دهند.

از تعارضِ فایل پرهیز کن

دو هم‌تیمی که یک فایل را ویرایش می‌کنند به بازنویسی منجر می‌شود. کار را طوری بشکن که هر هم‌تیمی مجموعه‌ی متفاوتی از فایل‌ها را برعهده داشته باشد.

پایش و هدایت کن

پیشرفتِ هم‌تیمی‌ها را بررسی کن، رویکردهایی را که کار نمی‌کنند به مسیر برگردان، و یافته‌ها را همان‌طور که می‌رسند جمع‌بندی کن. رهاکردنِ یک تیم بدونِ نظارت برای مدتِ طولانی ریسکِ تلاشِ هدررفته را بالا می‌برد.

عیب‌یابی

ظاهرنشدنِ هم‌تیمی‌ها

اگر پس از درخواست از Claude برای ساختِ تیم، هم‌تیمی‌ها ظاهر نمی‌شوند:

در حالتِ درون‌فرآیندی، هم‌تیمی‌ها ممکن است از قبل در حالِ اجرا باشند اما دیده نشوند. Shift+Down را بزن تا بینِ هم‌تیمی‌های فعال بچرخی.
بررسی کن وظیفه‌ای که به Claude دادی به‌اندازه‌ی کافی پیچیده بوده که توجیهِ یک تیم باشد. Claude بر اساسِ وظیفه تصمیم می‌گیرد آیا هم‌تیمی راه‌اندازی کند.
اگر صراحتاً پِین‌های تقسیم‌شده خواسته‌ای، مطمئن شو tmux نصب و در PATH تو در دسترس است:
Terminal window
```
which tmux
```
برای iTerm2، تأیید کن it2 CLI نصب است و Python API در ترجیحاتِ iTerm2 فعال است.

پرسش‌های دسترسیِ بیش‌از‌حد

درخواست‌های دسترسیِ هم‌تیمی‌ها به سرتیم می‌رسند، که می‌تواند اصطکاک ایجاد کند. پیش از راه‌اندازیِ هم‌تیمی‌ها، عملیاتِ رایج را در تنظیماتِ دسترسی از پیش تأیید کن تا قطع‌شدن‌ها کم شود.

توقفِ هم‌تیمی‌ها روی خطاها

هم‌تیمی‌ها ممکن است پس از مواجهه با خطا به‌جای بازیابی متوقف شوند. خروجی‌شان را با Shift+Down در حالتِ درون‌فرآیندی یا با کلیک روی پِین در حالتِ تقسیم‌شده بررسی کن، سپس یا:

مستقیماً دستورالعملِ بیشتری به آن‌ها بده
یک هم‌تیمیِ جایگزین راه‌اندازی کن تا کار را ادامه دهد

خاموش‌شدنِ سرتیم پیش از اتمامِ کار

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

نشست‌های یتیمِ tmux

اگر یک نشستِ tmux پس از پایانِ تیم باقی ماند، ممکن است کاملاً پاک‌سازی نشده باشد. نشست‌ها را فهرست کن و آن یکی را که تیم ساخته پایان بده:

tmux ls
tmux kill-session -t <session-name>

محدودیت‌ها

تیم‌های ایجنت آزمایشی‌اند. محدودیت‌های فعلی که باید از آن‌ها آگاه باشی:

بدونِ ادامه‌ی نشست با هم‌تیمی‌های درون‌فرآیندی: /resume و /rewind هم‌تیمی‌های درون‌فرآیندی را بازیابی نمی‌کنند. پس از ادامه‌ی یک نشست، سرتیم ممکن است تلاش کند به هم‌تیمی‌هایی پیام بدهد که دیگر وجود ندارند. اگر این اتفاق افتاد، به سرتیم بگو هم‌تیمی‌های جدید راه‌اندازی کند.
وضعیتِ وظیفه می‌تواند عقب بماند: هم‌تیمی‌ها گاهی موفق نمی‌شوند وظایف را کامل علامت بزنند، که وظایفِ وابسته را مسدود می‌کند. اگر یک وظیفه گیرکرده به‌نظر می‌رسد، بررسی کن آیا کار واقعاً انجام شده و وضعیتِ وظیفه را دستی به‌روز کن یا به سرتیم بگو به هم‌تیمی تلنگر بزند.
خاموش‌سازی می‌تواند کند باشد: هم‌تیمی‌ها پیش از خاموش‌شدن درخواست یا فراخوانیِ ابزارِ فعلی‌شان را تمام می‌کنند، که می‌تواند زمان ببرد.
یک تیم در یک زمان: یک سرتیم فقط می‌تواند یک تیم را مدیریت کند. پیش از ساختِ تیمِ جدید، تیمِ فعلی را پاک‌سازی کن.
بدونِ تیم‌های تودرتو: هم‌تیمی‌ها نمی‌توانند تیم یا هم‌تیمیِ خودشان را راه‌اندازی کنند. فقط سرتیم می‌تواند تیم را مدیریت کند.
سرتیم ثابت است: نشستی که تیم را می‌سازد برای تمامِ عمرِ آن سرتیم است. نمی‌توانی یک هم‌تیمی را به سرتیم ارتقا دهی یا رهبری را منتقل کنی.
دسترسی‌ها هنگامِ راه‌اندازی تعیین می‌شوند: همه‌ی هم‌تیمی‌ها با حالتِ دسترسیِ سرتیم شروع می‌کنند. می‌توانی حالت‌های تک‌تکِ هم‌تیمی‌ها را پس از راه‌اندازی تغییر دهی، اما نمی‌توانی هنگامِ راه‌اندازی حالت‌های هر-هم‌تیمی را تعیین کنی.
پِین‌های تقسیم‌شده نیازمندِ tmux یا iTerm2 هستند: حالتِ پیش‌فرضِ درون‌فرآیندی در هر ترمینالی کار می‌کند. حالتِ پِینِ تقسیم‌شده در ترمینالِ یکپارچه‌ی VS Code، Windows Terminal یا Ghostty پشتیبانی نمی‌شود.

گام‌های بعدی

رویکردهای مرتبط برای کارِ موازی و واگذاری را کاوش کن:

واگذاریِ سبک: ساب‌ایجنت‌ها ایجنت‌های کمکی را برای پژوهش یا تأیید درونِ نشستت راه‌اندازی می‌کنند، بهتر برای وظایفی که به هماهنگیِ بینِ ایجنت‌ها نیاز ندارند
نشست‌های موازیِ دستی: Git worktreeها به تو امکان می‌دهند چند نشستِ Claude Code را خودت بدونِ هماهنگیِ خودکارِ تیم اجرا کنی
مقایسه‌ی رویکردها: برای یک تفکیکِ کنار‌به‌کنار مقایسه‌ی ساب‌ایجنت در برابرِ تیمِ ایجنت را ببین