Если нужна гарантия, что агент действительно проверяет результат своей работы, одного промпта недостаточно. Надежнее всего работает многоуровневая схема: инструкции как baseline, хуки как детерминированный механизм и при необходимости, отдельный агент-ревьюер в рамках Spec-Driven Development (SDD).
Самый базовый и минимально необходимый вариант — явно прописать в файлах инструкций (AGENTS.md / CLAUDE.md), что перед завершением задачи агент обязан прогнать сборку, тесты и линтер. Но на практике такой подход не дает полной гарантии.
Если нужна именно детерминированность, лучше выносить проверку во внешний механизм. Для этого хорошо подходят хуки: например, финальный stop-hook, который срабатывает в конце агентского цикла, запускает нужные команды и возвращает ошибки обратно агенту. В таком режиме агент уже реально получает вывод компилятора, тестов или линтера и должен исправить проблему, прежде чем двигаться дальше.
Лично мне ближе подход, где это встроено в более широкий цикл разработки SDD. Когда есть понятная спецификация и поэтапный план, каждый шаг можно отдельно верифицировать: сначала проверить, что агент движется в рамках задачи, затем что код проходит детерминированные проверки, и только потом считать этап завершенным. Поверх этого хорошо ложится отдельный агент-ревьюер, который проверяет уже не только компиляцию, но и то, что решение действительно соответствует исходной задаче.
Вообще для open source это уже большая проблема. Раньше, если человек делал contribution, это почти всегда означало, что он реально вложился: разобрался в проекте, протестировал изменения, проверил, что его код работает. Сейчас этот входной барьер можно сказать исчез.
На мой взгляд с наплывом AI-assisted PRs нужно бороться такими же способами.
Например, почему бы команде не сделать бота (или может уже наверняка кто-то сделал такое), который будет модерировать и предварительно ревьюить PR уже на этапе открытия? Если это первый contribution от пользователя, к нему должны применяться повышенные требования. А еще лучше на первом этапе вообще не открывать PR, а заводить issue, где человек объясняет, что именно он хочет сделать и зачем. Такая фильтрация хотя бы помогает понять, насколько автор вообще адекватно понимает задачу и контекст проекта. Плюс стоит всегда автоматически делать первичный code review на уровне базовой адекватности: это вообще осмысленное изменение или полная фигня. Нужно обвешиваться всеми возможными guardrails.
История с wipe прям боль знакомая, сам терял сессию в OpenClaw похожим образом. Интересно, как восстанавливались: скиллы и конфиг пришлось собирать по чатам и памяти, или к тому моменту уже было что-то версионированное? И после инцидента дошли до автоматического provisioning, или пока остановились на ручных бэкапах?
Информация
В рейтинге
1 309-й
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Если нужна гарантия, что агент действительно проверяет результат своей работы, одного промпта недостаточно. Надежнее всего работает многоуровневая схема: инструкции как baseline, хуки как детерминированный механизм и при необходимости, отдельный агент-ревьюер в рамках Spec-Driven Development (SDD).
Самый базовый и минимально необходимый вариант — явно прописать в файлах инструкций (AGENTS.md / CLAUDE.md), что перед завершением задачи агент обязан прогнать сборку, тесты и линтер. Но на практике такой подход не дает полной гарантии.
Если нужна именно детерминированность, лучше выносить проверку во внешний механизм. Для этого хорошо подходят хуки: например, финальный stop-hook, который срабатывает в конце агентского цикла, запускает нужные команды и возвращает ошибки обратно агенту. В таком режиме агент уже реально получает вывод компилятора, тестов или линтера и должен исправить проблему, прежде чем двигаться дальше.
Лично мне ближе подход, где это встроено в более широкий цикл разработки SDD. Когда есть понятная спецификация и поэтапный план, каждый шаг можно отдельно верифицировать: сначала проверить, что агент движется в рамках задачи, затем что код проходит детерминированные проверки, и только потом считать этап завершенным. Поверх этого хорошо ложится отдельный агент-ревьюер, который проверяет уже не только компиляцию, но и то, что решение действительно соответствует исходной задаче.
Вообще для open source это уже большая проблема. Раньше, если человек делал contribution, это почти всегда означало, что он реально вложился: разобрался в проекте, протестировал изменения, проверил, что его код работает. Сейчас этот входной барьер можно сказать исчез.
На мой взгляд с наплывом AI-assisted PRs нужно бороться такими же способами.
Например, почему бы команде не сделать бота (или может уже наверняка кто-то сделал такое), который будет модерировать и предварительно ревьюить PR уже на этапе открытия? Если это первый contribution от пользователя, к нему должны применяться повышенные требования. А еще лучше на первом этапе вообще не открывать PR, а заводить issue, где человек объясняет, что именно он хочет сделать и зачем. Такая фильтрация хотя бы помогает понять, насколько автор вообще адекватно понимает задачу и контекст проекта. Плюс стоит всегда автоматически делать первичный code review на уровне базовой адекватности: это вообще осмысленное изменение или полная фигня. Нужно обвешиваться всеми возможными guardrails.
История с wipe прям боль знакомая, сам терял сессию в OpenClaw похожим образом. Интересно, как восстанавливались: скиллы и конфиг пришлось собирать по чатам и памяти, или к тому моменту уже было что-то версионированное? И после инцидента дошли до автоматического provisioning, или пока остановились на ручных бэкапах?