大模型代码执行安全：OpenSandbox沙箱隔离原理与工程实践

大模型写代码这件事，从 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 这一类方案的时候，我习惯把风险拆成四类，这样设计隔离策略时思路会清晰很多：

这四个维度，是后面所有设计和配置的出发点。

2. OpenSandbox 的隔离设计：把“信任边界”画清楚

2.1 多层隔离而不是一层隔离

OpenSandbox 的核心设计思路，一句话概括就是：代码进来，结果出去，运行环境不留存，每次都是全新环境。

我第一次看到这个设计理念的时候，觉得这像是给大模型“造了一间一次性的厨房”——所有的烹饪都在里面完成，做完菜只把菜品端出来，厨房连锅带碗全部销毁。这样即使 AI 在厨房里搞了什么名堂，也不会波及外面。

从实现层面，OpenSandbox 不是靠单一技术实现安全的，而是叠加了多个层级的隔离，每一层都有各自的防护目标：

• 容器层：用 OCI 容器隔离文件系统、进程空间、网络栈。容器内的进程看到的文件系统和网络都跟外部隔开。
• 内核安全层：通过 seccomp 限制系统调用，只允许必要的 syscall；通过 Linux capabilities 裁剪，去掉容器进程的提权能力。
• 资源配额层：通过 cgroups 限制内存、CPU、进程数。防止一个失控的进程拖垮宿主。
• 只读根文件系统：挂载只读 rootfs，容器内无法修改系统文件。需要临时写入的文件放在 tmpfs 中，运行结束全部销毁。

这种多层设计的好处是：单层被突破，还有下一层兜底。真实的安全边界从来不是一道墙，而是一组互相独立的墙。

2.2 运行时层面的细粒度管控

OpenSandbox 在运行时层面做的控制，是我觉得它跟“裸跑 Docker”最大的差别。

用过 Docker 的人都知道，docker run 默认给容器的权限比你想象的大很多。默认情况下容器内 root 用户的权限映射到宿主机上虽然受限，但依然存在不少风险面。OpenSandbox 的做法是把 Docker（或者底层容器运行时）暴露给用户的默认配置，收敛到最小可用集合：

• 去掉 NET_ADMIN、SYS_ADMIN 这类高危 capability，容器内无法改动网络规则或挂载文件系统。
• 默认关闭出网，容器内的代码默认无法访问公网。需要联网的场景，通过白名单的方式显式放行特定域名或 IP。
• 强制只读根文件系统，写操作只能落在指定的可写目录里。
• 限制进程派生的层数，防止模型生成一个无限 fork 的 fork bomb。
• 设置核心转储为不可用，避免进程崩溃时把内存数据写入磁盘。

这些细节单拎出来每一个都不难配置，但组合在一起，加上一套面向大模型调用场景的接口封装，才是 OpenSandbox 这类工具的真正价值。

2.3 结构化输出与执行审计：不只是隔离

一开始我以为沙箱只要管好隔离就够了，后来发现还远远不够。大模型执行代码之后，还需要把执行结果“喂回”给模型，让模型根据结果决定下一步动作。这时候如果沙箱只返回一个裸字符串，Agent 根本没法结构化地判断下一步怎么走。

OpenSandbox 的做法是，把一次代码执行抽象成一个结构化的事件，输出几个固定的字段：

json复制{
  "run_id": "8f3c1e2a7b5d4c6e",
  "status": "success",
  "exit_code": 0,
  "stdout": "hello world\n",
  "stderr": "",
  "elapsed_ms": 132,
  "memory_peak_mb": 34.2,
  "files_modified": [
    {"path": "/workspace/output.json", "size": 1024}
  ]
}

这个设计对大模型 Agent 特别友好。模型看到 status、exit_code、stdout、stderr 这样的结构化字段，就能判断运行结果，而不需要去解析一段可能混合了正常输出和错误输出的文本。files_modified 这个字段尤其关键——AI 写完代码之后经常要产出文件，沙箱把文件以产物（artifact）的形式返还，而不是让用户去容器里拷，这个体验差异很大。

同时，每一次执行都记录了 run_id、时间戳、资源占用、执行的代码全文。这些审计日志在跑测试、复现问题、安全排查的时候价值巨大。

3. 动手集成：把 OpenSandbox 接进 AI Agent

3.1 环境准备与部署

OpenSandbox 通常以一个独立服务的形式部署，AI 应用通过 HTTP 或 gRPC 接口跟它通信。我比较推荐这种“沙箱独立部署”的架构，而不是把沙箱逻辑嵌进主应用进程里。原因很直接：沙箱的崩溃、资源抖动、安全策略更新都不应该影响主服务；反过来，沙箱服务本身也需要一个干净、封闭的运行环境。

部署步骤大致是这样：

bash复制# 1. 拉取沙箱服务镜像
docker pull opensandbox/sandboxd:latest

