Почему один агент уже не справляется: как оркестрировать Claude Code, Codex и Kiro без хаоса в tmux

Я — Denis Shokhirev, Agentic AI Systems Architect из Freiburg im Breisgau, Germany, и в DennisCraft AI Studio я собираю production-grade AI-системы для DACH B2B на Claude, Supabase, n8n, Doppler и self-hosted Postgres. Самый неприятный момент в multi-agent разработке наступает не тогда, когда агент ошибается, а когда 3 агента одновременно пишут код, спорят за один репозиторий и оставляют после себя tmux-сессию, в которой уже никто не понимает, что было источником истины.

Один агент еще можно терпеть как “умного стажера”. Несколько агентов без оркестрации — это уже операционная проблема: конфликтующие ветки, повторные миграции, непроверенные зависимости, секреты в логах и непредсказуемый порядок изменений. В regulated окружении это заканчивается не “немного лишней работы”, а потерей трассируемости. Поэтому вопрос давно не в том, нужен ли второй агент. Вопрос в том, как задать роли, границы и контрольные точки так, чтобы Claude Code, Codex и Kiro работали как система, а не как толпа терминалов.

Почему один агент перестал хватать

Когда задача ограничена одним модулем, один агент еще справляется: прочитал контекст, сгенерировал код, прогнал тесты, открыл pull request. Но реальная система редко устроена так просто. В одном потоке у вас схема Postgres, в другом — API-контракт, в третьем — n8n workflow, а рядом еще policy для секретов и проверка generated code на CWE-patterns.

На моих последних внедрениях повторялась одна и та же картина: если дать одному агенту весь backlog, он тратит слишком много контекста на переключение между слоями. Если дать нескольким агентам одну и ту же codebase без правил, они начинают дублировать работу и ломать друг другу assumptions. Проблема не в “качестве модели”, а в топологии работы.

Где ломается схема “один агент на все”

OWASP в LLM Prompt Injection Prevention Cheat Sheet прямо указывает, что системам с LLM нужны явные границы доверия и валидация инструментов, а не только хороший prompt (OWASP, 2024, https://owasp.org/www-project-top-10-for-large-language-model-applications/). В кодогенерации это означает простое правило: агент не должен одновременно быть и исполнителем, и ревьюером, и владельцем среды.

Рабочая схема: роли вместо tmux-анархии

Я не пытаюсь “склеить” все в один сверх-агент. Я развожу роли. Claude Code хорошо держит архитектурную нить и длинный контекст задачи. Codex полезен как быстрый исполнитель для локальных фрагментов и альтернативных реализаций. Kiro имеет смысл использовать как отдельный исследовательский или вспомогательный контур, но не как источник финальной истины по репозиторию. Истина должна жить в git, проверках и очереди задач, а не в истории терминала.

Минимальный набор ролей

• Planner: разбивает задачу на атомарные изменения и определяет порядок.
• Builder: пишет код в изолированной ветке.
• Verifier: прогоняет semgrep, bandit, gitleaks, тесты и policy checks.
• Merger: сравнивает diff, принимает или отклоняет изменения.

Ключевой принцип здесь простой: один агент — одна зона ответственности, один рабочий набор файлов, одна ветка. Не давайте 2 агентам право редактировать одни и те же директории в одно и то же время. Это дешевле, чем потом разбирать race condition на уровне git history.

git checkout -b agent/planner-task-142
python -m pytest tests/unit -q
semgrep --config auto .
bandit -r app -q
gitleaks detect --source . --no-banner
git add .
git commit -m "task-142: planner output and safe code path"
git push origin agent/planner-task-142

Контроль не в tmux, а в очереди и проверках

tmux полезен как интерфейс наблюдения, но не как control plane. Как только tmux становится местом, где “живет процесс”, вы теряете воспроизводимость. Я предпочитаю простую схему: задачи лежат в Postgres, статусы меняются через API или workflow, а агент получает только то, что ему разрешено на текущем этапе.

Для этого не нужен выдуманный фреймворк. Достаточно Postgres, n8n и нормальной дисциплины статусов.

create table agent_jobs (
  id bigserial primary key,
  task_key text not null,
  role text not null check (role in ('planner','builder','verifier','merger')),
  branch text not null,
  status text not null check (status in ('queued','running','failed','done')),
  payload jsonb not null,
  created_at timestamptz default now(),
  updated_at timestamptz default now()
);

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

Что проверять до merge

Минимум: unit tests, semgrep, bandit для Python, gitleaks для секретов, проверка SQL на параметризацию, проверка миграций на idempotency. Anthropic в документации по tool use рекомендует ограничивать действия модели через четко описанные инструменты и подтверждение для чувствительных операций (Anthropic Docs, 2024, https://docs.anthropic.com/). Для production это означает: агент не должен сам себе выдавать доступ на destructive actions.

steps:
  - run: pytest tests/unit -q
  - run: semgrep --config auto .
  - run: bandit -r app -q
  - run: gitleaks detect --source . --no-banner
  - run: python scripts/check_sql_params.py
  - run: python scripts/check_migrations.py

Как распределять Claude Code, Codex и Kiro по задачам

Не нужно спорить, “кто лучше”. Нужно понимать профиль отказа каждого инструмента в вашей среде.

На практике это выглядит так: Claude Code планирует и делает крупный refactoring в отдельной ветке. Codex получает узкую подзадачу, например переписать один модуль или тесты. Kiro можно использовать на side-task: подготовить альтернативную реализацию, список edge cases или набор инвариантов для проверки. После этого все сходится в verifier-этапе. Если verifier не прошел — задача не спорит с человеком, а возвращается в очередь.

Что особенно важно в regulated среде

Если вы работаете в DACH, вас очень быстро догоняют требования аудита: кто изменил код, кто одобрил, на каком основании агент получил доступ, где журнал действий, как исключены secrets leakage и несанкционированные запросы к данным. В такой среде “у нас был tmux и 4 окна” не считается процессом.

Поэтому я исхожу из 3 правил. Первое: агент не хранит secrets в prompt, только получает scoped access через Doppler или другой контролируемый механизм. Второе: каждое действие должно оставлять журнал в системе задач или CI. Третье: merge — это событие контроля, а не “логический конец работы модели”. Как только вы строите процесс так, агентность перестает быть риском сама по себе.

FAQ

Можно ли обойтись без tmux вообще?

Да. tmux удобен для наблюдения и локальной отладки, но не должен быть единственным интерфейсом управления. Если задача, статус и проверки живут вне tmux, вы можете в любой момент восстановить ход работы.

Нужно ли каждому агенту отдельное окружение?

Для задач с записью в кодовую базу — да, лучше отдельная ветка и изолированный workspace. Иначе вы быстро получаете конфликты состояния, которые трудно воспроизвести.

Достаточно ли одного verifier-этапа?

Обычно нет. Я разделяю быстрые проверки до commit и более тяжелые проверки до merge. Это сокращает стоимость ошибок и не заставляет человека вручную фильтровать очевидные проблемы.

Где хранить память агента?

Не в истории терминала. Оперативное состояние задачи лучше хранить в Postgres или Supabase, а долговременные решения — в git, ADR и issue tracker.

Когда multi-agent действительно оправдан?

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

На каком этапе вашего LLM pipeline в production возникает больше всего проблем: при генерации кода, на стадии проверок, при merge или уже после выката в среду? Мне правда интересно сравнить это с тем, что я вижу у команд в DACH.
Я провожу бесплатный 30-минутный stack audit для фаундеров и CTO, которые строят AI в regulated markets. Напишите мне в LinkedIn или в @ger_dennis_ai.