Рантайм долгоживущих ИИ-агентов: сессии и чекпоинты

Viacheslav Dubrov

2026-05-26 · Обновлено 2026-09-06 · 38 мин · ИИ-агенты

Автоматический перевод Эта статья была автоматически переведена с оригинальной английской версии.

Обновление статьи

Изначально опубликовано 26 мая 2026 года. Проверено и обновлено 6 сентября 2026 года. Обновление охватывает новые возможности рантайма и варианты деплоя, а также исправленные сравнения платформ, механизмы контроля бюджета и ссылки на источники.

Запуск агента может длиться часами, но его воркер-процесс может перезапуститься в любой момент. Рантайм хранит состояние запуска, выполняет его tool calls и восстанавливает работу, если tool call прерывается на полпути. Следующее действие по-прежнему выбирает модель. В части 6 рассматривается харнесс: код, который передаёт контекст, проверяет tool calls и определяет, завершена ли работа.

Что такое рантайм ИИ-агента?

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

Четыре из пяти примитивов хранят состояние или ограничивают возможности кода: сессия, сэндбокс, чекпоинт и трейс. Харнесс принимает решения о памяти, контрактах инструментов и разрешениях. В этой статье описаны сервисы и хранилища, которые ему нужны. В части 6 рассматриваются его проверки, ретраи и acceptance-тесты.

Долгие запуски нарушают предположения о stateless-процессах

Stateless chat endpoint может хранить состояние запроса в одном процессе и удалить его после ответа. Долгий запуск агента проходит через перезапуски воркеров, деплои, сбросы контекста и паузы на согласование. Воркер-процесс больше не может быть источником истины.

Команда OpenAI Codex рассказывает, насколько долгими бывают такие запуски, в своей статье о harness engineering:

“Мы регулярно видим, как отдельные запуски Codex работают над одной задачей более шести часов (часто пока люди спят).”

Инженерная команда Anthropic описывает соответствующую проблему состояния в статье Effective harnesses for long-running agents:

“Главная сложность долгоживущих агентов в том, что они должны работать в дискретных сессиях, а каждая новая сессия начинается без памяти о том, что было раньше.”

Оба наблюдения приводят к одному дизайну рантайма: сохраняйте состояние за пределами воркера и делайте воркеры заменяемыми.

Сессия должна находиться за пределами воркер-процесса. Durable store записывает вызовы модели, намерения и результаты tool calls, а также согласования, чтобы другой воркер мог продолжить работу с последней безопасной точки после сбоя. Перед тем как считать такое возобновление безопасным, нужно согласовать незавершённый внешний эффект. Чекпоинты также позволяют рантайму начать новую сессию модели при заполнении контекстного окна, не проигрывая всю историю заново. В формулировке Anthropic экземпляры харнесса становятся одноразовыми и перезапускаемыми, а durable state хранится в другом месте.

Пять примитивов, которые нужно разместить до запуска

Статья Anthropic Scaling Managed Agents предлагает полезную терминологию для пяти обязанностей рантайма. Харнесс двигает агента вперёд, сессия записывает его действия, а сэндбокс выполняет команды. Чекпоинт даёт следующему воркеру точку возобновления, а трейс сохраняет свидетельства для последующей отладки. Компоненты можно объединять, но у обязанностей и границ отказа всё равно должны быть названия.

Сессия. Отдельно записываемый append-only event log вызовов модели, запрошенных и выполненных tool calls, ошибок и согласований. База чекпоинтов помогает с восстановлением, но история состояния графа не заменяет этот лог.

Термин перегружен, поэтому в этой статье используется схема именования для трёх интервалов. Thread — это пользовательский разговор, продолжающийся несколько дней. Это самый долгоживущий интервал, который может содержать множество запусков.

Сессия модели — самый короткий интервал: один непрерывный отрезок модельного контекста. Компактизация — шаг, на котором окно суммируется, чтобы работа могла продолжиться, — продлевает сессию модели, а не завершает её. Перезапуск или намеренный новый старт завершают её. В части 6 используется именно такое значение термина «сессия модели».

В этой статье «сессия» означает durable log одного запуска. В один лог могут писать несколько сессий модели, а один conversation thread может содержать несколько логов запусков. Для восстановления разбудите запуск, загрузите его сессию, согласуйте незавершённый побочный эффект, затем продолжите после последнего события: wake(sessionId) → getSession(id) → reconcile pending effects → resume from last event.

В LangGraph thread_id — это ключ хранения и извлечения данных checkpointer для истории состояния графа thread (см. LangGraph persistence); он не определяет границы разговора, сессии модели или event log из этой статьи. Выделите для event log собственный durable run или session ID, а затем явно задайте соответствие этих ID потокам LangGraph. OpenAI Agents SDK поставляется с десятью встроенными session backend, включая SQLiteSession, RedisSession, SQLAlchemySession, MongoDBSession и EncryptedSession (см. документацию Sessions). Они хранят изменяемую историю разговора, включая удаление, очистку и компактизацию; при необходимости сопоставьте ID сессии SDK с ID событий запуска, но не считайте историю SDK append-only логом восстановления или аудита без эквивалентной гарантии неизменяемости.

Харнесс. Цикл оркестрации и единственный примитив здесь, который принимает решения. Он собирает промпт из памяти, вызывает модель, проверяет предложенный tool call по правилам разрешений, отправляет разрешённые вызовы, записывает результаты обратно в сессию, применяет правила ретраев и решает, завершена ли задача. Средства планирования и управления контекстом кодируют предположения о возможностях модели. Обязательная авторизация и изоляция также реализуют требования, которые сохраняются по мере улучшения моделей. Anthropic прямо подчёркивает эту мысль — цитата приведена ниже, в разделе о режимах отказа, который в основном посвящён последствиям устаревших предположений.

Команда OpenAI Codex называет это harness engineering: разработка ПО по-прежнему требует инженерных усилий, но теперь большая их часть уходит на scaffolding, а не на сам код. CompiledStateGraph LangGraph, Deep Agents от LangChain и его entry point create_deep_agent, а также сам Claude Code — всё это харнессы в данном смысле.

Сэндбокс. Изолированная среда выполнения, где фактически запускаются команды. Страница OpenAI Agents SDK о sandbox concepts относит согласования, трейсинг, handoff и состояние, необходимое для возобновления запусков, к внешнему рантайму. Команды, изменения файлов и изоляция окружения относятся к сессии сэндбокса.

Под «внешним рантаймом» там понимаются харнесс и его state stores. В терминологии этой серии согласования и handoff — решения харнесса (часть 4 и часть 6); трейсинг и учёт возобновления — примитивы сессии и чекпоинта.

Сэндбоксы различаются временем жизни и тем, что они помнят между запусками. Самый простой вариант — fresh ephemeral: создать сэндбокс для одной задачи, уничтожить после её завершения и оплачивать cold start при каждом запуске.

Persistent paused сэндбоксы сохраняют файловую систему и снапшот памяти между запусками. Следующее возобновление может избежать полной загрузки. Snapshot or fork создаёт copy-on-write-образ из подготовленного родителя, поэтому множество задач используют общие установленные зависимости и прогретые кэши, не разделяя изменяемое состояние.

