给Agent一台可控的「云上计算机」：揭秘阿里云Agent Sandbox

编辑｜杜伟

当一个 Agent 开始接管你的工作，搜索资料、读取文件、运行代码、调用 API，这些都是常见的执行环节。任务复杂一些，Agent 还要根据环境返回的结果调整计划。这样的工作方式对底层基础设施提出了新的要求。

过去，企业部署大模型应用时，基础设施的关注重点更多地集中在推理效率上，包括响应时延、吞吐和算力成本。随着 Agent 进入真实业务，执行环境成为系统设计中的重要一层。

企业需要确定 Agent 能访问哪些数据和系统，代码、浏览器和其他工具在什么环境中执行以及不同任务之间如何隔离。请求量突然上升时，平台还要快速准备大量独立环境。对于持续时间较长的任务，执行状态、临时文件和中间结果也需要保存下来，避免一次中断就从头再来。

模型时代的基础设施更多服务于「让 AI 思考」，Agent 进入生产环境后，执行本身成为需要重点解决的基础设施问题。也正是在这一变化过程中，沙箱这一传统上多用于隔离不可信代码和进程的安全机制，逐渐演化为承载 Agent 执行的重要组件

今年 4 月，阿里云正式亮相面向企业级 AI Agent 的 Agent Sandbox 并开启公测，试图打造一套面向生产环境的智能体执行底座。2026 云栖大会上，阿里云进一步披露了智能体沙箱 Agent Sandbox 的技术架构和更多产业实践

一句话概括，阿里云 Agent Sandbox 面向 AgentRL/Eval 与 Agent Use/Serving 几大场景，通过安全隔离、弹性供给、状态保持和大规模并发能力，为 Agent 构建安全、稳定、高效的生产级云上执行环境。

阿里云智能集团研发副总裁、弹性计算产品线负责人吴结生发布阿里云 Agent Sandbox

在深入剖析阿里云 Agent Sandbox 的具体架构之前，我们有必要先厘清，沙箱为什么会进入 Agent Infra 的核心执行链路。

在 Agent Infra 中，沙箱承担什么角色？

在一套完整的 Agent Infra 中，不同组件各司其职。模型负责推理并生成下一步行动，编排系统负责组织任务、协调工具调用和执行流程。当任务需要运行代码、访问文件或操作浏览器时，通常还需要一个受控的执行环境，智能体沙箱便承担这一角色

它为进程、文件、网络、存储和系统权限设定边界，避免不同任务相互干扰，也降低单个任务对宿主系统和其他业务的影响。并且，随着 Agent 任务从短时交互转向长程执行，智能体沙箱还要管理运行环境的完整生命周期，包括创建、启动、暂停、状态保存、恢复和回收。

由此看来，智能体沙箱位于 Agent Infra 的执行层，其核心作用是为 Agent 提供受控的运行环境。它承载模型和编排系统产生的行动计划，把工具调用转化为真实的代码、进程和环境操作，同时对执行过程中的安全边界、资源使用和运行状态进行管理。

此前MiniMax云端 AI 助手 MaxClaw 和 MaxHermes 的架构中，就使用 Agent Sandbox 作为 agent的安全执行环境。

从并行训练到在线服务，透视 Agent Sandbox

理解沙箱在 Agent Infra 中的位置后，下一步要看它实际承载的任务形态。不同任务对执行环境的要求各有侧重，训练和自主迭代需要大量环境并行试验，并反复重置、复用状态；在线 Agent 则要在请求到达后快速启动环境，并在工具调用、长会话和暂停恢复过程中维持安全边界。

沿着这两类工作负载，阿里云 Agent Sandbox 的核心场景可以划分为两组：一是面向训练与评测场景，满足模型强化学习 Agentic RL 和模型 RSI 自我进化的需求。二是面向生产应用场景，为Agent Serving 和 Agent Use提供工具调用、代码执行等开箱即用、极致弹性、安全可靠的执行环境。

场景差异自然会落到接入和管理方式上。开发者关注能否快速调用，平台团队则关心沙箱能否纳入现有集群和治理体系。阿里云 Agent Sandbox 据此提供了两种 API 接入方式。

