概述

工具使用能力的天花板，过去三年一直被归咎于模型。BFCL榜单、各家厂商的 strict mode、越来越大的参数量，把"调不准工具"当成一个推理问题来解。但 2026 年的两份关键证据把矛头调转了方向：一篇 arXiv 论文（2602.20426）指出，agent 性能"increasingly plateaus due to the quality of the tool interfaces these agents consume"——卡点不在脑子，在入口；CallSphere 的工程报告则量化了这个入口的代价，terse 描述相对精确描述要损失 30%+ 的参数准确率。换言之，工具描述（description、schema、example）就是模型理解工具的唯一接口，写法直接决定调用准确率。本文把这个被严重低估的环节拆成四式——极简式、契约式、示例式、重写式——逐一实测其准确率、上下文成本与可自动化程度，并给出按工具规模选型的落地方案。

四式对比

深度分析

一、天花板不在模型，在描述入口

把"工具调不准"归因于模型，是这一轮最昂贵的误判。arXiv 2602.20426（《Learning to Rewrite Tool Descriptions for Reliable LLM-Agent Tool Use》）的切入点很尖锐：工具描述本就是写给人类开发者看的，它容忍的歧义，agent 解不掉——尤其在候选工具数量上涨之后。论文把现有改进路径总结成两条死胡同：一是为每个新 API 重跑一条多阶段 pipeline（合成 query→跑 agent 收轨迹→标注→多次强模型提示），成本随目录线性膨胀；二是各工具独立优化，无法泛化到没见过的工具。结论是：与其继续堆模型能力，不如把"接口质量"本身当成一等公民来优化。这与 Gorilla、ToolAlpaca 的发现一致——精确描述比 terse 描述在参数准确率上高出 30%+。模型已经不是瓶颈，接口契约才是。

二、式一·极简式：softmax 被压平，18% 选错

最直觉的写法是"搜索网页""创建预约"这样一句话描述，省 token、省心力。代价藏在机制里。LLM 选工具的本质是：把用户 turn 与每条工具描述做相似度计算，过 softmax 取最大。当两条描述都含"creates an appointment"、只在细则里分叉时，softmax 分布被压平，模型有 10–20% 的概率拿错那一个。CallSphere 给出的实测是模糊描述导致约 18% 的选错率，而且这种错误不会被 strict mode 拦下——schema 合规、工具选错，是更隐蔽的失败。极简式只适合工具数小于 6、且彼此功能正交的窄栈（如 CallSphere 的 Salon 场景）。一旦工具之间出现功能重叠，极简式的准确率会断崖式下跌，这也是为什么几乎所有"工具破百即崩"的现象，第一层病灶都能追溯到描述撞车。

三、式二·契约式：六段模板冲到 96%

CallSphere 的解法是把描述写成一份面向"200ms 内从 14 个候选里挑对"的初级工程师的 API 文档，固定六段：动词开头的一行 purpose、显式触发条件的 when to use、消歧用的 when NOT to use、含类型/格式/正则/示例的 parameter contract、返回值 JSON 草图、以及两条示例（一条 happy path、一条 disambiguation）。实测在 14 工具的医疗栈上跨 GPT-4o/Claude/Gemini 达到 96% 的 function-arg 准确率。关键机制是 when NOT to use 这一段——它强制把两条描述在嵌入空间里推开，给模型一个"硬负样本"信号。模板落地是一个标准 JSON：

{
  "name": "book_appointment",
  "description": "Books a clinical appointment for an EXISTING patient.\n\nWHEN TO USE: caller confirmed a provider, ISO-8601 start_time, existing patient_id.\n\nWHEN NOT TO USE:\n- Caller unverified -> call lookup_patient first.\n- Provider unknown -> call list_providers first.\n- Time vague -> clarify first.\n\nEXAMPLES:\n1) book_appointment(patient_id='p_91', provider='dr_patel', start_time='2026-05-08T15:00-04:00')\n2) reschedule: cancel_appointment then book_appointment.",
  "parameters": {
    "type": "object", "additionalProperties": false,
    "required": ["patient_id","provider","start_time"],
    "properties": {
      "patient_id": {"type":"string","pattern":"^p_[a-z0-9]{2,}$","description":"From lookup_patient"},
      "start_time": {"type":"string","format":"date-time","description":"ISO-8601 with TZ offset"}
    }
  }
}

