黎声旭大模型写代码这件事，从 GPT-3.5 时代开始大家就已经不稀奇了。真正让整个行业兴奋又紧张的，是 AI Agent 开始自己改代码、自己跑命令、自己执行脚本。Cursor、Codex 这类工具铺开之后，越来越多团队把大模型放进研发流程里，让它直接操作终端。这时候一个老问题换了新马甲冒了出来：模型生成的代码，你真的敢让它直接跑吗？它不是人编写的，没有经过 review，没有测试用例兜底，甚至可能是模型被 prompt 注入后生成的恶意代码。OpenSandbox 这类面向大模型代码执行场景的沙箱，解决的就是这个问题——在模型和真实系统之间画一条隔离线，让 AI 生成的代码在受控环境里运行，跑完销毁，不留痕，不外泄。这篇文章我会从场景拆解、隔离原理、实操接入、踩坑记录到选型对比，完整过一遍。
1. 让模型“跑代码”比“写代码”难在哪：先看清问题全貌
1.1 从代码生成到代码执行，风险等级完全不同
我见过太多团队，把大模型接到生产流程里的时候，其实没有仔细想过“代码执行”和“代码生成”是两种完全不同风险等级的能力。
生成代码，模型输出的是字符串，哪怕里面有 rm -rf /，只要你不去执行它，它只是一段文本。但一旦交给 Agent 去自动执行，这段文本就变成了操作系统的系统调用，有了实际的破坏能力。这中间的信任跳跃之大，很多人其实是低估的。
从工程角度看，代码生成阶段的问题只会让你“代码跑不起来”，而代码执行阶段的问题会让你“整个服务挂了”“数据库被清了”“公网 IP 被拿去挖矿”。前者是效率问题，后者是安全事故。大模型越好用、越自动化，这个风险就越被放大。
1.2 无沙箱执行的真实事故，远比想象中常见
说一个我实际遇到过的例子。当时团队做一个让模型帮忙处理 Excel 数据的小工具，模型生成了一段 Python 脚本，里面有一步是清理临时文件，它用了 shutil.rmtree('/tmp/xxx')。人写的代码大概率会检查路径前缀，但模型在 context 里看到了几个文件路径，直接拼了一段路径进去，结果把容器里一个挂载目录删掉了一半。代码在模型看来逻辑完全正常，但执行结果是破坏性的。
这还不是最严重的。行业里更常见的两个事故类型：
- 模型生成的代码里带了
os.system('curl ... | sh')这类下载执行逻辑，如果模型被 prompt 注入诱导，代码会去下载一段攻击脚本，然后本地执行。 - 模型跑一个递归遍历目录的代码，没有限制深度，也没有超时保护，几分钟内把宿主机 CPU 打满，整个服务跟着卡死。
这种事故的共同点是：行为不是模型“故意”的，而是模型的能力边界和运行环境之间的失配。没有沙箱，每次 AI 执行代码都是在赌。
1.3 沙箱需要兜住的四类风险
在做 OpenSandbox 这一类方案的时候，我习惯把风险拆成四类，这样设计隔离策略时思路会清晰很多：
| 风险类型 | 具体表现 | 沙箱对应的能力 |
|---|---|---|
| 恶意行为 | prompt 注入、模型生成恶意代码、下载执行外部脚本 | 资源隔离、网络白名单、只读文件系统 |
| 误操作 | 删库、覆盖配置文件、对宿主机造成破坏 | 文件系统隔离、权限最小化 |
| 资源耗尽 | 死循环、超大内存占用、海量日志输出 | 内存限制、CPU 配额、输出大小限制 |
| 数据外泄 | 模型把内部文件内容发送到外部接口 | 网络隔离、文件系统隔离、审计日志 |
这四个维度，是后面所有设计和配置的出发点。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. OpenSandbox 的隔离设计：把“信任边界”画清楚
2.1 多层隔离而不是一层隔离
OpenSandbox 的核心设计思路，一句话概括就是：代码进来，结果出去，运行环境不留存，每次都是全新环境。
我第一次看到这个设计理念的时候，觉得这像是给大模型“造了一间一次性的厨房”——所有的烹饪都在里面完成，做完菜只把菜品端出来，厨房连锅带碗全部销毁。这样即使 AI 在厨房里搞了什么名堂，也不会波及外面。
从实现层面，OpenSandbox 不是靠单一技术实现安全的，而是叠加了多个层级的隔离，每一层都有各自的防护目标：
- **容器