用弱模型来测 Agent Runtime

发布于：2026-11-02 1,112 字 4 分钟阅读

Factory 前几天发了一篇《Droid 1.0: Building a Frontier Harness》，讲他们怎么打磨自己的 Agent Runtime。文中有一句话我很认同：只针对一个模型调优，很难分清哪些是真正的进步，哪些只是在迁就这个模型的毛病。所以他们在很多个模型上一起测，只留下那些在不同模型上都成立的改进。

读到这里，我想到自己一直在用的一个做法。

平时大家说起 Claude Code，因为它是 Anthropic 开发的，很容易把它和 Claude 模型当成一回事。其实它里面完全可以接别的模型，Codex 也是一样。Claude Code、Codex 这类产品，包括我自己正在构建的东西，都属于 Agent Runtime。里面的模型可以随时更换；我们真正亲手搭的，是模型外围的运行系统，负责给提示词、定义工具、组织上下文，并一步步推进执行循环。

为了确认这套 Agent Runtime 本身足够扎实，我会先定一个评估标准，然后故意接一个比较弱的模型去跑任务。如果弱模型也能达到标准，我就认为这套 Agent Runtime 搭得不错了。

接着我会做 A/B Test，保持 Agent Runtime 不变，只把模型换成很强的那个。在同样的标准下，结果往往会好很多。

为什么偏偏要先用弱模型？

想把任务跑通，直接上手头最强的模型当然最省事。问题是，强模型会帮我掩盖 Agent Runtime 的缺陷。工具描述写得含糊，它能猜对；上下文给得乱，它也能自己理清楚。最后任务是完成了，但我很难分清是这套 Agent Runtime 真的扎实，还是模型在硬撑。

弱模型就没这个本事。哪里说得不清楚、哪里给的信息不够，它会直接失败。我顺着它卡住的地方往回找，看到的全是 Agent Runtime 里的漏洞。所以它更像一个测试，测的不是模型，而是我搭的这套 Agent Runtime。

这和 Factory 的思路其实是一回事：不让某一个模型的特点绑架自己的判断。区别只在于，他们是横向换不同家的模型，我是纵向换不同强度的模型。

不过这个做法也有个坑。为了让弱模型过关，人很容易往 Agent Runtime 里加一些拐杖：把任务拆得很碎、加很多检查、限制模型能做的事。这些安排对弱模型是帮助，对强模型却可能是天花板。强模型本来能自己判断的步骤，反而被过细的规则捆住了手脚。所以换上强模型以后，不只要看分数有没有变高，还要看哪些拐杖可以拿掉了。

好的 Agent Runtime 应该是这样的：本身足够扎实，对弱模型来说够用，对强模型来说不碍事。等模型继续变强的时候，它不用重写，只是跟着一起变强。

参考：Factory《Droid 1.0: Building a Frontier Harness》（2026-10-29）