你在做一个「客服工单助手」：用户描述问题后，模型可以调用多个工具，例如：
search_order(order_id)query_refund_policy(product_type)create_ticket(user_id, issue_type, priority)transfer_to_human(reason)请你设计一套评测方案，判断模型的 tool call 是否真的可靠。
你可以重点回答：
不知道
本次未作答，完整示范回答如下。
结论先行：Tool Call Evaluation 不能只看最终回答，而要把一次工具调用拆成“是否该调用、调用哪个工具、参数是否正确、顺序是否合理、失败后能否恢复、最终结果是否符合业务约束”几层分别评测。 因为在生产环境里，最终回答看起来对，不代表工具调用过程安全、稳定、可复现。
我会把正确性拆成四层：
第一，工具选择正确。
模型应该在需要查订单时调用 search_order，需要查退款规则时调用 query_refund_policy，而不是直接编造答案。
如果问题超出权限或风险较高，应该调用 transfer_to_human。
第二，参数填写正确。
例如用户说“查一下订单 123 的退款进度”，模型应该提取出 order_id=123，而不是漏填、错填，或者把用户 ID 当订单 ID。
第三，调用顺序正确。
有些场景不能一步到位。比如要创建工单，可能要先确认用户身份、查询订单状态，再决定 issue_type 和 priority。
如果顺序错了，可能会创建错误工单或绕过业务规则。
第四，结果使用正确。 工具返回结果后，模型不能忽略、误读或篡改工具结果。 例如退款政策说“不支持退款”，模型不能为了安抚用户说“可以退款”。
所以最终回答只是结果层评测，不能替代过程层评测。
测试集要覆盖正常路径、边界路径和异常路径。
正常路径： 例如用户提供完整订单号，问题明确，模型应该调用正确工具并给出明确答复。
信息缺失路径： 用户说“帮我查下退款”，但没有订单号。模型不应该乱调用，而应该追问必要信息。
多工具路径： 例如用户问“我这个商品能不能退，顺便帮我建个工单”。 模型可能需要先查退款政策，再根据结果决定是否创建工单。
权限和安全路径： 例如用户要求查看别人的订单，模型应该拒绝或转人工，而不是直接调用查询工具。
工具失败路径：
例如 search_order 超时、返回空、返回错误码。模型需要重试、降级、解释，或者转人工。
业务规则边界： 例如退款期限刚好过期、VIP 用户优先级更高、高风险投诉必须转人工。
每条 golden case 需要标注：期望工具、期望参数、期望调用顺序、期望最终行为。
我会分层评估，而不是只给一个总分。
工具选择准确率： 模型是否选对工具，是否避免了不该调用的工具。
参数准确率： 参数字段是否完整、类型是否正确、值是否来自用户输入或可信上下文。
调用顺序准确率： 多工具场景下，是否按照合理业务链路执行。
不必要调用率： 模型是否在不需要工具时滥用工具，例如普通解释类问题也调用订单查询。
漏调用率： 模型是否在必须查真实数据时直接编造答案。
失败恢复能力： 工具超时、报错、无结果时，模型是否能重试、追问、降级或转人工。
最终任务成功率： 用户问题是否被解决，且过程符合业务规则。
线上发现 tool call 错误后，我会通过 trace 定位链路。
如果模型选错工具，优先看 prompt 和 tool schema。 可能是工具描述不清楚，多个工具边界重叠，或者 prompt 没有说明什么时候必须转人工。
如果工具选对但参数错，重点看参数 schema 和上下文抽取。 比如字段名模糊、缺少 enum、没有 examples，或者上下文里有多个订单号导致模型混淆。
如果调用顺序错，通常是 workflow 设计问题。 这时不能只靠 prompt，而应该把关键业务流程固化成状态机或后端编排逻辑。
如果工具结果被误读，重点看结果格式和 response grounding。 工具返回结构应该清晰，最好用结构化字段，而不是让模型解析一大段自然语言。
如果只在复杂 case 出错，可能是模型能力或测试覆盖问题。 可以增加 few-shot、拆任务、换更强模型，或者把高风险步骤交给规则系统处理。
真正上线时，我还会加三类机制。
第一，可观测性。 记录每次请求的 user input、selected tool、arguments、tool result、final answer、latency、cost、error code，方便回放和排查。
第二，回归测试。 每次改 prompt、tool schema、模型版本或业务规则，都跑一遍 golden cases，避免工具调用能力退化。
第三，风险控制。 对退款、赔付、改地址、取消订单等高风险操作，引入 human-in-the-loop 或二次确认，不能完全交给模型自由执行。
一句话总结： 评测 tool call 可靠性，本质上是在评测模型能否把自然语言请求稳定地映射到正确、合规、可恢复的业务动作；因此必须同时评测过程、结果和线上可追踪性。