Multi-agent: правила и антикритерии

1. Три Claude не работают втрое сильнее

Safe default вы уже знаете: один Claude, а параллельность сначала нужно оправдать задачей. Теперь важно не просто повторить это правило, а сделать его жёстче — прогнать идею multi-agent через fitness check.

Самая опасная иллюзия здесь всё та же: «Один Claude помогает, значит три помогут втрое». Иногда так и есть — но лишь когда заранее ясно, кто что трогает, как это проверяется и где человек жмёт стоп. Иначе каждый агент даёт не ускорение, а coordination cost.

Ниже не новая теория, а тот же coordination cost в практическом виде.

Поэтому хорошее базовое правило звучит очень прозаично:

Чем больше агентов вы запускаете, тем строже должны быть ownership, verification и human checkpoints.

Если задача — исправить одну опечатку в тексте кнопки, multi-agent не ускоряет работу. Он просто превращает трёхсекундную правку в маленький корпоративный процесс. Красиво? Возможно. Полезно — как микросервис для калькулятора чаевых.

2. Пять вопросов, которые задают до запуска

Это всё ещё тот же первый инженерный вопрос — нужна ли параллельность вообще, — только в более жёсткой форме. Теперь нас интересует не просто «можно ли разделить работу», а выдержит ли эта идея ownership, verification и human bandwidth.

Вот простая схема, которую удобно держать в голове перед стартом.

flowchart TD
    A[Есть задача] --> B{Есть независимые потоки работы?}
    B -- нет --> C[Один Claude / plan mode]
    B -- да --> D{Можно разделить ownership?}
    D -- нет --> C
    D -- да --> E{Есть понятная отдельная проверка результата?}
    E -- нет --> F[Сначала добавить safety net]
    E -- да --> G{Есть ресурс на промежуточные human decisions?}
    G -- нет --> C
    G -- да --> H[Multi-agent оправдан]

Теперь разложим это чуть спокойнее.

Обратите внимание на четвёртый вопрос — он про safety net. Ни сложный CI, ни полная система quality gates не нужны, хватит минимума: понять, что результат одной роли не сломал результат другой. Без него multi-agent — как бригада ремонтников без рулетки: шума много, а результат потом перемеряют вручную.

Пятый вопрос новички особенно любят забывать. Идеально разделённая работа бесполезна, если вам некогда прочитать промежуточные результаты и вовремя сказать: «Стоп, сначала замораживаем API-контракт». Multi-agent без human bandwidth — отложенная путаница.

3. Когда параллельность честно окупается

Если fitness check пройден, обычно сразу видна и причина: работа реально бьётся на независимые куски, а не просто красиво переименована в несколько ролей.

Хороший пример из нашего Commerce OS — условный issue COM-512, доработка потока заказов. API-контракт зафиксирован, backend и frontend разведены по каталогам, тесты живут отдельно. Параллелятся три потока: серверный код, интерфейс, тестовое покрытие. Это независимые workstreams, а не три красивых названия для одной задачи.

# Fitness check — COM-512

Independent workstreams? yes
Ownership separable? yes
Safety net available? yes
Shared state low? yes
Verdict: multi-agent is justified