注意 pattern、format、additionalProperties:false 这些约束——它们把"契约"从自然语言下沉到 schema 层，strict mode 能在 API 层硬执行，是契约式能稳定到 96% 的另一半原因。

四、式三·示例式：3 个精选示例的小模型逆袭

当工具不变但输入多样时，契约式不够，得给模型看"在这个具体输入下该怎么调"。这就是 few-shot 示例式。LangChain 2024 年的两组实测给出了硬数据。在 Query Analysis（单次调用选检索源）任务上，Claude 3 Sonnet 从 16% 的零样本冲到 52%（3 条语义相似示例作为 messages）；在更 agentic 的 Multiverse Math（多步 ReAct）上，Claude 3 Haiku 从 11% 暴涨到 75%，仅凭 3 条示例就追平了 Claude 3.5 Sonnet 的零样本水平——小模型+示例可以匹敌大模型裸跑。三个反直觉结论值得记住：其一，3 条精选示例通常和全部 13 条一样好甚至更好，存在收益递减，别贪多；其二，动态按语义相似检索示例，远强于固定示例集；其三，示例作为 messages 注入，比拼成 string 塞进 system prompt 显著更好。示例式的成本是上下文随示例数线性增长，因此适合工具数中等（<15）、但输入空间复杂的场景。

五、式四·重写式：Trace-Free+ 的 150 工具规模战

前三式都是手工活，工具目录一旦涨到几十上百，人肉写契约和示例不可持续。式四是把它们自动化：离线学习并重写工具描述。arXiv 2602.20426 提出的 Trace-Free+ 用课程学习框架，把监督从"有轨迹"逐步迁移到"无轨迹"部署，让模型内化"什么样的描述才有效"的可复用模式，并配了一套从真实 API 合成高质量接口的数据管线。规模实验是真正的卖点：在 StableToolBench 上把候选工具扩到 150+ 时，Trace-Free+ 把准确率退化幅度压低了 29.23%，把 query 级平均成功率拉高了 60.89%，且跨域无需重训、可与 agent 微调叠加增益。它的意义在于回答了一个工程难题——目录扩张时不需要为每个新 API 重跑昂贵 pipeline。重写式的代价是前期基建（合成数据、课程训练），但它换来的是运行时零额外上下文成本，是大规模工具栈（20–150+）唯一可持续的路径。

六、描述体积甜区：80–250 token 的窄窗口

契约式和示例式都面临同一个约束：描述越长越准，但越长越挤上下文。CallSphere 给出的工程经验是一个80–250 token 的甜区——低于 50 token 会丢失消歧信息（退化成极简式的 18% 选错陷阱），高于 300 token 则开始挤占留给用户对话和工具结果的空间。这个窗口比直觉窄得多。优化手段有三：一是把"何时不用"这类消歧信息用最短的自然语言表达，必要时借助模型偏好的标签压缩（见下节）；二是用 schema 约束（enum/pattern/format）替代自然语言描述，把语义下沉到机器可校验的字段；三是对示例式启用动态检索，按当前 query 只注入 2–3 条最相关示例，而不是全量塞入。描述体积税和工具数量税是乘积关系——20 个工具各多 50 token，就是 1000 token 的固定开销，会直接吃掉长会话里的有效上下文。

七、模型差异：Claude 吃 few-shot、认标签、要 messages

四式没有"一招通吃"，因为它们的效果高度依赖具体模型。LangChain 实测显示 Claude 系列对 few-shot 的敏感度远高于 GPT 系列——Claude 3 Haiku 加示例能翻 6 倍，而 OpenAI 模型提升甚微甚至为零。格式上也有偏好：Claude 把示例作为 messages 注入效果最好，拼成 string 塞 system prompt 几乎无效（可能与 ChatML vs XML 格式差异有关）。CallSphere 进一步指出，Claude 额外受益于把 when NOT to use 段包进 <not_for> 标签——2026 年的旗舰模型被显式训练去解析带结构化标题的描述字段，"它们奖励你把描述当契约，惩罚模糊"。这意味着同一套工具描述，在 GPT-4o、Claude、Gemini 上的最优写法并不相同，跨厂商部署需要做模型相关的描述变体，而不是假设描述一次写好到处可用。

八、变现与训练营评估

