这两周有句话在智能体圈流传得挺广：效果不行就换个更贵的模型。10 月中旬挂上 arXiv 的两篇论文，用受控实验把这句话拆开看了——很多被归到模型头上的失败，其实写在 harness 里。
两篇作者不同、方法不同、结论却指向同一处。ToolBottleneckBench（arXiv 2610.21098，10 月 15 日，四位作者）的做法是把合成企业任务固定住，每次只改一个变量：注册工具目录规模、可见工具菜单大小、认证工作流复杂度，或者工具返回记录的编码方式。然后用精确评分器记录每个失败回合停在哪个义务上，以及是被哪个 harness 上限终止的。
菜单变大，掉的不是准确率是输出
结论最硬的一条是：四种压力里，只有「可见工具菜单」这一项对模型产生大幅惩罚。把菜单从 8 个 schema 涨到 128 个，同一批 36 个任务族上的成功率下降 17.5 个百分点（95% 置信区间 −20.2 到 −14.9），36 个任务族里 34 个都掉了。而认证工作流从低复杂度升到高复杂度，合并效应只有 0.8 个百分点，检测不到；返回记录换四种编码方式，效应小且校正后不显著。
更关键的是这个惩罚从哪来。菜单 8 个时被输出上限截断的回合占 1.6%，涨到 128 个时是 13.6%；在这 411 个被截断的回合里，有 391 个是在模型发出任何工具调用之前就结束的。跨配置的相关性是强负相关。把每次请求的输出上限放大 16 倍后，六个重度截断配置的截断率全部降到 1.4% 以下，同一项菜单惩罚从 −43.7 个点收敛到 −2.7 个点。
换句话说，一个模型在 128 个工具面前表现下降，很可能不是不会选，而是话没说完就被切断了。论文还把失败落点做了完整统计：在 20408 次精确评分里，91.5% 的失败由 harness 上限终止，真正属于结论错误的只有 5.5%。全部 849 次「选择失败」都来自一次工具都没调用的回合，其中 838 次是被输出截断终止的——这个标签标的是评分器按顺序停在了哪一步，不等于模型在多个工具之间挑错了。
harness 本身是实验条件
另一篇 AlphaDiana（arXiv 2610.20675，10 月 14 日，十九位作者）走的是测量系统的路子。它给数据集、智能体、环境和评分器都留了模块化接口，同时保留 harness 原生的控制循环，把「文件是否复用」和「记忆是否保留」这两个变量单独拆出来控制。三个开源模型 × 三个开源 harness × 五个答案型基准，两个模型另加两个交互型基准。
它的结论比 ToolBottleneckBench 更扫兴：harness 并不一致地提升推理准确率。harness 在「模型自己解不出的题」上拿到的分，可能被它在「模型不用工具本来就能答对的题」上丢的分抵掉。组件层面的干预同样不稳——无论是技能指引还是保留历史，都没能可靠地提高准确率。
还有一条关于成本的提醒：输出 token 用得更少不等于更省。当准确率下降时，每次正确回答摊到的输出 token 反而会更多；而低 token 熵完全可以伴随着错误答案。这直接挑战了「跑得短就是省」的直觉。
真正管用的修复都不在提示词上
ToolBottleneckBench 试了四种修复，赢的两种都不是让模型更聪明。connector-first router 让工具先选连接器再在连接器内排序检索，结果在全部 21 个既有配置上都优于任何一次整体配置切换，因为没有任何模型或路由切换能修好 harness 内部的检索失败。public-handoff controller 则用确定性程序跟随公开的交接信息来发工具调用，模型亲自发出的调用平均只有 1.2 次（总共 29.9 次），成功率提升 96.6 个百分点，单次回合的平均 token 从 13 万降到 2.1 万。
作者特意强调了一句：这两种修复都没有改善模型行为本身。一个改的是「哪些工具能到达模型」，另一个改的是「谁发出调用」。反过来，两种提示词修复——工作流提示和接口说明——都没能通过激活检验。
对读者的实际含义
两篇论文合起来给出的是同一套纪律：报告智能体的效果时，必须同时写出它是在哪套 harness 预算下测出来的。没有预算口径的准确率数字，跨系统比较基本失去意义。这对正在做选型的人尤其要紧——同一个模型换个工具编排方式就可能差十几个点，而这十几个点在多数评测报告里根本不会被提及。
另一层含义是给「工具越多越好」这句话降温。可见菜单的成本不只在选错的概率上，还在它实打实占掉的上下文：菜单从 8 涨到 128，单次请求的平均 prompt 从约 1.6 万 token 涨到约 3.8 万。菜单压缩与工具检索不是优化项，它是预算项。
论文本身也有明确边界要说清：ToolBottleneckBench 用的是合成企业任务（会计、邮件、文件、日历四类，12 类意图），21 个配置里多数是当前旗舰模型加上固定预算的 harness 契约；截断结果只在重度截断的配置里成立，零截断配置的交互项分别只有 2.8 和 1.0 个百分点；论文团队自己也提醒，cap 检查只是若干诊断手段中的一种。AlphaDiana 则只用三个开源模型，结论不宜外推到闭源前沿模型。至于这些装配层结论能不能转化成具体的产品改进，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
换模型依然有用。但在那之前，先看看是不是菜单没压缩、预算没写对、或者输出被切了——按这两篇论文的经验，这条路径的性价比通常高得多。