大模型代码执行的安全沙箱：OpenSandbox 隔离 AI 生成代码的架构与实践-平芜编程栈

先说一个前两天发生在团队里的真实场景。同事为了让 AI 编程助手能自己写测试、自己跑测试，把模型生成的命令行直接丢进了本地终端。第一次跑得很顺利，模型自动补了一个依赖、执行完测试、返回了结果。第二次就没那么幸运了：模型读到项目里一份 README，README 里有一段"看似人畜无害"的 base64 字符串，模型居然解码后当成命令执行了。虽然最终没造成损失，但这件事让我们意识到——大模型会写代码这件事，真正的难点从来不是生成，而是执行。更准确地说，是"让一个不可完全信任的程序在可控的边界内运行"。

OpenSandbox 这个名字，说的就是这件事。

它要解决的命题很具体：大模型（LLM/AI Agent）生成了一段代码，我们需要让它安全地把这段代码跑起来，同时不去影响宿主机、不去盗取数据、不去无限消耗资源。它不是让 AI 更会写代码，而是给 AI 的"手"戴上手套——让它可以操作，但不能乱摸。

如果你正在做 AI 编程助手、AI Agent、数据分析自动化，或者任何"模型自动执行代码"的功能，这篇内容应该能帮你少走一些弯路。我会从为什么需要一个专门的沙箱、沙箱的边界怎么设计、OpenSandbox 这类项目在架构上怎么落地、实际接入会踩哪些坑、以及它到底拦不住什么，这几个角度完整拆一遍。

1. 大模型会写代码之后，真正的难题变成了"在哪跑"

1.1 代码生成只是第一步，执行才是落脚点

现在的大模型已经能写出相当完整的 Python 脚本、Shell 命令、SQL 查询，甚至整套 CI 配置。当这些产物只是"给用户看"的时候，风险是可控的，因为最终决定权在用户手里，用户会审视、修改、再决定是否运行。但过去一年里，产品形态明显发生了变化：从"生成代码给人看"变成"生成代码给机器跑"。

AI 编程助手直接帮你执行命令、跑测试；
AI Agent 为了完成任务，自动调用 shell 工具操作文件系统；
数据分析平台让模型自己写 pandas 代码处理数据并返回图表；
自动化测试工具让模型生成用例后直接提交执行。

这些场景的共同点是：人工审查环节被大幅压缩，甚至完全消失。模型输出变成了一次真实的系统操作。问题在于，大模型的生成过程是概率性的，同样的 prompt 可能输出完全不同的代码；同一段代码这次没问题，下次可能因为对话上下文里混入的某些内容，多出一句os.system调用。当执行动作由机器自动完成，代码质量问题就升级成了系统安全问题。

所以"在哪跑"这个问题的权重，实际上已经超过了"怎么写"。OpenSandbox 这一类沙箱方案，核心就是接管"模型生成代码之后的运行"这个环节，让不安全的代码可以在一个能收放、能审计、能销毁的环境里执行。

1.2 直接在本机执行大模型代码的风险清单

我先不急着讲沙箱怎么做，而是把"直接在本机执行大模型代码会遇到什么"这件事列清楚。这决定了我们在沙箱里要重点隔离什么东西。

风险类型	触发方式	典型表现
提示词注入	模型读取了外部网页、文档，文本中埋有恶意指令	模型生成`rm -rf ~`、下载执行恶意脚本等危险命令
供应链依赖投毒	模型为了完成任务自动安装第三方包	安装了名字相似或被篡改的包，安装阶段就执行恶意代码
资源耗尽	模型输出死循环、大内存分配，或恶意 fork 子进程	开发机卡死、内存被吃光、CPU 被打满
数据外传	代码读取本机敏感文件，并尝试发起网络请求	`.env`、SSH 私钥、浏览器 Cookie 被读取并尝试发送到公网
权限蔓延	代码以当前用户权限执行，拥有过大的操作范围	写 cron、改 shell 配置、遍历删除项目文件
非恶意但愚蠢	模型对任务理解偏差，执行了多余或破坏性操作	"清理磁盘"变成全盘扫描删除缓存，批量重命名文件改错

