GLM 思考模式怎么开怎么关：参数与适用场景

数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。

先把结论摆在前面：GLM 的思考模式，默认状态是「开」而不是「关」，这跟很多人从别家 API 带过来的直觉正好相反。 官方文档《深度思考》里写得很明白，thinking.type 的默认值是 enabled，而 GLM-5.3 更进一步——官方注明它「不再支持关闭思考」，请求里传 disabled 会直接报错。所以你要做的不是「怎么把思考打开」，而是「哪些轮次值得让它想、哪些轮次该让它闭嘴」。控制手段一共三层：thinking.type 管开关，reasoning_effort 管深浅，模型选择管你有没有得选。再往上还有三种进阶形态——交错式思考、保留式思考、轮级思考，分别对应工具调用、编码 Agent 和多轮对话三类场景。下面按你真正会写代码的顺序来讲。

第一层：thinking.type 只有两个取值

官方文档《深度思考》的「核心参数说明」一节把 thinking.type 的取值列得很干净，只有两个：

• enabled：官方标注为默认值，启用动态思考
• disabled：禁用思考，直接给出回答

请求体里它是一个嵌套对象，不是平铺的字段。cURL 写法是这样：

{
  "model": "glm-5.2",
  "messages": [
    {"role": "user", "content": "今天天气怎么样？"}
  ],
  "thinking": {
    "type": "disabled"
  }
}

这里有个容易被忽略的细节：enabled 并不等于「每次都一定会想」。官方对 enabled 的解释是「启用动态思考」，并且在括号里区分了两类行为——一部分型号是模型自动判断是否需要思考，另一部分型号（文档明确点名了 GLM-5.3、GLM-4.7、GLM-4.5V）是强制思考。也就是说，同样传 enabled，你在不同型号上拿到的是两种不同的确定性：前者可能这次想、下次不想，后者一定会想。如果你的下游解析逻辑假设「开了思考就一定有推理内容」，那么在自动判断型号上，这个前提本身就不成立。至于模型这一轮没有思考时，reasoning_content 到底是空字符串还是干脆不出现这个字段，官方文档里没有找到相关说明——所以别按某一种形态把解析写死。官方 Python 示例的写法值得照抄：先用 hasattr 判断属性存不存在，再判断值是不是非空，两道判断都留着，不管哪种形态都不会炸。

至于关闭，官方在《思考模式》页面用一句话交代了边界：想关思考就传 type: "disabled"，但「注意 GLM-5.3 强制思考不能关闭」。《深度思考》页面用 Note 框重复了一次，措辞更硬——传 disabled 将会报错。这是本篇最值得记住的一条硬约束：选型阶段就要决定，你的场景允不允许「关不掉的思考」。如果你做的是高频短问答、对首字延迟敏感，那么在还能关思考的型号上做，比事后想办法把 GLM-5.3 的推理压下去要现实得多。

第二层：reasoning_effort 调深浅，注意它会被映射

如果你不想在「全想」和「不想」之间二选一，就用 reasoning_effort。这个参数在请求体里是与 thinking 平级的顶层字段，不是塞进 thinking 对象里的。这一点在官方那段控制推理程度的 cURL 示例里看得很清楚——thinking 对象和 reasoning_effort 是并排的两个键，谁也不套着谁：

{
  "model": "glm-5.3",
  "messages": [{"role": "user", "content": "分析一下这道数学题的解题思路"}],
  "thinking": {"type": "enabled"},
  "reasoning_effort": "max"
}

官方文档标注这个参数「仅 GLM-5.2 及以上支持」，并给出了这样一组可选值（以官方文档当前版本为准）：max（官方标注为默认且推荐，深度推理）、high（增强推理）、low（轻度推理）。

这里要提醒一句：官方在 low 这一档后面还跟了一个限定词——原文写的是「轻度推理，仅 GLM-5.3 支持」。抄取值清单的时候很容易把括号里的后半句一起漏掉，只记住三个字符串，结果把 low 当成通用档位到处传。而在紧接着的映射规则里，官方又说明了 GLM-5.2 在 API 请求中传 low 会怎么处理。官方文档这两处的口径并不完全对齐，遇到这种地方别自己脑补哪个更权威，写代码时按下面那段更具体的映射规则来，取值和默认行为仍以官方文档当前版本为准。

真正反直觉的部分在下面。官方分别给出了 API 端点和 Coding Plan 端点两套映射规则，而且两套不一样：

