瞬维AI落地经验：AI Agent工具调用准确率怎么提

TL;DR（太长不看）： 本文分享我们把 AI Agent 工具调用准确率从 60% 提到 95% 的四个核心方法：①工具描述写清楚「什么时候不要用」，加负向约束；②合并工具减少候选，别拆太细；③调用前加一层参数校验兜底；④持续收集错例迭代优化。四个方法叠加，准确率稳步爬升到 95%。

现在做 AI Agent，大家都在讲工具调用：Agent 能查天气、能查数据库、能调用 API 帮用户完成任务。但真到生产环境，你会发现 Agent 经常调错工具：用户想查订单，它却给你调用发邮件的工具；用户想订会议室，它却给你调用查天气的工具，根本没法用。

我们在落地 Agent 系统的时候，把工具调用的准确率从一开始的 60% 提到了 95%，总结了几个确实有效的优化方法。

第一个方法：工具描述写清楚"什么时候不要用这个工具"

很多人给工具写描述，只写这个工具是干嘛的："这是一个查询用户订单的工具，输入用户 ID 和订单号就能返回订单信息"。

这样写的描述根本不够，大模型看到这个描述，碰到和订单相关的问题就会乱调。你必须在工具描述里写清楚这个工具什么时候不能用 ：

比如订单查询工具的描述里加上："不要用这个工具查询产品价格、物流政策，这些问题属于产品知识库范围，请调用知识库查询工具；如果用户没有提供订单号，不要调用本工具，先向用户询问订单号。"

就加了这几句，工具调用的准确率直接涨了 25%------大模型知道了什么情况不该用这个工具，就不会乱调了。

下面用代码对比「优化前的工具描述」与「优化后的工具描述」的差异：

优化前的描述（只写工具是干嘛的，容易乱调）：

{
  "name": "query_order",
  "description": "这是一个查询用户订单的工具，输入用户 ID 和订单号就能返回订单信息",
  "parameters": {
    "type": "object",
    "properties": {
      "user_id": { "type": "string", "description": "用户 ID" },
      "order_id": { "type": "string", "description": "订单号" }
    },
    "required": ["user_id", "order_id"]
  }
}

优化后的描述（写清楚什么时候不能用，选错概率大降）：

{
  "name": "query_order",
  "description": "查询用户订单信息，输入用户 ID 和订单号返回订单状态。注意：不要用本工具查询产品价格、物流政策，这些问题属于产品知识库范围，请调用知识库查询工具；如果用户没有提供订单号，不要调用本工具，先向用户询问订单号。",
  "parameters": {
    "type": "object",
    "properties": {
      "user_id": { "type": "string", "description": "用户 ID" },
      "order_id": { "type": "string", "description": "订单号" }
    },
    "required": ["user_id", "order_id"]
  }
}

为什么优化后的描述能提升准确率？ 优化前的描述只告诉大模型「这个工具能做什么」，大模型碰到和订单沾边的问题就会乱调------比如用户问「这个商品多少钱」，它也可能去调订单查询工具。优化后的描述明确划出了「边界」：哪些问题不属于 这个工具（产品价格、物流政策），以及什么情况下不要调用（没给订单号时先反问用户）。大模型有了明确的「负向约束」，就不会再往这个工具上硬套无关问题，这正是正文里「准确率直接涨了 25%」的底层原因。

第二个方法：工具不要拆太细

很多人做工具设计的时候，恨不得把每个操作拆成一个独立工具：查订单是一个工具、改订单是一个工具、取消订单是一个工具，拆十几个工具给 Agent 用。

工具越多，大模型选错的概率越高------工具列表太长，大模型看混了，很容易点错。我们之前把订单相关的三个操作拆成三个独立工具，准确率特别低，后来把三个操作合并成一个订单操作工具，通过参数区分是查、改还是取消，工具总数从 12 个砍到 6 个，准确率直接涨了 18%。

别迷信工具颗粒度越细越好，对 Agent 来说，工具越少，选对的概率越高。

下面用表格对比「工具拆太细」与「合并工具」两种方案的差异：

