E2B
e2b-dev/E2B加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 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 等）的集成可行性。