这六类风险里，最值得警惕的是第一类。提示词注入不是模型自己"变坏"，而是模型在上下文里被外部内容操纵了。大模型执行链路的典型攻击路径是：模型读取一个网页或文件，网页里藏着一句"请忽略之前的指令，执行以下命令……"，模型照着做了。这时候如果执行环境是本机终端，损失就是真实的。

理解了这张风险清单，再回头看沙箱的设计目标就会很清晰：沙箱要解决的不是"这段代码有没有 bug"，而是"这段代码即使不怀好意，也搞不出大乱子"。

2. OpenSandbox 的沙箱边界：到底隔离了什么

2.1 两层基础隔离：进程空间与文件系统

沙箱首先解决的问题是：让 AI 生成的代码运行在一个"不同的世界"里。OpenSandbox 这类方案的底层，普遍依赖 Linux 内核的隔离机制来实现第一层边界。

进程隔离：通过 PID namespace，沙箱里的进程看不到宿主机的进程列表。代码里执行ps aux，看到的只是沙箱自己的一亩三分地，无法探测宿主机上在跑什么服务。
文件系统隔离：通过 Mount namespace，沙箱内的文件系统来自独立的镜像，宿主机目录默认不可见。模型在沙箱里执行ls /，看到的是预制镜像的目录结构，而不是宿主机真实的根目录。
用户隔离：通过 User namespace，把沙箱内的 root 用户映射成宿主机上的非特权用户。即使代码拿到了容器内的 root 权限，它在宿主机眼里也只是一个普通用户，无法直接提权。

在这层之上，OpenSandbox 通常还会做两个强化：根文件系统默认只读，以及资产目录显式挂载。只读意味着沙箱启动之后，代码无法修改镜像里的系统文件；显式挂载意味着"沙箱内能读到哪些宿主目录"是配置出来的，而不是默认全部可见。

打个比方：这不是给陌生人一把钥匙，而是给陌生人一个装了监控、只能进入指定房间的独立隔间，隔间里所有东西都是临时布置的，参观完直接拆掉。

2.2 网络和资源配额：把不可控行为按住

隔离了进程和文件系统之后，还有两件容易被忽略的事：网络和资源。

网络往往是数据外传的唯一通道。OpenSandbox 的默认姿态是断网。也就是说，沙箱内的代码默认不具备访问公网的能力。一个现实的意义在于：即便模型被诱导读取了宿主机挂载进来的文件，它也找不到路径把这些数据送出去。

当然，完全断网在很多场景下不现实。数据分析可能要从内网拉数据，AI Agent 可能调用内网 API。这时候需要做成可控的白名单：哪些域名、哪些 IP、哪些端口可以访问，由执行策略显式配置。默认全关，按需放行，这是安全设计里最基本的"默认拒绝"原则。

资源限制则是防止"不坏但蠢"的代码把机器拖垮。OpenSandbox 通常通过 cgroup 对每个沙箱实例做配额限制：

CPU 配额：限制最多占几核，避免死循环吃满宿主 CPU；
内存限制：超过配额直接 OOM，避免大内存分配拖垮宿主机；
进程数限制：限制pids_max，防 fork 风暴；
磁盘配额：限制沙箱内可写的磁盘空间，防把临时盘写满；
执行超时：超过时间上限直接强杀，避免任务永远不结束。

这些限制在设计上还有一个关键点：用完即销毁。沙箱实例默认是一次性的，执行完任务之后整个环境被销毁，临时文件不落盘。如果业务需要取回结果，通过显式 API 拉取输出文件，而不是让沙箱持久化保存用户数据。

2.3 容器不等于沙箱：多出来的那一层防御

