瞬维AI把Agent工具调用准确率从60%提到95%的四个土办法

2026-10-16 13:10 0 阅读

生产环境的真实困境

做AI Agent的人，演示时都很光鲜：问天气能查天气，问订单能查订单，问啥答啥。但真部署到生产环境，问题就来了——Agent经常乱调工具。

用户想查订单，它调了发邮件的工具；用户想订会议室，它给你查天气。我们刚开始落地的时候，工具调用准确率只有60%，意味着每10次调用就有4次出错，根本没法给用户用。

后来花了三个月，把准确率提到了95%。不是什么高深算法，就是四个工程上的土办法，一个一个往上叠。

第一招：工具描述要写"什么时候别用"

大部分人写工具描述，只写这工具是干嘛的：

"这是一个查询用户订单的工具，输入用户ID和订单号就能返回订单信息。"

这样写完全不够。大模型看到"订单"两个字，所有跟订单沾边的问题都想往这工具上套。用户问"这个商品多少钱"，它也去调订单查询；用户问"物流政策是什么"，它还是去调订单查询。

关键改动：在描述里加负向约束，写清楚什么时候不能用。

优化后的描述变成这样：

"查询用户订单信息，输入用户ID和订单号返回订单状态。注意：不要用本工具查询产品价格、物流政策，这些问题属于产品知识库范围，请调用知识库查询工具；如果用户没有提供订单号，不要调用本工具，先向用户询问订单号。"

就加了这几句话，准确率直接涨了25%。大模型知道了边界在哪，不会什么题都往一个工具上硬套。

代码层面的对比很明显。优化前的JSON Schema只有功能描述：

{
  "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"]
  }
}

背后的道理很简单：大模型做工具选择是个分类问题，只给正例它容易过拟合，给了负例才知道哪些样本要排除。这跟训练分类器是一个逻辑，只是换了个形式写在提示词里。

第二招：工具别拆太细，能合并就合并

很多人设计工具有个误区，觉得颗粒度越细越好。查订单是一个工具、改订单是一个工具、取消订单是一个工具，恨不得每个操作都独立出来。

我们最开始也是这么干的，订单相关就拆了3个工具，整个系统12个工具。结果准确率很差，大模型经常在"查/改/取消"之间选错。

问题根源：工具越多，候选空间越大，选错的概率越高。

后来把订单相关的三个操作合并成一个order_operation工具，通过action参数区分具体操作。工具总数从12个砍到6个，准确率涨了18%。

合并前的Schema是三个独立工具：

[
  {
    "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"]
    }
  }
]

合并后变成一个统一入口：

[
  {
    "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"]
    }
  }
]