阿里云披露Agent Sandbox技术架构，打造Agent生产级执行底座

过去企业部署大模型应用，基础设施的关注重点集中在推理效率：响应时延、吞吐和算力成本。但当 Agent 进入真实业务，执行环境本身成为系统设计中不可回避的一层。企业需要确定 Agent 能访问哪些数据和系统，代码、浏览器和其他工具在什么环境中执行，不同任务之间如何隔离；请求量突然上升时，平台还要快速准备大量独立环境；对于持续时间较长的任务，执行状态、临时文件和中间结果也需要保存下来，避免一次中断就从头再来。

正是在这一变化中，沙箱这一传统上多用于隔离不可信代码和进程的安全机制，逐渐演化为承载 Agent 执行的重要组件。阿里云于今年 4 月正式亮相面向企业级 AI Agent 的 Agent Sandbox 并开启公测，并在 2026 云栖大会上进一步披露了其技术架构和更多产业实践。

在一套完整的 Agent Infra 中，模型负责推理并生成下一步行动，编排系统负责组织任务、协调工具调用和执行流程。当任务需要运行代码、访问文件或操作浏览器时，还需要一个受控的执行环境——智能体沙箱便承担这一角色。它为进程、文件、网络、存储和系统权限设定边界，避免不同任务相互干扰，也降低单个任务对宿主系统和其他业务的影响。

随着 Agent 任务从短时交互转向长程执行，沙箱还要管理运行环境的完整生命周期，包括创建、启动、暂停、状态保存、恢复和回收。由此，智能体沙箱位于 Agent Infra 的执行层，承载模型和编排系统产生的行动计划，把工具调用转化为真实的代码、进程和环境操作，同时对执行过程中的安全边界、资源使用和运行状态进行管理。

阿里云智能集团容器、沙箱研发负责人易立在接受机器之心采访时，将 Agent Sandbox 概括为“本质上给 Agent 使用的一台计算机”。与传统上主要面向人和应用提供通用计算环境的虚拟机不同，它面向的是由模型驱动的执行任务：Agent 可能运行动态生成的代码，并访问文件、网络和外部系统，因此沙箱需要在计算、存储和网络层建立完整的安全边界；同时，无论是 Agent Serving 还是 RL 中的并行探索，又要求大量沙箱能够快速创建并投入运行。

不同任务对执行环境的要求各有侧重。训练和自主迭代需要大量环境并行试验，并反复重置、复用状态；在线 Agent 则要在请求到达后快速启动环境，并在工具调用、长会话和暂停恢复过程中维持安全边界。沿着这两类工作负载，阿里云 Agent Sandbox 的核心场景划分为两组：一是面向训练与评测，满足模型强化学习 Agentic RL 和模型 RSI 自我进化的需求；二是面向生产应用，为 Agent Serving 和 Agent Use 提供工具调用、代码执行等执行环境。

场景差异落到接入和管理方式上。开发者关注能否快速调用，平台团队则关心沙箱能否纳入现有集群和治理体系。阿里云 Agent Sandbox 据此提供两种 API 接入方式：Developer API 兼容 E2B，适合开发者快速创建和操作沙箱，也便于迁移已有 Agent 应用；Kubernetes API 面向企业平台和基础设施团队，适用于沙箱资源管理、安全治理以及日常运维，可结合已有 Kubernetes 集群、权限体系和运维流程对大规模 Sandbox 进行统一管理。

需要指出的是，Developer API 兼容 E2B 意味着其开发者接口设计受 E2B 生态约束；而阿里云与 E2B、Kubernetes 生态兼容的实际迁移成本与兼容性边界，目前并未详细披露。