Автономный AI-агент: как отпустить агента работать часами и не получить мусор

Что такое автономный AI-агент и чем он отличается от обычного запроса

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

Звучит просто, но типичный первый опыт выглядит так: агент получил задачу утром, а вечером выясняется, что он несколько часов правил уже исправленный баг, потому что забыл, что сделал час назад. Никто не сказал ему, когда остановиться и когда позвать человека. Ниже — как спроектировать цикл, который этого не допускает.

Важная оговорка: цикл не заменяет харнес. Харнес делает надёжным один прогон, цикл делает прогоны непрерывными. Цикл поверх плохого харнеса просто быстрее производит мусор.

Подходит ли задача для автономного агента

Первый вопрос — есть ли у работы финишная черта, которую можно проверить машиной. «Все тесты в каталоге tests/payments проходят», «все фичи из списка в статусе passing», «метрика выросла относительно базовой линии» — подходит. «Сделай код лучше» или «продолжай улучшать платежи» — нет: у такой цели нет конца, и цикл будет крутиться, пока не съест бюджет.

Полезно различать четыре типа циклов:

• Пошаговый — вы вводите каждый промпт; это обычная интерактивная работа.
• По цели — вы задаёте цель, останавливает независимая проверка или бюджет. Это и есть автономный агент на часы.
• По времени — запуск по расписанию (например, утренний разбор упавших сборок CI), останавливаете вручную.
• По событию — внешний триггер (новый issue, упавший деплой), останавливает обработка события или лимит повторов.

Частая ошибка — путать цикл по времени с циклом по цели: «каждые 10 минут продолжай делать платежи». Цикл по расписанию каждый раз начинает инструкцию с нуля и не знает, что уже сделано. Если у задачи есть финиш, нужен цикл по цели с памятью о прогрессе.

Шаг 1. Песочница: где агенту можно ломать

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

• Отдельная рабочая копия. git worktree даёт агенту свой каталог и свою ветку поверх того же репозитория. Основная ветка не трогается, несколько агентов не мешают друг другу, а неудачный прогон удаляется одной командой.
• Контейнер или виртуальная машина. Если агенту нужен полный доступ к командам, запускайте его в контейнере без доступа к домашнему каталогу, ключам и продовым базам.
• Тестовые данные. Локальная база, песочницы платёжных систем, фиктивные ключи. Ни одного продового секрета в окружении агента.

# своя ветка и каталог для автономного прогона
git worktree add ../shop-agent -b agent/f03-refunds

# после прогона: посмотреть результат или выбросить
git -C ../shop-agent log --oneline main..
git worktree remove ../shop-agent

Шаг 2. Права: минимум, достаточный для задачи

Чем дольше агент работает один, тем уже должны быть его права. В Claude Code разрешения настраиваются в settings.json (списки allow и deny для инструментов и команд): явно разрешите то, что нужно задаче, — запуск тестов, линтера, правку файлов в рабочей копии, — и запретите опасное: push в основную ветку, работу с секретами, сетевые команды, если они не нужны.

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

Запреты, которые нельзя нарушить, подкрепляйте механикой, а не текстом. Строчка «не трогай migrations/» в инструкции — это пожелание; хук, который блокирует правку этого каталога, или права файловой системы — гарантия.

Шаг 3. Цель, проверка, остановка — три строки до запуска

Простейший рабочий цикл держится на трёх вещах, и их стоит записать до запуска, а не по ходу:

1. Цель — как выглядит конечное состояние.
2. Верификация — машинно проверяемый способ узнать, что цель достигнута: команда, которая возвращает успех или ошибку.
3. Условие остановки — лимит попыток, времени или денег, после которого цикл останавливается, даже если цель не достигнута.

Удобно держать это в отдельном файле методологии, который правит только человек. Пример для платёжного бэкенда:

# program.md — методология автономного прогона

## Цель
Все фичи из .agent/feature_list.json в состоянии passing.

## Метрика
Число фич в passing. Растёт монотонно. Регрессия = немедленный откат.

## Ограничения
- Одна фича в работе одновременно.
- Не менять migrations/ и infra/.
- Не трогать зависимости без записи в журнал.

## Порядок работы
1. Взять первую фичу не в passing.
2. Реализовать, прогнать pytest и линтер.
3. Зелёное — коммит и запись в .agent/progress.md. Красное — исправить.

## Остановка и эскалация
- 3 неудачные попытки на одну фичу — пометить blocked, перейти к следующей.
- Все оставшиеся blocked — остановиться и написать отчёт.
- Любая задача про деньги клиентов, права доступа, удаление данных — не делать, а эскалировать.

Шаг 4. Цикл проверка-исправление с памятью на диске

