Перейти к содержанию

Автоматический перевод

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

Runtime для долгоживущих AI-агентов в 2026 году: сессии, sandbox, checkpoints и harness

Часть 5 серии Engineering the Agentic Stack

В предыдущих четырех постах мы разбирали внутреннее устройство агента: циклы рассуждений, архитектуру памяти, использование инструментов, безопасность. Этот пост — про внешнюю часть: production runtime вокруг долгоживущих AI-агентов.

Production AI-агенты в 2026 году перестали быть обработчиками запросов и стали фоновыми worker-процессами. Один run может длиться несколько часов. Worker, который его хостит, — не обязательно. Самая интересная инженерия сместилась из агента в runtime вокруг него. Модель выбирает следующий шаг. Runtime решает, что произойдет с этим шагом, если worker умрет посреди вызова.

Кратко: долгоживущим AI-агентам нужен runtime вне модели: журналы сессий, логика harness, изоляция sandbox, checkpoints, traces, policy checks, secrets и лимиты стоимости. Queue + worker + checkpoint DB — дефолт, если стек ваш; hosted harness подходят, если вас устраивают ограничения вендора. Выбирать нужно сначала по длине run, затем по семантике восстановления, требованиям к replay, изоляции sandbox и операционной ответственности.

Пост длинный. Вот что внутри:

В первой половине разбираются пять runtime-примитивов и сценарии отказов, ради которых каждый из них нужен. Во второй половине сравниваются одиннадцать вариантов развертывания — SDK-в-app-server, queue + worker, Temporal, Anthropic Managed Agents, Deep Agents Deploy, Cloud Run, Lambda, ECS, Kubernetes Job per session и еще два — и в конце дается руководство по выбору.

Что меняется, когда долгоживущие агентные сессии живут дольше процессов

Год назад «развернуть агента» означало завернуть chat endpoint в контейнер и направить на него load balancer. Такая работа ничем не отличалась от любого другого Python web service. Это перестало быть правдой в тот момент, когда агенты начали работать часами, а не секундами.

Команда OpenAI Codex зафиксировала новый baseline в своем разборе harness engineering:

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

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

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

Если отнестись к этой фразе всерьез, весь runtime stack меняет форму. Из «дискретных сессий без общей памяти» следуют три последствия, и каждое вносит в дизайн конкретный инфраструктурный компонент.

Если сессии дискретны, сама сессия должна жить вне процесса. In-memory state исчезает в момент выхода worker, поэтому сессию нужно писать в durable store, который сможет прочитать следующий worker. Если сессия может возобновиться после crash, durable record должен содержать всё, что произошло до этого момента, а не только финальный ответ. Это позволяет следующему worker продолжить с нужной точки, а не переигрывать run с нуля. Если модель заполняет свое context window до завершения работы, что-то должно checkpoint'ить прогресс, завершать текущую сессию и запускать новую, которая загрузит checkpoint вместо полного replay истории. В формулировке Anthropic harness становится «cattle»: disposable, restartable, identical instances. Состояние живет в другом месте.

Модель решает, что делать дальше. Runtime решает, разрешено ли это действие, где оно выполняется, как оно записывается и как run возобновляется после crash. Остальная часть поста — про этот runtime.

Пять runtime-примитивов, которые нужны каждому долгоживущему AI-агенту

Статья Anthropic Scaling Managed Agents дала индустрии рабочий словарь, и большая часть рынка уже на нем сошлась. Пять компонентов делают почти всю runtime-работу. Harness пошагово двигает агента вперед; session записывает, что он сделал; sandbox — место, где выполняются команды; checkpoint — то, что следующий worker читает при resume; trace — то, что вы будете читать через несколько дней, когда понадобится понять, что пошло не так. Каждый компонент можно заменить, пока сохраняется его ответственность.

Пять runtime-примитивов

Session. Append-only log всего, что произошло: model calls, tool calls, results, errors, approvals. Восстановление — это wake(sessionId) → getSession(id) → resume from last event. В LangGraph это thread_id плюс Postgres checkpointer (см. LangGraph persistence). OpenAI Agents SDK поставляется с десятью встроенными session backend, включая SQLiteSession, RedisSession, SQLAlchemySession, MongoDBSession и EncryptedSession (см. Sessions docs).

Harness. Orchestration loop. Он вызывает модель, парсит tool calls, выполняет их, записывает результаты обратно в session и применяет правила retry. Anthropic формулирует это прямо:

«каждый компонент в harness кодирует предположение о том, чего модель не может сделать сама по себе.»

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

Sandbox. Изолированная execution environment, где команды реально исполняются. Страница OpenAI Agents SDK sandbox concepts проводит границу очень четко:

«Внешний runtime по-прежнему владеет approvals, tracing, handoffs и resume bookkeeping. Сессия sandbox владеет командами, изменениями файлов и изоляцией окружения.»

