ChatDev у продакшені: де розсипається мультиагентний конвеєр
У демонстрації мультиагентна розробка виглядає переконливо: невелика ізольована задача, чистий репозиторій, передбачуваний результат за один прогін.
У робочому репозиторії конвеєр зустрічає чужий код, довгу історію змін і паралельні гілки — і тут виявляються точки відмови, яких у демо просто не було.
Перша й найчастіша — розсинхрон ролей під час оркестрації агентів. Архітектор описує рішення в одному наборі файлів, виконавець править інші, перевіряльник дивиться треті: формально всі ролі відпрацювали, а на виході — неузгоджений набір змін.
Поки немає явного контракту між ролями (хто які шляхи читає і які змінює), конвеєр дає хибне відчуття завершеності.
Друга — немарковані правки. Агент виходить за оголошену зону й змінює конфігурацію, тести або залежності, жодним чином це не позначивши. У загальному наборі змін таке змішано з цільовим, і перевіряльник витрачає час на археологію замість розбору логіки. Закривається атрибуцією: кожна правка прив’язана до ролі, кроку й номера прогону.
Третя — невідтворюваний прогін. Якщо не зафіксовано вхідні дані, версію моделі, зібраний контекст і результати викликів інструментів, повторний запуск дає інший код, а відкат і розбір інциденту стають неможливими. Нижче розбираємо, як це закривається на рівні конфігурації та процесу.
Що дає керований конвеєр агентної розробки
Мультиагентна розробка дає вимірюваний ефект лише тоді, коли ролі агентів, межі їхніх прав і точки обов’язкового людського рев’ю задані заздалегідь.
Ми розгортаємо ChatDev як оркестратор ролей — архітектор, розробник, рев’юер, тестувальник — і фіксуємо для кожного класу задач маршрут: що агент робить сам, де зупиняється й чекає інженера.
Перший показник — частка автономних задач, що доходять до злиття без ручного доопрацювання. На типових змінах, як-от правка логіки, покриття тестами або оновлення конфігурації, вона виходить на стійкі значення, і рев’ю перестає йти на механічні правки.
Час циклу правок скорочується тому, що перевірки йдуть паралельно з написанням коду, а не після нього.
Другий — усунений клас відмов. Зміни, що не пройшли автоматичні перевірки коду, статичний аналіз і тести, не доходять до основної гілки: агент-рев’юер повертає їх у цикл і не створює запит на злиття до зеленого прогону. Це знімає пласт інцидентів, які раніше ловилися на рев’ю або вже в середовищі експлуатації.
Простежуваність рішень агентів — те, без чого автономність перетворюється на ризик. Кожен крок пишеться в журнал: яка роль, на підставі яких файлів і результатів перевірок ухвалила рішення, який артефакт породила і хто підтвердив. За журналом відновлюється логіка зміни й видно, де втрутилася людина.
Далі розберемо, як ці показники рахуються, за якими порогами ухвалюється рішення про розширення автономності й що залишається за інженером на кожному етапі.
Режими прогонів: інтерактивний, пакетний, автономний
Режим прогону визначає, де в конвеєрі зупиняється людина і що можна прийняти за формальними ознаками. У ChatDev це перемикач рівня задачі: один і той самий ланцюжок ролей або йде з підтвердженням на кожному кроці, або проходить цикл повністю. Нижче — три режими й те, які обмеження кожен накладає на контроль і приймання.
| Режим | Коли підходить | Обмеження та контроль |
|---|---|---|
| Інтерактивний | нові предметні області, спірні вимоги, перші проходи по незнайомому репозиторію | людина підтверджує кожен крок: прогін іде в рази довше, зате правки вносяться до того, як рішення розійшлося по десятках файлів |
| Пакетний | однотипні задачі за відомим шаблоном: міграції, тести, документація | приймання за формальними критеріями — збірка, набір тестів, статичний аналіз; смислові розходження видно лише на виході пачки, відкат робиться за задачею цілком |
| Автономний | довгі ланцюжки кроків з чіткою ознакою готовності, регресійні прогони | потрібні обмежувачі: ліміт кроків, заборона на правку критичних шляхів, обов’язкова точка повернення — інакше помилка масштабується на всю гілку |
На практиці режими не виключають один одного. Пакетний — робочий за замовчуванням: передбачуваний час прогону й перевіряне приймання.
Автономний вмикаємо на ділянках, де є тести, тестові дані й швидкий відкат, а інтерактивний залишаємо для перших проходів і для задач, де вимоги ще уточнюються.
Впровадження ChatDev: від аудиту репозиторію до передачі
Впровадження ChatDev починається не із запуску агентів, а з інвентаризації того, що вже є в коді. Порядок етапів однаковий для будь-якого репозиторію: спочатку знімаємо факти, потім проєктуємо ролі й лише після цього даємо агентам доступ до роботи.
Кожен етап закінчується артефактом, який можна перевірити, — без нього наступний крок не починається.
- Аудит репозиторію. Дивимося структуру модулів, як збирається проєкт, де лежать тести й які критичні шляхи вони покривають. На виході — карта залежностей і базові метрики: час збірки, частка шляхів під перевірками.
- Схема ролей агентів. Визначаємо, хто проєктує, хто пише код, хто перевіряє і хто запускає тести, і на яких кроках задача переходить далі. Агенти не пишуть у захищені гілки напряму.
- Налаштування середовищ. Розгортаємо ізольовані оточення з доступом на читання до основної гілки, ключі й токени тримаємо поза кодом. Задаємо ліміти на обсяг контексту й кількість ітерацій — прогін не йде в нескінченний цикл.
- Сухий прогін. Беремо одну невелику задачу з поточної черги й проганяємо її цілком, від постановки до змін. Дивимося, скільки правок знадобилося після агентів і де ролі передавали роботу із втратами.
- Критерії приймання. До промислових запусків фіксуємо: тести проходять, статичний аналіз не дає нових зауважень, у кожної зміни є обґрунтування й слід. За цими критеріями будується звіт за кожним прогоном.
- Передача команді. Віддаємо регламент запуску, шаблони задач і розбір типових відмов. Перші прогони йдуть із нашим супроводом, далі команда веде цикл сама.
Конфігурації, схеми ролей і регламенти прогонів
Після першого прогону в репозиторії замовника залишається не набір демонстраційних сценаріїв, а робочий комплект: його достатньо, щоб запустити мультиагентну розробку заново без нас.
Усі артефакти версіонуються разом із кодом — правка ролі або правила доступу проходить той самий розбір на прийманні, що й зміна в сервісі.
- Карта ролей — які ролі виокремлено під задачу, за яку ділянку роботи кожна відповідає і за якою ознакою її результат приймається.
- Правила доступу агентів — що роль читає, куди пише, де перед злиттям обов’язкова перевірка людиною.
- Конфігурації прогонів — склад команди, порядок передавання задач, ліміти ітерацій і умови зупинки, щоб результат не залежав від виконавця.
- Регламент відкату — які точки збереження робляться до старту, як повернутися до попереднього стану і що вважаємо сигналом до відкату.
- Розбір конфліктів правок — арбітр спірної правки, обов’язкові перевірки та порядок, за яким дві ролі зводяться до одного рішення.
- Журнал прогонів — де лежать вхідні дані, кроки й результат: за ним збій відтворюється, а не обговорюється з пам’яті.
- Каталог перевірок — тести й статичний аналіз, які прогін зобов’язаний пройти до злиття в основну гілку.
Комплект передається у ваш репозиторій, і далі команда веде його сама: змінює склад ролей, додає перевірки, заводить нові конфігурації під змінені задачі. ChatDev ми налаштовуємо так, щоб ці файли читалися й правилися як звичайний код проєкту.
Кейс: скорочення циклу правок на агентному стенді
До впровадження стенда цикл правок у внутрішньому сервісі займав 9–11 днів: задача проходила рев’ю, поверталася на доопрацювання й знову ставала в чергу.
До злиття в основну гілку доходило близько третини задач — решту розбирали вручну, а розсинхрон контрактів між модулями ловили вже на інтеграції, коли вартість правки максимальна.
Що змінили
Зібрали агентний стенд на ChatDev: ролі аналітика, розробника, рев’юера й тестувальника працюють в одному діалозі й передають одне одному артефакти — уточнену постановку, патч, набір перевірок.
Кожна задача живе в окремій гілці, а в основну її пропускає закритий список перевірок: збірка, тести, звірка сигнатур і міграцій.
Що стало
Частка задач, що доходять до злиття з першого проходу, зросла з 35% до 78%, а медіанний час циклу правок скоротився з 9–11 днів до 2–3.
Клас відмов «модулі розійшлися за контрактом» перестав потрапляти в основну гілку: рев’юер-агент звіряє сигнатури до збірки, і розходження спливає на етапі постановки, а не на інтеграції.
Роль інженера залишилася вирішальною: фінальне злиття й спірні випадки — за людиною. Якщо агент не сходиться в рішенні, задача повертається з повним логом діалогу й переліком відхилених варіантів — розбір займає хвилини замість годин.
Чим ChatDev відрізняється від ручного складання сценаріїв агентів
Різниця не в тому, що один підхід розумніший, а в тому, де лежить відповідальність за результат прогону. У самописній зв’язці агентів ролі, порядок викликів і формат передавання контексту живуть у коді, написаному під конкретний сценарій.
Поки задач п’ять і всі одного типу, це швидко й гнучко. Коли сценаріїв десятки, а вхідні дані різнорідні, зв’язка починає поводитися по-різному на однакових запитах.
Відтворюваність прогонів страждає першою: стан розмазано між пам’яттю процесу, проміжними файлами й промптами, які правили по ходу. Повторити запуск можна, лише якщо від самого початку зберігали входи, версії ролей і порядок кроків.
Діагностика збоїв із тієї ж причини зводиться до читання коду й повторних запусків — журнал показує, що впало, але не чим був вхід.
| Що порівнюємо | Самописна зв’язка | Конвеєр ChatDev |
|---|---|---|
| Відтворюваність прогонів | залежить від того, що зберегли вручну | кроки й артефакти фіксуються за замовчуванням |
| Діагностика збоїв | за кодом і повторними запусками | за журналом кроків і даними між ними |
| Супровід конвеєра | правки в загальному коді на кожен сценарій | правила ролей і маршрутів спільні |
| Зростання кількості задач | час на розбір зростає лінійно | повтори й маршрутизація налаштовуються |
За зростання навантаження самописна зв’язка дорожчає не в розробці, а саме в супроводі конвеєра: кожен новий тип запиту тягне правки в загальний код і повторну перевірку вже працюючих ролей.
Готовий конвеєр закриває фіксацію кроків, повтори й маршрутизацію — доопрацювання залишаються точковими, а не наскрізними.
Сумніви техкоманди: контроль, відкати, ізоляція
Права агентів обмежуємо на рівні токена доступу: ChatDev отримує облікові дані лише на читання репозиторію й запис в окрему службову гілку.
Злиття робить людина через ручну перевірку, секрети в контекст агента не потрапляють, мережевий доступ контейнера обмежений списком дозволених адрес. Маніфест прав перевіряється за кожного запуску — вихід за межі зупиняє прогін, а не псує код.
Зациклення — друга часта історія: агенти переписують один і той самий файл по колу. Ставимо жорсткий ліміт ітерацій і кроків на задачу, стежимо, чи змінюється підсумкове розходження з базовою версією, і за зупинки змін прогін завершується звітом про причини. Плюс стеля на обсяг контексту — довгий цикл не перетворюється на некеровану витрату.
У легасі-репозиторій конвеєр вбудовуємо поступово: один модуль, ізольована гілка, характеризуючі перевірки на поточну поведінку. Результат агента проходить ті самі збірки й перевірки, що й ручні правки, — публічні контракти не змінюються нишком.
Як відкотити невдалий прогін?
Зміни живуть у службовій гілці й не впливають на основну. Не підійшов результат — гілка закривається, історія прогонів зі звітами зберігається для розбору. Відкат займає хвилини й не потребує ручної правки коду.
А якщо в легасі-коді немає тестів?
Спочатку закриваємо критичні шляхи перевірками, що фіксують поточну поведінку, і лише потім допускаємо агента до правок. Будь-яке розходження видно на збірці, а не після релізу в робочому контурі.
Обговоримо задачу: що потрібно для оцінки впровадження
Щоб повернутися з оцінкою та планом робіт, а не із загальними формулюваннями, нам потрібні вхідні дані щодо репозиторію, команди й поточних процесів.
Мультиагентна розробка вбудовується в наявний контур, тому спочатку дивимося, як влаштовані збірка, перевірки й приймання змін — від цього залежить і обсяг робіт, і те, які ділянки можна віддати агентам одразу, а які залишити за людьми.
- Структура репозиторію: мови, кількість модулів, стан збірки й тестів, де зосереджена основна логіка.
- Розгалуження й випуск версій: як готуються зміни, хто підтверджує злиття, як часто виходять релізи.
- Автоматичні перевірки: що запускається на кожну зміну, де перевірки досі робляться вручну.
- Склад команди: скільки інженерів володіє кодом, хто приймає результат агентів і як влаштована взаємна перевірка змін.
- Процеси роботи із задачами: як формулюються вимоги, де ведеться облік, за якими критеріями задача вважається готовою.
- Обмеження оточення: ізольовані середовища запуску, доступи, правила поводження з кодом і даними.
Цього набору достатньо, щоб повернутися з оцінкою та планом робіт: які ділянки закриваємо агентами, що залишається за інженерами, як перевіряємо результат на кожному кроці. Якщо частину вхідних даних ще не зібрано — не проблема, уточнимо в розмові й підкажемо, як їх отримати. Опишіть задачу — повернемося з оцінкою та планом.
