Откат агента: как вернуть систему в рабочее состояние после сбоя

Агент на базе языковой модели отличается от чат-бота одним: он не советует, а действует. Вызывает API, пишет в базу, отправляет сообщения, меняет файлы. Пока он справляется, это экономит часы. Когда ошибается — а ошибается он не так, как обычный скрипт, — последствия приходится разгребать руками. Механизм отката (rollback) для агента отвечает на вопрос: как вернуть систему в состояние до запуска, если запуск пошёл не по плану.

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

Чем откат агента сложнее отката транзакции в базе

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

Три типа побочных эффектов, которые ведут себя по-разному при откате:

• Обратимые — запись в вашу базу, создание файла, добавление задачи в очередь. Их можно вернуть, если вы сохранили предыдущее состояние.
• Частично обратимые — вызов внешнего платного API, изменение записи у стороннего провайдера. Технически откатить можно, но иногда за деньги или с задержкой.
• Необратимые — отправленное письмо, списанный платёж, опубликованный пост, удалённый бэкап. Отменить нельзя. Можно только компенсировать — например, послать письмо с извинением или инициировать возврат средств.

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

Четыре стратегии отката

Единого рецепта нет: выбор зависит от того, с какими системами работает агент и насколько дороги его ошибки. На практике комбинируют несколько подходов.

Снимок состояния (snapshot)

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

Журнал компенсирующих действий

На каждое действие агент записывает обратное: создал запись — знает, как её удалить; изменил поле — сохранил прежнее значение. Это паттерн Saga из распределённых систем. При откате журнал проигрывается в обратном порядке. Гибко, но компенсацию для каждого типа действия надо написать заранее, и для необратимых действий её попросту не существует.

Черновой режим (dry-run) и стадия подтверждения

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

Песочница с последующим применением

Агент работает в изолированной копии окружения, а результат применяется к боевой системе одним контролируемым шагом. Если в песочнице что-то сломалось, боевая система не пострадала. Хорошо для файловых операций и генерации кода, плохо — когда задача по определению требует живых внешних вызовов.

Как выглядит откат по шагам

Порядок для агента, у которого уже есть журнал действий:

1. Остановить агента, чтобы он не наделал новых изменений поверх уже сломанных.
2. Определить точку сбоя: на каком шаге план разошёлся с реальностью.
3. Разметить выполненные действия на обратимые, частично обратимые и необратимые.
4. Проиграть компенсации для обратимых — в порядке, обратном выполнению.
5. Для частично обратимых решить вручную: откатывать за деньги или оставить.
6. По необратимым запустить компенсацию (возврат, уведомление) и зафиксировать инцидент.
7. Сохранить журнал целиком: это материал для разбора и для правки промптов и ограничений.

Кому это пригодится и кому нет

Полноценный механизм отката оправдан не всегда. Он стоит времени на разработку, и для игрушечного проекта это перебор.

Он нужен, если:

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

Он избыточен, если:

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

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

Агент — программа на базе языковой модели, которая не просто отвечает текстом, а сама планирует и выполняет действия: вызывает инструменты, обращается к API, читает и меняет данные, чтобы достичь поставленной цели. Именно способность действовать, а не советовать, делает вопрос отката для агентов принципиальным.