Sandbox различаются по тому, как долго они живут и что помнят между run. Самая простая форма — fresh ephemeral: поднять sandbox для одной задачи, уничтожить после завершения и платить cold-start cost на каждом run. Persistent paused sandbox остаются живыми между run в paused state; файловая система и memory snapshot сохраняются, поэтому следующий resume занимает меньше секунды вместо полного boot. Snapshot or fork идет дальше: каждая задача ветвится как copy-on-write image от родительского образа, в котором уже установлены зависимости и прогреты кэши, поэтому дорогой setup выполняется один раз, а N задач делят базовый image. Per-worktree sandbox дают каждой задаче собственный workspace и собственный observability stack: отдельные logs, metrics и traces. Это позволяет дебажить run одного агента без протекания в другой. Конкретные цифры по cold-start и persistence для разных провайдеров есть в таблице ниже в этом разделе.

Checkpoint. Resumable state. В LangGraph PostgresSaver записывает StateSnapshot на каждой границе super-step, а per-task writes в checkpoint_writes позволяют не пересчитывать успешные outputs узлов, когда соседний узел падает. Snapshot — это JSON-serializable dict (v, ts, id, channel_values, channel_versions, versions_seen, pending_sends), задокументированный на странице PyPI langgraph-checkpoint-postgres и в LangGraph checkpoints reference.

Trace. Поверхность для replay и debug. Каждый model call, tool call и шаг sub-agent становится span с таймингами, inputs, outputs, количеством токенов и стоимостью. Когда шестичасовой run падает, trace — это то, что вы читаете, чтобы понять, что пошло не так. Terminal output к этому моменту уже давно исчез. GenAI semantic conventions OpenTelemetry стандартизируют имена атрибутов (какая модель, какой provider, сколько токенов, какой conversation, какой workflow), так что один и тот же trace корректно отображается в Tempo, Jaeger, Honeycomb или LangSmith без повторной instrumentation.

Policy и secrets — отдельные runtime-границы

Две границы проходят поперек всех пяти примитивов, и о них проще думать как об отдельных concern. Это runtime-версия аргумента про security из Части 4.

Policy engine

Перед каждым tool call выполняется permission check, который решает, будет ли вызов разрешен. В production распространены два паттерна. Deep Agents позволяет каждому subagent объявить, какие file paths он может читать или писать, а middleware блокирует всё вне этого объявления. Anthropic Managed Agents пропускает каждый tool call через MCP proxy, так что permissions применяются не в коде агента, а в proxy. Когда sensitive call требует human approval, interrupt() в LangGraph и approval hook в Deep Agents ставят graph на паузу, пока человек не скажет yes.

Secret broker

Модель не должна видеть long-lived secrets, и sandbox обычно тоже не должен. Паттерн Managed Agents здесь стоит копировать:

«Для Git мы используем access token каждого repository, чтобы клонировать repo при инициализации sandbox и привязать его к локальному git remote. Git push и pull работают внутри sandbox без того, чтобы агент вообще держал токен в руках. Для custom tools мы поддерживаем MCP и храним OAuth tokens в secure vault. Claude вызывает MCP tools через dedicated proxy; этот proxy получает token, связанный с session. … Harness никогда не узнает никаких credentials.»

В reference stack market-analyst-agent MCP sidecar читает OAuth tokens из Docker secret (в production — HashiCorp Vault) и отдает LangGraph worker только поверхность инструментов. Worker никогда не видит token. git push работает. cat ~/.ssh/id_rsa — нет.

Практическая sanity check для собственного стека: выпишите каждый компонент, который вы запускаете, и какой из пяти примитивов он реализует. Postgres может закрывать session и checkpoint. Worker container — это harness. Hosted-sandbox service вроде Daytona, Modal или E2B — это sandbox. Tempo или LangSmith — это trace. Если окажется, что два примитива живут в одном процессе, один crash положит оба. Если у двух примитивов один credential, одна утечка положит оба. Оба сценария легко внести случайно, когда вы движетесь быстро: worker, который еще и пишет traces, sidecar token, который еще и открывает checkpoint DB.

Failure modes production runtime для AI-агентов

Runtime существует ради того, чего модель сама делать не может: управлять retry, помнить, что она сделала три часа назад, изолировать файловую систему одного run от другого, останавливаться до исчерпания бюджета. Сейчас мы уже назвали семь его частей: harness, session log, sandbox, checkpointer, tracer, policy engine, secret broker. Как только один run агента пересекает примерно 30 минут wall time, начинает проявляться узнаваемый набор отказов. Большинство из них никак не связано с качеством рассуждений; это проблемы состояния, retry, sandbox и бюджетов.

Эти отказы делятся на четыре условные группы:

  • Проблемы качества результата: агент объявляет победу до того, как работа действительно завершена, забывает, что он делал после сброса context window, или доверяет собственной self-evaluation и выпускает сломанный output.
  • Проблемы контроля стоимости: агент застревает в retry loop или сжигает budget токенов или tool calls, не производя ничего полезного.
  • Проблемы состояния и crash: workspace drift, когда один run трогает файлы другого, tool calls срабатывают больше одного раза из-за replay при retry, или работа теряется, когда worker умирает между событиями.
  • Проблемы context window: модель prematurely делает summary и завершает run, потому что думает, что у нее заканчивается место, даже когда в окне еще есть запас.

Таблица ниже связывает каждый failure с mitigation pattern, runtime hook, где живет mitigation, и тем, нужен ли он еще на текущем поколении моделей. Некоторые mitigation уже не нужны. Чем старше ваш harness, тем больше в нем, вероятно, устаревших mitigation.

Failure modes и способы их смягчения

