Agent in the Sandbox：当 AI 有了自己的开发环境
周五下午，你把一个 Bug 交给 AI："用户连续点击两次取消按钮，系统会发送两次取消通知。"
几分钟后，你收到的不是一段修复建议，而是一份可以审查的代码改动。AI 找到了取消订单的入口，写了一个能复现问题的测试，确认它在修改前失败，再修复代码并重跑测试。交付说明里还留了一句：已验证连续请求，并发请求尚未验证。
这就是 Agent in the Sandbox 在 AI Coding 中的一种典型形态。Agent 在一个有明确权限边界的工作环境里读代码、改文件、跑命令，再根据执行结果继续工作。
Agent 负责下一步，Sandbox 负责执行边界
可以把它拆成两部分来看。
Agent 负责推进任务。它读到测试失败的输出，可以决定先查调用链，还是缩小复现范围。它看到某个改动引发了回归，可以回头修改方案。这样的工作方式依赖一个循环：执行一步，观察结果，再决定下一步。
Sandbox 是这些操作发生的地方。它可以提供一份仓库副本、构建工具和测试数据，也可以限制文件读写和网络访问。模型可以运行在环境之外，由 Agent 的运行框架把命令送到沙箱执行，再把结果带回来。 OpenAI Sandbox Agents 文档
这种分工让 AI 有机会用真实的运行结果修正自己的判断。它觉得问题出在前端，就可以先复现一次直接调用接口的情况。如果绕过页面仍能触发重复通知，排查就该转向后端。
一个取消订单的 Bug，怎么在沙箱里修？
团队可以给 Agent 准备一个独立工作区，里面有仓库副本、项目依赖和测试数据库。任务是修复重复通知，交付物是代码差异和测试结果。
- 复现问题。 对同一笔测试订单连续发起两次取消请求，记录通知发送次数。
- 定位原因。 检查订单状态更新与通知发送的顺序，确认第二次请求为什么还能触发通知。
- 修改并验证。 跑同一个复现用例，确认通知只发送一次，再检查首次取消等相关行为。
- 交付证据。 提供代码改动、执行过的测试，以及尚未覆盖的并发或失败场景。
在这个例子里，Agent 可以自行重跑测试、重建测试数据、撤销不合适的改动。如果环境没有生产数据库的访问路径，也没有发送真实通知的凭证，这些试验就可以在测试环境里完成。Codex Cloud 的独立任务工作区就是这种安排的一个实例。 Codex Cloud 文档
沙箱的边界，取决于你交给它什么
判断一个沙箱能约束什么，可以先看这三项。
| 边界 | 在开发任务中的例子 |
|---|---|
| 文件 | 可以修改任务工作区里的源码，宿主机上的 SSH 私钥不向该环境开放。 |
| 网络 | 可以访问指定的依赖仓库，其他目的地由网络策略限制。 |
| 凭证与工具 | 可以使用测试库账号。如果另有工具可以写生产库，该工具也需要独立的权限约束。 |
最后一项很容易被忽略。即使沙箱里的命令无法直连生产库，只要 Agent 还能调用一个有生产写权限的外部工具，操作就可能通过那条路径生效。理解一个 Agent 的实际权限，要把沙箱、凭证和外部工具放在一起看。 Anthropic 的 Claude Code 沙箱设计 · OpenAI 沙箱安全文档
人在什么时候介入？
当 Agent 交回补丁时，团队可以直接看代码差异和测试证据。连续请求测试通过，回答了"先后到达的两次请求是否仍会重复发送通知"。如果团队还关心两次请求同时到达，或者状态更新成功后通知发送失败，就需要相应的用例和业务约定。
这也是沙箱在团队里的实际价值。开发者可以把中间的复现、试错和重跑交给 Agent，把注意力留给需要工程判断的地方：测试覆盖了什么、改动会影响谁、是否可以合并。原先要守着终端跟完的排查过程，可以变成一次有代码、有证据、也有明确待确认项的交接。