response_format 是 Chat Completions 接口中用于约束模型输出格式的参数。普通 GPT 模型对该参数的支持已经比较成熟，但 o 系列推理模型因为内部加入了思维链机制，早期版本只允许返回纯文本，后来才逐步开放 json_object 和 json_schema。这个差异导致很多开发者在把之前的 GPT-4o 配置直接迁移到 o3-mini 等推理模型时，会遇到参数不生效或接口报错的问题。理解 response_format 在推理模型中的实际行为，是做结构化输出改造的第一步。

一、推理模型对 response_format 的支持边界

response_format 参数一共支持三种取值：text、json_object 和 json_schema。text 是默认值，模型返回普通自然语言；json_object 会强制模型输出一个合法的 JSON 对象，但不保证内部字段名称和类型；json_schema 则可以根据传入的 JSON Schema 严格约束输出结构。对于推理模型来说，并非所有版本都完整支持这三种模式。例如早期的 o1-preview 和 o1-mini 在某些 API 端点下只支持 text，而 o3-mini 以及后续更新的版本才逐步支持 json_object 和 json_schema。在实际调用前，最好先查看当前模型卡片或 API 文档中的 Supported parameters 列表，确认 response_format 处于可用状态。

推理模型与标准 GPT 模型在结构化输出上的最大区别，是思维链与格式约束的交互方式。推理模型在生成最终答案之前，会先产生一段内部推理过程，这段过程在 API 返回中通常不可见，但会消耗 token。当 response_format 被设置为严格 JSON 模式时，模型需要把推理结论压缩到 JSON 字段中，而不能再像文本模式那样自由输出冗长的分析段落。如果约束过强，模型可能因为找不到合适的表达路径而提前结束生成，返回一个字段缺失或截断的 JSON。因此，在使用 json_schema 时，通常建议把必要的推理摘要也作为一个字段放进 schema，而不是强制模型先输出推理文本再输出 JSON，这样可以让推理信息有地方存放。

二、json_object 模式配置示例与注意事项

json_object 模式是配置成本最低的结构化输出方式。它的唯一要求是：调用时必须在 messages 中的某一条消息里出现“JSON”这个关键词，否则 OpenAI 服务端会返回类似错误：Invalid parameter: 'response_format' of type 'json_object' is not supported with this model，或者直接提示消息中缺少 JSON 字样。这个限制同样适用于推理模型。一个常见的做法是直接在用户消息里写“请以 JSON 格式返回结果”，这样既满足了提示词要求，也能让模型明确知道需要输出的内容。

下面是一段使用 Python SDK 调用 o3-mini 并开启 json_object 模式的代码示例。要注意在推理模型上使用 json_object 时，模型仍然可能把推理过程混入最终 JSON 的某个字段中，因此返回数据的字段名不固定，需要二次提取。

from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(
    model="o3-mini",
    messages=[
        {
            "role": "user",
            "content": "请分析以下文本的情感，并以 JSON 格式返回：今天天气很好，适合出门散步。"
        }
    ],
    response_format={"type": "json_object"}
)
print(response.choices[0].message.content)

上述代码返回的内容通常是一个对象，例如 {"sentiment": "positive", "confidence": 0.92}，但第二次调用时字段名可能变成 {"label": "positive", "score": 0.9}。这是因为 json_object 只约束了“合法 JSON 对象”这一层，不约束键名和结构。如果业务系统需要稳定的字段，就必须在提示词中反复强调目标字段，或者改用 json_schema 模式。另外，推理模型在 json_object 模式下依然会消耗推理 token，建议根据任务复杂度设置 reasoning_effort，同时预留足够的 max_tokens，避免最终 JSON 在输出中途被截断。

三、json_schema 严格结构化输出配置

如果要求模型返回的 JSON 字段名、类型和必填项完全固定，就需要使用 json_schema 模式。与 json_object 不同，json_schema 需要传入一个包含 name、strict 和 schema 的对象。其中 strict 设置为 true 时，模型必须严格遵守 schema，不能输出额外字段；schema 则使用 JSON Schema 规范定义结构。对于推理模型而言，strict 模式会显著限制 token 生成空间，因此 schema 设计要尽量简洁，减少不必要的嵌套层级。

下面的示例演示了如何让 o3-mini 返回一个包含 sentiment 和 confidence 两个字段的分析结果。注意在 strict 为 true 的情况下，根节点必须是 type: "object"，所有 required 字段必须列出，并且设置 additionalProperties: false，否则 API 会拒绝请求。

response = client.chat.completions.create(
    model="o3-mini",
    messages=[
        {
            "role": "user",
            "content": "请判断用户反馈的情感倾向。"
        }
    ],
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "sentiment_result",
            "strict": True,
            "schema": {
                "type": "object",
                "properties": {
                    "sentiment": {
                        "type": "string",
                        "enum": ["positive", "negative", "neutral"]
                    },
                    "confidence": {
                        "type": "number",
                        "minimum": 0,
                        "maximum": 1
                    },
                    "reasoning": {
                        "type": "string",
                        "description": "简要说明判断依据"
                    }
                },
                "required": ["sentiment", "confidence", "reasoning"],
                "additionalProperties": False
            }
        }
    }
)
print(response.choices[0].message.content)

在这个示例中，reasoning 字段承担了保存推理摘要的功能，这样可以避免模型思维链信息被强制丢弃。实际测试中，推理模型在 json_schema 模式下偶尔会出现两种问题：一是输出 JSON 的结尾缺少闭合括号，二是 confidence 字段返回了超出范围的数字。前者通常与 max_tokens 设置过小有关，后者则提示 schema 中的数值约束可能需要结合提示词再次强调。总体来看，json_schema 模式比 json_object 更适合直接对接下游系统，但配置复杂度和 token 消耗也更高。

四、常见报错与调优建议

在推理模型上配置 response_format 时，最常见的问题就是参数无效错误。如果接口返回 Invalid parameter: response_format，首先要检查当前模型是否真的支持该模式。有些推理模型虽然支持 json_object，但不支持 json_schema，或者反过来；有些测试端点可能只支持文本输出。此时可以换用已经确认支持结构化输出的模型版本，或者在代码中做降级处理，先尝试 json_schema，失败后再降级为 json_object 或纯文本。

另一个高频问题是 JSON 截断。推理模型在生成过程中会优先分配 token 给内部推理，如果最终 JSON 的 max_tokens 设置刚好覆盖推理长度，输出阶段就会因为 token 耗尽而中断。解决办法是适当调大 max_tokens，同时降低 reasoning_effort，或者减少 schema 中的冗余字段。此外，如果使用官方 SDK 的 client.beta.chat.completions.parse 方法，需要确认该方法对推理模型的兼容性，因为 parse 会自动补全 schema 和 strict 设置，但部分推理模型版本可能尚未纳入支持范围。建议在关键业务中仍以显式传入 response_format 为主，并对返回内容做 JSON 解析容错。

总体而言，推理模型的结构化输出配置需要结合任务类型、token 预算和模型版本综合考虑。json_object 适合快速验证，json_schema 适合生产链路，但两者都要求提示词和参数互相配合。只要理解了推理模型与标准 GPT 模型在输出约束上的差异，就能稳定获得可解析的 JSON 结果。