先记住这个答案
评估 Agent 工具调用正确性，通常先建立包含期望工具名、参数键值对与顺序的参考答案。比对时，将每次调用规范化为规范化事件，支持参数无序匹配、别名函数等价归一，并对冗余调用单独扣分。重点区分工具选择错误、参数错误与多余调用，分别统计，避免单一正确率掩盖问题。
- 参数匹配时忽略顺序，函数名需归一
- 等价调用需通过别名表进行归并
- 冗余调用单独计数，不直接判失败
如何规范化与匹配工具调用
第一步将参考轨迹中的每个工具调用解析为结构化形式：工具名（含命名空间）、位置参数列表和关键字参数字典。同样解析待测轨迹。然后对工具名进行归一化，例如存在函数别名时，将 getWeather 与 fetchWeather 视为同一个函数。对于参数，位置参数可能需要映射到命名参数，例如调用 search(query="x", limit=5) 与 search("x", 5) 应视为相同。
匹配算法采用二分图最大匹配：每个参考调用与待测调用如果工具名一致且参数键值对完全匹配（忽略键顺序），则视为可匹配。对于必须按序执行的工具（如先支付后验证），还应保留序列约束，但一般评估先检查覆盖度。等价调用通过预先定义的映射表，如 getUserByEmail 与 getUser 可能并不总是等价，需要任务说明。参数顺序问题，JavaScript 对象键无序，实际比对时应转为排序后的键列表。
一个实际场景：订单处理 Agent 评估
假设任务：用户要求取消订单 #123 并退款 500 元。参考轨迹调用三个工具：1) getOrder(orderId="123") 2) cancelOrder(orderId="123") 3) refund(orderId="123", amount=500)。待测 Agent 调用为：1) getOrder("123") 2) refund(amount=500, orderId="123") 3) cancelOrder(orderId="123") 4) getOrder(orderId="123") 再次调用。
规范化后，getOrder("123") 等于 getOrder(orderId="123")，refund 参数顺序不同但键值匹配。匹配时，参考中的 getOrder 可与待测中的一个 getOrder 匹配，另一个为冗余；cancel 和 refund 也能找到对应。因此工具选择正确，但存在冗余，按规则扣冗余分。同时顺序也需检查：参考中 cancel 在 refund 前，而待测中 refund 在 cancel 之前，可能造成错误退款行为，需要根据任务定义判断是否顺序敏感。
极易发生误判的情况
当工具调用具有副作用时，顺序至关重要。例如先关闭账户再注销与先注销再关闭，虽然调用的工具集合相同，但次序不同会导致不同结果。若参考答案只包含调用，忽略时序，就会漏判。另一个失败边界是参数值等价，例如金额 500 元与 5 百元，或日期格式 2023-01-01 与 1/1/2023，需要定义值归一化规则。
处理方式：如果任务定义为顺序敏感，需在比对中加入顺序约束，使用序列对齐算法如动态规划，允许交换但惩罚。对于参数值等价，引入值解析器将日期、货币等格式化。代价是增加实现复杂度，且太多归一会掩盖实际错误。因此只对任务中明确等价的对象归一，否则保留原值。
容易答错的地方
- 只看工具名不检查参数
- 有些评估只判断是否调用了某个工具，忽略参数错误。例如 Agent 调用
sendEmail(to="a@b.com")但参数真实值是 c@b.com，实际上任务失败，但名对的工具会给误导。必须比对参数。 - 把调用顺序全部视为必须一致
- 许多工具调用顺序无关紧要，如两次独立查询。若强制顺序匹配，会误杀正确路径。应根据任务定义哪些工具序有约束，而非一刀切。
面试官还会怎么问？
如何与参考答案部分匹配时计分？
可采用 F1 或覆盖率。匹配调用数除以参考调用数为召回，除以待测有实际作用的调用数为精确率，但冗余单独扣除，而非降低精确率。也可给每个调用权重，总量权重相同。
等价调用归并导致误判怎么办？
归并表应基于任务数据，如日期格式差异可归并，但 API 名称不同通常表示不同功能。如果两个函数完全等价（如 v1/v2），可通过测试确定，然后加入归一。否则宁可严格，接受漏掉等价但概率低。
冗余调用是否一定扣分？
不一定。如果冗余是必要的轮询或补偿，则不算冗余。应根据任务的成本与副作用定义：如重复查询数据而无状态变化，可能不影响但增加成本，可用成本项评估；若多余调用有副作用则必须罚。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。