Vercel用AI软件工厂维护AI SDK：4周覆盖30% PR

The AI SDK 是全球最受欢迎的开源 AI 项目之一，每周服务超过 2000 万次 npm 下载，GitHub 仓库拥有超过 26000 颗星。维护这个代码库意味着同时追踪四个不断变化的靶心：

模型提供商：新提供商、新能力、新 bug

UI 框架：React、Next.js、Svelte、Vue 等的绑定

沙箱：Agent 运行代码的执行环境

适配器：Codex、Claude Code、Pi 等的适配层

经过多年的增长，该仓库每月收到 100 多条新 issue。当 Anthropic 的 Opus 4.6 模型发布后，PR 数量迎来了拐点。到六月底，累积的待处理事项已超过 1000 个 open issue 和近 800 个 pull request。

这个积压不是纪律问题。无论多么优秀的维护者，都无法仅靠更努力地工作来填补这道鸿沟，而且由于生成代码的成本很低，它只会越来越大。

我们没有试图扩大自己的规模，而是建立了一座软件工厂。四周后，它编写了我们合并的 25% 到 35% 的 PR，并关闭了 70% 到 80% 的 issue。

确定建造什么类型的工厂

在我们构建任何东西之前，必须回答三个问题：

为什么我们现有的使用 Agent 的方法不够用

什么样的自动化程度适合 AI SDK 这样的项目

如何使自动化和人类工作与风险对齐

为什么不再增加更多 Agent？

最优秀的维护者已经在积极使用 Agent 了。Mitchell Hashimoto 以"始终有一个 Agent 在工作"为目标来维护 Ghostty，并将每个 Agent 的失败记录在 AGENTS.md 中，以免重蹈覆辙。Simon Willison 并行运行四个编码 Agent，而 Vercel Agent 和 CodeRabbit 这样的审查机器人已经入驻数百万个仓库。其他维护者，如 Daniel Stenberg，则选择屏蔽 AI 生成的提交到 curl。

所有这些都有帮助，但没有一项能解决核心约束：所有这些解决方案仍然将每一次变更都路由到一个人的注意力上。我们相信，在 Agent 工程中，人类问责制仍然是信任的核心，所以我们知道我们的工厂需要把审查者效率作为首要原则来解决。

什么样的自动化适合 AI SDK？

软件工厂位于一条频谱的一端。一端是全自动化，Agent 编写、发布和部署代码，而人类从不阅读代码。中间是像 Codex 和 Claude Code 这样的适配层，一个人可以驾驶一个或一群 Agent。另一端是你几乎不想自动化的软件，因为风险太高，比如心脏起搏器中的固件或自动驾驶汽车。

AI SDK 需要在更谨慎的一端运作。它是基础 AI 基础设施，数百万应用程序构建于其上，因此质量和安全是不可妥协的，而且需要有人控制发布的内容。我们需要我们的工厂在人类周围大力自动化生命周期，但不移除人类。

如何使自动化和人类工作与风险对齐？

对于一个给定的变更，所需的人类审查深度与风险成正比。

带有详细功能规格的集中式路线图可以预先定义风险，并直接塑造进入软件工厂的工作。但像 AI SDK 这样的开源项目也会从社区收到 issue 和 pull request，不能保证它们与项目目标一致，也不能保证变更都是安全的。更高的风险意味着人类判断在系统中是更关键的部分。

为了优化我们的工厂来做出这种判断，我们知道 Agent 必须超越基于请求生成代码的范畴；它们需要在整个项目的背景下评估完整的工作单元。

我们的目标是让工厂生成每个变更的全面评估，包括契合度和风险，并提供完整的证据链记录，让审查者能够轻松地投入适当的工作量：

文档修复只需快速浏览验证

定义明确的提供商变更需进行重点验证

新的公开 API 需要深入审查

我们构建了什么

ai-sdk-factory 是一个软件工厂，自主处理 AI SDK 的 incoming issue 和 pull request。工厂中的 Agent 执行特定的、可审查的任务，如复现 bug、实现功能、为旧版 SDK 创建 backport。整个过程中人类保持控制，包括合并每个变更。

我们没有一次性交付工厂，而是逐步构建的，从流程的起点开始，将 issue 分类为 bug、功能或文档更新。第一步不仅让我们对积压工作的形态有了更多了解，还为后来构建的其他专业 Agent 传递了有价值的上下文。

我们原型化了多种方式来构建每个新类型的功能，在这个过程中形成了一套指导原则，塑造了进入生产环境的工厂架构。

每个任务构建一个 Agent

一旦我们的分类 Agent 达到了高准确率，我们专注于自动化 bug 复现、修复以及对修复的审查。我们探索构建一个具备每一步技能的单一 Agent，但很快意识到随着时间的推移，这会带来更高的维护和故障排除负担。

相反，我们为每个特定任务构建了一个单独的 Agent，使每个新能力都更容易推理、隔离测试和调试。每一个都被限定在一个特定的工作中，有自己的 prompt、上下文和评估。

如今工厂在流程的每个步骤都有专门的 Agent：

文档更新

功能实现

从一开始确保一切安全

我们在第二个 Agent 中实现了安全性，因为 bug 复现是工厂首次基于不受控内容执行代码的步骤。

在公共仓库上运行的工厂必须假设攻击者控制的输入：每个 issue、pull request、评论以及其中的链接都是不可信的。因为成功的开源项目是高价值目标，威胁范围从恶意代码变更和供应链攻击，到资源耗尽、API 密钥泄露和 prompt 泄露。

