当 AI 学会“造沙箱“：OpenSandbox 如何让大模型安全地执行代码

让 AI 写代码容易，让 AI 安全地运行代码？这才是真正的技术硬菜。

你有没有想过这样一个场景：你让 ChatGPT 或 Claude 帮你写了一段 Python 爬虫脚本，它写得漂漂亮亮，但你复制到本地一运行——"rm -rf /"——好家伙，人没了，数据没了，只剩下你和一台空空如也的电脑面面相觑。

当然，这只是一个极端的玩笑。但说真的，AI 生成的代码到底能不能直接运行？运行在哪里？出了问题谁来兜底？这些问题，在 AI 编程助手遍地开花的今天，已经从"理论问题"变成了"每天都要面对的问题"。

今天要介绍的 OpenSandbox，就是阿里巴巴开源的一套专门解决这个问题的"沙箱平台"。它的核心理念很简单：给 AI 生成的代码一个"隔离的游乐场"，让它在里面随便折腾，但绝对不能影响外面的世界。

一、为什么我们需要"代码沙箱"？

1.1 AI 时代的"信任危机"

还记得小时候玩沙子吗？家长总会圈出一块"沙坑"，你可以在里面尽情堆城堡、挖坑道，但绝对不能把沙子撒到客厅地板上。代码沙箱，本质上就是给程序圈出的一块"沙坑"。

在传统软件开发时代，代码都是人写的，经过 code review、测试、部署，每一步都有人把关。但 AI 时代不一样了——大模型可以在几秒钟内生成上百行代码，这些代码可能：

• 功能正确但有副作用：比如写文件时不小心覆盖了重要数据
• 无意中引入安全漏洞：比如 SQL 注入、命令注入
• 直接就是恶意代码：如果 prompt 被注入了恶意指令

更可怕的是，AI 生成的代码往往需要立即执行才能验证效果。你总不能每次都让人工审核一遍吧？那 AI 还有什么效率优势？

1.2 现有方案的痛点

在 OpenSandbox 出现之前，业界已经有一些代码执行方案：

方案一：直接在服务器上跑

• 优点：简单粗暴
• 缺点：简单粗暴地把服务器搞崩

方案二：用 Docker 容器隔离

• 优点：隔离性不错
• 缺点：每次创建容器太慢，资源管理复杂，没有统一的 API

方案三：用 Kubernetes 调度

• 优点：可扩展性强
• 缺点：门槛太高，小团队玩不起

方案四：用第三方沙箱服务（如 E2B、Modal）

• 优点：开箱即用
• 缺点：数据安全堪忧，国内网络访问受限，成本不透明

OpenSandbox 的出现，某种程度上是想把这些方案的优点集于一身：既有 Docker 的隔离性，又有 Kubernetes 的可扩展性，还提供了统一的 API 和多语言 SDK，最关键的是——它是开源的，你可以完全掌控自己的数据。

二、架构全景：四层设计的优雅哲学

OpenSandbox 的架构设计遵循"协议优先"的原则，整体分为四层。如果把它比作一家餐厅的话：

┌─────────────────────────────────────────────────────────┐ │                      SDKs 层                            │ │    (服务员：Python/Java/Kotlin/TypeScript 多语言支持)    │ ├─────────────────────────────────────────────────────────┤ │                      Specs 层                           │ │    (菜单：OpenAPI 规范，定义了所有可用的"菜品")          │ ├─────────────────────────────────────────────────────────┤ │                     Runtime 层                          │ │    (后厨：Docker/K8s 运行时，负责"做菜")                │ ├─────────────────────────────────────────────────────────┤ │                   Sandbox 实例层                        │ │    (餐盘：每个容器就是一份独立的"套餐")                  │ └─────────────────────────────────────────────────────────┘ 

2.1 SDKs 层：程序员的"点餐台"

作为一个开发者，你不需要关心底层是用 Docker 还是 Kubernetes，你只需要：