Окно контекста не переживает долгую работу: оно переполняется, сжимается, сессия перезапускается. Поэтому прогресс должен жить в файлах, а не в «голове» агента: список задач со статусами, журнал того, что сделано и что не сработало, git-история.

Хорошая модель — «трещотка, которая движется только вперёд», как в проекте autoresearch Андрея Карпатого, где агент за ночь проводит сотни ML-экспериментов. Каждая итерация: прочитать методологию, выдвинуть гипотезу, внести изменение, прогнать эксперимент с фиксированным бюджетом времени, сравнить с базовой линией. Улучшило — коммит, не улучшило — откат. Результат записывается в журнал, затем следующая гипотеза.

Из этой схемы стоит взять два решения:

• Фиксированный бюджет на попытку. Попытки становятся сравнимыми, и одна неудачная гипотеза не съедает всю ночь.
• В основной ветке только улучшения. Всё, что не сработало, откачено, а не свалено рядом. git log превращается в проверенный журнал работы, который утром легко прочитать.

Там же видно разделение ролей по файлам: инфраструктуру и оценку не правит никто, код эксперимента правит только агент, методологию — только человек. Агент не может «улучшить» результат, подкрутив способ его измерения.

Шаг 5. Кто решает, что готово: отдельный оценщик

Когда человека в петле нет, самооценка агента становится единственным тормозом — и этот тормоз не работает. Агент, который только что написал код, склонен считать его правильным: он видит свои рассуждения и «знает», что хотел сделать.

Правила разделения генератора и оценщика:

• Оценивает не та сессия, что делала работу. В Claude Code для этого удобны субагенты: у каждого свой контекст.
• Оценщик получает чистый контекст: требование, диф и результаты прогонов — и ничего из рассуждений исполнителя.
• По возможности оценщик — другая модель или хотя бы другой промпт с другой ролью.
• Вердикт выносится по рубрике, и каждый пункт ссылается на доказательство: строку теста, вывод команды, место в дифе.

Машинные проверки всё равно первичны. Оценщик нужен для того, что тесты не ловят: требование понято не так, тест подогнан под код, изменение вышло за рамки задачи.

Критерии остановки: когда агент должен сдаться

Цикл без условий остановки зацикливается — это вопрос времени. Минимальный набор:

Прогресс проверяйте по существу, а не по числу попыток: «сделано 40 итераций» ничего не значит, «число зелёных фич выросло с 5 до 9» — значит. Если задача буксует, это повод передать её человеку, а не гонять цикл ещё раз.

Риски автономного агента, которые не видны сразу

Очевидные риски — удалённые файлы и сломанная сборка — закрываются песочницей и правами. Опаснее тихие издержки, которые копятся неделями:

• Долг верификации. «Выглядит нормально» вместо «машинно подтверждено». Противоядие — только машинно проверяемые условия остановки, без исключений.
• Деградация понимания. Вы всё хуже знаете собственный код. Противоядие — обязательное чтение дифов: скорость цикла не должна превышать скорость вашего чтения.
• Когнитивная капитуляция. Вы перестаёте иметь мнение о результате и принимаете всё подряд. Полезно честно считать случаи «посмотрю позже» и не посмотрел.
• Раздувание контекста. Длинный прогон накапливает историю, и каждый следующий шаг дороже и хуже. Сжатие контекста и внешняя память нужны с первого цикла, а не когда всё уже поплыло.

Как запустить первый автономный цикл за вечер

Не начинайте с «агент сам найдёт и сделает задачи». Автономия растёт ступенями: сначала одна задача с целью и условием остановки, потом одна автоматизация по расписанию, потом разведённые исполнитель и проверяющий в изолированной рабочей копии, и только затем циклы, которые сами находят работу и идут параллельно.

1. Найдите задачу, которую делаете руками минимум дважды в неделю и у которой есть проверяемый финиш.
2. Запишите цель, верификацию и условие остановки — три строки.
3. Создайте отдельный worktree и настройте права: тесты и правка файлов разрешены, push и секреты — нет.
4. Заведите файл прогресса и попросите агента обновлять его после каждой итерации.
5. Разведите роли: исполнитель пишет, проверяющий в отдельном контексте оценивает диф.
6. Поставьте общий лимит и первый раз проверьте результат через час, а не утром.

Итог

Автономный AI-агент надёжен ровно настолько, насколько надёжны его рамки: песочница, где ошибка ничего не стоит, минимальные права, машинно проверяемая цель, память на диске, отдельный оценщик и жёсткие условия остановки с эскалацией к человеку. Без этого долгий прогон — не экономия времени, а отложенный разбор завалов. Как собрать такой цикл на сквозном проекте — от program.md до независимого оценщика — разобрано на практике в курсе по harness engineering.