2026-05-26 · Обновлено 2026-07-22

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

Долгосрочная работа ИИ-агент Рантайм в 2026 году: Сессии, Сэндбоксы, Чекпоинты и механизмы её оптимизации

Часть 5 из серии «Инженерия стека Агентный»

В предыдущих четырёх постах рассматривалась внутренняя архитектура агента: ризонинг циклы, память, tool use, и безопасность. В данной статье рассматривается механизм рантайм, обеспечивающий непрерывную работу указанных компонентов в условиях длительных сбоев сессии и ошибок в работе процессов.

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

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

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

Используйте рантайм в качестве единицы проектирования для агентов с длительным временем выполнения. Если невозможно четко указать местоположение каждого примитива, такой агент по-прежнему остается прототипом.

Длительные запуски нарушают предположения о безсостоянийных процессах

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

Команда OpenAI Codex сообщает о длине последовательности в своем харнесс-инжиниринг описание:

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

Инженерная команда Anthropic описывает соответствующую проблему состояния в Эффективные механизмы управления для агентов с длительным временем выполнения:

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

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

сессия должен находиться вне процесса рабочего элемента. Постоянно доступное хранилище фиксирует вызовы модель, результаты работы инструментов и подтверждения, что позволяет другому рабочему элементу возобновить работу с последней безопасной точки после сбоя. Чекпоинты также обеспечивает возможность для рантайм запустить новый цикл модель сессия при заполнении контекстное окно, без необходимости воспроизведения всей истории операций. Формулировки от Anthropic, харнесс экземпляры становятся временными и подлежащими перезапуску; постоянное состояние хранится в другом месте.

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

Пять примитивов рантайм, необходимых любому долгоживущему ИИ-агент

Anthropic’s Масштабирование управляемых агентов В данном описании представлен полезный набор терминов, относящихся к пяти ответственностям рантайм. харнесс обеспечивает движение агента вперед, сессия фиксирует совершённые им действия, а сэндбокс выполняет команды. чекпоинт передаёт следующему элементу работы точку возобновления обработки; трейс сохраняет доказательства для последующей диагностики. Реализация может объединять компоненты, однако ответственности и границы сбоев всё равно требуют наименований.

Сессия. Лог с записью только в добавление, содержащий информацию обо всем, что произошло: вызовы модель, tool calls, результаты, ошибки, утверждения. Восстановление wake(sessionId) → getSession(id) → resume from last event. В LangGraph это реализуется через thread_id плюс механизм проверки данных в Postgres (см. Персистентность LangGraph). OpenAI Agents SDK поставляет десять встроенных сессия бэкенды, включая SQLiteSession, RedisSession, SQLAlchemySession, MongoDBSession, и EncryptedSession (см. раздел) документация к Сессии).

Харнесс. Цикл оркестрация. Он вызывает модель, парсит tool calls, выполняет полученные операции, записывает результаты обратно в сессия и применяет правила повторных попыток. Компания Anthropic излагает суть дела кратко:

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

Команда Codex в OpenAI называет эту дисциплину harness engineering: разработка программного обеспечения по‑прежнему требует строгого соблюдения правил, однако теперь больше усилий вкладывается в создание структурной основы, чем в сам код. LangGraph’s CompiledStateGraph, глубокие агенты create_deep_agent, И сам Claude Code в этом смысле также является одним из таких инструментов.

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

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

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

Постоянное приостановление сэндбоксы позволяет сохранять файловую систему и снапшот в памяти между запусками. Это позволяет при следующем возобновлении работы избежать полной загрузки ОС. Механизмы снимка состояния или форкования создают копию типа «копирование при записи» на основе заранее подготовленного родительского образа, благодаря чему множество задач могут использовать установленные зависимости и готовые кэши, не делясь при этом своими изменяемыми данными.

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

Чекпоинт. Режим возобновления работы. В реализации LangGraph PostgresSaver записывает StateSnapshot на каждой границе супершага, при записях, специфичных для конкретной задачи checkpoint_writes Благодаря этому успешные результаты работы узла не пересчитываются при сбое одного из его собратьев. снапшот представляет собой словарь, сериализуемый в формате JSON.v, ts, id, channel_values, channel_versions, versions_seen, pending_sends) задокументировано в langgraph-checkpoint-postgres страница PyPI и LangGraph чекпоинты ссылка.

