为什么今天学这个
昨天跑通了 Function Calling 循环。今天处理循环里的下一处薄弱点：模型怎样知道参数该填什么。Tool Schema 用 JSON Schema 描述类型、必填项、枚举和范围；工具描述负责告诉模型何时该用、何时不该用。
一张图讲清楚
用户意图
工具描述
参数 Schema
服务端校验
固定工具执行
结果回流
描述控制“选不选”，Schema 控制“申请单怎么填”，服务端控制“能不能真的做”。
三个核心要点
- 写清触发条件与禁区：缺少明确时间或时区时先追问。
- 收窄合法空间：使用 required、enum、minLength 和 additionalProperties: false。
- 业务与版本留在应用层：权限、动态状态和破坏性升级不能交给静态 Schema。
最小可运行示例
const schema = {
name: "create_reminder_v1",
description: "为当前用户创建一次性提醒；缺时间或时区先追问。",
parameters: {
type: "object", additionalProperties: false,
required: ["title", "at", "timezone"],
properties: {
title: { type: "string", minLength: 1, maxLength: 80 },
at: { type: "string", format: "date-time" },
timezone: { type: "string", enum: ["Asia/Shanghai", "UTC"] },
channel: { type: "string", enum: ["app", "email"] }
}
}
};
完整原生 JS 校验代码、输入和预期输出见同日 Markdown。
生产环境会怎么翻车
- 选错工具：描述缺少正反触发条件。
- 结构通过却越权：把 Schema 合法误当授权合法。
- 新增字段破坏旧客户端：没有版本并行与回放验证。
- 时间提前八小时：没有明确 ISO 8601 偏移和 IANA 时区。
动手练习
增加 repeat 枚举，拒绝过去时间，并写 6 个测试输入。完成条件：3 个合法样本通过；缺字段、未知字段、非法时区分别给出清晰错误；模型不能指定别人的 userId。
面试表达
30 秒回答
Tool Schema 是模型与应用间的参数合同。用清晰描述控制何时调用，用 JSON Schema 收窄输入；服务端仍二次校验权限、业务状态和幂等。破坏性变更用版本化工具名发布。
3 分钟框架
按选择、结构、业务、安全、演进五层展开；测试同时覆盖合法输入、常见模型错误与恶意参数。
今日自测
description 和 Schema 各解决什么？
前者帮助选择工具，后者约束参数形状；都不替代服务端校验。
为什么不把所有规则塞进 Schema？
权限、数据库状态和当前时间是动态事实，需要代码判断。
timezone 从可选改必填怎样上线？
发布新版本并行运行，用日志和回放集验证迁移后再下线旧版。
权威来源与明天
明天：服务端注册、超时和错误。把今天的 Schema 放进固定注册表，并练习安全失败。