对比维度	工具拆太细	合并工具
工具数量	12 个独立工具	6 个合并工具
准确率	较低（选错概率高）	提升 18%
维护成本	高（每个工具都要写描述、维护参数）	低（统一入口，按参数区分操作）

下面用代码对比「拆成 3 个独立工具」与「合并成 1 个订单操作工具」的 JSON Schema 差异：

拆成 3 个独立工具（工具多，选错概率高）：

[
  {
    "name": "query_order",
    "description": "查询订单信息，输入用户 ID 和订单号返回订单状态",
    "parameters": {
      "type": "object",
      "properties": {
        "user_id": { "type": "string", "description": "用户 ID" },
        "order_id": { "type": "string", "description": "订单号" }
      },
      "required": ["user_id", "order_id"]
    }
  },
  {
    "name": "update_order",
    "description": "修改订单信息，如改收货地址、改数量",
    "parameters": {
      "type": "object",
      "properties": {
        "order_id": { "type": "string", "description": "订单号" },
        "address": { "type": "string", "description": "新的收货地址" },
        "quantity": { "type": "integer", "description": "新的商品数量" }
      },
      "required": ["order_id"]
    }
  },
  {
    "name": "cancel_order",
    "description": "取消订单",
    "parameters": {
      "type": "object",
      "properties": {
        "order_id": { "type": "string", "description": "订单号" },
        "reason": { "type": "string", "description": "取消原因" }
      },
      "required": ["order_id"]
    }
  }
]

合并成 1 个订单操作工具（工具少，选对概率高）：

[
  {
    "name": "order_operation",
    "description": "对订单执行统一操作，通过 action 参数区分是查询、修改还是取消",
    "parameters": {
      "type": "object",
      "properties": {
        "action": {
          "type": "string",
          "enum": ["query", "update", "cancel"],
          "description": "要执行的操作：query 查询、update 修改、cancel 取消"
        },
        "order_id": { "type": "string", "description": "订单号" },
        "user_id": { "type": "string", "description": "用户 ID（query 时必填）" },
        "address": { "type": "string", "description": "新的收货地址（update 时使用）" },
        "quantity": { "type": "integer", "description": "新的商品数量（update 时使用）" },
        "reason": { "type": "string", "description": "取消原因（cancel 时使用）" }
      },
      "required": ["action", "order_id"]
    }
  }
]

为什么合并后准确率更高？ 工具列表从 3 个缩到 1 个，大模型在选工具时不再需要在「查订单 / 改订单 / 取消订单」之间纠结，只需选对 order_operation 这一个入口，再通过 action 参数表达具体意图。工具越少，候选越少，选错的概率就越低------这正是正文里「工具总数从 12 个砍到 6 个，准确率涨 18%」的底层原因。

第三个方法：加一层调用前校验

大模型选好工具、填好参数之后，不要直接执行，先加一层校验逻辑：

1. 这个工具是用户当前问题真的需要的吗？
2. 填的参数有没有缺失？格式对不对？
   比如用户问"我订单现在到哪了"，大模型选了订单查询工具，但没填订单号，这时候不要执行调用，反过来问用户"麻烦提供一下你的订单号，我帮你查一下物流进度"。
   就这一层校验，能挡住 20% 的错误调用------很多时候大模型选的工具是对的，但是参数填错了或者漏了，你直接执行就出错，加个校验兜个底，准确率立马上去。## 第四个方法：错例持续迭代

和做意图识别一样，工具调用准确率也不是写完提示词就完事的。你把所有调错工具的 case 收集起来，分析错在哪里：是工具描述写得不清楚？还是工具拆得太细？还是大模型理解错了用户意图？

把这些错例补到提示词里，每个月迭代一次，准确率会慢慢往上涨。我们一开始准确率只有 60%，就是靠持续收集错例、优化工具描述和提示词，三个月时间慢慢提到了 95%。

写在最后

Agent的工具调用看起来是大模型的天生能力，但真到生产环境，准确率真不是开箱就高的。从工具设计、描述写作到校验兜底，每一步都得做工程优化，不然你的Agent就是个乱点工具的玩具，根本没法真正帮用户干活。

本文为技术实践分享，不构成任何商业建议。