从 Claude Opus 4.6 升级到 4.7 版本，工具调用（Tool Calling）的 Schema 结构发生了显著变化。这一演进并非简单的版本迭代，而是 Anthropic 对大模型工具调用可靠性的一次系统性增强。理解这些差异对于正在构建 AI 代理（Agent）系统的开发者而言至关重要，因为它直接影响函数签名的定义方式、参数校验的严格程度，以及下游系统的容错设计。
宽松模式到严格模式的核心转变
在 Opus 4.6 及更早版本中，工具定义主要遵循一个相对宽松的契约模型。开发者通过tools数组传入函数名称（name）、描述（description）和输入模式（input_schema），模型根据这些提示自主推断参数类型和必填项。这种方式的优势在于灵活性 —— 模型可以在一定程度上容忍 Schema 定义的不完整或模糊之处，并通过自然语言理解能力补全缺失信息。然而，这种灵活性的代价是可靠性不稳定：在复杂的多步骤工作流中，模型可能产生不符合 Schema 的参数、遗漏必填字段，或在参数类型上出现微妙的偏差，导致下游代码在反序列化时抛出异常。
Opus 4.7 引入了严格工具使用（Strict Tool Use）模式，通过在工具定义中设置strict: true参数来启用。启用后，工具调用的参数生成将受到语法约束采样（Grammar-Constrained Sampling）的强制校验。这意味着模型不再被允许 “推断” 缺失的参数，而是必须从预编译的 JSON Schema 语法中严格选择合法输出。从工程角度看，这一变化将工具调用的正确性从 “概率性正确” 提升到 “确定性正确”，大幅降低了因模型幻觉导致的运行时错误。
启用严格模式的工具定义示例如下：工具对象中新增strict字段并设为true，同时在input_schema中必须明确定义所有参数的type、必填项required以及是否允许额外属性additionalProperties。当模型生成不符合该 Schema 的参数时，API 会直接拒绝该工具调用并触发重试机制，而非返回无效的 JSON。
参数定义的关键差异与约束
Opus 4.7 对参数定义提出了更具体的要求。首先，属性排序规则发生了变化：在严格模式下输出的 JSON 对象中，必填属性（required中列出的字段）会优先出现在可选属性之前，且同类别内保持 Schema 中定义的原始顺序。这一变化看似仅涉及序列化细节，实际上对依赖属性位置进行解析的下游系统有直接影响 —— 如果你的代码此前假设特定字段总是在某个固定位置，需要相应调整解析逻辑。
其次，复杂度的硬性限制被引入。Opus 4.7 对严格工具 Schema 设置了明确的复杂度上限：每个请求最多支持 20 个严格工具、总共 24 个可选参数（跨所有工具）、以及 16 个联合类型参数（使用anyOf或类型数组如"type": ["string", "null"]）。这些限制并非人为设障，而是因为复杂 Schema 会导致语法编译时间呈指数增长 —— 当联合类型嵌套过深时，编译出的语法状态空间会超出服务器的处理能力。官方文档指出，一旦超出这些限制，API 将返回 400 错误并提示 "Schema is too complex for compilation"。对于需要调用大量工具的代理系统，建议将非关键工具保持为非严格模式，或将工具拆分到多个请求中处理。
第三，additionalProperties: false成为推荐配置。在 Opus 4.6 中，模型有时会返回 Schema 未定义的额外字段，这些字段在 Opus 4.7 的严格模式下会被拒绝。通过在 Schema 中显式设置additionalProperties: false，开发者可以确保模型输出的参数集合完全受控，避免意外字段导致的数据污染。
从 Schema 定义到 API 调用的参数配置
从 API 使用角度，4.6 到 4.7 的迁移涉及几个实际的参数名称和位置变化。在 4.7 中，结构化输出的配置从 beta 阶段的output_format迁移到了output_config.format，这一变化同样影响工具调用相关的配置。如果你正在使用 Anthropic 的 Python SDK，4.7 版本中可以通过client.messages.parse()方法结合 Pydantic 模型自动处理 Schema 转换 ——SDK 会在内部将 Pydantic 模型的约束（如minimum、maximum等）转换为 Schema 描述文本，同时在服务端使用简化版的 Schema 以确保兼容性，最终在客户端对返回结果进行完整校验。
对于需要同时使用结构化输出（JSON Response）和严格工具调用的场景，4.7 支持将两者组合使用：JSON 输出控制最终响应的格式，严具工具使用确保中间步骤的参数正确。这种组合对于构建需要多轮工具调用并最终返回结构化报告的代理工作流尤为有价值。需要注意的是，这两项功能不能与引用（Citations）功能同时启用，因为引用需要在文本中插入交叉引用标记，这与严格的 JSON Schema 约束存在冲突。
工程落地的监控与调优要点
将工具调用从 4.6 迁移到 4.7 时，建议在监控层面关注三个核心指标。首先是工具调用拒绝率—— 由于严格模式的参数校验更严格，初期可能会观察到更多的工具调用被拒绝，这些拒绝通常伴随着模型自行修正后的重试。监控这一指标可以帮助判断 Schema 定义是否过于严苛。其次是首次请求延迟—— 使用新的 Schema 时，API 需要约 100 至 200 毫秒进行语法编译，后续请求会从缓存中复用已编译的语法（缓存有效期为 24 小时），因此在仪表盘上应该能看到明显的 “冷启动” 与 “热调用” 延迟差异。第三是Token 消耗变化—— 严格模式要求在 Schema 中明确列出更多约束（特别是additionalProperties: false和required数组），这会导致工具定义的 Token 占用略有上升，但换取的是更可靠的下游处理。
在实际落地中，一个有效的策略是分阶段启用严格模式：首先对核心业务工具（如涉及数据写入、支付调用等高风险操作）启用strict: true，观察两周左右的运行数据后再扩展到辅助工具。这样可以在控制风险的同时逐步积累调优经验。对于 Schema 复杂度接近限制的工具集，建议使用 OpenAPI 3.0 规范中的oneOf替代深层的anyOf嵌套，或将一个复杂工具拆分为多个职责单一的正交工具。
总结与迁移建议
Claude Opus 4.7 的工具调用 Schema 演进，本质上是在灵活性与可靠性之间做出了更倾斜于后者的选择。对于依赖模型生成结构化工具参数的 AI 系统，这一变化带来了显著的工程质量提升，但也要求开发者投入更多精力在 Schema 设计、复杂度管理和监控告警上。迁移的关键不在于简单的模型版本切换，而在于重新审视工具定义的完整性 —— 是否所有必填参数都已显式声明、是否需要对额外属性进行约束、现有工具数量是否接近复杂度上限。在 4.7 的严格模式下，工具签名不再是一个 “提示” 而是一个 “契约”，这种设计理念的转变值得所有 AI 代理开发者深入理解并付诸实践。
资料来源：Anthropic 官方 Structured Outputs 文档（https://platform.claude.com/docs/en/build-with-claude/structured-outputs）