增加更多工具后，你的智能体“不知道”率为何反而下降了

你添加了搜索工具，接着是日历工具，然后是 CRM 工具，接着是四个数据库封装器（wrappers）和一个计算器。仪表盘的变化正如你所愿：任务完成率上升，延迟保持稳定，“我不知道”率从 14% 下降到 4%。这看起来像是能力的提升。事实并非如此。规划器并没有学到更多知识；它只是学会了减少拒答（abstention）。现在每个问题看起来都是可以回答的，因为总有 某个 工具的模式能与查询充分匹配并被调用。你消除的那 10 个百分点的“我不知道”并没有转化为正确的答案 —— 它们变成了自信的错误答案，分布在无人仔细评审的长尾场景中。

这就是工具表面扩展带来的“伪能力陷阱”（false-competence trap）。这是团队在庆祝改进时，发布了性能退化（regression）最常见的方式。评估准则衡量的是 Agent 是否尝试了任务并产生了一个形状合理的答案；它并不衡量 Agent 是否应该拒绝回答。拒答并非没有成本，但它是目前能获得的最廉价的正确行为，而一旦你的工具集变得足够大，以至于总有 某个 工具会被触发，你就再也看不见这种行为了。

这种机制并不神秘，而且现在已经有了充分的文档记录。更大的工具集会稀释规划器对更多候选工具的注意力。语义相似的工具会变得模糊不清。而推理调优模型（reasoning-tuned models）—— 也就是你上季度升级的那些 —— 结果证明是放大而不是抑制了工具幻觉（tool hallucination），因为思维链（chain-of-thought）会将任何看起来合理的调用合理化为一个自信的调用。你的“我不知道”率下降并不是因为 Agent 变得更聪明了。它下降是因为 Agent 变得更愿意猜测，而你给了它更多可以猜测的形状。

你真正衡量的是什么

拒答率本身是一个无用的数字。它是一个比例，其分母在你每次添加工具时都会默默扩大。一个以前因为没有工具匹配而返回“我无法提供帮助”的查询，现在会向清单中名称看起来最接近的那个条目发起工具调用。Agent 并没有开始正确处理查询；Agent 只是开始处理它了。处理是否正确是你“任务完成率”指标几乎肯定没有涉及的问题，因为任务完成率通常评分的标准是是否产生了 任何 答案以及该答案是否符合解析要求，而不是拒绝回答是否才是正确的结果。

由此产生了三个陷阱：

• “已回答”桶在增长，而你没有衡量新加入的条目是否正确。
• “已拒答”桶在缩小，而你无法判断失去的拒答是 正确地 失去了（新工具确实解决了一个以前无法解决的查询），还是 错误地 失去了（新工具给了规划器伪造答案的许可）。
• 在工具扩展之前编写的评估套件没有预料到规划器现在会尝试它以前跳过的类别 —— 因此，触发新失败模式的案例并不在测试集中。

重要的数字不是拒答率。而是 在查询不可回答的情况下的 拒答率。如果你不能构建一个你确信 Agent 应该拒绝的预留查询切片，你就没有拒答指标。你只有一个伪装成质量指标的尝试率（attempt-rate）指标。

为什么更多工具会促使规划器陷入伪能力陷阱

三种力量共同作用，且每一种在孤立状态下都是隐形的。

上下文稀释（Context dilution）。 你加载的每个工具定义都会消耗系统提示词或工具清单中的 token，在用户查询到达之前，模型的注意力必须分散在所有这些定义上。关于“中后部遗忘”（lost in the middle）效应的研究多年来已经表明，当相关上下文埋没在大型提示词中时，LLM 的准确率会崩溃 —— 而一个包含 50 个工具的清单正是如此。用户意图的信号被规划器不会使用的 49 个工具的噪声所稀释。选择准确率下降并不是因为单个工具更难调用，而是因为从一群工具中挑选出正确的那一个，比从房间里唯一的工具中挑选要难得多。

语义模糊（Semantic blur）。 你随时间添加的工具往往会重叠。search_docs、search_kb 和 search_articles 对你来说看起来不同，因为是你编写了它们并记住了边界。对于规划器来说，它们是嵌入空间中一小块区域内的三个点，规划器会选择描述的表面特征与查询最匹配的那个 —— 这并不等同于实际上能返回正确答案的工具。研究工具选择偏差的研究人员表明，仅仅是结构相似的 API 名称就足以导致错误选择率大幅上升，即使底层工具的行为完全不同。

宽容先验（Permissive priors）。 推理调优模型，即那些在行动前会产生可见思维链的模型，已被证明相对于非推理模型会 增加 工具幻觉。这种直觉令人不安但很清晰：一个因生成自信的多步计划而获得奖励的推理模型，会将拒答视为一个缺失的步骤。它的推理轨迹会寻找一条通过现有工具的路径，找到一条局部合理的路径并遵循它。思维链将调用合理化，而不是质疑是否应该发生调用。