Трейс. Интерфейс для воспроизведения и отладки. Каждый вызов модель, tool call и шаг дочернего агента превращается в спан, содержащий информацию о времени выполнения, входных данных, выходных результатах, количестве токен операций и затраченных ресурсах. При сбое шестичасовой задачи именно трейс позволяет определить причину неудачи, поскольку вывод терминала после завершения работы уже давно утерян. Это особенность OpenTelemetry’s Семантические конвенции генеративных ИИ стандартизировать имена атрибутов (какой модель, какой поставщик, сколько токены, какой диалог, какой рабочий процесс), чтобы один и тот же трейс корректно отображался в Темп, Jaeger, Сотовая структура, или LangSmith без повторной настройки инструментария.

Политика и секреты представляют собой отдельные рантайм границы

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

Механизм политик

Перед каждым tool call выполняется проверка прав, которая определяет, будет ли операция выполнена. В производственных средах часто применяются два подхода. Механизм Deep Agents позволяет каждому подагенту указать, какие пути к файлам он имеет право читать или записывать, при этом промежуточный слой блокирует любые запросы, выходящие за рамки этих указаний. В свою очередь, решение Anthropic Managed Agents заключается в том, что каждый tool call направляется через прокси MCP, что позволяет именно прокси обеспечивать соблюдение правил доступа вместо кода агента. Когда для выполнения чувствительного запроса требуется одобрение человека, система LangGraph’s interrupt() А механизм подтверждения Deep Agents приостанавливает обработку графа до тех пор, пока человек не даст согласие.

Секретный брокер

модель не должен иметь доступа к секретам длительного хранения, и сэндбокс обычно тоже не должен этого делать. В качестве примера следует взять паттерн Managed Agents:

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

В рамках market-analyst-agent стек ссылок: боковой процесс MCP считывает данные OAuth токены из секрета Docker (в продакшене, HashiCorp Vault) и выдает на рабочий процесс LangGraph лишь пользовательский интерфейс инструмента. Сам процесс никогда не имеет доступа к токен. git push Работает. cat ~/.ssh/id_rsa нет.

Postgres Это может охватывать сессия и чекпоинт. Контейнер рабочего процесса представляет собой харнесс. Служба подобная этому Дейтона, модальный объект, или E2B обеспечивает сэндбокс, при этом Темп или LangSmith хранит трейс.

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

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

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

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

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

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

В каждой строке присутствуют две идеи. Anthropic рассматривает проблему устаревания харнесс Харнесс — подход к разработке приложений с длительным временем выполнения:

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

Vercel, в связи с аналогичной проблемой чрезмерного количества инструментов, формирующих слишком множество предположений, Мы удалили 80% инструментов нашего агента.:

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

Согласно отчёту Vercel по типичному запросу, показатель успешности вырос с 80% до 100%, а худший сценарий сократился с 724 секунд на 100 шагов при количестве элементов 145 463 токены (ошибка) до 141 секунды на 19 шагов при количестве элементов 67 483 токены (успех). Вывод заключается не в том, что нужно «удалять свои инструменты», а в том, что каждый примитив в вашем рантайм, включая сам интерфейс инструмента, имеет период полураспада. Необходимо повторно проверять эти предположения при изменении модель.

Cognition обнаружил тот же движущийся цель на длине сессия с использованием Sonnet 4.5. В Перепроектирование Devin для Claude Sonnet 4.5 Они описывают модель, который проактивно выполняет запись. SUMMARY.md / CHANGELOG.md Поскольку система распознаёт исчерпание ресурсов контекста, но недооценивает количество токены, которое у неё ещё осталось. Их решение заключается в активации бета-версии с лимитом в 1 млн токен и ограничении объёма использования до 200 тыс., чтобы модель по-прежнему считал, что у него есть запас прочности. Однако со временем и это средство смягчения эффектов также превратится в бесполезный вес.

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

Жизненный цикл здоровой сессии выполнения

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

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

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

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

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

Оценка должна включать доказательства, полученные вне контекста их генерации. Использование свежего эвалуатор снижает смещение, обусловленное общим контекстом, в то время как тесты, инструменты проверки кода, тестирование в браузере и верификация схемы обеспечивают детерминистичные доказательства. Эта проверка может вернуть pass, fail, или needs_human. Для кодовых агентов ревизором может выступать другой модель сессия с инструментами только для чтения. В случае агентов, обрабатывающих данные и отчёты, необходимо сочетать детерминистическую верификацию с участием ревизора модель, чей опыт позволяет принимать окончательные решения.

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

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

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

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

1. SDK внутри сервера приложений (синхронный, с ограничением по запросу)

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

2. Очередь + рабочий процесс + чекпоинт БД

