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

Viacheslav Dubrov

2026-05-26 · Обновлено 2026-08-01 · 34 мин · ИИ-агенты

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

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

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

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

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

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

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

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

Команда OpenAI Codex рассказывает о длительности таких запусков в материале о харнесс-инжиниринге:

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

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

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

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

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

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

Материал Anthropic Scaling Managed Agents предлагает удобную терминологию для пяти задач рантайма. Харнесс двигает агента вперёд, session записывает его действия, а sandbox выполняет команды. Checkpoint даёт следующему worker-у точку возобновления; trace сохраняет свидетельства для последующей отладки. Реализация может объединять компоненты, но задачи и границы отказов всё равно нужно явно назвать.

Session. Append-only лог всего произошедшего: вызовов модели, tool calls, результатов, ошибок и согласований.

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

Model session — самый короткий интервал: один непрерывный фрагмент контекста модели. Compaction — шаг, на котором окно суммируется, чтобы работа могла продолжиться, — продлевает model session, а не завершает её. Перезапуск или намеренный новый старт завершает её. В части 6 термин «model session» используется именно в этом смысле.

В этой статье «session» означает надёжный лог одного запуска. Она находится между двумя другими понятиями: множество model sessions записывает данные в один лог, а один thread накапливает множество логов. Восстановление — это wake(sessionId) → getSession(id) → resume from last event.

В LangGraph восстановление использует thread_id вместе с чекпоинтером Postgres (см. LangGraph persistence). OpenAI Agents SDK поставляется с десятью встроенными бэкендами сессий, включая SQLiteSession, RedisSession, SQLAlchemySession, MongoDBSession и EncryptedSession (см. документацию по Sessions).

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

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

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

«Внешний рантайм по-прежнему отвечает за согласования, трейсинг, handoff-ы и учёт возобновления. Сессия sandbox отвечает за команды, изменения файлов и изоляцию окружения».

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

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

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

Per-worktree сэндбоксы дают каждой задаче собственное рабочее пространство и стек observability. Отдельные логи, метрики и трейсы позволяют отлаживать один запуск, не допуская утечки его состояния в другой. Таблица провайдеров ниже сравнивает поведение холодного старта и сохранение состояния.

Checkpoint. Состояние, из которого можно возобновить работу.

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

Checkpoint — это обычный 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() строит поверх checkpoint. Именно объект, чей .values позже выгружает debug bundle.

Trace. Поверхность для replay и отладки. Каждый вызов модели, tool call и шаг субагента становится спаном с длительностью, входами, выходами, количеством токенов и стоимостью. Когда шестичасовой запуск завершается с ошибкой, trace — это то, что вы читаете, чтобы понять причину. К этому моменту терминальный вывод уже давно исчез. GenAI semantic conventions OpenTelemetry стандартизируют имена атрибутов: какая модель, какой провайдер, сколько токенов, какой диалог и какой workflow. Для совместимого с OTLP назначения, поддерживающего эти соглашения, та же инструментализация может экспортировать trace в такие системы, как Tempo, Jaeger, Honeycomb или LangSmith, хотя могут потребоваться адаптеры бэкенда или специфичная для назначения конфигурация.

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

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

Проверка разрешений

Лестнице разрешений из части 4 нужно место выполнения. Проверка срабатывает перед каждым tool call и решает, пропускать ли его. В продакшене распространены два паттерна. Deep Agents позволяет каждому субагенту объявить, какие пути файлов он может читать или записывать, а middleware блокирует всё за пределами декларации. Anthropic Managed Agents направляет каждый tool call через прокси Model Context Protocol (MCP), поэтому разрешения проверяет прокси, а не код агента. Когда для чувствительного вызова требуется согласование человека, interrupt() LangGraph и approval hook в Deep Agents ставят граф на паузу до получения подтверждения.

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

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

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

В эталонном стеке market-analyst-agent — небольшом LangGraph-агенте, который получает рыночные данные и пишет аналитический отчёт в рамках этой серии, — MCP sidecar хранит API keys провайдера данных и предоставляет LangGraph worker только поверхность инструментов. В локальном compose-файле оба контейнера читают один и тот же .env; это упрощение для разработки, а не рекомендуемый паттерн. В продакшене окружение sidecar поступает из хранилища секретов — Docker secrets или HashiCorp Vault, — к которому worker не имеет доступа. После этого worker вызывает инструмент, ни разу не получая сам credential.

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

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

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

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

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

