当 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 asyncdef main(): # 创建沙箱 sandbox = await Sandbox.create( "opensandbox/code-interpreter:latest", entrypoint=["/opt/opensandbox/code-interpreter.sh"], timeout=timedelta(minutes=10), ) asyncwith 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