一句话看懂：OpenRouter 发布教程，把 AI Agent 调用工具时的失败拆成“选错工具”和“参数传错”两类，并给出三套针对性的评测方法。对正在做 Agent 产品的人来说，这是一份可直接落地的测试清单，而不是又一篇概念科普。
事件核心：发生了什么
OpenRouter 在 9 月 30 日的教程中指出，Agent 调用工具会在两个位置出错：一是工具选择错误，例如用户要退款，模型却调用了 lookup_order 而不是 refund_order；二是工具选对了但参数错误，例如调用 refund_order 时把 order_id 写成 ord_7282，而用户问的是 ord_7281。
针对这两类问题，教程给出三条路径：无参考答案的 LLM Judge，适合多个工具都可能合理、正确性依赖上下文的场景；确定性的 JSON Schema 参数校验，用来抓格式、类型、枚举和缺失字段，但教程强调 schema 通过不等于值正确；以及轨迹对比（Trajectory Comparison），在工具调用顺序影响结果时使用。教程还提到 DeepEval 已分别提供 Tool Correctness 与 Argument Correctness 指标，Phoenix 也有独立的工具选择评估器，说明这种拆分正在成为评测框架的共识。
为什么重要
当下的 Agent 竞争已经从“能不能调用工具”转向“调用得准不准”。工具调用错误往往不会被 API 报错暴露，只会表现为一个看起来正常但答非所问的结果，这让评测变得困难。把工具选择和参数正确性分开测试，意味着开发者可以用更低的成本定位问题：能用代码判定的就不要调用模型裁判，只有在语义模糊时才引入 LLM Judge。这既降低了推理成本，也减少了评测本身的不确定性。目前公开信息显示，这类评测方法仍是工程实践层面的推进，尚未形成统一的行业基准。
对用户/开发者/创作者的影响
对开发者而言，最直接的收益是评测成本结构的变化。参数的必填字段、类型、枚举值可以用 Schema 在代码里零成本校验，只有“这个工具选得是否合理”“这段 query 是否表达用户意图”才需要耗费 token 让模型打分。教程也提醒，比较不同模型时必须保持测试用例、评分规则、模型参数和路由配置一致，否则结论不可比。对使用 Agent 产品的普通用户，这套方法的意义在于更少出现“明明说了退款却查了订单”这类静默失败。对做内容或自动化流程的创作者，如果工作流里挂了搜索、生图或文档工具，同样可以用这套思路做小规模回归测试。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是 DeepEval、Phoenix 等评测框架是否会进一步合并或标准化工具调用指标；二是 OpenRouter 的多模型统一路由是否会把这类评测能力产品化，让开发者在一个接口下横向跑分；三是无参考答案的 LLM Judge 自身准确性如何校准，教程建议先用人工审核的小样本验证裁判模型，这一点是否会成为默认流程值得观察。