Failure mode Mitigation Всё ещё нужно? Runtime hook
Преждевременное завершение: агент слишком рано объявляет победу Разделение generator/evaluator: evaluator с fresh context читает файлы (а не chat) и голосует «done» или «not done». Default-FAIL на каждой acceptance check. Да; даже Anthropic в quick-start для cwc-long-running-agents всё ещё включает evaluator subagent. Sub-agent без инструментов Write/Edit и со своим context window
Feature amnesia между context windows Initializer agent пишет claude-progress.txt, feature-list.json, init.sh. Coding agent читает их на каждом cold boot. Да; одного compaction для этого недостаточно. Boot hook перед первым model call каждой session
Дублирование работы после session reset Append-only event log плюс структурированный handoff file. Каждая новая session стартует с pwd → read PROGRESS.md → review tests. Да Checkpoint PostgresSaver в LangGraph плюс artifact progress.md
Context anxiety: модель делает summary и преждевременно завершает run (a) Включить 1M-token beta, но ограничить effective usage до 200k (fix Sonnet 4.5 у Cognition). (b) Завершать session и собирать новую из handoff. Нет для Opus 4.5; Anthropic пишет, что «это поведение исчезло», а resets «стали мертвым грузом». Да для Sonnet 4.5 и GPT-5/Codex. Внешний driver ограничивает длину session, запускает следующую и возобновляет ее из checkpoint
Излишний оптимизм self-evaluation: модель считает свою работу успешной Отдельный evaluator плюс grounding через Playwright/MCP в реальном DOM, а не по скриншотам. Frontend rubric из harness design у Anthropic штрафует «AI-style» defaults. Да Evaluator запускается в отдельной session sandbox без write tools
Зависшие циклы и retry storms Лимит итераций на turn, exponential backoff, circuit breaker по rate tool errors. Жесткий budget на tool calls. Да Декоратор на node выполнения инструментов; RetryPolicy на Temporal Activities (см. Temporal OpenAI Agents SDK contrib)
Workspace drift: агент редактирует не относящиеся к задаче файлы Git commits как checkpoints, middleware с file permissions, per-session mount workspace. Middleware Deep Agents позволяет объявить path read/write. Да Middleware file permissions в LangGraph или per-task fork в Daytona/Runloop
Убегающая стоимость токенов или tool calls Per-run token budget, per-tool budget, kill switch, привязанный к счетчику Prometheus. Да; 24-часовая session Opus с плохим budgeting может за afternoon сжечь недельный API budget (Addy Osmani о long-running agents). Span attributes для cost attribution плюс правило в Alertmanager
Неидемпотентные tool calls Idempotency key на каждый tool call. В durable workflows retry может запустить один и тот же tool call больше одного раза, поэтому deduplication key блокирует дубликат. Да Temporal Activity с start_to_close_timeout и idempotency key
Потеря работы после crash процесса или sandbox Durable session log вне процесса; checkpoint после каждого super-step. wake(sessionId) → getSession(id) → resume. Да PostgresSaver на каждом super-step или оборачивание в Temporal Workflow

Две идеи проходят через всю таблицу. Anthropic о старении harness в Harness design for long-running application development:

«Каждый компонент в harness кодирует предположение о том, чего модель не может сделать сама, и эти предположения стоит stress-test'ить — и потому, что они могут быть неверными, и потому, что они быстро устаревают по мере улучшения моделей.»

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

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

По данным Vercel, на репрезентативном запросе success rate вырос с 80% до 100%, а худший случай сократился с 724 s / 100 steps / 145,463 tokens (ошибка) до 141 s / 19 steps / 67,483 tokens (успех). Вывод не в том, что нужно «удалить инструменты». Вывод в том, что у каждого примитива вашего runtime, включая tool surface, есть срок актуальности. При смене модели нужно заново проверять предположения.

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

У команды OpenAI harness есть однофразовая версия дисциплины: «Humans steer. Agents execute.» Когда что-то ломается, вопрос не в том, чтобы «попробовать сильнее». Вопрос в том, «какой capability не хватает, и как сделать его одновременно понятным и enforceable для агента?»

Жизненный цикл здорового run

Хорошо ведущий себя run скучен. Это цепочка маленьких восстанавливаемых шагов, и каждый пишет свой результат в durable storage до того, как начнется следующий, а не один гигантский request, который должен успешно пройти end-to-end. Разбиение run на такие шаги и позволяет ему переживать crash: когда что-то ломается, теряется только step, который был в полете, а следующий worker продолжает с последнего завершенного шага вместо старта заново.

Жизненный цикл развернутого agent run

  1. Boot либо из fresh session, либо из resumed session. При resume смонтируйте workspace в его последнем известном состоянии, прочитайте progress files, которые оставила предыдущая попытка (PROGRESS.md, feature-list.json), и загрузите последний checkpoint из базы. Здесь harness передает агенту всё, что предыдущий worker держал в памяти до своей смерти.
  2. Спланируйте всё до того, как сработает хоть один tool call. Зафиксируйте, как выглядит «done», сколько run может потратить, какие tools агенту разрешено вызывать и что должно останавливать run раньше срока. Эти значения плана становятся runtime checks; без них execution не от чего отталкиваться.
  3. Выполняйте по одному tool call за раз. Policy layer решает, разрешать ли вызов. Harness запускает его, захватывает результат и пишет одно событие в session log. Один step — одно событие. Crash между событиями восстанавливаем, потому что source of truth — это log, а не память worker.
  4. Делайте checkpoint на границах super-step, либо после каждого события в более простом harness. Сохраняйте state graph, diff workspace и ссылки на все produced artifacts. Именно этот checkpoint прочитает шаг 1 при следующем resume. Если checkpoint отсутствует или устарел, recovery деградирует до replay всего session log с нуля, а это значительно медленнее.
  5. Когда агент считает, что он закончил, проверяйте результат по артефактам: tests, reviewer с fresh context, schema validation, browser checks. Если проверка прошла, run успешно завершается. Если нет — run продолжается от последнего чистого checkpoint, а сообщение об ошибке добавляется в context, и делается новая попытка.

