Деплой агентов: принципы, тулы

Материал во важным поинтам и тулам в контексте деплоя агентных систем

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

Стейт
Важно помнить и про стейт - разделять типы состояния, у каждого свои требования:

Правила:

По тулам для оркестрации информация ниже.

Harness

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

Харнессы бывают двух видов: одни являются библиотеками и фреймворками, из которых вы собираете собственного агента, другие готовые агенты с уже встроенным харнессом.

LangGraph - это фреймворк для описания агента в виде графа шагов с сохраняемым состоянием, ветвлением и точками подтверждения со стороны человека. Он подходит там, где поток управления мультиагентной системы должен быть задан явно. https://github.com/langchain-ai/langgraph

Claude Agent SDK открывает тот же цикл, инструменты, разрешения и управление контекстом, которые использует Claude Code, поэтому команда может встроить в свой сервис боевой харнесс для кодинга и не писать цикл с нуля. https://platform.claude.com/docs/en/agent-sdk/overview

OpenAI Agents SDK - это легковесный фреймворк, построенный вокруг агентов, передачи управления между ними, ограничителей (guardrails) и трассировки. https://github.com/openai/openai-agents-python

Google ADK, Agent Development Kit, нацелен на мультиагентные системы: составные агенты и путь к развертыванию в Google Cloud. https://github.com/google/adk-python

OpenHands - open source платформа агентов для кодинга, в которой харнесс и исполнительная среда на базе Docker поставляются вместе. https://github.com/OpenHands/OpenHands

Codex CLI - готовый кодинговый агент со своими режимами песочницы на уровне ОС. В этом случае харнесс может встроить нижний слой и не выставлять его отдельным продуктом. https://github.com/openai/codex

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

Agent runtime

Между харнессом и механизмами изоляции может находиться агентный рантайм, он же исполнитель (executor). Он запускает агента и предоставляет ей среду исполнения через API. Благодаря этому слою разработчику харнесса не нужно поднимать виртуальные машины, готовить файловые системы, запускать процессы и высвобождать ресурсы. Во многих продуктах слой тонкий или слит с соседними, поэтому его лучше читать как зону ответственности, а не как обязательный блок.

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

KAgent это Kubernetes-native фреймворк для запуска агентов кластера: агенты, инструменты и их взаимодействие описываются ресурсами Kubernetes. Он захватывает и уровень харнесса, поэтому его лучше считать платформой, которая охватывает оба слоя. https://kagent.dev/

Temporal обеспечивает durable execution, то есть устойчивое выполнение. Это важно для долгого ранинга агента, которые должны переживать перезапуски, таймауты и сбои воркеров без потери прогресса. https://temporal.io

Amazon Bedrock AgentCore предлагает управляемый рантайм для агентов с изоляцией на уровне сессии, что переносит заботу о рантайме на облачный сервис. https://aws.amazon.com/bedrock/agentcore/

Cloudflare Agents запускает агентов с состоянием на платформе Cloudflare и естественно сочетается с ее предложением по песочницам. https://github.com/cloudflare/agents

Sandbox API

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

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

E2B это платформа песочниц для ИИ перформанса, предлагаемая как управляемый облачный сервис на микроВМ Firecracker. Приложение работает с API более высокого уровня и не касается низкоуровневой инфраструктуры, поэтому харнесс может использовать песочницу как инструмент выполнения кода. https://github.com/e2b-dev/E2B

OpenSandbox - универсальная платформа с SDK для нескольких языков и единым API песочниц. Жизненным циклом она управляет сама и может работать на Docker или на Kubernetes, а для более сильной изоляции ее можно настроить на gVisor, Kata Containers или Firecracker, которые администратор должен установить и проверить. В Kubernetes она может делегировать создание нагрузки собственному контроллеру или kubernetes-sigs/agent-sandbox.
https://open-sandbox.ai/ и https://github.com/alibaba/OpenSandbox

Microsandbox это встраиваемый self-hosted вариант, который запускает микроВМ через libkrun и поставляется с SDK для нескольких языков. По роли он сравним с E2B и OpenSandbox, а отличия лежат в API, модели развертывания, интеграции с инфраструктурой и зрелости.
https://github.com/superradcompany/microsandbox

Docker Sandboxes запускают кодинговых агентов внутри микроВМ, у каждой из которых свое ядро и свой Docker-демон, поэтому агент может собирать и запускать контейнеры, не затрагивая Docker-окружение хоста. В первую очередь это решение для локальных машин разработчиков.
https://www.docker.com/products/docker-sandboxes/ и https://docs.docker.com/ai/sandboxes

Daytona предоставляет песочницы для запуска сгенерированного ИИ кода с SDK и API.
https://github.com/daytonaio/daytona

