先记住这个答案
默认值可能诱导模型在信息不足时直接调用工具而非澄清，使错误参数与错误意图混在一起。且默认值出现在 schema 中可能会改变模型对参数重要性的感知。应慎用默认值，必要时让模型明确请求或提供与 missing 不同的 sentinel 值以便区分。
- 默认值会掩盖用户未澄清的真实意图
- 默认值应只用于安全无歧义的后备
- 必要时用特殊值区分显式指定与缺省
默认值如何干扰模型决策路径
在工具调用的 schema 中声明 default 后，从模型视角看该参数成为可选。模型依据用户意图与描述决定是否填入；若省略，运行时自动采用默认值。这使模型有机会回避明确解析不完整请求的责任。例如查找天气工具中 unit 默认 celsius，当用户没指定单位，模型倾向于直接调用而不再追问，因为省略参数合法且看似合理。
更深一层，默认值不仅为不完整输入给出答案，更隐式传递了"缺省没问题"的信号。模型在权衡是否值得追问或猜测时，看到默认值往往降低预期收益，从而更频繁猜测。而这种猜测基于分布概率而非用户真实偏好，一旦用户实际期望其他值，调用结果就错得悄然无息——没有报错，只是在语义层面偏离，后续对话更难察觉与纠正。
会议纪要工具的时间默认值
设工具 create_meeting_summary，参数 timezone 默认 UTC，duration 默认 60 分钟。用户说"总结今天下午和某人的会议"，未给时区。模型看到默认值便省去时区字段，直接调用。若用户实际在上海，默认 UTC 导致纪要时间显示差 8 小时。而如果 schema 无默认值且该参数必填，模型会追问用户时区，或在可用模型能力不足时主动猜一个并显式传入，至少留下可审查的参数。
即使模型猜错，显式传参也便于在运行日志中复盘意图-参数链路。本例中正确的做法是将时区设为必填或者不设默认但提供常见值列表让模型选择；即便为了兼容历史也不能静默采用 UTC，而应通过 sentinel 标记未指定并回调澄清。默认值只应为无业务歧义的技术后备，如重试上限，通常不应承载业务决策。
默认值可安全使用的边界
当参数缺省会导致无法执行或安全风险时，不用默认值而要求必填，这是清晰边界。但现实中更微妙是语义中性默认：分页大小默认 10 没有业务偏见，但时区、语言、货币默认却有地域假设。是否安全取决于用户是否可从上下文推断。若工具调用是内部流水线步骤而非直接面向用户，有时可用带缓存的默认值以保通。
另一边界：即使设默认值，也应确保校验层不对显式传入的等价值做二次变更，避免默认值与允许值集合冲突。若需保留"未提供"与"恰好为默认"的区分，通常做法是 schema 不设 default，运行时把缺省字段映射为特殊标记处理，或增加布尔字段。代价是多一轮澄清或转换逻辑，但保护了意图透明度。
容易答错的地方
- 默认值能提升成功率
- 错误。默认值让调用不报错但结果可能语义错误，掩盖真实失败。成功率应指用户意图达成，而非工具无异常返回。案例中默认 UTC 的调用成功返回，但用户认为结果错误，这类失败被默认值吞掉。
- 只要把默认值写明在描述里就安全
- 模型不总阅读描述细节，且 schema 的 default 属性影响更直接。描述中的默认值可能被忽略或误读。即使模型看到，它也可能高估用户对默认值的了解。应把默认值视为最后后备，而非沟通信息。
面试官还会怎么问？
如何判断什么参数适合设默认值？
标准是：若省略该参数，执行结果对任何合理用户都无歧义或歧义可事后无损修复。例如日志级别 debug 不是用户决定，可默认。反之任何用户偏好依赖上下文的，如单位、语言、时区，通常应要求显式。
如果已经为兼容旧版设置了默认值，如何最小化伤害？
把默认值改为 sentinel（如 "__unset__"），运行时检测到 sentinel 则触发澄清流程。同时 schema description 说明该情况，并尽快更新客户端。很难有永久兼容，需为意图正确性牺牲一点平滑迁移。
默认值是否影响模型对参数冗余度的判断？
会。模型在有默认值时通常会省略该参数，因为省略是允许的且可减少输出内容。若默认已符合需求，它会省略；但当默认不符合概率较高时，错误反而增加。应以期望代价衡量：默认正确率高且错误代价低才可设。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。