В этом списке нет ни одного шага, который требовал бы от агента помнить что-то между run. Состояние живет в session и checkpoint, а агент перечитывает его при каждом resume.

Инструментам с side effects нужна idempotency. Любому tool с side effects нужен idempotency key, производный от session ID и tool-call ID, который сохраняется до выполнения side effect. send_email(session_id, tool_call_id, message_hash). create_pr(session_id, tool_call_id, branch_name). charge_customer(session_id, tool_call_id, invoice_id). At-least-once execution — default в queue и workflow engines. Если повтор tool call может причинить реальный вред, инструмент не готов для агентов.

Evaluation должно выполняться вне producing context. Тот же контекст, который произвел ответ, не может надежно судить, правильный ли он. Свежий evaluator читает files и artifacts, прогоняет tests, lints, browser checks или schema validation и возвращает pass, fail или needs_human. Для code agents это еще одна model session с read-only tools. Для data и report agents — deterministic validator плюс reviewer model.

Одиннадцать паттернов развертывания AI-агентов и что определяет выбор между ними

Когда пять примитивов названы, следующий вопрос — какой deployment shape их запускает. Под «shape» я имею в виду схему размещения этих примитивов: где живет harness, где хранится state и какой тип sandbox выполняет работу. Это не просто выбор одного вендора. График ниже показывает, на какой оси run length каждый shape чувствует себя комфортно. Текст после него разбирает, что именно определяет выбор.

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

Deployment shapes и их sweet spot по длине run

График сравнивает shapes по длине run. Матрица ниже сравнивает их по владению: где физически живет каждый из пяти примитивов. Зеленые ячейки — там, где shape дает примитив; серые — там, где вы подключаете его сами.

Где живет каждый примитив в каждом deployment shape

1. SDK внутри app server (synchronous, request scoped)

Исходный shape. SDK агента работает внутри request handler. Подходит для задач меньше 30 секунд, demo и внутренних инструментов. Плохо подходит для всего, от чего HTTP client может отключиться. Максимальный HTTP timeout в Cloud Run — 60 минут, а любой panic веб-уровня убивает run. SDK — это harness, web process одновременно выступает sandbox, а state обычно живет в памяти процесса, если вы явно не вынесли его наружу. Не используйте этот вариант для многочасовой работы.

2. Queue + worker + checkpoint DB

Дефолт, который я рекомендую большинству команд, и production shape, использованный в market-analyst-agent: Python worker с PostgreSQL checkpointer, Redis Streams (или RabbitMQ) для входящей queue и MCP sidecar для инструментов. Подходит для run от 10 минут до нескольких часов при идемпотентных шагах. Local runner может обходить queue для synchronous development, но в production shape queue уже обязательна, как только вам нужны async submission и backpressure.

Приложение принимает request, создает строку session, кладет job в queue и возвращает run ID. Worker вытягивает job, запускает harness, пишет checkpoints, стримит status и сохраняет artifacts по мере работы. Postgres переживает сбои, workers — это cattle, а глубина queue дает backpressure. Spot/Preemptible compute работает, если checkpointer успевает записать всё на диск до того, как сообщает об успехе.

В этом shape worker — это harness. Worker container плюс per-thread mount workspace — это sandbox. Postgres владеет состоянием session и checkpoint. Traces уходят через OpenTelemetry в любой observability stack, который вы используете.

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

Код orchestration агента работает внутри Temporal Workflow; model calls и tool calls выполняются как Activities. State workflow живет в event-history log на Cassandra, MySQL или Postgres, так что состояние чисто replay'ится между deploy. В public preview интеграция Temporal × OpenAI Agents SDK поставляется с helper'ами OpenAIAgentsPlugin и activity_as_tool, а в разборе agentic sandboxes описано, как форкнуть запущенного агента на другого sandbox provider прямо посреди conversation. Idle workflows не потребляют compute. Но caveat'ы реальны: streaming и voice agents в текущей интеграции не поддерживаются, а LocalShellTool и ComputerTool отключены, потому что не вписываются в distributed model.

Используйте этот shape, когда в run есть настоящие waiting points: human approvals, external callbacks, long sleeps, retries с business rules, deploy windows. Human approval становится durable sleep без потребления compute, а не polling loop.

Код Workflow — это harness. Sandbox обычно живет вне Temporal и вызывается из Activities. Session и checkpoint state схлопываются в event-history log Temporal, а trace visibility дают Temporal UI плюс OpenTelemetry spans на каждом Activity.

4. Sandbox provider per session

