70. 工具调用准确率（Tool Usage Accuracy）

难度 P1 高频 · 岗位应用 · 频率 ★★★★☆ · 预计阅读 8 min 公司 OpenAI · Anthropic · Google 相关题 Q69 任务成功率 · Q62 工具使用模式 · Q22 Function Calling

本题阅读地图

面试场景还原 — 1 min
TL;DR 速记 — 30 sec
图解 — 30 sec
详细解析 — 5 min
常见踩坑与反例 — 1 min
面试官可能继续追问 — 1 min

面试场景还原

�面试官：我们 Agent 的任务成功率是 75%，想提升到 90%，你有什么思路？

🙋‍♂️我：优化 Prompt，让模型更仔细地思考。

👔面试官：Prompt 优化可能有点帮助，但你知道失败的任务中，有多少是因为工具调用出错导致的吗？

🙋‍♂️我：这个……不太清楚。

👔面试官：75% 的成功率背后可能有不同的原因：是理解错用户意图？还是规划有问题？还是工具调用出错？如果不拆细看，优化就是盲目的。特别是工具调用，它是 Agent 与外部交互的唯一手段，如果工具选错了或参数填错了，后面再怎么推理也没用。

🙋‍♂️我：那怎么评估工具调用的问题？

👔面试官：拆成三个维度：工具选择准确率（选没选对工具）、参数填写准确率（参数填没填对）、调用时机准确率（该不该调的时候调了）。分别监控，才能精确定位问题。

TL;DR 速记

是什么：评估 Agent 工具使用能力的核心过程指标
三维度：工具选择（选对了吗）、参数填写（填对了吗）、调用时机（该调吗）
重要性：工具调用是 Agent 与外部世界的唯一交互手段，调错则后续全错
数据采集：记录调用轨迹、对比理想轨迹、人工抽查边界 case
优化策略：优化工具描述、参数校验、Few-shot 示例、工具分类管理

图解

图 1：工具调用准确率的三维评估

图 2：工具调用错误的影响链

详细解析

为什么需要单独评估工具调用？

任务成功率（Task Completion Rate）是最终结果指标，但它是一个「黑盒」指标——任务失败了，你不知道是哪一层出了问题。

Agent 系统的典型故障分层：

用户输入
    ↓
意图理解层（理解对了吗？）
    ↓
规划层（规划合理吗？）
    ↓
工具调用层（选对了？填对了？时机对了吗？） ← 工具调用准确率评估这一层
    ↓
结果处理层（处理工具返回了吗？）
    ↓
输出生成层（生成合理回答了吗？）

工具调用层的关键地位：

工具调用是 Agent 与外部世界交互的唯一手段
工具调用错了，后续推理再正确也没用（garbage in, garbage out）
工具调用错误是最常见的失败原因之一

单独评估的价值：

精准定位：区分是「不知道怎么调」（理解/规划问题）还是「调错了」（调用执行问题）
指导优化：不同维度的错误需要不同的优化策略
过程监控：在最终结果出来前就能发现问题
工程决策：评估是否需要增加工具、优化工具描述、加强参数校验

三维评估体系详解

维度 1：工具选择准确率（Tool Selection Accuracy）

定义：Agent 面对一个需求时，是否选择了正确的工具。

计算方式：

工具选择准确率 = 正确选择工具的次数 / 总工具调用次数 × 100%

正确选择的标准：

该调工具的时候调了（不该调的时候没调）
从多个可用工具中选了最合适的那一个

示例分析：

用户需求：「帮我查一下明天的天气」

✅ 正确选择：调用 weather_api
❌ 错误选择 1：调用 search_api（绕远路）
❌ 错误选择 2：没有调工具，直接基于训练数据回答
❌ 错误选择 3：调用了 book_flight_api（完全不相关）

选择错误的典型原因：

工具描述不清晰，模型不知道每个工具的能力边界
工具数量太多，模型选择困难
需求模糊，多个工具都可能相关

维度 2：参数填写准确率（Parameter Filling Accuracy）

定义：Agent 调用工具时，参数填写是否正确。

计算方式：

参数填写准确率 = 参数填写正确的调用次数 / 总工具调用次数 × 100%

参数错误的类型：

错误类型	示例	后果
缺少必填参数	调用天气 API 没传城市名	调用失败
参数类型错误	数字参数传了字符串	调用失败或返回错误结果
参数值错误	城市名写成 "Beijing" 但 API 只接受 "北京"	调用失败
参数格式错误	日期格式 "2024-01-01" 但 API 要 "01/01/2024"	调用失败
多余参数	传了工具不认识的参数	部分工具会忽略，部分会报错

示例分析：

json

// 正确的调用
{
  "tool": "get_weather",
  "parameters": {
    "city": "北京",
    "date": "2024-01-15"
  }
}

// 错误的调用（参数值格式错误）
{
  "tool": "get_weather",
  "parameters": {
    "city": "Beijing",  // 错误：API 只接受中文
    "date": "tomorrow"  // 错误：API 要求具体日期格式
  }
}

