Построение мультиагентного рабочего процесса на основе Herdr

1. Иллюзия, что одного промпта будет достаточно, — и преграда, с которой я столкнулся

С появлением повсеместно доступных превосходных инструментов для AI-разработки, таких как Claude Code, Antigravity, Cursor и Codex, почти каждый наверняка испытал тот удивительный момент, когда достаточно одной строки в промпте с просьбой: «Добавь эту функцию», — и код мгновенно готов.

Для учебных проектов или простых скриптов вполне достаточно запустить одного AI-агента и вести разработку в диалоговом режиме. Однако как только вы попадаете в реальную корпоративную backend-среду, где несколько разработчиков работают вместе, а сложные бизнес-правила, строгая архитектура DDD и границы транзакций тесно переплетены, подход с одним агентом начинает демонстрировать серьёзные ограничения и приводить к сбоям.

Работая над сложной задачей, назначенной мне в командном проекте, я обнаружил, что передача одной сессии агента всего процесса — от DDL-миграции БД и JPA-репозиториев до доменных сущностей, сервисной логики, REST API и тестового кода — быстро приводит к критическим проблемам. После того как диалог превышал 15–20 сообщений, агент забывал о соглашениях фреймворка и доменных инвариантах, на которых акцентировалось внимание в начале, и произвольно перезаписывал код. Утомительный обмен сообщениями повторялся бесконечно: разработчикам приходилось вручную указывать на синтаксические ошибки и отсутствие обработки бизнес-исключений, одновременно построчно проверяя код, написанный агентом. Иногда агент не мог обнаружить недостатки собственного проектирования и кода, а вместо этого оправдывал свои слепые зоны словами: «Всё идеально».

Столкнувшись с этими проблемами, я изменил направление своего вопроса.
«Что, если вместо того, чтобы доверить всё одному AI, мы создадим автономную команду агентов, в которой специализированные агенты из каждой области будут проверять и улучшать работу друг друга?»

2. Почему именно «мультиагентная система», а не один агент?

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

① Распределение когнитивной нагрузки и сохранение чистоты ролей

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

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

В мультиагентной системе назначенному агенту дают единственную цель: «Ты — исследователь, и твоя единственная задача — изучить факты (связи в Domain, схему БД и поток вызовов). Ни при каких обстоятельствах не пиши код». Когда каждый агент на 100% сосредоточен на одной персоне, плотность и точность его вывода максимальны.

② Преодоление предвзятости самоутверждения с помощью независимой проверки

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

Если в сессии с одним агентом спросить: «Есть ли ошибки в написанном мной коде?», он обычно принимает предпосылки только что созданной им логики и отвечает: «Всё идеально, проблем нет».

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

③ Гигиена контекстного окна и предотвращение снижения производительности

Хотя контекстные окна LLM выросли до более чем 1 миллиона токенов, феномен «Lost in the Middle» — забывание первоначальных инструкций или пропуск промежуточной информации — а также снижение качества рассуждений по мере удлинения диалогов остаются реальными проблемами.

Один агент переносит в контекст одной сессии десятки тысяч строк текста, полученных при открытии 30 файлов, журналы ошибок сборки Gradle и подробные stack trace.

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

④ Синергия гетерогенных моделей и компенсация слепых зон

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

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

Gemini проверяет код, написанный Claude, а Claude проверяет код, написанный Gemini. Эти две модели, обученные на разных данных и имеющие разные архитектуры, компенсируют слепые зоны друг друга.

3. Практическое начало: гетерогенное объединение Antigravity и Claude Code

Всё началось с очень простого эксперимента.
«Что, если запустить Claude Code от Anthropic и Antigravity от Google рядом и заставить их работать вместе?»

Когда я действительно объединил две модели, синергия превзошла мои ожидания.

Модель Opus в Claude Code продемонстрировала выдающиеся способности в работе со сложной бизнес-логикой, объектно-ориентированном разделении ответственности и проектировании use case. Модель Gemini 3.6 Flash в Antigravity не имела себе равных при исследовании типов столбцов БД, зависимостей Spring bean и устаревших правил транзакций: она искала информацию в реальной файловой системе, используя огромный контекст и пугающую скорость.

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

4. Конец «челнока копирования и вставки»: знакомство с терминальным мультиплексором Herdr

Гетерогенное объединение моделей было великолепным, но вскоре я столкнулся с новым физическим узким местом.

Я копировал проектное решение из терминала 1 (Claude), переключался на терминал 2 (Antigravity), вставлял его и просил: «Проверь это для меня»… затем снова копировал результат, вставлял его в терминал 1 и просил: «Здесь есть проблема. Разберись»… Тот же процесс продолжался снова и снова.

