Компенсация — это контракт рантайма, а не промпт при ошибке

Автономный workflow одобрил возврат средств, отправил сообщение клиенту, зарезервировал товар и разместил заказ на закупку. Затем не прошла проверка в нижестоящей системе. Агент уже не может сделать вид, будто workflow не запускался. Письмо доставлено. Резерв мог увидеть другой сервис. Поставщик, возможно, уже исполняет заказ.

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

Полезное различие — не между успехом и ошибкой

Практика распределённых систем занимается этой ситуацией десятилетиями. Исходная модель Saga разбивает долгую транзакцию на более короткие. Если вся последовательность не может завершиться, компенсирующие транзакции корректируют последствия уже выполненных шагов. Более поздние спецификации business activity формулируют это прямо: длительная работа способна дать промежуточные результаты, видимые за пределами компьютерной системы, поэтому одного abort часто недостаточно. Чтобы обработать уже завершённую работу, может потребоваться бизнес-логика.

Этот контекст важен: агентные системы не создали новый класс отказов. Они увеличили число workflow, которые могут совершать значимые действия без человека, ведущего каждый шаг. Технический ответ не должен сводиться к просьбе к LLM после инцидента придумать извинение, отмену или возврат. У таких действий есть собственные последствия и границы полномочий. Их семантика должна быть спроектирована и одобрена заранее.

До допуска инструмента в управляемый workflow рантайм должен классифицировать его операцию по классу воздействия:

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

Это не просто метки в каталоге. Они определяют, какие ветви workflow рантайм вправе выполнять после неоднозначности, тайм-аута или частичного сбоя. Ключ идемпотентности может безопасно регулировать повтор запроса; API Stripe — знакомый пример. Но он лишь предотвращает повторное выполнение этого запроса. Он не отменяет платёж, не отзываёт отправленное сообщение и не возвращает успешно отправленный товар. Идемпотентность — свойство повтора. Компенсация — новое бизнес-действие.

Компенсируемому действию нужен полный контракт

Недостаточно назвать операцию компенсируемой, если рантайм не знает, что именно означает компенсация и при каких условиях она допустима. Контракт должен поставляться вместе с инструментом, создающим внешний эффект, а не существовать как неформальное знание в runbook.

• Класс воздействия и область идемпотентности, включая идентификатор для распознавания повтора запроса.
• Надёжно сохранённая квитанция операции: внешняя ссылка, принятый payload, время, статус и доказательства того, что произошло.
• Команда компенсации либо явное объявление необратимости операции.
• Доказательства, требуемые до запуска компенсации: например, подтверждение поставщика, статус доставки или запись клиента.
• Полномочие, необходимое для компенсации, и ограничивающие её условия политики.
• Срок компенсации или условие истечения, поскольку права на отмену, возврат и изменение часто зависят от времени.
• Маршрут эскалации и набор допустимых конечных бизнес-результатов.

Это архитектурное предложение AES, выведенное из устоявшихся паттернов saga и business activity. Оно превращает восстановление из импровизации, специфичной для приложения, в проверяемое требование допуска. Инструмент, который не может объявить класс воздействия, квитанцию и семантику восстановления, может быть полезен для анализа. Но он не готов к автономному внешнему действию.

Рантайм должен координировать результат, а не API-вызовы

Тайм-аут на границе API не сообщает организации, произошёл ли внешний эффект. Слепой повтор может его продублировать; слепая компенсация — создать второе вредное действие. Рекомендации OASIS для business activity однозначны: транспортные повторы и тайм-ауты не способны установить сквозное согласие для длительной работы. Управляемому рантайму нужна надёжная координация уровнем выше отдельных вызовов.

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

Когда workflow отклоняется от намеченного пути, рантайм должен выбрать один из четырёх широких ответов. Первый — повторить временно неудачную операцию, если она идемпотентна и доказательства указывают, что она не завершилась. Второй — применить альтернативный прямой путь, если иное разрешённое действие всё ещё приводит к бизнес-цели. Третий — выполнить объявленную компенсацию, когда нужно обработать уже наступившие последствия. Четвёртый — передать случай на рассмотрение человеку, если статус неоднозначен, полномочий недостаточно или последствия значительны.

Этот порядок намеренно не всегда направлен назад. Повторная отправка товара может быть предпочтительнее отмены заказа. Частичный возврат может быть корректнее попытки восстановить прежнее финансовое состояние. Исправляющее сообщение о раскрытии информации может быть необходимо, хотя исходное письмо нельзя отозвать. Компенсация не восстанавливает точное прежнее состояние. Она ведёт организацию к разрешённому результату в реальных условиях, которые уже сложились.

Отодвигайте точки невозврата

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

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

Восстановление — это организационное поведение

С ростом числа участников saga-системы всё сильнее зависят от идемпотентности, изоляции и наблюдаемости. То же верно для организации из агентов, сервисов и людей-операторов. Каждый участник должен переносить повторное выполнение после сбоя. Каждый значимый переход должен быть прослеживаем. А назначенные для эскалации люди должны получить конкретный кейс: что произошло, какие доказательства есть, какие компенсации ещё допустимы, чьи полномочия нужны и какие результаты разрешены политикой.

Практика BPMN-компенсации подтверждает этот принцип: завершённым активностям назначаются отдельные обработчики компенсации, а процесс может нацелить компенсацию на конкретную завершённую активность, когда важен порядок. Важна не сама BPMN. Важна идея: компенсация — это смоделированная способность, а не неструктурированная ветка исключения.

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

Проектируйте для мира, который уже изменился

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

Сделайте ответ исполнимым до действия агента. Классифицируйте эффект. Сохраните квитанцию. Объявите компенсацию или необратимость. Свяжите с контрактом доказательства, полномочия, сроки и эскалацию. Затем позвольте рантайму координировать восстановление так же тщательно, как он координирует прямую работу. В этом разница между агентом, умеющим вызывать инструменты, и автономной организацией, способной восстанавливаться ответственно.

Источники

• Hector Garcia-Molina и Kenneth Salem, «Sagas» — https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf
• OASIS, WS-BusinessActivity 1.1 — https://docs.oasis-open.org/ws-tx/wstx-wsba-1.1-spec-os/wstx-wsba-1.1-spec-os.html
• Microsoft, паттерн Compensating Transaction — https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction
• AWS, паттерн Saga orchestration — https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga-orchestration.html
• Stripe, идемпотентные запросы — https://docs.stripe.com/api/idempotent_requests
• Camunda, события BPMN compensation — https://docs.camunda.io/docs/components/modeler/bpmn/compensation-events/