Мультиагентный workflow для небольшой команды: worktree, роли и merge gate

Запускайте несколько coding agents только тогда, когда следующая задача делится на независимые зоны, контракт уже стабилен, каждый агент работает в отдельном workspace, а команда действительно может проверить несколько diff. Если двум агентам нужны одни и те же файлы, интерфейс еще меняется или reviewer не успевает читать изменения, быстрее оставить работу одному агенту.

Базовая схема для небольшой команды не похожа на автономный swarm. Начните с human lead, одного isolated implementer и одного verifier. У каждой задачи должны быть owner, branch или worktree, allowed files, forbidden files, handoff, команда проверки и merge gate.

Сначала проверьте route board, brief, worktree, handoff, verification gate, merge queue и метрику review-hour. Количество агентов увеличивается только после того, как этот минимум дал reviewable code.

Начинайте с маршрута, а не с числа агентов

Мультиагентный workflow работает не потому, что в нем много исполнителей, а потому, что зоны владения не мешают друг другу. Frontend agent и backend agent не являются безопасным разделением, если они одновременно придумывают API. Агент, который пишет тесты, не является независимым verifier, если вынужден угадывать, как будет выглядеть исправление.

Для небольшой команды есть четыре практических маршрута. Один агент нужен для связанных bugfix, миграций, безопасности и refactor, где важно одно поле зрения. Pipeline из двух агентов нужен, когда implementer может сделать scoped diff, а verifier может проверить brief, тесты и риск. Три агента работают, когда два implementer не делят файлы и имеют стабильный contract. Agent team оправдан только при сильном CI и очереди review.

Маршрут можно менять в течение недели. Начните с двухагентного pipeline, измерьте результат, потом добавляйте второго implementer. Если ownership еще не описан, новые agents обычно увеличивают coordination cost.

Когда несколько coding agents действительно помогают

Лучший случай - breadth-first работа с видимыми границами. Один агент меняет UI state, второй пишет integration tests. Один исследует failing path, второй проверяет regression coverage. Два агента меняют разные modules после того, как shared type или API contract уже зафиксирован. В каждом примере агент может закончить задачу без ожидания незавершенного кода другого агента.

Пять условий должны быть истинны одновременно. Scope описывается одной или двумя группами файлов. Shared contract достаточно стабилен для передачи. У каждого агента есть отдельный branch или worktree. Human reviewer видит diff и команды проверки, а не только чат. CI и reviewers могут принять merge последовательно.

Последнее условие самое дорогое. Два агента пишут быстрее, чем один reviewer читает. Если lead начинает целый день решать конфликты и переписывать brief, workflow не ускорился. Он просто перенес bottleneck в review.

Когда один агент лучше

Один агент лучше для tightly coupled работы. Database migration, auth middleware, billing flow, public API, weak tests, package dependency change, repo-wide rename или sensitive security edit должны оставаться под одним контуром контроля. Здесь важно не параллелить, а сохранить непротиворечивое решение.

Практическое правило: если агенту нужен unfinished code другого агента, чтобы понять следующее действие, не запускайте их параллельно. Сначала lead пишет contract, затем один agent делает первый diff, verifier или human подтверждает результат, и только потом следующий agent стартует от обновленного main.

Для небольшой команды это часто быстрее. Каждый последующий шаг имеет реальную базу, а не guessed interface. Ошибка локализована в одной ветке, review проще, rollback дешевле.

Day-one workflow

В первую неделю не перестраивайте весь процесс разработки. Возьмите одну низкорисковую задачу. Human lead пишет issue brief и выбирает маршрут. Implementer agent работает в отдельной ветке или worktree. Verifier читает только brief, changed files и handoff. Human reviewer оценивает semantic diff и merge risk. Main получает один merge за раз. Остальные worktrees обновляются перед продолжением.

Не отдавайте каждому агенту весь backlog. Дайте задачу, которую можно завершить, объяснить и вернуть. Output должен быть branch плюс written artifact, а не каталог с правками без происхождения.

Для первого запуска полезно заранее записать: почему задача separable, кто owns shared contract, какие файлы forbidden, какая команда подтверждает результат, кто принимает risk и в каком порядке merges попадут в main. Если эти вопросы не отвечены, parallel coding еще рано.

Task brief, который блокирует overlap

Brief - главный объект workflow. Он не дает двум агентам тихо решать разные задачи и дает reviewer конкретный contract.

md
Agent Task Brief