维度 3：调用时机准确率（Calling Timing Accuracy）

定义：Agent 是否在合适的时机调用工具。

计算方式：

调用时机准确率 = 时机正确的调用次数 / 总工具调用次数 × 100%

时机错误的场景：

过早调用：

还没理解清楚用户需求就调用
还没收集足够信息就调用

过晚调用：

应该早点调工具获取信息，却一直在内部推理
绕了很多弯路才想到要调工具

重复调用：

同样的工具、同样的参数连续调用多次
可能是遗忘或逻辑错误

遗漏调用：

该调的时候没调，导致任务失败

示例分析：

用户：「帮我查一下从北京去上海的最快方式」

❌ 过早：一上来就调用 train_api，没考虑飞机可能更快
❌ 过晚：先搜了很多网页了解「最快」的定义，最后才调 API
❌ 重复：查询火车时刻表时，因为内存里没记住，重复查了两遍
✅ 正确：先思考需要比较哪些交通方式 → 并行调用 train_api 和 flight_api → 对比结果

工具调用错误的类型与原因

错误类型	典型原因	优化策略
选错工具	工具描述不清晰；工具数量过多；需求理解偏差	优化工具描述；减少单次挂载工具数量；改进意图理解
参数缺失	Prompt 没强调必填参数；模型遗忘	在参数描述中标注 required；Few-shot 示例展示完整参数
参数值错误	格式不一致（如日期格式）；单位不一致（如米 vs 千米）	统一参数格式；在描述中给示例值；参数值校验
参数类型错	模型输出格式不符合 JSON Schema	加强 Schema 描述；后处理校验
时机过早	规划能力不足；急于行动	加强规划 Prompt；先思考后行动的训练
时机过晚	过度推理；忘记工具能力	工具描述中强调适用场景；适时提醒可用工具
重复调用	记忆缺失；逻辑错误	上下文管理；重复检测机制

数据采集与分析方法

数据采集内容：

每次工具调用需要记录：

json

{
  "timestamp": "2024-01-15T10:30:00Z",
  "session_id": "sess_xxx",
  "user_query": "查北京天气",
  "selected_tool": "get_weather",
  "parameters": {"city": "北京"},
  "tool_result": {"temperature": 25, "condition": "晴"},
  "tool_success": true,
  "llm_decision_trace": "思考过程...",
  "is_correct_selection": true,
  "is_correct_parameters": true,
  "is_correct_timing": true
}

自动判定方法：

规则判定：
- 工具返回错误 → 参数可能填错
- 工具返回空结果但不应该空 → 参数可能填错
- 连续调用相同工具相同参数 → 重复调用
黄金轨迹对比：
- 预定义「理想轨迹」（应该调什么工具、填什么参数）
- 对比实际轨迹与理想轨迹的差异
结果反向验证：
- 如果工具调用后任务最终成功 → 调用大概率正确
- 如果工具调用后任务失败 → 分析是不是调用错误导致

人工审核重点：

工具选择有争议的 case（多个工具都可能对）
参数填写边界 case（如空值处理、特殊字符）
调用时机微妙的 case

提升工具调用准确率的策略

策略 1：优化工具描述（Tool Description）

json

{
  "name": "get_weather",
  "description": "获取指定城市的天气信息。当用户询问天气、气温、是否适合外出时使用。",
  "parameters": {
    "city": {
      "type": "string",
      "description": "城市名称，必须是中文，如\"北京\"、\"上海\"、\"广州\""
    },
    "date": {
      "type": "string",
      "description": "日期，格式为 YYYY-MM-DD，如\"2024-01-15\"。不传则默认今天。"
    }
  },
  "required": ["city"]
}

要点：

说明工具的适用场景（什么时候该调）
参数描述给具体示例
标注必填参数

策略 2：Few-shot 示例

在 Prompt 中给工具调用的示例：

示例 1：
用户：北京今天天气怎么样？
思考：用户需要天气信息，应该调用 get_weather
调用：{"tool": "get_weather", "parameters": {"city": "北京"}}

示例 2：
用户：明天上海会下雨吗？
思考：用户需要明天上海的天气，调用 get_weather，date 参数填明天日期
调用：{"tool": "get_weather", "parameters": {"city": "上海", "date": "2024-01-16"}}

策略 3：参数校验层

在代码层增加参数校验，拦截明显错误的调用：

python

def validate_tool_call(tool_name, parameters):
    schema = tool_schemas[tool_name]

    # 检查必填参数
    for param in schema.required:
        if param not in parameters:
            return False, f"缺少必填参数: {param}"

    # 检查参数类型
    for param, value in parameters.items():
        expected_type = schema.properties[param].type
        if not check_type(value, expected_type):
            return False, f"参数 {param} 类型错误"

    # 自定义规则校验
    if tool_name == "get_weather":
        city = parameters.get("city")
        if not is_chinese(city):
            return False, "城市名必须是中文"

    return True, "校验通过"