Worktree-per-task предоставляет задачам отдельные checkout; Git worktrees используют общую инфраструктуру репозитория и не являются OS-сэндбоксами. Ограничивайте выполнение отдельно — контейнером, VM или политикой процессов. У каждого приложения на задачу также может быть собственный стек observability. Раздельные логи, метрики и трейсы позволяют отлаживать один запуск, не допуская утечки его состояния в другой. Таблица провайдеров ниже сравнивает контракты изоляции и персистентности.

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

PostgresSaver LangGraph записывает Checkpoint на каждой границе super-step. Super-step — это один раунд графа: один узел или параллельно выполненная группа узлов. Результаты отдельных задач записываются в checkpoint_writes, поэтому успешные результаты узлов не вычисляются заново при сбое соседнего узла.

Чекпоинт — обычный dict (v, id, ts, channel_values, channel_versions, versions_seen, updated_channels). LangGraph сериализует его через основанный на msgpack JsonPlusSerializer, а не JSON. datetime, set, Decimal и dataclasses корректно проходят round-trip. Формат описан на странице PyPI langgraph-checkpoint-postgres и в справочнике LangGraph checkpoints.

StateSnapshot — это отдельное, более подробное представление, которое graph.get_state() строит поверх чекпоинта. Debug bundle может экспортировать его .values как последнее известное состояние графа, но не восстановит детали событий, которые харнесс не записал.

Трейс. Поверхность для отладки и аудита. Каждый вызов модели, tool call и шаг субагента должны выдавать timing, status, модель и провайдера, correlation ID, число токенов и стоимость. Промпты, completion, аргументы инструментов и результаты инструментов — контент, включаемый по желанию: рекомендации GenAI OpenTelemetry по умолчанию ограничиваются метаданными, поскольку эти поля могут содержать чувствительные данные. Сначала определите правила редактирования или фильтрации, контроля доступа и хранения, и только затем собирайте их. Когда шестичасовой запуск завершается с ошибкой, именно трейс позволяет понять, что произошло. Он может поддержать расследование, но безопасное возобновление или replay обеспечивают event log и состояние чекпоинта вместе с обработкой идемпотентности. К этому моменту вывод терминала уже давно исчез. Семантические соглашения GenAI OpenTelemetry стандартизируют имена атрибутов: какая модель, какой провайдер, сколько токенов, какой разговор и какой workflow. Для совместимого с OTLP назначения, поддерживающего эти соглашения, одна и та же инструментализация может экспортировать трейс в системы вроде Tempo, Jaeger, Honeycomb или LangSmith, хотя адаптеры бэкенда или конфигурация под конкретное назначение всё ещё могут потребоваться.

Политики и секреты проходят через все примитивы

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

Исполнение разрешений

Лестнице разрешений из части 4 нужно место для выполнения. Проверка запускается перед каждым tool call и решает, пропускать ли его. В продакшене распространены два паттерна. Filesystem-permission middleware Deep Agents может ограничить встроенные filesystem tools заявленными путями. Она не управляет shell-командами сэндбокса, кастомными инструментами или вызовами MCP; их нужно ограничивать политикой сэндбокса или собственным tool proxy. Managed Agents Anthropic направляет кастомные MCP tool calls через прокси, который хранит учётные данные. Выполнение команд в сэндбоксе и Git-аутентификация используют разные пути; MCP-прокси не является универсальным интерсептором для каждого действия. Когда чувствительный вызов требует согласования человека, interrupt() LangGraph и approval hook Deep Agents ставят граф на паузу до ответа человека.

Брокер секретов

Модель не должна видеть долгоживущие секреты, и сэндбокс обычно тоже не должен их видеть. Паттерн Managed Agents стоит скопировать:

“Для Git мы используем access token каждого репозитория, чтобы клонировать репозиторий при инициализации сэндбокса, и подключаем его к локальному git remote. Git push и pull работают внутри сэндбокса, а агент никогда не обрабатывает сам токен. Для кастомных инструментов мы поддерживаем MCP и храним OAuth-токены в защищённом vault. Claude вызывает MCP-инструменты через выделенный прокси; этот прокси получает токен, связанный с сессией. … Харнесс никогда не получает доступ к credentials.”

В эталонном стеке market-analyst-agent — небольшом LangGraph-агенте, который получает рыночные данные и пишет отчёт аналитика, созданном в рамках этой серии, — воркер локально вызывает инструменты рыночных данных. Опциональный MCP-сервер экспортирует поверхность инструментов; он не является реализованным credential broker между воркером и провайдерами. Оба контейнера могут читать общий development .env. Для production-брокера потребуется перенести credentials провайдеров в хранилище, недоступное воркеру, и направить каждый относящийся к ним вызов через брокер.

Проверьте размещение

Практическая проверка — записать каждый компонент и указать, какой из пяти примитивов он реализует. Postgres может одновременно отвечать за сессию и чекпоинт. Контейнер воркера — это харнесс. Сервис вроде Daytona, Modal или E2B предоставляет сэндбокс, а Tempo или LangSmith хранит трейс.

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

Режимы отказа production-рантайма ИИ-агента

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

Сбои делятся на четыре группы:

• Сбои качества результата: агент объявляет победу до фактического завершения работы, забывает сделанное после сброса контекстного окна или доверяет собственной самооценке и отправляет сломанный результат.
• Сбои контроля стоимости: агент застревает в цикле ретраев или расходует бюджет токенов либо tool calls, не создав ничего полезного.
• Сбои состояния и падения: рабочие пространства расходятся, потому что один запуск изменяет файлы, принадлежащие другому; tool calls выполняются больше одного раза из-за повторного проигрывания при ретраях; работа теряется, если воркер завершается между событиями.
• Сбои контекстного окна: модель суммирует контекст и завершает работу раньше времени, решив, что место заканчивается, хотя в окне ещё достаточно запаса.

В таблице каждому сбою сопоставлены mitigation, основание рекомендации и runtime hook, который её обеспечивает. Поведение конкретной модели может меняться, поэтому воспринимайте наблюдения вендоров как повод заново проверить предположение, а не как постоянные правила.

За большинством строк стоят две идеи. Anthropic о неактуальности харнесса в Harness design for long-running application development:

“Каждый компонент харнесса кодирует предположение о том, что модель не может сделать самостоятельно. Эти предположения стоит подвергать стресс-тестированию — потому что они могут быть неверными и потому что по мере улучшения моделей быстро устаревают.”

Vercel о смежной проблеме — слишком большом числе инструментов, кодирующих слишком много предположений, — в статье We removed 80% of our agent’s tools:

“Мы удалили большую часть системы и свели агента к одному инструменту: выполнению произвольных bash-команд. Мы называем это file system agent.”

Цитата описывает bash-ядро; в выпущенном Vercel агенте осталось два инструмента, ExecuteCommand и ExecuteSQL, вместо старого примера кода, где было семнадцать инструментов. Часть 3 содержит полное сравнение до и после. По пяти репрезентативным запросам заявленный результат такой: успех вырос с 4/5 до 5/5, а худший случай сократился с 724 с / 100 шагов / 145 463 токенов (ошибка) до 141 с / 19 шагов / 67 483 токенов (успех). Именно строка с худшим случаем выглядит наиболее впечатляюще; в среднем по пяти запросам экономия токенов составила 37%. Вывод не в том, что нужно «удалить инструменты». По мере изменения поведения модели вспомогательные инструменты могут стать избыточными. При смене модели заново проверяйте это предположение.

