面向多 Agent 的容器化沙箱基础设施实践

01 基于容器构建 Agent Sandbox

以代码调试为例，Agent 会先调用大模型完成思考与规划，再进入代码环境执行和验证；过程中还可能通过 MCP 调用工具，读取历史请求、代码 Review 记录、知识库和记忆信息，最后汇总模型、工具与执行结果，并把必要信息更新到记忆模块。由于模型生成的代码可能包含错误、不可预期操作，甚至被提示词诱导执行恶意行为，Code Interpreter、Browser Use、Compute Use 等能力都需要运行在隔离的 Sandbox 中。

从基础设施视角看，智能体落地首先面对三类挑战。第一是数据安全：不同会话可能接触用户代码和历史数据，既要隔离会话，也要防止恶意代码访问宿主机、删除资源或横向渗透。第二是大规模极速交付：模型动态调用工具，一个任务可能临时展开多个 Agent，瞬间产生数十乃至上百个沙箱，资源需求会随会话数量和并行度剧烈波动。第三是状态持久化和成本控制：Agent 经常跨多轮、长周期运行，但沙箱大量时间在等待用户、工具或其他 Agent，如果一直保持运行会造成资源浪费。

因此，Sandbox 不能只有“创建”和“销毁”。它通常从包含镜像、规格、编排配置以及可选 Checkpoint 的模板创建，经历 Pending、Running、Paused 和 Completed 等状态。运行中的实例可以 Pause，释放主要计算资源；收到新输入后再 Resume。还可以对文件系统、内存乃至显存做 Checkpoint，生成可复用模板，用于长任务续跑或 Agent 强化学习中的多路径探索。

02 Agent Sandbox 的关键技术实现

安全隔离是一套组合机制。计算隔离要让不同沙箱的 CPU、内存互不干扰，并借助 KVM、Kata、Firecracker、gVisor 等技术强化沙箱与宿主机边界；网络隔离要限制 Agent 之间的东西向访问，南北向只开放必要出口，并为不同 Agent 划分清晰网络边界；存储隔离要求共享存储使用独立挂载点，避免跨会话读取；鉴权隔离则为单个 Agent 或沙箱配置独立 RBAC。以上能力还要叠加可观测和审计，使创建、执行、访问、休眠、唤醒和销毁全过程可追踪。

资源管理的难点是“启动急、运行短、等待长、负载不可预测”。分享中给出两类路径：一类采用 ACS Pod、AWS Fargate、Azure AKS Pod、GKE Agent Sandbox 等 Serverless 算力，降低用户管理底层资源的复杂度；另一类在 Kubernetes 节点池中组合 runD、Kata、Firecracker、gVisor 等运行时，自建安全与弹性能力。还给出了硬件侧参考：AMD EPYC 单颗最高 192C/384T，高整合比约 7:1，TCO 最高降低 67%，用于支撑海量沙箱高密部署。

在大规模 Agent Sandbox 场景中，底层算力需要同时满足高并发、高弹性和低成本要求。AMD EPYC 凭借高核密度，可提升单机 Sandbox 承载能力，为 Serverless 与 K8s 节点池提供高密度算力支撑。

状态保持分为文件系统、内存和显存。文件系统需要保存 rootfs、临时卷和持久化卷的变化；内存可采用 CRIU 的进程级 Checkpoint，或虚拟机整机内存快照；显存可借助 NVIDIA cuda-checkpoint 等机制。Firecracker 的典型思路是文件系统使用持久化存储并保存虚拟机维度内存快照，gVisor 则可结合持久化文件系统与进程级 CRIU。

阿里云 ACS Sandbox 的极速唤醒实践由五部分组成：对同构配置进行模板化和池化；以 Serverless 方式提供大规模资源；复用 ACS 安全沙箱的计算、网络和存储隔离；通过块存储快照预热与复制加速 Rootfs 恢复；由 Sandbox Operator 管理生命周期并屏蔽预热池复杂度。预热对象不仅包括 MicroVM，还包括计算规格、网卡、存储设备、Rootfs 和容器镜像缓存。这些生产经验进一步沉淀到 OpenKruise Agents。

在运行时层面，阿里云实践了两条休眠唤醒路径。CRIU 保存进程级状态，数据量较少、休眠轻量、硬件耦合较低，但对多进程、多个容器相互依赖的环境适配有限；虚拟机整机快照能够保留 Guest OS、网络协议栈等完整上下文，稳定性更好，但硬件耦合更高，通常不支持跨 CPU 代际恢复。两种方式都可以结合 Lazy Load，将关键恢复路径压缩到秒级，生产中需要根据业务形态选择。

03 OpenKruise Agents：连接 Agent 与 Kubernetes

OpenKruise Agents 是 CNCF 孵化项目 OpenKruise 社区下、面向 AI Agent Sandbox 的开源子项目，提供创建、休眠、唤醒、资源池化、资源变配、Checkpoint、Fork 和 Commit 等能力。它向上通过 E2B SDK、REST 或 gRPC 对接 Agent，向下通过 Kubernetes API 使用 Pod 承载 Sandbox，把开发接口与云原生资源管理连接起来。

