Dify 1.11.4 获取思维链 reasoning_content 并前端折叠渲染

关注

VIP免费原创最新推荐文章于 2026-09-16 14:45:54 发布 217 阅读 AI 写同款· GEO 优化 ›

Dify对接DeepSeek深度思考：完整获取并渲染reasoning_content实战随着大语言模型进入推理时代，思维链成为提升回答质量的关键机制。DeepSeek、Kimi等模型在输出最终答案前会生成一段reasoning_content，记录完整的推理过程。然而在Dify这类低代码平台中，如何将深度思考内容从模型API透传到前端，成为开发者普遍面临的难题。本文从流式输出原理出发，剖析Dify 1.11.4模型适配层对reasoning_content的封装逻辑，针对“reasoning_content must be passed back to the api”等高频报错给出三种解决方阅读详情

最近我把 Dify 社区版从旧版本升到了 1.11.4，顺手接了一个带“深度思考”能力的 LLM 模型。原本以为就是配个 API Key 的事，结果真正折腾起来才发现：如果直接用 Dify 的 LLM 节点，模型返回的 reasoning_content （也就是思维链内容）会被默认丢弃，用户只能看到最终答案，中间那串“思考过程”根本不会出现在消息里。更进一步，在多轮对话场景下，某些 OpenAI 兼容接口还会因为上一轮没有回传 reasoning_content 而直接报 HTTP 400，提示必须把思考内容原样带回。

这篇文章就用我实际跑通的方案，讲讲怎么在 Dify 1.11.4 里拿到 reasoning_content ，以及如何在前端把它渲染成可以折叠的“思维链”区块。整个方案不依赖改 Dify 内核，只用到工作流里的 HTTP 请求节点、代码节点和一点前端代码，适用于大多数想展示推理过程的开发者。

1. 先说结论：为什么 Dify 里看不到“思考过程”

1.1 深度思考模型返回的不只是一个答案

现在不少大模型都加入了“先思考、后回答”的机制。以 DeepSeek 的深度思考模型为例，API 返回的消息体里通常包含两个关键字段：

content ：最终回答给用户的文本。
reasoning_content ：模型内部生成的思考过程，包含推理步骤、中间结论、自我纠错等。

两者的关系，可以理解成“开会讨论的草稿”和“对外发布的会议纪要”。前者信息量大，但不适合直接呈现；后者是经过整理后的正经答案。但对很多 AI 应用来说， 用户其实很想看到草稿，因为草稿能展示模型是怎么一步步推导的，交互体验完全不同。 我见过不少知识库问答、代码助手、写作类应用，都把思维链折叠展示作为一项核心体验来宣传。

问题在于，Dify 的 LLM 节点在设计上主要消费的是最终 content 字段。 reasoning_content 这类扩展字段在模型供应商适配层里往往被过滤掉了。哪怕你在界面里选择了支持深度思考的模型，Dify 工作流里能拿到的东西也还是只有答案，思考过程根本没进入变量体系。

1.2 我们需要解决的问题其实有三个

单看标题：“Dify 1.11.4 配置 LLM 深度思考：获取 reasoning_content 并支持前端渲染”，拆开来看，实际要解决三件事：

让 Dify 能拿到 reasoning_content ：既然默认拿不到，就要换一种调用方式，把原始响应交给代码节点解析。
正确处理多轮对话中的 reasoning_content 回传 ：这也是很多人忽略的点。部分 API 在 thinking 模式下，要求后续请求的 assistant 消息里带着上一轮的推理内容，否则直接报错。
把推理内容展示到前端 ：Dify 默认聊天界面不会渲染未知字段，我们需要自定义输出格式和前端解析逻辑。

这篇文章的测试环境是 Dify 1.11.4 社区版，部署方式是 Docker Compose。后面提到的做法在当前版本里都能直接用；新版本（比如 1.17.x）虽然也在不断调整模型能力，但这个“直接调 API + 自解析”的思路是通用的，换到其他版本也不会过时。

2. 准备工作：确认模型接入与接口行为

2.1 在 Dify 里配置模型供应商，但别对它期望太高

首先还是要做好基础接入。登录 Dify 后台，进入“设置 -> 模型供应商”，找到 DeepSeek 或者其他支持 OpenAI 兼容接口的供应商，填入 API Key。Dify 1.11.4 社区版内置了 DeepSeek 供应商配置，选好后测试一下连接，能通就算成功。

不过这里要提前打个预防针： 供应商配置通过，只能保证模型能出答案，并不代表 reasoning_content 会出现在工作流变量里。 我试过直接在 LLM 节点的输出里找扩展字段，也试过在结束节点里绑定各种变量，结果都一样——Dify 把模型响应格式化成了统一的字符串，思考内容压根没有进入可选项。所以接下来的操作，不能依赖 Dify 的模型适配层。

2.2 先用 curl 验证 API 返回了什么

在动工作流之前，建议先用一条 curl 命令搞清楚目标 API 的返回结构。这样后面写 HTTP 请求节点时，你才知道该从哪里取字段。

以 DeepSeek 官方 API 为例，非流式请求大概是这样的：

curl https://api.deepseek.com/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-xxx" \
  -d '{
    "model": "deepseek-reasoner",
    "messages": [
      {"role": "user", "content": "请解释一下什么是递归？"}
    ],
    "stream": false
  }'

返回的 JSON 主体结构大致如下：

{
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "递归就是函数直接或间接调用自身。",
        "reasoning_content": "用户问什么是递归。递归是一种编程技巧，核心是函数调用自身。需要拆解为基线条件和递归条件。"
      },
      "index": 0
    }
  ]
}