Devops

上周 review 一个团队的代码。他们想做一个能自主修 bug 的 Agent，架构设计得很漂亮，模型选的也是最新的。但 Agent 跑起来后，改完代码就停了——它不知道怎么验证自己改得对不对。

我问他们：「测试覆盖率多少？」

「大概 30%，而且跑得慢，本地跑一次要 15 分钟。」

「日志呢？有结构化日志吗？」

「有，但格式不太统一，有时候打 JSON，有时候打纯文本。」

「Health Check 呢？」

「有个 /ping 接口，返回 200。」

我说：那你的 Agent 改完代码之后，怎么知道改对了？怎么知道部署上去没炸？怎么知道要不要回滚？

他想了想：「只能让人看一眼。」

我说：对，这就是问题所在——你的系统不是为 Agent 设计的，是为人设计的。 人可以用经验判断「这个改动应该没问题」，Agent 不行。Agent 只能依赖 可以调用、可以验证、可以反馈 的能力。

上周五晚上，我在给 ai-notepad 项目加一个功能：让 AI Agent 能自动发现并安装这个项目的 Skill。写完 SKILL.md、落地页、版本同步脚本后，我突然意识到一件事——这套流程已经不是「锦上添花」，而是应用交付的新底线。

如果你今天做一个应用，却没有提供 CLI 和 Skill，就像 2010 年做一个 Web 服务却没有 API 一样——用户（包括 AI Agent）根本用不了你。

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

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

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

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

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

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