Как контролировать долгую агентную задачу: план, контрольные точки и право остановки
Долгая агентная задача опасна не тем, что модель делает много шагов, а тем, что человек перестаёт замечать момент, когда правильный план стал неверным. Агент создаёт файлы, читает логи, запускает команды и выглядит занятым. Но занятость не равна движению к принятому результату. Этот гайд помогает собрать процесс, в котором любой шаг можно проверить, остановить и повторить.
Шаг 1. Опишите результат до запуска
Не давайте поручение «исправь проект» или «подготовь исследование». Сформулируйте выход: список из пяти найденных причин ошибки, pull request без изменения инфраструктуры, таблица с источниками и пустыми полями там, где факта нет. Добавьте запреты и бюджет: какие каталоги доступны, сколько времени можно работать, что считается стоп-сигналом. Если человек не может принять результат по нескольким ясным признакам, агент не сможет сам понять, что готово.
Шаг 2. Разделите план и исполнение
Попросите модель сначала предложить короткий план с контрольными точками. Человек проверяет, не пропущен ли источник, не выходит ли действие за полномочия и где потребуется тест. Затем разрешается только первая часть плана. После результата сравните его с критерием и переходите дальше. Это медленнее, чем один безнадзорный запуск, но быстрее, чем разбирать десятки ошибочных изменений в конце.
Шаг 3. Дайте минимальные инструменты
Агент получает не оболочку сервера целиком, а конкретные функции: прочитать каталог, создать файл в рабочей ветке, запустить один тест, найти документ в утверждённой базе. Аргументы проверяются кодом. Сеть, секреты, удаление и отправка сообщений включаются только отдельным решением. Права должны зависеть от задачи, а не от того, насколько «умной» кажется модель.
Шаг 4. Введите контрольные точки
Хорошая точка — видимый артефакт: список прочитанных источников, diff, тестовый отчёт, черновик таблицы. После каждой точки человек или автоматическая проверка отвечает на один вопрос: можно ли продолжать? Не заставляйте проверяющего читать длинное рассуждение модели. Ему нужны исходник, изменение, результат теста и причина следующего шага.
Шаг 5. Ограничьте расходы и циклы
Задайте максимум вызовов, времени и повторов одной операции. Если агент трижды получает одинаковую ошибку, он останавливается и формирует короткий отчёт: что пробовал, что увидел, какие данные отсутствуют. Нельзя оставлять цикл «попробую ещё раз» на ночь. Бюджет — это не только деньги за API, но и время человека, который утром будет распутывать последствия.
Шаг 6. Храните след решения
Запишите версию модели, конфигурацию, входные файлы, вызванные инструменты, созданные артефакты и статус проверки. Не храните секреты и лишние персональные данные в свободном логе. Для кода достаточно связать запись с веткой и commit; для исследования — со списком источников и версией документа. Такой след поможет сравнить последующий запуск и вернуть задачу к безопасной точке.
Шаг 7. Сделайте проверку независимой
Агент не должен оценивать собственную работу единственным тестом, который он сам написал. Используйте существующую CI-проверку, контрольный набор, второго рецензента или простое правило сравнения. Для текстового отчёта отдельно проверяйте числа, цитаты и отсутствие выдуманных фактов. В гайде о подготовке ИИ к независимой проверке есть вариант такой приёмки для непроцессных задач.
FAQ
Нужна ли контрольная точка после каждого вызова? Нет, после смыслового блока с наблюдаемым результатом. Можно ли запускать ночью? Только обратимый сценарий с жёстким бюджетом и аварийной остановкой. Кто владелец? Человек, принимающий конечный артефакт. Что делать с неудачей? Сохранить отчёт и сузить задачу, а не продолжать наугад. Можно ли дать агенту интернет? Только через разрешённые источники и с журналом запросов.
Иллюстрация редакции: авторская схема контрольных точек для агентной задачи, не снимок реального инструмента.