OpenRouter 发布工具调用评估指南：构建更可靠的 AI Agent 测试框架
随着 AI Agent 能力的日益增强，工具调用（Tool Calling）已成为其执行复杂任务的核心环节。然而，Agent 在工具使用上存在两种截然不同的故障模式：选错工具（Tool Selection）和参数传错（Argument Correctness）。OpenRouter 最新发布的《如何测试 AI Agent 的工具调用准确性》一文，为开发者提供了一套系统化的评估方法论。
核心痛点：两种独立的故障模式
开发者往往难以区分 Agent 失败的具体原因。例如，一个支持 lookup_order 和 refund_order 的客服 Agent，若用户询问退款政策，Agent 错误调用了 refund_order，这是工具选择错误；若它正确调用了 refund_order 但传入了错误的 order_id，则是参数错误。这两种错误需要完全不同的测试策略。
三大评估策略详解
1. 参考自由的 LLM 判断 (Reference-free LLM Judge)
当没有单一的标准答案，或者存在多种合理选择时，代码无法直接验证，此时需引入 LLM 作为裁判。
- 适用场景：工具选择模糊（如
web_searchvssearch_internal_docs）或参数语义复杂（如搜索查询是否准确表达了用户意图）。 - 实施方法：将用户请求、可用工具列表及模型输出输入给一个经过微调的 Judge 模型，要求其判断工具选择是否恰当。
- 注意事项：必须固定 Judge 模型的指令和版本，并在全面评估前在小样本集上进行人工校准。
2. 确定性的 Schema 参数校验 (Deterministic Schema Checks)
并非所有错误都需要 LLM 介入，结构性的参数错误可通过代码自动捕获。
- 适用场景：参数格式错误、必填字段缺失、类型不匹配（如字符串传入了布尔值）或额外字段违规。
- 实施方法：复用发送给模型的 JSON Schema 来验证返回的
arguments。例如，检查lookup_order是否缺少order_id，或include_items是否为布尔类型。 - 局限性：Schema 校验通过不代表参数值正确（例如
order_id格式正确但数值错误），因此需结合业务逻辑进行二次检查。
3. 调用轨迹对比 (Trajectory Comparison)
针对多步骤 Agent，单次调用的准确性不足以反映整体能力。
- 适用场景：任务依赖严格的调用顺序，如退款流程需依次执行
lookup_order->verify_refund_eligibility->issue_refund。 - 实施方法：对比模型生成的工具调用序列与预期轨迹。若存在多条有效路径达成同一结果，则不应强制要求序列完全一致，而应评估最终状态的正确性。
最佳实践与跨模型对比
在对比不同模型（特别是通过 OpenRouter 路由的模型）时，开发者必须确保测试的一致性：
- 统一测试用例：所有候选模型必须运行完全相同的测试集。
- 固定评分规则：无论是使用 LLM Judge 还是代码校验，评分标准和权重需保持一致。
- 环境隔离：模型配置（Temperature, Top-P）和路由配置（Routing Configuration）必须完全相同。
总结
OpenRouter 的这篇指南不仅提供了技术细节，更强调了评估的分层思维：对于结构问题用代码解决，对于语义问题用 LLM 解决，对于流程问题用轨迹分析解决。这对于构建生产级、高可靠性的 AI Agent 应用至关重要。