Cognition увидела такое же движущееся ограничение на длину сессии в Sonnet 4.5. В статье Rebuilding Devin for Claude Sonnet 4.5 они описывают модель, которая при ощущении исчерпания контекста заранее записывает SUMMARY.md / CHANGELOG.md, но недооценивает, сколько токенов ещё осталось. Их исправление — включить контекст на 1M токенов и ограничить использование до 200k, чтобы модель по-прежнему считала, что у неё есть запас. На момент публикации это было beta-флагом.

В документации Anthropic по context window, проверенной 6 сентября 2026 года, указано, что Sonnet 5 и Opus 5 по умолчанию поддерживают 1M токенов, а Sonnet 4.5 остаётся на уровне 200k. Текущие модели Sonnet автоматически получают обновления об оставшемся контексте, а server-side compaction доступна в beta для Claude 4.6 и более новых моделей. Перед копированием исторического лимита Cognition проверьте выбранную модель с поддерживаемыми ею настройками контекста. Большое окно или счётчик бюджета не гарантируют надёжное запоминание, и ни один из них не заменяет durable progress за пределами модели.

У команды OpenAI по харнессу есть формулировка в одну строку: «Люди направляют. Агенты выполняют». При сбое полезно спросить, какой capability отсутствует и как сделать его одновременно понятным и принудительно выполняемым для агента.

Здоровый жизненный цикл запуска

Хороший запуск скучен. Это цепочка небольших восстанавливаемых шагов, и каждый завершённый шаг записывает durable state до начала следующего.

Запись каждого результата до старта следующего шага ограничивает ущерб от сбоя. Исключение — внешний эффект in-flight: воркер может завершиться после commit провайдера, но до того, как харнесс запишет результат. Следующий воркер должен согласовать этот незавершённый эффект, прежде чем продолжить с последнего завершённого шага.

1. Запустите работу с новой или возобновлённой сессии. При возобновлении подключите рабочее пространство в последнем известном состоянии, прочитайте progress-файлы, оставленные предыдущей попыткой (PROGRESS.md, feature-list.json), загрузите последний чекпоинт и проверьте event log на наличие незавершённых intent инструментов. Согласуйте любой незавершённый внешний эффект до следующего вызова модели или инструмента.
2. Планируйте до выполнения любых tool calls. Зафиксируйте, как выглядит состояние «готово», сколько разрешено потратить запуску, какие инструменты агент может вызывать и что должно досрочно остановить запуск. Эти значения плана становятся runtime-проверками; без них выполнению нечем ограничить себя.
3. Сериализуйте tool calls с побочными эффектами или явно координируйте их. Проверка разрешений харнесса решает, пропускать ли каждый вызов. До dispatch добавьте intent pending с его idempotency key; после ответа провайдера добавьте результат. Независимые read-only или идемпотентные вызовы можно выполнять параллельно, если у каждого есть собственная durable-запись intent/result, а результаты агрегируются детерминированно. Если воркер завершился между побочным эффектом и записью результата, при возобновлении запросите результат у провайдера или повторите вызов с тем же ключом, затем добавьте восстановленный результат или needs_human. Например, Stripe возвращает сохранённый результат первого запроса для повторного idempotency key; другому провайдеру нужен эквивалентный контракт lookup или retry.
4. Создавайте чекпоинт на границах super-step или после каждого события в более простом харнессе. Сохраняйте состояние графа, diff рабочего пространства и ссылки на созданные артефакты. Именно этот чекпоинт читает шаг 1 при следующем resume. Если чекпоинт отсутствует или устарел, для восстановления может потребоваться пересборка состояния из event log, что значительно медленнее.
5. Когда агент считает работу завершённой, проверяйте артефакты: тесты, evaluator со свежим контекстом, валидация схемы, browser checks. При успешной проверке запуск завершается. При ошибке запуск возобновляется с последнего чистого чекпоинта, а сообщение об ошибке добавляется в контекст.

Ни один шаг в этом списке не требует, чтобы агент помнил что-либо между запусками. Состояние находится в сессии и чекпоинте, а при каждом возобновлении агент читает его обратно.

Сохраняйте operation ID, принадлежащий приложению, до dispatch и связывайте его с утверждёнными аргументами. Используйте его для восстановления того же бизнес-намерения, даже если replanning создаст новый ID tool call модели. Эти model ID записывайте отдельно для correlation. Естественно идемпотентным обновлениям вместо этого может потребоваться version precondition. Рекомендации AWS по ретраям объясняют, почему идентичность запроса представляет намерение. Определите, когда действие действительно новое и сколько длится дедупликация: Stripe разрешает удалять ключи не ранее чем через 24 часа. Перед новой попыткой согласуйте изменившийся payload и истёкшие ключи.

Выберите одного активного writer или lease на thread. Для входящих данных во время запуска явно задайте поведение: отклонять, ставить в очередь, прерывать или откатывать; эти варианты описаны в материале Deep Agents о рантайме. Отмена должна останавливать новые dispatch, записывать запрос и согласовывать эффекты in-flight; убийство воркера не отменяет вызов провайдера.

Контроль бюджета должен находиться рядом с dispatch. Конкурентные вызовы не должны расходовать один и тот же оставшийся лимит. Prometheus — это система мониторинга, а не authoritative ledger расходов на каждый запрос. Резервируйте консервативно и сверяйте фактическое использование; отложенный учёт провайдера и отмена всё равно могут вызвать перерасход.

Новые настройки моделей помогают регулировать темп запуска, но не владеют его лимитом расходов. Beta-функция Anthropic task budgets даёт поддерживаемым моделям Messages API advisory budget на agentic loop. Его можно превысить; max_tokens ограничивает один ответ, а не весь запуск. Поддержка зависит от модели: Opus 5 поддерживает task budgets, а Sonnet 5 — нет. Сохраняйте dispatch ledger и путь отмены даже при передаче модели budget hint.

Safety stops провайдера должны иметь собственный terminal path. Для misalignment_policy_violation OpenAI остановите dispatch, сохраните связанные записи и запросите проверку оператора вместо retry. Обрабатывайте stream errors после частичного output и согласовывайте предыдущие эффекты; граница мониторинга описана в части 4.

Оценка должна включать свидетельства за пределами контекста, в котором создавался результат. Evaluator со свежим контекстом снижает shared-context bias, а тесты, линтеры, browser checks и валидация схемы дают детерминированные свидетельства. Проверка может вернуть pass, fail или needs_human. Для code agents reviewer может быть другой сессией модели с read-only tools. Для data- и report-агентов сочетайте детерминированную валидацию с reviewer-моделью там, где всё ещё требуется суждение.

Одиннадцать паттернов деплоя ИИ-агентов и критерии выбора

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

Если вы читаете только одну из одиннадцати форм, читайте форму 2: queue + worker + checkpoint DB. Это вариант по умолчанию, который я рекомендую большинству команд, форма из reference repo и каркас, от которого отличаются большинство остальных: queue → worker → durable state, с заменой источника сэндбокса, владельца харнесса или движка состояния. После формы 2 остальные просматриваются быстрее.

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

1. SDK внутри app server (синхронный, в рамках запроса)

