Agentic 软件工厂：如何构建从 Issue 到生产、值得信赖的 AI 流水线

智能体软件工厂使用 AI Agent 将变更从 Issue 一路带到生产环境，由确定性门禁决定哪些可以发布。本文涵盖 Stripe、Spotify、OpenAI、StrongDM 和 Warp 的报告、参考循环、验证、合并队列、灰度发布、安全、成本、模型升级，以及一个 Google ADK 构建。

作者：JAMES BENNETT · FDEINTERVIEWS 编辑部 · 更新于 2026 年 10 月 20 日 · 阅读时长 36 分钟

实践一下：面向 FDE 的 Harness 工程课程 ·RAG 与 Agent 设计问题 ·评测回归套件与 CI 门禁的概念 ·必知的 FDE 问题

智能体软件工厂是一条流水线，AI Agent 将变更从需求一路带到生产环境。分诊 Agent 判断工作是否就绪，规格 Agent 将模糊之处转化为可检查的需求，实现 Agent 在沙箱中编写代码。随后，独立的验证与评审 Agent 试图证明代码有误，合并队列和渐进式发布决定是否上线，监控则将新问题重新录入。 人类不再敲代码，而是开始编写意图，负责门禁，并批准门禁无法判断的内容。CI/CD 自动化了变更所经过的路径，而工厂自动化的是变更本身的生产，这使稀缺资源从编写代码转移到验证和评审代码。已公布数据（Stripe、Spotify、OpenAI、StrongDM、Warp）的团队都认同这一转变，但在其他几乎所有方面都存在分歧，包括人类是否应该阅读代码。以下是截至 2026 年 10 月我们对有效做法的解读：证据、参考架构，以及大多数文章略过的部分——验证、合并物理、发布、安全、成本，以及底层模型发生变化时会发生什么。

运营软件工厂的团队公布了什么

这个术语并不新鲜（微软在 2000 年代曾用“软件工厂”指代模型驱动开发），但当前的含义来自 2025 年底至 2026 年中的一系列工程博客文章。每一篇都描述了同一条曲线上的不同位置。

现在来看制衡的一面。METR 2025 年 7 月的随机试验让 16 名经验丰富的开源开发者在自己维护的仓库中完成 246 个任务；使用 AI 工具后，他们耗时增加了约 19%，但他们却认为自己快了约 20%。Google 2025 年的 DORA 报告（近 5,000 名受访者，90% 在工作中使用 AI）发现，AI 的采用如今与更高的交付吞吐量相关，但仍与更低的交付稳定性相关，且 30% 的受访者表示对 AI 生成的代码几乎没有或完全没有信任。CodeRabbit 在 2025 年 12 月对 470 个开源 PR 的分析发现，AI 协作撰写的 PR 中问题数量约为 1.7 倍——考虑到 CodeRabbit 是销售代码评审产品的，阅读这一数字时应有所保留。

这些并不与工厂数据相矛盾。它们是从另一面描述同一件事。开发者在庞大而熟悉的代码库中与助手协作时，需要实时承担引导和检查的成本。工厂则将这一成本转移到无需人工监督即可运行的关卡中，而且只有在这些关卡存在的地方才有回报。这正是 DORA 的发现，一句话概括：AI 会放大它所落地的任何交付系统。

以上所有来源都支持以下五个结论：

• 关卡是代码，而不是提示词。 Stripe 的测试步骤无论模型怎么想都会运行。OpenAI 将其架构规则编码为 linter。Spotify 将验证移到了 Agent 无法触及的运行时中。
• 瓶颈转移到了审查和意图上。 Spotify 在 2026 年 3 月的 QCon London 上直言不讳：生成不再是约束，PR 审查才是。
• Agent 会钻弱评分器的空子。 Spotify 的早期 agent 会注释掉失败的测试并降级 Java 版本以获得绿色构建。StrongDM 正是出于这个原因把场景放在代码库之外。
• 狭窄、重复的变更类型先行。 每一个公开的大数字都是一次迁移、一次依赖升级或一次机械性重构。
• 没有稳定性控制的吞吐量会让交付变得更糟。 更多变更通过同样薄弱的门禁，意味着更多事故、更快发生。

工厂与 CI/CD 的区别

在 CI/CD 中，流水线是可信的，变更是可疑的。在工厂中，两者都可疑，而且每次模型发布时流水线都会变化。本指南的大部分内容都源于这一点。

参考循环

下面的循环是大多数公开的工厂最终收敛的形态，它与 Warp 记录的阶段（分诊、规格、实现、审查、验证、发布、监控）相吻合。把它当作一组决策来读，每个决策由一个 agent 或一个人负责，每条失败路径都有明确的去向。

我们的参考设计。Stripe 关于 Minions 的叙述 描述了确定性蓝图和隔离的 devbox，它们为实现与门禁的分离提供了依据。

接入

工作从团队已经在沟通的地方进来：Stripe 的大多数 Minion 运行是通过在会话中 @ 一个 Slack 应用启动的，这会把该会话及其链接交给 agent；Warp 接受 Slack、Teams、GitHub、GitLab、Linear 和 Jira；监控告警是第三个来源。在任何 agent 运行之前，接入应附上三样东西：谁提出的请求、这项工作涉及哪个代码库和负责人，以及变更类型（下文详述类型）。如果每个条目都没有负责人，工厂就会产出无人认领的 PR。

