2 мин чтения

13 агентов замыкают цикл тестов и исправлений

мультиагентные системыавтономная разработкаисправление ошибок

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

Как устроен цикл из 13 агентов

Меня здесь цепляет сама механика: 13 параллельных подписок Codex и Claude используются как пул специализированных агентов. Одни запускают тесты и оформляют отчеты об ошибках, другие автоматически готовят исправления. На момент обсуждения общий расход указан в диапазоне от $100 до $200.

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

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

Есть и более жесткая проверка самой идеи автономного ремонта. В исследовании Google агентный подход оценивался на 178 ошибках из внутренней системы учета. При 20 траекториях и Gemini 1.5 Pro система Passerine подготовила правдоподобные патчи для 73% машинных отчетов и 25,6% отчетов, созданных людьми. Правдоподобный патч, конечно, еще не равен безопасному слиянию.

Я бы первым делом проверял четыре границы:

  • изоляцию рабочих копий и окружений;
  • защиту от конфликтующих патчей;
  • независимость тестирующего агента от автора исправления;
  • условия остановки бесконечного цикла тестов и правок.

Что действительно меняется для разработки

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

Но один клиентский кейс не доказывает массовое внедрение такой схемы предприятиями. Документы Microsoft и Salesforce показывают, что мультиагентные архитектуры уже формализуют для корпоративных систем, а SWE-bench, RepairBench и DevAgentBench дают способы измерять исправление кода, генерацию тестов и ревью. Между архитектурным паттерном и надежным автономным конвейером все еще лежит контроль качества.

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

Ранее мы разбирали, как параллельные агенты Claude Code могут проверять pull request'ы и выявлять состояния гонки до попадания в CI/CD. Этот подход дополняет мультиагентные процессы тестирования и исправления ошибок, распределяющие задачи разработки между специализированными LLM-агентами.