填充式工具调用：当智能体在表演勤奋而不是真正干活

打开任何一个生产环境智能体的 trace，看一看在用户提问和第一个真正有用的动作之间到底跑了哪些工具调用。你会看到一个 get_user_profile 返回了一个根本没人用的名字、一个 check_status 返回绿色然后再也没被引用、一个 list_recent_orders 的结果被总结成"ok"然后直接丢掉。这些调用没有一个改变了最终答案。但每一个都花了真金白银的钱、真实的延迟，以及在 trace 里真实占一行。你的智能体已经学会了表演勤奋——而表演勤奋如今是你最大的单一浪费来源。

这就是填充式工具调用：智能体发出一个动作，不是因为它需要那个结果，而是因为"先想一想，再行动"的整体模式在训练时被反复奖励，多到模型现在会把"显得周全"当作回答任何问题的副作用来执行。这是一个 LLM 版本的初级分析师，故意打开五个根本不会读的标签页，好让坐在对面的高级同事看到自己很忙。区别只在于：初级分析师会累。智能体永远不会。

经济账比看起来更糟。2025 年阿里巴巴关于其 Metis 智能体的一项研究报告显示，基线系统中冗余工具调用占比高达 98%，经过针对性训练后降到 2%——更关键的是，准确率在同一时间还提升了。SMART 这类"工具滥用治理"方向的工作也证明，一个只有 7B 参数的小智能体，只要给它一个知识边界信号，就能用五分之一的调用量追平 70B 的同类水平。换句话说：填充式调用不只是贵，它还在主动拉低你的输出质量，因为上下文窗口里每多一个无关观测，都在稀释模型本该用来推理的那一点信号。

模型为什么会学着伪装周全

填充式调用是训练循环里长出来的，不是 prompt 里写出来的。如果微调或 RL 的奖励信号被"几乎都能从查询里获益的任务"所主导，那么策略梯度就会把模型推向更频繁地调用工具，而不是更少——因为多一次没必要的调用，对 loss 函数而言是隐形的；少一次该有的调用，对 loss 函数而言却是致命的。这跟一个"防御性医生"非要多开一次扫描是同一种不对称：漏诊有名字写在病例上，过度检查没有。

具体来说，有三种训练压力合谋制造填充：

• 只看结果的奖励模型。当奖励只盯着最终答案，模型就把中间步骤当作免费的，没有任何梯度把它拉向简洁。
• 从冗长的示范中模仿。被当作监督数据的公开智能体 trace 里，"我先验证一下……"这种模式比比皆是。模型先学会了这套语言脚手架，再学会脚手架后面通常挂着一个工具调用。
• 工具描述偏差。研究表明，仅仅是修改工具的描述文字，就能让选用频率发生不成比例的偏移。一个被描述成"X 的权威来源"的工具，只要问题里出现"X"这个字眼就会被调用，不管智能体其实早就知道答案。

你自己的 prompt 也在固化这种行为。那条经典的系统指令——"回答之前，先收集所有相关的上下文"——会被模型逐字执行。哪怕回答所需的全部上下文已经在用户那一句话里了，它还是会去"收集"。

填充式调用到底花了你多少钱

每一次填充式工具调用，背后都有四个计费表在跑。多数团队只插了第一个表。

第一个表是调用本身的 token。工具定义会在每一轮里被粘进上下文，schema 经常一写就是几百个 token。当一个智能体接入了太多工具服务器，光是工具定义就能吃掉绝大部分 prompt 预算。第二个表是结果的 token，这一项通常更糟：一个本来只需要 3 个字段的工具，返回了一个有 50 个字段的 JSON blob，于是模型在下一轮要花上数千个输入 token 来搞清楚哪些字段应该忽略。第三个表是延迟。一次到模型的往返大概是 800 毫秒；多加一次工具调用就要再加上网络往返、后端处理、再加一轮模型推理来消化结果。三个填充式调用堆在答案的路径上，就是"感觉是实时的功能"与"感觉是一个慢 API"之间的差距。第四个表是准确率衰减，这一项往往是团队最后才发现的。含有大量无关观测的长上下文，会可测地降低模型对相关信息的推理能力；最糟的情况是模型锚定在一个填充式观测上，给出一个错误答案——而那个问题在更短的上下文里本来是会答对的。

把这四个表加起来，你就明白为什么智能体的成本账永远对不上纸面计算。你的 token 账单涨了 3 倍，但用户能看到的工作只多了 1 倍——多出来的 2 倍都是表演。

反事实检验：去掉这次调用，答案会不一样吗？

加载中…