为 Chat Completions 请求选择推理参数

GenStudio 的 Chat Completions 接口兼容 OpenAI 请求形态，但推理参数不是一个统一字段。接入前先确认模型系列，再决定当前请求的控制参数、响应解析字段和多轮历史回传方式。

如果只需要快速判断参数，请先看本页速查。需要完整代码和工具调用历史处理时，再进入对应模型系列页面。

按模型系列确定参数来源

先用模型系列决定参数来源。生产代码使用模型系列自己的原生参数。

按模型系列选择原生参数

同一个请求字段不能套用到所有模型。选错字段时，模型可能忽略参数、返回 400，或返回没有推理字段的正常回答。

本组文档的模型系列页面分别说明各自的原生参数。

• GLM：当前请求使用 thinking.type，响应读取 reasoning_content，历史保留使用 thinking.clear_thinking；glm-5.2 额外支持 reasoning_effort。查看使用 GLM 的 thinking 参数。
• Kimi：K2.x 使用 thinking；kimi-k3 始终推理，使用顶层 reasoning_effort 调整推理强度；响应读取 reasoning_content。查看使用 Kimi 的 thinking 和 reasoning_effort。
• MiniMax：M3 使用 thinking.type 的 adaptive 或 disabled 控制当前请求是否思考；reasoning_split 只控制返回形态。split 模式可能返回 reasoning_content 和 reasoning_details，非 split 模式可能把推理放在 content 的 ＜think＞ 中。查看使用 MiniMax 的 thinking 和 reasoning_split。
• DeepSeek：当前请求使用 thinking.type 和 reasoning_effort，响应读取 reasoning_content；DeepSeek V4 提供 low、high 和 max 三档有效推理强度，默认值为 high。工具调用历史中需要回传推理字段。查看使用 DeepSeek 的 thinking 参数。
• Qwen 文本模型：使用原生 enable_thinking 参数，并按模型支持范围配合 thinking_budget 和 preserve_thinking。查看使用 Qwen 文本模型的 enable_thinking。
• MiMo：当前请求使用 thinking.type，响应读取 reasoning_content；工具调用历史中需要回传推理字段。查看使用 MiMo 的 thinking.type。

检查默认思考是否符合预期

先用默认行为判断是否必须显式传参。生产代码需要稳定行为时，仍应设置对应模型系列的推理参数。

• GLM：glm-5.2、glm-5.1、glm-5、glm-4.7 默认开启思考；glm-4.6 默认使用混合或自动思考。设置 thinking.type: "enabled" 后，glm-5.2、glm-5.1、glm-5 和 glm-4.6 会按请求判断是否需要思考，glm-4.7 则会强制思考。
• Kimi：kimi-k3 始终推理且 preserved thinking 始终开启；kimi-k2.7-code 默认开启 thinking 和 preserved thinking，且不可关闭；kimi-k2.6、kimi-k2.5 默认开启思考，可显式关闭。
• DeepSeek：DeepSeek V4 的 OpenAI-compatible 路径使用 thinking.type，并只在启用思考时设置 reasoning_effort。省略 reasoning_effort 时默认为 high；兼容值 medium 和 xhigh 也会映射为 high。
• MiMo：按目标模型验证默认行为；接入时优先显式设置该模型系列的原生参数。
• MiniMax：M3 省略 thinking 时默认使用 adaptive thinking，可显式设置 thinking.type: "adaptive" 或 thinking.type: "disabled"；M2.x 无法关闭 thinking。

接入请求、响应和历史消息

选定参数后，还需要同时处理响应字段和历史消息。当前请求开关只影响这一次生成；多轮对话和工具调用还取决于 assistant 消息中的推理字段是否按原样回传。

设置当前请求的推理开关

当前请求的控制参数只影响这一次模型生成。它不自动修复历史消息，也不等同于历史推理内容保留策略。

• GLM、Kimi K2.x、MiMo、DeepSeek 使用 thinking.type：

extra_body = {"thinking": {"type": "enabled"}}

• Kimi K3 使用顶层 reasoning_effort：

response = client.chat.completions.create(
    model="kimi-k3",
    messages=messages,
    reasoning_effort="high",
)

• MiniMax M3 使用 thinking.type 控制当前请求是否思考：

extra_body = {"thinking": {"type": "adaptive"}}

• MiniMax 的 reasoning_split 控制推理内容返回在哪里，不是 thinking 开关：

extra_body = {"reasoning_split": True}

如果某个模型是强制思考模型，不要把关闭思考作为正常路径写入业务逻辑。强制思考模型即使接受请求，也可能忽略关闭参数或返回与可切换模型不同的结果。