# 2. 启动沙箱守护服务，暴露 8080 端口
docker run -d --name sandboxd \
  -p 8080:8080 \
  -v /var/run/docker.sock:/var/run/docker.sock \
  --privileged=false \
  opensandbox/sandboxd:latest

注意这里把宿主机的 Docker socket 挂载给了沙箱服务，因为沙箱服务需要动态创建容器。这个挂载本身是一个高权限操作，所以部署层面建议把 sandboxd 单独部署在一台专用的内网机器上，只对内部服务开放端口。

3.2 最小可运行示例：执行一段 Python 代码

部署好之后，接口调用方式非常直接。用 Python 请求库举例：

python复制import requests

response = requests.post(
    "http://localhost:8080/v1/run",
    json={
        "language": "python3",
        "code": """
print("hello from sandbox")
import socket
try:
    socket.create_connection(("www.baidu.com", 80), timeout=3)
    print("network: connected")
except Exception as e:
    print("network: blocked", str(e))
""",
        "timeout_ms": 10000,
        "memory_limit_mb": 256,
        "network": False,
        "write_dirs": ["/workspace"]
    },
    timeout=15
)

result = response.json()
print(result["status"])
print(result["stdout"])

这段代码的执行结果，stdout 里会同时包含 hello from sandbox 和 network: blocked。因为 network 参数设成了 False，沙箱内默认断网，socket.create_connection 会超时或直接报错。这个小小的网络开关，就是防止数据外泄的第一道闸。

3.3 参数调优：超时、内存、网络策略

OpenSandbox 的每个请求都推荐显式带上资源限制参数，而不是用默认值。我踩过的坑是：早期图省事，不传 timeout_ms，结果模型生成了一段 while True: pass 的死循环，沙箱里的进程一直占着 CPU 不放。虽然沙箱不会搞垮宿主机，但它会一直占着资源额度，导致后续任务排队。

建议的初始参数：

3.4 为什么用“结果描述”而不是命令行输出

把沙箱结果喂回给 LLM 的 prompt 工程，也是需要花一点心思的地方。一开始我直接把 stdout 拼到 prompt 尾巴上，发现模型经常误判。后来我把结果重新组织成一段结构化的描述，效果好了很多：

text复制任务执行结果：
- 状态: 成功
- 退出码: 0
- 标准输出: hello world
- 错误输出: 无
- 耗时: 132ms
- 峰值内存: 34.2MB
- 生成文件: /workspace/output.json (1024 字节)
请根据以上结果决定下一步操作。

模型和人类一样，给它一个混乱的文本和一份清晰的结果摘要，判断准确率差距非常大。尤其是 exit_code 非零的时候，模型需要根据错误信息推理修正方案，这时候 stderr 的完整内容还是得给出来，但要用明确的字段标记。

4. 把沙箱调稳的进阶配置与真实坑点

4.1 资源配额：别让一次模型失误打垮整个服务

资源配额是整个沙箱方案里最容易被轻视的一环。大家焦点都放在“代码是不是会被攻击”上，反而忽略了“代码是不是会把资源吃光”这个更常见的问题。

AI 生成的代码里，内存泄漏、递归无边界、超大数组分配，都太常见了。我给一个真实数字：某次测试里，模型写了一个 LeetCode 风格的算法题解，里面有个对二维数组的初始化写成了 [[0] * n] * n，这个写法在 Python 里会创建同一个内部列表的引用副本。模型本来只想开一个 1000x1000 的矩阵，结果实际运行时的内存分配方式导致内存占用几乎到了 1GB。如果没有 memory_limit_mb 限制，这个请求直接就把整个沙箱服务的内存吃掉了。

所以在接入 OpenSandbox 的时候，我强烈建议在统一网关层做一个默认资源配额兜底。就算某个调用方忘了传参数，也不能让它无限跑。这个兜底非常关键。

4.2 网络白名单与“两次执行”策略

网络策略是我在真实业务里花费最多时间调的一个维度。最安全的做法当然是让沙箱完全断网，但很多实际场景里，AI 生成的代码确实需要访问内部 API 或拉取依赖包。完全断网会让工具的实用性大打折扣。

我的方案是“两次执行”策略。

第一次执行，完全不联网。让模型生成代码、跑纯本地逻辑、本地文件处理。绝大多数数据整理、代码分析、测试生成任务，这一步就够了。

第二次执行才带上网络白名单。当模型明确说“我需要从某个地址拉取数据”时，再把它需要的域名加进白名单，重新提交执行。这个流程多了一次交互，但网络攻击面被压缩到了极小的范围。

沙箱的 network 配置支持两种模式：

python复制# 白名单模式：只允许访问指定域名
{
    "network": {
        "enabled": True,
        "allow_domains": ["api.internal.example.com"],
        "allow_ips": ["10.0.0.5"]
    }
}

注意 allow_domains 和 allow_ips 要同时配置。DNS 解析本身会暴露给沙箱内部，如果只配域名，沙箱内进程可以通过 DNS 查询探测内网 IP 的存在，这种信息泄露虽然量小，但在高安全场景下不能忽视。