Более новый shape. Каждый run агента получает собственную microVM или container от sandbox-as-a-service provider. Harness живет где-то в durable среде; sandbox — disposable execution environment.

Provider Isolation Max session Concurrency Persistence Cold start
E2B Firecracker microVM 1 h Hobby / 24 h Pro 20 / 100 (до 1,100 с add-on) Pause/resume, ~4 s/GiB pause, ~1 s resume (public beta) ~150 ms p50
Vercel Sandbox Firecracker microVM 45 min Hobby / 5 h Pro/Ent 10 / 2,000 Disposable n/a
Daytona Docker (optional Kata) configurable auto-stop/archive зависит от тарифа Stop → Archive → Delete; fork поддерживается ~90 ms (в некоторых конфигурациях 27 ms)
Modal Sandboxes gVisor типичный lifecycle 1–15 min высокая Volumes для persistence; memory snapshot в preview «около одной секунды» по docs Modal
Runloop Devboxes microVM (custom hypervisor) suspend/resume; snapshot+branch «более 30,000 concurrent instances» по листингу AWS Marketplace Snapshot + branch от состояния диска менее 1 s

Источники: сравнение E2B и Daytona, собственные docs по sandboxes у Daytona и changelog по fork/snapshot, guide по sandboxes у Modal и guide по cold-start, листинг Runloop в AWS Marketplace и pricing Vercel Sandbox. В docs Daytona есть полезное замечание о семантике fork: «новый sandbox полностью независим … Daytona отслеживает связь parent-child в дереве fork». У каждого forked sandbox сохраняется ссылка на базу, от которой он ответвился, так что можно запросить lineage любого derived sandbox. Harness Codex у OpenAI использует per-worktree-вариант: «Codex работает на полностью изолированной версии этого приложения, включая его logs и metrics, которые уничтожаются после завершения задачи.»

Выбирайте этот shape, когда агент выполняет недоверенный код, browser automation, tests или package installs. Компромисс — стоимость и связка с провайдером, обе выше, чем при запуске shared workers.

Provider владеет только sandbox. Harness, session, checkpoint и trace остаются на вашей стороне, обычно как wiring варианта queue + worker из пункта #2.

5. Anthropic Managed Agents (hosted harness)

Запущены в public beta 8 апреля 2026 года, за beta header managed-agents-2026-04-01. Claude тарифицирует Managed Agents по стандартным token rates плюс $0.08 за session-hour. Биллинг помиллисекундный и применяется только пока status session — «running». Idle time бесплатен; runtime session «заменяет модель биллинга container-hour для Code Execution при использовании Claude Managed Agents». Вы получаете hosted session, harness, sandbox и vault-backed MCP proxy. Разделение brain/hands — это именно то, за что платится wake(sessionId): harness можно reinitialize на новом worker без потери state. Внимательно смотрите на структуру стоимости; runaway retry loop при тарификации по session-hour растет быстрее, чем при тарификации за token.

Читайте caveat'ы. Скидка Batch API не применяется («Sessions are stateful and interactive. There is no batch mode.»). Managed Agents недоступны через AWS Bedrock или Google Vertex AI. Multi-agent coordination и self-evaluation пока остаются в research preview. Lock-in высокий: вы меняете свободу в harness на то, что не запускаете loop сами.

Anthropic хостит все пять примитивов: session, harness, sandbox, checkpoint и trace. Вы отдаете runtime и получаете outputs.

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. Sandbox providers (LangSmith Sandboxes, Daytona, Modal, Runloop или custom) переключаются одним config value. State живет в virtual filesystem с pluggable backend'ами; memory скоупится на user, assistant или обоих. Lock-in ниже, чем у Managed Agents: harness распространяется по MIT-лицензии, instructions используют открытый стандарт AGENTS.md, а сами agents доступны через MCP, A2A и Agent Protocol. См. разбор LangChain runtime-behind-production-deep-agents.

По умолчанию хостятся все пять примитивов, но каждый можно заменить конфигурацией. Sandbox сидит за одним config value. Session и checkpoint живут на virtual filesystem с pluggable backend'ами. Trace идет в LangSmith.

7. Google Cloud Run service или job

У Cloud Run два разных runtime mode, и подходящий вариант зависит от того, как вызывается агент. Services привязаны к HTTP и scale-to-zero между запросами; harness работает как request handler и возвращается, когда run завершен. Jobs работают до полного завершения без HTTP entrypoint; harness работает как one-shot worker, который завершается в конце задачи. Оба могут хостить harness, но ни один не сохраняет state между run. Sessions и checkpoints должны жить в Postgres, Spanner или аналогичном внешнем store.

Жесткие лимиты у них очень разные. Timeout request в Cloud Run service: по умолчанию 300 s, максимум 3,600 s (60 min). У WebSockets тот же timeout. Cloud Run jobs: по умолчанию 10 минут на task, максимум 168 h (7 дней); для task с GPU максимум 1 час. Services scale-to-zero, если не включить always-on CPU; jobs не имеют HTTP и не autoscale'ятся.

Используйте service для synchronous run до 60 минут. Используйте job для более длинной one-shot или async работы. Cloud Run Jobs могут держать task живой днями, но не дают durable replay между deploy, сменами версий или заменой worker. Для задач длиннее 7 дней Cloud Run не подходит.

