使用 GLM 的 thinking 参数

连接 AI 助手

GLM 系列使用 thinking 对象配置当前请求的思考行为。glm-5.1、glm-5.2 可切换思考开关；glm-5.3、glm-5.3-flash 始终开启思考。本文说明 GenStudio 默认 OpenAI-compatible Chat Completions 路径的参数用法。需要在工具调用或长任务中保留历史推理时，再使用 clear_thinking 决定是否清除历史推理上下文。

检查 GLM 默认思考行为

用本节决定是否需要显式传 thinking.type。默认开启的模型不一定需要 thinking.type: "enabled"，但显式传参可以让请求行为更清楚。

• glm-5.2 和 glm-5.1 默认开启自适应思考。开启后，模型会根据请求判断是否需要思考，因此响应没有 reasoning_content，也属于正常结果。
• glm-5.3 和 glm-5.3-flash 始终开启思考，省略 thinking 即可使用默认行为；显式传参时，thinking.type 只能为 "enabled"。设置为 "disabled" 会返回 400。始终开启思考不保证每条响应都暴露 reasoning_content，尤其是工具调用响应；应用仍应兼容字段缺失。

如果业务对延迟敏感，可在 glm-5.1、glm-5.2 上比较关闭思考后的效果；使用 glm-5.3、glm-5.3-flash 时，可先测试 reasoning_effort: "low"。

设置当前请求的 thinking.type

当前请求只需要控制这一次生成时，设置 thinking.type。以下 Python 示例使用 OpenAI SDK。

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["API_KEY"],
    base_url="https://cloud.infini-ai.com/maas/v1",
)

response = client.chat.completions.create(
    model="glm-5.1",
    messages=[{"role": "user", "content": "What is 2 + 2? Give only the final answer."}],
    max_tokens=256,
    extra_body={"thinking": {"type": "enabled"}},
)

对于 glm-5.1 和 glm-5.2，关闭思考时只改 type：

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

对于 glm-5.2 和 glm-5.1，开启思考后仍应允许响应省略 reasoning_content。如果业务必须跳过思考，请显式设置 thinking.type: "disabled"。

按模型设置 reasoning_effort

glm-5.2、glm-5.3 和 glm-5.3-flash 支持 reasoning_effort，但取值语义不同。不要把这个字段直接复制到 glm-5.1 的请求中。

GLM-5.3 和 GLM-5.3-Flash

两种模型均使用 low、high、max 三档推理强度，默认值为 max。降低推理强度不会关闭思考。新请求只使用这三档，不要沿用 GLM-5.2 的 none、minimal、medium 或 xhigh 兼容取值。

extra_body = {
    "thinking": {"type": "enabled"},
    "reasoning_effort": "low",
}

GLM-5.2

该模型的 reasoning_effort 用于调整推理投入，不会把自适应思考改为强制思考。

GLM-5.2 的默认推理强度是 max。如果业务希望显式控制推理强度，建议先只使用有实际区分度的取值：

• high：较高推理强度。
• max：最高推理强度，也是默认值。

其他兼容取值会被模型侧归并或改变思考开关语义：

• none、minimal 会跳过思考；需要关闭思考时，优先使用 thinking.type: "disabled"。
• low、medium 会映射为 high。
• xhigh 会映射为 max。

extra_body = {
    "thinking": {"type": "enabled"},
    "reasoning_effort": "max",
}

用 curl 验证 thinking.type 请求体

先用 curl 确认请求体包含 GLM 原生 thinking.type。运行前先在当前终端设置 API_KEY 环境变量。以下 curl 命令适用于 bash/zsh 等 POSIX 风格 Shell（macOS/Linux、WSL、Git Bash）。如果使用 Windows PowerShell 或 CMD，请按对应 Shell 的语法调整命令。

curl --request POST \
  --url "https://cloud.infini-ai.com/maas/v1/chat/completions" \
  --header "Accept: application/json, text/event-stream" \
  --header "Authorization: Bearer $API_KEY" \
  --header "Content-Type: application/json" \
  --data-raw '{
    "model": "glm-5.1",
    "messages": [
      {
        "role": "user",
        "content": "What is 2 + 2? Give only the final answer."
      }
    ],
    "max_tokens": 256,
    "thinking": {
      "type": "enabled"
    }
  }'

终端录制

用 curl 验证 GLM thinking.type

在演示库中打开

适用于验证 GLM 原生推理字段是否按预期传入。

点击播放，无输出等待最多 1 秒。文字较小时，可放大阅读。

终端演示 · 放大阅读

用 curl 验证 GLM thinking.type

