Екипи от агенти

Координиране на няколко Claude Code сесии като един екип — експерименталният флаг, пускане на съотборници, agent панелът, display режимите, общият списък със задачи, permissions, лимити и цена.

Agent team е няколко Claude Code сесии, които работят заедно. Твоята сесия става lead: тя пуска съотборниците, раздава задачи и обобщава резултатите. Всеки съотборник е пълноценна, самостоятелна Claude Code инстанция със собствен контекстен прозорец.

Това, което го прави екип, а не просто разпръскване: съотборниците си пишат директно един на друг и споделят един списък със задачи, а ти можеш да отвориш кой да е от тях и да говориш с него, без да минаваш през lead-а.

Включване

Задаваш променливата в средата на shell-а си или в settings.json:

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

Това е цялата настройка. От v2.1.178 няма отделна стъпка за създаване на екип — екипът се формира с пускането на първия съотборник, а директориите му се чистят при изход от сесията. Старите TeamCreate и TeamDelete tools вече не съществуват.

Срещу субагентите

И двете паралелизират работа. Изборът е дали работниците трябва да си говорят помежду си:

Най-силните случаи са паралелно проучване и ревю, нови модули, при които всеки съотборник владее различни файлове, дебъгване с конкуриращи се хипотези и промени през няколко слоя — frontend, backend и тестове.

Екипите носят разход за координация. За последователна работа, промени по един и същ файл или силно зависими стъпки печели една сесия или обикновени субагенти. Когато самият план трябва да живее в код, а не в контекста на lead-а, посягаш към динамичен workflow.

Пускане на екип

Описваш задачата и съотборниците, които искаш, със свои думи. Claude ги пуска, попълва общия списък със задачи и накрая обобщава находките.

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

Claude може и сам да предложи екип, когато задачата изглежда паралелна — ти потвърждаваш. Никога не пуска съотборници без одобрение.

Писане на промпта за пускане

Съотборникът се събужда с проекта ти и без спомен за разговора ви, така че промптът за пускане е целият брифинг. Форма, която работи:

Goal: build a working full-stack app with a REST API and a React frontend.
The end result should run on http://localhost:3000 with users and posts,
plus a QA report confirming it works.

Spawn 3 teammates using Sonnet:

1. Backend dev — build the REST API in src/api/. Create routes for users
   and posts. When done, message the frontend dev with the endpoints.
2. Frontend dev — build the React UI in src/components/. Wait for the
   backend dev's message with the API contract, then wire up the fetches.
3. QA — write tests in tests/. Start with unit scaffolding, then add
   integration tests once backend and frontend report done.

Final deliverables:
- a running app on http://localhost:3000
- tests/report.md with pass/fail results
- docs/build-summary.md — what was built, key decisions, how to run it

Двете зависимости са изписани. „Message the frontend dev“ и „wait for the backend dev’s message“ са инструкции — екипът не изважда графа на предаванията от реда, в който си изброил ролите.

Agent панелът

Съотборниците се изброяват под полето за въвеждане в терминала на lead-а.

Display режими

По подразбиране е "in-process" (преди v2.1.179 беше "auto", така че обновени сесии, които преди са отваряли split panes, вече остават в един терминал). Задава се с teammateMode в ~/.claude/settings.json:

{
  "teammateMode": "auto"
}

claude --teammate-mode auto задава режима за една сесия. Флагът е експериментален и не се появява в claude --help.

Управление на екипа

Съотборници и модели

Claude сам преценява броя според задачата или ти го казваш изрично:

Spawn 4 teammates to refactor these modules in parallel. Use Sonnet for
each teammate.

Съотборниците не наследяват избора на lead-а от /model по подразбиране — това е редът Default teammate model в /config, където Default (leader’s model) ги кара да следват lead-а. Затова пък наследяват неговото effort ниво (в split-pane режим от v2.1.186).

Одобрение на план

За рискована работа накарай съотборника първо да планира. Той остава в read-only plan mode, докато lead-ът не одобри:

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