Developer API兼容 E2B，适合开发者快速创建和操作沙箱，也便于迁移已有 Agent 应用。开发团队可以通过熟悉的 API 完成代码执行、文件读写和工具调用， 减少底层环境搭建工作。Kubernetes API面向企业平台和基础设施团队，适用于沙箱资源管理、安全治理以及日常运维。平台团队可以结合已有 Kubernetes 集群、权限体系和运维流程，对大规模 Sandbox 进行统一管理。

云平台还需要让算力规格与任务价值匹配。阿里云表示，Agent Sandbox 当前定价在云厂商同类产品中最低、最具竞争力，提供了经济型、通用型和性能型三档算力 QoS：

• 经济型适合价格敏感、成本优先的任务，vCPU 为 0.060 元 /vCPU・小时，内存为 0.030 元 / GiB・小时；
• 通用型面向生产级通用负载，作为默认推荐配置，vCPU 为 0.078 元 /vCPU・小时，内存为 0.039 元 / GiB・小时；
• 性能型采用专属资源池，满足算力波动敏感的任务，目前仅极速版支持，vCPU 为 0.120 元 /vCPU・小时，内存为 0.060 元 / GiB・小时。

三档均按秒计费，深度休眠期间仅收取磁盘费用。据阿里云透露，结合按需供给、休眠唤醒和弹性能力，Agent Sandbox 在一些典型场景下的整体 TCO（总拥有成本）最高可降 70%

接下来，我们将沿着 Agent Sandbox 在两类典型场景中的运行链路展开，分别看它如何承载训练与评测以及在线服务。

训练评测的环境工程：并行供给、隔离执行与状态复用

在 Agentic RL、RSI 类自主迭代任务中，Agent 需要反复与环境交互。它可能先生成代码或行动方案，再运行 Rollout，获得 Reward，并根据结果继续调整、验证。因此大规模训练和评测需要同时运行大量相互隔离的环境。

环境创建是第一道考验。平台需要批量准备代码、依赖、数据和运行时，尽量减少重复初始化。当训练和评测从单个环境扩展到大规模并行，沙箱创建背后的资源供给链路会直接影响有效 Rollout 的吞吐。

一个执行环境从请求进入到可运行，通常涉及多个环节，任何一处出现瓶颈，都会降低并行环境的周转效率。模板、镜像缓存、资源预调度和实例预热等机制，可以将部分准备工作提前完成。而阿里云 Agent Sandbox 围绕数据加载、资源调度、MicroVM 创建、网络配置和应用初始化等环节进行了全方位优化。

目前阿里云 Agent Sandbox 支持每分钟创建 10 万个沙箱，单个 Region 支持百万级 Sandbox 在线运行。官方预置模板或完成预热的自定义模板，冷启动 P99 小于 180 毫秒；沙箱实例完成预热后，热启动 P99 小于 20 毫秒。

环境进入运行阶段后，沙箱需要为 Rollout 和评测提供隔离、稳定的运行空间。MicroVM 为每个执行环境提供独立的运行边界，代码、工具和进程在受控空间内运行，文件和临时状态也被限制在相应环境中。结合身份管理、网络策略、存储隔离和权限控制，平台还可以限制 Agent 的访问范围，减少异常代码对宿主系统和其他任务的影响。

当训练和评测需要重复使用相同或相近的初始状态时，环境还需要具备状态复用能力。阿里云 Agent Sandbox 支持保存内存级 Checkpoint，并基于同一状态创建新的实例。不同实例可以从相同起点继续执行各自的路径，用于并行探索、批量评测和重复实验。Reset、Fork 和 Replay 等操作由此成为环境管理的一部分，减少重新加载依赖和初始化状态的开销。

在线 Agent 服务的运行链路：快速启动、安全执行与任务恢复

而在 Agent Serving 和 Agent Use 场景中，智能体沙箱承载的是用户请求对应的实际执行过程。任务时长可能从几秒延伸到数小时，Agent 会根据执行环境返回的结果推进后续步骤。