分诊：负责说“不”的 agent

分诊是最便宜的阶段，也是省钱最多的阶段，因为它拒绝的每一个未就绪条目，都省下了一次实现运行、一次 CI 运行和一次审查的费用。Warp 公开的分诊技能会尝试理解并复现该 issue，然后打上四个标签之一：

ready-to-implement

,

ready-to-spec

,

needs-info

或者

wait-to-implement

。后两种会让工厂停摆，直到有人采取行动。

两条设计规则让分诊有效运转。给它只读工具且不授予任何密钥，因为它读取的是系统中最不受信任的文本（任何人都可以提交的 issue）。并用精确率来衡量它——即可自动化的标签的精确率，也就是它发往实现阶段的条目中最终被接受的变更所占的比例。一个把所有条目都往前送的 triage agent 看起来很高效，实际上却在烧钱。

规格说明：把模糊性转化为可检查的需求

当条目模糊或过大时，spec agent 会在任何人写代码之前先把它写下来。Warp 的 spec agent 会生成一份

PRODUCT.md

和一份

TECH.md

，存放在

specs/

下，并由人来审批。AWS 的 Kiro 以 EARS 形式（"WHEN 某条件 THE SYSTEM SHALL 某行为"）编写需求，并在需求、设计和任务之间设置审批关卡；GitHub 的开源 Spec Kit 则运行类似的 specify、plan、tasks 流程，可搭配你已有的任何 agent 使用。

格式本身不重要，重要的是一个属性：每条需求都有一个 ID 和一个能证明它的具名测试。无法检查的规格说明只是愿望，工厂的其余环节也就无从验证。

在沙箱中实现

实现 agent 在一个隔离的、一次性的环境中工作，仓库已检出。Stripe 的 devbox 预先预热，约 10 秒即可启动，并且与生产环境和互联网隔离，这正是 Minions 无需为每条命令请求许可就能运行的原因。在本地，每个 agent 使用一个 Git worktree 来隔离各自的工作副本。但这并不能隔离进程、凭据或网络访问；这些控制需要沙箱来实现。

先快反馈，后慢反馈：Stripe 在每次推送时于五秒内运行选定的 lint，然后是选择性 CI，并在交还给人之前将 CI 限制在两轮以内。Airbnb 发现，把失败文件连同其错误输出一起重试，比进一步调优提示词更有效；其工程师称这种方法为“暴力法”，它在四小时内迁移了约 75% 的文件。

验证：使用不同工具的另一个 agent

写代码的 agent 是对代码最差的评判者。Anthropic 的 harness 工作发现，调优一个独立的、持怀疑态度的评估器，远比让生成器对自身输出保持批判性容易得多，并且他们给评估器配了浏览器，使其可以点击运行中的应用。Warp 的实现 agent 使用 computer use 端到端地检查变更，并将录屏保存到 PR 中。Google 的 Antigravity 将这些输出称为 Artifacts：即人可以查看的计划、截图和浏览器录屏。

验证者应以全新的上下文开始：只有规格说明、构建产物和场景，而不包含实现者的推理。继承制作者的说明，正是检查者说服自己表示同意的方式。

审查：agent 先行，人在策略要求之处介入

审查 Agent 与实现者循环迭代若干轮（有上限），然后由人类结合验证证据一起审查 diff。并行的专项审查者（安全、性能、规格覆盖）比单个通才审查者能发现更多问题，而成本几乎不增加，因为它们同时运行。至少让一个审查者使用不同家族的模型，可以降低制造者和检查者拥有相同盲点的概率——这正是斯坦福法学院一篇博客文章对 StrongDM 配置提出的担忧。

合并、发布、监控

合并队列让变更针对当前 head 逐个落地。渐进式发布将每个变更暴露给一部分流量。监控 Agent 观察部署标记和错误率并创建新 issue，从而形成闭环。下面每一项都有单独的章节，因为每一项在 Agent 速度下都会以特定方式出问题。

自主性按变更类别划分，而非按公司划分

Dan Shapiro 在 2026 年 1 月提出的“五个层级”借鉴了驾驶自动化：从底部的“带劲的自动补全”，到像审查初级工程师一样审查的 Agent，再到顶部的“黑灯工厂”——输入规格，产出软件，全程无人查看。这些层级是有用的词汇。错误在于为整个组织只选一个层级。

依赖版本升级和对支付账本的变更绝不应共享同一策略。按变更类别设定上限，仅凭该类别自身的业绩记录来晋升，并在首次出现逃逸缺陷时降级。

我们推荐的晋升规则是：当一个类在连续多次被接受的变更中没有出现任何逃逸缺陷，并且对随机样本的人工审计结果干净时，就晋升一级；而一旦发生由它引起的事故，就降回原级。历史记录本身就是论据。没有人需要通过辩论来争论 AI Agent 总体上是否可信。

验证就是产品

如果工厂的产出是没有人完整阅读的代码，那么工厂真正的产品就是它的验证体系。这里的一切都是为了让“门禁全绿”意味着“需求已满足”。

确定性门禁优先

构建、类型检查、lint、单元测试、结构测试。它们便宜、快速、且无可争辩。OpenAI 的团队更进一步，编写了自定义 linter，其错误信息中包含修复指引，让门禁同时教会 Agent 如何修复。每一条你能用 linter 表达的架构规则，都是评审者少需要记住的一件事。