from opensandbox import Sandbox from code_interpreter import CodeInterpreter # 创建一个沙箱，就像点一份套餐 sandbox = await Sandbox.create(     "opensandbox/code-interpreter:latest",     timeout=timedelta(minutes=10), ) # 创建代码解释器 interpreter = await CodeInterpreter.create(sandbox) # 执行代码，获取结果 result = await interpreter.codes.run(     "print('Hello, Sandbox!')",     language=SupportedLanguage.PYTHON, ) print(result.logs.stdout[0].text)  # Hello, Sandbox! # 用完别忘了"结账" await sandbox.kill() 

这段代码看起来是不是很简单？但背后发生了什么呢？

1. SDK 通过 HTTP 请求告诉 Server："我要一个 Python 环境的沙箱"
2. Server 拉取镜像、创建容器、注入执行代理（execd）
3. 容器启动后，SDK 通过 execd 发送代码执行请求
4. execd 把代码交给内置的 Jupyter 内核执行
5. 执行结果通过 SSE（Server-Sent Events）实时返回给 SDK

整个过程对开发者来说是透明的，就像你在餐厅点餐，不需要知道后厨是煤气灶还是电磁炉。

2.2 Specs 层：契约精神的体现

OpenSandbox 定义了两套核心规范：

1. Sandbox Lifecycle API（沙箱生命周期 API）

这套 API 负责沙箱的"生老病死"：

沙箱有完整的状态机：

Pending → Running → Pausing → Paused     ↓         ↓                  ↓   Failed   Stopping          Running               ↓          Terminated 

2. Execd API（执行守护进程 API）

这套 API 负责沙箱内部的"干活"：

• 代码执行：支持 Python、Java、JavaScript、TypeScript、Go、Bash
• 命令执行：运行 Shell 命令，支持前台和后台模式
• 文件操作：读写、搜索、权限管理
• 系统监控：CPU、内存使用率实时监控

两套规范相互独立，但完美配合。这种"协议优先"的设计有一个巨大的好处：你可以替换任何一层的实现，只要遵循规范，整个系统就能正常工作。

2.3 Runtime 层：真正的"苦力活"

Runtime 层是整个系统的核心引擎，目前支持两种运行时：

Docker 运行时（已就绪）

适合单机部署和开发测试，代码实现在 server/src/services/docker.py：

class DockerSandboxService(SandboxService):     def create_sandbox(self, request):         # 1. 拉取镜像         self._ensure_image_available(image_uri, auth_config, sandbox_id)                  # 2. 创建容器（但先不启动）         container = self.docker_client.api.create_container(             image=image_uri,             entrypoint=[BOOTSTRAP_PATH],  # 使用自定义启动脚本             command=bootstrap_command,             environment=environment,             labels=labels,             host_config=host_config,         )                  # 3. 注入 execd 执行代理         self._prepare_sandbox_runtime(container, sandbox_id)                  # 4. 启动容器         container.start()                  # 5. 设置过期自动清理         self._schedule_expiration(sandbox_id, expires_at) 

这里有一个精妙的设计：execd 注入机制。OpenSandbox 不要求你的镜像预装任何东西，它会在容器创建后、启动前，把 execd 二进制文件"塞"进去。这意味着你可以用任何基础镜像（ubuntu、python、node），OpenSandbox 都能让它"听话"。

Kubernetes 运行时（开发中）

适合大规模生产部署，基于 Kubernetes Operator 模式：

apiVersion: sandbox.opensandbox.io/v1alpha1 kind: Pool metadata:   name: code-interpreter-pool spec:   template:     spec:       containers:         - name: sandbox           image: opensandbox/code-interpreter:latest   capacitySpec:     bufferMin: 1   # 最少预热 1 个     bufferMax: 3   # 最多预热 3 个     poolMax: 5     # 池子最大容量 

Kubernetes 运行时引入了"池化"概念，可以提前预热一批沙箱，用户请求时直接分配，大大降低了冷启动延迟。

