📊 Мультиагентная QA-система: 4 месяца спустя — цифры, эволюция, что удивило #qa#ai#head

В прошлом посте я рассказал, как устроена наша мультиагентная QA-система на Claude Code: координатор и несколько исполнителей-агентов, файловая шина, slash-команды как точки входа.

Теперь у меня есть 4 месяца данных. Полез в docs/test-sessions/, посчитал всё, что можно посчитать, и выписал интересное. Без приукрашиваний — где система выросла, а где стало сложнее.

📈 Объём вырос в 10 раз за два месяца Реальные /qa-сессии (с менеджерским планом и хотя бы одним исполнителем):

• Январь — 2 • Февраль — 2 • Март — 14 • Апрель — 20

Между февралём и апрелём — рост в 10 раз. Не потому что задач стало больше, а потому что порог запуска упал. В январе /qa запускалось «когда есть силы разобраться, если что-то пойдёт не так». В апреле — рутина: пришла задача, скопировал ссылку, нажал, через 30 минут читаешь отчёт.

Это та самая «фаза, когда инструмент перестаёт быть проектом и становится рукой». Заметить переход легко: смотришь в логи и не помнишь половину сессий. Они просто прошли.

🧩 Сессии стали сложнее Среднее число файлов в папке сессии (прокси-метрика для сложности):

• Январь — 6.5 • Февраль — 9.0 • Март — 10.6 • Апрель — 19.6

Что туда попадает: артефакты curl-ответов, логи, выгрузки отчётов, JSON с дампами для воспроизведения. Раньше менеджер просил агентов «проверить эндпоинт». Теперь — «прогони полный E2E с записью артефактов на каждом шаге, чтобы при ретесте можно было сравнить».

Самая большая сессия за апрель — 162 файла, 5 раундов тестирования, 5 МБ артефактов. Это была верификация фикса по сложной финансовой задаче: каждый раунд после деплоя заново снимали состояние, отчёты, логи и сравнивали с предыдущим. Без агентов это было бы три полных рабочих дня. У нас — 6 итераций за неделю в фоне, с детальным аудитом каждого прохода.

🔁 Появился ретест в несколько раундов Доля сессий с несколькими раундами (manager-plan-round2.md, round3.md и т.д.):

• Январь — 0% • Февраль — 0% • Март — 7% • Апрель — 20%

Рост говорит не о падении качества первой попытки, а о том, что система научилась дожимать. Раньше: нашли баг → пошли в ручной режим. Теперь: нашли баг → завели discoveries.md → ждём фикс на стенде → запускаем round 2 → сравниваем с round 1.

Каждый раунд — это новый менеджерский план, новый task-api.md с пере-фокусом на проблемную область, новый отчёт. Менеджер помнит контекст предыдущих раундов через файлы, не через свою память. Это важно — иначе после 3-го раунда контекст переполняется, и качество решений падает.

💬 Кросс-агентная коммуникация выросла на порядок discoveries.md — общий файл, куда Web Tester и API Tester в реальном времени дописывают находки. Это компенсирует то, что они работают параллельно и не видят друг друга.

Среднее число строк в discoveries.md на сессию:

• Январь — 0 (тогда discoveries ещё не использовался) • Февраль — 68 • Март — 17 • Апрель — 76

Доля сессий, где discoveries.md реально использовался: 0% → 100% → 71% → 85%.

Один из самых полезных кейсов: Web Tester, копаясь в JS фронтенда, обнаружил, что фронт шлёт параметр не в том формате, который ожидает документация. Записал это в discoveries. API Tester читал файл каждую минуту, увидел запись, переключился на правильный формат — и обнаружил, что бекенд этот формат игнорирует. Без discoveries.md API Tester ушёл бы в тупик с правильным эндпоинтом и неправильным параметром.

Это и есть та самая параллельность с координацией без блокировки. Один агент не ждёт другого — он пишет в общий файл и продолжает работу.

🐛 Качество отчётов: открытых вопросов почти нет Считал, сколько в финальных отчётах оставалось «открытых вопросов» — то есть пунктов, которые агенты не смогли проверить и оставили на потом:

• Среднее по апрелю — 0.55 вопроса на отчёт Это значит: агенты дожимают то, что им поручили. Не пишут «не смог проверить, потому что нет данных» — идут и создают данные через curl. Не пишут «UI не открылся» — отлаживают MCP-браузер до победы или открывают файл через JS.