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_search vs search_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 路由的模型）时，开发者必须确保测试的一致性：

1. 统一测试用例：所有候选模型必须运行完全相同的测试集。
2. 固定评分规则：无论是使用 LLM Judge 还是代码校验，评分标准和权重需保持一致。
3. 环境隔离：模型配置（Temperature, Top-P）和路由配置（Routing Configuration）必须完全相同。

总结

OpenRouter 的这篇指南不仅提供了技术细节，更强调了评估的分层思维：对于结构问题用代码解决，对于语义问题用 LLM 解决，对于流程问题用轨迹分析解决。这对于构建生产级、高可靠性的 AI Agent 应用至关重要。