工具的 Schema 和描述怎么写？模型才不容易调错参数

先这样答

模型选工具、填参数，依据只有注册时给的三样文本：名称、描述、参数 Schema。所以调用准确率的上限在这三样怎么写。名称用动词短语直接说动作，比如查订单状态就叫 search_order_status，不要叫 handle_order 这种看不出行为的名字。描述一句话说清三件事：干什么、什么情况该用、什么情况不该用，把边界写出来（「仅查询物流状态，不含退款改址」这种否定边界很关键）。参数设计上，能少则少、必填标清楚、类型和格式写死，日期给格式样例，选项固定就用枚举，自由字符串越少模型越没机会编。

一个实用的自查方法：把工具列表遮住实现只看 Schema，问自己「一个没见过系统的人能不能只靠这些文字选对工具、填对参数」。模型的能力和人读文档的能力在这方面是接近的，文档写得含糊，谁都调不对。

给面试官收尾：工具调用不准时，排查顺序应该是先改 Schema 和描述，再看提示词，最后才考虑微调。Schema 本质上就是提示词的一部分，改动也要走同一套评测集回归，不能凭感觉上线。

面试官会怎么追问

• 「描述里要不要放示例？」 参数格式复杂的要放，一个正确示例胜过一段格式说明，比如日期、嵌套结构。但示例也是文本，放太多会挤占上下文还互相干扰，每类格式一个精简正例就够。
• 「工具上百个，描述太长撑爆上下文怎么办？」 分层注册：第一层只给工具目录的摘要（类别、一句话用途），模型先选类别，运行时再把该类工具的完整 Schema 加载进上下文。这和工具路由是同一套思路，只是把路由决策交给模型本身。
• 「Schema 改了之后怎么保证不退步？」 Schema 改动要当提示词改动管理：同一套工具调用评测集，改前改后各跑一遍，看选择准确率和参数填对率。只改描述一句话也可能改变模型的工具偏好，必须有回归。

回答的坑

• 把描述写成实现文档，塞满内部字段和错误码。模型需要的是「什么时候该用我」，不是「我是怎么实现的」，实现细节对调用没有帮助还稀释关键信息。
• 参数设计照搬后端接口，一口气暴露十几个可选参数。后端接口是给程序调的，直接暴露会让模型在可选参数里猜，应该做一层面向任务的薄封装，只留模型真正需要填的输入。