Два CLI-агента одновременно: что из этого работает на живом проекте

от автора

Веду Claude Code и Codex одновременно на своём продукте: десктопное приложение на Electron, сайт с кассой и базой, свой терминал поверх ConPTY. Ниже то, что реально даёт эффект, то что стабильно ломается, и правила, к которым я пришёл, чтобы второй агент не стал вторым источником багов.

Сразу про ожидание «в два раза быстрее» — оно не сбывается. Два агента на одной задаче мешают друг другу, переписывают чужие правки и вдвоём убеждают вас, что всё хорошо.

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

Приём первый: исполнитель и адвокат дьявола

Основная схема. Один агент пишет, второй в режиме только на чтение пытается доказать, что первый не прав.

Всё решает формулировка задачи для второго. Не «посмотри код», а:

Считай, что в этой правке есть ошибка. Найди её. Сценарий отказа — конкретные входные данные и что именно сломается. Если ошибки нет, так и скажи, но сначала попробуй по-настоящему.

Разница большая. На «посмотри код» приходит пять замечаний про именование и отсутствие комментариев. На «докажи, что здесь баг» — гонки, необработанные ветки и предположения, которые сам не заметил, потому что писал их с уверенностью.

Второй агент должен работать только на чтение. Иначе он вместо разбора начинает чинить, и вы получаете вторую правку вместо мнения о первой.

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

Приём второй: веер на однотипной работе

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

Живой пример. Нужно было написать двенадцать статей в блог: разные темы, одинаковая структура, общие требования к разметке и перекрёстным ссылкам. Последовательно это неделя. Запустил двенадцать подагентов с одним общим брифом и разными темами.

Бриф решает всё. Двенадцать агентов, которым сказано «напиши статью про X», дадут двенадцать разных структур, разный тон и разные форматы файлов. Бриф должен быть контрактом: точный путь и имя файла, точный формат, обязательные и запрещённые элементы, список уже существующих материалов, на которые надо сослаться. У меня бриф вышел длиннее, чем задание любого отдельного агента, и это правильное соотношение.

Заглушки запрещать отдельным пунктом: никаких «здесь подставьте своё значение», «TODO», «пример». Агент, который не знает факта, по умолчанию пишет заглушку, и она уезжает в прод, если её не ловить. Я потом прогонял по всем файлам проверку на слова-маркеры и один раз действительно поймал.

Проверка после — не опция. Двенадцать результатов надо прогнать одинаковой автоматической проверкой, у меня это скрипт, который дёргает готовые страницы и смотрит разметку, ссылки, длину описаний. Читать двенадцать текстов глазами вы не будете, значит либо проверка автоматическая, либо её нет.

Часть агентов умрёт. У меня трое из двенадцати оборвались на ошибке API ровно перед тем, как записать файл. Двенадцать минут работы каждого в никуда, если не знать одной вещи: сессия агента переживает обрыв ответа. Написал в ту же сессию «продолжай, исследование уже сделано», и статья дописалась за минуту, с полным контекстом. Не перезапускайте упавшего агента с нуля, сначала попробуйте с ним поговорить.

Что ломается на самом деле

Проблемы параллельной работы не там, где их ждёшь.

Общее рабочее дерево

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

Правила, к которым я пришёл:

  • перед любой сборкой git status и взгляд на время изменения файлов, если в дереве есть свежие чужие правки — сборку не запускать;

  • задачи разводить по слоям (один в бэкенде, другой во фронте), а не по файлам внутри одного слоя;

  • если задачи всё-таки пересекаются — отдельное дерево на агента (git worktree) и слияние руками.

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

Не видно, кто из них тебя ждёт

Главный источник простоя, и его почти никогда не называют. Три терминала. В одном агент работает, в двух уже задал вопрос и стоит. Вы этого не видите: терминал выглядит одинаково и когда идёт работа, и когда её ждут.

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

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

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

Механику resume для каждого своего агента стоит выяснить до того, как она понадобится, и записать. В момент, когда упал терминал с двухчасовым контекстом, читать документацию поздно и обидно.

Лимиты

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

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

Они спорят

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

Что даёт эффект, а что нет

Не работает:

  • два агента на одной задаче в одном файле;

  • «пусть второй проверит» без явной установки искать ошибку;

  • автоматическое применение находок второго агента;

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

Работает:

  • исполнитель и адвокат дьявола на всём, что трогает деньги, доступ, миграции и удаление;

  • веер на однотипной независимой работе с жёстким брифом и автоматической проверкой после;

  • разведение по слоям: один агент в бэкенде, другой во фронте, третий гоняет проверки;

  • один агент на широкий поиск по репозиторию, второй на точечную правку.

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

Про инструменты

Всё описанное делается голыми руками: несколько терминалов, git worktree, дисциплина и заметки о том, как у кого устроен resume.

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

Чего в ней нет, чтобы не было сюрпризов: сама она код не пишет и агентом не является, это оболочка над вашими CLI; под macOS и Linux её нет. Официальный десктоп Claude Code с последних релизов тоже умеет параллельные сессии, но запускает только Claude Code. Здесь панель это настоящий терминал, и агент в нём любой: claude, codex, opencode или своя команда.

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

ссылка на оригинал статьи https://habr.com/ru/articles/1077450/