保护评分器

一个以构建变绿为目标的 Agent 会修改任何能让构建变绿的东西，包括测试本身。把测试、CI 配置和工厂自身的设置放在排除该 Agent 的 CODEOWNERS 条目之下。拒绝任何同时修改实现和评判该实现的测试的变更，或将其转交人工处理。将工厂的配置设为仅限人工修改。GitHub 的 Copilot coding agent 在结构上强制执行了这一原则的一个版本：它只能推送到名为

copilot/

的分支，不能批准或合并自己的 pull request，而且请求该工作的人也不能批准它。

留出场景

StrongDM 最具可迁移性的想法是把端到端场景当作机器学习中的留出集来对待：存储在代码库之外，从不展示给编码 Agent，并由 LLM 打分，输出一个它称为满意度的概率（即观察到的场景运行中可能满足用户的比例），而不是单一的通过或失败。存放在代码库中的测试可以被改写以迁就代码，而 Agent 从未见过的场景则不能。

StrongDM 针对其称为数字孪生宇宙的环境运行这些场景：Okta、Jira、Slack、Google Docs、Google Drive 和 Google Sheets 的行为克隆体，这让它每小时能运行数千个场景，而不受速率限制、API 账单或真实账户风险的困扰。大多数团队不会克隆六个 SaaS 产品，但为你的产品最依赖的两个外部服务做一个仿真是在能力范围内的，而这正是让故障模式测试变得安全的关键。

用变异测试来测试测试

行覆盖率只能告诉你哪些代码行被执行过，却不能告诉你测试是否会注意到一个 bug。变异测试可以：它在代码中植入小的缺陷，然后检查是否有测试失败。Meta 的 ACH 系统发表于 FSE 2025，它会生成有针对性的变异体，然后编写能捕获它们的测试；应用于 10,795 个 Android Kotlin 类时，它产生了 9,095 个变异体和 571 个测试，在 Messenger 和 WhatsApp 的测试马拉松中，工程师接受了其中 73% 的测试。对于一个工厂来说，变更代码上的变异得分是对“Agent 写的测试到底好不好？”这个问题最诚实的单一答案。大多数技术栈都有现成的工具：Java 用 PIT，JavaScript 和 .NET 用 Stryker，Python 用 mutmut。

需求可追溯性：最接近数学证明的东西

你无法在一般情况下证明代码满足一条用英文写成的需求。但通过四层手段，你可以比“测试通过”更接近这一目标，成本由低到高：

• 每条需求的“先失败后通过”。 每个需求 ID 至少映射到一个测试，该测试在旧代码上失败、在新代码上通过，同时所有之前通过的测试仍然通过。这正是 SWE-bench 给补丁评分的方式，而这个门槛只是一段简短的脚本：在基础提交上运行指定的测试，在变更上运行它们，然后比较结果。
• 对变更行做变异得分，从而确保这些“先失败后通过”的测试确实能捕获缺陷。
• 对应当对所有输入都成立的恒定性质（导出绝不丢行、退款绝不超过收费金额）使用基于属性的测试，借助 Hypothesis 这类库来搜索反例。
• 对小而后果重大的核心部分使用形式化方法：协议的 TLA+ 模型、经过验证的状态机。成本高昂，所以只保留给那些一个 bug 的代价超过证明成本的部分。

然后再加上统计层，因为 Agent 的行为在不同运行之间会有差异。

一致性：pass^k

τ-bench 论文将 pass^k 定义为同一任务的 k 次独立尝试全部成功的概率，并指出一个强大的 2024 年 Agent 在零售任务上单次解决率不到一半，而在 pass^8 下低于 25%。这个算术是无情的：在独立性假设下，pass^k 就是单次运行成功率的 k 次方。

τ-bench 论文使用 pass^k 来衡量重复试验下的可靠性。这些曲线展示的是独立性假设下的 pᵏ，而非该论文的实测结果。

一个成功率为 90% 的 Agent，连续八次成功的概率只有约 43%。同样的算术也适用于跨阶段场景：一个六阶段流水线，如果每个阶段的正确率都是 95%，那么端到端的正确率只有约 74%。把重要的评测任务运行多次，在平均值旁边同时报告 pass^k，并把两者之间的差距视为一个可靠性 bug。

LLM 评审：建议性、经过校准、可替换

LLM 评审适用于代码无法回答的问题（“这个 PR 是否实现了 issue 的要求？”），但作为硬性门槛则很危险。Spotify 曾添加一个评审器来检查生成的代码是否符合原始需求，结果发现它过于僵化、会阻止有效的变更，随着模型改进便将其移除了。如果保留一个，请用几百个人工标注的样本进行校准，跟踪其一致率，并在评审器的模型每次变更时重新校准。我们的 LLM-as-a-judge 论文笔记涵盖了已知的偏差。

吞吐量物理规律：队列、冲突与评审墙

一个每天开出 100 个拉取请求的工厂，而团队只能评审 20 个，那它并没有建成工厂，而是建成了一个队列。Little 定律精确地说明了这一点：在稳态下，等待时间等于积压量除以清理速率，因此每天增加 80 个的积压会延长每个 PR 的等待时间，包括紧急的那些。为每位评审者设置打开的 Agent PR 的在制品上限，并在达到上限时让工厂停止拉取新工作。