4.3 踩坑实录：超时残留进程与只读文件系统的冲突

接入 OpenSandbox 几个月，有几个坑值得拿出来单独说。

坑一：超时后残留子进程。 模型生成的代码里，经常会用 subprocess.Popen 去起子进程。父进程超时被沙箱杀掉了，但子进程还活着，继续占着 CPU 或者监听端口。后来我们在沙箱里加了进程组隔离，杀掉父进程时连同整个进程组一起杀，这个问题才解决。这个细节做沙箱的同学一定要关注。

坑二：只读文件系统导致的诡异崩溃。 我们有一次遇到模型生成的代码在本地跑得好好的，进沙箱就崩溃，而且报错信息完全看不出原因。排查了一个多小时，最后发现是代码里调用了某个库，这个库在 import 的时候要在 home 目录写一个配置文件，而沙箱的根文件系统是只读的，导致 import 直接报错。解决方案是把可写目录挂载到代码实际需要的位置，这里也体现出审计日志的价值——没有日志，这种诡异问题几乎没法定位。

坑三：沙箱内时钟漂移。 这是最隐蔽的一个坑。某些沙箱实现里，容器的系统时间和宿主机不一致，模型生成的代码如果涉及到 datetime.now() 或者日志时间戳，就会产生错误的时间数据。测试代码没人在意时间，但一旦涉及数据同步、任务调度，时间偏差就会引发连锁问题。建议集成的时候检查一下沙箱时间与宿主时间的偏移。

4.4 日志和审计数据的价值

沙箱不只是隔离，它还是全链路可观测的关键节点。每次执行都有唯一 run_id，把模型生成的代码、运行结果、资源消耗、网络请求记录绑定在一起，这是一个 AI Agent 系统想要稳定运行的必需品。

实际运营中，我靠这套日志做过这几件事：

• 发现某个 prompt 模板触发的代码经常出现 os.system 调用，于是专门针对这类 prompt 加了人工审核。
• 通过内存峰值统计，发现某个模型版本生成的代码内存使用明显偏高，及时调整了配额策略。
• 复现线上问题的时候，直接按 run_id 把当时的代码原样拉出来跑一遍，不需要让用户重新描述问题。

如果沙箱没有审计日志，那它只是安全工具；有了审计日志，它同时成了调试工具和模型行为的画像工具。

5. 和主流方案放在一起比：OpenSandbox 不是万能药

5.1 四个主流方案的差异

很多读者会问：我用 Docker 不行吗？用 Firecracker 会不会更安全？这里我根据自己的实际经验做一个横向对比：

这里我想重点说一下 Firecracker。如果你只是拿它来跑 Python 脚本，那确实有点大材小用，启动一个 microVM 的耗时可能比你代码执行时间还长。但如果你的场景是“模型下载了一个未知的二进制文件并执行它”，那 Firecracker 才是正确选择——毕竟二进制文件可以调用的系统调用面太广了，纯容器方案的防御纵深不够。

5.2 按业务场景选型，不要盲追最安全

选沙箱方案，一条核心原则是：隔离强度和业务效率之间要找到平衡点。

如果你的场景是 Agent 自动跑测试、自动改代码、自动处理文件，代码是模型生成的 Python/Node/Shell 脚本，OpenSandbox 这类轻量沙箱完全够用，秒级启动、低开销、接口友好。这是大模型代码执行场景里最主流的需求。

如果你的场景是让模型去执行从网上下载的未知二进制文件，或者你的服务面向不可信的多租户开放，那必须上更强的隔离方案，比如 gVisor 或 Firecracker。此时的性能开销是为了安全性支付的合理成本。

如果你的场景是高并发、短任务、延迟敏感，那还要考虑沙箱的复用策略。频繁销毁重建容器开销不小，利用沙箱池预热一批就绪容器，把创建耗时提前消耗掉，是一个实用的优化方案。

5.3 什么时候不该用沙箱兜底

最后要泼一盆冷水：沙箱不能解决所有安全问题。

Prompt 注入的问题，不能指望沙箱来兜底。模型被诱导输出了恶意代码，沙箱确实能拦截它对外部系统的破坏，但它拦不住模型“合理地”执行了一段读取内部数据的代码——如果这段代码的意图就是读取文件，沙箱没法区分这是正常任务还是恶意行为。所以输入侧的 prompt 过滤、敏感指令识别，该做还得做。

另外，访问控制的最小化原则同样适用于 AI Agent 系统：能给只读权限就不要给写权限，能给单目录权限就不要给全盘权限。沙箱是最后一道防线，不应该也不可能是唯一一道防线。

我在实际操作中最深的体会是：把 OpenSandbox 接进 Agent 的这段时间，核心工作不是配置沙箱本身，而是想清楚“哪些信任可以给，哪些绝对不能给”。每次让 AI 有更多操作权限之前，先问自己一句：如果这段代码被恶意利用了，我能不能承受这个后果？这个习惯比任何工具都重要。