先记住这个答案
缺省参数必须能被安全推断。如果模型依据上下文和描述能可靠补全，且错误代价低，可设为可选；若缺失会导致执行失败或产生不可变副作用，必须设为必填并要求模型补问或终止。同时要意识到，设必填也可能促使能力较弱的模型编造值，所以描述要明确缺失时的处理策略。
- 判据：缺失时能否安全推断
- 不能安全推断就必填并让模型补问
- 必填也可能诱发模型编造值
机制：从模型补全到服务端兜底的双向约束
工具 schema 的 required 不仅约束模型输出格式，其实是在表达“服务端对该参数存在确定性的依赖”。当参数被标记为必填，API 不会强制校验，模型仍可能缺省或编造；当为可选，运行时必须容忍缺失，否则模型一旦漏传就会中断。因此判据本质是：该参数的值能否仅凭上下文或描述安全推断出来。
能被安全推断取决于两个条件：一是模型可从对话历史、工具描述或其他参数推导出唯一合理值；二是推断错误的后果有限，例如查询语言默认设 en 不会引发不可逆动作。若两个条件不成立，就该设为必填，并要求模型在用户未提供时主动澄清，而不是自行猜测。
场景：天气接口的位置参数如何取舍
设一个 get_weather 工具，参数有 location、unit。当用户问“今天天气怎么样”而未给出位置时，若从对话历史能明确得知位置，模型可准确推断；若没有任何线索，模型可能猜测（官方示例曾猜成纽约），而非追问。此时 location 虽语义上必填，但能否设为可选取决于推断的可靠性。若设为必填，模型在缺失时更容易询问；若为可选，模型可能直接猜测。
因此当推断依赖用户输入中的隐含信息时，更稳妥的做法是设为必填，并在描述中指明若用户未给位置应先询问。这迫使模型走澄清路径，而不是冒险猜测。当然，若产品允许使用默认城市或靠 IP 定位，则可改为可选，但要承担猜错导致的错误结果。
边界：模型能力差异与工具语义
该判据在多步推理或低能力模型下容易失效。更强模型（如 Opus）更倾向识别缺失并询问，而能力较弱的模型（如 Sonnet）可能“合理地”编一个值继续执行。此时即使从机制上可推断，也不能保证安全，所以对高影响参数应必填并做服务端校验，防住幻觉值。
另一个易混淆点是可选参数与默认值的关系。可选不代表可无条件省略，有的可选参数依赖另一参数的取值，比如 sort_order 仅在 sort_by 非空时有意义。这类条件可选应写清楚依赖，服务端对缺省后的组合做二次校验；若缺省会进入无意义的中间态，不如将其并入同一必填组或拆开。
容易答错的地方
- 把语义必填当成 schema 必填
- 有人认为“调用必须有 location”就该写在
required里。但若模型总是能从对话明确提取到该值，设为可选反而减少失败；关键在“可推断”，而非语义必需。反例：分页page语义可缺但缺省默认第 1 页，可选才合理。 - 以为必填能完全阻止模型编造
- 设了
required并不保证模型一定填真实值。当用户信息不足，模型可能虚构一个看似合理值（如默认城市）。因此不能只靠 schema，还要服务端校验合法性，并在描述中给出“缺失请询问”的指引。
面试官还会怎么问？
必填参数漏传时，应该报错还是让模型补充？
取决于业务容错与模型重试成本。若工具无副作用或可安全重试，且模型能通过反馈快速修正，可返回结构化错误再让模型补一次；若执行已产生不可逆代价或重试成本高，则应先由服务端校验拦截，要求用户侧澄清。
可选参数在模型省略时，服务端应该用默认值还是跳过？
两种都常见：有默认值且语义合理就用默认；没有默认则跳过并采用“不传即不处理”的语义。关键是 schema 的 description 必须写明默认行为，否则模型以为自己传了而服务端用另一套默认，结果不一致。
工具升级时，如何把可选参数改为必填而尽量不影响存量调用？
先灰度：保留可选并在 description 强调新行为，运行期统计漏传率；同时让服务端对缺省返回可读错误，促使模型迭代。一段时间后再切必填，并在版本变更文档里给出迁移周期。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。