owner: agent-a
workspace: ../agent-a
branch: agent/a-checkout-state
goal: Add checkout state to the order summary component.
non_goals:
- Do not change payment provider code.
- Do not change database schema.
allowed_files:
- src/features/checkout/**
- tests/checkout/**
forbidden_files:
- src/lib/payments/**
- db/migrations/**
- package-lock.json
interface_contract:
- Use existing OrderStatus values.
- If a new status is required, stop and ask the human lead.
shared_state:
- No local database migration.
- Use test fixtures only.
required_checks:
- pnpm lint
- pnpm test tests/checkout
handoff_required:
- changed files
- commands run
- proof or failing output
- known risks
- review focus
done_means:
- The verifier can reproduce the checks and explain the diff.

Forbidden files не бюрократия. Это защита schemas, route maps, lock files, env, public API и shared configuration. Если brief не может назвать запретные зоны, задача слишком широка для parallel work.

Изолируйте работу через worktree или branches

Git worktree полезен тем, что один repository получает несколько рабочих деревьев. Один agent может запускать тесты и менять файлы, не пачкая checkout другого агента. Механика описана в официальной документации Git, но для команды важнее дисциплина: какой directory, какой branch, какие команды, какой merge plan.

bash
git switch main
git pull --ff-only
git worktree add ../agent-a -b agent/a-checkout-state
git worktree add ../agent-b -b agent/b-profile-copy
git worktree add ../verify -b verify/checkout-state
git worktree list

Worktree изолирует source files, но не изолирует все состояние. Database, ports, local services, secrets, package lock, CI runners, feature flags и public contracts требуют single owner.

Если worktree недоступен, используйте отдельные branches и clean checkouts. Требование то же: видимая граница workspace и понятный merge plan.

Handoff должен пережить чат

Chat summary не является handoff. Verifier и reviewer нуждаются в артефакте, который можно найти в pull request, issue comment или коротком handoff.md. Он фиксирует changed files, commands, proof, risks и review focus.

md
Agent Handoff

task: checkout state in order summary
owner: agent-a
branch: agent/a-checkout-state
changed_files:
- src/features/checkout/OrderSummary.tsx
- tests/checkout/order-summary.test.ts
commands_run:
- pnpm lint
- pnpm test tests/checkout
proof:
- All checkout tests pass locally.
known_risks:
- Empty order state still uses the existing fallback copy.
review_focus:
- Confirm the OrderStatus mapping is complete.
next_owner:
- verifier

Verifier по умолчанию не продолжает implementation. Его первая задача - проверить соблюдение brief: allowed files, tests, interface contract, proof и risks. Если verifier должен переписать те же feature files, task brief был недостаточно точным.

Добавляйте роли только когда они уменьшают нагрузку

Небольшой команде не нужна большая taxonomy. Достаточно human lead, implementer, verifier и human reviewer. Specialist нужен только для независимого потока: documentation, tests, migration или investigation.

Lead не обязан писать каждую строку, но owns the contract. Если contract не принадлежит человеку, agents invent different contracts, и каждый такой invention станет будущим conflict.

Verification gate и merge queue

Parallel work становится product work только в merge queue. Ветки надо merge последовательно, checks повторять, остальные worktrees обновлять после каждого merge.

bash
git switch main
git pull --ff-only
git merge --no-ff agent/a-checkout-state
pnpm lint
pnpm test
git push

cd ../agent-b
git fetch origin
git rebase origin/main

Gate проверяет пять вещей: diff меняет только allowed files; required checks запущены и записаны; interface contract intact; handoff называет risks и review focus; человек понимает semantic change. AI review полезен как дополнительный pass, но semantics, security, data handling и merge responsibility остаются у человека.

Где Codex, Claude Code, Cursor и frameworks

Инструменты выбираются после shape workflow. Codex подходит, когда нужны reviewable diffs, CLI, IDE, cloud tasks и PR-oriented flow. Claude Code подходит для supervised local sessions, complex context и более тонких permission rules. Cursor background agents, worktree wrappers и orchestration frameworks реализуют тот же процесс.

Если нужна именно развилка Codex или Claude Code, используйте отдельное сравнение Claude Code vs Codex. Если проблема в лимитах Codex, смотрите OpenAI Codex usage limits. Владелец этой страницы - не бренд, а brief, workspace isolation, handoff, diff, verification и human merge.

Хороший инструмент сохраняет brief, изолирует workspace, показывает diff, записывает proof и дает reviewer остановить merge. Если он этого не делает, сильная модель не спасет небольшой team process.

Измеряйте accepted diff per review hour

Количество agents - слабая метрика. Commits тоже слабы: agent может создать огромный diff, который трудно принять. Для небольшой команды review hour часто является самым редким ресурсом.

Прогоните две или три задачи через workflow перед стандартизацией. Сравните с хорошим single-agent baseline. Если two-agent pipeline дает cleaner tests, faster review или больше accepted work per lead hour, оставьте. Если coordination cost выше, уменьшайте split.

План на одну неделю

День 1: выберите low-risk issue с отдельной test coverage, создайте task brief и одну implementer branch. День 2: добавьте verifier без implementation edits. День 3: merge sequentially и запишите review minutes. День 4: пробуйте второго implementer только при stable contracts. День 5: сравните accepted work, rework, conflicts, CI и review time.

Цель - не доказать, что agent team впечатляет. Цель - найти минимальный процесс, который помогает небольшой команде ship reviewable code с меньшим lead time и меньшим rework.

Часто задаваемые вопросы

Какой самый маленький безопасный workflow?

Human lead, один implementer agent и один verifier agent. Implementer пишет scoped diff в isolated workspace. Verifier проверяет brief, tests, allowed files и risks. Human reviewer принимает merge decision.

Стоит ли команде из двух человек использовать несколько agents?

Да, но только для separable work. Обычно лучше начать с two-agent pipeline, а не с large agent team. Lead должен успевать читать diff и handoff.

Git worktree обязателен?

Нет. Worktree - strong default, потому что каждому agent достается отдельное working tree. Separate branches или clean checkouts тоже подходят, если есть workspace isolation и merge plan.

Какие файлы должны оставаться single-owner?

Schemas, migrations, package locks, env files, auth middleware, feature flags, public API contracts и shared route maps. Исключение - explicit change от human lead.

Может ли AI review заменить human review?

Нет. AI review ловит syntax, tests, style и consistency issues. Human review отвечает за semantics, product risk, security, data handling и merge responsibility.

Когда остановить мультиагентный режим?

Остановитесь, если agents требуют одни и те же файлы, interface still moving, reviewers не успевают, CI повторно падает или accepted diff per review hour ниже single-agent baseline.

Где место Codex и Claude Code?

Codex, Claude Code, Cursor, worktree wrappers и orchestration frameworks являются поверхностями для одного workflow. Выбирайте ту, которая сохраняет brief, workspace, diff, proof и review gate.

Сколько agents запускать одновременно?

Большинству небольших команд сначала надо доказать связку one implementer plus one verifier. Три agents возможны при independent scopes. Большая agent team требует ownership, CI, merge queue и review capacity.