Vercel 开始造“软件工厂”了：AI Coding 的下一站，不是更多 Agent

如果 Coding Agent 一天能同时完成十几个任务、提交十几个 PR，研发效率是不是也会跟着提升十几倍？

不一定。Agent 可以并行运行，可以在后台持续工作，但最终产出的代码仍然要被人理解、验证和判断。Coding 的产能上来之后，Review 很快会成为新的瓶颈。

Vercel 的 AI SDK（Vercel 开源的 TypeScript AI 应用开发工具包）团队已经碰到了这个问题。到今年 6 月底，仓库里积累了超过 1000 个 Open Issues 和接近 800 个 PR。团队没有继续简单增加 Coding Agent，而是搭起了一套 Software Factory：让不同 Agent 分别负责问题分类、复现、分析、实现、Review 和旧版本 Backport，并把验证、风险评估和人工决策放进同一条链路。

这套系统运行四周后，每周约 25%～35% 的 merged PR 已经来自 Factory；7 月关闭的 Issue 中，超过 75% 由它处理，Open Bugs 也下降了约 25%。

这组数据背后更值得讨论的是一个问题：当代码生成不再稀缺，有限的人类判断力应该放在哪里？

过去我们谈 AI Coding，常看的指标是生成速度、代码采纳率、一次能完成多少任务，或者一个工程师能同时驱动几个 Agent。这些指标当然重要，但衡量的主要还是代码生成这一环。

Agent 把 Coding Throughput 提高以后，后面的环节并不会自动变快。一个任务是否真的完成，仍然要经过需求理解、方案判断、验证、兼容性检查、风险评估以及最终 Merge。代码生成只是其中一环。

这也是为什么“更多 Agent”不一定等于“更高交付效率”。假设过去一个 Maintainer 一天只能完成两个修改，现在可以同时启动十个 Agent，结果可能不是十倍交付，而是十个等待 Review 的 PR。Coding 的瓶颈被打开以后，Review Capacity 反而更快暴露出来。

Vercel 在设计 Factory 时，把 reviewer efficiency 放在了很靠前的位置。因为 AI SDK 的 Maintainer 本身已经是 Coding Agent 的积极使用者，有人会长期让 Agent 在后台工作，也有人同时启动多个 Agent，再叠加自动 Code Review。但无论前面启动多少 Agent，最后所有修改仍然会汇入人的注意力。

所以问题已经不只是“Agent 能完成多少 Coding Task”，而是整个研发系统最终能够消化多少可信的工作。

AI Coding 往下走，真正需要优化的已经不只是写代码的吞吐，而是整条研发链路的有效吞吐。

Vercel 并没有做一个能力越来越大的“超级 Agent”。

他们最开始试过一个 Agent 搭配多个 Skills，让它根据任务调用不同能力，但很快发现，随着职责增加，维护、故障定位和 Eval（用于持续评估 Agent 效果的测试用例）都会越来越复杂。

最终，他们选择了 One Agent Per Task。

Issue Classification 由一个 Agent 负责，Bug Reproduction 由另一个 Agent 负责，Implementation、PR Review、Feature Analysis、Documentation Update、Backport（把主分支上的修改同步到仍在维护的旧版本）也分别拆开。每类任务都有自己的 Prompt、Context 和 Eval，可以独立测试、调试和迭代。

这里的重点并不是“Multi-Agent 比 Single Agent 更先进”，也不意味着 Skills 这条路线走不通。Agent 和 Skill 实际上解决的是不同层级的问题。

如果 React、数据库迁移、测试规范只是 Implementation Agent 完成同一类职责时需要调用的不同经验，它们完全可以继续做成 Skills；但 Reproduction、Implementation 和 Review 的目标、上下文、权限乃至评价标准已经明显不同，就更适合拆成独立 Agent。

所以一个更可能长期存在的形态是：

上层用 Agent 划分职责和治理边界，下层再通过 Skills 复用专业知识和方法。

真正重要的是，每个 Agent 开始拥有清晰的职责边界，并且可以被独立评估和维护。