2.4 Sandbox 实例：每个容器都是一个独立王国

每个沙箱实例的内部结构是这样的：

┌──────────────────────────────────────────────┐ │                 容器边界                      │ │  ┌────────────────────────────────────────┐  │ │  │           用户进程（entrypoint）        │  │ │  │         python main.py / bash          │  │ │  └────────────────────────────────────────┘  │ │                      ↑                       │ │  ┌────────────────────────────────────────┐  │ │  │              execd 守护进程             │  │ │  │  - HTTP API 服务器                     │  │ │  │  - Jupyter 内核客户端                  │  │ │  │  - 文件系统操作                        │  │ │  │  - 系统指标采集                        │  │ │  └────────────────────────────────────────┘  │ │                      ↑                       │ │  ┌────────────────────────────────────────┐  │ │  │           Jupyter Server               │  │ │  │  - IPython (Python)                    │  │ │  │  - IJava (Java)                        │  │ │  │  - gophernotes (Go)                    │  │ │  └────────────────────────────────────────┘  │ └──────────────────────────────────────────────┘ 

execd 守护进程是这里的核心，它是用 Go 语言编写的轻量级 HTTP 服务器，负责：

1. 接收外部的代码执行请求
2. 通过 WebSocket 与 Jupyter 内核通信
3. 将执行结果以 SSE 流的形式返回

// execd 的路由定义 func NewRouter(accessToken string) *gin.Engine {     r := gin.New()          // 代码执行     code := r.Group("/code")     code.POST("", runCode)           // 执行代码     code.DELETE("", interruptCode)   // 中断执行     code.POST("/context", createContext)  // 创建执行上下文          // 命令执行     command := r.Group("/command")     command.POST("", runCommand)     command.DELETE("", interruptCommand)          // 文件操作     files := r.Group("/files")     files.POST("/upload", uploadFile)     files.GET("/download", downloadFile)          return r } 

三、深入源码：几个令人拍案叫绝的设计

读源码最有趣的部分，就是发现那些"看起来简单，其实精心设计"的细节。

3.1 execd 注入：无侵入式的"寄生"

OpenSandbox 不需要你修改镜像，它是怎么做到的？

答案在 DockerSandboxService._prepare_sandbox_runtime 方法中：

def _prepare_sandbox_runtime(self, container, sandbox_id):     # 1. 从 execd 镜像中提取二进制文件     archive = self._fetch_execd_archive()          # 2. 在目标容器中创建目录     self._ensure_directory(container, "/opt/opensandbox", sandbox_id)          # 3. 把 execd 二进制文件塞进去     container.put_archive(path="/opt/opensandbox", data=archive)          # 4. 安装启动脚本     self._install_bootstrap_script(container, sandbox_id) 

启动脚本 bootstrap.sh 长这样：

#!/bin/sh set -e # 后台启动 execd /opt/opensandbox/execd >/tmp/execd.log 2>&1 & # 然后执行用户的原始命令 exec "$@" 

通过覆盖容器的 ENTRYPOINT 为 bootstrap.sh，把用户原本的命令作为参数传入，实现了"先启动 execd，再运行用户进程"的效果，完全无侵入。

3.2 Jupyter 集成：站在巨人的肩膀上

为什么选择 Jupyter 作为代码执行引擎？因为它已经解决了"多语言代码执行"这个难题：

• IPython 内核支持 Python
• IJava 内核支持 Java
• gophernotes 内核支持 Go
• ITypeScript 内核支持 TypeScript

execd 通过 WebSocket 与 Jupyter Server 通信，使用标准的 Jupyter 消息协议：

// 连接到 Jupyter 内核 func (c *Client) ConnectToKernel(kernelId string) error {     wsURL := fmt.Sprintf("ws://%s/api/kernels/%s/channels", host, kernelId)     return c.executeClient.Connect(wsURL) } // 执行代码并流式返回结果 func (c *Client) ExecuteCodeStream(kernelId, code string, resultChan chan *ExecutionResult) error {     return c.executeClient.ExecuteCodeStream(code, resultChan) } 

