企业官网建设流程全解析

1296

问题几乎不在模型，而在工具本身。这篇把「工具调用」这件事从底层拆开讲：模型是怎么选工具的、什么情况下会选错、一个合格的工具有哪些硬指标。

一、模型是怎么"看见"你的工具的

每轮对话开始，宿主会把所有可用工具的名称、描述、参数 schema一起塞进上下文。模型据此决定调不调、调哪个、传什么参数。

这带来三个直接推论：

1. 描述就是接口。描述写得含糊（“查询数据”），模型不会调它；写得具体（“查询指定城市当日天气，参数 city 为中文城市名”），命中率立刻上升。
2. 参数说明决定成败。参数没说类型、没说必填，模型就会传空值或传错类型，然后工具报错。
3. 工具越多，成本越高。一万个工具的 schema 会占掉大量 token，模型还在候选里挑花眼。

所以**「工具数量」是负债，不是资产**。

二、一个合格工具的五个硬指标

第 5 条最容易被忽略。Agent 是自动执行的，一个读不懂的错误信息，会让它反复重试同一个错误调用——这就是很多"Agent 陷入死循环"的真实原因。

三、渐进式披露：让 Agent 不被工具淹没

工程上成熟的解法是渐进式披露（progressive disclosure）：

1. 首屏只暴露几十个高频工具；
2. 模型需要别的能力时，通过一个「检索工具」去搜；
3. 检索到之后再展开其完整 schema。

好处很直接：上下文可控（token 省下来了）、候选集小（选错率下降）、列表不炸（客户端不卡）。

代价是设计要求变高：你得判断哪些工具属于"高频"，还得把检索做准。

判断一个工具源是否成熟，看它有没有做这件事就够了——一次性暴露上万个工具的平台，基本没考虑过 Agent 的实际运行环境。

四、计费设计会反向影响 Agent 的行为

这点很少有人提，但很关键。

如果平台"调用即扣费、失败也扣"，那么：

• 开发者会倾向于少调、慎调，Agent 的能力被浪费；
• 一旦参数校验不严，模型误调一次，用户就白白损失积分；
• 用户对平台的信任会快速下降。

合理的规则是：参数不全不执行、结果异常判失败、失败不计费。这不是慷慨，而是让开发者敢于放手让 Agent 试错——试错成本低，Agent 才可能真正跑起来。

选择工具服务时，我会把这一条放在价格前面。

五、一个真实案例的拆解

以一个中文远程 MCP 服务（万机阁，端点在qianjige.app.workbuddy.host/mcp）的做法为例，对照上面的标准看它做对了什么：

• 渐进式披露：首页只暴露三十来个精选工具，其余按需检索；
• 必填参数拦截：schema.required缺参数直接返回错误说明，不执行、不扣费；
• 结果校验：返回内容里出现NaN/undefined视为失败，不计费；
• 类目划分：位置天气出行 / 金融 / 媒体 / 搜索 / 计算等，方便按需取用。

它并不完美——需要操作本机文件的任务它做不了（远程服务碰不到磁盘），这类需求只能用本地 stdio 服务。但在"给 Agent 补中文实时数据能力"这件事上，路径确实比自建短得多。

六、给搭 Agent 的人的四条实操建议

1. 先定任务，再选工具。从"Agent 要完成什么"倒推需要哪些能力，而不是先接一堆工具再想怎么用。
2. 工具描述当文档写。每加一个工具，先问：模型只看这段描述，能不能正确判断该不该用。
3. 必填参数必须拦在工具侧。不要指望模型每次都传全。
4. 接完做一次「压力测试」。故意传空值、传错类型、传不存在的地名，看它返回什么、扣不扣费。

这四条做完，Agent 的可用性通常会有明显提升，而且跟换不换模型没关系。

小结

• 模型选工具只靠描述和 schema，这两样就是你的产品质量；
• 数量是负债，要做渐进式披露；
• 失败计费与否决定了 Agent 敢不敢用；
• 选工具源时，先测「调不通会不会扣分」，再看价格。

Agent 的能力上限，很多时候不是模型决定的，是你给它的工具决定的。

如果这篇文章帮你解决了一个具体问题，欢迎留言交流。

万机阁 MCP 工具市场（一个 MCP，一万种本事） https://qianjige.app.workbuddy.host/ ｜