Это значение по умолчанию, которое я рекомендую для большинства команд, а также та версия, что используется в продакшене. market-analyst-agent: работник на Python с механизмом проверки указателя в PostgreSQL, Redis Streams (или) RabbitMQ) Для входящей очереди предусмотрен специальный MCP sidecar, предназначенный для размещения инструментов. Такая архитектура отлично подходит для задач с временем выполнения от 10 минут до нескольких часов, при этом шаги в рамках процесса являются идемпотентными. Локальный запускатель позволяет обойти очередь в целях синхронной разработки, однако в режиме производства очередь становится неотъемлемой частью системы, когда требуется асинхронная передача заданий и реализация механизмов бэкпрессура.

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

В данной архитектуре исполняющим элементом выступает харнесс. Его контейнер и рабочее пространство каждой нити образуют границы выполнения, однако ненадёжному коду по‑прежнему требуется усиленная среда сэндбокс или виртуальная машина. Система Postgres отвечает за управление состоянием сессия и чекпоинт. Запросы Трейсы проходят через OpenTelemetry к той стековой структуре observability, которая используется в текущей среде.

3. Механизм рабочего процесса с высокой устойчивостью (стиль Temporal)

Код агента оркестрация выполняется внутри временного рабочего процесса; вызовы модель и операции tool calls реализуются в виде отдельных активностей. Состояние рабочего процесса хранится в журнале истории событий, поддерживаемом базами данных Cassandra, MySQL или Postgres, что обеспечивает чистую реконструкцию состояния при каждой развертке. Версия с публичным превью Интеграция модуля Temporal с агентами OpenAI SDK отправляет OpenAIAgentsPlugin и ещё один activity_as_tool вспомогательный компонент, а также описание агентный сэндбоксы описывает процесс перенаправления работающего агента на другого поставщика сэндбокс в ходе диалога. Рабочие потоки в состоянии ожидания не потребляют никаких вычислительных ресурсов. Однако существуют важные ограничения: в текущей версии интеграции не поддерживаются агенты для стриминга контента и обработки голосовых команд. LocalShellTool и ComputerTool Они отключены, поскольку не соответствуют архитектуре распределённого модель.

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

Код рабочего процесса представляет собой харнесс. сэндбокс обычно находится вне структуры Temporal и вызывается из составляющих Activities. Состояния Сессия и чекпоинт сохраняются в журнале событий Temporal, тогда как видимость трейс обеспечивается интерфейсом Temporal в сочетании с OpenTelemetry спаны в каждом Activity.

4. Провайдер Сэндбокс в рамках сессия

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

Таблица объединяет Сравнение E2B и Daytona, Daytona’s документация сэндбоксы и форк/снапшот Хроника изменений, модальность сэндбоксы и ситуация холодного запуска руководства, Страница каталога AWS Marketplace для Runloop, и ценообразование Vercel Сэндбокс.

Daytona фиксирует связь «родитель — потомок» для каждого независимого форк, что позволяет сохранять историю происхождения генерируемых сэндбоксы. Система харнесс в Codex от OpenAI использует вариант, ориентированный на отдельный worktree: «Codex работает с полностью изолированной версией данного приложения, включая его журналы событий и метрики, которые удаляются сразу после завершения соответствующей задачи».

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

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

5. Управляемые агенты Anthropic (хостинг харнесс)

Anthropic выпустила Managed Agents в публичной бета-версии 8 апреля 2026 года, ограничив доступ к ней managed-agents-2026-04-01 beta-заголовок. Сервис предоставляет хостинговый прокси сессия, харнесс, сэндбокс, а также прокси, обеспечиваемый защитой из хранилища MCP. wake(sessionId) Возможно инициализация харнесс на новом рабочем процессе без потери устойчивого состояния сессия.

Claude взимает плату с управляемых агентов по стандартным тарифам токен плюс 0,08 доллара за каждый час работы сессия. Оплата производится с точностью до миллисекунд и применяется только тогда, когда статус сессия равен «running»; время бездействия не оплачивается. Поэтому неконтролируемый цикл повторных попыток увеличивает сумму расходов на сессия за час сверх стоимости, уже связанной с токен.

Прочитайте примечания. Скидка для пакетных операций API не применяется («Сессии являются состоянийзависимыми и интерактивными инструментами; режим пакетных операций отсутствует»). Сервис Managed Agents недоступен через AWS Bedrock или Google Vertex AI. Multi-agent координация и самооценка пока находятся в стадии исследовательского превью. Уровень «закрепления» высок: при этом приходится идти на компромиссы. харнесс свобода от необходимости вручную запускать цикл.

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

6. Развертывание глубоких агентов LangChain (управляемый облачный харнесс)

