10 月 9 日，Cockroach Labs 的两位工程师 Adam Storm 和 Rafi Shamim 发表了一篇复盘，记录他们用一条 coding agent 流水线维护数据库迁移工具 MOLT 的五个月。这条流水线叫 MOLT Sinai，按教学医院组织：issue 是病人，合并是出院，agent 分别扮演分诊护士、专科医师、主治医师和出院护士，人类工程师只在 agent 解决不了时作为「医疗主任」介入。4 月 21 日到 9 月 11 日，它合并了 1,238 个 PR，其中 7 个后来被回滚；只有 92 个 issue 升级到人类；Claude token 总花费约 13.5 万美元，平均每个 issue 约 84 美元。本文依次讲它的角色与流转机制、写进 skill 的几条规则、成本与产出，以及作者自己列出的几个问题。
这套系统值得细看的地方，是它把预算花在了哪里。
过去一年常见的 agent 编程实验大多以吞吐量为目标，原文举的例子是 Gas Town 并行跑大量 agent、再用合并层处理冲突，以及 Cursor 重写 SQLite 时变更量大到需要自建版本控制。Cockroach Labs 的问题不同：迁移工具里一个隐蔽的 bug 可能在数据进库的路上损坏用户数据，所以他们衡量的不是每小时产出多少 PR，而是「这些 PR 里有多少，我们自己合进去会觉得丢人」。作者明确表示宁可让 agent 慢 10 倍。结果是每个 issue 通常在流水线里停留一到两天，经过方案评审、代码审查、出院审计三道 agent 关口，同期出院 1,322 个 issue，升级到人类的只有 92 个，1,238 个 PR 的回滚率约为 0.6%。
这组数字说明，agent 的可靠性主要来自流程的结构，而不是模型单次输出的质量。花在关口上的钱和时间是这套系统的主要成本，也是它能把人工介入压到 7% 左右的原因。
五个角色与 label 驱动的流转
整条流水线跑在 GitHub Actions 上。病人的状态存在 issue 的 label 里：每个阶段是一个 workflow，在对应的 label 落到 issue 上时启动，加载该角色的 prompt，干完活后在病历文件里追加一条结构化记录，再打上下一个阶段的 label。记录里带有 <!-- SINAI:TREATMENT_PLAN --> 这样的标记，方便后面的 agent 定位和解析。被打回的工作沿虚线返回：方案被拒退回 workup，CI 失败或审查要求修改退回实施，卡住的阶段升级给医疗主任。
主流程上有五个角色。分诊护士判断 issue 的严重程度和复杂度，决定收治还是退回；专科医师（原文为 Fellow）先做 workup，复现问题、阅读代码、写治疗方案，方案通过后再写代码；主治医师（Review Attending）是另一个 agent 实例，prompt 的目标是找错而不是修复，先审方案，再审代码；出院护士在合并前检查流程是否走完；医疗主任是人类。主流程之外还有四个按自己节奏运行的部门：护士长每 30 分钟巡房一次，重跑卡住的阶段；感染控制科在主分支挂掉时锁住全部 workflow；安全部门每周写流程复盘；研究部门主动提新需求。
作者选医院做模型的理由很具体：医院长期管理能力参差的人员完成高风险工作，有强制交接、强制第二意见，也有大量关于交接出错后果的研究。LLM 对这套体系非常熟悉，这一点后面会再讲到。
写进 skill 的六条规则
作者说，系统的大部分安全性来自几条写进 skill 的规则：
| 规则 | 具体要求 |
|---|---|
| 先有方案，方案先审 | 动代码前必须复现问题、做鉴别诊断、写出包含诊断、改动文件、新增测试、风险和未决问题的方案，主治医师批准后才能实施 |
| 不准即兴发挥 | 实施中范围变了，停下来重写方案，回到方案评审。skill 里这条规则只有两个词：Don't improvise |
| 测试不走捷径 | 不得禁用、跳过、削弱或修改测试来让它通过。测试失败时默认测试是对的；确实要改测试，必须单独提交、单独审查。每次代码审查先撤掉改动，确认新测试全部失败 |
| 卡住了不硬撑 | 写一份 I-PASS 交接（病情严重度、病人摘要、待办、情况意识、综合判断）升级给主治医师，接手的 agent 先复述它理解的内容再开工 |
| 出院护士审计审查者 | 合并前最后一道关口不重审代码，只核对流程：有批准、审查模板已填、没有未解决的讨论、CI 为绿、提交历史干净。任一项不满足，出院失败并标出原因 |
| 找主任前先查先例 | 人类做出的可推广决定写进只追加的先例日志。agent 升级前必须先查日志，有适用先例就照办并引用，只有人类能创建先例 |
其中最后两条针对的是 agent 系统里容易被忽略的一层。出院护士这条规则存在的理由，原文写得很直接：把控制权交给 agent 时，需要确认它们在照指令做事，而它们有时并没有。先例日志则把人类的每一次裁决变成可复用的规则，五个月下来，agent 升级给人类的次数降了下来。
I-PASS 是医院真实使用的交接格式，原文引用的研究显示，医护人员用标准格式交接病人信息后，交班期间的不良事件减少了 50%。
1,238 个 PR 与 13.5 万美元
为了验证这套模型，他们先在 MOLT 仓库的一个镜像里运行。4 月 21 日到 9 月 11 日的数据如下：
| 指标 | 数值 |
|---|---|
| 合并的 PR | 1,238 |
| 出院的 issue | 1,322 |
| agent 提给其他 agent 处理的 issue | 1,299 |
| 合并后被回滚的 PR | 7 |
| 升级到人类主任的 issue | 92 |
| PR 新增行数中位数 | 527 |
五个月里合进去的代码超过 100 万行。1,299 这个数字说明流水线会自己产生工作：拆分出的子 issue、方案里划出范围的后续工作、研究部门的提案、安全部门的整改项。仓库里将近一半的 issue 是 agent 提的，从第二个月起，人类就不再是主要的需求来源，只负责决定收治哪些。
成本方面，Claude token 总计约 13.5 万美元，平均每个 issue 约 84 美元。前面提到的一到两天停留时间里，大部分花在等人类审查上。模型配置随版本演进：起初所有阶段都用 Opus，Fable 推出后改为用 Fable 做方案，再由方案决定实施阶段用哪个模型；Sonnet 或 Opus 实施不顺时，可以升级到 Fable。原文的成本图里出现过 Opus 4.6 到 Opus 5、Fable 5 与 5.1、Sonnet 5 等多个型号。每次换模型都要调一轮 skill 来压成本，他们大约每两周做一次优化，UI 类任务因为要处理截图，单价更高。
文章开头的案例是 IBM Db2 支持。需求从一个 issue 开始，规划 agent 判断它太大，拆成 15 个带依赖关系的子 issue，其中 2 个在 workup 时又被拆了一次，实施过程中 agent 还给自己的工作补提了十来个 issue。最终开了 32 个子 issue，合并 27 个 PR，审查打回 55 次，升级 9 次，其中 2 次到人类。从周三晚上到周五下午，不到两天，没有一行代码由人编写，token 花费 4,172 美元。作者拿 2024 年人工做 Oracle 支持对比：9 个月，工程成本约 16 万美元，并据此给出「快 164 倍、便宜 38 倍」。
这组对比需要谨慎看待。Db2 一侧只算了 token，没有计入人的时间；Oracle 一侧是两年前的人工成本。更关键的是，Db2 是流水线自主运行第一周的产物，那段时间人类没有审查任何代码，作者在文末写明，他们仍在确认 Db2 支持的正确性。第一周之后，他们打开了「人类批准模式」，每次合并都要有人看过，之后才用它开发要交付给客户的 Migration Assistant。也就是说，1,238 个 PR 的数据里，大部分是在有人类最终签字的前提下取得的。
方案评审、拆分上限与病历：起作用的几个设计
角色设定的效果超出预期。 每个角色的 skill 开头只有几句身份描述，作者认为这几句最有价值。主治医师的开头是：你是与治疗这个病例的专科医师不同的 agent 实例，你的工作是找出 bug、安全问题、回归风险和对已批准方案的偏离。LLM 知道教学医院怎么运作、鉴别诊断是什么、第二意见意味着什么，一个 persona 就带进了整套职业规范。原文举了一个例子：一个已经审了好几轮的 PR 上有一处 docstring 问题，主治医师没有自行把它打回，而是写道，「在病人已经精疲力竭的情况下」，它把问题提交给主任裁决。这句话不在任何 skill 文件里，是 agent 入戏之后自己写出来的。
方案评审是收益最高的一道审查。 方案被拒的比例不到 10%，但每次被拒，返工都发生在最便宜的阶段。一个遥测修复的目标是从日志里去掉客户的主机名和数据库名，方案评审发现还有一处遗漏会泄露这些信息。作者判断，这个问题到代码审查阶段大概率发现不了。
单个改动的硬上限是 1,000 行。 workup 估计改动超过 1,000 行（含测试），就必须拆成带依赖图的子 issue，子 issue 超了再拆。上限的目的是让审查者，无论是 agent 还是人，能把整个改动装进脑子里。Db2 的 32 个子 issue 就是这条规则的产物。
病历完整。 每个 issue 留下全部过程产物：workup 方案、动代码前写的复现测试及其失败记录、方案的每一版、每次 I-PASS 交接、每个带理由的审查结论，以及每个阶段的模型、token、耗时和成本。这些记录放在一个随代码一起合并的归档分支里，PR 的 diff 只保留代码。五个月后，任何一个 PR 为什么被合并，都能从 issue 里还原出来，安全部门的每周复盘也依赖这份记录。
这套流水线后来还维护了它自己。Sinai 框架被拆成独立仓库后，约 1,570 个提交里有约 1,340 个（85%）由流水线写成。护士长每 30 分钟巡房的机制，就来自一个 agent 遇到 GitHub Actions label 事件的竞态问题、提了 issue，另一个 agent 设计并实现了修复。目前 Cockroach Labs 有四个仓库在用这套模型。
一行修复返工 11 轮：作者列出的四个问题
原文用了不少篇幅讲问题，这部分和成果同样有参考价值。
角色入戏也带来了官僚化。 一个 issue 的方案只有一句「按重复关闭，#691 已经修了」，方案评审确认无误，却仍然升级给人类，理由是评审协议只定义了 APPROVE、REJECT、ESCALATE 三种结果，没有「按重复关闭」。一处界面文案从 Validating 改成 Verifying，返工五轮，最后闹到主任那里，争议点是低风险 PR 能不能在一个不稳定的 CI 变绿前合并（agent 经常在 CI 为红时尝试合并，理由是失败不是自己造成的）。还有代码审查因为 PR 描述里的一个小笔误拦下一个没有代码缺陷的 PR，审查者留下的非阻塞意见被流水线开成新 issue。部分问题已经修复，作者认为剩下的是一个严格执行规则、把质量放在第一位的系统必须付出的代价。
审查循环缺少熔断。 issue 1777 被标记为紧急，修复只有一行：在一条代码路径里调用一个已有函数，另外三条同级路径已经这么做了。它前后返工 11 轮，耗时两天，依次卡在注释规范、PR 描述里的一处不实陈述、与原方案的细微偏离、测试质量、两次 rebase、两次 workflow 失败和人类批准。返工超过三轮的 issue 会进入安全复盘，在一个复盘周期内，三个复杂 issue 分别返工 9 轮、9 轮和 7 轮，花掉了约 631 美元，而这个周期的总花费是 1,046 美元。安全部门的结论是，代码审查没有「可计数的不收敛熔断」，不收敛的循环要么很晚才升级，要么永远不升级。他们最近合入了修复：一个 PR 连续 4 轮返工都出现新的阻塞问题，或者实质性返工累计 6 轮，审查者必须交给主治医师。规则刚上线，作者说还没有足够数据证明效果。
研究部门太能找活。 它最初每 3 小时扫一次代码库，提出的 issue 多到人类来不及审核是否收治，后来降到每天一次，并把待收治的提案上限设为 10 个。难处在于这些 issue 大多是有价值的，作者在交互式 Claude 会话里排查问题时，经常发现流水线几周甚至几个月前就提过一模一样的 issue。全部处理又太贵，怎么从中挑出值得做的，他们还没有答案。
它不培养人。 两位作者合计有 40 多年行业经验，这套系统正是为日程排满的资深工程师设计的：晚上把 issue 交给流水线，早上审完合并，白天开会的同时再塞一批，一整天的会议可以换来 10 个高质量的 PR。但刚毕业的工程师需要的是学会做判断，这套系统给不了。他们正在增加新模式：让人类自己写方案、接受 agent 评审并为方案辩护，或者拿着评审通过的方案自己写代码。
skill 文件的 23% 冗余
每个角色由一个 skill 文件定义，内容是流程、规则、模板和禁止事项。这些文件的写法和很多知识库一样：每出一次问题，就加一条规则。
7 月他们做了一次审计。25 个 skill 文件，总计 10 万多个英文单词，其中约 2.3 万个（23%）可以删掉，而不改变任何一道关口、命令、模板或标记。最主要的问题是同一条规则在多处重复，70 处发现共涉及约 6,000 词，有一个文件的冗余率达到 47%。
这些冗余直接计入账单。出院护士每次运行要先加载约 21,800 词的指令，约合 29,000 token，然后才开始读它要检查的 PR；基础的医院协议 skill 被全部 15 个 agent 加载，那里的冗余代价最大。作者的总结是，prompt 像代码一样腐化：规则只加不删，直到文件长到没人能从头读完。他们是从 token 账单上发现这个问题的，目前还没有针对它的 linter。
对自建 harness 的参考
这篇复盘的价值在于数据和问题都给得很完整。按场景看，可以直接借鉴的部分如下：
| 场景 | 可以借鉴的做法 |
|---|---|
| 已经在用 agent 改生产代码 | 加一道代码之前的方案评审，评审者用独立实例和「找错」的 prompt |
| 多 agent 串行协作 | 交接用固定格式，并要求接手方先复述理解 |
| 人类经常被同类问题打断 | 建先例日志，只允许人类写入，agent 升级前必须先查 |
| 审查和修复会来回拉锯 | 给返工轮数设硬上限，超过就换人或升级，规则要可计数 |
| skill 和 prompt 越写越长 | 定期审计重复规则，按每次运行的加载量算成本 |
| 需要事后追责或复盘 | 把方案、交接、审查结论和每阶段成本写进与代码分开的记录 |
需要注意的是，这套系统的成本结构是为数据库迁移这种「错一次代价很大」的场景设计的。平均每个 issue 84 美元、一到两天的周期、三道审查关口，对一个写内部脚本或做原型的团队来说并不划算。它真正可以迁移的是两条原则：审查要放在写代码之前，审查流程本身也要被审查。
原文：Adam Storm、Rafi Shamim，Five months treating bugs like patients and coding agents like a medical team，Cockroach Labs Blog，2026-10-09。本文为解读，数据均引自原文。
关于 harness 设计的更多整理，可以看 harness-engineering-practice。