Отказы делятся на четыре группы:

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

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

В актуальной документации Anthropic по контекстному окну по состоянию на август 2026 года для Sonnet 4.5 по-прежнему указано 200k. Окно 1M поставляется по умолчанию, без beta-заголовка, на Opus 4.6 и более поздних версиях, а также на Sonnet 4.6 и более поздних версиях. Следить стоит именно за ограничением. Оно существует только потому, что Sonnet 4.5 неверно оценивает оставшийся контекст; когда модель перестанет это делать, лимит перестанет быть исправлением и станет искусственным потолком. С момента публикации Cognition сменилось уже не одно поколение моделей; прежде чем использовать эти данные дальше, сверьте их с актуальным списком моделей.

Команда OpenAI, занимающаяся харнессом, формулирует это в одну строку: «Люди направляют. Агенты выполняют». Когда что-то ломается, полезно спросить, какой capability не хватает и как сделать её одновременно понятной и enforceable для агента.

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

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

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

1. Загрузитесь из новой session или возобновите существующую. При возобновлении подключите workspace из последнего известного состояния, прочитайте progress-файлы, оставленные предыдущей попыткой (PROGRESS.md, feature-list.json), и загрузите последний checkpoint из базы данных. Здесь харнесс передаёт агенту всё, что предыдущий worker успел держать в памяти до сбоя.
2. Спланируйте работу до выполнения любых tool calls. Зафиксируйте, что означает «готово», сколько запуску разрешено потратить, какие инструменты агент может вызывать и что должно досрочно остановить запуск. Эти значения плана становятся проверками рантайма; без них выполнению нечему противодействовать.
3. Выполняйте по одному tool call за раз. Проверка разрешений харнесса решает, разрешать ли вызов, затем отправляет его, сохраняет результат и записывает одно событие в лог session. Один шаг — одно событие. Сбой между событиями можно обработать, потому что источником истины является лог, а не память worker-а.
4. Создавайте checkpoint на границах super-step или после каждого события в более простом харнессе. Сохраняйте состояние графа, diff workspace и ссылки на созданные артефакты. Именно этот checkpoint читает шаг 1 при следующем возобновлении. Если checkpoint отсутствует или устарел, восстановление превращается в медленное проигрывание всего лога session с нуля.
5. Когда агент считает работу завершённой, оцените её по артефактам: тестам, evaluator со свежим контекстом, проверке схемы и браузерным проверкам. Если проверка проходит, запуск завершается успешно. Если нет, запуск возобновляется с последнего чистого checkpoint; сообщение об ошибке добавляется в контекст, после чего выполняется новая попытка.

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

Любому инструменту с побочными эффектами нужен idempotency key, производный от ID session и ID tool call и сохранённый до выполнения побочного эффекта. 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). В очередях и workflow-движках по умолчанию используется at-least-once execution, поэтому дубликат неизбежно появится. Если повторный вызов инструмента может причинить реальный вред и его нельзя дедуплицировать по ключу, инструмент ещё не готов для использования агентами.

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

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

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

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

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

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

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

2. Очередь + worker + checkpoint DB

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

Приложение принимает запрос, создаёт строку session, помещает задачу в очередь и возвращает ID запуска. Worker забирает задачу, запускает харнесс, записывает checkpoint, стримит статус и сохраняет артефакты по мере работы. Postgres переживает сбои, worker-ы заменяемы, а глубина очереди обеспечивает backpressure. Spot/Preemptible compute работает, если чекпоинтер завершает запись на диск до сообщения об успехе.

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

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

Код оркестрации агента выполняется внутри Temporal Workflow, а вызовы модели и инструментов — как Activities. Состояние workflow находится в логе истории событий на базе Cassandra, MySQL или Postgres, поэтому корректно воспроизводится после деплоев. Интеграция Temporal × OpenAI Agents SDK, общедоступная с марта 2026 года, поставляется с helper-ами OpenAIAgentsPlugin и activity_as_tool, а в материале об agentic sandboxes описан fork работающего агента на другого sandbox-провайдера прямо во время диалога. Idle workflow не потребляют вычислительные ресурсы. Но ограничения существенны: realtime agents не поддерживаются, streaming всё ещё помечен как experimental, а LocalShellTool и ComputerTool отключены, поскольку не вписываются в распределённую модель.