deepagents deploy пакеты deepagents.toml в формат LangSmith Деплой с поддержкой надёжной эксплуатации, управления памятью, многоклиентской архитектуры, режима участия человека, observability, изолированной выполнения кода и запланированных задач. Поддерживаются режимы работы в облаке, гибридном формате и локально на сервере деплой. Провайдеры Сэндбокс (LangSmith Сэндбоксы, Daytona, Modal, Runloop или пользовательские решения) можно менять с помощью одного параметра конфигурации. Состояние системы хранится в виртуальной файловой системе с возможностью подключения различных бэкенды; объём памяти определяется для отдельного пользователя, ассистента или для обоих. Уровень привязки к конкретному решению ниже, чем у Managed Agents: харнесс распространяется под лицензией MIT, а инструкции соответствуют стандартам открытого программного обеспечения. AGENTS.md стандартный вариант; агенты предоставляются через MCP, A2A и Agent Protocol. См. документацию LangChain. рантайм — глубокие агенты, работающие в режиме за кулисами продакшена отчёт.

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

7. Служба или задача Google Cloud Run

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

Критические ограничения в этих двух случаях сильно отличаются друг от друга. Время ожидания запроса к сервису Cloud Run истекло: Значение по умолчанию — 300 секунд, максимальное значение — 3 600 секунд (60 минут). WebSocket’ы установить такой же таймаут. задания Cloud Run: По умолчанию время выполнения задачи составляет 10 минут, максимальный лимит — 168 часов (7 дней); для задач, использующих GPUs, максимальный лимит — 1 час. Сервисы сокращают свою нагрузку до нуля, если не включена функция постоянной активности CPU; задания не имеют интерфейса HTTP и не подвергаются автоматическому масштабированию.

Для синхронных задач продолжительностью до 60 минут используйте сервисы типа «синхронный запуск». Для более длительной однократной обработки или асинхронных операций применяйте механизмы заданий. Cloud Run Jobs позволяют поддерживать выполнение задач в течение нескольких дней, однако они не обеспечивают возможности повторного запуска после обновлений версий, замены рабочих процессов или других изменений в инфраструктуре. При сроках выполнения свыше 7 дней не рекомендуется использовать Cloud Run.

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

8. AWS Lambda (почему это неподходящий инструмент)

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

В течение своего временного окна в 15 минут Lambda может хранить не более одного tool call. харнесс, сессия, чекпоинт, сэндбокс и трейс вынуждены размещаться в других местах.

9. Количество задач AWS ECS / Fargate на один запуск

В документации Fargate не указано жесткого лимита по количеству задач рантайм, в отличие от Lambda. Квоты на сжатие нагрузки Fargate Разрешается начальный пакет запусков в объёме 100 единиц, после чего возобновление запусков происходит со скоростью 20 единиц в секунду; при этом существуют отдельные бюджеты для запусков по запросу и для спот-запусков. квоты сервиса ECS Ограничьте объёмы работы сервисов с помощью механизма обнаружения AWS Cloud Map лимитом в 1 000 задач на сервис, а кластеры, основанные на EC2, — лимитом в 5 000 экземпляров контейнеров.

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

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

10. Задача Kubernetes или пространство имён для сессия

Отлично, когда вы уже работаете с этим. Kubernetes и требуется режим сэндбокс-на-сессия при использовании контроля на уровне всего кластера. Это становится проблемой, когда необходима запускомая скорость в доли секунды, поскольку загрузка образа контейнера и инициализация пода занимают слишком много времени на холодный старт. Схема работы заключается в выполнении по одной задаче для каждого запущенного агента. activeDeadlineSeconds, PersistentVolumeClaim для рабочей среды и sidecar для сервера MCP. Реализацию механизма восстановления после сбоев необходимо разрабатывать самостоятельно. Использование Kubernetes исключительно для размещения агентов сопряжено с высокими затратами из-за сложной настройки и большой нагрузки на операционную часть. Такой подход оправдан лишь в том случае, если вы уже используете K8s по другим причинам.

Kubernetes обеспечивает хранение харнесс и среды выполнения для каждой отдельной задачи, как правило, в виде одного Job, а иногда — в отдельном пространстве имён. Высокий уровень изоляции по-прежнему зависит от класса рантайм, правил сетевого доступа, механизмов безопасности подов, а также от ограничений, налагаемых самим контейнером или виртуальной машиной. Статусы Сессия и чекпоинт сохраняются во внешней базе данных или в объекте PersistentVolumeClaim.

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

