一文搞懂 Agent Sandbox（沙箱）：为什么 AI 不能随便操作你的电脑？
一、为什么 Agent 需要沙箱？
假设你正在使用 Claude Code、Codex 这样的 AI 编程助手。
你让 Agent 帮忙修改代码、安装依赖、运行测试，它都能自动完成。
但问题来了：
如果 Agent 执行了一条危险命令，比如 **rm -rf ~/**，把你的个人文件全部删除了怎么办？
更严重的是，Agent 可能受到 Prompt Injection（提示词注入）攻击。
例如，它读取了一个包含恶意指令的文件，误以为里面的指令是用户要求，随后偷偷读取 SSH 私钥并尝试发送到外部服务器。
问题的根源在于：
Agent 虽然能够自主执行任务，但我们不能让它拥有不受限制的操作权限。
这就是 Agent Sandbox（沙箱）要解决的问题。
二、什么是 Agent Sandbox？
Sandbox，中文叫作沙箱，本质上是一种隔离运行环境。
可以把它理解成一个有围栏的院子：
- 院子里面，Agent 可以自由活动。
- 院子外面，Agent 不能随意访问。
- 如果需要跨越围栏，就必须获得额外授权。
例如，你让 Agent 修改一个 Python 项目。
没有沙箱时，它执行的命令可能拥有当前用户的全部文件访问权限。
有了沙箱之后，我们可以规定：
- 允许读取项目代码。
- 只允许修改当前项目目录。
- 禁止访问 SSH 私钥等敏感文件。
- 只允许连接指定的网络服务。
这样，即使 Agent 执行了错误或恶意指令，也能在一定程度上限制损害范围。
为什么不直接使用权限弹窗？
传统方法是让 Agent 每执行一条命令，都先征求用户同意。
但如果 Agent 一次任务需要执行几十条命令，你就需要不停点击"允许"。
时间一长，用户很容易不再仔细检查命令。
这被称为 Approval Fatigue（审批疲劳）。
沙箱提供了另一种思路：
与其让用户反复审批，不如提前规定 Agent 的活动范围，在范围内自动执行，超出范围再进行限制或审批。
既能提高自动化程度，又能降低安全风险。
三、Agent Sandbox 是如何实现的？
沙箱最核心的两项能力是：
文件系统隔离 + 网络隔离。
1. 文件系统隔离
文件系统隔离主要解决两个问题：
- Agent 可以读取哪些文件？
- Agent 可以修改哪些文件？
假设你的项目目录是：
/home/user/project/我们可以配置沙箱：
允许 Agent 修改：
/home/user/project/禁止 Agent 访问：
/home/user/.ssh/禁止 Agent 修改：
/home/user/.bashrc这样，Agent 即使执行了越权的文件操作，也会被沙箱阻止。
需要注意的是，读取权限和写入权限是两个独立的概念。
例如，Agent 可能需要读取系统依赖库，但不应该获得修改这些文件的权限。
2. 网络隔离
只限制文件访问还不够。
假设 Agent 已经读取到某些敏感信息，如果网络没有限制，它仍然可能尝试将信息发送出去。
因此，沙箱还需要控制网络访问。
一种常见的实现方式是 网络代理（Proxy）+ 域名白名单。
例如，我们可以规定：
允许访问：
registry.npmjs.org禁止访问：
malicious.example.com当 Agent 执行 npm install 时，正常的依赖下载可以继续进行。
但如果某个恶意依赖试图连接未授权的服务器，请求就会被拦截。
当然，前提是沙箱能够有效限制直接联网，防止程序绕过代理。
文件系统隔离负责限制本地资源访问，网络隔离负责限制对外通信，两者相互配合。
四、谁来真正执行这些限制？
这里有一个关键问题：
如果 Agent 不遵守沙箱规则怎么办？
因此，可靠的沙箱不能只依赖 Prompt 告诉模型"不要修改某些文件"，而需要使用操作系统提供的隔离机制。
以 Claude Code 的沙箱方案为例：
macOS：Seatbelt
Seatbelt 是 macOS 提供的沙箱机制，可以限制进程对文件系统等资源的访问。
Linux：bubblewrap（bwrap）
bubblewrap 利用 Linux Namespace 等机制，为进程创建隔离环境。
例如，可以让 Agent 只能看到必要的系统目录和项目目录，而看不到宿主机上的某些敏感文件。
这与单纯的 Prompt 约束有本质区别。
Prompt 约束是告诉 Agent："你不应该这么做。"
操作系统隔离则是：
即使 Agent 想这么做，操作系统也不允许。
五、Docker、gVisor、MicroVM 又是什么？
除了 Seatbelt、bubblewrap，业界还有多种隔离技术。
它们的主要区别在于隔离方式和安全边界。
| 技术 | 核心特点 |
|---|---|
| Docker | 容器隔离，共享宿主机内核 |
| bubblewrap | 轻量级进程隔离，利用 Linux Namespace |
| gVisor | 在用户空间处理大量系统调用，减少宿主机内核暴露 |
| Firecracker MicroVM | 使用轻量虚拟机，拥有独立的客户机内核 |
可以简单理解为：
Docker、bubblewrap 适合许多常见的应用隔离场景，但仍然共享宿主机内核。
gVisor 进一步减少不可信程序直接接触宿主机内核的机会。
Firecracker MicroVM 则通过虚拟机提供更独立的运行环境，适用于安全要求较高的多租户场景。
不过，隔离并非越复杂越好。
对于本地个人 Agent，轻量级沙箱通常更方便；对于需要执行大量陌生用户代码的云端 Agent，则需要考虑更强的隔离方案。
具体选择还取决于权限配置、性能开销和安全要求。
六、有了沙箱，Agent 就绝对安全吗？
并不是。
沙箱只能限制 Agent 的操作范围，不能保证 Agent 在允许的范围内不会犯错。
例如：
1. 沙箱允许修改当前项目
Agent 依然可能误删项目代码。
2. 网络白名单设置得太宽
恶意程序可能利用已允许的网络服务泄露数据。
3. 沙箱允许访问危险接口
例如开放 Docker Socket，可能使沙箱内的进程间接控制宿主机资源。
4. 沙箱启动失败后自动降级
如果系统在沙箱启动失败时，仍然允许 Agent 不受限制地执行命令，隔离就失去了意义。
因此，在工程实践中，还需要遵循三个原则：
- 最小权限： 只授予完成任务必需的权限。
- 默认拒绝： 未明确授权的敏感操作不应自动放行。
- 纵深防御： 沙箱配合权限审批、日志审计、备份等机制共同保护系统。
七、总结
Agent Sandbox 的核心思想其实非常简单：
让 Agent 拥有完成任务的能力，但不必拥有用户的全部权限。
我们可以从三个层面理解它：
- 为什么需要？ 防止 Agent 的错误操作或恶意指令造成不可控的损害。
- 怎么实现？ 通过文件系统隔离、网络隔离以及操作系统级权限控制，限制 Agent 的操作范围。
- 如何选择？ 本地 Agent 可以考虑轻量级沙箱，云端多租户 Agent 则可能需要更强的隔离技术。
随着 Agent 从简单的聊天助手逐渐变成能够写代码、执行命令、部署服务的自动化系统，沙箱也会成为 Agent 工程架构中越来越重要的一部分。
沙箱的目标不是让 Agent 什么都不能做，而是让它能够在受控的边界内安全地做事。