项目提供两套集成方式。AI 科学家和开发者可以使用兼容 E2B 的 Python SDK，直接调用 create、sleep、wake、destroy，无需了解 Kubernetes 细节；平台和运维团队则可以使用 Sandbox CR、SandboxSet，以声明式方式完成沙箱资源创建、状态同步、休眠调度、资源回收、实例数量和配置管理。

整体架构包括 Agent Apiserver、Sandbox 管理和 Checkpoint 管理三部分，分别负责标准 API 与路由、生命周期与池化，以及沙箱的快照、克隆和容器镜像 Commit。

在休眠唤醒流程中，Agent 通过 E2B 发起 Sleep，Agent-Apiserver 触发 Job，使 Sandbox 休眠，并把文件系统和内存状态保存到云盘或快照；再次需要执行时，系统通过 Job 恢复状态并唤醒 Sandbox。对用户只暴露模板、是否保存内存和文件系统等配置，底层与 CRIU、容器运行时和云盘快照的交互由系统封装。

池化能力把 Sandbox 分为 In-Using、Available 和 Paused 三类。请求到来时，Agent-Apiserver 从 Available 池快速分配实例，再由 Agent-Proxy（Envoy、Proxy-Manager）完成路由，实现预热实例的秒级获取。

为了降低长期预热成本，AutoScaler 可根据池水位或时间扩缩容，Refresher 负责已使用实例的清理复用和镜像动态更新；预热时可用极小规格维持实例，真正运行前再动态调整 CPU、内存、镜像和存储挂载。

Commit 通过 CRI 捕获 overlayfs 读写层，把文件差异打包为标准 OCI 镜像并推送仓库，适合保存已安装依赖和配置好的开发环境，实现状态回溯、重建和迁移。

Checkpoint 在 Commit 基础上利用 CRIU 保存寄存器、内存页、网络连接等进程上下文，形成“镜像 + 内存 Dump"的完整快照，可恢复到特定执行时刻，也可在 Agent RL 或 MCTS 场景中快速 Fork 出多个探索分支。PPT 同时说明，当前实现以镜像 Commit 为主，后续可进一步转向云盘承载。

04 Agent Sandbox 生态

从功能看，生态可以分为四层：LangGraph、AgentScope、Kagent、Dapr Agent 等 Agent Framework 负责多 Agent 协作、工作流、模型抽象和推理；OpenKruise Agents、AgentCube、SIG Agent-Sandbox 等 Sandbox Infra 负责资源供给和状态持久化；AIO Sandbox、redroid、AndroidWorld 等 Agent Runtime 提供工具集成和操作系统仿真；Kata、gVisor 等容器与虚拟化技术提供安全、快速的运行环境。

AgentScope on K8s 展示了框架与基础设施的衔接方式：基于 AgentScope Core 构建的应用可以部署到 Kubernetes，Agent 应用通过 HTTP 调用多个 Sandbox，Sandbox 则可以运行在 ECS Pod、Kata、MicroVM 或 Virtual Kubelet 之上。

整体上，上层既可以接入百炼、AgentScope、LangChain 等生态，也可以自建应用；中间通过 Pod 协议、Sandbox 协议或 E2B 兼容层衔接；底层最终收敛到 ACK、ACS 和 Kubernetes API 这一套统一基础设施。生态可以多路径接入，但共享同一个容器与沙箱底座。

05 客户案例与实践效果

MiniMax 的 MaxClaw、MaxHermes 采用控制平面与执行平面分离：ACK 负责消息分发、任务编排、策略下发、状态管理和运行观测，ACS Agent Sandbox 以 MicroVM 承载执行环境，并结合独占 ESSD、弹性网卡、NAS、网络 Default Deny 和 Checkpoint 提供隔离与长任务连续性。PPT 披露的案例数据包括 20-40 毫秒实例供给、每分钟 15000 个沙箱、MicroVM 级强隔离和实例漂移或重启后的状态恢复。

Kimi 的场景覆盖深度研究、OK Computer 等 C 端 Agent，以及 K2 模型 RL 训练。其挑战包括高峰期数万并发、模型生成代码的安全执行、研究型长任务中断恢复和 RL 批量启停。方案采用分级调度：ACK 节点池承载常态基线，提供多可用区、多规格弹性和自定义镜像、数据盘快照；当排队超过 500 或等待超过 30 秒时，任务溢出到 ACS Agent Sandbox，通过 MicroVM、Quota 热更新、休眠唤醒和内存级 Checkpoint 扩展。PPT 给出的案例结果包括虚拟化开销降低 90%、沙箱启动提速 60% 以上、10 万级 Pod 稳定调度，以及数秒内克隆大量 RL 分支实例。

结语

多 Agent 基础设施的关键，不是简单启动更多容器，而是把强隔离、极速交付、状态连续和成本控制组合成完整生命周期。容器、MicroVM、Serverless、预热池、休眠唤醒、Commit 与 Checkpoint 分别解决不同环节的问题；OpenKruise Agents 则把这些生产能力抽象为开发者可调用、平台团队可运维的标准接口，使 Agent 的工具执行从临时环境走向可规模化的基础设施。

以上就是本次分享的内容，谢谢大家。