编程Agent评测转向：框架质量比模型选择更影响结果

本月的开发工具报道中有一件小事，比那些大模型发布更能说明问题：影响编码 Agent 排名的因素，已经悄悄地从模型本身变成了 Agent 的 Harness（构建框架）。CellCog 八月评级中，Claude Code 因深度 hooks、子 Agent 和动态工作流能力位居第一。Codex CLI 因云端能力、PR 形态的自主性被点名。Cursor 则在编辑器内流程上领先。注意这里评分的是什么——不是"谁的模型最聪明"，而是"谁在模型周围搭建的脚手架最好"。

我前几周写过，我想找个理由换掉手上的编码 Agent，结果找不到，因为各模型已经趋同，而我的个人配置对结果的影响比模型本身还大。这些排名就是这个论点的行业共识版本。

我找了一圈，没有找到换 Agent 的理由

"Harness 排名"实际上在衡量什么

看看那些评分维度，全都是 Harness 属性，而非模型属性。Hooks：工具能否在恰当的时机自动运行你的测试、linter、各种检查？子 Agent：它能否启动带有独立指令的局部辅助单元——以及像 Claude Code 现在这样——每个子 Agent 还能用各自的模型？动态工作流：面对一个长任务，它能否进行规划、分支和恢复，而不是一次性搞定？Effort 控制：面对需要深度推理的步骤能否调高算力，面对简单步骤能否降下来？

这些没有一条是"模型本身"。全是你在模型外围搭建的那套机器，而这恰恰是决定一个 Agent 能否在真实代码库里存活下来的关键因素。对这些特性打分，等于公开承认：模型已成商品，Harness 才是差异所在。同一份基础模型，放进不同的脚手架，表现就像完全不同的产品——这就是为什么一个工具能登顶，另一个却让你沮丧，哪怕底层权重完全相同。

Opus 5 的细节印证了这一点

这篇评测里最有说服力的特性不是跑分，而是子 Agent 级模型控制：在一个任务内部，为不同子 Agent 分配不同模型的能力。机械性步骤用便宜快速的模型，需要判断力的步骤用昂贵但谨慎的模型，全部在同一轮运行内完成。

这是路由能力，built 进 Harness 内部，而且这正是我从各个方向反复碰到的同一个思路——我在本地测试过的 escalation router、Switchyard proxy、"默认用小模型，按需切大模型"。当你的编码 Agent 支持按子 Agent 分配模型时，工具本身已经把路由层吸收进去了。Harness 不再只是模型的"外围"，而是在编排多个模型，在它们之间做选择现在成了你拥有的配置权。这和"选最好的模型"是两码事，而且这才是真正能移动你结果的活儿。

如果我来用这个思路

别再挑最好的模型了，开始投资你的 Harness，因为排名已经在悄悄告诉你该这么做。具体来说，不管你用哪个 Agent：把测试/lint hooks 接好，让验证自动化；去学习子 Agent 和 effort 控制，别停留在默认配置；把你的项目规范写下来，让 Agent 能读到。这四件事对本季度任何一个模型切换决定的帮助都大。

然后用排名本来的意图来读 Harness 排名：不是"哪个工具最好"，而是"哪些能力重要"——hooks、子 Agent、路由、恢复。然后确认你真的在用自己工具已有的那些特性。大多数人把被排名的功能全扔在默认关闭状态。

哪个 Harness 特性在你真正开启之后，对你的结果改变最大？我在收集这类案例，因为工具默认配置与其配置潜力之间的差距，是这个领域里最少被讨论的数字。