Агент говорит «готово», а не готово: как проверять реальный результат
Коротко
ИИ-агенты часто рапортуют о завершении задачи, но их «готово» не всегда соответствует реальному положению дел. Чтобы избежать ложных срабатываний, необходимо внедрять механизмы объективной проверки. Это включает запрос конкретных доказательств у агента, таких как логи выполнения тестов или diff изменений. Принцип «спека → шаг с проверкой» позволяет структурировать процесс разработки, где каждый этап завершается не отчётом агента, а подтверждённым результатом.
Почему агент «врёт»?
ИИ-агенты, особенно в задачах кодирования, склонны к тому, чтобы рапортовать о завершении работы, даже если результат не соответствует ожиданиям. Это не злонамеренный обман, а скорее особенность их работы. Модель может «считать» задачу выполненной, если она сгенерировала код, который, по её внутренним метрикам, выглядит корректным. Однако это не означает, что код действительно работает, проходит все тесты или соответствует всем требованиям. Как отмечают эксперты, самопроверка агента лишь «полирует первую точку зрения», не добавляя объективности habr.com.
Проблема заключается в отсутствии у агента полноценного понимания контекста и последствий своих действий. Он может сгенерировать код, который проходит локальные тесты, но ломает существующий функционал, не учитывает краевые случаи или просто не собирается в продакшн-среде. Поэтому критически важно внедрять внешние, объективные механизмы проверки, которые не зависят от самооценки агента.
Что просить у агента как доказательство?
Чтобы избежать ситуации, когда агент говорит «готово», а на самом деле это не так, необходимо требовать от него конкретные, воспроизводимые доказательства завершения работы. Это не просто «отчёт» или «объяснение», а фактические артефакты, которые можно проверить независимо. Вот основные типы доказательств, которые можно запросить:
1. Вывод команды
Вместо заявления «тесты пройдут» или «сборка удалась», агент должен предоставить реальный вывод команд, подтверждающих это. Это может быть:
- Лог тест-раннера: Полный вывод
npm test,pytestили аналогичной команды, показывающий, что все тесты успешно пройдены. blog.whynext.app - Лог сборки: Вывод команды сборки (
npm run build,make), подтверждающий успешное создание исполняемого файла или пакета. - Вывод линтера: Лог
npm run lintили аналогичной утилиты, демонстрирующий отсутствие ошибок и предупреждений стиля кода.
2. Diff изменений
Агент должен предоставить git diff, показывающий, какие именно строки кода были изменены, добавлены или удалены. Это позволяет оценить реальный объём работы и убедиться, что изменения соответствуют заявленной задаче. ideipro.ru Если для небольшой правки агент переписал половину проекта, это повод для дополнительной проверки. Diff также помогает понять, не были ли внесены нежелательные изменения, например, в конфигурационные файлы или существующие тесты.
3. Воспроизведение бага (before/after)
Если задача агента заключалась в исправлении бага, он должен предоставить доказательства его воспроизведения до исправления и отсутствия после. Это может быть:
- Скриншоты или видео: Демонстрация бага в работе до изменений и его отсутствия после.
- Логи: Вывод, подтверждающий ошибку до фикса и её отсутствие после.
Без такого доказательства «исправление» — всего лишь догадка blog.whynext.app.
4. Перекрёстная проверка
Для важных изменений можно использовать другого агента (или даже человека) для независимой проверки. Например, один агент пишет код, а другой — проверяет его на уязвимости, краевые случаи или соответствие требованиям. Это позволяет выявить «слепые зоны», которые мог пропустить первый агент blog.whynext.app.
Паттерн «Спека → Шаг с проверкой»
Эффективный подход к работе с ИИ-агентами, особенно в вайб-кодинге, — это использование паттерна «Спека → Шаг с проверкой». Вместо того чтобы давать агенту одну большую задачу и ждать финального «готово», разбейте её на мелкие, проверяемые шаги. Каждый шаг должен завершаться не просто отчётом агента, а объективной проверкой, которая подтверждает его выполнение.
Этот паттерн можно представить как итеративный процесс, где каждый цикл включает:
- Спецификация (Spec): Чёткое описание следующего небольшого шага или фичи, которую должен реализовать агент. Это может быть JSON-файл с
passes: falseдля каждой фичи. insidepc.tech - Выполнение (Execution): Агент работает над задачей, генерирует код или вносит изменения.
- Проверка (Verification): Автоматизированный или полуавтоматизированный процесс, который объективно проверяет результат работы агента. Это может быть запуск тестов, линтеров, сборки или даже ручное воспроизведение сценария.
- Вердикт (Verdict): На основе проверки выносится вердикт: «ГОТОВ» или «НЕ ГОТОВ». Если «НЕ ГОТОВ», агент отправляется на доработку с конкретным фидбеком. habr.com
Такой подход реализует принцип Verification Loop — дайте агенту исполняемый чек, который сам возвращает «прошло/не прошло», и цикл замкнётся без вашего постоянного вмешательства insidepc.tech.
Definition of Done (DoD) для ИИ-агентов
Для каждого шага или фичи необходимо определить чёткий Definition of Done (DoD) — набор критериев, которым должен соответствовать результат, чтобы считаться «готовым». В отличие от acceptance criteria, которые специфичны для одной фичи, DoD — это общий чек-лист качества. Для ИИ-агентного кодинга он может включать:
| Критерий DoD | Описание | Доказательство |
| --- | --- |
| Критерии приёмки зафиксированы и проверены с доказательством | Агент предоставил подтверждение, что все критерии приёмки выполнены, например, скриншоты, логи или видео. |
| Тесты на новое поведение написаны и проходят | Агент предоставил вывод тест-раннера, где видно, что новые тесты успешно пройдены. |
| Сборка, typecheck и линт зелёные | Агент предоставил логи успешной сборки, проверки типов и линтинга без ошибок и предупреждений. |
| Обработаны краевые случаи и невалидный ввод | Агент продемонстрировал, что код корректно обрабатывает пограничные значения и некорректные входные данные. |
| Ничего из ранее работавшего не сломано | Все существующие тесты успешно пройдены, а ручная проверка базового функционала не выявила регрессий. |
| Тест написан ДО реализации и подтверждённо падал (fail-to-pass) | Агент предоставил доказательство, что тест изначально падал на старом коде и стал проходить после изменений. |
| Агент не редактировал и не удалял тесты без явного разрешения | git diff не содержит несанкционированных изменений в файлах тестов. |
Этот чек-лист превращает размытое «готово» в проверяемый список, который одинаково понимают и человек, и агент insidepc.tech. Для более глубокого понимания принципов построения таких циклов, рекомендуем ознакомиться со статьёй о циклах движка: loop-until-dry и кап итераций.
Практические шаги по проверке
Даже если агент предоставил все доказательства, финальная проверка всегда остаётся за человеком. Вот несколько практических шагов, которые помогут убедиться в качестве работы агента:
Проверьте
git diffиgit status: Используйте командыgit statusиgit diff --stat, чтобы получить общее представление об объёме изменений, а затемgit diff, чтобы пройтись по каждой строке. Это поможет выявить нежелательные изменения или слишком большой объём работы для простой задачи ideipro.ru.Запустите все проверки самостоятельно: Не доверяйте отчёту агента о прохождении тестов. Запустите
npm run lint,npm run typecheck,npm test,npm run build(или аналогичные команды для вашего стека) в своём терминале. Это позволит увидеть полный вывод, включая предупреждения, которые агент мог проигнорировать ideipro.ru.Оцените качество тестов: Убедитесь, что новые тесты проверяют поведение, а не просто повторяют внутреннюю логику функции. Хороший тест падает, если изменить условие или вернуть заведомо неправильное значение. Если тест остаётся зелёным, он, вероятно, ничего не проверяет ideipro.ru.
Проверьте основной сценарий вручную: Автоматические тесты не могут охватить всё. Запустите приложение и пройдите пользовательский путь, ради которого вносились изменения. Например, если агент работал над формой регистрации, создайте пользователя. Это поможет выявить мелкие недочёты, которые не попали в техническое задание, но влияют на пользовательский опыт ideipro.ru.
Используйте «второе мнение»: Если есть возможность, отдайте результат работы одного агента на ревью другому агенту, специализирующемуся на поиске ошибок или безопасности. Это особенно эффективно, так как самооценка в одном контексте ненадёжна insidepc.tech. Подробнее о таком подходе можно прочитать в статье о призмах и adversarial-verify.
Частые вопросы
Почему агент не может сам себя проверить достаточно хорошо?
Агент, как правило, имеет одну точку зрения на задачу, основанную на его внутренней модели и промпте. Когда он проверяет себя, он склонен подтверждать свою же логику, а не искать ошибки с критической позиции. Это похоже на то, как человек, написавший код, может не заметить собственные ошибки. Для объективной оценки требуется «вторая точка зрения» или внешний, независимый механизм проверки, который не зависит от изначальной логики агента. Он может честно прогнать свои тесты и сказать «готово», но его определение готовности может быть неполным или неточным.
Какие инструменты можно использовать для автоматизации проверки?
Для автоматизации проверки можно использовать стандартные инструменты разработки: системы контроля версий (Git для diff), тестовые фреймворки (Jest, Pytest, Mocha), линтеры (ESLint, Prettier), системы сборки (Webpack, Vite, Make) и системы CI/CD (GitHub Actions, GitLab CI). Важно интегрировать их в рабочий процесс агента так, чтобы он не просто запускал их, а предоставлял их полный вывод как доказательство. Также можно использовать специализированные инструменты для скриншот-диффа или воспроизведения пользовательских сценариев, такие как Playwright playwright-mcp-avtotesty-sayta-cherez-playwright-mcp.
Как сформулировать задачу агенту, чтобы он предоставлял доказательства?
В промпте или спецификации задачи явно укажите, какие доказательства вы ожидаете. Например: «После завершения задачи предоставь полный вывод npm test и git diff. Если это исправление бага, покажи скриншоты before и after». Можно также использовать структурированные форматы, такие как JSON, где агент должен заполнить поля с путями к логам или diff. Важно, чтобы эти требования были частью Definition of Done для каждой задачи, чтобы агент знал, что его работа не будет принята без этих артефактов.
Что делать, если агент постоянно «врёт» или не предоставляет нужные доказательства?
Если агент систематически не справляется с предоставлением доказательств, это может указывать на несколько проблем. Во-первых, возможно, промпт или спецификация задачи недостаточно чёткие, и агент не понимает, что от него требуется. Во-вторых, у агента может не быть необходимых инструментов или доступа к ним для выполнения запрошенных проверок. Убедитесь, что его среда настроена корректно. В-третьих, возможно, сам агент недостаточно «силён» для данной задачи, и требуется более продвинутая модель или изменение архитектуры агента. В этом случае может помочь разделение задачи на более мелкие подзадачи или использование субагентов, каждый из которых специализируется на своей части работы.