智能体面对一排工具，凭什么知道每个工具能干什么、参数怎么填？靠的是一份函数的 schema——工具自带的说明书。没有这份说明书，大模型面对工具就像面对一排没贴标签的开关，只能瞎按。
说明书上都写了什么
一份典型的 schema 通常包含三块内容：功能描述，用一两句话告诉模型这个工具是干什么的；参数清单，列出每个参数的名字、类型、是否必填；以及取值约束，比如字符串长度、数字范围。模型读的就是这些文字，读完才决定何时调用、怎么填参。
三块内容各管一段，模型读的时候是分开用的：
| 组成 | 里面写什么 | 模型据此定什么 |
|---|---|---|
| 功能描述 | 一两句话说明这个工具是干什么的 | 该不该用这个工具、何时调用 |
| 参数清单 | 每个参数的名字、类型、是否必填 | 这一次要填哪几栏、各填什么类型 |
| 取值约束 | 字符串长度、数字范围这类边界 | 填进去的值合不合格 |
描述写得越清楚，模型用得越准。同样的工具，描述从「发送消息」改成「向指定手机号发送短信验证码，号码须为大陆 11 位」，调用的准确率会明显不同。豆包的插件接入和通义千问的工具扩展，背后都依赖这种结构化声明来衔接模型与外部能力。
生活类比：家电附带的说明书
新买的洗衣机附带一本说明书，写明有哪些模式、转钮怎么拧、什么衣物不能洗。schema 就是工具的这本说明书，Agent 每次干活前都会翻一遍，照着上面的说明填表、按顺序操作。
但说明书也有比方不到的地方。家电说明书你很少重读，schema 却在每一次调用前都要被模型重新读入；说明书写错了顶多浪费一次洗衣，schema 写含糊了，模型会持续、稳定地填错参数，错法都一模一样。
怎么读一份 schema
不用会写代码，也能看懂 schema 的关键信息：
- 先看功能描述：它解决什么问题、适用什么场景，判断该不该用这个工具。
- 再看必填参数：有哪些栏位必须填，类型是什么，取值有没有范围限制。
- 最后看示例：很多 schema 附带填写范例，照着范例的结构理解最省力。
对照表：
- schema：静态说明书，写一次用很久，回答「这工具有哪些栏位」。
- 参数：动态填入的值，每次调用都不同，回答「这一次具体填什么」。
分不清这两者，排查调用错误时就会找错方向。
工具怎么被规划选中，要看任务规划；每次往说明书栏位里填的值，就是工具调用的参数；调用后返回的东西如何进入上下文，可以读观察结果；工具一直跑不完怎么办，还有一篇最大步数限制可以接上。
schema 还有一个容易被忽略的作用：它是平台之间迁移工具的通用语言。把一个工具从 A 平台搬到 B 平台，代码逻辑未必通用，但 schema 的思路是相通的——功能描述加参数清单加取值约束。看懂了这个结构，换个平台不过是换一种格式把同样的内容重写一遍，上手成本远比从零学低。这也是为什么建议每接入一个新工具都亲手读一遍它的 schema——读的过程，就是在建立对工具边界的准确预期。
把 schema 当成验收标准来抠字眼并不夸张——描述里每一个含糊的词，最后都会变成模型执行时的随机性。写清楚，是用好工具的第一步。说到底，schema 不是文档，而是模型与工具之间的接口约定。下次发现工具总被用错，先别急着怀疑模型，回头重写这份说明书——多数时候，问题出在说明书上。
换个问法再问函数的 schema 三句
- 改了 schema 之后为什么模型立刻会用错？：因为说明书是模型判断的唯一依据。参数名改了、描述改了，模型读到的世界就变了，调用行为随之改变。
- 描述写长一点好还是短一点好？：以够用为准。关键信息一个不缺，废话一句不写。太短模型靠猜，太长浪费上下文还容易互相打架。
- 同一个工具在不同平台说明书写法一样吗？：大方向一致，细节格式可能不同。迁移工具时以目标平台的格式规范为准，逐项核对。
