Трасса — не журнал воспроизведения: что должен сохранять управляемый runtime агентов

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

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

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

Трасса описывает поведение, журнал продвигает состояние

Трассы и спаны OpenTelemetry представляют операции. Семантические соглашения задают общие имена и атрибуты, благодаря которым телеметрию можно сопоставлять между системами. В соглашениях для генеративного ИИ есть спаны вызова агента и исполнения инструмента. Это важная основа для наблюдения за задержками, ошибками, зависимостями и маршрутом запуска через распределённую систему.

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

Различие здесь структурное. История workflow используется системами надёжного исполнения, чтобы продвигать или заново создавать состояние workflow после сбоя. Трасса оптимизирована для описания операций. Журнал исполнения, напротив, должен быть достаточно авторитетным, чтобы определить следующий переход. В нём нужна упорядоченная долговечная запись существенных изменений состояния: идентификаторов шагов; устойчивых входов и результатов; версий workflow и политик; согласований; квитанций вызовов инструментов; итогов фиксации; повторов; таймеров; и состояния компенсации.

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

Фиксируйте недетерминизм на границе

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

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

Граница не в том, чтобы «хранить всё». Она в том, чтобы хранить необходимое для управления и восстановления значимых решений. Сохранение каждого токена промпта, скрытой цепочки рассуждений или мимолётного наблюдения создаёт риски для приватности и безопасности, увеличивает стоимость и усложняет эволюцию схемы, часто почти не помогая восстановлению. В актуальных определениях OpenTelemetry для GenAI сообщения промпта и ответа, определения инструментов, аргументы вызовов и результаты инструментов являются opt-in полями; сами соглашения всё ещё развиваются. Их нельзя считать стабильной спецификацией записи для воспроизведения.

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

Внешним эффектам нужны квитанции, а не оптимизм

Самые сложные переходы пересекают границу runtime. Письмо может быть уже доставлено в момент тайм-аута. Раскрытую информацию может быть невозможно отозвать. Физическая операция может требовать процедуры безопасности, а не отката. Ни один журнал не обеспечит ровно одно выполнение всех распределённых эффектов.

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

Именно здесь автономные организации становятся либо надёжными, либо дорогостоящими для расследования. Оператор восстановления должен видеть, что шаг 18 ждёт согласования, шаг 19 создал счёт по конкретной версии политики, а у шага 20 неоднозначная квитанция доставки, требующая сверки. Состояние «по трассе всё выглядит успешно» для эксплуатации недостаточно.

Происхождение отвечает на другой вопрос

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

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

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

Архитектурное правило таково: связывайте все три записи общими идентификаторами запуска, шага, участника, артефакта и эффекта, но сохраняйте различие их назначений. Телеметрии подходят ориентированные на производительность сроки хранения и выборка. Журналу исполнения нужны долговечность, ориентированная на корректность, и строгий контроль доступа. Графу происхождения нужны отношения, ориентированные на родословную, и сроки хранения, соответствующие объясняемым артефактам. Требования к приватности у этих записей также будут разными.

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

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

Автономность становится управляемой, когда runtime отличает историю запуска от его состояния. Трассы рассказывают историю запуска. Журналы сохраняют состояние, нужное для безопасного продолжения. Происхождение объясняет, откуда взялись результаты. Организации, которым агенты нужны за пределами одного запроса, должны строить все три уровня — и не требовать от одного из них работы двух других.

Источники

• Семантические соглашения OpenTelemetry и соглашения GenAI
• Microsoft, паттерн Event Sourcing
• AWS, рекомендации по детерминизму для durable execution
• Документация Temporal об истории workflow и восстановлении
• AWS, руководство по паттернам Saga
• W3C PROV-O