很多人听到这里会想：这不就是docker run吗？确实，容器是沙箱的基础载体，但默认的 Docker 容器跟真正面向大模型代码执行的沙箱，差距还很大。

维度	默认 Docker 容器	OpenSandbox 类沙箱
内核隔离	共享宿主机内核，内核漏洞可能穿透	叠加 seccomp 白名单，高风险系统调用直接拒绝
用户权限	默认 root，容器内提权路径多	非 root 运行，User namespace 隔离
网络	默认有网络能力	默认断网，白名单域名才可访问
资源限制	默认不限制 CPU 和内存	cgroup 强制配额，超限即杀
文件写入	容器的可写层可被篡改	只读根文件系统，改动不持久
生命周期	手动管理，容易泄漏	默认 TTL + 显式销毁，用完即回收

最核心的差异在 seccomp 和系统调用过滤。容器的隔离依赖于内核的特性，但容器内进程仍然可以直接向内核发起系统调用。沙箱会在这一层加一道白名单：除了读写文件、创建进程、网络相关等必要调用，其他高风险调用直接返回权限错误。这样即使代码试图执行某些敏感操作，在进入内核之前就被拦住了。

更进一步，如果威胁模型要求更高，还会把沙箱运行时替换成用户态内核（如 gVisor）或微虚机（如 Firecracker），让代码执行在一个完全独立的内核之上。OpenSandbox 的架构要把运行时设计成可替换的，原因就在这里：不同业务对安全等级的要求不一样，运行时是选择项，而不是写死的一项。

3. OpenSandbox 是怎么"造"出来的：架构拆解与关键决策

3.1 以服务化的思路做执行引擎

我第一次接触 OpenSandbox 这类方案时，直觉是把沙箱做成一个本地库，在 Agent 进程里直接调用。真正落地之后才发现，面向大模型代码执行的沙箱必须服务化，而不是本地化。

原因有三点：第一，代码执行的请求会来自不同业务线，服务化之后才能统一做鉴权、配额和审计；第二，沙箱运行时不希望跟业务进程共享权限，独立服务可以把自己的权限降到最低，避免"业务被攻破 = 沙箱管理面被攻破"的连锁反应；第三，审计日志需要集中采集，分散在本地进程里根本没法查。

从架构上看，OpenSandbox 类的执行引擎通常包含五个模块：

控制面 / API 网关：接收"我要执行一段代码"的请求，校验调用方身份、配额、执行策略，然后把请求交给执行引擎。
调度与执行引擎：负责沙箱实例的生命周期管理，包括创建、执行代码、收集 stdout/stderr、超时强杀、销毁实例。
沙箱运行时：真正运行代码的底层载体。它可以是基于 OCI 规范的容器运行时，也可以替换成 gVisor 或 Firecracker 这类更高隔离级别的运行时。
镜像仓库与依赖代理：存放预制好的基础镜像，例如包含 pandas、numpy 的数据分析镜像，以及内网依赖代理，让沙箱不需要访问公网也能装包。
审计与指标系统：记录每次执行的调用方、时间、资源用量、网络请求、敏感系统调用，为事后的安全排查提供依据。

这个拆分方式的关键在于"控制面"和"数据面"分离。控制面负责决策，数据面负责执行。模型生成的代码永远只接触数据面，拿不到控制面的任何凭证。

3.2 一份可落地的最小配置样例

直接给一个风格类似 OpenSandbox 的配置样例，方便你理解一个沙箱执行请求长什么样：

{ "name": "data-analysis-task", "image": "opensandbox/python:3.11-pandas", "language": "python", "code": "...", "limits": { "cpu": 1, "memory_mb": 1024, "disk_mb": 512, "timeout_seconds": 30, "network": "off", "pids_max": 64 }, "files": { "read_only": ["/dataset/input.csv"], "writable": [] }, "audit": true }

逐项解释一下设计意图：