工具描述工程是少数几个既有硬技术门槛、又能立刻产出可量化收益的切入点，非常适合包装成训练营或企业内训。可量化的卖点很扎实：契约式 +30% 参数准确率、示例式让小模型追平大模型（省 token 即省钱）、重写式在大规模目录上抑制退化。一套标准化产品应包含：契约式六段模板与 JSON 校验器、few-shot 示例库与动态检索器、按工具规模选式的决策树（<6 极简、<20 契约、<15+复杂输入示例、20–150+ 重写），以及一个 nightly 回归评测（CallSphere 的做法是对 37 个 agent、90+ 工具、115+ 表夜夜跑准确率）。门槛在于需要客户开放真实工具目录做评测，但这也正是壁垒——一旦绑定客户的工具栈做持续优化，迁移成本极高，是典型的咨询+订阅双轮模型。

工具描述如何决定调用：四式作用点

flowchart TD
    U["用户 turn"] --> EMB["嵌入 user turn"]
    EMB --> SIM["与每条工具描述算相似度"]
    D1["极简式描述<br/>(<50 token)"] -.压平分布.-> SIM
    D2["契约式描述<br/>含 when NOT to use"] -.推开嵌入空间.-> SIM
    D3["示例式描述<br/>2-3 动态示例"] -.注入 messages.-> CTX
    D4["重写式描述<br/>离线优化后注入"] -.零运行时成本.-> SIM
    SIM --> SOFT{"softmax 选工具"}
    SOFT -->|"模糊: 18% 选错"| WRONG["错误工具"]
    SOFT -->|"契约: 96% 选对"| PICK["正确工具"]
    CTX["system/messages 上下文"] --> PICK
    PICK --> ARGS["按 param 契约填参<br/>pattern/format/enum 校验"]
    ARGS --> CALL["strict mode 硬执行"]
    CALL --> RET["工具结果"]
    RET --> VERIFY{"结果消化"}
    VERIFY -->|"可疑"| EMB
    style WRONG fill:#f4cccc
    style PICK fill:#d9ead3
    style SIM fill:#fff2cc

四式分别作用在不同环节：极简式与契约式决定"相似度计算"那一关的分布形态；示例式作用在上下文注入；重写式作用在描述本身的离线质量。理解了作用点，就知道该在哪个环节下药——选错工具是描述问题（式一/二/四），填错参数是契约问题（式二），不调用是该用没用（when NOT 缺失），三者病灶不同，用药也不同。

推荐方案

• 工具数 <6 且功能正交：极简式即可，别过度工程。把精力放在参数 schema 的 enum/pattern 上。
• 工具数 6–20、有功能重叠：上契约式六段模板，必写 when NOT to use，配 strict mode 把契约下沉到 schema。这是性价比最高的一档，96% 准确率的甜区。
• 工具数 <15 但输入空间复杂（如多检索源、多租户）：在契约式基础上叠加示例式，用动态语义检索注入 2–3 条示例，小模型可追平大模型零样本。
• 工具数 20–150+、目录持续扩张：上重写式（Trace-Free+ 思路），离线优化描述、运行时零成本，配 nightly 回归评测守住准确率不随规模退化。
• 跨厂商部署：为每个目标模型准备描述变体——Claude 用 <not_for> 标签 + messages 注入示例；GPT 系列不必强求 few-shot；Gemini 走契约式中性写法。
• 避坑：描述长度锁死 80–250 token，低于 50 退化为 18% 选错陷阱，高于 300 开始吃有效上下文；永远不要在两条工具间复用同一段描述。

把模型当引擎，把描述当唯一接口——引擎再强，接口写得模糊，softmax 照样把车开进沟里。工具使用能力的下一个 10% 提升，不在更大的模型，在更诚实的描述。

参考来源

1. Tool Description Templates LLMs Reliably Call (2026) — CallSphere — 量化 terse 描述损失 30%+ 参数准确率，给出契约式六段模板与 96% 实测、80–250 token 甜区。
2. Learning to Rewrite Tool Descriptions for Reliable LLM-Agent Tool Use (arXiv 2602.20426) — Trace-Free+ 框架，150+ 工具规模实验中准确率退化 −29.23%、成功率 +60.89%（StableToolBench）。
3. Few-shot prompting to improve tool-calling performance — LangChain — Claude 3 Sonnet 16%→52%、Claude 3 Haiku 11%→75%，messages 优于 string、3 例≈13 例等实测结论。
4. Berkeley Function Calling Leaderboard (BFCL) — 工具调用能力权威基准，提供 native vs prompt 模式与多场景准确率横评。
5. LLM Tool Specifications and Descriptions — apxml — 工具规范与描述的工程化写法指南，含参数契约与示例组织。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。