打开或关闭此视图时会暂停，播放进度保持不变。窄屏可左右滑动查看完整内容。

保留工具调用之间的历史推理

如果希望模型在工具调用前后的同一个任务中延续推理上下文，请设置 clear_thinking: false。clear_thinking 默认为 true，只控制历史推理是否保留，不控制当前请求是否生成推理。

extra_body = {
    "thinking": {
        "type": "enabled",
        "clear_thinking": False,
    }
}

只有当请求历史中确实包含模型返回过的 reasoning_content 时，保留历史推理才有意义。即使设置了 clear_thinking: false，也不要为没有返回推理内容的 assistant 消息补写字段。

回传带有 reasoning_content 的 assistant 消息

当 assistant 消息包含 tool_calls 和 reasoning_content 时，把这个 assistant 消息原样放回 messages[]，然后追加工具结果。

assistant_message = {
    "role": "assistant",
    "content": response.choices[0].message.content or "",
    "tool_calls": [
        {
            "id": tool_call.id,
            "type": "function",
            "function": {
                "name": tool_call.function.name,
                "arguments": tool_call.function.arguments,
            },
        }
        for tool_call in response.choices[0].message.tool_calls
    ],
}

reasoning = getattr(response.choices[0].message, "reasoning_content", None)
if reasoning:
    assistant_message["reasoning_content"] = reasoning

messages.append(assistant_message)
messages.append(
    {
        "role": "tool",
        "tool_call_id": assistant_message["tool_calls"][0]["id"],
        "content": '{"weather": "Sunny", "temperature": "25 C"}',
    }
)

回传时不要改写、摘要或重新排序 reasoning_content。这类修改可能导致请求被拒绝，或让后续推理失去连续性。

切换思考开关时保留真实历史

glm-5.1 和 glm-5.2 支持按轮切换思考开关，但历史消息必须反映真实返回结果。glm-5.3 和 glm-5.3-flash 不支持关闭思考，请在各轮保持思考开启。

如果 Turn 0 的 assistant 有 reasoning_content，而 Turn 1 没有该字段，则 Turn 2 请求应：

1. 保留 Turn 0 assistant 中原始的 reasoning_content。
2. 不给 Turn 1 assistant 补写 reasoning_content。
3. 在需要 preserved thinking 时设置 thinking.clear_thinking: false。

如果这次请求要有意丢弃历史推理，可以不使用 preserved thinking；但这会牺牲历史推理连续性，并可能影响缓存命中。

读取流式响应中的 reasoning_content

流式响应中，GLM 的推理增量在 delta.reasoning_content。OpenAI SDK 类型不一定声明该字段，读取时使用动态访问。

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="")

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

请求设置 stream_options.include_usage: true 时，流结束前的最终用量汇总 chunk 只携带 usage，且 choices 为空。以上代码只解析推理和可见内容，因此跳过该 chunk；需要记录用量时，应在跳过前读取 chunk.usage。

响应可能完全不返回 reasoning_content 增量。只要响应正常完成，且包含可用的回答或工具调用，应用就可继续处理。

对于 glm-5.3 和 glm-5.3-flash，需要流式读取工具参数时，可同时设置 stream: true 和 tool_stream: true。按工具调用的 index 拼接 delta.tool_calls 中的参数片段，收到完整参数后再解析 JSON、校验并执行工具。下一轮继续回传原始工具调用 ID、工具结果和实际返回的推理字段。

与 structured output 一起使用

glm-5.3 和 glm-5.3-flash 的思考参数不负责校验结构化结果。当提示词与 schema 冲突时，即使设置 response_format.type: "json_schema" 和 strict: true，也可能返回字段类型错误或包含额外字段的 JSON。

应用必须自行校验 schema；HTTP 200 和 finish_reason: "stop" 不能代替校验。finish_reason: "length" 或空 content 应视为不完整结果。完整处理方式参见 Structured output。

修复历史推理导致的 400 错误

出现 400 时，先检查当前参数和历史消息。

• 对 glm-5.3 和 glm-5.3-flash，确认没有设置 thinking.type: "disabled"，且 reasoning_effort 使用 low、high 或 max。
• assistant 消息里有 tool_calls 时，对应的 tool 消息必须紧跟正确的 tool_call_id。
• 如果历史 assistant 原本返回了 reasoning_content，回传时不要删除或改写。
• 如果某轮没有返回 reasoning_content，保持字段缺失；不要补写空的或人工生成的推理。
• 如果不需要历史推理连续性，清理历史消息后重新发起新会话，比混合不完整历史更安全。