综上所述：更大的清单给了规划器更多的候选对象，这些候选对象比看起来更相似，且规划器经过训练更倾向于行动而非不行动。“我不知道”率下降是因为架构现在对拒答是不友好的。这种下降是性能退化的领先指标，而不是进步的滞后指标。

正确的查询处理并不等同于尝试处理查询

团队往往很晚才察觉到这种偏差，因为评测套件是围绕 Agent 能做什么 构建的，而不是围绕它 应该拒绝做什么 构建的。将“拒绝”视为“正确”是缺失的评估维度。

一个有用的重新构思是在评分之前将查询分为三类：

• 可以通过当前工具集回答。 正确的响应意味着调用了正确的工具且输出正确。
• 当前工具集无法回答，但原则上是可以回答的。 正确的响应应该是清晰且有范围限制的拒绝——“我没有办法做到这一点，原因如下”——而不是产生幻觉式的尝试。
• 描述不充分。 正确的响应是提出澄清问题，而不是调用工具。

陷阱在于，如果不进行这种拆分，每个查询都会按照第一类进行评分，即便拒绝是正确的决策，也会被视为失败。团队会下意识地训练自己去庆祝“尝试率”，而作为任何偏好信号下游的规划器（Planner），也会学到同样的教训。

如果你希望在工具扩展的过程中保持“弃权”（abstention）能力，评测中至少需要包含一个“没有工具匹配”即为正确答案的切片。随着每次工具扩展，这个切片应该变得更大而不是更小，因为每个新工具都会创造一类新的“差一点就匹配”的查询，规划器会受到诱惑去不恰当地调用它。关于“我们增加了五个工具”的诚实版本应该是：“我们增加了五个工具，同时也增加了五种 Agent 可能出错的新方式，因此弃权测试集也相应增加了。”

保持弃权率稳定的模式

一旦你接受了工具扩展即是弃权能力扩展，以下几种模式就变得不可或缺。

评测中的拒绝切片，其规模应与工具清单相匹配。 每个新工具发布时，都应附带一些“看起来”属于该新工具但实际上应该被拒绝的留出（held-out）查询。这与分类器中的对抗性测试模式相同：校准能力存在于那些“差一点就中”的案例里。如果你无法生成这组“差一点就中”的测试集，说明你对工具边界的理解还不足以添加它。

规划器必须参考的置信度信号。 模型口头表达的置信度是不可靠的——多项研究表明，模型说“我不确定”并不能很好地预测其准确性。但是，一个独立的、经过校准的闸门——比如一个小型分类器、保形预测（conformal prediction）层，或者一个刻意的两阶段规划器（第一步选择工具，第二步检查匹配度）——可以将弃权率保持在应有的水平。关键在于这个闸门必须在主推理循环之外。在循环内部，模型会将其合理化并绕过它。

针对每个查询的受限工具清单。 “始终公开所有工具”的模式是大多数效能稀释的根源。大多数现代 Agent 框架现在都支持某种形式的工具检索——根据查询挑选前 k 个相关的工具，然后针对这个较小的集合进行规划。这是结构性的修复，比任何 Prompt 层面的干预都重要。从 200 个工具目录中筛选出的 10 工具清单，在选择准确率上通常优于 200 工具的完整清单，而且弃权率能保持其实际意义，因为规划器无法对那些碰巧出现在上下文中的东西进行模式匹配。

弃权预算，作为一等指标进行监控。 团队的心理模型应该是：基于我们收到的描述不充分或超出范围的查询占比，查询组合中“我不知道”响应的底线是 X%。如果弃权率降至 X% 以下，这应该是一个回归告警，而不是值得庆祝的事。像对待错误率一样对待弃权率——将其视为底线而非上限——这样“伪能力”陷阱就不再是无声的了。

明天要做的事

提取过去 30 天的 Agent 追踪记录（traces）。根据 Agent 是否调用了工具以及最终交互是否成功完成进行分类——但同时也要随机抽取一些“调用了工具且成功完成”的样本，让人工审核正确答案是否本该是拒绝。

你很可能会在绿色的“完成”指标下发现大量“伪能力”案例。在这些案例中，规划器选择了一个“几乎”匹配的工具，返回了一个形状合理的评估结果，而用户因为错误答案并不明显而没有抱怨地继续操作。这部分代价就是由于你的工具扩展，将每一次“我不知道”默默转化为了一次自信的尝试。

关于 Agent 可靠性，一个不那么时髦的真相是：弃权是一种能力，而不是一种失败模式。一个知道什么时候不采取行动的 Agent 比一个拥有庞大工具库的 Agent 更有价值，而失去前者的最快方式就是在扩展后者的同时没有察觉到风险。仪表盘不会向你发出警告。你必须专门针对“拒绝”进行埋点，否则你将一直把“尝试”误认为是“答案”。