Agent teams: возможности и ограничения

1. Соблазн команды агентов и где он врёт

Если честно, agent team звучит очень соблазнительно. Один агент читает код, второй — тесты, третий — UI, четвёртый готовит review, и всё разом. Мини-отдел разработки без отпусков, кофе-пауз и дейли — слишком хорошо, чтобы быть правдой. И, как это часто бывает в инженерии, именно здесь я советую притормозить.

После fitness check вопрос такой: если параллельность оправдана, это несколько ролей (reviewer, investigator, executor) или уже тяжёлая форма с общим слоем координации? На этой границе появляется agent team. Проблема в том, что люди слышат team и мысленно дорисовывают то, чего система не обещала: коллективный разум, синхронизацию «как у живой команды», почти автономную разработку. На деле это координируемая группа изолированных контекстов — у каждого свой кусок задачи, своё окно контекста, свои ограничения, своя зона слепоты. Правило про coordination cost из первой лекции уровня здесь работает в полную силу: чем больше агентов, тем дороже координация, и оправдывать её надо реальной параллельностью и ясной проверкой.

Здесь полезна очень бытовая аналогия. Вы не наняли четырёх инженеров — вы рассадили четырёх помощников по отдельным комнатам, выдали каждому инструкцию и стопку бумаг и попросили вернуться с выводами. Ускоряет — но только если заранее решили, кто что смотрит, что считается результатом и кто соберёт всё обратно. Иначе это не команда. Это управляемый хаос.

2. Что такое agent team в этом курсе

Чтобы не путаться в терминах, сразу договоримся о строгом смысле. Agent team — это не «открыто несколько сессий» и не «я дважды вызвал subagent». Это организованная схема с координирующей ролью, участниками в отдельных контекстах, общим слоем координации и явными точками возврата результата человеку. Названия команд и кнопок в Claude Code меняются от версии к версии — важнее модель, чем интерфейс. По сути схема состоит из нескольких частей:

Здесь полезно один раз собрать иерархию, чтобы потом не склеивать разные уровни в одну кучу:

• multi-agent — зонтичное понятие для любой координированной работы, где больше одного worker context;
• agent team — тяжёлая форма multi-agent с lead, teammates, task list и handoff;
• orchestration pattern — схема ролей и артефактов, которая может существовать и без полноценной team-схемы;
• конкретную роль может исполнять main session, fresh session, subagent или человек.

Здесь особенно важно не перепутать agent team с просто параллельными вкладками. Три сеанса Claude с тремя запросами — ещё не team. Team начинается там, где есть координация, роли, общая точка сборки и ответственность за переходы.

Ещё одна важная деталь: даже если в продукте есть сущность team lead, человек всё равно стоит над конструкцией. Lead координирует, но владельцем результата, риска и merge остаётесь вы. AI-тимлид не уйдёт на больничный — но и не подпишет за вас release note, rollback plan и решение «можно ли это мержить».

3. Изолированные контексты: сила и предел

Сильная сторона agent team проста: каждый работает в своём контекстном окне. Один копается в тестах, второй читает UI-слой, третий разбирает конфиги — основная сессия не превращается в свалку гипотез, а человек получает компактные handoff-результаты.

Но именно здесь живёт и главное ограничение: изолированные контексты — не общая память. Нашёл один участник критичную деталь в orders/refund — второй о ней чудом не узнает. Деталь надо передать: через summary, task list, handoff или решение lead-роли. Общая доска задач — доска, а не коллективный разум из научной фантастики.

Вот простая схема того, как это выглядит на уровне потоков информации:

flowchart TD
    H[Человек] --> L[Lead / координатор]
    L --> A[Teammate A]
    L --> B[Teammate B]
    L --> C[Teammate C]
    A --> T[Общий task list / handoff]
    B --> T
    C --> T
    T --> L
    L --> H

На схеме видно главное: результаты не «перетекают» между участниками — они поднимаются в точку координации и возвращаются к человеку. Agent team умеет параллельно собирать части картины, но не гарантирует, что они сами сложатся в цельную систему. Именно поэтому зрелая team сначала исследует, а право на изменение получает кто-то один — после human checkpoint. Массовая параллельная запись в код эффектнее звучит, чем работает.

4. Agent team на примере Commerce OS

Чтобы всё это не осталось красивой абстракцией, давайте посмотрим на близкий нам контекст. Задача в Commerce OS: в очереди возвратов помечать запросы свыше 100 долларов, чтобы оператор не пропускал high-value кейсы без ручного подтверждения. Не один файл и не одна строка — тут бизнес-правило, UI inbox, существующие тесты и риск регрессии в refund flow. Вот где team может быть полезной — но именно как параллельное исследование, а не как «четыре агента одновременно переписывают проект»:

Lead:
- собирает постановку и ограничения
- удерживает правило: без широких edits

Коллега A:
- проверяет backend refund rule и связанные конфиги

Коллега B:
- смотрит UI inbox и badge/alert path

Коллега C:
- анализирует существующие tests и coverage gaps

Человек:
- решает, нужен ли один общий executor после исследования

Обратите внимание на одну тихую, но очень важную деталь. В этом примере почти все роли могут оставаться read-only. Это зрелый сценарий. Команда не кидается сразу писать код в три стороны. Она сначала распараллеливает исследование: где живёт логика, где будет UI-эффект, где есть пробелы в тестах, какие риски мы увидим раньше, чем начнём править файлы.

Такой подход даёт реальную пользу. Человек получает не один огромный мутный ответ «я всё посмотрел», а несколько более узких отчётов с evidence. После этого уже легче принять решение: достаточно ли одного executor-а, стоит ли заводить worktree, не задеваем ли мы чувствительную зону, не ушла ли задача в более рискованную область, чем казалось в начале.