这个区别在生产系统里很关键。如果一个 Bug 最终修错了，可以继续追问：是最初 Classification 错了，还是 Reproduction 没有准确复现？是 Implementation 偏离了 Spec，还是 Review 没有识别风险？每个节点都可以单独定位，而不是最后只得到一句“这次 Agent 没做好”。

从这个角度看，Agent 的边界已经越来越像传统软件系统里的模块边界。

如果 Software Factory 只是把一个任务拆给多个 Agent，它的价值仍然有限。Vercel 这次实践里更值得关注的是：Agent 的交付物开始从代码扩展成证据。

文章里有一个很完整的真实案例。

7 月 24 日，一位社区用户提出，希望 AI SDK 的 OpenAI Web Search 支持 blockedDomains（用于禁止 Web Search 访问指定域名的配置）。如果按照最直接的 Coding Agent 路径，系统读取 Issue 后就可以开始修改代码。

AI SDK Factory 没有这么做。

Classification Agent 先判断这是一个 Feature Request。随后，Analysis Agent 写了一个 Probe（用于验证某个假设的最小测试），在当前 main 分支运行，确认现有实现确实不支持 blockedDomains。

也就是说，在进入实现之前，Factory 先证明了一件事：这个问题本身成立。

确认之后，Analysis Agent 才继续形成 Spec，包括 API 如何增加字段、Provider Adapter 如何映射、是否保持向后兼容，以及需要修改哪些文档。

Implementation Agent 再根据 Spec 修改代码。实现完成以后，它实际调用 OpenAI Web Search，把 wikipedia.org 放进 blocked domains，并检查返回结果，确认这个域名确实无法被访问。

随后，独立的 Review Agent 检查整个修改，包括功能是否完整、是否存在副作用、性能风险以及向后兼容问题。最后才由 Maintainer 阅读这些证据、Review 代码，并决定 Merge。

到这里，人拿到的已经不只是一个 Code Diff，而是一条相对完整的工程证据链：

这会直接改变 Review 的成本。

如果 Agent 只是提交 500 行代码，再告诉你“实现完成，测试通过”，Reviewer 仍然需要重新理解需求、确认修改范围、判断方案、检查测试是否覆盖关键行为。Coding 的时间省掉了，但判断成本并没有减少多少。

如果 Agent 同时给出问题复现、实现依据、验证结果和风险分析，人就可以把更多精力放在真正依赖经验和判断的问题上。

Software Factory 生产的不只是代码，而是在尝试交付一个带着 Evidence 的工程工作单元。

Verification 也因此不再只是实现结束后的最后一道测试。它开始出现在链路两端：实现之前，验证“我们是不是在解决一个真实而且理解正确的问题”；实现之后，再验证“这个修改是不是真的解决了它”。

从生成 Code，到交付 Code + Evidence，这可能是 AI Coding 进入生产系统之后非常重要的一步。

Vercel 并没有因为 Factory 可以完成大量工作，就把人从流程里拿掉。

AI SDK 是大量项目依赖的基础设施，最终进入主干的修改仍然必须由人 Review 和 Merge。但这并不意味着每个任务都值得投入同样多的人工注意力。

一处 Documentation Fix，可能只需要快速确认；一个边界清晰的 Provider Change，可以做针对性验证；一个新的 Public API，则需要更深入地判断 API 设计、兼容性和长期维护成本。

这其实比简单讨论 Human-in-the-loop 更进一步。

过去我们强调关键节点需要保留人工 Gate，但当 Agent 产生的工作量大幅增加以后，如果所有任务都机械地进入同一种人工审批流程，人的注意力仍然会被迅速耗尽。更合理的方式，是让人工投入与任务风险相匹配。

哪些事实可以由 Agent 提前验证，哪些兼容性问题可以自动检查，哪些修改只需要快速扫一遍，哪些决策必须由有经验的 Maintainer 深度参与，这些问题本身开始成为系统设计的一部分。

从这个角度看，AI 不是简单替代 Review，而是在重新组织 Review。Agent 先完成信息搜集、问题复现、机械实现、自动验证和部分风险识别，人再负责那些无法被可靠自动化的判断。