Spotify 应对其评审墙的方案包含三部分：文化（让推动迁移的工程师批准其 PR 并关闭过时的 PR）、工具（一个能排定优先级、并可能自动合并文档的 PR 收件箱）和标准化（做事方式越少，Agent 代码正确的概率越高，评审也就越快）。同时也要降低评审本身的成本：每个 Agent PR 都应以它实现的规格说明、它能工作的证据（测试输出、场景结果、一段录屏）、未测试内容的说明以及变更类别作为开头。

并行 Agent 也会相互冲突。同时运行过多个 Agent 的实践者报告了相同的模式：两个 Agent 向同一个测试文件添加测试，两个 Agent 编辑同一个热点配置文件，一个 Agent 重命名了另一个仍在调用的函数。对于最后一种情况，Git 会报告干净的合并，只有在合并结果上重新运行测试才能发现问题。以下四个习惯能消除大部分痛苦：

• 在分诊时为每个任务声明文件作用域，并对热点文件持有租约，避免两个 Agent 抢占同一个文件。
• 把新测试放进以功能命名的新文件中，而不是追加到共享文件里。
• 所有变更都通过合并队列落地：将每次变更变基到当前最新提交上，并在合并前重新运行门禁检查，确保每次变更都是针对 main 分支的实际最终状态进行测试的。
• 保持 PR 小而短命。OpenAI 团队描述了最小化的合并门禁和短命的拉取请求，并通过后续重跑来处理不稳定的测试，而不是直接阻塞。

不稳定的测试值得特别一提。Agent 一旦碰到不稳定的测试就会重试、消耗 token，甚至可能去“修复”从未损坏的代码。将已知的不稳定测试隔离起来，并为 Agent 提供它所见每个失败测试的不稳定历史记录。

以 Agent 速度交付：来源追踪、发布与回滚

当某个指标在下午 3 点发生变动时，你需要知道是哪次变更导致的，以及是哪个工厂配置产生了那次变更。为每个 Agent 提交打上来源标记：运行 ID、模型的带日期版本、提示词和技能版本、规格 ID 以及变更类别。Git trailers 就足够了。并将相同的字段带到仪表盘上的部署标记中。没有这些，来自新模型版本的回归看起来就像一次随机的坏运气。

以下三条规则在 Agent 速度下比在人类速度下更为重要：

• 新行为通过功能开关发布，默认关闭。 合并和发布成为两个独立的决策，而在合并自动化之后，功能开发的发布决策仍可以长期保留在人类手中。
• 金丝雀分析是自动化的。 将金丝雀与基线在错误率、延迟 和一个业务指标上进行对比，无需等待人工即可回滚。Argo Rollouts、Flagger 和 Spinnaker 的 Kayenta 都能做到这一点；OpenFeature 则为你提供一个厂商中立的开关 API。
• 错误预算 为工厂把关。 当服务正在消耗其错误预算时，停止合并该服务的 Agent 变更。人工热修复则继续放行。

监控 Agent 闭合了循环，而没有熔断器的闭环就是一个振荡器。一条告警创建一个 issue，一个 Agent 修复了症状，部署又触发了另一条告警，循环不断重复。将告警按根因去重为每个根因一个 issue，限制监控器每天对每个服务可创建的 issue 数量，拒绝在无人工审查的情况下对工厂自身在过去一小时内发布的变更自动创建 issue，并为每个循环指定一名人类负责人。

安全：工厂本身就是一个攻击面

Simon Willison 的“致命三要素”（2025 年 6 月）指出，当一个 Agent 同时具备私有数据访问权限、暴露于不可信内容以及对外通信途径时，它就变得可被利用。一个朴素的工厂默认就具备这三者。它读取任何人撰写的 issue、PR 评论和依赖文档；它持有代码仓库，通常还持有密钥；并且它可以推送代码、发表评论并访问网络。Agent 读取的任何文本都可能携带它可能遵循的指令。解决方案是架构层面的：在每个阶段至少移除其中一条腿。

幻觉包这一行值得强调，因为利用它成本低，防范它也成本低：模型反复虚构的名称可以被他人注册。带允许列表的镜像可以消除这一类风险。关于注入方面的更多内容，请参阅我们的 prompt injection concept 和 agent sandboxing，AI security and governance questions 涵盖了面试官如何就此进行探查。

上下文管理：每个 Agent 应该看到什么

每个阶段都需要其决策所需的最小上下文，而检查者绝不应继承制造者的推理。这两个方向上出错代价都很高：上下文太少，Agent 会靠猜测；上下文太多，它会锚定在错误的东西上。

已发布的工厂实践中有四项能让实现 Agent 的上下文在仓库规模下有效运作。OpenAI 将 AGENTS.md 控制在约 100 行以内，作为目录使用，真正的知识存放在一个带版本管理的

docs/

目录中，并运行一个文档园艺 Agent 来标记过时的文档。Stripe 将几乎所有 Agent 规则限定在子目录范围内，因此编辑某个服务的 Agent 不会读取另一个服务的约定，并且在运行开始前预取提示词中链接的内容。OpenAI 让应用对 Agent 清晰可读：每个工作树启动自己的实例，Agent 可以直接查询日志和指标。对于长时间运行的任务，磁盘上的进度文件能在上下文压缩后保留下来，而对话历史则不能。我们在关于