Здесь важны не сами слова, а смысл. Backend owner сидит только в src/api/orders/*, UI owner — только в клиентской части заказов, тестовая роль трогает отдельные tests и не лезет в production-код. Вы не просите троих «помочь с фичей» — вы даёте каждому свой кусок территории.

Вторая честная ситуация для multi-agent — параллельная проверка конкурирующих гипотез. Например, в Commerce OS медленно открывается экран метрик. Одна гипотеза: дело в SQL-запросе. Другая: в повторных вызовах внешнего клиента. Два read-only investigation-потока собирают evidence, каждый по своей гипотезе, а человек решает, чья убедительнее.

Третья понятная зона — независимые read-only review-ракурсы. Если у вас уже готов diff, иногда оправдано параллельно попросить одного reviewer-а посмотреть на performance-риск, а другого — на test gaps. Ключевое слово снова read-only: как только оба начали «немножко подправлять», это уже не review, а гонка за ownership.

Формула: multi-agent оправдан там, где отдельно отвечаешь на три вопроса — кто делает, что сдаёт на выходе, как это проверяется отдельно от остального.

4. Один Claude — зрелое решение, а не слабость

Правильный verdict часто звучит скучно: один Claude, один plan mode, одна аккуратная серия изменений — способ не платить coordination cost там, где параллельность декоративна. В инженерии скучное решение очень часто и есть профессиональное.

Самый очевидный пример — маленькая задача. COM-518, правка текста кнопки — verdict очевиден: single-agent.

Но маленький размер — не единственный критерий. Задача на 200–300 строк тоже плохо параллелится, если она строго последовательная. Один PaymentService: сначала воспроизвести баг, потом найти root cause, потом выбрать одно изменение в одном месте, потом проверить побочный эффект. Поток работы один. Multi-agent создаст два конкурирующих diff’а в одном service-классе.

Ещё один стоп-сигнал — неясный scope. Если вы сами пока не можете сформулировать, где проходит граница задачи, запускать роли рано. Частая ошибка новичков: непонятный issue пытаются разбить об стену из агентов. Не понимаете bug — начните с reproduction, plan mode, пакета доказательств и одного investigator-а. Иначе получите несколько уверенных, но противоречивых объяснений одной проблемы.

Особенно опасно запускать multi-agent как способ «коллективно подумать» вместо нормального task spec. Это похоже на ситуацию, когда человек не знает, куда ехать, и поэтому открывает сразу три навигатора. Голосов больше — маршрут понятнее не станет.

5. Shared state и пустой safety net душат параллельность

Красивые схемы чаще всего ломают две вещи: общий изменяемый контекст и отсутствие внятной проверки. Shared state и отсутствие tests — не нюансы, а полноценные антикритерии.

Shared state — это ситуация, где роли хоть и названы по-разному, но реально сидят на одной изменяемой поверхности. Самый частый вариант — один файл или модуль. Чуть менее очевидный — общий контракт: два агента правят разные части проекта, но обе зависят от одного ещё не зафиксированного API. На бумаге ownership разделён, а гипотеза одной роли мгновенно меняет входные данные для другой.

Представьте, что вы хотите вынести OrderRefundService из большого OrderService, но characterization tests ещё нет и неясно, какие методы — публичный контракт. Формально: «Один рефакторит, второй пишет тесты». На практике второй пишет тесты на поверхность, которую первый прямо сейчас меняет. Не независимые потоки, а два человека на одной лестнице.

Без safety net проблема усиливается вдвойне: два результата уже не сравнить. Оба убедительны, оба со сводками, но какой сломал поведение — зацепиться не за что, кроме ощущения. Multi-agent лишь поднимает скорость производства уверенно оформленных ошибок.

В реальной работе полезно помнить очень жёсткое правило: shared state высокий, проверка слабая — сначала не агенты, а изоляция или более сильный verification.

6. Fitness check как короткий артефакт

Чтобы не принимать такие решения на эмоциях, полезно превратить их в короткий инженерный артефакт — не новый документ рядом с Parallelism Decision, а его короткую форму для Workflow Kit.

Удобно держать маленький шаблон, например workflow-kit/snippets/multi-agent-decision-template.md:

task: COM-512
size: large
workstreams_independent: yes      # backend, UI и tests разведены
ownership_split_by: modules
tests_available: unit
shared_state_risk: low
verdict: multi-agent

Этот шаблон хорош тем, что заставляет вас сформулировать решение коротко и по делу.

Для задачи, где multi-agent не оправдан, заполнение будет ещё короче, и это нормально:

task: COM-518
size: small
workstreams_independent: no
ownership_split_by: none
tests_available: n/a
shared_state_risk: low
verdict: single-agent

Эта запись не конкурирует с Parallelism Decision: нужен полный reasoning — оставляйте record, verdict очевиден — хватит shorthand.

На практике такой шаблон можно хранить не только отдельным файлом: для маленьких задач вставьте строки в PLAN.md, в заметку к issue или в описание PR. Смысл не в бюрократии — решение становится явным, и меньше соблазна через час сказать: «Давайте докинем ещё агента, раз начали».

И ещё один полезный эффект: если фиксировать такие решения регулярно, начнёте видеть повторяющиеся паттерны. Например, все задачи с shared_state_risk: high стабильно шли лучше в single-agent. Уже не интуиция, а инженерная практика.

7. Цена координации, которую новички не видят

Новички замечают только расход токенов — самый очевидный счётчик. Но coordination cost шире: multi-agent просит не только вычислений, но и внимания. Не готовы к этому — автоматизация не спасает, а быстрее производит хаос.

Особенно коварна цена переключения внимания. Один Claude в main session держит одну линию мысли. Три агента дают три линии, между ними надо постоянно прыгать. Через какое-то время ловишь себя на том, что уже не помнишь, какой output финальный, какой черновик и кто работал на старой версии assumptions. Это не проблема продукта, а естественная цена параллелизма.

Есть ещё эффект ложного консенсуса. Если дать всем ролям слабый task spec, два агента независимо повторят одну неверную идею. Снаружи это выглядит убедительно: «Смотри, оба пришли к одному выводу» — но оба читали один плохой input: не подтверждают друг друга, а одинаково ошиблись.

Небольшая памятка тут полезнее любой мотивационной речи:

Есть очень честное правило, которое сразу ставит всё на место: если у вас нет времени прочитать три промежуточных отчёта, у вас нет времени на multi-agent. Красивым названием роли эту стоимость не отменить.

8. Как записать профессиональный verdict

Полезно уметь писать короткий verdict без чувства вины. Не «мы не осилили multi-agent», а «multi-agent здесь не нужен». Это всё тот же первый артефакт — в PLAN.md, issue note или PR description.

Для single-agent решения хватит буквально нескольких строк:

## Решение по параллелизму
Task: COM-518
Verdict: single-agent
Reason: small sequential change in one file
Rejected: subagent, worktree, multi-agent

Для задачи, где multi-agent действительно оправдан, запись может быть не намного длиннее:

## Решение по параллелизму
Task: COM-512
Verdict: multi-agent
Split: backend/orders, frontend/orders, tests/orders
Human checkpoint: before merge

Заметьте, что в обеих версиях есть объяснение, а во второй — обязательный human checkpoint: multi-agent не снимает с человека финальное решение, лишь меняет форму его подготовки.

Но здесь появляется следующая развилка. Verdict multi-agent ещё не значит целую team-схему. Иногда хватает одного investigator-а или reviewer-а. А иногда задача уже требует lead, handoff и общей task list.

Научитесь писать такой verdict за тридцать секунд — и multi-agent перестанет быть фейерверком. Он станет обычным рабочим инструментом, который включают, только когда он окупается. Один Claude, fitness check, короткая запись решения — вот база, на которой параллельность из красивой иллюзии становится инженерным выбором.