Несколько ИИ-агентов одновременно упираются не в модель и не в тариф. Они упираются в три вещи: общие файлы, ваше внимание и контекст, который теряется при каждом переключении. Схема параллельной работы либо решает эти три проблемы, либо не работает.

Статья про независимые агенты на одном проекте, а не про подагентов внутри одной сессии — про них в разборе ИИ-агентов.

Зачем вообще несколько

Причина всегда одна: агент работает минутами, а вы в это время не делаете ничего. Один шаг — правка, сборка, тест, поиск по проекту — это от десятков секунд до нескольких минут. Пока идёт этот шаг, второй агент мог бы разбирать другую задачу.

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

Четыре схемы разделения работы

1. По задачам, не пересекающимся по файлам

Самая безопасная. Один правит фронтенд, второй — скрипт выгрузки, третий — тексты. Конфликтов нет, потому что нет общих файлов. Требует, чтобы вы заранее знали границы задач.

2. По ролям на одной задаче

Первый делает, второй ревьюит по готовому диффу. Второму важно дать не «посмотри, всё ли хорошо», а конкретный список: что проверить, чего не бывает, где искать типовые дырки. Иначе получите вежливое «выглядит хорошо».

3. По вариантам решения

Одна задача, два-три агента, разные подходы, потом вы выбираете. Дорого по токенам, оправдано там, где цена неправильного выбора архитектуры высока, а откатывать потом больно.

4. Конвейер

Первый разбирается и пишет план, второй выполняет, третий проверяет. Передача — через файл в репозитории, а не через ваш пересказ. Хорошо ложится на большие миграции, где шагов много и они однотипные.

Чего среди схем нет. «Два агента вместе делают одну задачу в одних и тех же файлах» — это не схема, это гарантированный конфликт. Параллелить нужно то, что не пересекается, либо разносить по копиям рабочего дерева.

Конфликты за файлы

Два агента в одной папке видят один диск. Пока они читают — нормально. Как только оба пишут, начинается:

  • агент прочитал файл, подумал, записал — и затёр правку второго, сделанную в промежутке;
  • оба поставили зависимости и подрались за файл блокировки пакетного менеджера;
  • один сделал git checkout и утащил рабочее дерево из-под второго;
  • оба запустили сборку и поделили один каталог вывода.

Три рабочих способа это развязать:

  1. Разные папки. Отдельная копия проекта на агента, слияние через git. В git для этого есть git worktree — несколько рабочих деревьев одного репозитория без повторного клонирования.
  2. Разные ветки в разных деревьях. То же самое, но каждый агент коммитит в свою ветку, а вы сливаете по мере готовности.
  3. Явное разделение зон. В задаче каждого написано, какие каталоги его, и стоит запрет на остальные. Работает без инфраструктуры, но держится на дисциплине формулировок.

Первый способ надёжнее, третий дешевле. Смешивать можно: изоляция деревьев для тех, кто пишет, общее дерево для того, кто только читает и проверяет.

Внимание человека как узкое место

Практический предел параллельности определяется не машиной. Каждый агент периодически останавливается и ждёт от вас ответа: подтвердить команду, уточнить требование, выбрать вариант. Три агента — это три очереди, которые вы обслуживаете по одной.

Что реально помогает:

  • Видеть, кто ждёт. Если для этого нужно щёлкать по окнам, параллельность съедается переключением. Ожидающий агент должен быть виден без поиска.
  • Меньше поводов спрашивать. Заранее разрешённые безопасные команды и запреты, прописанные в задаче, снимают половину вопросов.
  • Асинхронные ответы. Агент, который во время ожидания продолжает делать то, что может, ценнее агента, замирающего целиком.
  • Разные типы задач в параллели. Две задачи «разберись и предложи» требуют вашего участия одновременно. Задача на исследование плюс задача на механическую правку — нет.

По ощущению от работы: два агента ведутся спокойно, три — рабочий максимум для одного человека, четыре и больше имеют смысл только если часть из них выполняет длинные задачи без вопросов.

Что происходит с контекстом

Второй скрытый налог — контекст. У каждого агента он свой, и общего знания у них нет. Три следствия:

  • то, что вы объяснили первому, второй не знает;
  • решение, принятое в одной сессии, во второй не действует;
  • закрытый терминал уносит с собой историю, если инструмент не умеет её восстанавливать.

Лечится это только выносом знания из головы агента в файлы проекта. Всё, что должны знать все, живёт в репозитории: правила в CLAUDE.md или AGENTS.md, принятые решения — в коротком журнале, план миграции — в отдельном файле, который агенты по очереди дописывают. Файл читают все, память не читает никто.

Когда не надо

  • Задача одна и она тонкая. Второй агент здесь не ускорит, а добавит вам работы по сверке.
  • Вы ещё не знаете границ задач. Параллелить неопределённость — верный способ получить три несовместимых решения.
  • Изоляции нет. Несколько пишущих агентов в одной папке без разделения деревьев — это не параллельность, это гонка.
  • Вы не успеваете читать диффы. Если проверка отстаёт, параллельность просто быстрее накапливает непроверенный код.

Где всё это держать

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

VibeeCode сделан именно под этот сценарий: терминалы с агентами живут панелями в одном рабочем пространстве, панели раскладываются сплитами или свободно на холсте, сессии восстанавливаются, между агентами есть общая память, а задачу можно надиктовать голосом по-русски. Модель и агент остаются теми же — меняется место, где вы за ними наблюдаете.

Если параллельность пока не нужна, полезнее начать с одного агента: старт с нуля и контрольные точки, а затем выбор инструмента под задачу и его установка — например, Codex CLI на Windows.