当 Coding Throughput 越来越容易扩张，真正稀缺的开始变成人的判断带宽。

Software Factory 很大一部分价值，就在于尽可能减少人重新调查和重新验证每个任务的成本，把有限的注意力放到 API 设计、架构 Trade-off、产品决策和高风险变更上。

这可能也是为什么 Vercel 没有选择完全自治的软件工厂。他们自动化的是围绕 Human Judgment 的大量工作，而不是简单把 Human Judgment 从系统里删除。

Vercel 的另一个实践细节也很值得借鉴：他们没有一开始就设计一套覆盖完整研发流程的平台。

第一步只是 Issue Classification。

这个能力稳定之后，再加入 Bug Reproduction；之后继续增加 Fix、Review、Feature、Documentation、Backport。最早几个 Agent 甚至没有直接部署到完整的云端系统，而是先通过本地 CLI 跑真实任务。

等这些能力逐渐稳定以后，团队才把系统迁移到由 Functions、Queues、Sandbox、Database、Logs 和 Monitoring UI 组成的生产环境。

这个顺序很重要。

很多研发自动化方案容易先从一张完整流程图出发：Requirement、Design、Development、Test、Release，然后试图一次把所有环节串起来。系统很快变得很大，但真正的问题也变得越来越难定位：到底是模型不行、上下文不够、验证不充分，还是 Runtime 自身不稳定？

Vercel 走的是另一条路：先找到一个高频、边界清晰、容易验证的任务，把它跑稳；再增加下一个任务，并建立两个节点之间稳定的输入输出关系。随着越来越多节点成熟，Factory 才逐渐形成。

先跑稳一个真实任务，再一点点扩大 Automation Boundary，比先设计一座完整的“无人软件工厂”更现实。

这种演进方式也体现在他们对失败的处理上。Factory 的每次运行会进入 Success、Flawed、Blocked 或 Manual 四种状态。

Flawed 说明 Agent 产生了错误结果，团队就继续改 Prompt、Context 或补新的 Eval；Blocked 说明 Agent 不一定不会做，而是运行环境缺 Credential、Service 或 Dependency，需要补 Runtime 能力；Manual 则代表系统触碰到了团队主动保留的人工边界，需要持续判断这部分是否已经具备进一步自动化的条件。

它们并没有被统统归类成“Agent 执行失败”。

每一种失败都会返回到系统的不同层，成为下一轮优化的输入。自动化边界也就在这个过程中一点点向外扩张。

这里也包括 Backport 这样的任务。blockedDomains 功能合入 main 后，Factory 又自动为 v6 和 v5 创建 Backport PR。其中 v5 因代码差异出现冲突，Agent 继续识别冲突、完成修改和验证，再交给人 Review。过去这类工作因为机械、耗时、收益有限，经常会被 Maintainer 推迟甚至放弃，现在则非常适合交给 Factory。

Vercel 在文章最后写了一句话：

我觉得这句话比“Software Factory”这个名字本身更值得关注。

过去，大部分工程师主要维护的是 Product Code。需求来了，我们分析、实现、测试，然后交付。

但当 Agent 持续进入研发流程以后，工程师需要维护的对象正在增加：Prompt、Context、Eval、Tools、Harness、Runtime、Verification、Workflow、Policy，以及它们之间的边界和反馈机制。

这些能力共同构成了另一套系统——一套“生产软件的软件”。

过去工程师更常问的是：

以后可能会越来越多地问：

这也是为什么我觉得，AI Coding 的下一站未必是再增加更多 Agent。

Agent 数量增加以后，代码产能可以继续上升，但这并不会自动转化成更高的软件交付能力。真正决定一套研发系统能够走多远的，开始变成 Agent 如何被组织、结果如何被验证、风险如何被管理，以及有限的人类判断力最终被放在哪里。

Vercel 所说的 Software Factory，真正值得关注的或许正是这里。

参考

Vercel，Building a software factory for AI SDK，2026-08-12
https://vercel.com/blog/building-a-software-factory-for-ai-sdk