Исходная форма. Agent SDK запускается внутри request handler. Подходит для задач короче 30 секунд, демо и внутренних инструментов. Плохо подходит для всего, от чего HTTP-клиент может отключиться. HTTP timeout Cloud Run составляет максимум 60 минут, а любой panic на web-tier завершает запуск. SDK — это харнесс. Для недоверенного выполнения инструментов нужен отдельный сэндбокс, а состояние обычно живёт в памяти процесса, если явно не вынести его наружу. Не используйте этот вариант для многочасовой работы.

2. Queue + worker + checkpoint DB

Вариант по умолчанию, который я рекомендую большинству команд, и production-shaped demo implementation в market-analyst-agent: Python-воркер с PostgreSQL checkpointer, Redis Streams (или RabbitMQ) для входящей очереди и MCP sidecar для инструментов. Подходит для запусков от 10 минут до нескольких часов с идемпотентными шагами. Локальный runner может обходить очередь при синхронной разработке, но в продакшене очередь становится частью формы, когда требуются асинхронная отправка и backpressure.

В production-паттерне приложение принимает запрос, создаёт строку сессии, отправляет job в очередь и возвращает run ID. Воркер забирает job, запускает харнесс, записывает события сессии и чекпоинты, стримит статус и по ходу сохраняет артефакты. Postgres сохраняется, воркеры заменяемы, а глубина очереди даёт backpressure. Spot/Preemptible compute подходит, если durable-записи событий и чекпоинтов завершены до того, как воркер сообщит об успехе. Связанный репозиторий демонстрирует форму, но не проверенное durable recovery. Его consumer читает новые сообщения, не забирая pending jobs, ACK-ает исключения и повторно доставляет работу с новым initial state вместо определённого resume-контракта. Для продакшена нужны claim/lease/reclaim/ACK и fault-тесты, прежде чем эту топологию можно будет назвать восстанавливаемой.

В этой форме воркер — харнесс. Его контейнер и workspace на thread создают границу выполнения, но для недоверенного кода всё равно нужен hardened sandbox или VM. Event store владеет историей сессии; PostgresSaver владеет состоянием чекпоинтов. Они могут использовать одну базу только если харнесс явно записывает обе схемы. Трейсы передаются через OpenTelemetry в используемый вами стек observability.

3. Durable workflow engine (в стиле Temporal)

Код оркестрации агента запускается внутри Temporal Workflow; вызовы модели и инструментов выполняются как Activities. Состояние workflow хранится в event-history log на базе Cassandra, MySQL или Postgres, поэтому может воспроизводиться после сбоев. Для деплоев кода workflow, пересекающихся с уже выполняющимся запуском, нужны replay-safe Worker Versioning или patches; замена кода без этого может сломать replay. Интеграция Temporal × OpenAI Agents SDK, доступная в общем режиме с марта 2026 года, поставляется с helper OpenAIAgentsPlugin и activity_as_tool, а в материале agentic sandboxes описано перенаправление работающего агента на другого провайдера сэндбокса посреди разговора. Бездействующие workflow не потребляют вычислительные ресурсы. Ограничения существенны: realtime agents не поддерживаются, streaming всё ещё помечен как experimental, а LocalShellTool и ComputerTool отключены, поскольку не соответствуют распределённой модели.

Используйте эту форму, когда у запуска есть реальные точки ожидания: согласования людей, внешние callbacks, длительные sleep, ретраи с бизнес-правилами, окна деплоя — и команда может поддерживать replay-safe versioning workflow. Согласование человека становится durable sleep, не потребляющим compute, а не polling loop.

Код Workflow — это харнесс. Сэндбокс обычно находится за пределами Temporal и вызывается из Activities. Состояние сессии и чекпоинта объединяется с event-history log Temporal, а видимость трейсов обеспечивают Temporal UI и спаны OpenTelemetry для каждой Activity.

4. Sandbox provider на сессию

Более новая форма. Каждый запуск агента получает собственную microVM или контейнер у sandbox-as-a-service-провайдера. Харнесс живёт в durable-среде, а сэндбокс — одноразовая среда выполнения.

Показатели запуска у провайдеров измеряют разные интервалы и не образуют рейтинга скорости. Измеряйте отдельно время от API request до первой успешной команды и latency до готовности приложения, учитывая состояние image/cache, регион, concurrency и p95/p99. Например, примерно секундная загрузка контейнера Modal не включает инициализацию приложения. Перед load test проверьте account concurrency limits.

Daytona записывает parent-child link для каждого независимого fork, сохраняя lineage производных сэндбоксов. Харнесс OpenAI Codex использует вариант per-worktree: «Codex работает в полностью изолированной версии приложения, включая его логи и метрики, которые удаляются после завершения задачи».

Выбирайте эту форму, когда агент запускает недоверенный код, browser automation, тесты или установку пакетов. Компромисс — более высокие стоимость и зависимость от провайдера по сравнению с общими воркерами.

Провайдер владеет только сэндбоксом. Харнесс, сессия, чекпоинт и трейс остаются на вашей стороне и обычно подключаются по форме queue + worker из пункта 2.

5. Anthropic Managed Agents (hosted harness)

Anthropic запустила Managed Agents в public beta 8 апреля 2026 года за beta header managed-agents-2026-04-01. Сервис предоставляет hosted session, харнесс, сэндбокс и MCP proxy, связанный с vault. wake(sessionId) может инициализировать харнесс на новом воркере без потери durable session state.

Anthropic тарифицирует Managed Agents по стандартным расценкам за токены плюс $0.08 за session-hour. Тарификация идёт с точностью до миллисекунд и применяется только при статусе сессии «running»; idle time бесплатен. Поэтому runaway retry loop добавляет стоимость session-hour сверх стоимости токенов.

Читайте ограничения. Скидка Batch API не применяется («Сессии stateful и интерактивны. Batch mode отсутствует»). Managed Agents недоступен через AWS Bedrock или Google Vertex AI. В рамках beta MCP tunnels и «dreaming» агента требуют отдельного research preview с запросом доступа; мультиагентная координация и rubric-graded self-evaluation входят в документацию beta. Lock-in высокий: вы жертвуете свободой харнесса, чтобы не запускать цикл самостоятельно.

В стандартной cloud-конфигурации все пять примитивов находятся у Anthropic. При использовании self-hosted sandboxes вы управляете выполнением, файловыми системами и исходящим сетевым трафиком, а Anthropic запускает оркестрацию и модель. Входы и результаты инструментов всё равно попадают в его control plane; подключённые skills и memory хранятся там и синхронизируются. Владение выполнением не делает всю систему self-hosted.

Claude Platform on AWS также поддерживает Managed Agents и self-hosted sandboxes; это отдельный сервис, не Bedrock. Там автономной сессии требуется user-role event для повторной аутентификации через шесть часов, а self-hosted sessions не могут подключать memory stores. У first-party Managed Agents этих двух ограничений нет. Перед копированием дизайна сессии проверяйте и платформу, и модель.

6. LangChain Deep Agents Deploy (managed open harness)