读取响应中的推理内容

应用侧应按模型系列读取推理字段，并允许字段缺失。很多 OpenAI SDK 类型不会静态声明 provider 扩展字段，Python 代码应使用动态访问方式。

message = response.choices[0].message

reasoning = getattr(message, "reasoning_content", None)
reasoning_details = getattr(message, "reasoning_details", None)
content = message.content or ""

if reasoning:
    print(reasoning)
elif reasoning_details:
    print(reasoning_details)
elif "<think>" in content:
    print(content)

流式响应中也按同样的字段名读取 delta。请求设置 stream_options.include_usage: true 时，流结束前的最终用量汇总 chunk 只携带 usage，且 choices 为空。以下推理内容解析代码应跳过该 chunk；需要记录用量时，应在跳过前读取 chunk.usage。

for chunk in stream:
    if not chunk.choices:
        continue

    delta = chunk.choices[0].delta
    reasoning = getattr(delta, "reasoning_content", None)
    if reasoning:
        print(reasoning, end="")
    else:
        for detail in getattr(delta, "reasoning_details", None) or []:
            text = detail.get("text") if isinstance(detail, dict) else getattr(detail, "text", None)
            if text:
                print(text, end="")

    text = getattr(delta, "content", None)
    if text:
        print(text, end="")

回传历史中的推理内容

只有当前请求参数还不够。多轮对话，尤其是工具调用，会把上一轮 assistant 消息放回 messages[]。如果上一轮 assistant 消息带有推理字段，回传策略会影响请求是否被接受和模型是否能延续上下文。

• 普通多轮对话没有工具调用时，通常只需要回传面向用户的 assistant content。不要伪造没有返回过的推理字段。
• assistant 同时返回 tool_calls 和 reasoning_content 时，回传 assistant 消息时保留原始 reasoning_content，再追加 tool 消息。
• GLM preserved thinking 需要在请求体中使用 thinking.clear_thinking: false，并原样回传已经存在的 reasoning_content。
• Kimi K2.x preserved thinking：kimi-k2.6 需要在请求体中使用 thinking.keep，并原样回传已经存在的 reasoning_content；kimi-k2.5 不支持 preserved thinking，不要发送 thinking.keep；kimi-k2.7-code 默认保留历史推理，仍需原样回传模型返回的 assistant 消息。
• Kimi K3 的 preserved thinking 始终开启。多轮对话和工具调用必须原样回传完整 assistant 消息，包括模型实际返回的 reasoning_content 和 tool_calls。
• MiniMax 工具调用需要回传完整 assistant 消息。M3 split 模式的非流式响应可能只包含 reasoning_content，流式重建后的消息可能同时包含 reasoning_content 和 reasoning_details；非 split 模式的推理可能在 content 中。服务端实际返回哪些字段，就原样保留哪些字段。

回传历史时不要重新排序、改写或补写推理内容。如果某一轮的 assistant 消息没有 reasoning_content，保留它的缺失状态即可；自适应思考、显式关闭思考或跳过思考都可能产生这种响应。不要用空字符串、摘要或人工生成内容冒充模型原始推理字段。

没有推理内容时检查请求和响应模式

请求返回 200 但没有推理内容时，先检查请求和模型行为，再判断是否是错误。

• 确认模型是否默认关闭推理，是否需要显式设置该模型系列的原生参数，例如 thinking.type 或 reasoning_effort。
• 对 GLM 自适应思考模型，thinking.type: "enabled" 允许模型自行判断；本次响应没有 reasoning_content，也属于正常结果。
• 确认模型是否是强制思考模型。强制思考模型通常不需要显式开启。
• 确认当前响应模式。流式响应需要从 delta 中拼接推理内容。
• 检查 MiniMax M3 是否设置了 thinking.type: "disabled"，以及是否使用了 reasoning_split。split 模式先读取 reasoning_content，再把 reasoning_details 作为回退；未开启 split 时，推理可能在 content 的 ＜think＞ 片段中。
• 如果请求返回 400，先移除不属于该模型系列的推理参数，再按对应系列页面重新构造请求。

查看完整请求样例和回传规则

确定模型系列后，进入对应页面查看完整请求样例和历史回传规则。

• 使用 GLM 的 thinking 参数
• 使用 Kimi 的 thinking 和 reasoning_effort
• 使用 MiniMax 的 thinking 和 reasoning_split
• 使用 DeepSeek 的 thinking 参数
• 使用 Qwen 文本模型的 enable_thinking
• 使用 MiMo 的 thinking.type
• Function Calling — 在工具调用场景中，推理内容回传通常和工具结果回传同时处理。