沙箱是我们防御的基础。ai-sdk-factory 中的每个 Agent 都在一个隔离的 Vercel Sandbox 中运行，包含其代码、运行时，以及 Agent 特定任务所需的 secrets。有了这些护栏，不受信任的内容可以影响 Agent 提议的内容，但任何单一任务可能造成的损害都被限制在沙箱内。

我们还在沙箱周围构建了一层屏蔽层，控制 Agent 可以通过网络访问什么，阻断攻击者用来从隔离环境中提取 secrets 的路径。

最后一道防线是人类审查：没有任何内容可以在没有 AI SDK 团队中人类批准的情况下被合并。

先在本地构建价值，再迁移到云端

我们为工厂构建的前几个 Agent 是通过本地 CLI 运行的。这使我们的团队能够快速迭代，因为我们注意到了不准确之处、感受到了摩擦、并原型化了不同的想法。

一旦多个步骤通过 CLI 可靠地运行，我们就准备好将系统转移到托管基础设施上。ai-sdk-factory 使用：

用于 API、workers 和 webhook 入站的 Vercel Functions

用于任务执行的 Vercel Queues

用于 Agent 工作空间的 Vercel Sandbox

用于工厂数据的 Neon Postgres

如今，GitHub webhook 喂养 issue 队列，一旦它们到达，workers 自动拉取并在沙箱中启动 Agent 运行。我们还构建了一个监控 UI，跟踪每个并行运行，并可视化队列供审查者团队使用。

通过我们的工厂发布软件

7 月 24 日，一位社区成员请求在 OpenAI 网络搜索中支持 blocked-domain，该请求成为 issue #17898。以下部分解释软件工厂处理该 issue、打开带有功能实现的 pull request、并最终将合并的功能 backport 到 SDK v5 和 v6 所经历的每个步骤。

工厂运行的第一个 Agent 对 issue 和 pull request 进行分类。在这种情况下，ai-sdk-factory bot 在 issue 上评论并应用了一个标签，以高置信度识别类型为 Feature。Agent 在评论中包含其分类的理由。

分类之后，分析 Agent 运行。工厂中的 Agent 不会对功能请求或 bug 的技术有效性做任何假设，因此分析 Agent 编写了一个探针来确认 blocked domains 支持的缺失。issue-17898-type-probe.ts 被生成并运行，在查找 blocked-domains 但未找到时以错误失败。

失败的探针证明了该功能在 main 分支上缺失，Agent 将其作为证据包含在分析中。

然后分析 Agent 使用其调查结果为该功能构建了规格：在现有的 web-search 工具中添加一个可选的 blockedDomains 过滤器，并将其映射到提供商的 blocked_domains 字段。

Agent 还确认该规格符合 SDK 的 provider-adapter 架构并且是向后兼容的，甚至划定了文档变更的范围。

另一个 Agent 随后实现了规格并打开了 pull request。实现 Agent 运行了一个实时的端到端测试，执行了一个 wikipedia.org 被 blocked 的 OpenAI 网络搜索，并确认该域名无法访问。该测试作为额外证据被包含在 pull request 上。

接下来，一个审查 Agent 对变更进行了评分，当没有发现任何问题时批准了它。Agent 将该功能评级为完全实现，评分如下：

副作用风险：低

性能风险：无

向后兼容风险：低

最后，Lars 阅读了来自 Agent 的证据链，审查了代码变更，并合并了 PR #18033 到 main。

一旦 Lars 合并了初始 PR，ai-sdk-factory 为两个 backport 打开了额外的 PR，#18035 针对 v6，#18036 针对 v5。v5 的 backport 没有干净地应用，因此工厂 Agent 标记并提交了冲突状态，确定并验证了一个修复，并在十七分钟后推送了它。审查之后，Lars 合并了这两个 backport PR。

结果

我们在生产环境中运行软件工厂刚刚超过四周。以下是结果：

我们每周合并的 PR 中，有 25% 到 35% 现在是由 ai-sdk-factory Agent 编写的。

工厂 PR 占每周合并到 v6 发布线的 50% 以上，v5 也类似。Backport 曾经是我们跳过的工

作，因为处理合并冲突不值得。v5 和 v6 现在得到了更好的支持。

在七月，关闭的 issue 中有超过 75% 是由工厂关闭的。

Open issue 从六月底峰值的 1022 个下降到八月初的 844 个，open bug 下降了约 25%。

ai-sdk-factory 是公开运行的，所以你可以在仓库上看到它编写的每个 pull request。

改进工厂成为工作本身

运行工厂最有趣的部分是当它失败时会发生什么。每次运行以四种方式之一结束：成功、有缺陷、阻塞或手动。只有成功才会发布，所以其余的都是重新进入系统作为反馈的信号。

有缺陷的运行意味着 Agent 产生了错误的东西，修复方法是更好的 prompt、更好的上下文，或者一个新的评估案例，以便下次自动捕获相同的错误

阻塞的运行意味着环境缺少某些东西，比如凭证、服务或依赖，修复方法是配置它

手动运行标记了我们有意画的边界，并迫使我们问自己：工厂的改进是否足以移除它

这些修复中的每一个都扩展了自动化边界，每周工厂都能处理之前无法信任它的工作。

运行工厂与团队已经应用于测试套件和流水线的纪律相同，但指向的是做工作的系统，而不是检查工作的系统。在一个 Agent 定义 SDLC 的世界里，改进工厂将成为标准的工程工作。

在一键部署你自己的软件工厂

这个软件工厂随 4 个 Agent 一同交付：Classifier、Analyzer、Implementer、Reviewer。开源并构建在 eve 之上。