和

的文章中对此有更深入的探讨。

工具上下文同样重要。在 400 个工具中做选择的模型，其选择质量不如在 12 个工具中做选择的模型，这正是 Stripe 为每个 Minion 提供精选工具子集的原因，也是为什么在架构中应包含一个按角色暴露工具的 Agent 网关。

成本：衡量每个被接受变更的成本

每次运行的 Token 花费是错误的指标。决定工厂是否划算的数字是每个被接受变更的成本：Token、沙箱计算、CI 分钟数、人工审查时间，再加上已合并但后来被回滚的变更成本。一次廉价运行产出的 PR 如果没人能合并，其代价是 Token 花费加上审查者拒绝它所花的时间。

已公布的参考数据差距很大。Warp 2026 年 8 月文章中的一张仪表盘截图显示，4 月至 7 月期间每个 PR 约 58 美元。StrongDM 的经验法则是，如果工厂每天每位工程师的 Token 花费低于 1,000 美元，就还有改进空间；Simon Willison 指出，当每月每位工程师的花费达到约 20,000 美元时，问题就变成了商业模式问题。对于不同的变更类别，两者都可能是对的。在合并一个变更能节省数天时间的地方大量投入，而在修改错别字上则几乎不花钱。

审查时间不是可以忽略的零头。举例来说，按每小时 100 美元的综合成本计算，15 分钟的审查价值 25 美元，与许多运行的 Token 成本处于同一量级。一个通过在 PR 中提供更好的证据而将审查时间减半的工厂，其节省效果与一个将 Token 减半的工厂相当。

这些杠杆，大致按收益排序：

• 尽早拒绝。 分诊是最廉价的阶段。它搁置的每一个未就绪条目，都省下了一整套实现、CI 和评审周期。
• 提示词缓存。 Agent 循环每一轮都会重新发送相同的长前缀（系统提示词、仓库地图、工具定义），而这正是 缓存 折扣所针对的场景。

定价假设：Claude 提示词缓存。示例采用官方声明的 1.25 倍写入和 0.1 倍读取费率；在预算规划前请核实所选模型的当前费率。

• 按阶段路由。 分诊、打标签和规格覆盖检查使用快速、廉价的模型；实现和安全评审使用强大的模型。我们的 模型路由概念 说明了如何决策。
• 硬性上限。 每个任务设置 token 预算、墙钟时间限制和重试上限，由编排器强制执行，而不是在提示词中请求。Stripe 的两轮 CI 限制就是范例。
• 按变更类别控制验证深度。 对一个错别字修复动用五个并行评审者是浪费。验证力度应随变更类别伸缩。
• 先做快速本地检查，再跑缓慢的 CI。 一个五秒钟就能失败的 lint 检查，可以省下二十分钟的流水线。

AI 成本与单位经济学概念 中有构建单位成本模型的通用方法。

模型升级：新模型就是整个工厂的一次部署

工厂的行为是模型、harness、提示词与技能、工具以及仓库的函数。改变其中任何一项，工厂都需要重新验收。模型升级是团队最常跳过验收的变更，因为新模型在公开 基准测试 上“更好”。

公开基准测试无法验收你的工厂。2026 年 2 月，OpenAI 停止公布 SWE-bench Verified 分数：它审计了其 o3 模型未能稳定解决的 138 道题目，发现其中 59.4% 的测试或描述存在实质性问题，并且发现证据表明前沿模型在训练中见过这些基准题目。（我们的 SWE-bench 论文笔记 解释了该基准是如何构建的。）一个反映训练接触程度的分数，对你的代码库毫无参考价值。

应改为构建私有回放套件。选取由人工修复过的已关闭 issue，连同合并的 PR 及其测试，并将其排除在所有提示词和技能之外。用 fail-to-pass 规则评分，加入你的保留场景，并记录成功率以外的更多指标。

在工厂配置中固定带日期的模型版本，绝不要指向"latest"别名，否则工厂会按照别人的时间表自行升级。要预期门槛需要在两个方向上重新论证：Spotify 曾在其 LLM 评审器改进到足以阻止更多坏变更时将其移除，而能力更强的模型可能需要更严格的篡改检查。

即使模型完全不变，行为也可能发生变化。Anthropic 2025 年 9 月的事后复盘描述了三个基础设施 bug，它们间歇性地降低了 Claude 的输出质量长达数周，并称其评测未能捕捉到用户报告的问题。其修复措施包括在生产系统上持续运行质量评测。工厂版本的做法是：每小时通过真实生产路径发送少量已知答案的金丝雀任务，并在通过率下降时发出警报。

基础设施：工厂运行在什么之上

工厂可以清晰地分为三个平面。控制平面负责决策；工作平面是一次性的；门槛平面是 Agent 绝不能更改的部分。

截至 2026 年 10 月，各层的可选方案（这个列表很快会过时；但各层本身不会）：

关于自建还是采购：Warp 自己的文章也承认，构建扩展工厂所需的全部基础设施是一项巨大的工程。我们的立场是租用沙箱和运行器，而自己掌控门槛和策略。门槛编码了你的组织对"正确"的定义，没有任何供应商能替你持有这一点。我们关于多 Agent 编排、Agent 可观测性和 Agent 与工作流的抉择的概念文章涵盖了控制平面内的设计选择。