Хотя роли агентов были разделены, я, разработчик, превратился в «челнок копирования и вставки», курсирующий между терминалами.

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

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

• Herdr в реальном времени отслеживает поток вывода каждой Pane и самостоятельно определяет, работает ли агент (Работает), заблокирован ли он (Заблокирован) или завершил работу (Готово). Необходимость ждать перед терминалом и решать, когда нажать Enter, полностью исчезла.

• Как только одна Pane завершает проектирование и отображает статус «Готово», демон Herdr перехватывает выходной Markdown через JSON-over-Socket IPC и немедленно напрямую передаёт его вместе с промптом на стандартный ввод (stdin) следующей Pane. Утомление от копирования и вставки буквально исчезло.

• При выполнении длительной сборки или полного набора тестов в одной сессии окно промпта разработчика тоже часто полностью зависало. В Herdr каждая Pane изолирована в собственном процессе и виртуальном TTY, поэтому даже во время запуска сотен фоновых тестов в одной Pane можно было в любой момент продолжать работу в терминале другой Pane.

5. Эволюция мульти-Pane-конфигурации Herdr: от разделения Pane для написания кода до создания 8 Agent Panes

Я не начинал с 8 идеально настроенных Panes. Я последовательно обрабатывал сложные задачи разработки, сталкивался с бесчисленными сбоями и узкими местами, а затем развивал конфигурацию, выделяя отдельную Pane всякий раз, когда возникала новая проблема.

Этап 1: первое разделение — начало с обмена один на один (coding Pane)

Изначально основная сессия (Claude Code) в одиночку выполняла всё: анализ требований, проектирование архитектуры, написание кода и компиляцию. Однако по мере накопления десятков историй редактирования файлов и обширных журналов ошибок компиляции непосредственно в основной сессии происходило загрязнение контекста: уже через 10 сообщений агент забывал доменные правила, изложенные в начале.

Чтобы решить эту проблему, я впервые выделил coding Pane. Главный оркестратор занимался только общим проектированием и инструкциями, а масштабный набор кода и отладку ошибок компиляции делегировал Gemini Flash, чья невероятная скорость помогла сохранить основной контекст чистым и защищённым.

Этап 2: гетерогенные парные проверяющие, разрушившие убеждение, что «написанный мной код идеален»

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

Чтобы решить эту проблему, я создал две независимые review Pane на разных моделях, которые проводили разрушительную проверку, исходя из предположения, что «в этом коде обязательно есть скрытый недостаток». Я поручил claude-review выявлять нарушения архитектуры и доменные инварианты, а antigravity-review — исследовать Null safety, SQL N+1 и откат транзакций. В частности, я запускал обоих проверяющих одновременно (Parallel), а не последовательно, вдвое сокращая время ожидания и создавая взаимонезависимую многовекторную сеть перекрёстной проверки.

Этап 3: после завершения написания кода уже слишком поздно всё переделывать — введение проверки проектных решений (design-verify)

Однако даже при безупречных написании кода и проверках оставался ещё один существенный источник потерь. Иногда фундаментальные недостатки — например, «базовое доменное моделирование выполнено неправильно» или «проектирование границ транзакций не соответствует требованиям» — обнаруживались только после полного завершения написания кода, на этапе проверки. Каждый раз приходилось полностью откатывать сотни строк с трудом созданного production-кода и начинать всё с нуля.

Чтобы принципиально предотвратить такую масштабную переработку, я принял стратегию переноса обнаружения дефектов на этап до начала написания кода. Я добавил design-verify Pane, которая сразу после создания документа открывала фактический исходный код и сопоставляла его с проектным документом. Устраняя пограничные случаи и архитектурные недостатки на 100% ещё на этапе проектирования, до начала написания кода, я сократил количество итераций во всём цикле разработки и вдвое уменьшил время разработки.

Шаг 4: Разделение командующего и проектировщика — независимая панель проектирования

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

В ответ мы установили принцип: «оркестратор не должен писать документы напрямую и должен сосредоточиться исключительно на командовании и контроле качества», — и независимо выделили панель проектирования, предназначенную для глубокого объектно-ориентированного анализа и проектирования.

Шаг 5: Не проектировать на основе воображения — выделение панели исследования

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

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

Шаг 6: Контратака журналов — выделение панели тестирования

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

Чтобы предотвратить это, мы выделили панель тестирования (Gemini Flash), предназначенную для запуска полного набора тестов и выявления дефектов, изолировав объёмный вывод журналов внутри подчинённой панели. Агент, работающий на модели Gemini Flash, быстро обрабатывал целиком бесконечно длинные журналы тестов.

Шаг 7: Готово сразу после начала сеанса — завершение автоматического предоставления ресурсов на основе хуков

