沙箱
文件系统、网络与进程隔离，以及 Coding Agent 为什么离不开它。
一句话理解：沙箱是给 Agent 划出的“工位”——文件只能动这一块，网络只能连这几家，进程跑不出这个圈；有了它，才敢让 Agent 少问几次、多干点活。
Coding Agent 每天在做一件听起来很危险的事：在你的电脑或服务器上执行它自己写的命令。npm install 会下载并运行第三方脚本，rm -rf 敲错一个路径就是灾难，一段测试代码可能顺手读了 ~/.ssh 里的私钥再发到某个网址。
只靠“每条命令都弹窗问用户”是不行的：一个任务几十上百条命令，用户很快就会闭着眼睛点“允许”。沙箱的价值，是把安全从“每一步靠人判断”变成“边界由操作系统强制执行”，让 Agent 在边界内自由行动，越界时才找人。
沙箱隔离的三件事
| 隔离维度 | 限制什么 | 不隔离会怎样 | 例子 |
|---|---|---|---|
| 文件系统 | 能读哪些路径、能写哪些路径 | 改坏系统文件、篡改 Shell 配置植入后门、读走凭据 | 只允许写当前项目目录和临时目录 |
| 网络 | 能连哪些域名、能不能发出请求 | 把代码或密钥发往外部服务器、下载恶意依赖 | 只允许访问包管理器和公司 Git 仓库 |
| 进程 | 子进程能否逃出限制、能否访问系统服务 | 通过子进程或系统套接字绕过限制 | 所有子进程继承同样的限制 |
文件隔离和网络隔离必须同时存在。 Claude Code 的沙箱文档对此说得很直白：没有网络隔离，被攻破的 Agent 可以把 SSH 密钥之类的敏感文件发出去；没有文件隔离，它可以篡改系统资源，反过来为自己打开网络通道。只做一半，等于没做。
把三道墙和各自放行、拦截的例子放在一起看：
真实产品怎么做
主流 Coding Agent 都把沙箱当作核心能力，而且优先使用操作系统自带的隔离机制，而不是靠模型“自觉”。
Claude Code（据官方文档）：
- macOS 上使用系统内置的 Seatbelt，Linux 和 WSL2 上使用 bubblewrap；原生 Windows 不支持沙箱。
- 默认可写：当前工作目录、会话临时目录，以及用户额外添加的目录；默认 可读整台电脑，文档特别提醒这意味着
~/.aws/credentials、~/.ssh/这类凭据文件默认仍可读，需要额外配置屏蔽。 - 网络通过沙箱外的代理控制，默认不预先放行任何域名，第一次访问新域名时请用户批准。
- 两种模式：沙箱内命令自动放行，或仍然逐条走权限确认。
- 命令在沙箱内跑不通时，Agent 可以申请“脱离沙箱重试”，但这会重新走权限确认；管理员可以关闭这个逃生口。
Codex（据 OpenAI 官方文档）：
- 沙箱模式分为
read-only、workspace-write（默认，可在工作区内读写和运行命令）与danger-full-access（移除限制，不推荐）。 - 审批策略决定越界时是否停下来请示，例如
on-request（越界时请示）和never（不请示）。 - 本地运行默认关闭网络；在云端环境中，安装依赖的准备阶段可以联网，Agent 执行阶段默认离线。
两家的共同思路可以画成这样：
权限和沙箱是两层，不能互相替代。 权限层在命令执行前看“字面上要做什么”，而一个看起来无害的 npm test 可能在测试脚本里做任何事；沙箱层在命令运行时由操作系统盯着“实际做了什么”，不管模型选了什么命令都成立。
沙箱不是万能的
官方文档都坦率列出了局限，产品经理需要知道这些“漏风”的地方：
- 放行的域名太宽：Claude Code 文档警告，放行
github.com这类大域名本身就可能成为数据外传通道；默认代理只看域名、不检查加密流量内容。 - 配置反向打洞：允许写入
$PATH下的目录或 Shell 启动文件，等于允许 Agent 给自己“升级权限”；放行 Docker 套接字几乎等于把宿主机交出去。 - 环境变量继承：沙箱内命令默认会继承父进程的环境变量，里面的 API Key 同样可见，需要专门清理或掩码。
- 只管 Shell 命令：文件读写工具、浏览器操作、Computer Use 走的是另外的边界。Claude Code 文档明确说，计算机操作运行在你真实的桌面上，而不是隔离环境里。
所以沙箱是 降低风险，而不是 消除风险。隔离强度从弱到强大致是：
| 隔离方式 | 隔离强度 | 启动成本 | 适合 |
|---|---|---|---|
| 进程级沙箱（Seatbelt、bubblewrap） | 中 | 几乎为零 | 本地 Coding Agent 的日常命令 |
| 容器 | 中高 | 秒级 | 统一的开发环境、CI 中运行 Agent |
| 虚拟机 / 云端一次性环境 | 高 | 秒到分钟 | 执行不可信代码、云端长任务、多租户产品 |
不只 Coding Agent 需要沙箱
「销售分析 Agent」要写 Python 处理上传的 Excel，代码执行环境同样需要隔离：一份恶意构造的文件、或模型写错的一段代码，都不应该能访问其他租户的数据或公司内网。常见做法是每个会话一个一次性容器，只挂载本次上传的文件，默认不联网，运行结束即销毁。
常见误区
- “有沙箱就可以开全自动。” 沙箱只管文件和网络边界，管不了“在允许范围内做错事”，比如在项目目录里删掉一半代码，或者把错误的补丁推上去。
- “只隔离文件就够了。” 能联网的 Agent 可以把能读到的一切发出去；文件和网络必须一起限制。
- “沙箱会让 Agent 变笨。” 恰恰相反，边界清晰之后可以减少打断，让 Agent 连续工作更久。
设计要点
- 默认可写范围是否收敛到任务目录与临时目录？
- 凭据文件和含密钥的环境变量是否对沙箱内命令不可见？
- 网络是白名单还是黑名单？白名单里有没有过宽的域名？
- 命令被拦截时，Agent 能否看到被拦原因并换一种做法，而不是反复重试？
- “脱离沙箱执行”的逃生口是否需要人工批准，能否由管理员统一关闭？
- 沙箱不可用时（缺依赖、平台不支持），是静默降级还是直接失败？
练习
用 45 分钟为「销售分析 Agent」的代码执行环境写一页沙箱策略：
- 列出它需要读的数据、需要写的产物、需要访问的网络地址。
- 写出默认拒绝、明确放行的三份清单：可读路径、可写路径、可访问域名。
- 设想一段被注入的代码试图把数据发到外部地址，说明你的策略在哪一层拦住它。
延伸阅读
下一步
下一课「浏览器 Agent」离开终端，走进网页：当 Agent 需要读页面、点按钮、带着登录态操作时，会遇到哪些沙箱之外的新问题。