使用 GLM 的 thinking 参数

GLM 系列使用 thinking 对象配置当前请求的思考行为。对于自适应思考模型，thinking.type: "enabled" 表示允许模型根据请求判断是否需要思考，不保证每次响应都返回 reasoning_content。需要在工具调用或长任务中保留历史推理时，再使用 clear_thinking 决定是否清除历史推理上下文。

检查 GLM 默认思考行为

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

• glm-5.2、glm-5.1 和 glm-5 默认开启自适应思考。开启后，模型会根据请求判断是否需要思考，因此响应没有 reasoning_content，也属于正常结果。
• glm-4.7 默认开启思考；显式设置 thinking.type: "enabled" 时会强制思考。
• glm-4.6 默认使用混合或自动思考。显式设置 thinking.type: "enabled" 后，模型仍会根据请求判断是否需要思考。

如果业务对延迟敏感，先用目标模型测试关闭思考后的回答质量和响应时间。

设置当前请求的 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"}},
)

关闭思考时只改 type：

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

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

设置 GLM-5.2 的 reasoning_effort

reasoning_effort 只适用于 GLM-5.2。不要把这个字段直接复制到 glm-5.1、glm-5 或 glm-4.7 的请求中。该字段用于调整推理投入，不会把 GLM-5.2 的自适应思考改为强制思考。

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 原生推理字段是否按预期传入。

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

如果希望模型在工具调用前后的同一个任务中延续推理上下文，请设置 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 支持按轮控制思考，但历史消息必须反映真实返回结果。

如果 Turn 0 的 assistant 有 reasoning_content，而 Turn 1 因自适应判断、关闭思考或使用 reasoning_effort: "none" / "minimal" 而没有 reasoning_content，则 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 增量。只要响应和可见内容正常，应用可以继续按普通响应处理。

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

出现 400 时，先检查历史消息，而不是先调整 prompt。

• assistant 消息里有 tool_calls 时，对应的 tool 消息必须紧跟正确的 tool_call_id。
• 如果历史 assistant 原本返回了 reasoning_content，回传时不要删除或改写。
• 如果某轮没有返回 reasoning_content，保持字段缺失；不要补写空的或人工生成的推理。
• 如果不需要历史推理连续性，清理历史消息后重新发起新会话，比混合不完整历史更安全。