• 在 API 请求中，GLM-5.3 只接受 max、high、low，官方明确说「其余输入将报错」；而 GLM-5.2 能收下的取值多得多，包括 xhigh、medium、minimal、none，其中 none 或 minimal 代表模型放弃思考，low 与 medium 会被映射为 high，xhigh 会被映射为 max。
• 在 Coding Plan 请求中，GLM-5.3 的映射关系又不同：none、minimal、low 归为 low，medium、high 归为 high，xhigh、max 归为 max。

把这几行读透，你会发现一件事：你以为自己在降档，实际上可能一档都没降。在 GLM-5.2 的 API 端点上传 low，按官方说明它会被映射为 high，跟你预期的「轻度推理」不是一回事；真想让模型少想，官方给出的语义是 none 或 minimal。同一个字符串在不同型号、不同端点下含义不同，这个设计确实有点反直觉，写代码时别把 effort 值硬编码成一个全局常量到处复用，至少要按「型号 + 端点」两个维度分开配置。

思考内容藏在 reasoning_content 里，不在 content 里

模型想了什么，不会混进 content。官方响应示例里，choices[0].message 下面同时有 content 和 reasoning_content 两个字段，前者是给用户看的答案，后者是推理过程。

流式场景下则是从 delta 上取。官方 Python 示例的处理方式是先判断属性是否存在再取值：

for chunk in response:
    if not chunk.choices:
        continue
    delta = chunk.choices[0].delta
    if hasattr(delta, 'reasoning_content') and delta.reasoning_content:
        reasoning_content += delta.reasoning_content
    if hasattr(delta, 'content') and delta.content:
        print(delta.content, end="", flush=True)

注意示例里那个 if not chunk.choices: continue——官方自己都写了这一行守卫，说明存在 choices 为空的分片，直接下标取值会崩。另外官方示例里还先取了 chunk.choices[0].delta，再用 hasattr 做属性存在性判断，这套写法比直接 delta.reasoning_content 稳，建议照抄。

官方在「注意事项」里也点明了两件与成本和体验相关的事实：启用深度思考会增加响应时间，思考过程会消耗额外的 Token。具体消耗怎么计入账单、怎么把它控制住，是另一个话题，可以配合站内的API 成本监控怎么做一起看。

交错式思考：工具调用之间还能继续想

《思考模式》页面把三种进阶形态讲清楚了，先说交错式（Interleaved thinking）。

官方的说法是这项能力默认支持，并注明「从 GLM-4.5 开始就支持」。它解决的问题是：模型在调用工具之间、以及收到工具返回结果之后，还能继续思考。这样模型可以先解读每一次工具输出，再决定下一步动作，把多次工具调用和推理步骤串成一条链，而不是「一次性想完、后面机械执行」。

官方在这里挂了一个 Note 框，内容是使用交错思考加工具时的硬要求：必须显式保留 reasoning content，并在返回工具结果时一并返回。这句话对应到代码上就是——你把 tool 角色的消息 append 回 messages 之前，那条 assistant 消息里除了 content 和 tool_calls，还得带上 reasoning_content。官方示例正是这么拼的：

messages.append({
    "role": "assistant",
    "content": content,
    "reasoning_content": reasoning,
    "tool_calls": [...]
})
messages.append({"role": "tool", "tool_call_id": tool_calls[0]["id"], "content": ...})

那么漏传会怎么样？《思考模式》这一页只给了「必须」两个字的硬要求，没有说明漏传之后接口会不会直接报错。能查到的最接近的一条口径在《对话补全》API 参考里：官方在 clear_thinking 的说明中写道，历史 reasoning_content 缺失、裁剪、改写或重排，会导致效果下降或无法生效。注意这句话给的后果是效果层面的，不是「请求失败」。所以排查这类问题时别只盯着报错码——你可能一条错误日志都拿不到，得靠模型行为的变化来反推。

保留式思考：clear_thinking 这个开关是反着的

保留式思考（Preserved thinking）是官方为编码场景引入的能力：让模型在上下文中保留先前 assistant 回合的 reasoning content。官方给出的收益有三条——保持推理连续性与对话完整性、提升模型表现、提高缓存命中率，并说这在真实任务中能节省 tokens。

开关叫 clear_thinking，注意它的语义是反的：官方写的是通过 "clear_thinking": False 在 API 端点中开启保留式思考。字段名说的是「清除思考」，所以「不清除」才等于「保留」，第一次写很容易传反。

默认状态两个端点不一样，官方用 Check 框专门标了：Coding Plan 端点默认开启，标准 API 端点默认关闭（以官方文档当前版本为准）。也就是说，如果你在 Coding Plan 上调通了一套流程，平移到标准 API 端点会发现行为对不上，得自己把 clear_thinking 显式传成 False。