Cloud Run хостит harness. Session, checkpoint, sandbox и trace — это внешние сервисы, которые вы подключаете сами: обычно Postgres или Spanner для session/checkpoint, сам container как sandbox и Cloud Logging плюс OpenTelemetry для trace.

8. AWS Lambda (почему это не тот инструмент)

Максимальный timeout функции Lambda — жесткие 900 s (15 минут). API Gateway добавляет сверху отдельный лимит в 29 s. Agent harness, у которого минимально полезный run — это «минуты или часы», не может жить на Lambda без внешнего state store и стратегии re-invocation, которая по сути заново собирает shape queue + worker с нуля. Используйте Lambda для отдельных tool calls — например, file fetch или upload в S3 — которые вызываются более долгоживущим orchestrator. Но не размещайте orchestrator там.

В лучшем случае Lambda удерживает один tool call в своем 15-минутном лимите. Harness, session, checkpoint, sandbox и trace должны жить где-то еще.

9. AWS ECS / Fargate task per run

Жестко задокументированного лимита по времени работы task нет (в отличие от Lambda). По Fargate throttling quotas запуск ограничен по rate: burst 100, пополнение по 20 в секунду, при этом on-demand и spot учитываются по отдельным бюджетам 20/sec. ECS service quotas: services с AWS Cloud Map service discovery ограничены 1,000 task на service; теоретический потолок — 5,000 EC2 instances на cluster. Fargate требует режим awsvpc, так что каждый task получает собственный network interface и private IP — именно то, что нужно, если вам нужен доступ к внутренним данным в VPC. Fargate Spot доступен; закладывайтесь на interruption. Durability полностью на вас: встроенного replay как в Temporal нет.

Fargate хостит harness и дает каждому run собственный sandbox: один task на run. Session, checkpoint и trace уходят во внешние сервисы. Обычно выбирают RDS или DynamoDB плюс CloudWatch/X-Ray.

10. Kubernetes Job или namespace per session

Подходит, если вы уже эксплуатируете Kubernetes и хотите sandbox-per-session с cluster-wide controls. Плохо подходит, если вам нужен startup меньше секунды, потому что pull контейнерного image и инициализация pod занимают слишком много времени при cold start. Типовой паттерн — один Job на каждый agent run, с activeDeadlineSeconds, PersistentVolumeClaim для workspace и sidecar для MCP server. Crash recovery придется строить самостоятельно. Переходить на Kubernetes только ради hosting агентов дорого по конфигурационному и операционному overhead. Имеет смысл только если вы уже используете K8s по другим причинам.

K8s хостит harness и sandbox, обычно как один Job на run, а иногда и с выделенным namespace для более сильной изоляции. Session и checkpoint живут во внешней DB или на PersistentVolumeClaim. Trace уходит в тот observability stack, который уже работает у вас в кластере.

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

Reference-вариант для следующего раздела. Смысл этого shape в том, что он one-for-one повторяет production topology (те же примитивы, та же сетевая форма), но работает на одной машине. Перед тем как отправлять что-то похожее в production, прочитайте список «not production-safe» в конце следующего раздела.

Compose повторяет shape #2 на одном host. Postgres хранит session и checkpoint. Worker container — это harness. Mount workspace — это shared sandbox. Опциональный OpenTelemetry stack — это trace.

Reference stack: Docker Compose

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

Reference topology Docker Compose

Единственный фрагмент, который стоит показать inline, — canonical wiring в LangGraph. Это самый маленький конкретный пример примитива checkpoint:

from langgraph.checkpoint.postgres import PostgresSaver

DB_URI = "postgresql://agent:${POSTGRES_PASSWORD}@postgres:5432/agent"
with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()  # creates tables on first run
    graph = builder.compile(checkpointer=checkpointer)

Observability, которая переживает run

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

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

Structured event log (чтение после run)

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

OpenTelemetry GenAI traces (чтение после run)

Тот же тип пошаговых данных, но в виде spans со стандартными атрибутами из semantic conventions gen_ai.*: имя модели, provider, количество input и output токенов, conversation ID, имя workflow (статус Development по состоянию на v1.36.0). Provider-specific fields живут в подпространствах (anthropic.*, openai.*), ключом для которых служит gen_ai.provider.name. Причина использовать стандарт — portability: один и тот же trace будет корректно отображаться в Tempo, Jaeger, Honeycomb или LangSmith без переinstrumentation кода при каждой смене backend.

Tool-call timeline плюс workspace diffs (чтение во время run)

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

Ephemeral stack per worktree (читается самим агентом во время run)

Согласно посту OpenAI о harness: «Logs, metrics, and traces are exposed to Codex via a local observability stack that's ephemeral for any given worktree.» Каждый worktree агента получает свой короткоживущий Loki + Prometheus + Tempo, ограниченный только этим run. Агент запрашивает его по ходу работы. Именно это позволяет prompt'у вроде «ни один span в этих четырех user journeys не должен превышать две секунды» превратиться в то, что агент может проверить напрямую, а не угадывать.

