深夜卡住的工程现场

发布前一夜，你把一个搁置三个月的旧代码库问题交给账户里最贵的云端模型。它读代码、改代码、跑测试、撞上错误、再试、再撞。到第9轮，它悄悄把自己的修改退回第3轮的样子；到第14轮，又漂回去了。模型卡住了，账单没有。

打开网易新闻 查看精彩图片

这不是偶发故障。AI编程一旦从演示进入日常使用，这类情况会反复出现。根据我们自己的失败数据，大量智能体任务失败并不是模型缺少能力，而是模型在无人干预时陷入循环：围着同一个思路打转、重复同一个动作、上下文溢出，最后超时。

单模型走不通，多模型未必

从6月起，行业里几个部分各自得出了大致相同的结论。OpenRouter推出Fusion，让多个模型分别回答后再合并成一个输出；Hermes把多智能体混合做成一等公民功能；Cursor用超过一千个智能体重写了整个SQLite。

一个模型走进死胡同，不代表几个模型也会。但随之而来的问题是：给模型“组队”，是不是意味着要架起GPU集群、烧掉一大笔令牌费用？

27B阵容对阵1.6万亿参数旗舰

过去六个月，我们测试了一个有些反直觉的答案，并把它做成产品：Fusion-MOA。它跑在一台GPU服务器上，由一个27B开源模型牵头，只在需要时拉入几个同级模型。结果在真实终端工程任务上达到50%通过率，领先一个2950亿参数的云端旗舰，并比一个1.6万亿参数的巨无霸高出15个百分点。

令牌消耗呢？只是它们的一小部分。

“选最强模型”从来不是稳妥策略

哈佛商学院和BCG的一项联合研究提出了一个广为人知的词：锯齿前沿。意思是模型能力不是一条平滑曲线，而是布满突然高峰和低谷的不规则地形。同一个模型可能在一个问题上表现出色，在下一个问题上连实习生都不如。

真实工程工作中，这种不均衡很明显：有些模型擅长读懂遗留代码字里行间的真实意图；有些模型擅长顺着满屏错误日志追根因；有些模型擅长推理一个修复会不会弄坏下游其他部分。真正解决一个问题，往往需要同时具备这三种能力。

指望单个模型样样精通，就像指望一个工程师同时是公司最好的架构师、最好的调试员和最好的测试员。