Справочный материал для следующего раздела. Смысл использования такой структуры заключается в том, что она однозначно воспроизводит производственную топологию (одинаковые примитивы, идентичная сетевая структура), при этом работая на одном устройстве. Перед выпуском любого подобного решения обязательно ознакомьтесь с списком «не подходит для производственной среды», приведённым в конце следующего раздела.

Создайте зеркала формата #2 на одном хосте. Сервер Postgres поддерживает состояния сессия и чекпоинт, в то время как контейнер рабочего процесса выполняет роль харнесс. Монтирование общего рабочего пространства удобно для разработки, но не обеспечивает изоляции ненадёжных процессов. Опциональная стек-структура OpenTelemetry используется для хранения записей трейсы.

Стек для референса: Docker Compose

исходной топологии, применяемой в slavadubrov/market-analyst-agent, это рабочий процесс LangGraph и механизм проверки целостности данных в Postgres, Qdrant для retrieval, вспомогательного процесса типа MCP, очереди Redis для асинхронных запусков в режиме, максимально приближенном к продакшену, и факультативного Prometheus / Grafana / Локи / Темпо / OTel стек observability. В режиме local compose Redis является необязательным лишь потому, что синхронный запускающий процесс может напрямую вызывать рабочий процесс. docker compose up приводит всю топологию в рабочее состояние локально.

Единственным элементом, который стоит показать внутри текста, является каноническая схема подключения 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"
with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()  # creates tables on first run
    graph = builder.compile(checkpointer=checkpointer)

Observability, сохраняющийся после выполнения

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

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

Структурированный журнал событий (чтение после запуска)

Каждый вызов модель, tool call, а также результаты, ошибки и статусы утверждения записываются в постоянное хранилище с использованием идентификатора сессия и временной метки. После завершения выполнения к этим данным можно обращаться так же, как к обычной таблице базы данных. Addy Osmani чётко устанавливает стандарты в этой области. Долгосрочно работающие агенты: Если невозможно восстановить действия агента за последние 24 часа из надёжного хранилища, то речь идёт о долго выполняемом шелл-скрипте, который случайно вызывает LLM, а не о долго работающем агенте.

OpenTelemetry Генеративный ИИ трейсы (чтение после запуска)

Тот же самый пошаговый набор данных, но выдаваемый в формате спаны с использованием стандартных атрибутов из gen_ai.* семантические конвенции: модель — имя, поставщик, количество входных и выходных данных токен, идентификатор диалога, название рабочего процесса (статус разработки по версии v1.36.0). Поля, специфичные для конкретного поставщика, находятся в подпространствах имён.anthropic.*, openai.*) отключён по ключу gen_ai.provider.name. Причина использования этого стандарта — портабельность: тот же трейс корректно отображается в Tempo, Jaeger, Honeycomb или LangSmith без необходимости повторной настройки инструментов анализа кода при каждой смене бэкенды.

Хронология вызовов инструментов и различия в рабочем пространстве (читается во время выполнения)

Самый быстрый способ узнать, что именно делает агент в данный момент, — это отслеживать результаты его действий в рабочем пространстве, а не перебирать логи сессия. Anthropic’s Харнесс Примитивы для долгосрочной работы агентов Claude В комплекте с инструментом quick-start поставляются два хука для этой цели: watch -n 5 'git log --oneline -8' показывает последние коммиты, совершённые агентом, и watch -n 5 'find screenshots -name "*.png" | tail -5' Отображаются самые свежие скриншоты, сделанные системой. Двух окон терминала, обновляющихся каждые пять секунд, достаточно для определения того, действительно ли процесс выполняется эффективно или просто тратит время впустую.

Временная стековая память для worktree (читается самим агентом во время выполнения)

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

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

Минимальная самостоятельно развернутая стек-сборка observability

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

1. OpenTelemetry Коллектор с процессором GenAI и фильтром атрибутов gen_ai.*.
2. Tempo (или Jaeger) для трейсы, сортируемый по gen_ai.conversation.id / thread_id3. Loki — механизм для хранения структурированных записей журнала событий.
3. Prometheus для gen_ai.client.token.usage, gen_ai.client.operation.duration, gen_ai.server.time_to_first_token (см. раздел) Стандарты измерения показателей генеративных ИИ).
4. Панели Grafana, ориентированные на gen_ai.agent.name и gen_ai.request.model.

Альтернативы с хостингом (выбрать одну, а не три):

• LangSmith: нативная интеграция с LangGraph; а также цель деплой для развертывания Deep Agents. экспертная группа: Наилучший вариант — если приоритетом являются эвал-первые наборы данных для регрессии.
• Arize Phoenix: OSS, работающий нативно с OTLP, интегрируется с OpenInference инструментализация.
• Панель управления трейсинг от OpenAI: автоматическая при использовании агентов OpenAI SDK или их интеграции Temporal.
• Claude трейсинг от Anthropic: предназначен для сессии выполнения внутри управляемых агентов.

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

