Agent 工具调用回归测试：跨模型跑 function calling 的六个必测点

引言

Agent 类应用最脆弱的地方不是推理能力，而是工具调用。同一个 prompt、同一套工具定义，模型 A 能规规矩矩返回结构化参数，模型 B 却把参数包成字符串、或凭空编造一个不存在的工具、或在多轮里丢掉调用 id。这类问题在单次演示里看不出来，只在批量运行和版本切换时集中爆发。所以换模型、升级版本之前，必须有一套工具调用的回归测试。本文给出六个必测点、一套网关侧的灰度与回放方法，示例日志取自词元无忧的调用明细。

一、为什么工具调用最容易在换模型时崩

工具调用是 “自然语言理解 + 结构化输出 + 多轮状态维护” 三件事叠在一起。不同模型厂商对 function calling 的实现路径不同：有的走独立的 tools 字段，有的靠提示词约束输出 JSON，有的在流式里分块返回参数。协议层一旦被网关重写，结构就可能变形。加上 Agent 常常一轮里连调多个工具，任何一次参数格式偏差都会让后续步骤连锁失败。

二、六个必测点

1.schema 严格度：给一个带必填字段和枚举值的工具定义，看模型是否严格按 schema 输出，还是擅自增加字段、把枚举值写成近义词。

2.参数类型：故意设计一个需要整数和一个需要布尔值的参数，检查返回的是 3 还是 "3"，是 true 还是 "true"。类型漂移在部分链路上非常常见。

3.并行调用：一次提问需要同时调两个工具，看模型是否返回多个 tool_use 块，以及 id 是否互不重复。

4.多轮回填：把工具执行结果按 tool_result 回填，检查模型是否正确关联到对应的调用 id。id 丢失是网关改写响应体最典型的症状。

5.幻觉工具：问一个现有工具无法回答的问题，看模型是老实说做不到，还是编造一个不存在的工具名。后者在 Agent 里会导致直接异常。

6.长上下文下的工具选择：把工具数量加到 15 个以上、描述都较接近，观察选择准确率是否明显下滑。这一项最能暴露模型在工具集变大后的稳定性。

三、用网关做灰度与回放

回归测试要跑得起来，前提是能 “同一批样本打不同模型”。统一网关在这里的价值是两件事：

一是灰度切换。把新版本模型配成独立的一个 model 标识，让测试流量先走它，生产流量仍走旧版，用同一套业务代码对比两边的工具调用成功率、平均轮次、异常率。有问题随时切回，不需要改代码。

二是历史回放。把生产环境真实的请求日志导出，脱敏后作为回归样本重放。词元无忧的调用明细保留了完整的请求与响应结构，包括工具调用块和错误信息，这类日志正是回放测试最需要的原料 —— 人工构造的样本永远覆盖不到真实用户那些奇怪的多轮组合。

四、判分：自动 + 抽检两条腿

工具调用的正确性可以自动判：参数是否符合 schema、id 是否匹配、是否调用了不存在的工具，这些用规则就能覆盖。但 “工具选得对不对” 属于语义判断，建议规则判一遍之后再人工抽检 20 条，尤其关注那些 “参数合法但选错工具” 的隐性错误 —— 这类错误不会报异常，只会让 Agent 越跑越偏。

总结

Agent 换模型不是改一个 model 参数就结束，工具调用的六个必测点才是真正的验收标准：schema 严格度、参数类型、并行调用、多轮回填、幻觉工具、大工具集下的选择准确率。测试要能跑起来，需要网关提供灰度切换和历史回放两个能力，再配合 “规则判分 + 人工抽检” 的双轨判分。把这套回归做成固定流程之后，你换模型的决策依据是数据而不是演示效果 —— 而一份结构完整的调用日志，正是这套流程能成立的基础。