让 AI Agent 安全执行任意代码的基础设施。两个来自布拉格的童年好友，用 Firecracker microVM 解决了硅谷顶级 Agent 公司都需要但没人专门做的那个问题。
TL;DR · 30 秒读完
E2B 用 Firecracker microVM 为 AI Agent 提供安全的代码执行沙箱，两个来自布拉格的童年好友，把无意间做出的一个小功能，做成了硅谷顶级 Agent 公司都需要的核心基础设施。
反共识洞察：88% 世界财富 100 强"注册"听起来亮眼，但注册不等于付费，真正决定生死的也不是技术优势——AWS AgentCore 已用同款 Firecracker 技术入场——而是能否在大厂收编之前把开发者生态的护城河挖得足够深。
2022 年，Vasek Mlejnsky 和 Tomas Valenta 在做开发者文档工具"DevBook"。他们是布拉格的童年好友，毕业于查理大学数学物理学院，研究方向是计算机视觉。那个文档工具里，他们做了一个小功能：嵌入式沙箱代码执行。
GPT-3.5 发布后，他们意识到自己无意间做出的这个"小功能"，正是整个 AI Agent 生态系统缺少的那块核心基础设施。2023 年 3 月，他们以此为核心重新立项，FoundryLabs, Inc. 成立于旧金山。
问题的本质是这样的：AI 生成的代码不能直接在宿主机上运行。不是性能问题，是信任问题。一个 Agent 生成的 Python 脚本可能是恶意的、错误的、或者包含意外的系统调用。你需要一个边界。
绝大多数人的答案是 Docker 容器。E2B 的答案是 Firecracker microVM。区别在于：Docker 共享宿主机 Linux kernel，有 container escape 的风险；Firecracker 给每个沙箱一个独立的 Linux kernel，隔离级别达到 VM 级。这是 AWS Lambda 使用的同款技术。
冷启动慢是 VM 的传统问题。E2B 的解决方案是：预热 VM 池 + 内存快照（snapshot），新请求从快照恢复，将冷启动时间压到约 150ms。这个数字意味着在 Agent 对话的流式体验里，用户几乎感知不到沙箱启动的延迟。
| 产品 | 隔离层 | 冷启动 | 定位 |
|---|---|---|---|
| E2B | Firecracker microVM | ~150ms | AI Agent 专用 |
| Daytona | Docker 容器 | ~90ms | 通用开发环境 |
| Modal | gVisor | ~200ms | GPU 工作负载 |
| AWS AgentCore | Firecracker | — | AWS 原生，2025 年底入场 |
Python / TypeScript 双端 SDK，让开发者用三行代码为自己的 AI Agent 接入安全的沙箱代码执行能力。这是 E2B 最核心的产品，也是绝大多数客户的第一个接触点。月下载量 200 万+，GitHub Stars 8,150+。
每个 SDK 调用在后端启动一个独立的 Firecracker microVM。VM 从内存快照恢复，启动约 150ms，执行完毕后销毁。开发者无需了解任何 VM 细节。
完整的 Linux 桌面环境，专为 Computer Use 类 Agent 设计。Manus 是最著名的客户——他们用 E2B Desktop 给每个 Agent 提供一台完整的虚拟电脑，整合了 27 个工具，据报道半天内完成接入。
Manus（完整桌面 Agent）、Perplexity（高级数据分析，1 周上线，并发扩展到数千会话）、Genspark、Lindy（数天内上线 Agentic 功能）。
支持通过 Model Context Protocol 将 E2B 沙箱接入 Claude、GPT 等主流模型。MCP 标准的兴起让 E2B 的集成路径大幅简化——以前需要 API 调用的地方，现在一个 MCP 工具声明就够了。
MCP 成为 AI 工具标准后，E2B 的沙箱能力可以更容易地成为任意 AI 应用的默认代码执行后端，不再局限于原生 SDK 集成。
Bring Your Own Cloud 和企业本地部署方案。Fortune 100 的 88% 注册用户中，相当一部分是有合规要求的大型企业——他们的代码不能送到 E2B 的公有云上，需要在自己的 VPC 内运行 Firecracker 集群。
企业 BYOC 是 Infrastructure SaaS 的标准路径：开发者注册用 SaaS，企业上规模后用 BYOC/On-Prem，后者单价显著更高。Groq（高速代码执行）、Hugging Face 已在此路径上。
"Docker 对不可信代码的隔离是结构性缺陷，不是配置问题。共享 kernel 就是共享风险。"
Docker 容器对不可信 AI 代码的安全性存在本质缺陷——container escape 漏洞历史上多次被复现。microVM 是当前唯一在启动速度和隔离级别上同时满足 Agent 场景要求的技术选择。
Why：AWS Lambda 已用 Firecracker 在生产环境处理数万亿次调用，验证了可靠性。E2B 是将其开源专门化为 AI Agent 场景的第一个玩家。
How：通过 VM 预热池 + 内存快照，将 VM 级隔离的冷启动代价从秒级降至 150ms，使其在对话流式场景下可用。
硅谷顶级 Agent 公司（Manus、Perplexity）选择由两个布拉格人创建的基础设施，说明技术质量和开发者体验是真实护城河。风险投资的地域偏见在基础设施层是弱信号——开发者不看创始人护照。
Why：Manus 选择 E2B Desktop 的标准不是投资人背书，而是半天接入时间。Perplexity 的标准是 1 周上线 + 数千并发会话的扩展性。
How：查理大学计算机视觉背景，让两人对底层系统和性能工程有超出平均水平的感知。
这个数字验证了市场需求的真实性——大企业的工程师在探索 Agent 能力时，E2B 是他们遇到的最简单的沙箱方案。但 Fortune 100 企业的"注册"和"生产部署"之间存在巨大鸿沟，实际 ARR 结构是这个故事的关键未知数。
Why：免费 tier 的低门槛注册，是 PLG 策略的标准动作，不等于商业化成功。
How：从"注册"到"生产"的转化率，以及企业合同的 ACV，才是判断商业健康度的正确指标。
AWS 在 2025 年底推出 AgentCore，技术路线是 Firecracker——这验证了 E2B 的技术判断，但也意味着 E2B 需要在大厂的 AWS 原生优势之外建立足够深的开发者生态护城河。
Why：AWS 的优势在于与既有云基础设施的深度绑定，而不是沙箱技术本身（他们用的同款 Firecracker）。
How：E2B 的生存路径是"多云 + 开源社区 + 开发者工具生态"，而不是纯技术差异化。
E2B 的核心命题是：AI Agent 的代码执行安全是一个独立的基础设施层，不应该被嵌入在 Agent 框架里，也不应该被 AWS 等云平台收编。他们用 Firecracker 下了正确的技术赌注，用 PLG 积累了真实的开发者体量，现在面临的挑战是在大厂入场之前建立足够深的生态护城河。30 人团队、$32M 融资、5 亿次沙箱启动——这个比例本身就是他们效率密度的证明。
两个布拉格人在 2022 年做文档工具时，无意间发现了 AI Agent 时代最需要的那块基础设施。他们没有犹豫——直接以此为核心重新立项。三年后，硅谷最聪明的 Agent 公司在他们的沙箱里运行代码。