还有一条约束值得抄下来贴到代码注释里。官方原话是：需要把完整、未修改的 reasoning content 传回 API，所有连续的 reasoning content 必须与模型在原始请求期间生成的序列完全一致，不要重新排序或修改这些 content，否则会降低效果并影响缓存命中。很多团队为了省上下文，习惯把历史消息裁剪、摘要、去重再送回去——这套做法在保留式思考下会同时打掉两样东西：推理效果和缓存。缓存这条线的机制可以对照GLM 上下文缓存怎么才能命中那篇看，两者是咬合在一起的。

在请求里，这个开关是塞进 thinking 对象里的，跟 type 平级：

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

官方示例用的是 OpenAI SDK 加 extra_body 的写法，把带 clear_thinking 的整个 thinking 对象塞在 extra_body 里透传下去。这个细节值得留意：你如果用的是各种封装层、网关、Agent 框架，要先确认它给不给你透传自定义字段的口子，否则这个能力根本传不下去。

轮级思考：在同一个会话里按轮开关

第三种形态叫轮级思考（Turn-level Thinking），官方定义是「按轮控制推理计算」——同一调用会话中，每一轮请求都可以独立选择开启或关闭思考。官方标注这是 GLM-4.7 新引入的能力。

官方列出的三条价值，翻译成工程语言就是：轻量轮次（问个事实、改个措辞）关掉思考换响应速度，重任务轮次（复杂规划、多约束推理、代码调试）打开思考换正确率；开关在会话内可随时切换，模型仍能保持对话连贯与输出风格一致；Agent 场景里，快速执行的工具轮次降低推理开销，需要综合工具结果做决策的轮次再开启深度思考。

官方还补了一句省事的话：这套机制同时适用于交错式与保留式思考，无需手动区分。所以你不需要在代码里维护「现在是哪种思考模式」的状态机，只要每轮请求把 thinking 对象按当轮需要拼好，再记得把历史 reasoning_content 带上就行。

什么时候开、什么时候关

官方文档《深度思考》的「最佳实践」直接给了两张场景清单，可以拿来当默认策略：

推荐启用的场景是复杂问题分析和解决、多步骤推理任务、技术方案设计、策略规划和决策、学术研究和分析、创意写作和内容创作。可以禁用的场景是简单事实查询、基础翻译任务、简单分类判断、快速问答需求。

这两张单子的共同逻辑是「答案是不是靠推导出来的」。翻译、分类、事实查询这类任务，答案基本是映射关系，多想一步没有增量收益，只增加延迟和 Token 消耗；而方案设计、多约束规划，模型不推一遍就容易漏条件。落到产品上，比较务实的做法是按功能入口而不是按用户请求来配置：一个应用里，搜索框走关思考，「帮我写方案」按钮走开思考，别指望在一个统一的接口里靠 prompt 让模型自己决定。

最后，三个最容易栽的坑

第一，别假设关思考这条路一直在。官方已经明确 GLM-5.3 传 disabled 会报错，你的代码如果无条件往请求里塞 "thinking": {"type": "disabled"}，一旦换型号就是一片报错。稳妥写法是把「本型号支不支持关思考」做成配置项，而不是写死在请求构造函数里。相关的报错定位思路可以看GLM API 常见报错怎么排查。

第二，reasoning_effort 传下去不等于生效成你想的那一档。上面那套映射规则决定了同一个字符串在不同型号、不同端点下含义不同。真要验证自己降档有没有生效，看 usage 里的 token 结构变化，比看参数传没传下去更可靠。

第三，reasoning_content 是有状态的，不是日志。很多人第一反应是把它当调试信息打到日志里就丢掉，结果交错式思考和保留式思考都拿不到应有的效果。官方在这两处的措辞其实是不一样的：交错式那一节的 Note 框只要求「必须显式保留 Reasoning content，并在返回工具结果时一并返回」，说的是别丢；保留式那一节的 Check 框要求得更细，传回去的必须是完整、未修改的 reasoning content，而且不要重新排序或修改。别把后面这条更严的要求想当然地套到前面那条上，但两处指向的是同一件事——这份内容是要回传的输入，不是可以随手丢掉的输出。

一句话收尾：GLM 这套思考体系的复杂度不在开关本身，而在默认值、映射规则、端点差异这三处不一致。写接入层的时候，把这三处都做成显式配置而不是隐式默认，后面换型号才不至于返工。所有取值和默认行为以官方文档当前版本为准。