Cockroach Labs 把编程 agent 组成「教学医院」跑了五个月：合并 1238 个 PR、只回滚 7 次，平均每个问题约 84 美元

为什么是医院

多数团队用编程 agent 的方式，是让一个 agent 从头写到尾，再由人来审。Cockroach Labs 的 Adam Storm 和 Rafi Shamim 在 10 月 9 日的文章《Five months treating bugs like patients》里描述了另一种做法：他们为数据库迁移工具 MOLT 搭了一条名为 MOLT Sinai 的流水线，按教学医院的分工来组织 agent。

每个 GitHub 问题是一个「病人」。「住院医」agent 负责诊断、写复现测试、起草治疗方案；另一个独立实例担任「主治」，专门挑方案和代码的毛病；「出院护士」在合并前核查审查有没有按规矩做；「值班护士」每 30 分钟把卡住的环节重新跑一遍；人类工程师是「主任」，做最终决定、立先例。规则包括先出方案再写代码、不许削弱测试、卡住时用结构化格式交接，超过 1000 行的问题必须拆小。各环节由问题标签触发 GitHub Actions 运行，模型用的是 Claude 系列，后期改为用 Fable 做规划、Sonnet 或 Opus 实现，必要时升级到 Fable。

五个月的账

实验从 4 月 21 日跑到 9 月 11 日：

• 合并 1238 个 PR，落地超过 100 万行代码，总共只回滚了 7 次；
• 1299 个问题里，近一半是 agent 自己发现并提出的；
• token 花费约 13.5 万美元，平均每个问题约 84 美元；
• 被驳回的方案不到 10%；问题一般在流水线里停留一到两天，大部分时间在等人审。

最醒目的是一次对比：给 MOLT 适配 IBM Db2 的冲刺不到两天完成，token 花费约 4172 美元；作者估算此前人工完成的 Oracle 适配用了约九个月、16 万美元，据此算出快 164 倍、便宜 38 倍。这是作者自己的估算，两项工作的范围并不完全相同。

没跑顺的地方

作者也写了失败：一个紧急的一行修复来回返工 11 轮、拖了两天；一个只改一个词的界面文案返工 5 轮，最后闹到「主任」那里；agent 有时试图在 CI 失败的情况下合并；负责提新任务的「研究部」把待办列表塞爆，只能限流；流水线自己的技能文件越写越冗余，审计发现约 23% 可以删掉。他们后来加了「熔断」：多轮返工仍不收敛时，审查方直接交给「主治」处理。

文章里最值得借鉴的结论是：在写代码之前审方案，抓住了一些代码审查大概率会漏掉的问题，比如一处可能把客户数据写进日志的改动；改动拆得够小，人才审得过来。作者的原话是，速度重要，但质量重要得多。