理解 E2B，需要把开源项目和它背后的公司放在一起看。公司的市场判断、客户需求和收入来源，会影响开源项目的方向；项目中不断增加的能力，也反映了公司正在尝试解决哪些问题。
从 2022 年的 DevBook 到 2026 年的 E2B，这段历史并不长。其中有三个值得关注的节点：2023 年，转型为 Agent 提供执行环境；2024 年，围绕代码解释这一主要用例聚焦产品；2025 年起，进一步扩大企业业务和交付能力。
这三个节点分别回答了三个问题：E2B 要做什么，客户怎样使用它，以及公司怎样把它变成可以持续交付的服务。
2023：转型，为 Agent 提供执行环境
从 DevBook 到托管编程 Agent
E2B 的前身是 DevBook，一个提供交互式开发文档和 Playground 的产品。开发者可以在浏览器中直接运行示例，不必先在本地安装工具和配置环境。2022 年 12 月，Prisma 曾宣布使用 DevBook 提供交互式 Playground，让用户学习数据库查询和迁移。Prisma 当时的公告这类体验并不难理解：教程旁边就是一个准备好的环境，用户可以实际运行命令，得到真实反馈。环境运行在远程，浏览器是操作入口。
这项业务给团队留下了一个重要积累：怎样为用户准备真实、可运行的开发环境。
随着 Agent 兴起，环境的操作者从人扩展到了由大语言模型驱动的程序。根据 E2B 的官方回顾，2023 年 3 月，团队尝试把 GPT-3.5 与原有 Sandbox 结合，让 Agent 通过工具调用在远程环境中运行代码。随后，E2B 还探索了托管编程 Agent：用户连接 GitHub 仓库、提交需求，通过 Pull Request 查看生成的代码，并用评论继续协作。2023 年 6 月的 smol developer 公告中，团队明确表示为 Agent 提供独立的 Firecracker 虚拟机 。公司回顾、smol developer 公告
Firecracker 是 AWS 开源的轻量虚拟机监控器。在这里，它为代码和命令提供隔离运行的机器环境。
收敛产品责任执行层
不过，提供一个完整的编程 Agent，会把许多问题同时带进产品。
作为开发者，我期待得到的是一个能完成需求的程序，或者一个可以合并的 PR。最终效果却取决于模型、任务规划、代码生成、测试和执行环境，也可能受到需求本身是否明确的影响。例如，项目需要 Windows 环境，实际提供的却是 Linux，单靠生成代码就很难解决这个差异。只要生成的项目不能运行，或者 PR 没有完成需求，即使底层 Sandbox 正常工作，对用户来说，任务仍然失败了。用户也未必能判断问题究竟出在哪里。从这个角度看，编程 Agent 的竞争首先围绕任务完成效果展开。用户是否需要远程执行环境，要由工作方式决定；在本机使用编程 Agent，同样可以完成许多开发任务。时至今日（2026年），本地开发仍然是软件行业的主流，无数工程师在本地使用 Codex、Claude Code、OpenCode、Pi 等 Agent 进行软件开发相关的工作。
E2B 逐步收敛了自己的产品责任：应用开发者负责构建 Agent，E2B 为这些 Agent 提供安全、可靠的执行环境。 这样，它就能服务不同的模型、框架和业务。在公司回顾中将这个转变描述得很快，但同期仍有几个月的 Agent 产品探索。侧面说明这个产品边界是在实践中逐步清晰的。
2023 年下半年，这个方向通过两项能力变得具体：Python SDK 提供创建环境、执行命令和文件操作等在应用层更加易用的依赖；Custom Sandboxes 则允许开发者用 Dockerfile 定义依赖和程序，通过 CLI 提交构建，得到可复用的环境模板。历史发布记录、Custom Sandboxes 公告
模板解决了一个非常实际的问题：如果 Agent 每次工作都要安装同样的 Python 包和工具，就可以把这些准备工作提前完成。后续任务直接从模板创建实例，减少重复安装和等待。
flowchart TB
subgraph Prepare["提前准备环境"]
Config["Dockerfile<br/>声明软件和依赖"] --> Template["构建可复用的模板"]
end
Template -->|"创建实例"| A["Sandbox A<br/>运行代码、操作文件"]
Template -->|"创建实例"| B["Sandbox B<br/>独立执行另一项任务"]
Agent["业务应用中的 Agent<br/>调用模型、决定下一步"] -->|"通过 SDK 执行操作"| A
A -->|"返回输出、文件或错误"| Agent图中展示一种常见接入方式：应用负责决策，Sandbox 负责执行。Agent 的控制逻辑也可以部署在 Sandbox 内，模型推理不必在其中运行。
SDK 和模板共同把团队已有的环境能力，变成了其他应用可以接入和复用的基础设施。对于交给 Sandbox 的操作，执行结果会返回应用，成为 Agent 决定下一步的依据；如何规划任务、选择模型和组织整个 Agent，仍由应用方负责。
这是 E2B 发展过程中最根本的一次转型：公司的主要服务对象变成了构建 Agent 的开发者，产品责任集中到了执行层。
2024：聚焦，让代码解释更容易接入
用专用 SDK 响应用户需求
通用执行环境可以做很多事情，但应用开发者仍然要完成接入工作：怎样启动代码、维持会话、获取结果，以及怎样把图表和文件展示给用户。2024 年春，E2B 推出了 Code Interpreter SDK。5 月的官方公告明确说明，代码解释已经成为客户最主要的用例，团队提供专用 SDK，是为了简化这类应用的开发。Code Interpreter SDK 公告
以表格分析为例，用户提出问题，模型生成 Python 程序，程序读取数据并计算，最后返回文字、表格或图片。应用需要把这一整段流程连接起来。专用 SDK 将代码执行和输出整理成更直接的接口，减少了应用围绕通用 Sandbox 编写的衔接代码。
flowchart LR
User["用户提出<br/>表格分析问题"] --> App["应用调用模型<br/>生成 Python 代码"]
App --> SDK["Code Interpreter SDK<br/>提交代码、收集结果"]
SDK --> Sandbox["Sandbox 中执行<br/>读取数据、计算、绘图"]
Sandbox --> Result["文字、图表、文件<br/>或执行错误"]
Result --> App
App -->|"展示结果"| User从技术上看，这一步复用了已有的 Sandbox，并整合 Jupyter 等执行组件。主要增量体现在对常见任务的完整支持：执行环境已经准备好，同一会话可以继续使用，代码输出也更容易被应用处理。
对于基础设施产品来说，让上层应用更容易使用，本身就是价值。代码解释为“给 Agent 一台计算机”这个概念提供了具体入口，开发者可以将它对应到数据分析、可视化和计算任务中。客户的实际使用，又为团队决定优先完善哪些能力提供了依据。正题上来说这是一次由需求推动的产品聚焦。
从代码执行扩展到桌面操作
2024 年 10 月，E2B 公布由 Decibel 领投的 1,150 万美元种子轮融资。同年第四季度，公司推出 Desktop Sandbox beta，把执行环境扩展到了图形桌面。Desktop 让 Agent 能够通过截图、鼠标和键盘操作应用。虚拟机不需要连接物理显示器，软件可以在内存中生成虚拟桌面。供人实时观看和接管的桌面流，则在 2025 年 3 月进一步补齐。Desktop 初始实现、实时桌面流实现
这里需要区分两件事：通过对外暴露的端口访问 Sandbox 中的网页，和观看 Sandbox 内部的完整桌面。Desktop 增加的是后者所需的桌面与操作能力。
这些变化沿着同一个思路展开：底层提供通用环境，上层围绕实际任务提供更易用的入口。代码解释率先获得了明确的客户反馈，Desktop 则扩展了 Agent 使用图形应用的方式。2024 年对于 E2B 的意义，就在于找到了一些具体方式让客户认识产品的价值并采用公司提供的基础设施建设 。
2025 起：商业扩展，承接企业的生产需求
从客户需求看能力演进
当应用开始接入企业业务，仅仅“代码能够运行”就不够了。
假设 Agent 需要访问公司内部的 ERP、财务系统或开发系统，这些接口通常不会直接暴露到公网。运行在外部云环境中的 Sandbox，默认无法直接访问它们，需要额外安排网络连接和权限。有些企业还要求数据和执行环境留在自己的云账户中。与此同时，正式业务会带来更多运行要求：需要支持多少并发，数据存放在哪里，怎样控制访问，出现故障后谁来处理，以及谁来持续维护可用性。
2025 年 7 月 28 日，E2B 宣布完成由 Insight Partners 领投的 2,100 万美元 A 轮融资。公司明确表示，资金将用于扩展云基础设施、改善开源互操作，以及扩大企业工程和商业团队。这反映了公司对企业业务的进一步投入；E2B 在此之前就已经提供云服务。公司融资公告 我们可以结合客户案例，理解这些需求与项目能力之间的关系。
- 2025 年的 Manus 案例描述了一个需要浏览器、终端和文件系统的 Agent。任务可能持续较长时间，也可能中途等待用户补充信息，因此需要保留工作现场，之后再继续。暂停与恢复就能承接这类需求。Manus 案例
- 2026 年，E2B 又公开介绍了运行中 Sandbox 的 fork，允许从同一个执行现场创建不同分支，分别尝试后续方案。fork 发布记录
- 2026 年的 Rogo 案例披露，其需求包括约 10,000 至 15,000 个并发 Sandbox。它希望获得这项能力，同时减少自建和运营基础设施的投入；E2B 能够提供托管运行，是其选择外部服务的理由之一。Rogo 案例
这里是在解释需求与能力之间的关系，并不意味着这些功能一定由某个客户直接推动。作为一个外部观察者，这些案例能帮助我们理解，为什么执行状态、并发、网络和故障处理会成为平台持续投入的方向。
Cloud 与 BYOC：交付位置和运维责任
企业需求也让部署方式变得重要。
E2B Cloud 由 E2B 托管。BYOC，全称 Bring Your Own Cloud，则由 E2B 在客户的 AWS 或 GCP 账户中部署和运营，将 Sandbox 的运行位置与客户自己的云边界结合起来。客户拥有云账户和网络边界，E2B 继续承担约定的部署与运行职责。官方 BYOC 文档、企业部署说明
flowchart TB
App["客户应用 / Agent"] --> CloudSandbox
App --> BYOCSandbox
subgraph Cloud["E2B Cloud：E2B 管理的云环境"]
CloudSandbox["Sandbox 与运行数据"]
end
subgraph BYOC["BYOC：客户的 AWS / GCP 账户与 VPC"]
BYOCSandbox["Sandbox 与运行数据"] --> Internal["获准访问的内部系统"]
end
Ops["E2B 部署与运营服务"] -.-> CloudSandbox
Ops -.->|"控制与运维联系"| BYOCSandbox这是部署责任示意图。BYOC 仍与 E2B 保持控制面通信，不等于完全离线；内部系统的访问也需要配置网络和权限。
在项目实现中，调度、集群管理、访问控制、监控和故障处理，共同支撑这些运行要求。公开源码能够帮助我们理解机制；具体商业部署包含哪些能力、提供什么支持，还需要看相应交付方案。
从商业模式看，开源项目和托管服务承担着不同的工作。开源代码使开发者能够理解、修改和自行运行系统，也为内部研究与测试提供了起点；商业服务提供计算资源、规模化运营、故障处理和约定的支持。即使客户具备自建能力，也可能因为系统复杂度和长期运维成本而选择购买服务，把省下来的工程投入用于自己的应用。源码是否可用，与企业是否愿意自己维护这套基础设施，是两个需要分别考虑的问题。
E2B 的发展由此连成了一条脉络：
- 转型确定了为 Agent 提供执行环境的方向
- 聚焦让这个基础设施更容易进入具体应用
- 商业扩展则要求项目和公司能够长期承担客户的运行需求。
把公司和项目放在一起看，就更容易理解后续的技术问题：任务为什么需要快速启动，执行现场为什么需要暂停和保存，企业为什么在意部署位置，以及哪些运行责任需要由平台承担。
结语
还好 E2B 整个项目和公司的历史没有那么“悠久”，才能让我有机会和 GPT 一起梳理总结一下整个项目以及这家公司的发展历史。通过这种方式来理解代码背后的选择，通过理解这些选择来学习值得借鉴的经验，最后将这些经验带回到自己的日常工作中去。技术能力如何在真实需求中逐渐找到自己的位置？一个环境能够运行代码只是起点，让开发者容易接入、让任务稳定运行、让企业愿意长期使用，都需要持续的产品选择和工程投入。
作为 Sandbox 系列的第二篇博客其实还是没有深入到技术与技术架构中去，关于 E2B 的架构我们留在下一篇吧。后续力所能及的应该还有两三篇，最后涉及 VM 深入操作系统底层的估计就只能谈谈自己的理解然后稍微带过了，毕竟我自己也没搞清楚，抛砖引玉吧。