Система из 7 специализированных панелей была завершена, однако ручное разделение 7 окон и добавление соответствующих инструментов и подсказок при каждом запуске Herdr создавало ещё одно неудобство.

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

6. 1 оркестратор + 7 специалистов

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

У каждой панели больше нет избыточной или неоднозначной роли. В соответствии с принципом единственной ответственности каждой назначена собственная специализированная задача и оптимизированный для неё движок LLM, и каждая работает независимо.

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

Название панели	Специализированная задача	Модель	Обоснование выбора и основная роль
main	Общее управление конвейером и контроль качества	Claude Sonnet	Взаимодействие с разработчиком, распределение задач по этапам и контроль коммитов/слияний Git
research	Эмпирическое исследование фактов кодовой базы	Gemini 3.7 Flash	Быстрое изучение пакетов, схем БД и потоков вызовов с использованием обширного контекста
design	Написание архитектурных документов и подробных проектных документов	Claude 3.7 Opus	Написание проектных документов на основе возможностей глубокого анализа
design-verify	Атакующая проверка проектных решений	Gemini 3.7 Flash	Поиск дефектов и пограничных случаев исходя из предположения, что «это проектное решение неверно»
coding	Реализация кода и компиляция	Gemini 3.7 Flash	Высокоскоростное написание кода с исключительной скоростью и соблюдением соглашений фреймворка
claude-review	Первичная проверка кода (структура/DDD)	Claude Sonnet	Проверка нарушений архитектурных границ, связанности, границ транзакций и бизнес-инвариантов
antigravity-review	Вторичная проверка кода (ошибки/стабильность)	Gemini 3.7 Flash	Проверка безопасности работы с null, проблем SQL/N+1, отсутствующих исключений, идемпотентности и соглашений о написании кода
test	Регрессионная проверка с помощью полного набора тестов	Gemini 3.7 Flash	Запустить все тесты Gradle

7. Сквозной рабочий процесс с несколькими агентами

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

1. Предотвращение неудачи «автономии по принципу laissez-faire»: если предоставить агентам автономию со словами «обсудите между собой и разработайте функциональность», они могут преждевременно перейти к написанию кода или потратить токены на бесконечные обсуждения. Необходим конвейер, который устанавливает чёткие контракты входных и выходных данных для каждого агента.

2. Реализация принципа «Shift-Left» в разработке программного обеспечения: чем позже обнаруживается дефект, тем экспоненциально выше стоимость его исправления. Лучший способ сократить общий срок разработки и исключить откаты кода — устранить как можно больше дефектов на этапе проектной документации, до начала написания кода.

3. Детерминированная сходимость благодаря контрольным точкам качества: благодаря строгому контролю, например «повторять проверку, пока не останется проблем» и «подтвердить отсутствие ошибок тестов», результат всегда сходится к качеству производственного уровня без дефектов, независимо от состояния LLM или вероятностных вариаций.

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

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

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

8. Четыре изменения, которые я заметил после внедрения рабочего процесса с несколькими агентами

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

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

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

В-третьих, я смог добиться одновременно скорости и качества. Хотя я работаю над задачей один, теперь я вношу вклад в кодовую базу команды с максимально высоким уровнем качества — так, словно выделенная senior-команда тщательно выполнила предварительное исследование, подготовила подробный проектный документ в формате Markdown, провела два раунда перекрёстной проверки, написала корейские Javadoc и выполнила полное регрессионное тестирование.

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

9. Заключение: поиск собственного оптимизированного рабочего процесса с несколькими агентами

Конфигурация «1 Orchestrator + 7 Specialists», представленная в этой статье, является моим собственным результатом, полученным методом проб и ошибок примерно за две недели. Эта конфигурация не является «универсальным решением» для каждого разработчика и каждого проекта. В ориентированной на UI frontend-среде центральную роль играл бы агент регрессионного визуального тестирования, тогда как стартапу на ранней стадии, где важна быстрая проверка гипотез, скорее подошла бы облегчённая конфигурация из 2–3 Panes.

Важно не количество, а «принципы».

1. Чёткость ролей: не назначайте одному агенту слишком много ролей; разделяйте исследование, проектирование, реализацию и верификацию, чтобы максимально повысить концентрацию.

2. Состязательная перекрёстная проверка, устраняющая предвзятость самоутверждения: не доверяйте своему проектному решению вслепую; поручайте агентам с разными точками зрения искать в нём дефекты и подвергать его критике.

3. Лаконичный контекст: изолируйте подробные необработанные журналы внутри отдельных агентов и обменивайтесь только уточнёнными результатами.

4. Финальный контроль разработчика: не делегируйте ИИ каждое решение; разработчик должен сохранять ключевые контрольные точки, такие как утверждение проектирования и финальная проверка.

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

informalife