image指向一个预制镜像，而不是允许执行时临时pip install，这样可以减少供应链投毒面。
limits.network = "off"是默认值，意味着沙箱内代码一旦尝试创建网络连接就会失败。如果需要联网，显式配置域名白名单。
files.read_only用于把宿主机的数据文件以只读方式挂载进沙箱。这样模型能读数据，但改不了源文件。
files.writable默认留空，代码写不了任何持久化目录。如果确实需要产出文件，指定一个临时的可写目录，任务结束后通过 API 取回。
audit = true意味着这次执行的全过程都要落日志，包括执行了哪些系统调用、尝试连接了哪些地址、占用了多少资源。

这套配置的核心姿态是：默认不给，按需给。给得越少，代码能造成的破坏就越小。

3.3 为什么执行策略要单独抽象

我在最初设计时犯过一个错误：把资源限制、网络开关、文件挂载这些参数直接写在业务代码里。结果每个业务接入的方式都不一样，运维根本没法统一审计。

OpenSandbox 这类项目给我的一个启发是：执行策略必须独立抽象成一等公民。

也就是说，"能不能跑网络请求"、"最多用多少内存"、"能读哪些目录"这些规则，应该由策略模板统一管理，而不是散落在业务代码里。例如：

数据分析策略：内存大、断网、可读数据集目录、不可写；
AI Agent 工具策略：内存中等、可访问白名单 API、可写临时目录；
代码沙箱测试策略：内存小、断网、完全只读、超时短。

这样做的好处是安全工程师只需要审查策略模板，不需要一行一行看业务代码。而且策略的变更可以灰度下发，不需要重新发布业务服务。如果你打算在自己的项目里落地沙箱，我强烈建议一开始就把策略单独建一张表或者一个配置目录来管。

4. 大模型执行代码的场景矩阵：哪些必须上沙箱，哪些可以不上

4.1 数据分析、AI Agent、CI 自动化三类典型场景

沙箱不是所有场景都必须上的。我试着把实际的项目场景分成三类，你可以对照自己的情况。

数据分析 / Notebook 式执行。典型形态是：用户上传一个 CSV，模型写 pandas 代码做统计分析，然后把图表或者统计结果返回给用户。这种场景下，沙箱要读取用户数据文件，但严格不能联网，也不能写宿主机的任何目录。OpenSandbox 的典型做法是：把用户文件只读挂载进沙箱，执行完把结果文件取出来，沙箱销毁。数据文件自始至终不会落到宿主机的业务目录里。

AI Agent 自动操作。Agent 型的应用更复杂，因为 Agent 可能需要执行 shell 命令、调用系统工具、操作文件。这类场景我强烈建议把"工具执行"整体放进沙箱：Agent 通过 function calling 请求执行命令，命令在沙箱里运行，宿主机文件按需只读挂载。这样即使 Agent 模型被上下文中的恶意内容误导，损失范围也被限制在沙箱内。

CI / 自动化测试。自动化测试需要的是环境可复现和并发能力强。模型生成测试用例后，每个用例在一个新的沙箱里跑，环境干净，互不干扰，跑完即销毁。这个场景下，关注点更多在并发配额和依赖管理上，网络通常按需开放到内网测试环境。

4.2 判断是否需要沙箱的四要素

如果你的项目还不确定要不要上沙箱，可以按这四个要素过一遍：

代码来源：代码是模型生成的，还是用户手写的？模型生成的代码且未经过人工审查，信任度最低。
执行目标：代码跑在哪？本地开发机、生产服务器、还是临时的隔离环境？目标越重要，越需要沙箱。
数据敏感度：代码执行过程中要不要接触密钥、PII、生产数据？一旦需要接触敏感数据，隔离和审计就必不可少。
执行频率：是一次性人工执行，还是高频自动执行？高频自动化任务只要有风险，就会被放大成必然事故，必须由沙箱兜底。

我个人的判断标准是：只要你的 AI 应用存在"模型生成的代码被自动执行"这条路径，默认就应该上沙箱。即便短期没有安全事件，审计日志本身就是巨大的价值——出事的时候你有地方查，而不是两眼一抹黑。