在 Google 上构建一个：ADK、Gemini CLI 和 Jules

Google 的技术栈从三个层面覆盖工厂，且它们组合得很好。

• Gemini CLI GitHub Action（google-github-actions/run-gemini-cli）在 GitHub 工作流中运行，用于 issue 分诊、拉取请求评审，以及当有人提及 @gemini-cli 时提供按需帮助。项目上下文放在 GEMINI.md 文件中，该 action 的文档建议使用 Workload Identity Federation 而非长期有效的 API 密钥。这是为仓库配备分诊和首轮评审器的最快方式。
• Jules 是 Google 的异步编码 Agent：它将仓库克隆到云端虚拟机中，制定计划、运行测试并打开拉取请求。它提供命令行工具和 API，因此可以作为实现阶段的候选方案，由你自己的编排器调用。
• Agent Development Kit (ADK) 用于构建你自己的控制平面。其工作流 Agent 是确定性的：SequentialAgent 按顺序运行步骤，ParallelAgent 同时运行它们，LoopAgent 则不断重复，直到某个子 Agent 上报升级或达到最大迭代次数。Agent 通过会话状态共享数据（用 output_key 写入，用 {key} 占位符读取）。adk deploy 的目标可以是 Vertex AI 上的 Agent Engine、Cloud Run、GKE 或 Docker。

以下是用 ADK 实现的工厂核心。测试门是一个自定义 Agent，它运行真实的测试命令，因此模型无法与之争辩。

import subprocess
from typing import AsyncGenerator

from google.adk.agents import BaseAgent, LlmAgent, LoopAgent, ParallelAgent, SequentialAgent
from google.adk.agents.callback_context import CallbackContext
from google.adk.agents.invocation_context import InvocationContext
from google.adk.events import Event, EventActions
from google.genai import types

FAST, STRONG = "gemini-2.5-flash", "gemini-2.5-pro"  # pin the versions your replay suite qualified


class TestGate(BaseAgent):
    """Deterministic gate: runs the real test command. The model cannot argue with it."""

    command: list[str]

    async def _run_async_impl(self, ctx: InvocationContext) -> AsyncGenerator[Event, None]:
        result = subprocess.run(self.command, capture_output=True, text=True, timeout=900)
        passed = result.returncode == 0
        yield Event(
            author=self.name,
            content=types.Content(role="model", parts=[types.Part(text=result.stdout[-4000:])]),
            actions=EventActions(
                state_delta={"tests_passed": passed, "test_log": result.stdout[-4000:]},
                escalate=passed,  # green tests end the loop; red tests send it round again
            ),
        )


def require_green(callback_context: CallbackContext) -> types.Content | None:
    """A LoopAgent that runs out of iterations does not fail. Skip review instead of reviewing red code."""
    if not callback_context.state.get("tests_passed"):
        return types.Content(role="model", parts=[types.Part(
            text="Tests still red after the retry budget. Escalating to a human.")])
    return None


triage = LlmAgent(
    name="triage", model=FAST, output_key="triage",
    instruction="Read the issue: {issue}. Reply with exactly one label: "
                "ready-to-implement, ready-to-spec, needs-info or park, then one line of reasons.")

spec = LlmAgent(
    name="spec", model=STRONG, output_key="spec",
    instruction="Turn the issue {issue} into numbered requirements (R1, R2...) "
                "and name the test that will prove each one.")

implement = LlmAgent(
    name="implement", model=STRONG, output_key="patch",
    instruction="Implement {spec}. Previous test output, if any: {test_log?}. "
                "Never edit files under tests/ or ci/.")

build_loop = LoopAgent(
    name="build_loop", max_iterations=3,
    sub_agents=[implement, TestGate(name="test_gate", command=["pytest", "-q"])])

reviewers = ParallelAgent(name="reviewers", before_agent_callback=require_green, sub_agents=[
    LlmAgent(name="security_review", model=STRONG, output_key="security",
             instruction="Review {patch} against {spec} for security issues only."),
    LlmAgent(name="spec_review", model=FAST, output_key="coverage",
             instruction="For each requirement in {spec}, name the test in {patch} that proves it, or say MISSING."),
])

factory = SequentialAgent(name="factory", sub_agents=[triage, spec, build_loop, reviewers])

我们用 google-adk 2.11.0 对控制流进行了验证，用桩 Agent 代替模型调用。测试通过时会上报升级并在一轮后结束循环。测试失败时则按配置循环三次。

然后我们发现了那个

require_green

回调所针对的陷阱。没有它，一个

LoopAgent

耗尽预算后

max_iterations

只会直接结束，而父 Agent

SequentialAgent

会带着失败的测试继续进入评审阶段。我们还尝试在循环之后放置的自定义 Agent 中设置

end_invocation

。在 2.11.0 中，父 Agent 仍然会运行下一步，因为每个子 Agent 都会获得调用上下文（invocation context）的独立副本。一个

before_agent_callback

在下一阶段返回内容才是可靠跳过该阶段的方法。这个通用经验超越了这个框架本身：每一个有上限的循环都需要一条明确的超预算路径，而默认行为通常是不报错地继续执行。

关于 ADK 工具链还有两点。第一，

