# 切到 GLM-5.3 之后，Thinking 参数写成 disabled 为什么请求直接失败？

**URL:** <https://www.shiqidu.com/t/topic/1892>\
**Category:** 人工智能\
**Tags:** 问与答, API, AICoding\
**Created:** [2026 年11 月 2 日 04:16 UTC](https://www.shiqidu.com/t/topic/1892 "2026-11-02T04:16:34Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

作者： ![shiqidu\_editor](https://www.shiqidu.com/user_avatar/www.shiqidu.com/shiqidu_editor/32/528_2.png) [@shiqidu\_editor](https://www.shiqidu.com/u/shiqidu_editor)\
发布日期： [2026 年11 月 2 日 04:16 UTC](https://www.shiqidu.com/t/topic/1892/1 "2026-11-02T04:16:34Z")

</div>

把请求里的 `model` 改成 `glm-5.3` 以后，旧习惯里用来关思考的 `thinking.type: "disabled"` 一送上去，整段会被拒。智谱文档《[GLM-5.3](https://docs.bigmodel.cn/cn/guide/models/text/glm-5.3)》写得很死：这个型号会始终启用思考，不再支持禁用。迁模型 ID 之前如果参数还按旧习惯传，很容易卡在这一步。

## 文档里的参数表

《GLM-5.3》页的功能变更一段写明：目前只处理文本，支持 1M 上下文窗口，最大输出 Tokens 为 128K。思考相关参数如下：

- `thinking.type`：只接受 `enabled`，默认也是 `enabled`，不支持禁用。
- `reasoning_effort`：`low`、`high`、`max`，默认 `max`。文档对三档的说明是轻量 / 增强 / 深度推理。

页面上的迁移提示原文大意是：若应用里还在用 `thinking.type: "disabled"`，请在把模型 ID 更新为 `glm-5.3` **之前** ，先改成 `enabled`，并把 `reasoning_effort` 设为 `low`。否则请求会失败。复杂 Coding 任务文档建议用 `max`。

最小请求形态可以按文档示例收成：

```json
{
  "model": "glm-5.3",
  "messages": [{"role": "user", "content": "…"}],
  "thinking": { "type": "enabled" },
  "reasoning_effort": "max"
}

```

日常想省一点思考开销，把 `reasoning_effort` 调成 `low` 即可，不要再传 `disabled`。需要更深推理时再用 `high` 或 `max`。三档怎么选没有统一公式，文档只给了 Coding 等复杂任务偏 `max` 的建议。延迟和费用体感要自己用同一条提示对比，这篇不引用任何竞品分数表。

## 迁的时候先改哪一步

容易踩坑的顺序是：先改 `model`，请求一发就失败，再回头翻文档。按迁移提示，应先改客户端或网关里的 `thinking` / `reasoning_effort`，确认不再出现 `disabled`，再切模型 ID。代理层、SDK 封装、提示词模板、CI 里的 fixture 如果还写着旧字段，也会在切模型后一起爆。

有的封装会把「关闭思考」做成布尔开关，内部仍序列化成 `thinking.type: "disabled"`。开关在旧模型上能用，不代表新模型还认。切 `glm-5.3` 前，把序列化结果抓一条出来看字段，比只改 UI 开关更靠谱。流式和非流式示例在文档里都要求带上 `thinking.type: "enabled"`，别只改了非流式路径。

接入端点文档列了 OpenAI Chat Completions、OpenAI Response、Anthropic Message 几类 Base URL。若曾经订阅过 GLM Coding Plan（含已过期），文档备注暂时只能走 OpenAI Chat Completions 协议调模型 API，其余协议的开放进度以页面后续更新为准。这篇只核思考参数。套餐积分、Flash / FlashX 进不进 Coding Plan 另说，不在这里展开价目。

排错时先看返回体里是不是明确抱怨 `thinking` / `disabled`，再查本地配置。有的网关会把未知字段丢掉，表面上看请求「成功了」，实际上思考强度一直停在默认 `max`，账单和延迟都会和预期不一致。另一类相反：网关把旧的 `disabled` 原样转发给新模型，于是整段失败。两种都要在代理日志里把 outbound JSON 打出来对一下。

文档里的能力列表还提到流式输出、Function Calling、上下文缓存、结构化输出等，这些和「能不能关思考」不是同一件事。思考被迫开启之后，工具调用轮次里还要不要回传思维链字段，以智谱深度思考专题文档为准，这篇不把旧模型的习惯直接搬过来。基准评测数字、和其他型号的对比表一律不抄，避免写成跑分帖。

如果业务上必须「完全不思考」的短链路，按当前文档做不到，只能继续留在仍支持 `disabled` 的旧模型 ID，或接受 `reasoning_effort: "low"` 作为最轻的一档。把模型名先改掉再指望参数兼容，是这次迁移里最常见的顺序错误。团队若有统一的模型路由配置，把 `glm-5.3` 的默认思考参数写进同一处，比让每个业务服务自己猜字段名省事。

已经切到 `glm-5.3` 的，你们是统一把 `reasoning_effort` 钉在 `low`，还是按任务在 `low` / `high` / `max` 之间切换？