Отхвърлените планове се връщат с обратна връзка, преработват се и се подават отново. Lead-ът решава самостоятелно, затова сложи критериите си в промпта — „only approve plans that include test coverage“, „reject plans that modify the database schema“.

Директен разговор със съотборник

Избираш го в панела и натискаш Enter (или кликваш неговия pane в split режим). Докато гледаш in-process съотборник, обикновеният текст и skills отиват при него, но вградените команди пак се изпълняват в сесията на lead-а.

Преизползване на subagent дефиниции

Можеш да пуснеш съотборник от коя да е subagent дефиниция — project, user, plugin или дефинирана през CLI — като споменеш типа по име:

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

Съотборникът спазва tools allowlist-а и model от дефиницията, а тялото ѝ се добавя към системния му промпт, вместо да го замества. SendMessage и tools за задачите остават достъпни дори при ограничителен tools.

Спиране на съотборник

Ask the researcher teammate to shut down

Lead-ът изпраща заявка за спиране; съотборникът може да я приеме и да излезе чисто или да я откаже с обяснение. Няма отделна стъпка за почистване — общите директории си отиват с края на сесията.

Задачи и съобщения

Общият списък със задачи е повърхността за координация. Задачите са pending, in progress или completed и могат да зависят една от друга — pending задача с неразрешени зависимости не може да бъде взета. Lead-ът може да възлага изрично или съотборникът сам си взема следващата свободна и незаблокирана задача, щом приключи текущата. Взимането минава през file locking, за да не грабнат двама една и съща задача, а завършването автоматично отблокира зависимите.

Съобщенията са push, не poll:

• Автоматична доставка — съобщенията между агентите пристигат, без lead-ът да ги дърпа.
• Idle известия — спрелият съотборник уведомява lead-а. От v2.1.198 ход, който приключва с API грешка, докладва провала и текста на грешката, вместо да изглежда като нормален край.
• По име — всеки съотборник може да пише на всеки друг по име. Няма broadcast: за да стигнеш до всички, изпращаш по едно съобщение на получател. Кажи на lead-а как да кръсти всеки, ако искаш имена, към които после да се обръщаш.

Всеки съотборник зарежда CLAUDE.md, MCP сървъри и skills като нормална сесия, плюс промпта при пускането. Историята на разговора на lead-а не се пренася, затова слагай специфичните детайли в промпта при пускането.

Hooks

Гейтовете за качество висят на три hook-а; изход с код 2 връща обратна връзка:

Полето team_name в тези payload-и носи името, изведено от сесията, и е deprecated.

Къде живее всичко

Името на екипа се извежда от сесията: session- плюс първите осем знака от session ID-то.

config.json пази runtime състояние — session ID-та, tmux pane ID-та и масив members с имена и agent ID-та (записът на lead-а винаги носи agent type team-lead). Съотборниците го четат, за да се открият взаимно. Не го редактирай на ръка и не го пиши предварително; следващата промяна на състоянието те презаписва. Няма еквивалент на ниво проект — .claude/teams/teams.json в репото ти е най-обикновен файл.

Директорията с конфигурацията на екипа се маха при край на сесията. Директорията със задачите остава, никога не се качва никъде и следва същото cleanupPeriodDays задържане като транскриптите на сесиите — така продължена сесия си пази задачите.

Permissions

Съотборниците тръгват с permission настройките на lead-а — включително --dangerously-skip-permissions, ако lead-ът работи с него. Можеш да смениш режима на отделен съотборник след пускането, но не и да зададеш различни режими при самото пускане. Permission промптовете на съотборниците изскачат в сесията на lead-а, така че ги одобряваш там.

Когато нещо се обърка

Таблицата отдолу е за грешки в начина, по който екипът е бил пуснат. За това, което екипите наистина не могат, виж Ограничения.

Ограничения

Размер и цена

Разходът на токени расте приблизително линейно с броя активни съотборници — всеки е отделна Claude инстанция със собствен контекстен прозорец. За проучване, ревю и нова функционалност обикновено си струва; за рутинни задачи една сесия излиза по-евтино.