Infrastructure

昨晚在电子书上读到一段关于 Stripe Minions 的文字，让我停下来想了很久。

不是因为它用了什么惊艳的模型，而是因为它揭示了一个被大多数人忽略的事实：

Minions 能 work 的首要原因跟 AI 模型本身几乎无关，而是 Stripe 在 LLM 出现之前就为人类工程师建设了多年的基础设施。

完整的代码树、成熟的构建系统、全面的测试覆盖、标准化的开发环境——这些不是为 AI 准备的，是十多年来为人类工程师准备的。AI Agent 到来时，直接继承了这套基础设施。

好的人类工程基础设施，就是好的 AI 工程基础设施。

很多人对MaaS（Model as a Service）的理解停留在"套一层API"——把OpenAI的接口包一下，加个Key管理，做个用量统计，就叫MaaS了。如果这就是MaaS的全部，那它确实没什么技术含量，随便一个API Gateway就能干。

但现实是：几乎所有在生产环境跑AI应用的团队，最终都会自建或依赖一个MaaS层。 不是因为他们闲，而是因为裸调模型API在生产环境里根本撑不住。

MaaS层真正要解决的问题是：把一个概率性的、无状态的、昂贵的模型API调用，变成一个可靠的、可观测的、成本可控的服务。

AI Agent 能搜索、能总结、能写代码，但有一件事它做不好：读你的互联网。你的 Twitter Timeline、你的 YouTube 推荐、你的 Hacker News 首页——这些个性化内容藏在登录态背后，普通的 API 调用拿不到。

OpenClaw 的远程浏览器方案解决了这个问题：在一台带桌面的 Ubuntu 服务器上运行真实浏览器，保存各大网站的登录信息，然后通过网络让 AI Agent 直接操控这个浏览器。AI 看到的就是你看到的。

当你构建一个能够自主编写和执行代码的 AI 代理时，安全性和隔离性成为了首要考虑的问题。如何让 AI 安全地运行用户或自身生成的代码，而不会影响主系统？E2B（Execute to Build）正是为解决这个问题而生的云沙箱平台。本文将深入探讨 E2B 在 AI 基础设施中的最佳实践。