План отката для ИИ-агентов: как отменить ошибочные действия до того, как пользователи потеряют доверие
Надежному ИИ-агенту не обязательно быть идеальным. Ему нужно уметь вовремя остановиться, объяснить свою ошибку и восстановиться.
Если ваш агент обновит не то поле в CRM или отправит дубликат платежа, простая повторная попытка не исправит ситуацию. Вам нужен план отката еще до того, как произойдет реальный инцидент.
Поскольку агенты переходят от простого чата к реальной работе, они начинают изменять состояние (mutate state). Это превращает механизм отката из чисто бэкенд-задачи в полноценную продуктовую функцию.
Типичные сценарии сбоев:
- Агент использует неверный ID записи.
- Повторная попытка приводит к дублированию действия.
- Смена модели меняет логику работы инструмента.
- Рабочий процесс возобновляется со старыми данными в памяти.
- Частичное выполнение последовательности оставляет данные в несогласованном состоянии.
Как построить уровень восстановления:
Используйте журнал действий (Action Ledger) Не полагайтесь только на логи. Создайте реестр, который фиксирует каждое изменение состояния. Каждый вызов инструмента должен создавать запись до и после выполнения. Это ваш «источник истины» (source of truth) для восстановления.
Классифицируйте действия Не все действия одинаковы.
- Только для чтения: откат не требуется.
- Внутренние обновления: восстановите предыдущее значение из снимка (snapshot).
- Внешние обратимые: удалите событие или обновите статус.
- Внешние необратимые: используйте компенсацию вместо полноценного отката. Письма или платежи нельзя «раз-отправить». Вам придется отправить исправление или произвести возврат.
Обеспечьте идемпотентность Модель не гарантирует идемпотентность. Это должна обеспечивать среда выполнения ваших инструментов (tool runtime). Используйте ключи идемпотентности, чтобы при повторной попытке выполнения задачи агентом не возникало дублирующих побочных эффектов.
Используйте паттерн Saga Для длительных рабочих процессов каждое прямое действие должно иметь компенсирующее действие.
- Создали задачу? Компенсация — её удаление или отмена.
- Обновили поле? Компенсация — восстановление старого значения.
- Отправили письмо? Компенсация — отправка исправления.
Внедрите контрольные точки (checkpoints) Перестаньте просить модель «сообразить, на чем мы остановились» после сбоя. Используйте контрольные точки для хранения текущего состояния, выполненных действий и ожидающих задач. Система должна загружать контрольную точку для возобновления работы.
Создайте очередь восстановления Если шаг проверки не пройден, переместите задачу в очередь восстановления. Это позволит вам возобновить, компенсировать или закрыть задачу. При высокорисковых ошибках всегда запрашивайте подтверждение у человека.
Доверие строится на прозрачном восстановлении. Если агент совершает ошибку, не используйте расплывчатые формулировки. Четко скажите пользователю, что именно изменилось, почему это произошло и как вы это исправили.
Разработайте план отката до того, как произойдет первый инцидент.
Optional learning community: https://t.me/GyaanSetuAi