如何测试 AI Agent 的工具调用准确性

核心亮点

OpenRouter 发布教程，讲解如何测试 AI 智能体的工具调用准确性，核心是把失败拆成两类：工具选择错误（选错工具）与参数错误（工具对但参数错）。分而治之才能对症下药，而不是笼统说"又错了"。

具体能力或事件经过

教程主张不要只盯最终答案，要单独测"调了哪个工具"和"参数填得对不对"。比如该调搜索却调了计算，是选择错；工具对但日期格式错，是参数错。两类错误的修复路径不同，混在一起会误导优化方向。

技术细节

做法是准备带标准答案的用例：每条标清"期望工具"与"期望参数"。跑批后统计选择准确率与参数准确率，分别归因。这样能定位是路由层还是填槽层的问题。建议用真实流量抽样，而非纯合成，保留分布与失败模式。

与竞品对比

很多团队用端到端成功率一个指标糊弄，难以诊断。OpenRouter 把工具调用拆成选择+参数两步评测，和软件测试里"单测分层"同源。它和同批的回归测试、golden 评测教程构成一套方法论，比单次打分更工程化。

行业影响或适用场景

凡是智能体要调 API、查库、跑命令的场景都该用。客服、运维、数据分析的智能体，工具调用错一次就出事故。分层评测让团队在模型或提示词变更后，快速知道是"选错工具"还是"填错参数"，缩短排错时间。

数据口径与可信度

教程给的是方法论，阈值与样本量需你按自有任务标定。用例要覆盖高频与易错工具，评分标准写成可执行 rubric。引用时保留"通用方法"的限定，别当开箱即用的测试套件，仍需结合自身流量建设。

风险与边界

分层能定位问题，但不保证修好：选择错可能根因在提示词描述不清，参数错可能根因在 schema 定义模糊。评测集太小会漏长尾。它要和回归、监控配合，不能替代线上观察。误把参数错当选择错会改错地方。

市场定位

OpenRouter 借一连串教程把自己定位成"智能体评测方法论"提供方，而不只是模型商店。对用量大的团队，这类工程纪律比模型覆盖更值钱。它在卖"怎么靠谱用模型"，顺带把路由入口绑进工作流。

延伸观察

工具调用可靠性会成 Agent 落地的前置条件。未来比的不是模型多会聊，而是多会"做对动作"。分层评测、回归、golden 集这些工程能力，会像单测之于软件一样成为 Agent 团队的标配，缺了就别上生产。

进一步分析

说白了，测智能体不能只看过没过，要拆成"选对工具没"和"参数填对没"。两类错修法不同：选错常是路由或描述问题，填错常是 schema 或示例问题。分而治之才能少走弯路。这是把软件测试的分层思想搬进了 Agent 评测。

实操建议

建工具调用评测集：每条标期望工具与期望参数，用真实流量抽样。分别统计选择准确率与参数准确率，归因为路由层或填槽层。模型/提示词变更后重跑，接进 CI。把失败模式记进用例库，逐步扩到数百条。监控生产参数错率，发现异常回滚。

一句话结论

说白了，OpenRouter 教程把工具调用错误拆成"选错工具"与"填错参数"两类分别评测。分而治之才能对症优化。凡智能体调外部工具的团队都该用，它是 Agent 可靠落地的工程基本功。