Используйте эту форму, когда в запуске есть настоящие точки ожидания: согласования людей, внешние callback-и, длительные sleep, retry с бизнес-правилами или окна деплоя. Согласование человека становится надёжным sleep без потребления вычислений, а не polling loop.

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

4. Sandbox provider для каждой session

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

Холодный старт здесь — это end-to-end provisioning, а не чистая загрузка: ~150 мс E2B добавляются к ~125 мс загрузки Firecracker, которые часть 4 приводит для самого гипервизора. Таблица объединяет данные из сравнения E2B и Daytona, документации Daytona по sandboxes и changelog fork/snapshot, руководств Modal о sandboxes и cold start, страницы Runloop в AWS Marketplace и тарифов Vercel Sandbox.

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

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

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

5. Anthropic Managed Agents (hosted harness)

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

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

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

Anthropic размещает все пять примитивов: session, harness, sandbox, checkpoint и trace. Вы передаёте провайдеру рантайм и получаете результаты.

6. LangChain Deep Agents Deploy (managed open harness)

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

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

7. Сервис или job Google Cloud Run

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

Жёсткие лимиты у этих режимов сильно различаются. Таймаут запроса Cloud Run service: по умолчанию 300 с, максимум 3 600 с (60 мин). WebSockets получают тот же таймаут. Cloud Run jobs: по умолчанию 10 мин на task, максимум 168 ч (7 дней); для task-ов с GPU максимум 1 час. Services масштабируются до нуля, если не включить always-on CPU; jobs не используют HTTP и не масштабируются автоматически.

Используйте service для синхронных запусков продолжительностью до 60 минут. Job подходит для более долгой одноразовой или асинхронной работы. Cloud Run Jobs могут поддерживать task в течение нескольких дней, но не обеспечивают надёжного replay после деплоев, смены версии или замены worker-а. После 7 дней Cloud Run использовать не следует.

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

8. AWS Lambda (почему это неправильный инструмент)

Максимальный timeout функции Lambda жёстко ограничен 900 с (15 мин). Если перед функцией стоит API Gateway, лимит интеграции зависит от типа API. HTTP APIs допускают 30 секунд; для REST integrations по умолчанию действует 29 секунд, а Regional и private REST APIs могут настроить больший timeout. Ни один из этих путей не превращает Lambda в многочасовой worker. Долгоживущий харнесс всё равно требует внешнего состояния и повторных вызовов, то есть фактически возвращает нас к форме queue + worker. Используйте Lambda для ограниченных tool calls, например загрузки файлов или отправки объектов в S3, вызываемых долго работающим оркестратором. Не размещайте там оркестратор.

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

9. AWS ECS / Fargate task на каждый запуск

В документации Fargate нет жёсткого ограничения на время жизни task, в отличие от Lambda. Квоты throttling Fargate допускают burst запуска из 100 task-ов и пополнение со скоростью 20 в секунду, с отдельными бюджетами для on-demand и spot. Квоты ECS service ограничивают services с обнаружением через AWS Cloud Map 1 000 task-ами на service, а кластеры на EC2 — 5 000 container instances.

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

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

10. Kubernetes Job или namespace на каждую session

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

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

11. Локальный Docker Compose (только для разработки)

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

Compose повторяет форму №2 на одном хосте. Postgres хранит состояние session и checkpoint, а контейнер worker — это харнесс. Общий mount workspace удобен при разработке, но не изолирует непроверенные запуски. Опциональный стек OpenTelemetry записывает трейсы.

Эталонный стек: Docker Compose

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

Единственная часть, которую стоит показать inline, — каноническая wiring-схема LangGraph. Это иллюстративный фрагмент, а не пример, запускаемый из репозитория. Для его запуска нужны langgraph, langgraph-checkpoint-postgres и psycopg[binary,pool], доступная база PostgreSQL с правом создавать таблицы чекпоинтера, 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-ы легко отлаживать: при сбое вы читаете ответ и live log. У долгоживущих агентов такой возможности нет. К моменту сбоя шестичасового запуска интересное событие произошло пять часов назад, live-вывод терминала исчез, а worker, который его создал, уже заменён. Никто не будет восстанавливать запуск по памяти. Поэтому отладка опирается на надёжные артефакты, записанные, пока запуск ещё выполнялся.

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

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

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

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

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

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