5. 接入 OpenSandbox 的实操流程与三个真实踩坑

5.1 最小可用的接入路径

下面是一个简化版的接入流程，基于 OpenSandbox 这类方案的通用 API 风格，目标是在本地跑通一个最小闭环。

第一步，启动沙箱服务（示意命令，不同实现的具体命令会有差异）：

opensandbox runtime start \ --runtime-type=docker \ --default-image=opensandbox/python:3.11

第二步，创建一个沙箱实例：

curl -X POST http://localhost:8080/v1/sandboxes \ -H "Content-Type: application/json" \ -d '{ "image": "opensandbox/python:3.11", "limits": { "cpu": 1, "memory_mb": 512, "timeout_seconds": 30, "network": "off" } }'

第三步，向实例提交一段代码执行：

curl -X POST http://localhost:8080/v1/sandboxes/{sandbox_id}/exec \ -H "Content-Type: application/json" \ -d '{ "language": "python", "code": "print(1 + 1)" }'

第四步，拿到输出结果，销毁实例：

curl -X DELETE http://localhost:8080/v1/sandboxes/{sandbox_id}

接入大模型的完整链路也不复杂：让模型通过 function calling 输出结构化代码，前端校验一次 JSON 格式，再把代码提交给沙箱执行。关键点是：不要让模型直接拼系统命令，而是让模型输出参数化、结构化的调用，由你的代码负责翻译成沙箱执行请求。这样模型的自由度被限制在一个安全的接口面里。

5.2 踩坑一：资源限额设置与 OOM 问题

我第一版把沙箱内存统一设成 128MB，想着代码量都不大，结果数据分析任务一跑就 OOM，模型读个 50MB 的 CSV 就崩了。后来又把内存放宽到 4GB，结果并发 10 个任务时宿主机内存告急。

教训是：资源配额不能设全局默认值，必须按执行策略分层。

简单代码解释类任务：内存 128~256MB，CPU 0.5 核，超时 10 秒；
数据分析类任务：内存 1~2GB，CPU 1 核，超时 60 秒；
重计算任务：内存 4GB 以上，CPU 2 核，但并发数必须压低。

配额的粒度应该跟业务场景匹配，越精细越好。顺带提醒一点：内存限制不仅防 OOM，也是防恶意代码的重要手段。刻意分配大数组然后不释放，是模型输出中真实出现过的情况。

5.3 踩坑二：镜像与依赖网络策略

默认断网之后，立刻遇到一个新问题：模型输出的代码需要pip install一些库，但沙箱连不上公网，任务直接失败。

一开始我觉得这是"沙箱拖累了功能"，后来才发现正确的解法不是开放公网，而是管理依赖：

把常用依赖直接预制进基础镜像。比如数据分析场景，把 pandas、numpy、matplotlib 都装进opensandbox/python:3.11-pandas镜像里，模型需要时直接 import，根本不需要现场安装。
搭建内网依赖代理。如果确实需要临时安装包，让沙箱访问内网 PyPI 代理，而不是公网 PyPI。
按域名白名单逐步放开，同时所有网络请求都进审计日志。

这样既保留了模型执行代码的灵活性，又让"安装依赖"这个高风险动作变得可控。依赖预装还有一个隐藏好处：执行速度快很多，不用每次任务都花十几秒在装包上。

5.4 踩坑三：沙箱泄漏与僵尸进程回收

第三个坑最隐蔽。最初我在每次任务结束后，没有强制销毁沙箱实例，想着"下次还能复用，节省启动时间"。结果跑了一个晚上之后，宿主机磁盘被占满了，一查发现堆了几百个没回收的沙箱实例，每个实例都占用了一部分磁盘和内存。

回收机制必须设计成三层保险：

