Idempotency, retry и rollback: как агенту безопасно менять реальные системы

Короткий ответ

Idempotency, retry и rollback: как агенту безопасно менять реальные системы — это production-задача, а не демонстрационный prompt. Практический принцип: каждое изменяющее действие проектировать с idempotency key, precondition, журналом эффекта и проверенным откатом. Ключевое решение: retry без idempotency может дважды создать заказ, отправить письмо или изменить запись. В инженерной среде результат принимается по evidence, traceability и воспроизводимой проверке, а не по уверенности формулировки модели.

Граница системы и предмет контроля

Автономность — это свойство workflow, а не модели. Один и тот же LLM может работать как read-only помощник, как исполнитель после подтверждения или как агент, запускающий ограниченный цикл без участия человека. Уровень автономности задаётся допустимыми действиями, лимитами, средой выполнения, критериями остановки и тем, в каких точках требуется инженерное approval.

В production опаснее всего не отдельная ошибочная фраза, а неверное действие с побочным эффектом: перезапись файла, изменение записи PDM/ERP, массовая отправка, запуск неподходящего расчёта, неконтролируемая команда shell. Поэтому автономный контур обязан быть транзакционным там, где возможно, идемпотентным при повторных вызовах, наблюдаемым и способным остановиться при неизвестном состоянии.

Что должно быть определено до запуска

Артефакты и архитектурные границы

Контур автономности проектируют как конечный автомат с явными состояниями: queued, running, requires_approval, blocked, failed, completed и rolled_back. Переходы разрешает policy, а не свободный текст модели. Это особенно важно для длинных задач, где процесс переживает restart и должен продолжаться с checkpoint, не повторяя уже выполненный side effect.

Изменяющий tool должен иметь bounded scope: конкретный проект, объект, диапазон данных, число операций и срок действия полномочий. Дополнительно задаются budget по шагам/стоимости, network policy и stop conditions. При расхождении ожидаемого и фактического состояния выполнение прекращается до ручной классификации исключения.

Практический workflow

После каждого side effect состояние перечитывается и сравнивается с ожидаемым. Повторный запуск использует idempotency/checkpoint, поэтому не создаёт второй объект и не повторяет уже принятую операцию.

Инженерный сценарий

Автономность повышают ступенчато: read-only → draft → approval-gated write → bounded autonomous write. Каждый следующий уровень требует отдельного evidence о качестве и восстановлении после сбоя.

Что измерять

Чем выше автономность, тем важнее метрики side effects: rollback, duplicate action, policy violation, human rescue и незавершённые долгие задачи. Их нельзя прятать внутри общего task success.

Критерии приёмки

Failure modes и защитные меры

• повторная запись после timeout. Защитная мера: compare-and-set revision; событие сохраняется как regression/incident case.
• rollback не восстанавливает связанный объект. Защитная мера: idempotency storage; событие сохраняется как regression/incident case.
• частичный batch считается успешным. Защитная мера: retry только известных transient ошибок; событие сохраняется как regression/incident case.
• агент не знает итог предыдущего вызова. Защитная мера: backup перед batch change; событие сохраняется как regression/incident case.
• precondition изменилась между планом и записью. Защитная мера: postcondition verification; событие сохраняется как regression/incident case.

Как переводить из пилота в production

Пилот автономного workflow обязан иметь kill switch, лимит шагов, лимит стоимости, timeout, checkpoint и запрет на произвольное расширение scope. Сначала проверяется recovery path, затем happy path; иначе система умеет выполнять задачу, но не умеет безопасно останавливаться.

Расширение автономности оформляется как изменение класса допуска. Для нового уровня повторно проходят evals, security review и тест rollback. Массовые операции получают batch limit и canary batch, а не запускаются сразу на всём наборе объектов.

Traceability и эксплуатационная запись

Для автономного цикла сохраняют checkpoint ID, budget, step number, side-effect receipt, idempotency key, approvals, retries, rollback actions и reason code остановки. Без этого невозможно доказать, что повторный запуск безопасен.

Чек-лист перед production

Навигация по Wave AI R5 · часть 3 из 5