Jupyter 的 Session 机制还天然支持"有状态执行"——你可以在第一次执行中定义变量，第二次执行中继续使用，非常适合交互式编程场景。

3.3 过期自动清理：没有内存泄漏的秘密

沙箱是有生命周期的，用完必须销毁，否则资源会被耗尽。OpenSandbox 使用了一个巧妙的 Timer 机制：

def _schedule_expiration(self, sandbox_id, expires_at):     # 计算还有多久过期     delay = max(0.0, (expires_at - datetime.now(timezone.utc)).total_seconds())          # 创建一个定时器     timer = Timer(delay, self._expire_sandbox, args=(sandbox_id,))     timer.daemon = True  # 守护线程，主进程退出时自动清理          # 取消旧的定时器（如果有），设置新的     with self._expiration_lock:         existing = self._expiration_timers.pop(sandbox_id, None)         if existing:             existing.cancel()         self._expiration_timers[sandbox_id] = timer          timer.start() 

更贴心的是，服务重启时会自动恢复所有沙箱的过期定时器：

def _restore_existing_sandboxes(self):     containers = self.docker_client.containers.list(         all=True,         filters={"label": [SANDBOX_ID_LABEL]},     )          for container in containers:         expires_at = parse_timestamp(labels.get(SANDBOX_EXPIRES_AT_LABEL))                  if expires_at <= now:             # 已经过期，立即清理             self._expire_sandbox(sandbox_id)         else:             # 重新设置定时器             self._schedule_expiration(sandbox_id, expires_at) 

这种设计保证了：即使服务意外重启，也不会有"僵尸沙箱"残留。

3.4 网络隔离：给沙箱戴上"紧箍咒"

AI 生成的代码可能会尝试访问互联网，下载恶意软件或者泄露数据。OpenSandbox 通过 NetworkPolicy 实现了精细的网络控制：

networkPolicy:   default_action: deny  # 默认禁止所有出站   egress:     - action: allow       target: "pypi.org"      # 允许访问 PyPI     - action: allow         target: "*.github.com"  # 允许访问 GitHub 

这就像给沙箱戴上了"紧箍咒"——它只能访问你明确允许的域名，其他一概不行。

四、实战演练：从零开始玩转 OpenSandbox

说了这么多理论，让我们动手实操一下。

4.1 环境准备

首先确保你的机器上装了 Docker：

docker --version # Docker version 24.0.0 或更高 

然后拉取 Code Interpreter 镜像：

docker pull opensandbox/code-interpreter:latest 

4.2 启动服务端

git clone https://github.com/alibaba/OpenSandbox.git cd OpenSandbox/server # 复制配置文件 cp example.config.toml ~/.sandbox.toml # 安装依赖并启动 uv sync uv run python -m src.main 

服务启动后会监听 http://localhost:8080。

4.3 写一个简单的客户端

import asyncio from datetime import timedelta from opensandbox import Sandbox from code_interpreter import CodeInterpreter, SupportedLanguage async def main():     # 创建沙箱     sandbox = await Sandbox.create(         "opensandbox/code-interpreter:latest",         entrypoint=["/opt/opensandbox/code-interpreter.sh"],         timeout=timedelta(minutes=10),     )          async with sandbox:         # 创建代码解释器         interpreter = await CodeInterpreter.create(sandbox)                  # 执行 Python 代码         result = await interpreter.codes.run(             """             import math                          def calculate_pi(n):                 '''使用莱布尼茨公式计算 π'''                 pi = 0                 for i in range(n):                     pi += ((-1) ** i) / (2 * i + 1)                 return pi * 4                          estimated_pi = calculate_pi(1000000)             print(f"估算的 π 值: {estimated_pi}")             print(f"真实的 π 值: {math.pi}")             print(f"误差: {abs(estimated_pi - math.pi)}")             """,             language=SupportedLanguage.PYTHON,         )                  # 打印输出         for line in result.logs.stdout:             print(line.text)          # 清理资源     await sandbox.kill() if __name__ == "__main__":     asyncio.run(main()) 

