OpenAI Responses API 的 text.format、json_schema、json_object、strict、required、additionalProperties 和 refusal 有什么区别？

如果你的目标是让 Responses API 返回可验证的业务对象，优先使用 text.format.type = "jsonschema"，提供稳定的名称和 JSON Schema，并在模型支持时启用 strict: true。不要把 jsonobject 当成模式校验，也不要在看到 refusal、incomplete 或非文本 output item 时强行解析业务 JSON。

text.format 是 Responses API 的文本输出格式入口。默认文本模式适合自然语言；jsonschema 适合需要固定字段和类型的结构化结果；jsonobject 是较旧的 JSON 模式。它们约束的是模型生成的文本结果，不等同于函数工具的参数定义。

jsonschema 不只是要求“看起来像 JSON”，而是向模型提供预期对象的字段、类型、数组结构和枚举等规则。调用方随后仍应进行本地反序列化和业务校验，因为模式一致不代表内容在业务上必然正确。

jsonobject 的核心承诺是生成合法 JSON，而不是保证输出符合某个指定 Schema。对于支持 Structured Outputs 的较新模型，官方文档建议优先使用 jsonschema。继续使用 JSON mode 时，提示中还必须明确要求输出 JSON，并处理达到输出上限等异常情况。

strict: true 表示模型将严格遵循 Structured Outputs 支持的 JSON Schema 子集。它不是“开启所有 JSON Schema 关键字”，也不是替代本地验证器。使用未支持的关键字时，请求可能被拒绝，或无法获得预期约束效果。

模式名称用于标识结构化输出定义。应使用稳定、可读、符合接口字符约束的名称，例如 supportdiagnosis，不要把时间戳或用户输入拼进名称。稳定名称也有利于日志聚合、缓存命中和故障定位。

描述用于解释这个结构的用途，帮助模型理解字段组合的整体语义。它不能代替字段级定义，也不应塞入不受信任的用户指令。简洁说明“对象代表什么”通常比重复 Schema 更有效。

schema 是标准 JSON Schema 风格的对象，常见根类型为 object，内部包含 properties、required 和 additionalProperties。应用应把它作为版本化契约管理，而不是在每次请求中临时拼接一套不同结构。

在严格结构化输出中，对象的字段通常需要全部列入 required。如果业务字段可选，不要简单从 required 删除；可按官方示例将其类型设计为包含 null，然后仍把字段列为必填。这样输出形状稳定，值是否存在由 null 表达。

对象层级设置 additionalProperties: false 可以阻止模型生成 Schema 未声明的额外键。嵌套对象也应逐层明确该约束，否则外层严格并不自动替代内层对象的定义。

例如 errorcode 可能不存在，可将类型声明为 string 与 null 的联合，并把 errorcode 放入 required。消费者总能看到这个键：有值时是字符串，无值时是 null，无需猜测“缺键”和“解析遗漏”的区别。