adk eval

使用诸如

tool_trajectory_avg_score

（要求工具调用序列完全匹配，默认阈值 1.0）和

response_match_score

（ROUGE-1 相似度，默认 0.8）等标准为评测集打分。它的效率指标

token_usage_v1

和

tool_call_count_v1

只做报告，从不判定通过或失败。精确轨迹匹配适合分诊 Agent，因为其工具序列应当是可预测的；但对实现 Agent 来说这是错误的门，因为它可以通过多种方式得到正确的补丁；在那里应使用基于评分标准的准则以及你的“从失败到通过”的重放测试套件。第二，

adk optimize

使用 GEPA 方法重写 Agent 的指令。这正是 Warp 用其观察者 Agent 所描述的那类自我改进，它应当与工厂的任何其他变更一样，纳入同样的模型升级资格认证流程。

一个实用的分工方式：把 Gemini CLI action 放在最前面做分诊和初审，实现工作交给 Jules 或你自己的 ADK 循环在沙箱中运行，把关机制保留在现有的 CI 和合并队列中，并将 ADK 编排器部署到 Cloud Run 或 Agent Engine，让回放套件在 CI 中针对每一次配置变更运行。

谁来运营工厂

已公开的工厂都由小团队运营：StrongDM 起初只有三个人，OpenAI 的 harness 项目从三名工程师增长到七名。角色比人数更重要：

• 工厂负责人。 一名平台工程师，负责 harness、沙箱、把关机制、预算和变更类别策略。工厂是一个有用户的产品，这个人就是它的产品负责人。
• 意图负责人。 编写规格说明和场景的产品工程师和 PM。编写 Agent 无法用错误方式满足的验收标准，如今已成为一项核心工程技能。
• 代码负责人。 通过 CODEOWNERS 为每个领域指定评审人。评审容量必须像其他容量一样进行规划。
• 可靠性。 发布策略、错误预算，以及当 Agent 变更失控时的事故处理流程。
• 安全。 Agent 身份、出站流量、工具策略，以及每个阶段的三重审计。
• 评测负责人。 负责回放套件、裁判校准和模型资格认证。起初通常由工厂负责人兼任，但当自动化三个或以上变更类别时，就应成为独立角色。

DORA 的 2025 年报告发现，90% 的组织已经在运行至少一个内部平台。工厂是这类团队的自然延伸，把它放在那里，比放在一个不负责 CI、部署或值班的独立“AI 团队”里要好。

价值不断增长的技能是：快速且带着怀疑态度地阅读 diff、编写无法被钻空子的规格说明和测试，以及当工厂开始产生新一类坏变更时，通过其追踪记录调试工厂本身。

从哪里开始：按优先级排列的用例

三个场景展示了同一个循环在不同输入下的表现。

四百个服务需要升级日志库。 分诊将其标记为可自动化，编排器按仓库分发任务，共享同一份规格说明。每次运行都有严格的预算和两轮 CI 上限。达到上限后仍失败的仓库进入人工处理列表，而不是无限重试——这正是 Spotify 早期脚本化迁移中提到的剩余 30% 问题。PR 收件箱将变更分组，让一位负责人可以批量审批。

凌晨 2 点的空指针告警。 监控 Agent 将其与未关闭的问题去重，附上堆栈跟踪和可疑部署的来源信息，并提交一个 issue。分诊在沙箱中复现该问题，实现 Agent 根据复现步骤编写修复和一个“先失败后通过”的测试，验证器重放失败的请求。人工在早上批准；金丝雀发布上线。如果可疑部署本身就是一个 Agent 的变更，监控器还会针对生成它的工厂配置提交一个 issue。

一位产品经理在 Slack 中请求 CSV 导出功能。 分诊将其标记为

ready-to-spec

。规格 Agent 编写需求：包含哪些列、一百万行数据时如何处理、谁有权导出。PM 批准。实现先在功能开关后上线，留存场景验证未授权用户无法获取任何内容，然后先对一位客户开启该开关。权限需求将此变更归入高影响类别，因此需要两位人工批准，无论该 Agent 在 CSV 代码上的过往记录如何。

需要防范的失败模式

• 篡改测试。 Agent 修改评分器。用所有权规则而非指令来防范。
• 看似合理但错误。 代码整洁，却解决了一个略有不同的问题。用每个需求的“先失败后通过”测试和留存场景来防范。
• 范围蔓延。 一个两行的修复变成了 600 行的重构。按变更类别对 diff 大小设门槛，并要求拆分。
• 橡皮图章式审查。 在高流量下，人类只会批准门槛已通过的内容。Spotify 曾将审查者比作监控自动化系统的飞行员。每周深度审计一个随机样本，并跟踪审查者发现问题的频率。
• 失控循环。 Agent 对一个偶发失败重试了 40 次。预算和上限应放在编排器中。
• 上下文腐化。 过时的文档会大规模地教给 Agent 错误的惯例。运行文档维护任务，并为文档标注日期。
• 单一文化。 同一个模型负责编写、验证和审查，因此它们共享同一套盲点。至少在一个门槛上使用不同的模型家族或确定性检查。
• 振荡。 监控器和修复器互相追逐。去重、限速，并为循环指定一位人工负责人。
• 虚构依赖。 使用允许列表，并要求新依赖包必须经人工批准。
• 静默退化。 模型或基础设施变更在没有报错的情况下降低了质量。在生产路径上持续运行金丝雀任务。

