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

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

Так появился agent-bus.

Канал между двумя рабочими сессиями

agent-bus связывает Claude Code с уже открытым чатом Codex на той же машине. Claude отправляет вопрос, Codex получает его в контексте проекта, отвечает, и Claude продолжает работу с учётом обсуждения.

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

У транспорта нет встроенных ролей. Роль определяется договорённостью внутри конкретной задачи. Claude может писать код, а Codex проводить ревью. В другой ситуации они могут вместе обсуждать архитектуру или поменяться местами.

В комплекте есть несколько готовых режимов:

  • author-reviewer, когда первый агент реализует изменение, а второй проверяет готовый результат;
  • reviewer-author, зеркальный сценарий;
  • discuss, свободное обсуждение без фиксированных ролей.

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

Какой рабочий процесс получился у меня

Первый агент начинает выполнять задачу и вносить изменения.

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

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

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

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

Таких раундов может быть несколько. Агенты сами понимают, когда нужен ещё один проход, а когда решение уже можно считать согласованным.

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

Опыт использования

Объективно оценить эффект пока сложно. У меня нет достаточного количества одинаковых задач, которые можно было бы выполнить с agent-bus и без него, а затем сравнить по понятным метрикам.

Субъективно качество получается выше.

Главная причина в скорости обратной связи. Один агент успевает показать промежуточное решение второму ещё до того, как вокруг него вырастет много нового кода. Замечания приходят, пока исходные решения остаются в контексте и их легко изменить.

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

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

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

Что внутри

agent-bus состоит из одного Node.js-скрипта и файлового mailbox в:

~/.local/state/agent-bus

Сервер и сетевой транспорт не используются. Сообщения записываются в локальные файлы, а операции выполняются через атомарное переименование.

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

Если подходящего чата Codex нет, можно запустить фоновый read-only процесс. Основным сценарием всё равно остаётся открытый чат: он сохраняет прозрачность и позволяет человеку войти в разговор.

Установка

Сначала подключаем marketplace и устанавливаем плагин в Claude Code:

/plugin marketplace add Educentr/claude
/plugin install agent-bus@educentr-marketplace

Затем устанавливаем часть для Codex:

/agent-bus:install

После перезапуска Codex открываем чат в каталоге проекта, отправляем в него любое первое сообщение и подключаемся из Claude Code:

/agent-bus:connect
/agent-bus:mode author-reviewer

Дальше можно формулировать запросы обычным языком:

  • «спроси Codex»;
  • «обсуди с Codex архитектуру»;
  • «отдай изменение на ревью».

Сейчас инструмент разработан и проверен на macOS. Для работы нужны Node.js, Codex CLI, lsof и ps. Поддержку Linux я пока не заявляю.

Почему я сделал свой инструмент

Вполне возможно, что похожее решение уже существует.

Раньше я бы начал с поиска: собрал список инструментов, прочитал документацию, сравнил архитектуру, установил несколько кандидатов и попытался понять, совпадают ли они с моим сценарием.

В агентской разработке экономика этого решения изменилась.

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

В случае agent-bus я довольно точно представлял результат:

  • Claude Code должен писать в уже открытый чат Codex;
  • вся переписка должна оставаться перед глазами;
  • человек может подключиться в любой момент;
  • роли определяются внутри разговора;
  • транспорт работает локально и обходится без отдельного сервиса.

При таких вводных собственная реализация оказалась самым коротким путём от идеи до работающего инструмента.

Конечно, у этого подхода есть цена. Свой код придётся поддерживать, проверять после обновлений Claude Code и Codex, документировать и развивать. Поэтому он особенно хорошо работает для небольших инструментов с чёткими границами.

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

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

Код постепенно становится самой дешёвой частью эксперимента. Гораздо важнее точно сформулировать желаемое поведение и понять, работает ли оно в реальном процессе.

Дивный мир.

Зачем мне это понадобилось

Мне хотелось сохранить сильные стороны независимого агентного ревью и добавить обратную связь в тот момент, когда код ещё формируется.

agent-bus даёт агентам общий канал, а человеку оставляет наблюдаемость и контроль. Ревью становится частью разработки, архитектурные сомнения обсуждаются раньше, а история решений остаётся перед глазами.

Код, инструкция и описание протокола:

github.com/Educentr/claude/tree/main/plugins/agent-bus

Если попробуете agent-bus на своих задачах, расскажите, какие схемы взаимодействия между агентами у вас получились.