🧪 离线分数很好看，为什么线上还是频繁把工具调错
很多团队给模型接入搜索、工单、支付或 CRM 工具后，都会先做一套tool calling benchmark。表面上看，只要模型把工具名和参数拼对，离线分数就会迅速上涨。⚠️ 可一进真实链路，系统仍会出现“查到了旧单号”“多调一步把状态改坏”“结果正确但成本翻倍”这类问题。离线87%的轨迹通过率，并不等于线上就真的可用。📉
根因往往不在模型不会选工具，而在评测只检查“像不像参考答案”。🧠 真实生产里，同一个任务可能存在多条合法调用路径；相反，看起来轨迹很像的调用，也可能因为参数缺一个时间窗、缺一个租户 ID，最终把错误状态写进系统。只盯着trajectory match，评测奖励的就会是“表面相似”，而不是“结果正确且副作用可控”。📌
🔍 真正该核对的，不只是调用顺序，还包括结果验真和额外成本
工具调用场景里，最常见的误判有两类。第一类是模型多调了无关工具，答案仍然勉强正确，于是被高分放过。第二类是轨迹文本几乎一致，但关键参数槽位偏了一位，最后把错误数据写入外部系统。🔎 这也是很多团队为什么离线榜单很好看，线上回滚工单却越来越多的原因。😵
| 评测方式 | 离线得分 | 真实成功率 | 额外调用率 | 主要盲区 |
|---|---|---|---|---|
| 只看参考轨迹一致率 | 88.4% | 61.2% | 23.7% | 奖励表面相似调用 |
| 轨迹 + 参数槽位校验 | 82.6% | 72.9% | 14.1% | 不核对副作用状态 |
| 轨迹 + 结果验真 + 成本惩罚 | 79.8% | 81.5% | 6.3% | 维护成本更高 |
🛠️ 更稳的做法，是把评分拆成意图、参数、结果和预算四层
更适合生产的做法，是把一次工具调用拆成四层打分。✅ 第一层看工具意图是否正确，第二层看参数槽位是否完整，第三层直接核对执行后的目标状态，第四层再惩罚无意义的额外调用和重试。若工具具有写操作，还应在sandbox或dry-run环境里回放，避免评测集本身污染业务数据。🔒
defscore_tool_run(expected,actual):intent_ok=float(actual.tool_name==expected.tool_name)arg_score=compare_args(expected.args,actual.args)outcome_ok=float(verify_state(expected.post_state,actual.post_state))extra_penalty=0.2*max(actual.extra_calls,0)score=0.35*intent_ok+0.25*arg_score+0.30*outcome_ok-extra_penaltyifactual.has_side_effectandnotoutcome_ok:return0.0returnround(max(score,0.0),4)某客服工单链路在引入Outcome Verification后，离线总分反而从86%降到80%，但线上误改状态率从4.7%降到0.9%。📊 这个结果很有代表性：真正可靠的工具评测，通常不会让分数更漂亮，却会让错误更难藏在“看起来差不多”的轨迹里。🧩
🚀 接下来 3 到 6 个月，工具调用评测会从静态对答案转向可执行验真
接下来3到6个月，工具调用评测的分水岭，不会是谁写了更多参考轨迹，而是谁先把executable benchmark、状态快照和副作用回放接起来。🚀 只要评测还停留在文本比对层，模型就总能靠“说得像”骗过分数，却骗不过真实系统。🧭
笔者认为，Tool Calling最难的部分从来不是生成一段函数名，而是把一次外部动作安全地落到正确状态。💡 你们现在更头疼的，是参考轨迹太僵硬，还是结果验真太难接进评测流水线？如果这篇文章对你有帮助，欢迎点赞、收藏和关注。🙂