Timeline tool calls плюс diff workspace (читаются во время запуска)

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

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

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

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

Минимальный self-hosted стек observability

Для системы вроде market-analyst-agent:

1. OpenTelemetry Collector с GenAI Normalizer Processor (contrib, alpha) для поддерживаемых GenAI-атрибутов. Используйте стандартные процессоры Attributes или Transform, чтобы фильтровать или переписывать поля gen_ai.*.
2. Tempo (или Jaeger) для трейсов с ключами gen_ai.conversation.id / thread_id.
3. Loki для записей structured 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: лучше всего подходит, если приоритетом являются eval-first regression suites.
• Arize Phoenix: OSS, нативно работает с OTLP (wire protocol OpenTelemetry), сочетается с инструментализацией OpenInference.
• Tracing dashboard OpenAI: автоматически доступен при использовании OpenAI Agents SDK или его Temporal integration.
• Claude tracing Anthropic: для session, выполняющихся внутри Managed Agents.

Инструментируйте узел LangGraph

Это иллюстративный фрагмент, который runner примеров репозитория пропускает. Он предполагает, что у узла LangGraph уже есть активный OpenTelemetry span, текущий thread_id и объект response провайдера usage с input_tokens и output_tokens; настройка tracer, конфигурация экспорта и 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: 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

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

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

Этот bundle даёт человеку или reviewer-агенту достаточно свидетельств для реконструкции сбоя. «Агент застрял» — слишком расплывчато. Конкретный иллюстративный отчёт выглядит так: session s_123 потратила 71 процент токенов на повторение трёх команд после сбоя npm install.

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

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

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

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

• Менее 30 секунд, идемпотентный: SDK в рамках request lifecycle внутри app server.
• От 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 training loops: K8s Job + volume + Temporal.

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

Соответствие платформы варианту использования

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

Deep Agents Deploy — единственный столбец матрицы без красных и жёлтых ячеек: короткие синхронные запуски, многочасовые batch-задачи, fork sandbox, GPU-работа и минимальный lock-in везде отмечены зелёным. Это делает его кандидатом, когда одна платформа должна обслуживать все ваши workload-ы. Но production track record у него короче, чем у стека queue + worker + Postgres. Считайте зелёные ячейки заявленными capabilities, которые нужно проверить, а затем сравните операционные ограничения, не отражённые в матрице.

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

Стоимость нужно смоделировать до принятия решения, а не после. Строка session-hour составляет $0.08/hour on top of standard token costs. If a single session ran continuously, that is about$58 в месяц за session. При 100 постоянно работающих session это около $5,800/month _before tokens_. Multiply$0.08; умножьте эту сумму на ожидаемое число часов одновременных session, добавьте счёт за токены и сравните результат со стоимостью стека queue + worker в собственной инфраструктуре. Миграция с Managed Agents впоследствии станет re-platforming, а не изменением конфигурации.

Hosted harness против собственного харнесса

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

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

Выбирайте hosted harness, если его поддержка моделей, граница данных, поведение восстановления и точки расширения уже подходят. Выбирайте owned harness, если эти ограничения являются требованиями, которые, как вы ожидаете, будут меняться. Миграция между вариантами меняет состояние, observability и границы выполнения, поэтому проверьте путь выхода до того, как production-данные начнут от него зависеть.

Hosted sandbox против собственной среды выполнения

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

Хранилища состояния: Git, DB и object storage рядом

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

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

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

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

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

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

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

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

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

Используйте object storage, если:

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

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

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

Добавляйте gates, если tool call разрушителен и необратим (записи в DB, перемещение денег, отправка внешних сообщений), выходит за blast radius агента (production deploy, публикация для клиентов) или если review требуется регулятором. interrupt() LangGraph и approval middleware Deep Agents имеют встроенную поддержку таких gates. Часть 4 объясняет, почему gates относятся к разрешениям, а не к промптам.

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

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

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

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

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

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

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, Checkpoints.
• langgraph-checkpoint-postgres на PyPI.
• Документация LangChain, Deep Agents overview.
• Блог 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-файлов.

Провайдеры sandbox

• 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, память Qdrant, MCP sidecar и описанная выше топология Docker Compose — доступен на GitHub.