Петля обратной связи

Назначение

Дать агенту способ проверить результат, прочитать ошибку и повторить работу до выполнения критерия. Агент запускает проверку внутри сессии, а вы получаете результат вместе с доказательствами.

Также известен как

Give the agent a way to verify its work, verification loop, замкнутый цикл проверки.

Проблема

Без проверки агент может остановиться на правдоподобном коде. Например, валидатор принимает корректный промокод, но ошибается на просроченном.

Если теста нет, ошибку должны заметить вы. До этого агент считает задачу завершённой.

Критерий готовности должен описывать наблюдаемое поведение. Тогда агент сможет отличить написанную реализацию от проверенного результата.

Решение

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

Агент выполняет правку, запускает проверку и исправляет найденный сбой. Вы выбираете критерии до начала работы и оцениваете доказательства в конце.

Степень автоматизации цикла можно выбирать под задачу.

1. Инструкция в промпте просит агента запускать проверки и исправлять найденные ошибки.
2. Цель на сессию задаёт условие, к которому агент возвращается после очередного шага.
3. Детерминированный гейт блокирует завершение, пока обязательная проверка не прошла.
4. Второе мнение добавляет ревью в свежем контексте для проверки полноты и качества (см. писателя и рецензента).

Доказательство должно прийти из окружения, а не из рассказа агента. Вывод, который агент перепечатал в итоговое сообщение, он мог и сочинить: написать 4 passed без запуска или по запуску до последней правки. Проверяйте по записи, которую сохранил харнес: вызову инструмента в журнале сессии, логу CI, коду возврата в хуке, скриншоту от браузерного инструмента. Эти данные показывают, что именно агент проверил, и помогают принять работу без восстановления всей сессии.

Структура

На схеме разработчик передаёт задачу и критерии проверки.

Агент повторяет цикл правок и проверок до успеха, затем возвращает доказательства. Хук может закрепить условие выхода, а независимое ревью дополнить автоматические проверки.

Участники / Компоненты

• Разработчик задаёт критерии и принимает результат по доказательствам.
• Агент меняет код, запускает проверку и разбирает результат.
• Проверка оценивает заданное свойство результата.
• Сигнал сообщает агенту, выполнен ли критерий.
• Доказательства сохраняют команду, вывод или изображение проверенного состояния. Их записывает окружение, а не агент.

Когда применять

• Результат можно проверить воспроизводимым способом.
• Агент должен выполнять несколько итераций без постоянного наблюдения.
• Интерфейс можно сравнить с макетом по заданным критериям.
• Баг можно воспроизвести тестом до начала исправления.

Последствия и компромиссы

• ➕ Агент разбирает найденные ошибки без ожидания ручной проверки каждого шага.
• ➕ Часть дефектов обнаруживается до ревью.
• ➕ По сохранённым результатам вы видите объём выполненной проверки.
• ➖ Если проверки нет, её подготовка потребует отдельной работы.
• ➖ Слабая проверка пропустит реализацию, которая не решает задачу полностью.
• ➖ Агент может ослабить проверку ради успеха. Изменения критериев нужно контролировать отдельно.

Реализация

1. Опишите ожидаемое поведение до реализации и укажите, как его проверить.
2. Если проверки нет, начните с воспроизводящего теста (см. TDD с агентом).
3. Попросите запускать проверку после правок, читать результат и исправлять обнаруженные ошибки.
4. Защитите критерии от подгонки. Изменение теста или ослабление условия согласуйте отдельно; при необходимости закрепите ограничение хуком.
5. Для длительной автономной работы добавьте контроль завершения и ревью в свежем контексте.
6. Принимайте работу по записям окружения: журналу вызовов инструментов, логу CI или результату хука. Пересказ результата в итоговом сообщении агента доказательством не считается.
7. Закрепите команды проверки в памяти проекта, чтобы агент знал их в каждой сессии.

В OpenSpec, Superpowers и скиллах Мэтта Покока проверки входят в рабочий процесс реализации. Конкретный механизм зависит от набора скиллов и критериев задачи.

Пример

Для валидатора промокодов вы задаёте проверяемые случаи вместе с задачей.

Напиши validatePromoCode: SUMMER25 принимается, просроченный код отклоняется с причиной expired, код другого региона — с причиной region, пустая строка отклоняется

Агент пишет тесты и реализацию. Проверка просроченного кода падает, потому что сравнение дат не учитывает часовой пояс. После исправления агент повторяет запуск. В журнале сессии виден последний прогон тестов после финальной правки с результатом 4 passed.

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

Антипаттерны и частые ошибки

• Поверить на слово. Сообщение «готово» не показывает, что проверял агент. Требуйте результаты запуска.
• Пересказанный вывод. Строка 4 passed в итоговом сообщении — тоже слова агента. Сверяйте её с запуском в журнале сессии или в CI.
• Слабый оракул. Проверка может пропустить значимые случаи. Сверяйте её с требованиями задачи.
• Проверка без запуска. Наличие тестов в репозитории не означает, что агент их выполнил. Задайте команду и условие завершения.
• Подгонка проверки. Ослабленное условие скрывает дефект. Изменения критерия требуют отдельного решения.
• Юнит-тесты как финал. Для пользовательской фичи проверьте также сквозной сценарий, иначе возможен преждевременный успех.

Известные применения

• Claude Code best practices описывают постановку задач с критериями и примерами проверки.
• Агентские инструменты могут поддерживать цели на сессию, Stop-хуки и ревью-сабагентов.
• Харнес Anthropic для долгоживущих агентов связывает статусы фич с проверками и запускает smoke-тест в начале сессии.
• SDD-тулкиты включают критерии приёмки в спецификации и задачи, а Superpowers использует цикл TDD.

Связанные паттерны

• Шлюзы качества проверяют стандарты всего проекта на каждом изменении, а не критерий одной задачи.
• TDD с агентом начинает итерацию с теста до изменения кода.
• Писатель и рецензент проверяет свойства, для которых нужно суждение.
• Рефлексия помогает найти недостатки через самокритику, но требует внешнего подтверждения.
• Четыре фазы задаёт проверки в плане и использует их при реализации.
• Преждевременный успех возникает, когда работу объявляют готовой без сквозной проверки пользовательского сценария.
• Уан-шот описывает ожидание готового результата от одного прохода без цикла проверки.