ChatDev в проде: где рассыпается мульти-агентный конвейер
В демонстрации мульти-агентная разработка выглядит убедительно: небольшая изолированная задача, чистый репозиторий, предсказуемый результат за один прогон. В рабочем репозитории конвейер встречает чужой код, длинную историю изменений и параллельные ветки — и здесь проявляются точки отказа, которых в демо просто не было.
Первая и самая частая — рассинхрон ролей при оркестрации агентов. Архитектор описывает решение в одном наборе файлов, исполнитель правит другие, проверяющий смотрит третьи: формально все роли отработали, а на выходе — несогласованный набор изменений. Пока нет явного контракта между ролями (кто какие пути читает и какие меняет), конвейер даёт ложное чувство завершённости.
Вторая — немаркированные правки. Агент выходит за объявленную зону и меняет конфигурацию, тесты или зависимости, никак это не пометив. В общем наборе изменений такое смешано с целевым, и проверяющий тратит время на археологию вместо разбора логики. Закрывается атрибуцией: каждая правка привязана к роли, шагу и номеру прогона.
Третья — невоспроизводимый прогон. Если не зафиксированы входные данные, версия модели, собранный контекст и результаты вызовов инструментов, повторный запуск даёт другой код, а откат и разбор инцидента становятся невозможны. Ниже разбираем, как это закрывается на уровне конфигурации и процесса.
Что даёт управляемый конвейер агентной разработки
Мульти-агентная разработка даёт измеримый эффект только тогда, когда роли агентов, границы их прав и точки обязательного человеческого ревью заданы заранее. Мы разворачиваем ChatDev как оркестратор ролей — архитектор, разработчик, ревьюер, тестировщик — и фиксируем для каждого класса задач маршрут: что агент делает сам, где останавливается и ждёт инженера.
Первый показатель — доля автономных задач, доходящих до слияния без ручной доработки. На типовых изменениях, вроде правки логики, покрытия тестами или обновления конфигурации, она выходит на устойчивые значения, и ревью перестаёт уходить на механические правки. Время цикла правок сокращается потому, что проверки идут параллельно написанию кода, а не после него.
Второй — устранённый класс отказов. Изменения, не прошедшие автоматические проверки кода, статический анализ и тесты, не доходят до основной ветки: агент-ревьюер возвращает их в цикл и не создаёт запрос на слияние до зелёного прогона. Это снимает пласт инцидентов, которые раньше ловились на ревью или уже в среде эксплуатации.
Прослеживаемость решений агентов — то, без чего автономность превращается в риск. Каждый шаг пишется в журнал: какая роль, на основании каких файлов и результатов проверок приняла решение, какой артефакт породила и кто подтвердил. По журналу восстанавливается логика изменения и видно, где вмешался человек.
Дальше разберём, как эти показатели считаются, по каким порогам принимается решение о расширении автономности и что остаётся за инженером на каждом этапе.
Режимы прогонов: интерактивный, пакетный, автономный
Режим прогона определяет, где в конвейере останавливается человек и что можно принять по формальным признакам. В ChatDev это переключатель уровня задачи: одна и та же цепочка ролей либо идёт с подтверждением на каждом шаге, либо проходит цикл целиком. Ниже — три режима и то, какие ограничения каждый накладывает на контроль и приёмку.
| Режим | Когда подходит | Ограничения и контроль |
|---|---|---|
| Интерактивный | новые предметные области, спорные требования, первые проходы по незнакомому репозиторию | человек подтверждает каждый шаг: прогон идёт в разы дольше, зато правки вносятся до того, как решение разошлось по десятку файлов |
| Пакетный | однотипные задачи по известному шаблону: миграции, тесты, документация | приёмка по формальным критериям — сборка, набор тестов, статический анализ; смысловые расхождения видны только на выходе пачки, откат делается по задаче целиком |
| Автономный | длинные цепочки шагов с чётким признаком готовности, регрессионные прогоны | нужны ограничители: лимит шагов, запрет на правку критичных путей, обязательная точка возврата — иначе ошибка масштабируется на всю ветку |
На практике режимы не исключают друг друга. Пакетный — рабочий по умолчанию: предсказуемое время прогона и проверяемая приёмка. Автономный включаем на участках, где есть тесты, тестовые данные и быстрый откат, а интерактивный оставляем для первых проходов и для задач, где требования ещё уточняются.
Внедрение ChatDev: от аудита репозитория до передачи
Внедрение ChatDev начинается не с запуска агентов, а с инвентаризации того, что уже есть в коде. Порядок этапов одинаков для любого репозитория: сначала снимаем факты, затем проектируем роли и только потом даём агентам доступ к работе. Каждый этап заканчивается артефактом, который можно проверить, — без него следующий шаг не начинается.
- Аудит репозитория. Смотрим структуру модулей, как собирается проект, где лежат тесты и какие критичные пути они покрывают. На выходе — карта зависимостей и базовые метрики: время сборки, доля путей под проверками.
- Схема ролей агентов. Определяем, кто проектирует, кто пишет код, кто проверяет и кто запускает тесты, и на каких шагах задача переходит дальше. Агенты не пишут в защищённые ветки напрямую.
- Настройка сред. Разворачиваем изолированные окружения с доступом на чтение к основной ветке, ключи и токены держим вне кода. Задаём лимиты на объём контекста и число итераций — прогон не уходит в бесконечный цикл.
- Сухой прогон. Берём одну небольшую задачу из текущей очереди и прогоняем её целиком, от постановки до изменений. Смотрим, сколько правок понадобилось после агентов и где роли передавали работу с потерями.
- Критерии приёмки. До промышленных запусков фиксируем: тесты проходят, статический анализ не даёт новых замечаний, у каждого изменения есть обоснование и след. По этим критериям строится отчёт по каждому прогону.
- Передача команде. Отдаём регламент запуска, шаблоны задач и разбор типовых отказов. Первые прогоны идут с нашим сопровождением, дальше команда ведёт цикл сама.
Конфигурации, схемы ролей и регламенты прогонов
После первого прогона в репозитории заказчика остаётся не набор демонстрационных сценариев, а рабочий комплект: его достаточно, чтобы запустить мульти-агентную разработку заново без нас. Все артефакты версионируются вместе с кодом — правка роли или правила доступа проходит тот же разбор на приёмке, что и изменение в сервисе.
- Карта ролей — какие роли выделены под задачу, за какой участок работы каждая отвечает и по какому признаку её результат принимается.
- Правила доступа агентов — что роль читает, куда пишет, где перед слиянием обязательна проверка человеком.
- Конфигурации прогонов — состав команды, порядок передачи задач, лимиты итераций и условия остановки, чтобы результат не зависел от исполнителя.
- Регламент отката — какие точки сохранения делаются до старта, как вернуться к предыдущему состоянию и что считаем сигналом к откату.
- Разбор конфликтов правок — арбитр спорной правки, обязательные проверки и порядок, по которому две роли сводятся к одному решению.
- Журнал прогонов — где лежат входные данные, шаги и результат: по нему сбой воспроизводится, а не обсуждается по памяти.
- Каталог проверок — тесты и статический анализ, которые прогон обязан пройти до слияния в основную ветку.
Комплект передаётся в ваш репозиторий, и дальше команда ведёт его сама: меняет состав ролей, добавляет проверки, заводит новые конфигурации под изменившиеся задачи. ChatDev мы настраиваем так, чтобы эти файлы читались и правились как обычный код проекта.
Кейс: сокращение цикла правок на агентном стенде
До внедрения стенда цикл правок во внутреннем сервисе занимал 9–11 дней: задача проходила ревью, возвращалась на доработку и снова вставала в очередь. До слияния в основную ветку доходило около трети задач — остальные разбирали вручную, а рассинхрон контрактов между модулями ловили уже на интеграции, когда стоимость правки максимальна.
Что изменили
Собрали агентный стенд на ChatDev: роли аналитика, разработчика, ревьюера и тестировщика работают в одном диалоге и передают друг другу артефакты — уточнённую постановку, патч, набор проверок. Каждая задача живёт в отдельной ветке, а в основную её пропускает закрытый список проверок: сборка, тесты, сверка сигнатур и миграций.
Что стало
Доля задач, доходящих до слияния с первого прохода, выросла с 35% до 78%, а медианное время цикла правок сократилось с 9–11 дней до 2–3. Класс отказов «модули разошлись по контракту» перестал попадать в основную ветку: ревьюер-агент сверяет сигнатуры до сборки, и расхождение всплывает на этапе постановки, а не на интеграции.
Роль инженера осталась решающей: финальное слияние и спорные случаи — за человеком. Если агент не сходится в решении, задача возвращается с полным логом диалога и перечнем отклонённых вариантов — разбор занимает минуты вместо часов.
Чем ChatDev отличается от ручной сборки сценариев агентов
Разница не в том, что один подход умнее, а в том, где лежит ответственность за результат прогона. В самописной связке агентов роли, порядок вызовов и формат передачи контекста живут в коде, написанном под конкретный сценарий. Пока задач пять и все одного типа, это быстро и гибко. Когда сценариев десятки, а входные данные разнородные, связка начинает вести себя по-разному на одинаковых запросах.
Воспроизводимость прогонов страдает первой: состояние размазано между памятью процесса, промежуточными файлами и промптами, которые правили по ходу. Повторить запуск можно, только если с самого начала сохраняли входы, версии ролей и порядок шагов. Диагностика сбоев по той же причине сводится к чтению кода и повторным запускам — журнал показывает, что упало, но не чем был вход.
| Что сравниваем | Самописная связка | Конвейер ChatDev |
|---|---|---|
| Воспроизводимость прогонов | зависит от того, что сохранили вручную | шаги и артефакты фиксируются по умолчанию |
| Диагностика сбоев | по коду и повторным запускам | по журналу шагов и данным между ними |
| Сопровождение конвейера | правки в общем коде на каждый сценарий | правила ролей и маршрутов общие |
| Рост числа задач | время на разбор растёт линейно | повторы и маршрутизация настраиваются |
При росте нагрузки самописная связка дорожает не в разработке, а именно в сопровождении конвейера: каждый новый тип запроса тянет правки в общий код и повторную проверку уже работающих ролей. Готовый конвейер закрывает фиксацию шагов, повторы и маршрутизацию — доработки остаются точечными, а не сквозными.
Сомнения техкоманды: контроль, откаты, изоляция
Права агентов ограничиваем на уровне токена доступа: ChatDev получает учётные данные только на чтение репозитория и запись в отдельную служебную ветку. Слияние делает человек через ручную проверку, секреты в контекст агента не попадают, сетевой доступ контейнера ограничен списком разрешённых адресов. Манифест прав проверяется при каждом запуске — выход за рамки останавливает прогон, а не портит код.
Зацикливание — вторая частая история: агенты переписывают один и тот же файл по кругу. Ставим жёсткий лимит итераций и шагов на задачу, следим, меняется ли итоговое расхождение с базовой версией, и при остановке изменений прогон завершается отчётом о причинах. Плюс потолок на объём контекста — длинный цикл не превращается в неуправляемый расход.
В легаси-репозиторий конвейер встраиваем постепенно: один модуль, изолированная ветка, характеризующие проверки на текущее поведение. Результат агента проходит те же сборки и проверки, что и ручные правки, — публичные контракты не меняются втихую.
Как откатить неудачный прогон?
Изменения живут в служебной ветке и не влияют на основную. Не подошёл результат — ветка закрывается, история прогонов с отчётами сохраняется для разбора. Откат занимает минуты и не требует ручной правки кода.
А если в легаси-коде нет тестов?
Сначала закрываем критичные пути проверками, фиксирующими текущее поведение, и только потом допускаем агента к правкам. Любое расхождение видно на сборке, а не после релиза в рабочем контуре.
Обсудим задачу: что нужно для оценки внедрения
Чтобы вернуться с оценкой и планом работ, а не с общими формулировками, нам нужны вводные по репозиторию, команде и текущим процессам. Мульти-агентная разработка встраивается в существующий контур, поэтому сначала смотрим, как устроены сборка, проверки и приёмка изменений — от этого зависит и объём работ, и то, какие участки можно отдать агентам сразу, а какие оставить за людьми.
- Структура репозитория: языки, число модулей, состояние сборки и тестов, где сосредоточена основная логика.
- Ветвление и выпуск версий: как готовятся изменения, кто подтверждает слияние, как часто выходят релизы.
- Автоматические проверки: что запускается на каждое изменение, где проверки до сих пор делаются вручную.
- Состав команды: сколько инженеров владеет кодом, кто принимает результат агентов и как устроена взаимная проверка изменений.
- Процессы работы с задачами: как формулируются требования, где ведётся учёт, по каким критериям задача считается готовой.
- Ограничения окружения: изолированные среды запуска, доступы, правила обращения с кодом и данными.
Этого набора достаточно, чтобы вернуться с оценкой и планом работ: какие участки закрываем агентами, что остаётся за инженерами, как проверяем результат на каждом шаге. Если часть вводных пока не собрана — не проблема, уточним в разговоре и подскажем, как их получить. Опишите задачу — вернёмся с оценкой и планом.