请求到达后，平台需要快速准备可用环境。模板预热、镜像缓存、资源调度和沙箱复用等机制，可以缩短从请求进入到任务开始执行之间的等待时间。面对突发流量，平台还要动态创建、调度和回收大量独立沙箱，保持响应速度和资源供给的稳定性。

任务执行过程中，安全边界需要跟随操作建立。阿里云 Agent Sandbox 从应用访问和运行时两个层面划定安全边界。应用侧通过 Agent Identity 为任务绑定独立身份，长期密钥不直接进入沙箱，并且入站认证和出站策略控制网络访问； 审计能力记录关键操作。运行时层面通过 MicroVM、Non-root、只读根文件系统、VPC/NetworkPolicy 和独立临时盘等机制，进一步限制计算、网络、存储和系统权限范围。

此外，在线 Agent 的执行过程往往并不连续。任务可能等待模型返回、外部 API 响应或人工确认。如果持续占用完整计算资源，空闲时间就会转化为额外成本。阿里云 Agent Sandbox 支持休眠和唤醒，在保留必要运行状态的同时释放 CPU 和内存资源。任务恢复时，环境可以继续使用此前保存的内存数据、临时文件和网络信息，深度休眠唤醒 P99 可低于 600 毫秒

这里需要区分运行状态与业务状态。沙箱负责保存和恢复自身的内存、文件及进程环境，任务进度、数据库写入和外部系统操作仍需由上层应用记录和处理。两类状态分别管理，才能避免沙箱恢复后出现业务上下文缺失。

以上训练评测中的并行环境和状态复用，以及在线服务中的快速响应、权限控制和休眠恢复，背后都离不开一套稳定的执行环境。阿里云 Agent Sandbox 把这些能力集中到同一套运行时里，承担起 Agent 进入生产环境后的执行底座角色。

Agent 走向生产，沙箱站上基础设施 C 位

从基础设施演进的视角来看，智能体沙箱正处在一个关键节点。容器通过镜像封装应用及其依赖，提高部署一致性和集群管理效率；虚拟机提供通用且隔离的运行环境；Serverless 进一步降低应用按需获取计算资源的门槛。Agent 进入生产环境后，新的工作负载又对执行环境提出了不同要求。

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

另外，Agent 任务可能跨多轮交互，并在活跃执行与长时间等待之间切换，任务生命周期与实际计算活跃时间并不一致。为了让任务暂停后还能接着跑，文件、中间结果和运行状态需要被保留下来，这也让状态持久化和恢复成为阿里云 Agent Sandbox 的重要能力。

这些运行特征共同决定智能体沙箱在 Agent Infra 中的位置。阿里云智能集团资深产品专家杨秋弟表示，阿里云希望 Agent Sandbox 成为 Agent 与云基础设施之间的安全执行底座：向上提供开发者友好的接口和生态兼容能力，向下连接计算、存储和网络，将任务创建、资源隔离、权限控制和日志审计等共性能力沉淀为统一的执行环境。

在开放生态建设方面，阿里云现阶段更倾向于先从接入层推进，通过对 E2B、Kubernetes 以及主流 Agent 开发框架的兼容，让企业尽量复用已有的开发和运维体系。目前，这条路径已在不同类型的 Agent 场景中得到验证。

阿里云百炼使用 Agent Sandbox 承载 Agentic RL/Eval 的 Rollout、Reward 以及独立评测环境，贯通训练、评测与应用执行。面向大规模 Agent Serving，MiniMax 基于 Agent Sandbox 在 10 秒内拉起 5000 个沙箱，整体 TCO 降低 25%；月之暗面 Kimi 实现每分钟数万个沙箱的弹性扩容，启动时间缩短 50%。千问办公、理想汽车、金山办公和前程无忧也已将其用于办公、企业助手、代码与浏览器执行、AI 招聘等场景。

正如杨秋弟所说，「模型决定 Agent 想多远，Sandbox 决定 Agent 走多远。」 Sandbox 的价值就在于为模型能力提供一个安全、稳定、可持续的执行环境，让 Agent 的规划真正落到生产系统中。