deepagents deploy упаковывает deepagents.toml в LangSmith Deployment с durable execution, memory, multi-tenancy, human-in-the-loop, observability, sandboxed code execution и scheduled runs. Поддерживаются cloud, hybrid и self-hosted deployment modes. Провайдеры сэндбоксов (LangSmith Sandboxes, Daytona, Modal, Runloop или custom) переключаются одним значением конфигурации. Файлы агента и память живут в virtual filesystem с подключаемыми backend; персистентность чекпоинтов отделена, а память имеет область видимости user, assistant или обоих. Lock-in ниже, чем у Managed Agents: харнесс лицензирован по MIT, инструкции используют открытый стандарт AGENTS.md, а агенты доступны через MCP, протокол A2A (Agent2Agent) и Agent Protocol. См. материал LangChain runtime-behind-production-deep-agents.

По умолчанию все пять примитивов hosted, но каждый можно заменить конфигурацией. Сэндбокс задаётся одним параметром. Memory filesystem отделена от persistence thread и checkpoint. Трейс отправляется в LangSmith.

7. Google Cloud Run service или job

У Cloud Run есть два разных режима рантайма, и подходящий режим зависит от способа запуска агента. Services привязаны к HTTP и масштабируются до нуля между запросами; харнесс работает как request handler и возвращает ответ после завершения запуска. Jobs выполняются до конца без HTTP entrypoint; харнесс работает как одноразовый воркер и завершается по окончании задачи. Оба режима могут размещать харнесс, но ни один не хранит состояние между запусками. Сессии и чекпоинты должны находиться в Postgres, Spanner или аналогичном внешнем хранилище.

Жёсткие лимиты у них сильно различаются. Timeout запроса Cloud Run service: по умолчанию 300 с, максимум 3 600 с (60 мин). WebSockets получают тот же timeout. Cloud Run jobs: по умолчанию 10 минут на task, максимум 168 ч (7 дней); для tasks с GPU максимум 1 час. Billing по инстансам (всегда выделенный CPU) всё ещё допускает scale-to-zero; minimum instances — отдельная настройка; jobs не используют HTTP и не autoscale.

Используйте service для синхронных запусков длительностью до 60 минут. Для более долгой одноразовой или асинхронной работы используйте job. Cloud Run Jobs могут поддерживать task в течение нескольких дней, но не дают durable replay при деплоях, изменениях версий или замене воркера. Более долгий workflow может охватывать несколько executions, если внешний оркестратор владеет durable progress.

Cloud Run размещает харнесс. Состояние сессии и чекпоинта хранится в Postgres, Spanner или другом внешнем store, а трейсы могут идти через Cloud Logging и OpenTelemetry. Service container — это environment выполнения; добавьте отдельный сэндбокс, если агент запускает недоверенный код.

8. AWS Lambda: ограниченные invocations и durable workflows

Максимальный timeout функции Lambda — жёстко 900 с (15 минут). Если функцию обслуживает API Gateway, лимит интеграции зависит от типа API. HTTP APIs допускают 30 секунд; для REST integrations по умолчанию 29 секунд, а Regional и private REST APIs могут настроить больший timeout. Lambda durable functions, запущенные в декабре 2025 года, добавляют managed checkpoints, steps и waits для executions длительностью до одного года. Активный invocation остаётся ограниченным, а durable workflow может пережить его. Сопоставьте поддерживаемые runtimes, регионы, правила replay и идемпотентность activities со своими требованиями.

Lambda может размещать ограниченный харнесс в пределах лимита 15 минут. Состояние сессии и чекпоинта по-прежнему требует явно заданного внешнего хранилища; для недоверенного кода добавьте отдельный сэндбокс, а трейсы экспортируйте во внешнюю telemetry-систему. Durable Lambda workflow может координировать многочасовую работу через ограниченные invocations.

9. AWS ECS / Fargate task на запуск

Fargate не документирует жёсткий лимит времени жизни task, в отличие от обычного invocation Lambda. Fargate не поддерживает GPU tasks; для GPU workloads в ECS нужны подходящие EC2 instances или внешний GPU service. Fargate предоставляет изоляцию tasks на основе виртуализации, но credentials и разрешённый сетевой доступ всё равно требуют threat model. Fargate throttling quotas допускают burst запуска из 100 и восстановление с 20 в секунду, с отдельными бюджетами для on-demand и spot. ECS service quotas ограничивают services с AWS Cloud Map discovery 1 000 tasks на service, а кластеры на базе EC2 — 5 000 container instances.

Fargate требует режим awsvpc, поэтому каждая task получает network interface и private IP. Такая форма подходит для доступа к данным внутри VPC. Fargate Spot добавляет риск прерываний, а durability остаётся вашей ответственностью, поскольку у платформы нет replay в стиле Temporal.

Fargate размещает харнесс и даёт каждому запуску собственную task. Это разделяет рабочие пространства и credentials задач, но само по себе не является полноценным сэндбоксом для враждебного кода. Сессия, чекпоинт и трейс отправляются во внешние сервисы, такие как RDS или DynamoDB, плюс CloudWatch/X-Ray.

Перед самостоятельной сборкой AWS session layer также сравните Amazon Bedrock AgentCore Runtime. Он размещает код вашего агента с managed session lifecycle и выбором compute. AWS документирует до 8 часов на serverless microVM или до 14 дней на типе compute Instances, который также поддерживает GPU workloads. Instances используют управляемые AWS ресурсы EC2 в вашем аккаунте, поэтому их security model отличается от serverless-варианта. Явно выбирайте и тестируйте этот compute contract; более долгоживущий instance всё равно не обеспечивает exactly-once execution внешнего побочного эффекта.

10. Kubernetes Job или namespace на сессию

Подходит, если вы уже управляете Kubernetes и хотите sandbox-per-session с cluster-wide controls. Плохо подходит, если нужен старт за доли секунды, поскольку загрузка container image и инициализация pod слишком долгие при cold start. Паттерн — один Job на запуск агента, с activeDeadlineSeconds, PersistentVolumeClaim для workspace и sidecar для MCP-сервера. Восстановление после сбоя нужно строить самостоятельно. Внедрять Kubernetes только ради агентов дорого из-за сложности конфигурации и операционной нагрузки. Это оправдано лишь при уже существующем K8s по другим причинам.

Kubernetes размещает харнесс и per-run environment выполнения, обычно как один Job, иногда с отдельным namespace. Сильная изоляция по-прежнему зависит от runtime class, network policy, pod security и нижележащей границы контейнера или VM. Состояние сессии и чекпоинта находится во внешней базе или на PersistentVolumeClaim.

11. Local Docker Compose (только dev)

Эталон для следующего раздела. Смысл этой формы в том, что она один к одному повторяет production topology (те же примитивы и та же сетевой форма), но запускается на одном компьютере. Не повторяет она изоляцию: один общий workspace mount, один Postgres, отсутствие hardened sandbox и отсутствие отдельных failure domains между воркером и его состоянием. Ничего, что выглядит так, в продакшен не отправляйте.

Compose воспроизводит форму №2 на одном хосте. В reference stack Postgres хранит состояние чекпоинтов, а контейнер воркера является харнессом. Production-shaped session требует отдельного event store с независимой записью; одной истории PostgresSaver недостаточно. Общий workspace mount удобен при разработке, но не изолирует недоверенные запуски. Опциональный OpenTelemetry stack записывает трейсы.

Reference stack: Docker Compose

