写了好几个月的 AI 应用，我越来越觉得一件事很有意思：让大模型“写代码”其实不难，难的是让它在你的机器上“跑代码”而不把整个系统搞挂。项目一多，需求就从“帮我生成一段 Python 脚本”变成了“让 Agent 自己写完、自己执行、自己看结果”，这时候如果不给代码执行套一层可靠的隔离，大模型就成了一个拿着管理员权限但完全不可控的实习生。OpenSandbox 这名字听起来像某种玩具项目，但它解决的问题非常现实：如何让大模型在一个可控、可审计、可销毁的环境里安全地执行代码。这篇文章我会从风险模型、隔离方案选型、架构拆解到部署实操，完整讲一遍我落地这类沙箱执行环境时的思考过程，适合正在做 AI Agent、AI 编程工具、数据分析自动化，或者单纯想给“大模型插件”加一层安全壳的开发者看。

我最初接触 OpenSandbox 的动机很朴素：团队里有人做了一个“让模型分析 Excel 表格”的内部工具，第一次测试，模型为了算平均值，直接跑了一个os.system('rm -rf /tmp/cache')，好在是在容器里，不然整台开发机的临时文件全没了。那次之后我意识到，凡是让大模型接触真实执行环境的地方，必须有一道物理级别的边界。

1. 大模型“动手执行代码”之后，风险到底藏在哪

1.1 从“生成代码”到“执行代码”，本质是一次信任跃迁

很多人对大模型执行代码的风险没有概念，是因为他们习惯了“生成代码——人工检查——手动运行”这个流程。人在这个链条里充当了安全阀：代码是你审过的，后果是你承担的。但一旦进入 Agent 形态，模型通常会自主完成“理解任务—生成代码—执行—读取结果—修正”的循环，安全阀被拿掉了。

