沙箱先是工作现场，然后才是安全设施

很多人说 agent 沙箱，第一反应是安全：把模型生成的代码关起来，不让它碰本机，不让它乱访问网络，不让它破坏生产系统。

这个反应没有错，但太窄。对一个真正要交付结果的 agent 来说，沙箱首先是工作现场。它要有代码仓库，有依赖，有语言运行时，有测试工具，有网络策略，有临时文件，有缓存，有日志，有退出方式，也要有把结果交还给人的路径。

人类开发者打开电脑时，这些东西通常已经在机器上。Agent 没有自己的电脑。它每接一个任务，都需要一个可以被创建、配置、观察、恢复和销毁的运行现场。

所以沙箱不是一个附加安全层。它正在变成 Agent 产品的运行界面。

环境准备会直接决定 agent 的上限

OpenAI Codex 的 cloud environments 文档，把这件事写得很具体。用户可以用环境控制 Codex 在云端任务里安装什么、运行什么；提交任务后，Codex 会创建容器、检出指定分支或 commit，运行 setup script，应用网络访问设置，然后在终端命令循环里编辑代码、跑检查、验证结果。

这不是简单的「给模型一个 shell」。产品点在前半段：选哪个仓库版本，装哪些依赖，是否复用缓存容器，环境变量怎么放，测试命令从哪里来，失败时人能不能看到 diff 和日志。

如果环境准备错了，模型再聪明也会被拖进低质量循环。依赖装不上，它会猜；测试跑不了，它会凭感觉收口；工具版本和生产不一致，它会交出一个只在沙箱里绿的结果。

很多 agent 失败，看起来是推理失败，实际是运行现场太粗糙。它没有拿到正确工具链，也没有一个可信的验证完整流程。

GitHub 把沙箱放进协作流程

GitHub Copilot cloud agent 的文档把另一面说清楚了：agent 在 GitHub Actions 驱动的临时开发环境里研究仓库、制定计划、修改代码、执行测试和 linter，然后把变更放到分支和 pull request 里让人 review。

沙箱不只是计算资源。它还连着组织协作方式。

在 IDE 里的 agent mode，更像人旁边的助手；cloud agent 则更像被分派任务的后台开发者。它需要自己的分支，需要日志，需要 commit，需要 PR，需要 reviewer 能看懂它做了什么。环境本身因此成为产品体验的一部分：任务是否能从 issue 进入，是否能在分支上留下清楚记录，是否能在 PR 前迭代，是否能被团队审查。

GitHub 还允许用 copilot-setup-steps.yml 定制 cloud agent 环境：预装依赖，切换更大的 runner，使用自托管 runner，配置 Windows 环境，配置 secrets 和变量，甚至调整 firewall。这里的关键词是「更像真实开发现场」。

如果一个企业仓库依赖私有包、特殊编译器、内部证书和自定义 runner，通用沙箱无法直接胜任。Agent 要进入生产流程，沙箱就必须能继承团队的工程事实。

网络策略是产品协议

OpenAI Codex 的 internet access 文档默认关闭 agent 阶段联网，只允许 setup scripts 联网安装依赖；如需开启，可以按环境配置有限或不受限访问。文档也明确列出风险：不可信网页带来的 prompt injection，恶意或有漏洞依赖，许可证受限内容，以及数据泄露。

这件事经常被讨论成安全策略，但它也是产品协议。

Agent 能不能访问公网，能访问哪些域名，能用哪些 HTTP 方法，能不能下载依赖，能不能调用外部 API，决定了它能完成什么任务，也决定了用户要承担什么责任。一个完全离线的 agent 很安全，但它可能无法查文档、拉包、跑集成测试。一个完全联网的 agent 更自由，但风险和审计压力会立刻上升。

成熟产品不会把网络做成一个粗暴开关，而会把它变成环境的一部分：默认关闭，按任务开启，按域名收窄，按方法限制，敏感动作留日志，最终 diff 和 work log 必须能被人复查。

沙箱因此承载了一条隐含契约：agent 可以行动，但行动半径要被配置出来，而不是靠它临场自觉。

文件系统是 agent 的记忆接口

E2B 的文档把 sandbox 描述成按需创建的安全 Linux VM，用来让 agent 执行代码、处理数据和运行工具。Daytona 的文档则更强调「完整可组合电脑」：独立内核、文件系统、网络栈、vCPU、内存和磁盘，并通过 SDK、API、CLI 做生命周期管理、文件操作、进程执行和运行时配置。

