工具调用走到今天：我们需要的不是更多函数，而是一个协议

如果你今年还在做 LLM 应用，大概率逃不开两个词：Agent、工具调用。

我见过最常见的“进度条幻觉”是：

接上函数调用
加几个工具（搜索、SQL、发工单、查监控）
让模型自己规划

然后就以为“Agent 诞生了”。

真实情况是：你得到了一堆脆弱的胶水代码——工具签名变了就炸、权限稍微复杂就绕不过去、工具多一点模型就乱点按钮。

这篇文章我想谈一个更朴素的结论：当工具多到一定规模，你需要的不是更多工具，而是一套协议与契约，让工具生态可插拔、可治理、可观测。

1. 工具调用的失败，往往不是模型不聪明

我们内部最早的工具集只有 3 个：

日志搜索
指标查询
配置对比

那时工具调用非常丝滑，模型像个熟练的 SRE。

后来工具慢慢涨到 20+：

发版系统
工单系统
权限系统
多集群配置
业务数据库

问题立刻变味：

你不知道模型“能不能”调用某个工具（权限、环境、租户）
你不知道模型“为什么”调用（动机与证据不可解释）
你不知道它“调用了什么”（参数、结果、重试、错误）

最烦的是，工具本身没错，模型也不傻，错的是连接方式：

我们把工具当成函数，把模型当成调用者；但当规模上来，它们更像服务，需要契约与治理。

2. 我们后来怎么做：把工具“产品化”

我最想强调的一点是：

工具不是 `def foo(x):`，工具是一个小产品

它至少要回答：

这个工具是干什么的（任务边界）
谁能用（权限与租户）
能用到什么程度（配额、速率限制）
失败怎么解释（错误语义）
输出怎么被消费（稳定 schema）

如果这些不清楚，模型会替你“补齐”，而模型补齐出来的东西通常就是事故的种子。

3. 我们写了一份“工具契约”，并强制执行

一份很实用的工具契约长这样（示例）：

name: log_search
purpose: "在指定时间范围内检索日志"
inputs:
  - name: query
    type: string
    required: true
  - name: time_range
    type: string
    required: true
    examples: ["last_15m", "2025-03-20T10:00:00Z..2025-03-20T10:30:00Z"]
outputs:
  schema:
    type: object
    properties:
      hits:
        type: array
        items:
          type: object
          properties:
            ts: {type: string}
            service: {type: string}
            message: {type: string}
errors:
  - code: PERMISSION_DENIED
    meaning: "无权限访问该租户日志"
  - code: INVALID_RANGE
    meaning: "时间范围非法"
limits:
  max_calls_per_request: 2
  timeout_ms: 1500
observability:
  log_fields: [request_id, tool_name, duration_ms, error_code]

注意我们在里面放了 limits 和 observability。

不是因为好看，而是因为生产里你最终会问：

为什么突然变慢？
为什么成本突然变贵？
为什么某个租户一直失败？

工具契约不解决一切，但它能让这些问题“可回答”。

4. 今年的热点：工具协议与可插拔生态

年初大家都在讨论“如何把更多外部能力接进模型”。我反而更在意另一件事：

当工具来源变得多样（内部服务/第三方/本地脚本），你怎么保证它们能被统一地发现、授权、调用、追踪？

我们做的策略是把工具调用抽成一层“网关”：

工具注册（metadata、版本、schema）
权限判定（租户、角色、配额）
调用记录（trace、重试、错误）
结果脱敏（PII、敏感字段）

flowchart LR
  A[LLM/Agent] --> B[Tool Gateway]
  B --> C1[内部服务]
  B --> C2[第三方API]
  B --> C3[本地脚本]
  B --> D[审计/指标/追踪]

这样做的好处很现实：

工具换实现不影响模型（只要契约不变）
权限/配额统一治理
观测统一，出了问题能追到“哪次调用、什么参数、什么错误”

这就是平台工程那套思路：先定接口与约束，再谈规模。

5. 反直觉经验：工具越多，模型越该“少做决定”

工具生态变复杂后，我们反而减少了模型的自由度：

让模型先输出意图（intent）和证据（evidence）
再由系统根据意图选择可用工具集合
最后才允许模型在集合内调用

这不是不信任模型，而是承认系统边界：

生产里的自由度，最终都会以事故的形式付费。

6. 你可以从这三步开始

给每个工具写一份契约：purpose/inputs/outputs/errors/limits/observability。
把工具调用统一走网关：授权、配额、脱敏、追踪不要散落在各处。
让模型少做“权限与资源”的决定：它做意图与推理，系统做选择与约束。

如果你做到了这些，Agent 才有可能从“能跑”变成“能用”。

琅琊苑