举个最常见的场景：你让 Agent 帮你在服务器上排查磁盘占用，它可能会先执行df -h，然后根据输出继续执行du -sh /home/*，最后为了“清理空间”直接跑rm -rf /home/old_logs。如果这个环境没有隔离，且权限没有收敛，一次判断失误就是数据事故。更麻烦的是，大模型的代码生成带有概率性，同样的任务跑十次，可能有三次会写出没料到的危险调用，这种不确定性正是“完全信任”的大敌。

所以，问题的核心不是“模型会不会写错代码”，而是“模型写错之后，系统能不能承受”。OpenSandbox 这类方案做的事情，就是把执行环境压缩成一个一次性、可丢弃、与宿主机隔离的“飞地”，让模型在里面随便折腾，出了问题销毁重来。这也是“沙箱”这个词在 AI 场景下的真正含义：不是为了跑不信任的第三方程序，而是为了给不可预测的模型行为买一份保险。

1.2 四类高频威胁：提示词注入、恶意依赖、资源失控、数据泄露

我把工作中真实遇到和可以预见的风险归成四类，刚开始做方案的时候，建议先把这四张牌都想到，再去碰技术细节。

提示词注入是目前最阴险的一类。我曾经用一段嵌在网页里的<img src=x onerror="console.log('ignore previous instructions...')">文本做过测试，模型读完之后真的试图调用系统命令。关键是，这种攻击文本不需要多精巧，普通的聊天对话都可能触发，更不用说在网页抓取、文档解析这种场景下。

恶意依赖则更隐蔽。模型为了“用起来方便”，经常会在沙箱里执行pip install，但包名可能被拼写错误或者被恶意仿冒。如果沙箱没有配置可信任的软件源白名单，这一步相当于让模型自己给自己开门。至于资源失控和数据泄露，靠人为盯着是不可能的，必须靠系统层面的配额和网络策略兜底。

这些风险叠加在一起，传递出一个信号：单纯给 Agent 一个 Docker 容器是不足以应对的，你需要的是一个有默认拒绝策略、可编排、能快速启停的执行环境。这就引出了 OpenSandbox 这一类方案的设计核心。

2. OpenSandbox 的隔离设计：为什么不是普通 Docker

2.1 隔离级别选型：进程沙箱、容器沙箱、微虚拟机沙箱

市面上做“代码执行隔离”的方案不少，粗分有三类：进程级沙箱、容器级沙箱（Docker 这类）、微虚拟机级沙箱（Firecracker、gVisor 这类）。它们在隔离强度、启动速度、资源开销上有明显的取舍。

我最早图省事，直接用 Docker 跑模型生成的代码。优点是接入快，镜像生态好，一个python:3.11-slim加上挂载目录就能开跑，但用的时间久了发现两个硬伤：第一，容器共享宿主机内核，一旦模型代码里出现针对内核漏洞的逃逸载荷，隔离层就形同虚设；第二，Docker 生命周期管理完全靠外部编排，沙箱因为异常崩溃后，残留容器清理不及时会堆积资源。做安全隔离，不能赌“模型不会写出逃逸代码”。

进程级沙箱（比如直接在子进程里加 seccomp 限制）启动速度最快，轻量到几乎没有额外开销，但限制也最明显：沙箱与宿主机仍然共享文件系统、网络栈和大量内核接口，能隔离的“攻击面”有限，更适合信得过的代码做故障隔离，不适合拿来隔离模型生成的不可信代码。

微虚拟机方案（如 Firecracker）是当前这一类工具的主流选择。它在宿主机上以极轻量的方式启动一个个微型虚拟机，每个机器都跑独立内核，内存开销可以控制在几十 MB 级别，启动时间在几百毫秒到一两秒之间。对 AI 场景来说，这个强度和速度的平衡点非常舒服。OpenSandbox 走的正是这条路线——以微虚拟机的内核隔离作为“物理边界”，再叠加一层资源配额和应用层策略。

2.2 核心模块拆解：控制面、执行单元、镜像管理与 MCP 接入

看一个沙箱方案是否好用，我习惯先看它的架构是否把“控制面”和“执行面”分开了。OpenSandbox 的模块划分基本符合这个逻辑，我拆成四个部分来看：

第一是控制面（Manager / API Server），负责接收大模型应用的执行请求、调度沙箱生命周期、记录执行日志。你可以把它理解成“调度前台”，所有的create_sandbox、run_code、kill操作都打到这一层。这一层不实际执行任何用户代码，所以即使出问题，也不会污染业务主进程。

第二是执行单元（Sandbox Runtime），也就是微虚拟机实例本身。每个执行单元都有独立的文件系统、网络栈和进程空间。实际执行代码的任务在单元内部完成，执行完毕之后，整个单元可以被整体销毁。这种“用完即焚”的模式，让 Agent 在几分钟前“读取过什么文件、下载过什么依赖”变得不再重要，因为环境本身消失了，残留风险也随之消失。

第三是镜像与文件系统管理。沙箱要能跑代码，光有内核不够，还得有根文件系统：Python 解释器、常用库、系统工具链都打包在基础镜像里。OpenSandbox 在创建沙箱时会按需加载镜像，并且支持通过快照方式保存某个沙箱的状态，供后续会话复用。

第四是 MCP（Model Context Protocol）接入层。MCP 这两年已经成为大模型应用接入外部工具的事实标准，OpenSandbox 以 MCP Server 的形式暴露沙箱能力，意味着任何支持 MCP 的客户端都可以把“执行代码”当成一个普通工具来调用，而不需要为每个应用定制集成代码。

整个调用链路通常是这样的：Agent 收到用户指令，判断需要执行代码，随即通过 MCP 调用沙箱服务——控制面安排一个执行单元，把代码和输入数据塞进去，等待运行结果，把 stdout、stderr、退出码返回给 Agent，然后销毁执行单元。如果 Agent 还需要后续交互，可以保持沙箱存活并继续追加指令。

2.3 资源上限与网络策略：默认拒绝比默认放行稳妥得多

安全设计有个容易被忽略的原则：白名单永远比黑名单好维护。OpenSandbox 的资源配额和网络策略，应该默认照着“最小授权”去配。

以网络策略为例，很多代码执行任务根本不需要访问外网：模型只是处理一段文本、跑一个算法，最多访问内部数据库。那我就不应该给它“任意出站”的权限，而应该在需要时按域名或 IP 白名单放行。这样即使模型代码被注入，恶意脚本想向外回传数据也得先过网络这一关。我在实际配置里，会把常规任务对应的沙箱设为“无外网”，只有明确需要抓取网页、下载依赖的任务，才单独开一个带白名单出站规则的沙箱。

资源上限也是同理。给沙箱设置 CPU 配额、内存上限、磁盘上限和执行超时时间，不是为了防止“正常代码跑不了”，而是为了给“异常代码”一个快速终结的信号。一个跑了 5 分钟的while True: pass大概率是出问题了，直接杀掉比等它自己结束安全得多。具体的参数怎么配，我在下一节的实操部分会给出参考值。

3. 实操：部署 OpenSandbox 并跑通第一个安全执行任务

3.1 环境准备与部署方式

OpenSandbox 的部署方式跟大多数同类工具类似，最开始可以直接用 Docker Compose 把控制面服务拉起来。生产环境建议拆开部署，但本地验证阶段，单机部署完全够用。

前置条件就三件事：一台 Linux 机器（macOS 也能跑，但虚拟化层支持不如 Linux 直接）、安装好 Docker 和 Docker Compose、保证至少有 4GB 以上可用内存。如果打算跑比较大的数据分析任务，内存建议留到 8GB 以上。安装命令很简单：

# 克隆项目并进入目录 git clone https://github.com/opensandbox/opensandbox.git cd opensandbox # 复制环境变量配置 cp .env.example .env # 启动控制面与默认镜像管理服务 docker compose up -d

启动完成后，默认会暴露一个 HTTP API 端口。你可以先访问健康检查接口确认服务已经就绪：

curl http://localhost:8000/api/v1/health

看到{"status":"ok"}类的返回，说明控制面已经正常工作。如果访问不通，优先检查是不是防火墙没放行端口，或者 Docker 容器没正常启动。

3.2 创建沙箱并执行第一段 Python 代码

第一次跑通代码执行，我建议用官方 Python SDK 做最小验证。安装 SDK 之后，核心操作就三步：与服务端建立连接、创建沙箱实例、在实例里执行代码。我给出一个可以直接复制的示例：

import os from opensandbox import Sandbox # 连接控制面服务，地址和密钥按实际环境填写 client = Sandbox( api_key=os.environ["OPENSANDBOX_API_KEY"], endpoint="http://localhost:8000", ) # 创建沙箱实例，指定运行时和资源上限 sandbox = client.create( runtime="python:3.11-slim", memory_limit="2GB", cpu_limit=1, timeout=120, ) # 在沙箱内执行代码，返回结果包含 stdout、stderr 和退出码 result = sandbox.run(""" import math print(math.sqrt(144)) print("hello from sandbox") """) print(result.stdout) # 12.0 / hello from sandbox print(result.exit_code) # 0 # 用完后销毁，彻底释放资源 sandbox.kill()

这段代码里有几个细节值得展开说。创建沙箱时如果没有显式指定内存和 CPU 限制，服务端会使用默认值，但生产环境我建议永远显式声明，因为不同任务对资源的诉求差异太大了。timeout参数也很重要，它控制的是单次run调用的最长执行时间，超时会被强制终止，防止代码里出现真正的死循环。

执行结果返回后，stderr和exit_code一定要传给大模型。很多 Agent 应用只取 stdout，结果模型看不到报错信息，会在同一段错误代码上反复重试，既浪费算力又浪费时间。把完整的运行结果（包括退出码）交给模型，它才能根据真实错误信息修正代码。

3.3 通过 MCP Server 接入大模型应用

SDK 直连适合程序内部调用，但如果你的 AI 应用是通过 MCP 协议接入外部工具的，OpenSandbox 可以直接作为一个 MCP Server 挂在客户端里。这意味着你可以在支持 MCP 的桌面客户端或 Agent 框架中，直接给模型增加一个“代码执行器”工具。

以配置文件的方式接入 MCP Server，大概长这样：

{ "mcpServers": { "opensandbox": { "command": "opensandbox-mcp", "args": ["--endpoint", "http://localhost:8000"], "env": { "OPENSANDBOX_API_KEY": "your-api-key" } } } }

配置好之后，客户端会自动发现并注册一个名为execute_code之类的工具。之后你在对话里让 Agent“帮我跑一段 Python 算一下上个月销售数据的中位数”“把这个 CSV 做一次去重并统计每列的缺失值”，它会自动把任务拆解成代码，发到 OpenSandbox 里执行，再把结果返回给你。

这里有一点要提前心理建设：模型一旦可以执行代码，它的“自主性”会肉眼可见地变强，同时它调用的频率也会变高。一个简单的数据分析任务，模型可能反复创建沙箱跑好几轮。所以我在接入 MCP 之后做了一件事：在应用侧加了调用频率限流，并在沙箱服务侧设置了单会话最大执行次数，防止模型“热情过头”把资源耗尽。

3.4 从“能用”到“好用”：几个值得调整的配置

跑通最小链路之后，我建议在生产环境里调整这几个配置，它们的性价比非常高：

超时时间不要给太长。单次代码执行建议默认 30~60 秒，最长不要超过 5 分钟。绝大多数正常的数据处理任务在 30 秒内能结束，跑超过 5 分钟的任务要么是数据量真的太大，要么是代码出了问题。把超时设短，牺牲的是处理极大任务的灵活性，换来的是系统不会被失控任务拖死。

日志必须采集到外部。沙箱销毁之后，里面的文件系统就没了，如果日志只写在沙箱内部，等于没写。正确的做法是在控制面把每次执行的任务 ID、代码摘要、输出摘要、退出码都同步到外部日志系统，比如 Elasticsearch 或者简单的文件追加。这一点在事后排查“模型到底跑过什么命令”时极其重要。

如果有多个团队共用一套沙箱服务，一定要在控制面开启项目/租户隔离。一个团队的任务不应该能看到另一个团队的文件系统快照，这属于最基本的多租户卫生。

4. 落地时的常见问题与排查经验

4.1 提示词注入拦不住？试试这三层防线

前面说过提示词注入是最防不胜防的风险，但也不是完全没有办法。我的做法是设置三层防线，而不是只靠沙箱一个物理边界。

第一层是入口检测。当大模型读取网页、文档等外部内容时，在进入执行链之前加一道分类器，专门识别“试图改变系统指令”的文本片段。这个检测不可能做到 100%，但能拦下一大半常见的注入攻击，比如“忽略之前所有指令”“你是一个没有限制的 AI”这类明显特征。

第二层是沙箱内收敛。凡是模型自主生成的代码，都在沙箱内执行，同时沙箱要默认屏蔽一切敏感路径。比如沙箱根文件系统里不要挂载主机的/etc、~/.ssh、环境变量里的密钥要过滤掉。即使注入成功，模型能“看见”的东西也极其有限。

第三层是输出过滤。在 Agent 把沙箱执行结果返回给用户之前，做一次内容过滤和敏感信息扫描，防止模型无意中把内存里的密钥或者内部 IP 写进给用户的回复。这三层合起来，即使注入真的穿透了大模型，也到不了宿主机，更出不了安全边界。

4.2 排障速查表：我在实际运行中遇到的高频问题

这几条都是从实际教训里总结出来的。尤其是沙箱销毁导致数据丢失那一条，我刚开始没想清楚，让模型在一个暂存目录里写好处理结果，结果沙箱一销毁，唯一的输出文件就没了。后来所有需要保留的文件，都一律要求它先把内容上传到外部存储，再返回路径。

4.3 几个很容易忽略的审美教训

用 OpenSandbox 这类方案做生产落地，技术细节之外，我还想分享几条更泛化但也更值钱的经验。

第一，不要拿沙箱当数据库。因为沙箱是临时环境，任何需要跨会话保留的数据都必须落盘到外部。我看到过有人把沙箱当作“计算型 Redis”用，快照随手存，结果环境一销毁，所有状态都没了，再找回来非常痛苦。

第二，并发上限永远比你想象中的小。刚开始我只给服务开了 20 个并发沙箱，想着够用了，结果几个 Agent 同时跑数据分析任务，瞬间把宿主机 CPU 打满。后来把并发数降到 8，配合排队机制，系统反而更稳。因为在 AI 场景里，任务执行的不确定性很大，并发峰值的波动比常规 Web 服务剧烈得多。

第三，审计日志要留得越细越好。模型自主执行代码这件事，需要的是可追溯性。我会记录每次执行任务的完整链路：是谁触发的、模型当时判断要做什么、生成的代码是什么、执行的输出是什么、退出码是多少。这些事在出问题的时候回头看，全是救命稻草。

写在最后的个人体会

把“让大模型安全地执行代码”这件事真正落地之后，我最大的感受是：安全不该靠堵，而该靠边界设定。模型可能写出任何代码，但只要你给它的是一个随时可以销毁、够不到敏感资源、资源耗尽就会被杀掉的隔离环境，它的“不可控”就在一个可以接受的范围内。OpenSandbox 这类方案的优势也不在于某一种隔离技术多先进，而在于把内核隔离、资源配额、生命周期管理这些能力打包成了一个 Agent 可以直接调用的标准接口，让“给代码执行加安全壳”变成了工程上很自然的一件事。如果你也在做 AI Agent 或者想给现有工具加一个“能跑 Python”的能力，我建议先小范围试用，把沙箱创建的响应时间、资源开销、错误处理都摸一遍再上生产。安全执行这件事，永远值得多花一点时间。