Reference topology, используемая в slavadubrov/market-analyst-agent, состоит из LangGraph worker, Postgres checkpointer, Qdrant для retrieval, MCP sidecar, Redis queue для async production-like запусков и опционального observability stack Prometheus / Grafana / Loki / Tempo / OTel. В local compose Redis опционален только потому, что synchronous runner может вызывать воркер напрямую. docker compose up поднимает core topology локально; MCP sidecar и observability stack включаются профилями (--profile mcp, --profile observability).

На диаграмме показан PostgresSaver локального демо. Production-shaped session добавляет отдельно записываемую event schema для intent и outcomes инструментов; один PostgresSaver по-прежнему является только состоянием чекпоинта.

Единственный компонент, который стоит показать inline, — каноническая wiring-схема LangGraph. Это иллюстративный фрагмент, а не runnable example из репозитория. Для запуска нужны langgraph, langgraph-checkpoint-postgres и psycopg[binary,pool], доступная PostgreSQL database с правом создавать таблицы checkpointer, POSTGRES_PASSWORD и предварительно собранный StateGraph в builder; см. настройку Postgres checkpointer в документации LangGraph.

import os
from urllib.parse import quote

from langgraph.checkpoint.postgres import PostgresSaver

password = quote(os.environ["POSTGRES_PASSWORD"], safe="")
DB_URI = f"postgresql://agent:{password}@postgres:5432/agent"
# `builder` is your StateGraph, already built
session_id = "session-123"
with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()  # creates tables on first run
    graph = builder.compile(checkpointer=checkpointer)
    result = graph.invoke(
        {"messages": [{"role": "user", "content": "Continue the task"}]},
        {"configurable": {"thread_id": session_id}},
    )

Observability, переживающая запуск

Короткие request handler легко отлаживать: при сбое вы читаете response и live log. У долгоживущих агентов такой возможности нет. К моменту сбоя шестичасового запуска интересное событие произошло пять часов назад, live terminal output исчез, а создавший его воркер заменён. Никто не станет восстанавливать запуск по памяти. Поэтому отладка опирается на durable artifacts, записанные, пока запуск ещё выполнялся.

Production stacks обычно покрывают четыре типа артефактов, разделённых на две группы. Два читают после завершения запуска — для postmortem и replay: доступный для запросов event log каждого шага и трейсы OpenTelemetry, показывающие, куда ушли время и токены. Два читают во время запуска. Один — live tail того, что агент создаёт в workspace. Другой — observability stack на worktree, который сам агент может запрашивать, пока работает.

Structured event log (читается после запуска)

Каждый вызов модели, tool call, результат, ошибка и согласование записываются в durable storage с ключом session ID и timestamp. После завершения запуска к нему можно обращаться как к обычной таблице базы данных. Addy Osmani прямо задаёт планку в Long-running Agents: «Если вы не можете восстановить из durable storage, что делал агент за последние 24 часа, у вас не долгоживущий агент, а долгоживущий shell script, который случайно вызывает LLM».

OpenTelemetry GenAI traces (читаются после запуска)

Те же пошаговые данные выдаются как spans со стандартными атрибутами из семантических соглашений gen_ai.*: имя модели, провайдер, количество входных и выходных токенов, ID разговора и имя workflow. Стабильность соглашений всё ещё имеет статус Development.

В 2026 году они были вынесены из основного репозитория semantic conventions OpenTelemetry в собственный репозиторий GenAI semantic conventions. Имена атрибутов можно использовать для инструментализации, но зафиксируйте проверенную ревизию, а не номер версии main repository. Поля конкретных провайдеров находятся в subnamespace (anthropic.*, openai.*), привязанных к gen_ai.provider.name. Стандарт нужен ради portability: в OTLP-compatible destinations, поддерживающих эти соглашения, смена backend может не потребовать повторной инструментализации кода, хотя backend adapters или destination-specific configuration всё равно могут понадобиться.

Timeline tool calls и diffs рабочего пространства (читаются во время запуска)

Самый быстрый способ понять, что агент делает прямо сейчас, — следить за тем, что он создаёт в workspace, а не искать по session log. Quick-start Anthropic Harness Primitives for Long-Running Claude Agents содержит двухпанельный watch loop: watch -n 5 'git log --oneline -8' показывает последние коммиты агента, а watch -n 5 'find screenshots -name "*.png" | tail -5' — последние сделанные им скриншоты. Двух терминальных панелей с обновлением каждые пять секунд достаточно, чтобы понять, движется ли запуск вперёд или зациклился.

Ephemeral stack на worktree (читается самим агентом во время запуска)

По публикации OpenAI: «Логи, метрики и трейсы доступны Codex через локальный observability stack, ephemeral для каждого worktree». Каждый worktree агента получает собственные краткоживущие Loki + Prometheus + Tempo, ограниченные только этим запуском. Агент сам запрашивает их во время работы. Благодаря этому промпт вроде «ни один span в этих четырёх пользовательских сценариях не должен превышать две секунды» превращается в проверяемое агентом утверждение, а не в догадку.

(Evaluator со свежим контекстом из таблицы режимов отказа читает эти артефакты, чтобы решить, «готово» ли. Он относится к evaluation, а не к observability; см. § здоровый жизненный цикл запуска. Он зависит от всех описанных выше поверхностей.)

Минимальный self-hosted observability stack

Для чего-то вроде market-analyst-agent:

1. OpenTelemetry Collector с GenAI Normalizer Processor (contrib, alpha) для поддерживаемых GenAI-атрибутов. Используйте generic Attributes или Transform processors для фильтрации или переписывания полей gen_ai.*.
2. Tempo (или Jaeger) для трейсов, с ключами gen_ai.conversation.id / thread_id.
3. Loki для записей структурированного event log.
4. Prometheus для gen_ai.client.token.usage, gen_ai.client.operation.duration и gen_ai.client.operation.time_to_first_chunk — метрики gen_ai.server.* выдаёт model server, поэтому они доступны только при самостоятельном размещении весов (см. GenAI metrics conventions).
5. Grafana dashboards с ключами gen_ai.agent.name и gen_ai.request.model.

Hosted alternatives (выберите одну, не три):

• LangSmith: нативная интеграция с LangGraph; также deployment target для Deep Agents Deploy.
• Braintrust: лучший вариант, если приоритет — regression suites, ориентированные на eval.
• Arize Phoenix: OSS, нативный OTLP (wire protocol OpenTelemetry), работает в связке с инструментализацией OpenInference.
• Tracing dashboard OpenAI: автоматически доступен при использовании OpenAI Agents SDK или его Temporal integration.
• Claude tracing Anthropic: для сессий, работающих внутри Managed Agents.

Инструментализация узла LangGraph

Это иллюстративный фрагмент, который runner примеров в репозитории пропускает. Он предполагает, что у узла LangGraph уже есть активный OpenTelemetry span, текущий thread_id и объект response провайдера usage с input_tokens и output_tokens; настройка tracer, export configuration и mapping usage провайдера находятся за пределами фрагмента.

# In the LangGraph node, around the model call:
span.set_attribute("gen_ai.operation.name", "chat")
span.set_attribute("gen_ai.provider.name", "anthropic")
span.set_attribute("gen_ai.request.model", "<your-model-id>")
span.set_attribute("gen_ai.response.model", "<your-model-id>")
span.set_attribute("gen_ai.conversation.id", thread_id)
span.set_attribute("gen_ai.agent.name", "market-analyst")
span.set_attribute("gen_ai.workflow.name", "research_then_write")
span.set_attribute("gen_ai.usage.input_tokens", usage.input_tokens)
span.set_attribute("gen_ai.usage.output_tokens", usage.output_tokens)