# 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 Реестр семантических конвенций генеративных ИИ.

Запросы по трем распространённым сбоям

# 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 }

Паттерн пакета для отладки

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

• session.jsonl: полная выгрузка журнала событий из PostgresSaver (checkpointer.list({"thread_id": ...})).
• last_state.json: StateSnapshot.values начиная с последнего успешного супершага. trace.json: Экспортированные в формате OTLP данные спаны за данный запуск.
• tool_calls.csv: (ts, tool, input_hash, latency_ms, status, error).
• workspace.tar.zst: каталог рабочей среды плюс git diff в противовес коммиту с инициализацией. screenshots/*.png: что видел агент.
• PROGRESS.md, feature-list.json, а также любые другие файлы с прогрессом, созданные агентом. env.txt: теги изображений, версия модель, SHA-хэш коммита харнесс.

Этот набор данных предоставляет агенту-человеку или агенту-ревизору достаточно доказательств для воссоздания причин сбоя. Фраза «агент застрял» слишком расплывчата. Примерный отчет содержит конкретику: сессия s_123 потратило 71 процент своего времени на токены — повторение трёх команд. npm install Не удалось.

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

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

Начнём с измерения длины последовательности нулей/единиц

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

• Менее 30 секунд, идемпотентность обеспечена: цикл обработки запроса SDK на сервере приложений.
• От 30 секунд до 60 минут, восстановление после сбоев не требуется: очередь + рабочий процесс + чекпоинт БД.
• От 60 минут до 24 часов: та же очередь + рабочий процесс или задача в Cloud Run для однократной обработки. Для поддержки версионирования и возможности повторного выполнения используйте механизм долговечных рабочих потоков.
• Более 24 часов — необходима стабильность при обновлениях: механизм долговечных рабочих потоков (в стиле Temporal). Задачи Cloud Run могут хранить длительные вычисления до предела объёма задачи, но не поддерживают функцию повторного выполнения.
• Циклы обучения методом RL продолжительностью в несколько дней: задача в K8s + том + Temporal.

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

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

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

Книга «Deep Agents Deploy» охватывает все типы рабочих нагрузок, указанные в матрице, что делает её подходящим решением в ситуациях, когда одна платформа должна обрабатывать как краткосрочные задачи, так и задания продолжительностью в несколько часов, а также кодовые и исследовательские агенты и запланированные операции. Однако такой универсальный подход сопровождается меньшим временем применения на практике по сравнению со стеком «очередь + рабочие процессы + Postgres». Рассматривайте зелёные ячейки как утверждения о возможностях, требующие проверки, после чего сравните операционные ограничения, которые невозможно отразить в матрице.

Управляемые агенты Anthropic подходят для вашей рабочей нагрузки полностью или вообще не подходят. У этого продукта есть три строгих ограничения: он работает исключительно в хостинговой среде, использует исключительно модель Claude, и срок его работы не превышает 24 часа за раз сессия. Если ваша рабочая нагрузка соответствует всем трем условиям — например, это внутренний кодинговый агент, который работает пакетами по 2–6 часов, и вы не хотите самостоятельно управлять харнесс — то управляемые агенты становятся отличным решением, позволяющим существенно сократить объём работы с платформой у вашей команды чанк. Однако если хотя бы одно из ограничений нарушается из-за необходимости использования модели, отличной от Claude, модель, требований к самостоятельной развертке или необходимости работы в течение 48 часов, управляемые агенты не подходят. Никакие изменения конфигурации здесь не помогут.

Перед тем как приступать к реализации, обязательно проведите моделирование стоимости, а не после этого. Стоимость использования сессия в часовом формате составляет 0,08 доллара за час сверх стандартных затрат на токен. Если один сессия будет работать непрерывно, это приведёт примерно к расходам в 58 долларов в месяц на каждый сессия. При работе 100 единиц сессии непрерывно сумма составит около 5 800 долларов в месяц до учёта токенов. Умножьте 0,08 на ожидаемое количество часов одновременной активности сессия, сложите полученную сумму к счету за токен и сравните её с затратами на использование очереди и стека рабочих процессов на собственной инфраструктуре. Сделайте это до начала работы, поскольку переход с Managed Agents позже требует полной замены платформы, а не просто изменения конфигурации.

Хостинговые харнесс против собственных харнесс

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

LangChain встречается с обеих сторон этой строки, из-за чего у пользователей возникают путаницы. Компания предлагает LangGraph — библиотеку под лицензией MIT, которую можно самостоятельно разместить на собственном сервере, а также Deep Agents Deploy — управляемый продукт, в котором Deep Agents харнесс запускается на платформе LangSmith Деплой в режиме работы в облаке по умолчанию (хостингуемом провайдером). Это одна и та же компания, но два разных способа эксплуатации модели. Вы сами выбираете способ модель, а не поставщика. (Deep Agents Deploy также имеет режим самостоятельной установки для команд, желающих получить удобство работы харнесс без использования облачных сервисов; в этом случае решение размещается в категории «собственный сервер».)

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

Хостинговая среда сэндбокс против собственной среды выполнения

Выбирайте хостинговую среду сэндбокс в тех случаях, когда механизмы изоляции провайдера, возможность паузирования/возобновления работ или семантика форк соответствуют уровню угрозы модель и установленным ограничениям по ресурсам при запуске. Docker или Fargate подходят для надёжных внутренних задач, требующих доступа к VPC или строгого соблюдения правил размещения данных, однако стандартный контейнер не обеспечивает достаточной защиты от вредоносного кода. Для предотвращения установки ненадёжных пакетов или выполнения генерируемых программ необходимо использовать gVisor, Kata, микроВМ или другой усиленный рантайм.

Хранилища состояния: Git, базы данных и объектные хранилища рядом друг с другом

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

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

База данных чекпоинт хранит состояние графа: принятые решения, участвовавшие узлы, полученные результаты и список операций, которые необходимо выполнить далее. Хранилище артефактов содержит крупные итоговые файлы, такие как PDF, файлы формата Parquet и скриншоты. Эти артефакты не должны находиться в Git или в базе данных чекпоинт.

Когда использовать git в качестве хранилища состояния

Используйте Git в тех случаях, когда объём работы связан с кодом (редактирование нескольких файлов, рефакторинг, генерация приложений) или документацией, для которой важна история изменений файлов. Схема действий проста: создайте ветку для выполнения задач, сделайте коммит с инициализацией, а затем фиксируйте ключевые этапы — после настройки, после каждой новой функции, после прохождения тестов и после окончательной очистки. Храните SHA-хеш последнего коммита рабочей среды рядом с строкой чекпоинт. При возобновлении работы следующий сотрудник берёт эту ветку и читает git log --oneline -8, осматривает git status а также последняя разница, после чего происходит чтение PROGRESS.md или любой другой файл передачи данных, созданный предыдущей версией сессия.

Это делает Git инструментом для восстановления объекта, находящегося в процессе редактирования, а не заменой чекпоинт базы данных. Git способен ответить на два вопроса: что изменилось и какая версия прошла тестирование. Он не может сообщить харнесс, какой узел графа следует обработать далее, какой tool call ожидает одобрения или какой попытка повтора уже использовала свой ключ идемпотентности. Система харнесс от компании Anthropic использует коммиты инициализации вместе с коммитами по отдельным функциям в качестве источника истины для восстановления рабочей среды; модель считывает git log --oneline -8 для восстановления состояния. Игнорировать Git, если результатом работы является единый ответ в формате диалога — такие затраты не оправданы.

Когда использовать точки контроля БД

Использовать PostgresSaver-стиль контрольных точек, при котором агент обладает графовой структурой с несколькими узлами, промежуточное состояние которых имеет значение (планировщик → исследователь → автор → верификатор). Репозиторий-образец использует именно этот подход по данной причине. Не храните артефакты рабочей среды объемом в терабайты в чекпоинт; такие данные должны находиться в системах объектного хранения.

Когда использовать хранилище артефактов (S3 / GCS)

Используйте объектное хранилище в следующих случаях:

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

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

Когда вводить этапы утверждения человеком

Добавляйте шлюзы в тех случаях, когда tool call сопровождается разрушительными и необратимыми действиями (запись в базу данных, перемещение средств, отправка внешних сообщений), когда tool call покидает зону влияния агента (развертывание в продакшене, публикация контента для клиентов) или когда регулирующие органы требуют проведения проверки. LangGraph’s interrupt() Медиаэлементы утверждения как Deep Agents, так и других подобных решений встроенно обеспечивают поддержку этих шлюзов. Часть 4 Обосновано, почему эти шлюзы представляют проблему с точки зрения разрешений, а не проблему промпт.

Практический чек-лист для продакшена

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

1. Какой хранилище управляет событиями сессия и чекпоинты?
2. Что происходит, если рабочий процесс завершается на полпути выполнения tool call?
3. Можно ли повредить рабочее пространство другого запуска?
4. Какие действия требуют одобрения?
5. Могут ли модель или сэндбокс читать необработанные учетные данные?
6. Какой tool calls может безопасно попытаться выполнить задачу заново?
7. Где применяется лимит стоимости за отдельный запуск?
8. Какая проверка свежего контекста определяет завершение работы?
9. Где хранятся окончательные результаты после завершения работы сэндбокс?
10. Можно ли объяснить причины неудачного запуска на следующий день без его повторной эксплуатации?

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

Следующим слоем является цикл харнесс

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

Список литературы

Технические отчеты

• OpenAI, Харнесс-инжиниринг: использование Codex в мире, ориентированном на агенты.
• Anthropic Engineering, Эффективные механизмы управления для агентов с длительным временем выполнения.
• Anthropic Engineering, Харнесс проектирование для разработки долгоживущих приложений.
• Anthropic Engineering, Масштабирование управляемых агентов: разделение «мозга» и «рук», 8 апреля 2026 года.
• Когнитивные процессы AI, Перепроектирование Devin для Claude Sonnet 4.5: уроки и сложности.
• Vercel, Мы удалили 80% инструментов нашего агента..
• Адди Османи, Долгосрочные агенты.

LangGraph и Deep Agents

• Документация LangGraph Персистентность.
• Ссылка на LangGraph, Чекпоинты.
• langgraph-checkpoint-postgres на PyPI.
• Документация LangChain Обзор Deep Agents.
• Блог LangChain, рантайм, находящийся за линией производства Deep Agents.

Агенты OpenAI SDK

• Агенты OpenAI SDK, Сессии.
• Агенты OpenAI SDK, Сэндбокс концепции.

Временные аспекты

• Временной блог, Представляем Temporal и агентный сэндбоксы: агентов OpenAI SDK.
• Временной блог, Готовые к эксплуатации агенты от OpenAI Agents SDK с поддержкой временных зависимостей.
• Temporal × OpenAI Agents SDK — описание внесения изменений в README (temporalio/sdk-python).

Платформа Anthropic

• Anthropic, Ценообразование на платформе Claude: Управляемые агенты сессия — тарифы за час работы. anthropics/cwc-long-running-agents: Код для работы с Claude 2026 в режиме «take-home», включающий сабагента эвалуатор и шаблоны файлов для отслеживания прогресса.

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

• ZenML, E2B против Daytona: сравнение сэндбокс для инженеров платформ.
• Документация Daytona Сэндбоксы.
• Хроника изменений Daytona, эндпоинты Сэндбокс, форк и снапшот.
• Модальные документации, Сэндбоксы.
• Модальные документации, руководство Холодный старт.
• Runloop в AWS Marketplace.
• Цены и лимиты Vercel Сэндбокс.

Время ожидания и квоты облачной платформы

• Google Cloud, Настроить время ожидания запросов для сервисов.
• Google Cloud, Использование WebSockets.
• Google Cloud, Установите временной лимит выполнения задач для работ.
• AWS, Настроить время ожидания выполнения функции Lambda.
• AWS, квоты Lambda.
• AWS, Квоты на сжатие нагрузки Fargate.
• AWS, Квоты сервиса ECS и лимиты сжатия трафика API.

Observability

• OpenTelemetry, Семантические конвенции для генеративных систем AI.
• OpenTelemetry, Реестр атрибутов генерации AI.
• OpenTelemetry, Семантические конвенции для агента генеративного ИИ и фреймворк спаны.
• OpenTelemetry, Семантические конвенции для метрик генеративных AI.

Серия

• Часть 1: ИИ-агент Ризонинг Циклы в 2026 году: ReAct, ReWOO и подход «планирование — выполнение». Часть 2: ИИ-агент Архитектура памяти в 2026 году: чекпоинты, хранилища векторов и память документов. Часть 3: ИИ-агент Tool Use в 2026 году: MCP, интерфейс командной строки, навыки, выполнение кода и ACI.
• Часть 4: ИИ-агент Безопасность в 2026 году: гардрейлы, права доступа, сэндбоксы, HITL и ограничение области применения MCP.
• Часть 5: Долгосрочные ИИ-агент Рантайм в 2026 году (эта статья) Часть 6: Харнесс-инжиниринг для ИИ-агенты: проверки приемки, трейсы, повторные попытки, передача задач и цикл обработки в рамках модель.

Код агента аналитика рынка (работник LangGraph, механизм проверки целостности данных в Postgres, память базы данных Qdrant, сайдкар MCP, а также описанная выше топология Docker Compose) находится в GitHub._