Разработка AI-агента для отладки кода: архитектура «Агента Смита» от ТестОпс

Сергей Левенец, CTO команды ТестОпс, описал реальный опыт создания внутреннего агента под рабочим названием «Агент Смит». Задача звучала амбициозно: ноль багов в бэклоге. Первую версию собрали за два-три дня, но основное время ушло на отладку шагов и настройку вспомогательных модулей. По словам Левенца, самым сложным оказалось научиться оценивать издержки от внедрения агента, а не просто запустить его.

Из чего состоит «Агент Смит» сегодня?

«Агент Смит» вырос в платформу. Кроме исправления багов на ней работают:

• воспроизведение багов в браузере,
• автоматизация ручных тест-кейсов,
• ревью кода по требованиям,
• подготовка тестовой документации.

Лучше всего отлажен именно процесс исправления багов. Команда подчёркивает: текущий набор шагов не «канон», а временная гипотеза, которая постоянно пересматривается.

Что понадобится

• Любая LLM с поддержкой длинного контекста (команда не раскрывает конкретную модель, но архитектура подразумевает несколько отдельных вызовов с чистым контекстом).
• Граф кода (инструмент индексации кодовой базы, чтобы агент видел связи между файлами).
• Система задач с машинно читаемыми баг-репортами (Jira, YouTrack или аналог).
• Список защищённых путей: helm/, k8s/, Dockerfile, конфиги CI, файлы, которые агент не имеет права трогать.
• Два-три дня на первую версию и значительно больше на отладку шагов.

Пошаговая инструкция: как устроен прогон агента

1. PREPARE: подготовка рабочей зоны. Агент определяет, от какой ветки отталкиваться и куда пойдёт мёрж-реквест (запрос на слияние кода): в основную ветку, релизную или фича-ветку. Делает чекаут, создаёт свою ветку под фикс, запускает переиндексацию графа кода. Если граф не собрался, следующий шаг не получит граф-контекст вовсе: устаревший граф хуже, чем никакого. Здесь же применяется список защищённых путей.

2. ACCEPTANCE: формирование критериев приёмки. Агент читает баг-репорт и формулирует, что значит «пофикшено». Читать код ему при этом запрещено: единственный вход на этом шаге это сам репорт. Причина: агент здесь выступает оракулом (тем, кто решает, какое поведение правильное). Оракул, увидевший реализацию, начинает описывать то, что код делает, вместо того, что он должен делать, и вся проверка превращается в тавтологию. Каждый критерий опирается на дословную цитату из репорта. Если нечего процитировать, это догадка, а не требование. Отдельно агент выписывает смежное поведение, которое фикс не должен сломать. Если в задаче не хватает данных (текстов, локализации, значений), агент не сочиняет правдоподобное, а помечает задачу заблокированной. На этой стадии первая точка, где нужен человек: агент просит у тестировщиков уточнение.

3. DIAGNOSE: поиск корневой причины. Агент читает код, ничего не меняя, ищет корневую причину, а не место падения. На выходе: гипотеза, файл, строки, отвергнутые версии и слой, в котором будет правка. Два вопроса дороже остальных: это один баг или целый класс? И меняет ли фикс инвариант (неизменное правило), на который опирается чужой код? Отдельно закодифицировано правило против допущения «в бэкенде это уже работает, тут только допилить UI»: агент обязан подтвердить это чтением кода.

4. JUDGE: независимая проверка диагноза. Отдельный вызов модели с чистым контекстом (судья не видит рассуждений автора диагноза) сверяет диагноз с критериями приёмки. Проверяется одно: объясняет ли названная причина заявленный симптом? При расхождении диагноз пересобирается с обратной связью судьи, до двух раз. Дальше прогон останавливается, задача возвращается человеку с обоими вердиктами.

5. ESTIMATE: оценка сложности. Оценка в стори-поинтах (условных единицах сложности задачи) по шкале {0.5, 1, 2, 3, 5}. Для каждого значения в промпте прописаны объективные признаки, чтобы это была классификация, а не интуиция. Отдельно оценивается радиус поражения: практика показала, что это самостоятельная ось риска, не зависящая от объёма правки. Оценка от двух считается дорогой и останавливает процесс до подтверждения человеком.

Что делать с этим прямо сейчас?

Разработчикам и тимлидам. Архитектура «граф вместо цепочки промптов» с JSON-артефактами на каждом шаге воспроизводима на любом стеке. Начните с двух шагов (ACCEPTANCE и DIAGNOSE), добавьте JUDGE как отдельный вызов с чистым контекстом и посмотрите, сколько ложных диагнозов отсеивается.

Авторам Дзена и контент-маркетологам. Принцип «оракул не должен видеть реализацию» работает и в контенте: когда вы проверяете текст нейросети, сначала сформулируйте, что должно быть в тексте, и только потом читайте результат. Иначе вы будете подгонять оценку под то, что модель уже написала.

Предпринимателям в РФ и СНГ. Ai агенты разработка (агентный подход к автоматизации рутины в коде) не требуют конкретного облачного провайдера. Команда ТестОпс не раскрывает, какую именно модель использует, а значит, архитектура переносима: можно собрать аналог на доступных в России API, включая GigaChat или YandexGPT, если модель поддерживает длинный контекст и структурированный вывод.

Принцип «оракул не видит реализацию» стоит забрать в любой рабочий процесс с нейросетями, не только в код. Сначала критерии, потом результат, потом независимая проверка. Это дешевле, чем три итерации переделки, и работает одинаково для бага в коде и для текста в редакторской задаче.