为 AI SDK 搭建一座「软件工厂」

AI SDK 团队近期公开了一套被称为「软件工厂」的自动化系统 ai-sdk-factory，用于自主处理 AI SDK 项目涌入的 issue 与 pull request。四周时间上线后，这套工厂已能贡献团队合并 PR 的 25–35%，并关闭 70–80% 的新提交问题，同时保留人类维护者对每一次合并的最终控制权。

项目规模与积压挑战

AI SDK 是目前下载量最大的开源 AI 项目之一，每周下载量超过 2000 万次，GitHub 仓库收获 26000 颗以上的 star。维护团队需要同时追踪四个快速变化的维度：模型提供方及其新能力、React / Next.js / Svelte / Vue 等 UI 框架绑定、agent 运行代码所用的沙箱环境，以及 Codex、Claude Code、Pi 等 harness 适配器。

随着多年累积，项目每月新增 issue 已超过 100 条。在 Anthropic 发布 Opus 4.6 模型之后，PR 数量出现拐点式增长；到 6 月底，仓库已堆积超过 1000 个未关闭 issue 和接近 800 个待处理 PR。团队指出，这并非维护者投入不足的问题：随着代码生成成本持续降低，积压只可能继续扩大，靠「更努力地工作」无法弥合差距。

为什么是「工厂」而不是更多 agent

在动手前，团队回答了三个前置问题：现有 agent 方案为何不足、什么程度的自动化适合 AI SDK 这类项目、如何让自动化与人工投入与风险对齐。

业界已有多种尝试：Mitchell Hashimoto 让 agent 持续在 Ghostty 仓库工作并把每次失败写入 AGENTS.md；Simon Willison 并行运行四个编码 agent；Vercel Agent、CodeRabbit 等审查 bot 已部署在数百万仓库；Daniel Stenberg 则选择直接屏蔽 cURL 的 AI 生成提交。这些做法都有价值，但都把每一处变更路由到同一位人类审阅者的注意力上。团队认为，agentic 工程中的信任核心仍是人类问责制，因此工厂的第一原则是提升 reviewer 的效率，而不是绕过人。

自动化存在一个光谱：一端是完全无人值守的 agent 全流程部署，中间是 Codex、Claude Code 这类由人指挥的 harness，另一端是几乎不应自动化的关键系统（如心脏起搏器固件、自动驾驶）。AI SDK 属于基础设施层，全球有上百万应用构建于其上，质量与安全不可妥协，需要把自动化压在围绕人类的生命周期里，而不是把人移除。

风险对齐：按变更风险调整审查深度

工厂的设计目标是为每一次变更生成完整的「适配度与风险评估」，附带一串可追溯的证据链，让 reviewer 按需投入精力：

• 文档修复：快速扫一眼即可核实；
• 定义明确的 provider 变更：做有针对性的验证；
• 新公共 API：进入深度评审。

中央化的路线图与详细功能规格可以在变更进入工厂前就定义好风险，但开源项目同时会收到大量社区提交的 issue 与 PR，无法保证它们与项目目标一致或足够安全。风险越高，对人类判断的依赖就越重。

工厂架构与原则

ai-sdk-factory 由一系列专门 agent 组成，每个 agent 负责一项可独立审视的任务：bug 复现、bug 修复、PR 评审、向旧版本 SDK 做 backport、文档更新、功能分析、功能实现。人类在整个流程中始终掌握控制权，包括最终合并。

团队刻意采用「一任务一 agent」而非「一个万能 agent + 多项技能」的路线：后者会带来更高的维护与排障成本，前者让每一项新能力都更容易推理、隔离测试和调试。每个 agent 拥有独立的 prompt、上下文和评估体系。

系统是增量上线的。第一步先做 issue 分类（bug / 功能 / 文档），这一步本身已经让团队看清了积压的形态，并为后续专门 agent 提供了有用的上下文。随后才接入 bug 复现、修复、评审等环节。安全机制从第二个 agent（即 bug 复现）开始就同步引入，因为这是工厂首次执行不可信内容对应代码的节点。