问题摘要：DeepSeek V4（flash / pro）在 OpenClaw 中进行多轮对话时，第二轮开始 API 返回 HTTP 400 “The reasoning_content in the thinking mode must be passed back to the API”。根因是 OpenClaw 的 parseThinkingSignature 函数无法处理 DeepSeek 的非 JSON 签名字段，导致 thinking block 被丢弃。本文提供 3 种修复方案。

发生了什么错误

DeepSeek V4 是当前性价比最高的推理模型之一。但在 OpenClaw 中接入后，单轮对话正常，一到第二轮就报错：

1
400 The `reasoning_content` in the thinking mode must be passed back to the API.

这个错误说明：第一轮 DeepSeek 返回了思考内容（reasoning_content），但第二轮请求中缺少了这个字段。

为什么单轮正常，多轮就报错

因为单轮对话不需要上下文压缩。多轮对话时，OpenClaw 会把历史消息压缩（compaction），这中间经过了序列化和反序列化：

  1. 第一轮 DeepSeek 返回思考内容 → OpenClaw 存为 thinking block，thinkingSignature = "reasoning_content"
  2. 第二轮请求前做 compaction → parseThinkingSignature("reasoning_content") 被调用
  3. 函数尝试 JSON.parse("reasoning_content") → 抛出异常 → catch 里 return null
  4. thinking block 被丢弃 → DeepSeek API 校验失败 → 400

根因：parseThinkingSignature 的格式假设

直接定位到问题函数（位于 OpenClaw 的 compaction-successor-transcript.js）：

1
2
3
4
5
6
7
8
9
function parseThinkingSignature(value) {
  if (typeof value !== "string" || value.trim().length === 0) return null;
  try {
    const signature = toReasoningSignature(JSON.parse(value));
    return signature ? parseReasoningItem(signature) : null;
  } catch {
    return null; // <-- 非JSON格式直接丢弃
  }
}

函数假设 thinkingSignature 总是 JSON 格式（符合 OpenAI Responses API 规范），但 DeepSeek 直接用了纯字段名字符串 "reasoning_content"。

格式差异对比

属性 OpenAI 格式 DeepSeek 格式
thinkingSignature JSON 字符串（有结构） 纯字符串 "reasoning_content"
JSON.parse 结果 正常解析 报错
compaction 后 保留 thinking block 丢弃 → 400

社区修复进展

编号 类型 状态 说明
#72915 Issue Open 当前问题主 issue
#71455 Issue Closed 同名问题
#71473 PR Closed（未合并） 修复 reasoning_content，审查后被关闭
#71915 Issue Closed DeepSeek 导致的 Gateway 100% CPU
#72132 PR Open 测试 PR

PR #71473 未合并的原因：审查者认为不应在核心代码中为特定 provider 做特殊处理。但目前没有更好的解决方案被提出。

3 种修复方案

方案 A：本地 patch（推荐，立即生效）

在 parseThinkingSignature 的 catch 块中添加 fallback：

1
2
3
4
5
6
7
8
9
10
11
12
13
function parseThinkingSignature(value) {
  if (typeof value !== "string" || value.trim().length === 0) return null;
  try {
    const signature = toReasoningSignature(JSON.parse(value));
    return signature ? parseReasoningItem(signature) : null;
  } catch {
    // Fallback: DeepSeek uses raw field name, not JSON
    if (value === "reasoning_content") {
      return { type: "reasoning_content" };
    }
    return null;
  }
}

patch 文件在 OpenClaw 的 dist/ 目录下，搜索 compaction-successor-transcript 找到对应的 JS 文件直接修改即可。

方案 B：换模型（临时绕行）

使用不返回 thinking block 的模型，如 MiMo V2.5、GLM-5、Kimi K2.5 等。这些模型的多轮对话正常。

方案 C：升级版本（不一定修复）

从 v2026.4.21 升级到 v2026.4.26 可获取 Venice provider 的相关变通修复，但 DeepSeek 核心问题未修复。

如果你也遇到这个问题

最快解决路径：直接应用方案 A 的本地 patch，5 分钟搞定。然后在 GitHub Issue #72915 下回复你的版本信息和日志，帮助社区推动官方修复。

验证修复：patch 后发起多轮对话测试，观察不再出现 400 错误即可。

经验

  1. 多 provider 兼容性是 Agent 框架的核心挑战。不同厂商的 API 规范再接近，edge case 总会暴露。
  2. compaction 序列化/反序列化链路很脆弱。thinking block、tool call replay 在压缩链条上极易出格式问题。
  3. PR 被搁置是常态。开源项目代码审查周期长，生产环境依赖时本地 patch 更可靠。
  4. 升级不解决所有问题。升级前查看 release notes + 关联 issue。

FAQ

这个错误只影响多轮对话吗？

是。单轮对话不经过 compaction，不会触发该问题。

patch 后需要重启 OpenClaw 吗？

需要。修改 dist 文件后重启 gateway 才能生效。

DeepSeek V4 Flash 和 Pro 都会触发吗？

都会，因为两者使用相同的 reasoning_content 签名格式。

官方什么时候修复？

暂无合并计划。建议在 #72915 下留言催促。

用其他 Agent 框架（Dify、FastGPT）会碰到这个问题吗？

不会。这是 OpenClaw 特有的 compaction 实现导致的。其他框架的上下文压缩机制不同。

补充信息

  • OpenClaw 版本：2026.4.21 → 2026.4.26
  • DeepSeek 模型：deepseek-v4-flash / deepseek-v4-pro
  • DeepSeek API：api.deepseek.com/v1（兼容 OpenAI 格式）
  • 关联 Issue：#72915
  • 关联 PR：#71473 / #72132