当模型开始调用工具：AI 应用的中间层

过去我们评价一个模型，主要看它“答得好不好”。现在，越来越多的人开始看它“能不能把事做完”。这是一个不小的转变。回答问题只需要语言能力，完成任务却需要调用搜索、数据库、代码执行、支付接口，甚至需要在一个失败之后重新规划。

当模型开始调用工具，应用架构就多出了一个中间层。它不直接面向用户，也不直接训练模型，却决定了整个系统是否可靠。这个中间层，正在成为 AI 应用竞争的关键。

一、从“回答问题”到“完成任务”

一个聊天机器人可以告诉你如何订机票，但它不能替你订。一个 Agent 可以查询航班、比较价格、填写乘机人信息、处理支付失败，最后把确认短信发给你。前者输出的是文本，后者输出的是结果。

这个变化带来的第一个问题是：模型如何知道有哪些工具可用？第二个问题是：模型如何知道什么时候该用哪个工具？第三个问题是：工具调用失败之后，模型如何恢复？

这三个问题看起来是技术细节，实际上决定了产品的边界。一个只能调用一个工具的 Agent，和一个能协调十几个工具、处理权限与冲突的 Agent，是完全不同的产品。

图 1 · 工具调用的基本循环。真正的复杂度藏在失败、重试与权限判断里。

二、中间层到底在做什么

我倾向于把中间层拆成四件事：工具注册、上下文管理、执行控制、结果评估。

能力	解决的问题	失败时的表现
工具注册	模型知道有什么可用	模型凭空编造接口
上下文管理	模型知道该带什么信息	上下文过长或关键信息丢失
执行控制	调用顺序、权限、重试	重复调用、越权、死循环
结果评估	判断任务是否完成	模型自认为完成，实际没有

这四件事里，最容易低估的是“结果评估”。很多演示能跑通，是因为演示者知道任务应该在哪里结束；真实用户不知道，模型也不知道。如果没有一个独立的评估环节，Agent 很容易在“看起来完成了”的地方停下来。

一个常见的做法，是让模型输出结构化的状态，再由程序判断是否满足完成条件。比如订票任务，不能只看模型说“已订好”，还要检查订单号、支付状态和行程单。模型的自我报告只能作为线索，不能作为证据。

三、可靠性比聪明更难

在工具调用里，可靠性往往比智能更重要。一个不够聪明但行为稳定的 Agent，通常比一个偶尔惊艳但经常越权的 Agent 更有用。

工具描述就是一个例子。下面这段 JSON 是一个简化后的工具声明。它看起来只是元数据，实际上决定了模型会不会误用这个工具。

{
  "name": "create_refund",
  "description": "为已支付的订单创建退款申请。仅在用户明确要求退款且订单状态为 paid 时调用。",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "订单号，格式为 GW- 开头的 12 位字符串"
      },
      "reason": {
        "type": "string",
        "enum": ["duplicate", "damaged", "not_received", "other"],
        "description": "退款原因"
      }
    },
    "required": ["order_id", "reason"]
  }
}

这段声明里，至少有三个防误用的设计：描述里写明了调用条件；参数使用枚举而不是自由文本；订单号有格式约束。它们不能保证 100% 正确，但能显著降低模型“想当然”的概率。

除了工具描述，还需要超时、幂等、重试上限和人工接管。一个支付接口被重复调用两次，可能造成真实损失；一个搜索接口超时后无限重试，可能拖垮整个任务。这些都不是模型能力问题，而是工程问题。

四、谁来拥有中间层

中间层的位置很微妙。模型厂商可以做，云厂商可以做，应用公司也可以做。谁来做，取决于谁最接近具体的业务流程。

模型厂商的优势是理解模型的行为，能做出更原生的工具调用协议；云厂商的优势是基础设施和权限体系；应用公司的优势是知道业务里的例外情况，知道哪些步骤不能自动化。

短期内，三者会同时存在。长期看，中间层可能会像今天的支付网关或身份认证一样，变成一种标准化的基础设施。到那时，竞争的重点不再是“能不能调用工具”，而是“能不能在出错时安全地恢复”。

这也是为什么我最近更关注那些不性感的指标：任务成功率、平均恢复时间、越权调用率、人工接管率。它们不像模型榜单那样引人注目，却更接近真实的生产力。

结语

模型调用工具，看起来只是多了一个 API。但它改变了软件的形态：从“人操作界面”，变成“人描述目标，模型编排步骤”。中间层就是这场变化的脚手架。

脚手架不会出现在最终的建筑照片里，但它决定了建筑能不能站稳。下一次看到一个 Agent 演示，不妨多问一句：工具失败了呢？权限怎么控制？谁来判定任务真的完成了？这些问题的答案，比演示本身更能说明问题。