E2B
为 AI Agent 提供云端隔离沙箱,让 AI 生成的代码安全执行
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
为 AI Agent 提供云端隔离沙箱,让 AI 生成的代码安全执行
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
想象一下:你对 AI 助手说「帮我把这张图片转成黑白,然后发到群里」,AI 不仅理解了你的意思,还能真正打开画图软件、执行转换操作、打开通讯软件上传文件——整个过程就像你在远程操控一台真实电脑一样。在 E2B 出现之前,这样的场景更多是科幻设想;而现在,它已经成了可以落地的工程现实。
E2B(Environment 2 Brain?Environment-to-Business?官方未明确定名)是一个开源云基础设施平台,专注于为 AI Agent 提供可信赖的代码执行环境。简单来说:当你让 AI Agent 执行一段它自己生成的代码时,这段代码需要一个「隔离房间」来运行,不能让它在你的真实电脑或者服务器上乱来——E2B 就是这个「隔离房间」的供应商。
图1:E2B SDK 同时支持 JavaScript/TypeScript 和 Python 两种主流开发语言,开发者可按项目技术栈灵活选择
2023 年,以 GPT-4 为代表的大语言模型展示了令人惊叹的代码生成能力。AI 不仅能写代码,还能 debug、写测试用例、甚至解释复杂代码库。然而,很快业界发现了一个根本性瓶颈:AI 生成的代码谁来执行?
如果直接在你自己的服务器上跑 AI 生成的代码,等于把钥匙交给陌生人——恶意代码、数据泄露、资源耗尽,每一项都是噩梦。传统方案是 Docker 容器化,但 Docker 对于「每次请求都生成一个新容器、执行完后销毁」的高频场景来说,初始化慢、资源占用高,并不理想。
E2B 的核心团队(来自捷克)瞄准了这个痛点,构建了一套专为 AI 场景优化的沙箱执行系统。这套系统被全球顶级科技公司采用——官方数据显示,世界 100 强企业中 94% 已在使用 E2B 的服务,包括 Frontier Agentic Workflows(前沿 AI Agent 工作流)。
E2B 最基础的玩法,就是启动一个隔离的云端沙箱,然后在里头跑命令。这和 SSH 登录一台远程服务器类似,但有本质区别:
使用 Python SDK 的示例:
from e2b import Sandbox
with Sandbox.create() as sandbox:
result = sandbox.commands.run('echo "Hello from E2B!"')
print(result.stdout) # Hello from E2B!
同样的逻辑用 JavaScript 实现:
import Sandbox from 'e2b'
const sandbox = await Sandbox.create()
const result = await sandbox.commands.run('echo "Hello from E2B!"')
console.log(result.stdout)
这段代码的背后,是 E2B 在云端启动了一个微型虚拟机(基于 Linux),将命令发送到里头执行,然后返回结果。开发者无需关心底层运维,只需调用 SDK 接口。
如果基础沙箱是「能跑命令的远程终端」,那么 Code Interpreter 就是「能跑代码的云端 REPL」。E2B 提供了专门的 @e2b/code-interpreter(JS)或 e2b-code-interpreter(Python)扩展包,让 AI 能执行代码并获取执行结果:
import { Sandbox } from '@e2b/code-interpreter'
const sandbox = await Sandbox.create()
const execution = await sandbox.runCode('x = 1; x += 1; x')
console.log(execution.text) // outputs: 2
这个模式特别适合 AI Agent 需要「做数学计算」「处理数据」「生成文件」的场景。例如在 AI 聊天机器人中,用户上传了一个 CSV 文件让 AI 分析,AI 可以直接调用 runCode() 来执行数据处理逻辑,而不是「假装分析」后输出一个它自己编造的结果。
E2B 支持完整的自托管部署。官方提供了基于 Terraform 的基础设施代码(放在独立的 infra 仓库),支持 AWS 和 Google Cloud 两大平台。这意味着:
自托管部署目前支持 AWS 和 GCP,Azure 平台还在规划中。此外还支持在「通用 Linux 机器」上部署(通过 Terraform),为私有化部署场景提供了灵活性。
图2:E2B 的预览图展示了多沙箱并行执行的企业级场景——每个 Agent 可以拥有独立的工作环境,互不干扰
从代码仓库结构来看,E2B 采用 pnpm monorepo 架构,主仓库包含:
| 子包 | 说明 |
|---|---|
packages/cli | 命令行工具,用于本地开发调试 |
packages/connect-python | Python SDK 的底层通信层(基于 ConnectRPC) |
packages/js-sdk | JavaScript/TypeScript SDK(主推,使用 Vitest 测试) |
packages/python-sdk | Python SDK(与 JS SDK 功能对齐) |
spec/ | OpenAPI 规范定义 |
代码生成流程高度自动化:团队用 codegen.Dockerfile 构建了一个 Docker 镜像,内含 Go 工具链(buf、protoc-gen-go、protoc-gen-connect-go)和 Python 工具链(openapi-python-client、datamodel-code-generator),通过 make codegen 一键生成各语言的 API 客户端代码。这种设计确保了多语言 SDK 与后端 API 的一致性——改动一次 API 规范,所有语言 SDK 同步更新。
项目维护了大量依赖安全修复记录(包括 lodash、minimatch、picomatch、yaml、brace-expansion 等流行包的已知漏洞补丁),体现出团队对供应链安全的重视。但作为一个依赖了 pnpm 生态大量包的主仓库,长期来看需要持续关注依赖树的安全状态。
E2B 的上手体验相对友好:
pip install e2b 或 npm i e2b,无需配置 Docker 镜像不过,有两个门槛需要注意:
对于普通 AI 爱好者而言,直接使用 E2B 有一定门槛——它更像是一个面向开发者的基础设施组件,而非面向终端用户的应用。但如果你的目标是构建 AI 应用,E2B 是目前最成熟的开源方案之一。
E2B 并非万能解决方案,以下几点值得注意:
执行性能有限:沙箱毕竟运行在云端虚拟机中,相比本地直接执行,同等计算量下会有额外的网络延迟和资源开销。对于毫秒级敏感的实时应用,需要评估是否可接受。
冷启动成本:沙箱创建涉及虚拟化开销,短时间高频调用场景(如每个用户请求都新建沙箱)成本较高。生产环境通常需要沙箱池化(预创建多个沙箱复用)。
云端成本:E2B 官方云的定价基于使用量,自托管虽然一次性投入大,但长期看在大规模使用场景下可能更经济。需要结合实际业务量做成本测算。
安全边界:虽然 E2B 提供了强隔离,但沙箱内的代码仍然是「可执行代码」——如果沙箱内的工具配置不当(如开放了文件写入权限),理论上仍有风险。正确配置沙箱权限是使用者的责任。
E2B 的出现代表了 AI 应用开发的一个新阶段:AI 不再只是「给建议」,而是真正「能干活」。
在 E2B 之前,开发者通常需要在 AI 输出和实际执行之间加一道人工确认环节(防止 AI 生成有害代码);有了 E2B 这类沙箱基础设施后,这道环节可以被「安全隔离 + 权限控制」所替代,使得 AI Agent 的自主性大幅提升。
这带来的变革是深远的:代码解释器、数据分析 Agent、自动化测试工具、Coding Copilot……这些场景都将从 E2B 这类基础设施中受益。可以说,E2B 正在做的事情,和当年 Docker 让「应用容器化」成为主流一样——让「AI 代码执行」变得安全、标准化、可规模化。
| 维度 | 内容 |
|---|---|
| 编程语言 | Python(主 SDK)、TypeScript/JavaScript(JS SDK) |
| 架构 | monorepo(pnpm workspace)+ gRPC/ConnectRPC 通信 |
| 许可证 | Apache-2.0 |
| 主要功能 | 云端隔离沙箱、命令执行、代码解释器(runCode) |
| 自托管 | 支持(Terraform + AWS/GCP) |
| 部署难度 | 简单(SDK 使用),中等(自托管) |
| 硬件需求 | 云端:无需本地 GPU;自托管:标准 Linux 云主机 |
如果你正在开发需要 AI「真正动手执行任务」的 Agent 应用,E2B 是目前开源社区中成熟度最高、社区最活跃的解决方案之一。建议从官方 Cookbook(e2b-cookbook 仓库)中的示例开始,快速验证与你的 AI 框架(LangChain、AutoGen、CrewAI 等)的集成可行性。