(Reviewer с fresh context из таблицы failure modes читает эти артефакты, чтобы решить, достигнуто ли «done». Он относится к evaluation, а не к observability; см. § healthy run lifecycle. Но зависит от всех поверхностей выше.)

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

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

  1. OpenTelemetry Collector с GenAI processor и attribute filter по gen_ai.*.
  2. Tempo (или Jaeger) для traces, с ключами gen_ai.conversation.id / thread_id.
  3. Loki для structured event-log entries.
  4. Prometheus для gen_ai.client.token.usage, gen_ai.client.operation.duration, gen_ai.server.time_to_first_token (см. GenAI metrics conventions).
  5. Grafana dashboards с ключами gen_ai.agent.name и gen_ai.request.model.

Hosted alternatives (берите один, а не три):

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

Instrument the LangGraph node

# 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", "claude-sonnet-4-5")
span.set_attribute("gen_ai.response.model", "claude-sonnet-4-5")
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.

Три запроса, которые вам реально нужны

# Loki: token usage per agent over 1h
sum by (gen_ai_agent_name) (
    rate({service_name="market-analyst-agent"} | json | unwrap gen_ai_usage_output_tokens [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 }

Паттерн debug bundle

Когда run падает, worker должен сохранить /workspaces/${THREAD_ID}/_debug/ с артефактами, которые вы запросили бы на postmortem:

  • session.jsonl: полный dump event-log из PostgresSaver (checkpointer.list({"thread_id": ...})).
  • last_state.json: StateSnapshot.values с последнего успешного super-step.
  • trace.json: spans run, экспортированные в OTLP.
  • 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 files, написанные агентом.
  • env.txt: image tags, версия модели, commit SHA harness.

Именно этот bundle нужен человеку (или другому агенту), чтобы понять, что произошло. Без него каждый failed run — это догадка. «Агент застрял» — слишком расплывчато. Полезный отчет о сбое выглядит скорее так: session s_123 потратила 71 процент токенов в retry loop из трех команд после того, как npm install завершился ошибкой.

Выбор правильного shape: руководство по принятию решения

Большая часть сравнения выше сводится к нескольким решениям.

Начинайте с длины run

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

  • До 30 секунд, идемпотентно: SDK в app server на жизненном цикле request.
  • От 30 s до 60 min, без необходимости crash recovery: queue + worker + checkpoint DB.
  • От 60 min до 24 h: тот же queue + worker или Cloud Run Job для one-shot работы. Если дополнительно нужны versioning и replay — durable workflow engine.
  • Больше 24 h и должен переживать deploy: durable workflow engine (стиль Temporal). Cloud Run Jobs могут держать долгую работу до своего task limit, но не дают replay semantics.
  • Многодневные RL training loops: K8s Job + volume + Temporal.

Когда длина run определена, остальное уже вопрос выбора платформы.

Соответствие платформ use case'ам

Соответствие платформ use case'ам

Матрица намеренно плотная: одиннадцать shapes и множество типов workload в одном представлении. Почти любое ее прочтение определяется двумя паттернами.

Deep Agents Deploy — единственная колонка, где все строки зеленые. То есть это единственный shape в списке, который подходит для всех типов workload, которые отслеживает матрица: короткие run, многочасовые run, code agents, research agents, scheduled jobs. Эта широта — самый сильный аргумент в его пользу. Компромисс — зрелость. Harness вышел недавно, и вокруг него меньше production track record, чем вокруг более старых альтернатив вроде queue + worker + Postgres stack, который команды эксплуатируют годами. Если ваше главное ограничение — «поддерживать все типы workload без re-platforming», принимайте меньшую зрелость и выбирайте Deep Agents Deploy. Иначе предпочитайте shape, который вы уже умеете эксплуатировать.

Anthropic Managed Agents либо полностью подходит под ваш workload, либо не подходит вообще. У продукта три жестких ограничения: только hosted, только Claude, и менее 24 часов на session. Если ваш workload удовлетворяет всем трем — например, это внутренний coding agent, который работает рывками по 2–6 часов, и вы не хотите сами эксплуатировать harness, — Managed Agents отлично подходит и снимает с команды большой кусок platform work. Если хотя бы одно ограничение нарушается — вам нужна не-Claude модель, self-hosted compliance или run на 48 часов, — Managed Agents не подходит. Никакая конфигурация этого не изменит.

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

Hosted harness против owned harness

Различие здесь операционное, а не в том, кто написал код harness. Hosted значит, что vendor запускает harness loop в своей инфраструктуре, а вы вызываете API. Owned значит, что loop работает на вашей инфраструктуре, даже если сам код harness пришел от vendor.

LangChain фигурирует по обе стороны этой границы, и это часто путает. Они делают LangGraph — MIT-licensed library, которую вы self-host'ите (owned), и Deep Agents Deploy — managed product, который по умолчанию запускает harness Deep Agents на LangSmith Deployment в облаке (hosted). Та же компания, две разные operating model. Вы выбираете модель, а не vendor. (У Deep Agents Deploy есть и self-hosted mode для команд, которым нужна ergonomics harness без облачной части; этот mode уже относится к owned.)

Выбирайте hosted harness, когда у вас нет platform capacity, а ограничения vendor вам подходят. Managed Agents означает только Claude. Deep Agents Deploy в cloud mode означает LangSmith в production. Взамен vendor берет на себя caching и compaction.

Owned harness (LangGraph, Deep Agents Deploy в self-hosted mode или custom harness поверх SDK) — правильный выбор, когда у вас есть platform engineers, когда вам нужно итерировать shape harness быстрее, чем vendor выпускает обновления, когда compliance требует data residency под вашим контролем, или когда multi-model routing across providers не обсуждается. Платите вы за это pager'ами и большей операционной surface area.

Большинству команд стоит начать с hosted, измерить, что именно нужно менять, и переходить на owned только тогда, когда ограничения hosted действительно начинают мешать.

Hosted sandbox против Docker / Fargate sandbox

Выбирайте hosted sandbox, когда критично время создания sandbox (меньше 200 ms), нужен pause/resume session с memory state или требуются semantics fork/branch. Выбирайте Docker или Fargate, когда вы уже платите за этот compute, нужен доступ изнутри VPC к чувствительным источникам данных или есть жесткие ограничения по data residency.

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

У долгоживущих агентов обычно одновременно работают не один, а три state store, и каждый хранит свой тип state. Git хранит state workspace: код, документы и progress files, которые изменяет агент. Каждый commit дает harness стабильную recovery point и дает следующей session компактную историю для inspection. Checkpoint DB хранит graph state harness: что было решено, какие nodes выполнились, какие results вернулись и что запускать следующим. Именно это позволяет следующему worker возобновить run из середины. Artifact store хранит большие конечные outputs, такие как PDF, parquet files и screenshots. Им не место ни в git, ни в checkpoint DB.

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

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

Так git становится recovery surface для редактируемого артефакта, но не заменой checkpoint DB. Git может ответить на два вопроса: что изменилось и какая версия прошла tests. Он не может сказать harness, какой graph node запускать следующим, какой tool call ждет approval или какой retry уже использовал свой idempotency key. Harness Anthropic использует initializer commits плюс per-feature commits как source of truth для восстановления workspace; модель читает git log --oneline -8, чтобы восстановить state. Пропускайте git, если work product — это один conversational answer. Overhead того не стоит.

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

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

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

Object storage нужно в трех ситуациях. Во-первых, когда output больше нескольких сотен KB. Checkpoint DB не рассчитаны на большие blobs, и попытка хранить их там делает болезненными и саму DB, и формат checkpoint. Во-вторых, когда downstream consumers — BI tools, клиенты или другие сервисы — должны получать URL-addressable artifacts напрямую, без прохождения через агента. В-третьих, когда retention window для state run и retention window для deliverable расходятся. Session log можно удалить через 30 дней, а финальный report хранить годами. Ключуйте layout по (thread_id, checkpoint_id, artifact_name), чтобы всегда можно было восстановить, какой run произвел какой artifact.

Когда добавлять human approval gates

Добавляйте gates, когда tool call разрушительный и необратимый (записи в DB, движение денег, отправка внешних коммуникаций), когда tool call выходит за blast radius агента (production deploy, customer-facing publish) или когда review требуют регуляторы. interrupt() в LangGraph и approval middleware в Deep Agents имеют встроенную поддержку таких gate. В Части 4 уже разбиралось, почему эти gates — concern permissions, а не prompt.

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

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

  1. Какой store владеет session events и checkpoints?
  2. Что происходит, если worker умирает посреди tool call?
  3. Может ли один run повредить workspace другого run?
  4. Какие действия требуют approval?
  5. Может ли модель или sandbox читать raw credentials?
  6. Какие tool calls можно безопасно retry?
  7. Где enforced per-run cost cap?
  8. Какая проверка с fresh context определяет «done»?
  9. Где живут финальные outputs после исчезновения sandbox?
  10. Можем ли мы завтра объяснить failed run, не перезапуская его?

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

Ключевые выводы

  1. Долгоживущим агентам нужен runtime, а не просто увеличенный HTTP timeout. Runtime держит session, workspace, результаты tool calls, checkpoints, traces, budgets, approvals и credentials вне памяти модели.
  2. Ключевые компоненты — это session, harness, sandbox, checkpoint и trace. Policy checks и secret brokering проходят поперек всех них.
  3. Первый вопрос при deployment — длина run. 20-секундный helper может жить в app server. Шестичасовому coding или research run нужны queue, worker, durable state и стратегия sandbox.
  4. Queue + worker + checkpoint DB — практический дефолт, если вы хотите владеть runtime сами. Hosted harness вроде Anthropic Managed Agents или Deep Agents Deploy лучше, когда вас устраивают ограничения vendor и вы не хотите сами эксплуатировать loop.
  5. Инструментам с side effects нужны idempotency keys. В queue и workflow engines retry — нормальное явление. Без deduplication retry может отправить одно и то же письмо, создать один и тот же PR или дважды списать деньги с клиента.
  6. Observability должна переживать worker. Для failed six-hour run полезные артефакты — это event log, последний checkpoint, trace, timeline tool calls, diff workspace, screenshots и metadata окружения.
  7. Runtime-предположения стареют вместе с изменением моделей. Перепроверяйте context resets, evaluator patterns, tool surfaces и budget rules при смене моделей или harness.
  8. Secrets должны оставаться вне harness и вне model context. Агент получает capability инструмента, а не raw credentials.

Ссылки

Инженерные разборы

LangGraph и Deep Agents

OpenAI Agents SDK

Temporal

Платформа Anthropic

Провайдеры sandbox

Timeout и quotas облачных платформ

Observability

Серия

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