Claude 负责写,Gemini 负责评审,ChatGPT 负责当传声筒

单一供应商的 AI 在纸面上看起来更简单,在实践中却会交付脆弱性。RakuAI 由一个多供应商的智能体循环构建——而且被构建成能被任何供应商的模型驱动。开发流程映照着产品论点本身。

周六早上,咖啡,以及在它再次改变之前的这套工作流。当我告诉别人我正在和自主编码智能体一起构建一个引擎时,第一个问题总是”用的是哪个智能体”。诚实的答案是”好几个,各自扮演不同的角色,而分工本身很重要”。这篇文章就是那个更长的答案。

眼下这套开发工作流里,至少有三家不同的 AI 供应商,在这个循环里扮演着不同的角色。原因不是忠诚度或者挑剔,而是每个模型在不同形状的工作上确实表现更好,而试图让一个模型什么都做,产出的代码质量会明显更差。

今天的这些角色

Claude 编写大部分运行时代码。 跨越大型代码库的长上下文推理,在编辑之前先做规划,在一个”脑子”里保持大量状态。这是我用来处理 issue 队列上实质性子系统工作的模型。当一个 issue 写着”实现一个 OpenXR 合成图层管理器和动作空间”时,落地这个 PR 的就是 Claude。

Gemini 评审大部分 PR。 不同的训练,不同的盲点。当 Claude 落地一个 PR 时,Gemini 会读这份 diff 并提出反对意见。Gemini 提出的那类评论,和我自己手动会提出的那类不一样。有些是噪音,有些很有用。信噪比足够好,让我信任把 Gemini 作为每份 diff 的第一道评审关卡。

ChatGPT 是我用来当传声筒的地方。 当我在某个架构决策上卡住、还不知道该往哪个方向走时,我会对着 ChatGPT 把想法大声说出来。在这个角色里,这个模型不写代码。它会逼我审视自己的假设,提出三种不同的框架,让我能和它争论。这是一个资深同侪本该扮演的角色,而我目前没有这样一个人。ChatGPT 是这个角色的模拟。

Copilot 待在编辑器里。 这是自动补全的角色。当我手动写代码时(这比人们想象的要少,但确实会发生),Copilot 是我在 IDE 里看到建议的那个模型。它擅长局部上下文、”接下来四行”这类工作。

这就是这套工作流。四个模型,四种角色。每一个在自己的角色上,都比其他模型在这个角色上做得更好。

为什么多供应商很重要

三个原因。

每家供应商的能力天花板不一样。 如果我用一个模型来扮演所有角色,这个模型的每一个弱点都会体现为开发流程中的一个弱点。Claude 擅长编写,但不太擅长在自己写的东西里找 bug。Gemini 擅长找 bug,但我不会放心让它在无人监督的情况下规划一次重构。ChatGPT 在开放式的架构问题上思考得很好,但它在真实子系统里写出的代码不是我想要交付的。每一个都是某个位置上最好的工具。

评审中的独立性是结构性的。 我落地的最重要的一条规则是,写一个 PR 的模型不能是评审这个 PR 的模型。自我评审不是评审。让一个不同供应商的模型来做第一道评审,能带来架构上、训练数据上、失败模式上的独立性。Gemini 在 Claude 代码里抓到的 bug,都是那种不这样做就会真的落地的真实 bug。

不被锁定在单一供应商上。 这个引擎被构建成能接受任何云端 LLM 的指挥(上个月的 XRAssistantService 相关工作里提到过)。构建这个引擎的开发工作流,应该与这种姿态相匹配。我不希望这个运行时的工程建设,依赖于某一家供应商在接下来五年里保持领先。没有哪一家会一直领先。现在表现好的那些,以后会以不同的方式表现好。在开发层运行一套多供应商的工作流,能让这项工程建设保持可移植性。

诚实地说说代价

有几项。

协调开销是真实存在的。 在任务进行中途切换供应商,会带来认知开销。解决办法是把每个任务保持在一个供应商的赛道内,让交接发生在任务之间,而不是任务内部。

账单会累积起来。 同时维持四个模型的订阅并不是免费的。这笔成本是实实在在的,目前由我个人承担。它带来的回报,可以用已交付的子系统来衡量,所以在现阶段这笔账是算得过来的。但这不会永远成立。

供应商之间的质量漂移是一个真实的问题。 当 Gemini 在 Claude 一直在做的某类任务上变得更好时,正确的做法是把那类任务转移给 Gemini。错误的做法是因为工作流文档上写的是老办法,就继续用老办法。工作流文档必须每隔几周就修订一次,因为模型的格局在这套工作流之下不断变化。

各家供应商互相之间并不知道对方的存在。 当 Claude 写了一段将由 Gemini 来评审的代码时,Claude 并不知道这件事。当 ChatGPT 和我争论一个架构决策时,Claude 最终的实现也看不到那场争论。这些供应商之间的整合,存在于我的脑子里。这是一个脆弱的地方,让整合寄居在这里,如果我要构建基础设施来帮助别人运行这套工作流,这正是我想要修复的事情之一。

那运行时那一侧呢?

这正是开发工作流的故事和引擎本身的故事汇合的地方。

两周前落地到运行时里的 XRAssistantService,在设计上就是模型无关的。原因和这套开发工作流采用多供应商的原因完全一样。这个接口的构建方式,让这些实验室里任何一家的模型都能通过这个运行时驱动一个 AR 体验。在任何给定任务上表现最好的那家实验室的模型,就能在任何给定体验中提供那项任务的意图。

这是一个更宏大的赌注:”这个产品建立在某家供应商的这个模型上”的时代很短暂。我们正在进入的时代是”这个产品围绕着模型形状的能力来构建,而在任何给定时刻哪个具体模型来填补哪个能力槽位,是一个配置选择”。引擎必须为此做好准备。构建这个引擎的开发工作流,也应该体现这一点。

我希望构建者和实验室从中得到什么

如果你是一家编码智能体供应商,并且正在读这篇文章,我认为该优化的指标是”这个智能体的 PR,在一个竞争供应商的智能体评审下能存活下来的频率有多高”。自我一致性不是标准,跨厂商评审下的存活率才是标准。在这个指标上表现好的智能体,才会是那些被用于认真工作的智能体。

如果你是一名开发者,正在考虑为一个认真的代码库采用 AI 辅助的工作流,不要只选一个模型然后止步于此。选一个来写代码,选一个不同的来评审,再用第三个来为开放式的架构决策当传声筒。这个成本溢价是真实的,而质量差异更大。

如果你是一名企业领导者,正在考虑在你的开发组织里引入 AI,多供应商这个模式才是能够规模化的那种。单一供应商的采用方案在纸面上看起来更简单。在实践中它会产生脆弱性,既有技术层面的,也有战略层面的。

安静的周六。引擎这个周末收获了三十五次提交。这些提交中的大多数,六个月后都会变得看不见。但产出它们的这套工作流不会。