Имена атрибутов взяты без изменений из реестра OpenTelemetry GenAI semantic conventions.

Три запроса, которые стоит иметь на dashboard

# Loki: output tokens per agent in the last hour (one completion event per call)
sum by (gen_ai_agent_name) (
    sum_over_time({service_name="market-analyst-agent"} | json | event = "model_call_completed" | unwrap gen_ai_usage_output_tokens | __error__="" [1h])
)

# PromQL: p95 model latency per model
histogram_quantile(0.95,
    sum by (le, gen_ai_request_model) (
        rate(gen_ai_client_operation_duration_bucket[5m])
    )
)

# TraceQL: long-running tool calls
{ span.gen_ai.operation.name = "execute_tool" && duration > 30s }

Агрегация LogQL предполагает ровно одно logged completion event на каждый вызов модели. Дедуплицируйте эти события до ingestion; иначе rate покажет tokens per second вместо суммарного значения за один час. Проверьте mapping полей относительно развёрнутого Loki stream.

Паттерн debug bundle

При сбое запуска воркер должен сохранить /workspaces/${THREAD_ID}/_debug/, содержащий артефакты, которые понадобятся для postmortem:

• events.jsonl: export отдельно записываемого append-only event store харнесса, включая intents инструментов, outcomes, approvals и errors.
• checkpoints.jsonl: история состояния графа из checkpointer.list({"configurable": {"thread_id": ...}}), помеченная как checkpoints, а не event log.
• last_state.json: StateSnapshot.values с последнего успешного super-step.
• trace.json: OTLP-exported spans запуска; baseline — metadata, а собранный content подчиняется trace policy.
• tool_calls.csv: (ts, tool, input_hash, latency_ms, status, error).
• workspace.tar.zst: каталог workspace плюс git diff относительно initializer commit.
• screenshots/*.png: что видел агент.
• PROGRESS.md, feature-list.json и другие progress-файлы, созданные агентом.
• env.txt: image tags, версия модели, harness commit SHA.

Вместе эти артефакты могут дать человеку или reviewer agent достаточно свидетельств для восстановления сбоя — при условии, что харнесс записывал event store, пока запуск выполнялся. «Агент застрял» — расплывчатое утверждение. Иллюстративный отчёт конкретен: сессия s_123 потратила 71% токенов, повторяя три команды после сбоя npm install.

Как выбрать подходящую форму: руководство по решениям

Большинство приведённых сравнений сводится к нескольким решениям.

Начните с длительности запуска

Используйте длительность запуска как первый фильтр:

• Меньше 30 секунд, идемпотентный: SDK в app server в рамках request lifecycle.
• От 30 с до 60 мин: queue + worker + checkpoint DB.
• От 60 мин до 24 ч: та же queue + worker или Cloud Run Job для одноразовой работы. Если также нужны versioning и replay, используйте durable workflow engine.
• Более 24 часов, необходимо переживать деплои: durable workflow engine (в стиле Temporal). Cloud Run Jobs могут поддерживать долгую работу до лимита task, но не предоставляют replay semantics.
• Многодневные циклы обучения с reinforcement learning: K8s Job + volume + Temporal.

После этого грубого фильтра проверьте побочные эффекты, восстановление, replay, изоляцию, расположение данных и команду, которая будет эксплуатировать систему.

Соответствие платформы сценарию

Матрица плотная, и ни одна зелёная ячейка сама по себе не определяет архитектуру; обычно решающими становятся условные ячейки, где платформа что-то поддерживает с оговорками. Широкий охват workloads полезен, но он не показывает data residency, replay semantics, зависимость от провайдера, операционную зрелость или стоимость последующего переноса состояния.

Во всех платформах для conditional cells используется одно и то же правило. AWS/VPC- и GPU-возможности Deep Agents зависят от hybrid deployment или sandbox provider; Managed Agents может использовать customer-operated execution при сохранении hosted orchestration. Строка выбора сэндбокса включает интеграцию внешнего провайдера, которую вы строите на принадлежащем вам рантайме или настраиваете в managed harness. Она не обещает снапшот работающего состояния. Kubernetes Job также требует API или queue layer для интерактивного запроса; быстрое завершение не превращает его в HTTP service. Перед выбором сравните network access, hardware, recovery и state-export path выбранного деплоя. Строка harness-code описывает доступ к реализации цикла, а не portability managed deployment или его состояния. Для запуска GPU в Kubernetes также нужны GPU nodes, drivers и device plugin.

Managed Agents требует Claude и orchestration под управлением Anthropic. Его опциональный self-hosted sandbox может подойти для выполнения в приватной сети, но требование self-host inference или control plane всё равно исключает этот вариант. Проверьте, какие inputs инструментов, results, skills и memory могут пересекать эту границу. Внутренняя разработка может подходить, если такие потоки данных приемлемы и команда хочет делегировать эксплуатацию харнесса.

Цену стоит моделировать до фиксации решения, а не после. Стоимость session-hour — $0.08/hour сверх стандартной стоимости токенов. Если одна сессия работала бы непрерывно, это около $58/month на сессию. Для 100 непрерывно работающих сессий — около $5,800/month до учёта токенов. Умножьте $0.08 на ожидаемое число часов работы concurrent sessions, добавьте к счёту за токены и сравните с затратами на queue + worker stack в собственной инфраструктуре. Переезд с Managed Agents впоследствии будет re-platforming, а не изменением конфигурации.

Hosted harness против owned harness

Здесь различие определяется тем, кто эксплуатирует харнесс, а не тем, кто написал его код. Hosted означает, что вендор запускает цикл харнесса в своей инфраструктуре, а вы вызываете API. Owned означает, что цикл запускаете вы на своей инфраструктуре, даже если код харнесса предоставлен вендором.

LangChain оказывается по обе стороны этой границы, что часто приводит к путанице. Компания поставляет LangGraph — библиотеку с лицензией MIT, которую вы размещаете самостоятельно (owned), — и Deep Agents Deploy — managed product, который по умолчанию запускает харнесс Deep Agents в LangSmith Deployment в cloud mode (hosted). Одна компания, две разные операционные модели. Вы выбираете, кто запускает цикл, а не чей логотип стоит на библиотеке. (У Deep Agents Deploy также есть self-hosted mode для команд, которым нужна ergonomics харнесса без cloud component; этот режим относится к owned.)

Выбирайте hosted harness, когда его поддержка моделей, граница данных, поведение восстановления и extension points уже подходят. Выбирайте owned harness, когда эти ограничения обязательны и, как ожидается, будут меняться. Миграция между ними меняет state, observability и execution boundaries, поэтому проверьте exit path до того, как production data начнёт от них зависеть.

Hosted sandbox против принадлежащей вам execution environment

Выбирайте hosted sandbox, когда isolation, pause/resume или fork semantics провайдера соответствуют threat model и startup budget. Docker или Fargate могут подойти для доверенных внутренних workloads, которым нужен доступ к VPC или строгая data residency, но стандартный контейнер не является достаточной границей для hostile code. В части 4 описаны варианты изоляции для этого случая.

State stores: Git, DB и object storage рядом

Долгоживущие агенты обычно одновременно используют три state store, поскольку каждый владеет своим артефактом.

Git хранит состояние workspace: код, документы и progress-файлы, которые изменяет агент. Каждый коммит даёт харнессу стабильную точку восстановления, а следующей сессии — компактную историю.

Checkpoint database хранит состояние графа: что было решено, какие узлы выполнялись, какие результаты вернулись и что нужно запустить дальше. Artifact store содержит крупные финальные outputs, например PDF, Parquet-файлы и скриншоты. Эти артефакты не должны находиться в Git или checkpoint database.

Когда использовать git как state

Используйте git, когда workload похож на код (многофайловые изменения, рефакторинг, генерация приложения) или достаточно похож на документы, чтобы история файлов имела значение. Паттерн прост: создайте run branch, сделайте initializer commit, затем коммитьте на значимых границах: после настройки, каждой фичи, прохождения тестов и финальной очистки. Последний workspace commit SHA храните рядом со строкой чекпоинта. При resume следующий воркер переключается на branch, читает git log --oneline -8, проверяет git status и последний diff, затем читает PROGRESS.md или handoff-файл, записанный предыдущей сессией.

Так git становится поверхностью восстановления редактируемого артефакта, а не заменой checkpoint DB. Git может ответить на два вопроса: что изменилось и какая версия прошла тесты. Но он не скажет харнессу, какой узел графа нужно запустить следующим, какой tool call ожидает approval и какой retry уже использовал idempotency key. Харнесс Anthropic использует initializer commits и per-feature commits как источник истины для восстановления workspace; модель читает git log --oneline -8 для восстановления состояния. Пропускайте git, когда результатом является один conversational answer. Накладные расходы не окупаются.

Когда использовать DB checkpointing

Используйте checkpointing в стиле PostgresSaver, когда у агента есть структура графа с несколькими узлами, промежуточное состояние которых важно (planner → researcher → writer → verifier). Именно поэтому это используется в reference repo. Не помещайте workspace artifacts терабайтного масштаба в checkpoint; для них предназначено object storage.

Когда использовать artifact store (S3 / GCS)

Используйте object storage, когда:

• output больше, чем должна переносить checkpoint database;
• downstream consumers нужен artifact, доступный по URL, без обращения к агенту; или
• у deliverable и run state разные сроки хранения.

Например, session log можно удалить через 30 дней, а финальный отчёт хранить годами. Структурируйте layout по (thread_id, checkpoint_id, artifact_name), чтобы producing run оставался восстанавливаемым.

Когда запрашивать согласование человека

Требования к согласованиям задавайте на основе риска действия, уже предоставленных полномочий и deployment policy. Обратимая draft-запись в базу данных отличается от списания средств с клиента или разрушительного изменения в продакшене. Когда требуется согласование, покажите фактическое действие, аргументы и назначение, сохраните решение и проверьте его заново, если предложенный вызов изменился; отклонённый вызов выполнять нельзя. interrupt() LangGraph и approval middleware Deep Agents могут поставить запуск на паузу для такого решения. В части 4 объясняется, почему это permission decision, а не инструкция в промпте.

Практический production checklist

До запуска долгоживущего агента ответьте на эти вопросы в конкретных терминах инфраструктуры.

1. Какое хранилище владеет событиями сессии и чекпоинтами?
2. Что произойдёт, если воркер завершится посреди tool call?
3. Может ли один запуск повредить workspace другого запуска?
4. Какие действия требуют согласования?
5. Может ли модель или сэндбокс прочитать raw credentials?
6. Какие tool calls можно безопасно повторить?
7. Где обеспечивается per-run cost cap?
8. Какие детерминированные свидетельства определяют завершение, а каким оставшимся критериям нужен reviewer?
9. Где окажутся финальные outputs после удаления сэндбокса?
10. Сможем ли мы завтра объяснить сбой запуска, не выполняя его заново?

Если ответ на любой из вопросов — «промпт говорит агенту быть осторожным», система ещё не задеплоена. Это всё ещё демо.

Следующий слой — цикл харнесса

Этот рантайм может поддерживать запуск в живом и восстанавливаемом состоянии, но durability не доказывает корректность работы. В части 6, Harness Engineering for AI Agents, рассматривается примитив харнесса из таблицы выше: как по трейсу определить, с каким из нескольких сбоев вы столкнулись, где находятся правила ретраев и остановки, что должен сохранять handoff и как внешняя acceptance-проверка определяет завершение запуска. Это также последний материал серии.

References

Engineering write-ups

• OpenAI, Harness engineering: leveraging Codex in an agent-first world.
• Anthropic Engineering, Effective harnesses for long-running agents.
• Anthropic Engineering, Harness design for long-running application development.
• Anthropic Engineering, Scaling Managed Agents: Decoupling the brain from the hands, 8 апреля 2026 года.
• Cognition AI, Rebuilding Devin for Claude Sonnet 4.5: Lessons and Challenges.
• Vercel, We removed 80% of our agent’s tools.
• Addy Osmani, Long-running Agents.

LangGraph и Deep Agents

• Документация LangGraph, Persistence.
• LangGraph reference, Checkpoints.
• langgraph-checkpoint-postgres на PyPI.
• Документация LangChain, Deep Agents overview.
• Документация LangChain, Deep Agents permissions.
• Блог LangChain, The runtime behind production Deep Agents.

OpenAI Agents SDK

• OpenAI Agents SDK, Sessions.
• OpenAI Agents SDK, Sandbox concepts.

Temporal

• Блог Temporal, Introducing Temporal and agentic sandboxes: the OpenAI Agents SDK.
• Блог Temporal, Production-ready agents with the OpenAI Agents SDK + Temporal.
• README Temporal × OpenAI Agents SDK contrib (temporalio/sdk-python).

Платформа Anthropic

• Anthropic, Claude platform pricing: расценки Managed Agents за session-hour.
• anthropics/cwc-long-running-agents: Code with Claude 2026 take-home с evaluator subagent и progress-file patterns.

Провайдеры сэндбоксов

• ZenML, E2B vs Daytona: sandbox comparison for platform engineers.
• Документация Daytona, Sandboxes.
• Changelog Daytona, Sandbox fork and snapshot endpoints.
• Документация Modal, Sandboxes.
• Документация Modal, Cold start guide.
• Runloop on AWS Marketplace.
• Vercel Sandbox pricing and limits.

Тайм-ауты и квоты cloud-платформ

• Google Cloud, Configure request timeout for services.
• Google Cloud, Using WebSockets.
• Google Cloud, Set task timeout for jobs.
• AWS, Configure Lambda function timeout.
• AWS, Lambda quotas.
• AWS, Fargate throttling quotas.
• AWS, ECS service quotas and API throttling limits.

Observability

• OpenTelemetry, Semantic conventions for generative AI systems.
• OpenTelemetry, Gen AI attributes registry.
• OpenTelemetry, Semantic conventions for GenAI agent and framework spans.
• OpenTelemetry, Semantic conventions for generative AI metrics.

Код Market Analyst Agent (LangGraph worker, Postgres checkpointer, Qdrant memory, MCP sidecar и описанная выше Docker Compose topology) находится на GitHub.