考察点
这道题区分「接过现成 API」和「自己设计过工具」的候选人。面试官想听你讲 schema 每个字段对模型行为的影响，而不是背 JSON Schema 语法。追问方向：工具拆细还是合并、参数太多怎么办、schema 改了线上会有什么影响。
参考答案
schema 是写给模型的 Prompt
先建立一个认知：tool schema 不是给编译器的接口声明，是模型决策的依据。模型看不到你的代码注释和文档，它对这个工具的全部认知就是 name、description、parameters 这三块。设计 schema 的本质是写一段高密度的 Prompt。
具体设计要点
name 用动词短语：search_orders 比 order_api 好，cancel_order 比 order_manage 好。模型选工具时首先匹配的是语义，名字含糊的工具要么被忽略要么被乱调。命名空间冲突时加前缀，比如 crm__create_ticket。
参数强类型 + 枚举收敛：每个参数都写明 type，能用 enum 收敛的取值绝不留成自由字符串。比如 status 枚举 ["pending", "paid", "shipped"]，比让模型自己猜「已支付」该传什么字符串靠谱得多。日期格式在 description 里写死 YYYY-MM-DD，不然模型今天传 ISO、明天传中文。
required 最小化，可选参数给默认值语义：必填参数越少，模型构造调用的失败率越低。能缺省的就别放进 required，并在参数描述里说明「不传默认查最近 7 天」。
参数数量控制：经验上单个工具参数超过七八个，模型的填参准确率会明显下降。参数多往往意味着工具粒度不对，该拆。
拆分还是合并
判断标准是看调用模式而不是看业务归属。如果两个操作 90% 的场景是连着调的，合并成一个工具有利于减少轮次；如果一个工具内部有 action 参数决定行为（create/update/delete 一把抓），模型选错 action 的概率很高，这种「瑞士军刀式」工具要拆成原子工具。我们项目里的经验：原子工具 + 少量高频组合工具，比纯粹的原子集合调用轮次少、错误率也更低。
返回值也要设计
很多人只管入参不管出参。工具返回给模型的内容直接进上下文：返回要精简，去掉模型用不到的字段；错误要返回可读的错误说明而不是裸堆栈，模型能根据「订单不存在，请确认订单号」自我纠正，但看不懂 NullPointerException。大结果集要截断或分页，一次返回几百行 JSON 会把上下文撑爆。
迭代纪律
schema 上线后改动要当接口变更对待：改 description、加参数都可能改变模型行为，需要回归测试一批典型用例再放量。
可能的追问
- 怎么验证 schema 设计得好不好？ 准备一批覆盖边界 case 的评测集，看工具选择准确率、参数填充准确率两个指标；线上再监控无效调用率和模型自我纠正次数。
- 几十个工具全塞给模型会有什么问题？ 上下文成本暴涨，且工具之间语义重叠会让选择准确率下降。解法是先做一层工具检索（按用户 query 语义召回 top-K），只把候选工具喂给模型。
- schema 里能写 few-shot 吗？ 可以在 description 或参数说明里嵌简短的调用示例，对参数复杂的工具效果明显，但要控制长度，示例是每次都进上下文的。