Автономным организациям нужен детерминированный контур управления

Автономной организации не нужно пытаться сделать своих агентов детерминированными. Детерминированной должна быть система управления вокруг них.

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

Инференс генеративной модели — ненадёжная основа для повторно исполняемого управляющего потока. Google указывает, что фиксированный seed лишь помогает воспроизводимости в режиме best effort: идентичный результат не гарантирован, а изменения модели или параметров могут изменить ответ. Это не дефект, который нужно устранить. Вероятностное суждение часто и составляет ценность агента. Архитектурная ошибка — позволить этому суждению незаметно возникать вновь внутри механизма, который обязан восстанавливать исполнение организации.

Контур — это управление потоком, а не интеллект

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

Агент входит в эту архитектуру, но не является её центром. Инференс модели, поиск и другие операции, чьи результаты могут меняться, должны находиться за явными границами activity. Оркестратор вызывает activity, получает результат, фиксирует его в истории workflow и затем использует именно зафиксированный результат для следующих шагов.

Этот паттерн следует базовым ограничениям устойчивого исполнения. Microsoft документирует, что durable-оркестраторы используют event sourcing и replay, поэтому при каждом воспроизведении должны выдавать один и тот же результат. Компания отдельно предупреждает, что прямые вызовы API времени, случайных чисел и UUID могут нарушить это требование. Показательна её рекомендация для случайных чисел: вынести генерацию в activity, поскольку возвращаемое activity значение сохраняется в истории оркестрации и безопасно при replay.

AWS формулирует тот же принцип в рекомендациях по durable execution. Результат устойчивого шага чекпоинтится и извлекается при последующем replay. Стабильным должен быть и идентификатор шага: timestamp или случайный идентификатор в имени создаёт другую сущность шага и ломает воспроизведение. Для агентных систем вывод прямой: вызов модели — не управляющая логика, которую следует запускать заново при replay. Это durable activity, чей принятый результат должен быть извлечён.

“Организация не обязана воспроизводить ход рассуждений модели. Она обязана воспроизводить свои действия после принятия её результата.

Принятие превращает ответ в артефакт решения

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

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

Представим процесс рассмотрения страхового случая. Агент изучает представленные материалы и рекомендует обычную обработку либо передачу профильному специалисту. Устойчивый контур фиксирует рекомендацию, проверяет, допускают ли маршрут кейса и бюджет предложенный путь, назначает следующего исполнителя и запускает соответствующий срок. Если процесс падает после назначения, при восстановлении нужно использовать принятую рекомендацию. Новый вызов модели может дать иной маршрут даже при фиксированном seed. Это не восстановление, а новое решение.

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

Что должно быть по разные стороны границы

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

• Держите правила маршрутизации, проверки полномочий, расписания повторных попыток, пути эскалации, сроки, лимиты бюджета и условия фиксации в durable-оркестрации.
• Выносите инференс модели, поиск, внешние запросы и другие недетерминированные операции в явные activities со стабильными идентификаторами.
• Сохраняйте принятый результат activity и контекст, необходимый для его интерпретации: экземпляр workflow, запрос, контекст действующей политики и событие принятия.
• При восстановлении извлекайте сохранённый артефакт. Не вызывайте модель заново только потому, что код оркестратора воспроизводится.
• Оформляйте пересмотр моделью как новый управляемый переход — при необходимости со своей причиной, оценкой, авторизацией и сохранённым результатом.

Третий пункт — не просто соглашение о логировании. Трасса может описывать то, что, по-видимому, произошло; durable-граница ограничивает то, что может произойти при восстановлении. Если оркестратор при replay напрямую вызывает модель, внешне безобидный рестарт способен изменить маршрут, порог обязательства или путь эскалации. Сохранение принятого результата вне воспроизводимой логики предотвращает такую подмену.

Восстанавливаемость — свойство организации

Azure Durable Functions разделяет функции оркестратора, activity и entity, а runtime управляет состоянием, чекпоинтами, повторными попытками и восстановлением длительных workflows. Эти возможности полезны не только для технических задач. Они выражают требование, актуальное и для автономных организаций: работа должна оставаться понятной и управляемой, когда ни один процесс не существует непрерывно.

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

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

Не путайте replay с пересмотром

Практическое правило простое. Replay реконструирует предыдущее исполнение по сохранённой истории. Пересмотр создаёт новую историю. Им нужны разные контроли.

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

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

Источники

• Microsoft, «Durable Task Framework code constraints»: https://learn.microsoft.com/en-us/azure/durable-task/common/durable-task-code-constraints
• Microsoft, «Durable Functions overview»: https://learn.microsoft.com/en-us/azure/durable-task/durable-functions/durable-functions-overview
• AWS, «Durable execution step design best practices»: https://docs.aws.amazon.com/durable-execution/patterns/best-practices/step-design/
• Google Cloud, «Content generation parameters»: https://cloud.google.com/vertex-ai/generative-ai/docs/multimodal/content-generation-parameters