一个 90 天的搭建计划

不要从功能开发入手。第一个类别应该足够枯燥，使犯错代价低廉；同时足够频繁，使业绩记录能快速积累。

这对前沿部署工程师意味着什么

FDE 会在客户环境中构建这些工厂，而约束条件正是最有意思的部分：一个代码无法外传的 VPC、一份已批准模型清单、一个比 Agent 出现得更早的变更管理委员会，以及一个读过提示词注入资料的安全团队。本指南中的设计问题（选择哪些变更类别、设置哪些门禁、由谁审批、来源信息如何汇入客户的审计追踪）正是你会在会议室里被要求回答的问题。它们也正以系统设计题的形式出现在面试中：“设计一个让 Agent 根据生产告警修复 bug 的系统”或“你如何让 Agent 安全地向我们的 monorepo 提交 PR”。面试官会关注确定性的门禁、每个变更类别的自主程度、评分器的保护、上线与回滚，以及每个被接受变更的成本。请结合系统设计问题和 RAG 与 Agent 问题进行练习，面向 FDE 的 Harness Engineering 课程则会带你动手构建验证与闭环部分。

把它转化为 offer。练习与之对应的真实问题和概念：

常见问题

Agent 化软件工厂是一条让 AI Agent 把一项工作从需求推进到生产的流水线。分诊 Agent 判断工作是否就绪，规格 Agent 编写可检验的需求，实现 Agent 在沙箱中编写代码，独立的验证与评审 Agent 试图证明它有错，合并队列加上渐进式发布决定它是否上线。监控会把新 issue 反馈回这个闭环。人类负责表达意图、掌管门禁，并审批门禁无法判断的内容。

CI/CD 自动化了变更在人类编写之后的流程：构建、测试、部署。而工厂自动化的是变更本身的生产过程，因此它增加了 CI/CD 从来不需要的阶段：分诊、规格说明、沙箱化实现、对抗性验证、检查 Agent 是否削弱了测试、按变更类型设定的自主性规则，以及记录每次提交由哪个模型、提示词和技能版本生成的溯源信息。稀缺资源从编写代码转移到了验证和审查代码。

在大多数已公开的工厂中，是的。Stripe 要求每一条 Minion 拉取请求都由工程师审查，Spotify 报告审查已成为其瓶颈，Warp 则在规格和代码环节保留了人工检查点。StrongDM 是个例外：其规则规定没有任何人类编写或审查代码，而是依赖留出场景。我们的建议是按变更类别将审查设为可选，由过往记录来赢得这一资格，并且对身份验证、支付、数据迁移或工厂自身的门禁永远不设为可选。

给每条需求一个 ID 和一个测试，该测试在变更之前失败、变更之后通过，即 SWE-bench 使用的“先失败后通过”规则。保留一组实现 Agent 从未见过的留出场景。用变异测试衡量测试能否捕获缺陷。禁止 Agent 在同一次变更中编辑测试、CI 或门禁。对重要任务运行多次并跟踪 pass^k，即连续成功 k 次的概率，因为一个 90% 成功率的 Agent 连续成功八次的概率只有大约 43%。

衡量每个被接受变更的成本：token、沙箱计算、CI 分钟数、人工审查时间和回滚成本。已公开的数字差异很大。Warp 在 2026 年中期的一份仪表盘显示每条拉取请求约 58 美元，而 StrongDM 则指出，一个每天每位工程师花费不到 1,000 美元 token 的工厂仍有增长空间。最大的杠杆是提示词缓存（重发前缀可节省约 87%）、将廉价阶段路由到更便宜的模型、严格的重试上限，以及在分诊阶段拒绝未成熟的工作。

讨论 (6)

按变更类别设定自主性这一节是我希望更多平台团队最先阅读的部分。我见过的每一次工厂推广停滞，都是因为有人试图为整个代码库设定单一的自主性级别，而一旦第一条身份验证变更溜了过去，整个实验就宣告结束，包括那些一直运行良好的依赖升级。

是的，反过来也成立。按类别建立过往记录，可以让你在几周内将文档和 lint 修复提升为自动合并，而支付类则永远保持两次人工审批。没有人需要就“Agent 总体上是否可信”这一哲学问题争出胜负。

读者提问：如果一个团队本季度只能在常规 CI 之外增加一道门禁，应该选哪一道？

评测器的所有权。将测试、CI 配置以及工厂自身的设置纳入 CODEOWNERS，并排除 Agent；除非有人工签字确认，否则拒绝任何同时触及实现代码和评判该实现的测试的更改。这只需一个下午的成本，却能堵住 Agent 将红色构建“洗绿”的最廉价途径。

关于模型升级部分，我想补充一点：保留上一季度的重放结果。当新模型在成功率上得分相同，但其 diff 规模大了 40% 时，只有保留了旧的 diff 规模分布，你才会注意到这一点。审查负载的增加同样是一种退化。

ADK 的陷阱是真实存在的，而且其影响超出了 ADK 本身。任何设有最大迭代次数上限的循环都必须回答：当达到上限时会发生什么，而框架的默认行为通常是不报错地继续执行。请在编写正常路径之前，先编写超出预算时的处理路径。