为什么 AI Agent 让 Sandbox 再次受到关注？
Sandbox 并不是随着 AI 和 Agent 兴起，最近几年才出现的概念。它由来已久，核心是为程序提供一个受到约束的运行环境，限制程序能够访问的资源和造成的影响。在云端执行场景中，我们还希望它运行高效、资源占用少、启动快，并根据需要支持停止、恢复等能力。
在 AI Agent 流行之前，Sandbox 就已经应用于浏览器、Serverless、边缘计算和多租户计算等场景。例如，Firecracker 最初就是为 AWS Lambda 等服务的安全隔离和高效运行而开发的。对很多普通业务团队来说，这些能力长期藏在底层基础设施里，不一定需要自己选型和建设。Firecracker 项目介绍
复杂任务需要“一台电脑”
但随着 AI 和 Agent 的发展，执行环境开始成为应用团队需要直接面对的问题。不仅是软件开发，在金融、保险、影视、法律等行业中，都存在需要使用多种工具、处理多种材料才能完成的复杂任务。过去，这样的任务通常由一位有经验的从业者坐在电脑前完成：打开专业软件，在 Excel 中输入公式、建立模型，在不同应用之间切换，从公司内部系统下载数据，处理文件，再上传结果、提交操作。
如果要让一个由大语言模型驱动的 Agent 完成类似的工作，仅仅让它回答问题，或者调用几个预先定义好的 API，可能就不够了。当任务的复杂度、开放性或通用性达到一定程度时，它往往需要一个更完整、更灵活的执行环境。简单来说，Agent 需要“一台电脑”。
这台“电脑”需要满足什么条件？
给 Agent 提供这台电脑，会遇到几个现实问题。
第一是成本。Agent 并不是时时刻刻都有任务。如果为每个用户或会话配置一台全年运行的云主机，大量空闲时间可能使成本变得不合理。我们希望环境按需分配，空闲时释放计算资源，需要时再启动或恢复。
第二是隔离。多个用户可以共享底层物理机器，但不能毫无边界地共享同一个工作环境。否则，A 修改了一个文件，B 还以为这是自己的版本，随后把它上传到业务系统，问题就出现了。除此之外，还有客户数据、凭证和程序执行权限之间的隔离要求。
第三是响应速度。用户发起任务后，不应该先等十分钟，让环境准备完毕。我们希望环境尽快可用，最好能达到秒级，某些准备充分的场景甚至能达到毫秒级。
第四是扩展能力。这个环境不能配置好之后就固定不变，而应该允许我们随着业务发展，调整软件、依赖和工具，适应新的任务。
把这些需求放在一起，就会发现：Sandbox 这种已有的技术形态，恰好能承接其中相当一部分需求。
Firecracker、gVisor 和 E2B 分别提供什么？
不过，这里需要区分几个名字。Firecracker 是用于创建 microVM 的虚拟机监控器；gVisor 通过用户态内核提供隔离；E2B 则是更上层的沙箱执行平台。 它们处于不同层次，不能统称为 VM，也不是每种 Sandbox 都天然具备完整的暂停、恢复和调度能力。Firecracker、gVisor、E2B 案例中的技术说明
什么企业在用 Sandbox？
从公开资料中，已经可以看到不同类型的企业在使用这些能力：
- Anthropic 的 Cowork 使用本地 VM，为面向知识工作的 Agent 提供隔离环境。技术文章
- 腾讯在 Agentic RL，也就是 Agent 的强化学习训练中，使用 gVisor 承载大量代码执行和测试任务。技术文章
- OpenAI 的 Codex 在早期公开介绍中，就为云端任务提供独立的沙箱执行环境。这里能够确认的是隔离执行环境，不能仅凭这份资料进一步断言其底层使用了哪种 microVM。产品介绍
- Manus 使用 E2B 为 Agent 提供包含浏览器、终端和文件系统的虚拟计算机。E2B 发布的案例还提到，Manus 当时采用了自托管部署。客户案例
- Effective AI 使用 E2B 支持保险行业的精算建模、费率计算、表格生成和合规工作流。客户案例
这些公司有的服务于某个具体行业，有的像 Manus 一样，提供可以处理多种任务的通用工具；还有的将 Sandbox 用于 Agent 的训练过程。隔离执行环境正在进入更多 AI 工作流的大趋势是毋庸置疑的。随着 Agent 开始实际处理文件、运行程序并交付工作成果，执行环境也成为产品能力的一部分。但大公司在用，并不代表我们的公司也应该马上开始用。真正需要判断的是：它们所解决的问题，是否也存在于我们的业务中？
同一家公司的不同产品，也会选择不同的沙箱
即使在同一家公司内部，答案也可能不同。Anthropic 的不同产品就采用了不同的 Sandbox 形态：claude.ai 的代码执行使用云端 gVisor 容器；Claude Code 使用本地操作系统提供的沙箱机制；Cowork 则使用本地 VM。Cowork 最初把 Agent loop 放在 VM 内，后来又将其移到 VM 外，把代码执行留在 VM 内。Anthropic 技术文章 Sandbox 在哪里运行、隔离哪些操作、能够访问什么资源，以及 Agent 本身是否运行在其中，都需要根据产品需求决定。
我们应不应该用 Sandbox？
首先我们需要先区分“使用 Sandbox”和“建设平台”这两个不同的需求阶段。 对于企业来说，“要不要使用 Sandbox”和“要不要建设一套 Sandbox 平台”，是两个不同的决策。 首先应该证明业务确实需要隔离执行能力，然后才讨论如何提供这种能力，以及是否值得自建。不能因为业务开始使用 Agent，就直接推导出需要建设一套基于 E2B、microVM 或其他技术的基础平台，把调度、镜像、存储、监控和回收全部做起来。
Agent loop 和执行操作是两回事
在 Web Service 进程中运行 Agent，完全可以是一种合理的方案。关键在于，我们所说的“运行 Agent”，具体指什么。
- 一种情况是：Agent 调用模型，选择业务工具，校验参数和权限，然后调用业务 API。
- 另一种情况是：Agent 调用模型，生成 Python、TypeScript 或 Shell 脚本，再执行代码、运行命令、启动程序。
它们都叫“运行 Agent”，但从工程上看，含义并不一样。
第一种情况下，实际执行的是我们已经开发、测试和部署好的业务代码。模型主要负责选择工具、提供参数。只要工具边界、参数校验、业务授权和资源限制等机制到位，这类 Agent 的控制逻辑完全可以运行在 Web Service 或后台 Worker 中。
第二种情况下，系统开始执行运行时生成的代码。如果没有额外的隔离和权限限制，直接在服务进程中执行代码，或者启动子进程运行脚本，这些代码就可能访问服务本身可访问的文件、凭证、网络和其他资源。
需要隔离的是这些不可信的执行操作。Agent 的控制逻辑，仍然可以留在 Web Service 或 Worker 中。
根据工作负载选择执行环境
是否需要 Sandbox，要结合实际工作负载判断。
- 如果 Agent 只负责知识库问答、订单查询、日程安排，已有业务 API 就能覆盖任务，通常不需要额外引入通用执行沙箱。即使流程很长，只要每一步都是调用既定 API，主要问题也可能是任务编排、状态保存和失败重试。
- 如果任务只是生成固定格式的报表，模型负责找到数据、填写内容，剩余部分交给已有程序即可。如果只是处理图片，而外部专业服务已经提供了合适的 API，也未必需要给 Agent 一个自由执行代码的环境。
- 如果确实需要运行少量脚本，但语言、依赖和输入输出范围都比较明确，那么具备可靠隔离边界的受限解释器，或者专门的隔离执行服务，就可能足够。这类需求需要认真处理安全边界，但不一定需要完整的 Linux 工作环境。
再看软件开发这种需求更充分的场景：
Agent 可能需要安装依赖、启动服务、运行多个程序，使用 Shell、Git 和各种命令行工具，还要适配项目已有的开发和测试环境。这时，几个固定函数或者一个简单解释器，往往就不够了。它需要一个能够容纳这些操作的通用执行环境，Sandbox 就有了直接的价值。
这种需求也不只存在于软件开发行业。例如，一个法律行业的客户，表面上需要的是知识问答和材料分析，但它可能有自己的技术团队、内部系统和复杂工作流，需要 Agent 编写脚本来整理材料、连接系统、处理数据。行业标签并不能决定执行环境的需求，具体任务才能。
一个关键信号：代码执行成为产品能力
一个很重要的信号是：我们在完善业务 Agent 时，是否反复遇到这样的情况——已有 API 或工具无法完成某个步骤，但 Agent 如果能生成并运行一段代码，这个问题就能解决？如果这种情况频繁出现，并且生成代码确实能可靠地弥补能力缺口，那么代码执行，甚至完整计算环境，就已经成为产品能力的一部分。Effective AI 就体现了这种变化。它早期帮助保险团队分析文档，后来需要进一步生成精算模型、电子表格和费率计算程序。工作从“分析材料”走向“产出可使用的模型和文件”，对执行环境的需求也随之变强。客户案例 这说明的是：某些工作负载需要隔离执行环境，而不是每个 Agent 都需要单独配一台 VM。
六种不值得引入完整 Sandbox 平台的情况
反过来，也有很多不值得引入完整 Sandbox 平台的场景。
| 情况 | 判断依据 | 更合适的做法 |
|---|---|---|
| 业务已经被固定 API 覆盖 | 售后 Agent 只需查订单、读政策、提交退款申请。为每个会话创建 VM 会增加运维环节，却未必提高任务完成率。 | 优先改进业务接口、权限模型和评估数据。 |
| 用通用 Agent 取代成熟的确定性流程 | 每晚将同样的 CSV 转成同样的报表，已有固定程序可以稳定完成。让模型反复写脚本、启动沙箱，可能增加成本和结果波动。 | 常规计算交给已有程序，Agent 负责理解异常或解释结果。 |
| 只有文件交换，却建设完整的休眠恢复体系 | 任务只需保存输入、输出和少量 JSON 状态，重启程序就能恢复，未必需要保存内存、进程和虚拟设备状态。 | 先保存必要的文件和状态；只有状态难以重建时，再考虑完整 VM 快照。 |
| 真正的问题发生在外部业务系统 | 发错邮件、误删客户记录、错误提交订单，销毁沙箱也无法撤销。 | 投入业务权限、预览确认、幂等、审计和补偿机制，Sandbox 不能替代这些能力。 |
| 主要软件不适合 Linux 沙箱 | 工作流依赖特定 Windows 桌面程序、硬件设备或商业软件授权，通用 Linux microVM 未必适合。 | 优先评估应用原生接口或受控桌面环境。 |
| 平台建设走在真实需求前面 | 只有低频试验场景，却先建设调度、镜像分发、快照存储、计费和运维平台，产品方向变化后可能无人使用。 | 先验证具体任务的业务价值，需求稳定后再考虑平台化。 |
同样，反过来也不能因为流量小，就把不可信代码直接放进核心服务。流量决定规模投入，信任边界决定是否需要隔离。
如何开始：先验证业务价值，再考虑平台化
对于正在考虑投入 Sandbox 的团队，我们可以按照下面的顺序推进：
-
先选一个现有方案确实做不好的业务任务。 例如跨格式对账、复杂材料整理，或客户自定义计算。明确交付物和验收标准，而不是以“成功启动一个沙箱”为目标。
-
用最小成本接入隔离执行能力。 数据和网络条件允许时，可以先使用托管服务；也可以复用公司已有的受控计算设施。为该任务提供必要的文件、依赖、资源额度和访问权限。此时不必建设通用平台，也不必给每个 Agent 都分配 VM。
-
与一个合理的简单方案比较。 对照组可以是固定工具、专用 Worker 或已有计算服务。比较真实任务完成率、人工修正时间、每个成功任务的总成本，以及失败后的恢复工作量。只比较启动速度，无法证明业务价值。
-
需求稳定后，再决定是否自托管和平台化。 当数据驻留、客户网络、定制能力、使用规模或长期成本提出明确要求时，再评估自托管。比较时，要把补丁升级、容量管理、故障响应和存储维护的人力一起算进去。
在技术与潮流快速发展的 Agent 时代，快速获取和吸收新的知识与技能又不丢失自己的思考和判断去追赶时尚，或许已经是软件工程师必不可少的能力。与君共勉。