运行后你会看到：

估算的 π 值: 3.1415916535897743 真实的 π 值: 3.141592653589793 误差: 9.999989545520858e-07 

整个过程中，代码是在隔离的 Docker 容器中执行的，即使你写了 os.system('rm -rf /') 也只会把容器内的文件删掉，不会影响宿主机。

4.4 与 AI 编程助手集成

OpenSandbox 的真正威力在于与 AI 结合。项目自带了多个集成示例：

• Claude Code：让 Claude 在沙箱中执行它生成的代码
• Gemini CLI：Google Gemini 的代码执行环境
• Codex CLI：OpenAI Codex 的代码执行环境
• LangGraph：基于 LangChain 的 Agent 工作流

以 Claude Code 为例，集成思路大致是：

1. 用户向 Claude 提问："帮我写一个爬取豆瓣电影 Top250 的脚本"
2. Claude 生成代码
3. 代码发送到 OpenSandbox 执行
4. 执行结果返回给 Claude
5. Claude 根据结果调整代码（如果有错误）
6. 循环直到成功

这种"生成-执行-反馈-修正"的循环，让 AI 编程助手从"只会写代码"进化到了"能写能调试"。

五、与同类产品的对比

市面上还有哪些类似的产品？让我们做个横向对比：

OpenSandbox 的最大优势在于：开源 + 数据自主 + 国内友好。对于对数据安全有要求的企业，或者需要在国内部署的场景，OpenSandbox 几乎是唯一的选择。

六、未来展望：沙箱技术的星辰大海

OpenSandbox 的 Roadmap 里还有很多有趣的计划：

6.1 Go SDK

目前只有 Python、Java/Kotlin、TypeScript SDK，Go SDK 还在开发中。考虑到 Go 在云原生领域的广泛使用，这个 SDK 的呼声很高。

6.2 kubernetes-sigs/agent-sandbox 集成

这是 Kubernetes SIG 正在开发的一个官方沙箱标准。OpenSandbox 计划与之集成，这意味着未来可以用 kubectl 来管理沙箱！

# 未来可能的用法 kubectl create sandbox my-sandbox --image=python:3.11 kubectl exec -it my-sandbox -- python 

6.3 声明式网络隔离

目前的网络策略是基于 DNS 的，未来会增加基于网络层的控制，实现更精细的流量管理。

6.4 更多 AI 框架集成

除了现有的 Claude、Gemini、Codex 集成，还计划支持：

• AutoGPT
• CrewAI
• AutoGen

七、写在最后：安全不是束缚，而是自由的前提

有人可能会问：搞这么复杂的隔离机制，是不是"杞人忧天"？

我的回答是：安全措施的价值，不在于它阻止了多少攻击，而在于它让你可以放心地做更多事情。

想象一下，如果没有沙箱：

• 你敢让 AI 自动执行它生成的代码吗？
• 你敢让用户在你的平台上运行任意代码吗？
• 你敢把代码执行功能集成到生产系统中吗？

有了沙箱，这些都不是问题。就像有了安全带，你才敢踩油门；有了保险，你才敢创业；有了沙箱，AI 才敢真正"动手"。

OpenSandbox 的出现，不仅仅是一个技术产品，更是 AI 编程范式的一个重要基础设施。它让"AI 写代码"从 demo 走向了生产，让"人机协作编程"从概念变成了现实。

如果你也在探索 AI 编程的可能性，不妨试试 OpenSandbox。毕竟，让 AI 在沙箱里"随便玩"，总比让它在生产环境"随便搞"要安全得多。

项目地址：https://github.com/alibaba/OpenSandbox

更多AIGC文章

RAG技术全解：从原理到实战的简明指南

更多VibeCoding文章