Cockroach Labs：五个月把 bug 当病人、把编码智能体当医疗团队

四月的一个周三傍晚到周五下午，Cockroach Labs 用来把数据库迁移到 CockroachDB 的工具 MOLT，获得了从 IBM Db2 迁移的能力。Db2 是最早的商用关系型数据库之一，SQL 方言丰富，类型系统复杂，还有原生的线路协议。要在 MOLT 中支持它，需要一个新的模式转换器、一条新的 Fetch 路径（把数据行取出并装入 CockroachDB）、一条新的 Verify 路径（装载后比对数据）、一份内置的 ANTLR 语法、一个供 CI 使用的 Docker 镜像，外加一万多行测试夹具。2024 年为 MOLT 增加 Oracle 支持时，同等工作耗时 9 个月，约花费 16 万美元的工程成本。这一次的 Db2 不到两天完成，没有任何人手写一行代码，token 账单是 4172 美元：速度快了 164 倍，成本低了 38 倍。

这个结果的起点只是一个 GitHub issue，里面描述了需求。随后，一个规划智能体读完它，判断任务太大，不能一次处理，于是把它拆成十五个子 issue，并画出明确的依赖图：先打地基，再做类型系统，然后是行迭代器，接着是 Fetch、Verify、Convert，最后是 CI 和测试数据。其中两个子 issue 在各自的工作评估里又被判定为过大，于是被再次拆分。在推进过程中，智能体还针对自己的工作另外提交了约十几个 issue，内容包括测试夹具的缺口、一个类型映射的缺陷，以及一处隔离级别的修复。值得注意的是，这些问题不是人发现的，而是流水线自己发现、自己登记、自己排进队列的。把工作拆开并让依赖显式化，是这套系统能够在两天内完成大块头任务的第一个关键。

Cockroach Labs 为这条流水线选了一个有意思的组织隐喻：教学医院。每个 bug 被当作一位病人，每个编码智能体则是医疗团队中的一个角色。分诊护士负责接收和初筛，判断问题是什么、有多大、该交给谁；住院医师（Fellow）负责动手治疗，也就是写出修复；复核主治医师（Review Attending）负责严格评审，把关质量；出院护士负责收尾，确保合并前的各项检查和记录都已完成。这个比喻的价值不在于可爱，而在于它把软件工程里本来就存在、但常被省略的分工与制衡，用一套人人熟悉的医疗流程重新固定下来。写代码的人不能自己批准自己的代码，这一点在医院里是常识，在智能体流水线里却需要刻意设计。 更重要的是几条硬性纪律。第一，写代码之前必须先做计划，并且计划本身要经过评审，也就是在花费 token 生成大量代码之前，先让错误的方向被拦下来。第二，严格的测试覆盖是合并的前提，而不是事后补充。第三，要有细致的记录，每个决定、每次修改都留下痕迹，这既是医疗病历的做法，也是事后追查回退原因的唯一依据。第四，在合并之前设有安全护栏。这些规则看上去朴素，但它们恰好针对的是智能体最容易出问题的地方：目标理解偏差、过度自信、以及没有人对产出负责。 衡量这套流水线是否可靠，最有说服力的是回退次数。在五个月里，这条流水线处理了超过一百万行代码，只发生了 7 次回退。这个数字说明，自主产出和企业级的可靠性并不必然冲突，前提是把可靠性当作系统结构的一部分，而不是寄希望于单个模型足够聪明。同样的机制也支撑了 Migration Assistant 这类功能：当复杂的数据库迁移要由智能体来构建和维护时，规划评审、测试覆盖和完整记录，就是避免昂贵回归的主要手段。需要说明的是，原文给出的是 Cockroach Labs 自己的经验数字，Oracle 九个月与 16 万美元的对比也是公司自己的估算，读者应把它们看作一个有力的案例，而不是普遍适用的基准。

从成本结构看，这个案例还有一层容易被忽略的含义。Oracle 项目的 16 万美元是工程时间，Db2 项目的 4172 美元是 token 账单，两者的计价单位不同，但都指向同一件事：当代码的生产成本大幅下降，真正昂贵的东西就变成了判断。哪些需求值得做，任务该怎么拆，哪个结果可以放行，这些判断仍然需要被明确地写下来并交给有权限的角色。教学医院的比喻之所以有效，正是因为医院早已习惯在高风险环境中，把判断权分配给不同的人，并要求每一步都有记录可查。软件团队过去靠个人经验和口头默契完成的事，现在必须变成流程，因为执行者已经换成了不会疲劳、也不会主动提出疑问的智能体。把隐性的工程常识显式化，也许是这类系统带给团队的最大副产品。

对于行业而言，这篇文章的意义在于换了一个问题。过去人们常问：哪个模型写代码最强？这个案例提示我们，更有价值的问题是：如何组织一群智能体，让它们像医疗团队那样分工、互审、留痕，并在出错时有明确的责任链？当成本从九个月降到两天、从十六万美元降到四千多美元，瓶颈就从编码本身转移到了需求描述、任务拆解和验收这些环节。团队如果想复制这样的结果，应当先投资于拆解能力、评审流程和测试基础设施，而不是只追逐更强的模型。