И вот это важная мысль: самая взрослая agent team часто сначала помогает сузить задачу, а не сделать её «автоматически большой».

5. Где ограничения кусаются всерьёз

На демонстрациях agent team выглядит очень бодро, пока вы смотрите первые десять секунд. Потом включается реальная инженерия, и начинают вылезать вещи, которые маркетинговый ролик обычно стыдливо обходит. Если вы эти ограничения понимаете заранее, вы управляете инструментом. Если нет — инструмент начинает управлять вами.

Особенно коварна первая строка. Coordination cost — это не только токены. Это ваши глаза, ваше внимание и ваше время на принятие решений. Три аккуратных отчёта по 150 строк каждый — это уже не ускорение само по себе. Это материал, который ещё нужно прочитать, сопоставить, проверить на противоречия и превратить в дальнейшее действие. Если задача была маленькой или средней, вы очень легко проигрываете по суммарному усилию.

Вторая проблема — shared state. Допустим, один участник уже понял, что публичный API менять нельзя, а другой на старой постановке успел построить вывод, который как раз на это изменение опирается. Технически оба работали честно. Но общая картина уже разошлась. Без явного механизма handoff и обновления общего task list это всплывёт поздно — обычно в тот момент, когда вы уже эмоционально готовы верить красивой сводке.

Ещё неприятнее выглядит история с resumption. Любая более сложная схема плохо переносит прерывания. Один участник не вернулся, второй подвис, третий успел закончить, но контекст lead-а уже устарел. В итоге вы либо повторяете часть исследования, либо принимаете решение по неполному материалу. И вот тут становится ясно: agent team — это не бесплатная параллельность, а организационная конструкция, которую нужно поддерживать.

6. Human checkpoint не убирается даже у «умной» team

На этом месте у новичков часто появляется опасная мысль: «Ну если lead уже всё собрал, может, пусть система сама решит, что делать дальше?» Звучит логично ровно до первого чувствительного кейса. В реальной инженерной работе human checkpoint никуда не девается, потому что именно человек несёт ответственность за trade-offs, риск и финальный шаг.

Team может прекрасно параллелить исследование. Может быстро сравнить несколько гипотез. Может собрать evidence по разным частям codebase. Но как только дело касается решения уровня «теперь пишем код», «этот diff можно мержить», «это затрагивает refund flow», «мы уверены, что scope не расползся» — тут всё равно нужен человек. Не потому, что ИИ «глупый», а потому, что инженерное решение — это не только сумма найденных фактов, но и ответственность за последствия.

Можно сформулировать это чуть жёстче: agent team без human checkpoint — это не смелая автоматизация, а просто перенос риска в туманную зону. Особенно опасно это на путях, связанных с оплатой, авторизацией, данными пользователя и любыми shared-contract изменениями. В таких местах красивый сводный отчёт ещё не равен безопасному действию.

Поэтому зрелый процесс выглядит так: team помогает собрать и сжать картину, а человек утверждает следующий шаг. И если в какой-то момент вам хочется «убрать человека из цикла, чтобы было быстрее», это почти всегда хороший сигнал вернуться на шаг назад и спросить себя: а задача точно настолько независимая и безопасная, чтобы так рисковать?

7. Опасные обещания про agent team

Очень многое в этой теме ломается не на технике, а на формулировках. Если вы плохо описали себе, что именно делает team, вы будете ждать от неё невозможного. А дальше начнётся классическое «ну почти получилось, только почему всё так сложно». Поэтому полезно заранее заменить опасные обещания на зрелые инженерные формулировки.

Особенно опасно первое обещание. Оно звучит вдохновляюще, но на деле заставляет вас проектировать слишком широкий scope. Вместо узкого вопроса «какие части можно исследовать параллельно?» появляется фантазия «как бы эту штуку сделать без моего участия». И почти всегда это заканчивается не автономией, а более дорогой и хрупкой версией обычной работы.

Нормальная зрелая установка звучит гораздо скучнее — и поэтому гораздо полезнее. Agent team не строит проект за вас. Она помогает быстрее разобрать сложную задачу на независимые куски анализа и вернуть вам промежуточные результаты в виде, пригодном для решения. Это уже очень ценно. Просто это не магия, а инженерный инструмент с ценником в виде внимания, координации и проверки.

8. Схема в Workflow Kit спасает team

Любая advanced-возможность быстро превращается в миф, если её нигде не зафиксировать как рабочий артефакт. Поэтому в Workflow Kit полезно держать хотя бы очень короткую текстовую схему, которая отвечает на три вопроса: кто координирует, кто что смотрит и где человек останавливает автоматизм. Это не отдельный ritual поверх всего остального, а просто черновик pipeline под team-сценарий.

Даже такая маленькая заготовка уже помогает:

[human owner]
   ↓ approve
[lead: координация]
   ├─ [A: API scan, read-only]
   ├─ [B: UI scan, read-only]
   └─ [C: test scan, read-only]

handoff: AGENT_HANDOFF_CONTRACT.md
finish: human decides next executor

Полезность этой схемы в том, что она заставляет вас ответить на неудобные вопросы до старта работы. Кто пишет код? А может, пока никто. Кто собирает выводы? Lead. Где лежит handoff-формат? В уже знакомом AGENT_HANDOFF_CONTRACT.md. Где стоп-линия? Перед следующим executor-решением человека. С такой записью agent team перестаёт быть красивой вывеской «мы теперь работаем многими агентами» и становится обычным инженерным инструментом: дорогим, ограниченным, не всегда нужным, но понятным.