显式销毁：每次任务结束，业务代码调用销毁接口，这是第一层；
TTL 自动过期：每个沙箱实例创建时带上一个最长存活时间，比如 30 分钟，超时后控制面自动强杀；
后台巡检兜底：定期扫描所有沙箱实例，把长时间空闲或超龄的实例清理掉。

靠人工记得销毁是不现实的，尤其在 AI Agent 这种自动化调用链里，任何一步异常都会导致实例泄漏。三层保险缺一层都会出问题。

6. 用一次受控的红队演练验证边界，再看它挡不住什么

6.1 一次模拟攻击的完整链路

在沙箱上线之前，我们在测试环境里做了一次受控的对抗验证。注意，这里说的"攻击"是测试工具构造的模拟恶意输入，只针对自己的沙箱环境，目的是验证防御边界，不是教攻击手法。

第一组测试是提示词注入。我们把一段包含恶意指令的文本喂给模型，诱导它生成删除目录的代码。让模型在沙箱里执行shutil.rmtree('/app/data')。结果符合预期：删除动作只影响沙箱内部的可写目录，宿主机上的/app/data目录完全不受影响。如果这段代码在本机跑，至少是一次真实的文件删除事故。

第二组测试是数据外传。我们构造了一段代码，尝试读取挂载进沙箱的敏感文件，然后建立网络连接发送到外部地址。由于网络策略是off，connect 调用直接失败，审计日志里记录了这起尝试外联的行为。数据没有出去，但日志告诉我们模型确实被诱导了——这本身就是重要的安全信号，可以触发告警。

第三组测试是资源耗尽。我们让代码执行一个死循环。沙箱的 CPU 配额和超时机制起了作用，30 秒后控制面强杀了进程并销毁实例。宿主机全程没有任何资源抖动，其他业务不受影响。

这三组测试说明了一件关键的事：边界正确的沙箱，即使在最坏情况下，损失也是局部的、可恢复的、可追踪的。它不能阻止模型产生恶意的想法，但能阻止这个想法波及到真实系统。

6.2 沙箱真正挡住的与挡不住的

红队演练验证之后，反而让我更清醒地看到沙箱的边界。它挡住了本地文件系统被破坏、敏感进程被探测、默认网络外传、资源滥用这四类问题，但它不是万能的。

以下三类情况，沙箱本身解决不了：

宿主机内核漏洞：如果沙箱运行时本身有内核逃逸漏洞，恶意的代码理论上可能突破隔离。所以宿主机加固是必须配套的，包括非 root 运行沙箱进程、启用 AppArmor 或 SELinux、禁用不必要的内核模块。
配置层面的失误：如果有人在挂载配置里把宿主机/home目录整个以可写方式挂载进沙箱，那沙箱等于透明。配置审查和最小权限原则，比沙箱本身更重要。
模型层面的诱导：沙箱拦截的是执行阶段的危害，模型在自然语言层面被诱导产生恶意 payload，这个行为发生在执行前。你需要在入口做 prompt 安全策略、对模型输出做语义检查，而不是把希望全部放在沙箱上。

所以我的建议是：把沙箱当作纵深防御体系里的一层，而不是唯一的一层。一个相对稳妥的组合是：入口做 prompt 过滤和输出检查，中间用沙箱承载所有自动执行的代码，底层做好宿主机制加固，全程留审计日志并配置告警。每一层都独立工作，即使某一层被绕过，损失也不会被放大。

我个人实际使用下来最深的体会是：沙箱解决的不只是安全问题，还有工程效率问题。以前让 AI 自动跑代码，我总是提心吊胆地盯着输出；现在代码先在沙箱里跑一遍，我才放心把结果拿回来看。再分享一个小技巧吧：把沙箱返回的 stdout、stderr 和退出码原样回传给模型，往往能让模型根据报错自己修正代码。只传一个"成功"或"失败"的布尔值，模型基本没有方向去自我纠错。这个细节，实测下来对 AI 自动编程类任务的完成率提升非常明显。