Cloudflare Sandbox SDK открывает изолированные Linux среды из Workers. https://github.com/cloudflare/sandbox-sdk

Vercel Sandbox предлагает эфемерные Linux микроВМ для запуска недоверенного или сгенерированного ИИ кода. https://vercel.com/docs/vercel-sandbox

Isolation runtime

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

Firecracker это монитор микроВМ, расположенный низко в стеке. На его основе можно построить собственный менеджер песочниц, который поднимает микроВМ, монтирует среду, запускает команды, ограничивает ресурсы и удаляет все после завершения работы. https://firecracker-microvm.github.io/

gVisor нацелен на контейнеры в песочнице и помещает пользовательское ядро между приложением и Linux хостом. Нагрузка сохраняет контейнерную форму, а часть поверхности системных вызовов обрабатывается дополнительным защитным слоем. https://github.com/google/gvisor

Kata Containers сочетают контейнерный интерфейс с изоляцией на основе ВМ. https://katacontainers.io/

Cloud Hypervisor еще один монитор виртуальных машин на Rust, ориентированный на облачные нагрузки. Он может служить бэкендом для рантаймов на базе ВМ. https://github.com/cloud-hypervisor/cloud-hypervisor

Обычные контейнеры на runc остаются базовым уровнем. Они быстрые и повсеместные, но используют общее ядро хоста, поэтому лучше подходят для доверенного или малорискового кода, чем для произвольного вывода агента. https://github.com/opencontainers/runc

Для локальных инструментов разработчика часто используют примитивы ОС: bubblewrap с Landlock и seccomp на Linux и Seatbelt на macOS. По этому пути идет sandbox-runtime от Anthropic, на котором построена песочница в Claude Code. https://github.com/anthropic-experimental/sandbox-runtime и https://github.com/containers/bubblewrap

Orchestrator

Оркестрация управляет множеством таких сред одновременно. Kubernetes отвечает за планирование, жизненный цикл, ресурсы, сеть, обнаружение сервисов, секреты, масштабирование и восстановление после сбоев. Сам по себе он не песочница. Он запускает нагрузки через container runtime, и прочность изоляции зависит от того, какой рантайм ему указан, обычно через RuntimeClass, выбирающий runc, gVisor, Kata или другой вариант. Поэтому оркестратор стоит рядом со слоем изоляции и выбирает его, а не лежит над ним как очередной этаж стека. Он также опционален: Microsandbox, Docker Sandboxes на ноутбуке или собственный менеджер на Firecracker работают без него.

Kubernetes это вариант по умолчанию для больших парков песочниц. https://kubernetes.io/ и https://kubernetes.io/docs/concepts/containers/runtime-class/

K8s Agent Sandbox из kubernetes-sigs делает песочницу управляемой сущностью экосистемы Kubernetes через пользовательские ресурсы и контроллер. Архитектурно рабочая нагрузка агента размещается в кластере, абстракция песочницы ее изолирует, а ниже работает конкретный рантайм, например Kata или gVisor. Так возникают независимые уровни ответственности: харнесс управляет поведением, песочница средой исполнения, рантайм изоляции обеспечивает границу, а Kubernetes размещением и жизненным циклом. https://github.com/kubernetes-sigs/agent-sandbox

Red Hat Agent Sandbox развивается в том же направлении как Kubernetes-native инфраструктура для изолированных нагрузок агентов, с отдельным выбором низкоуровневого рантайма. Корректнее всего сравнивать его с K8s Agent Sandbox и другими агентно-ориентированными слоями оркестрации. https://developers.redhat.com/articles/2026/07/15/red-hat-build-agentsandbox-isolated-workload-management-kubernetes

KAgent также относится сюда, когда агентами управляют как распределенными нагрузками в Kubernetes, а харнесс стоит выше. https://kagent.dev/

Nomad это альтернативный планировщик для команд, которые не используют Kubernetes, но которым нужны размещение и жизненный цикл для множества нагрузок. https://github.com/hashicorp/nomad

Host infrastructure

В самом низу находятся машины, на которых все работает: железо или облачные инстансы, ядро хоста и поддержка виртуализации, от которой зависят слои выше. Инструментам на микроВМ нужен KVM в Linux или Hypervisor.framework в macOS, поэтому облачные развертывания часто требуют bare metal инстансов или вложенной виртуализации, а локальным установкам нужны соответствующие права на машине. Прочность каждой границы выше по-прежнему ограничена ядром хоста и гипервизором, на которые она опирается.

KVM это слой виртуализации Linux, который используют Firecracker, Kata, libkrun и Cloud Hypervisor. https://linux-kvm.org

Hypervisor.framework от Apple играет ту же роль в macOS для локальных инструментов на микроВМ. https://developer.apple.com/documentation/hypervisor

#ии #инфраструктура #ai #devops #агент #aiagents