这些说法背后有一个共同点：agent 需要一个可以读写的世界。

模型上下文只能暂存文字，不能代替文件系统。真实任务会产生仓库 diff、测试输出、下载的依赖、临时脚本、日志、构建缓存、中间数据和最终产物。把这些都塞进上下文，既贵，也不可靠。更自然的做法，是让 agent 像开发者一样使用文件系统，把上下文留给判断，把现场留给沙箱。

Daytona 提到 stateful environment snapshots，这尤其重要。Agent 如果每次都从空白环境启动，会浪费大量时间重装依赖、重建缓存、重新准备数据。可复用快照让环境从一次性容器变成长期工作台，也让团队可以把「这个仓库应该怎样被 agent 打开」固化下来。

这会改变 agent 产品的竞争点。谁能更快拉起正确环境，谁能更可靠地保存中间状态，谁能更清楚地暴露文件和进程，谁就更接近可用的生产系统。

任意代码执行需要更硬的隔离

Modal 的 Sandboxes 文档直接把用途说成：安全容器，用来执行不可信用户或 agent 代码，适合运行语言模型生成的代码、创建隔离环境、检出 git 仓库并跑测试、运行任意依赖和 setup scripts。它还把 sandbox lifecycle 拆成创建、调度、初始化、运行、终止等状态，方便监控和自动化。

沙箱不是只有 coding agent 才需要。任何让模型生成并执行代码的产品，都会遇到同一个问题：你要让它跑，但不能让它无限制地跑。

资源限制、超时、进程状态、stdout/stderr、文件提取、GPU/CPU/ 内存配置、生命周期事件，这些看起来像云计算细节，实际是 agent 产品细节。用户不会关心底层怎么调度，但会关心任务为什么卡住、代码是否真的运行、结果从哪里下载、失败能不能重试、费用有没有失控。

当 agent 可以运行任意代码，沙箱就必须同时承担三件事：隔离风险，提供真实执行能力，给产品层返回可解释状态。缺任何一项，都会把体验拖回演示级别。

microVM 暗示了下一层基础设施竞争

Firecracker 项目把自己定位为用于创建和管理安全多租户容器与函数服务的 microVM 技术，目标是兼顾安全隔离、资源效率和快速启动。它不是专门为 AI agent 做的，但它解释了为什么 agent 沙箱最终会走向更底层的基础设施竞争。

Agent 的运行环境有一个矛盾：它既要像虚拟机一样隔离，又要像容器一样快；既要支持大量并发小任务，又要能跑复杂依赖；既要便宜，又不能把不同用户、不同仓库、不同密钥混在一起。

如果只是偶尔跑一个 demo，普通容器就够了。可一旦产品要同时服务许多用户、许多仓库、许多长短不一的任务，启动速度、隔离强度、冷启动成本、镜像缓存、网络策略、磁盘持久化和日志采集都会变成核心指标。

这也是为什么 E2B、Daytona、Modal 这类产品值得单独看。它们卖的是 agent 时代的执行 substrate：给模型一个可控、可观察、可计费、可复用的电脑。

好沙箱会让 agent 少猜一点

Agent 产品最怕两种状态。第一种是能力不足，什么都不能做，只能聊天。第二种是能力过度，什么都能做，但人不知道它做了什么。

沙箱的价值，是在两者之间划出工作边界。它把仓库、依赖、工具、网络、权限、资源和日志组织成一个明确现场。Agent 在里面行动，人从外面观察、配置、审批和接管。

这比「更聪明的模型」更朴素，也更接近生产。模型当然还会进步，但每一次进步都会扩大它需要执行的任务半径。任务半径越大，运行环境越重要。

未来评估一个 agent 产品，不能只问它调用了哪个模型，也不能只问它有没有 sandbox。更好的问题是：

  • 它的环境能不能复现团队真实工具链？
  • 它的网络访问能不能按任务收窄？
  • 它能不能保存和恢复工作现场？
  • 它的文件、进程、日志和 diff 能不能被人审查？
  • 它的资源消耗能不能被限额和归因？

这些答案合在一起，才决定 agent 是一个会聊天的工具，还是一个能稳定工作的执行者。