策略 4：工具分类与动态挂载

不要一次性给模型挂载所有工具，而是按场景动态挂载：

python

if user_intent == "weather":
    available_tools = [get_weather, get_air_quality]
elif user_intent == "travel":
    available_tools = [search_flight, search_train, book_hotel]

减少选择范围，提升选择准确率。

策略 5：错误反馈与迭代

当工具调用失败时，把错误信息反馈给模型，让它学习：

工具调用失败：get_weather({"city": "Beijing"})
错误信息：城市名必须是中文

模型学习后，下次调用：get_weather({"city": "北京"})

常见踩坑与反例

踩坑 1：只看任务成功率，忽视工具调用准确率

错误做法：只监控最终任务是否完成，不监控工具调用对不对。

问题：任务成功率低时不知道是哪层的问题，无法针对性优化。

正确做法：分层监控：任务成功率 → 工具调用准确率 → 各维度细分指标。

踩坑 2：工具描述写得模糊

错误做法：工具描述只有一句话，模型不知道具体怎么用。

正确做法：详细描述适用场景、参数含义、示例值。

踩坑 3：没有参数校验

错误做法：直接把模型输出的参数传给工具，不做任何校验。

问题：参数错误导致工具调用失败，浪费资源且体验差。

正确做法：增加参数校验层，拦截明显错误的调用。

踩坑 4：工具数量过多

错误做法：一次性给模型挂载几十个工具。

问题：模型选择困难，准确率下降。

正确做法：按场景动态挂载工具，每次不超过 5-10 个。

踩坑 5：没有错误反馈机制

错误做法：工具调用失败后直接报错，不给模型学习和重试的机会。

正确做法：把错误信息回传给模型，让它分析原因并重试。

面试官可能继续追问

追问 1：工具选择准确率怎么提升？ 答题要点：优化工具描述（明确适用场景）、减少单次挂载工具数量、用 Few-shot 示例教模型怎么选、按场景动态挂载工具。
追问 2：参数填写准确率怎么提升？ 答题要点：详细描述参数含义和格式、给示例值、增加参数校验层、在 Prompt 中强调必填参数。
追问 3：工具调用错误怎么分类处理？ 答题要点：区分选择错误、参数错误、时机错误；选择错误优化工具描述；参数错误增加校验；时机错误优化规划 Prompt。
追问 4：工具调用成本和准确率怎么平衡？ 答题要点：关键任务（如支付）必须 100% 准确，多重校验；普通查询任务可以适当降低要求；用轻量级模型做工具选择，强模型做主推理。

面试总结

工具调用准确率是 Agent 工程能力的核心指标。面试时强调：

三层评估：工具选择、参数填写、调用时机，分别监控才能精确定位问题
指标价值：工具调用是 Agent 与外部世界的唯一交互手段，调错则后续全错
优化策略：优化工具描述、Few-shot 示例、参数校验、动态挂载

记住：只看任务成功率是黑盒评估，拆开看工具调用准确率才能知道「哪里错了」。这是区分「会搭 Agent」和「精通 Agent」的关键知识点。

章节首页 · ← Q69 · Q71 →

70. 工具调用准确率（Tool Usage Accuracy） ​

本题阅读地图 ​

面试场景还原 ​

TL;DR 速记 ​

图解 ​

图 1：工具调用准确率的三维评估 ​

图 2：工具调用错误的影响链 ​

详细解析 ​

为什么需要单独评估工具调用？ ​

三维评估体系详解 ​

维度 1：工具选择准确率（Tool Selection Accuracy） ​

维度 2：参数填写准确率（Parameter Filling Accuracy） ​

维度 3：调用时机准确率（Calling Timing Accuracy） ​

工具调用错误的类型与原因 ​

数据采集与分析方法 ​

提升工具调用准确率的策略 ​

常见踩坑与反例 ​

踩坑 1：只看任务成功率，忽视工具调用准确率 ​

踩坑 2：工具描述写得模糊 ​

踩坑 3：没有参数校验 ​

踩坑 4：工具数量过多 ​

踩坑 5：没有错误反馈机制 ​

面试官可能继续追问 ​

面试总结 ​

70. 工具调用准确率（Tool Usage Accuracy）

本题阅读地图

面试场景还原

TL;DR 速记

图解

图 1：工具调用准确率的三维评估

图 2：工具调用错误的影响链

详细解析

为什么需要单独评估工具调用？

三维评估体系详解

维度 1：工具选择准确率（Tool Selection Accuracy）

维度 2：参数填写准确率（Parameter Filling Accuracy）

维度 3：调用时机准确率（Calling Timing Accuracy）

工具调用错误的类型与原因

数据采集与分析方法

提升工具调用准确率的策略

常见踩坑与反例

踩坑 1：只看任务成功率，忽视工具调用准确率

踩坑 2：工具描述写得模糊

踩坑 3：没有参数校验

踩坑 4：工具数量过多

踩坑 5：没有错误反馈机制

面试官可能继续追问

面试总结