Dify 1.11.4 配置 LLM 深度思考：获取 reasoning_content 并支持前端渲染

Dify 1.11.4 配置 LLM 深度思考：获取 reasoning_content 并支持前端渲染

本文基于一套真实运行的 Dify 1.11.4 环境，完整演示以下内容：

• 使用 OpenAI-API-compatible 接入支持思考模式的模型；
• 使用通义供应商配置 qwen3.6-plus；
• 在 LLM 节点开启思考模式和推理标签分离；
• 从 LLM 节点输出中取得 reasoning_content；
• 通过 Dify API 的 SSE 事件把思考内容交给前端渲染；
• 排查"开了思考模式但没有深度思考内容"的常见问题。

一、先理解 Dify 的深度思考链路

在 Dify 1.11.4 中，"让模型思考"和"把思考内容拆出来"是两个不同动作：

LLM 节点 enable_thinking=true
            ↓
模型/供应商返回推理内容
            ↓
启用推理标签分离 reasoning_format=separated
            ↓
LLM 节点输出：
  text                最终答案
  reasoning_content   思考内容
            ↓
SSE node_finished.data.outputs
            ↓
前端分别渲染"思考过程"和"最终答案"

两个开关的职责如下：

配置	作用
思考模式	告诉模型生成推理内容，对应模型参数 enable_thinking=true
启用推理标签分离	将 <think>...</think> 一类推理内容从正文中剥离，写入 reasoning_content

Dify 1.11.4 的 LLM 节点最终会生成类似下面的输出：

{
  "text": "最终回答",
  "reasoning_content": "模型的思考过程",
  "usage": {},
  "finish_reason": "stop"
}

如果不启用推理标签分离，兼容模式会保留正文中的 <think> 标签，而 reasoning_content 通常为空。新流程建议使用分离模式。

二、进入 Dify 模型供应商设置

1. 打开设置

进入 Dify 工作室，点击右上角头像，在菜单中点击"设置"。

2. 打开模型供应商

进入设置后，在左侧点击"模型供应商"。

模型供应商页面会列出已经安装和配置的供应商。本文使用两种接入方式：

• OpenAI-API-compatible：适合 OpenAI 协议兼容的私有模型服务；
• 通义：直接使用 DashScope API Key 调用千问模型。

三、方式一：配置 OpenAI-API-compatible

1. 找到模型和凭据

找到 OpenAI-API-compatible，点击"显示模型"，确认目标模型已经存在。本文以 mimo-v2.5 为例。

如果还没有目标模型，可以先添加模型；如果已经存在，则点击"管理凭据"。

2. 编辑模型凭据

将鼠标悬停到凭据项上，点击编辑图标。

3. 填写模型信息

需要重点检查以下字段：

• 模型名称必须与上游服务中的模型 ID 完全一致；
• API Key 填写上游服务签发的密钥；
• API Endpoint 通常以 /v1 结尾，例如 https://llm.example.com/v1；
• 模型模式选择 Chat；
• 上下文长度、最大生成长度应与真实模型能力一致。

不要直接照抄截图中的示例地址。截图只用于说明字段位置，生产环境必须填写自己的 HTTPS 地址和密钥。

4. 配置"思考模式支持"

继续向下找到"思考模式支持"。Dify 1.11.4 提供三个选项：

• 仅支持思考模式；
• 仅支持非思考模式；
• 两种模式都支持。

如果模型既能普通回答，也能通过参数动态开启思考，选择"两种模式都支持"。这样 LLM 节点参数面板中才可以自由切换思考模式。 OpenAI-compatible 服务还需要满足以下条件：

1. 上游模型本身支持推理模式；
2. 供应商插件能正确传递 enable_thinking 等参数；
3. 上游返回的推理内容能被插件转换为 Dify 可识别的推理文本，例如 reasoning_content 或 <think>...</think>；
4. 流式返回格式与 OpenAI Chat Completions 协议兼容。

只在 Dify 中勾选"支持思考模式"，不能让一个原本不支持推理的模型凭空产生 reasoning_content。

四、方式二：配置通义千问

1. 打开通义供应商配置

在模型供应商页面找到"通义"，点击"配置"或"管理凭据"。

2. 编辑通义 API Key

悬停到已有凭据，点击编辑按钮；没有凭据时直接新增。

3. 填写 DashScope API Key

填写 DashScope API Key，并根据 Key 所属地域选择是否使用国际端点。

这里经常出现一个配置错误：国内站创建的 Key 与国际站端点混用。出现鉴权失败或模型不存在时，应先核对 Key 的地域和"国际端点"开关。

4. 确认目标模型可用

展开通义模型列表，确认 qwen3.6-plus 已启用且状态正常。

在本文测试环境中，qwen3.6-plus 的参数列表包含：

• enable_thinking：是否开启思考模式；
• thinking_budget：思考长度限制；
• temperature、max_tokens、top_p 等常规模型参数。

如果选择模型后看不到"思考模式"，通常说明当前模型定义或通义插件版本没有声明该参数。此时应更新插件，或选择明确支持思考模式的千问模型。

五、在 LLM 节点开启深度思考

1. 选中 LLM 节点

进入 Chatflow 或 Workflow 编排页面，点击需要开启思考模式的 LLM 节点。

2. 打开模型参数

确认节点使用的是目标模型，然后点击模型名称右侧的参数图标。

3. 打开两个关键开关

在参数面板中完成以下设置：

1. 将"思考模式"设为 True；
2. 根据业务需要设置"思考长度限制"；
3. 在 LLM 节点设置面板中打开"启用推理标签分离"。

thinking_budget 越大，模型可使用的思考长度通常越长，但延迟和 Token 消耗也可能增加。建议先从 512～2048 的范围验证，再结合模型文档和业务复杂度调整。

4. 检查输出变量

开启推理标签分离后，LLM 节点输出变量中会出现：

• text：最终回答；
• reasoning_content：推理内容；
• usage：Token 和费用信息。

后续节点可以通过变量选择器引用它。变量表达式示例：

{{#llm.reasoning_content#}}

其中 llm 是节点 ID。实际编排时建议通过 Dify 变量选择器插入，不要手工猜测节点 ID。

六、真实运行效果对比

测试问题为：

三个盒子分别贴着"苹果""橙子""苹果和橙子"的标签，但三个标签全都贴错了。你只能从一个盒子里拿出一个水果，如何确定三个盒子的正确标签？

1. 关闭思考模式

关闭思考模式后，LLM 节点能够正常输出答案，但 reasoning_content 是空字符串。

2. 开启思考模式和推理标签分离

开启后，同一个问题的 LLM 节点输出出现了非空 reasoning_content。

展开输出区域，可以看到完整推理文本与最终回答已经成为两个独立字段。

本次单次测试结果如下，仅用于验证字段是否产生，不作为性能基准：

状态	reasoning_content	总 Token	LLM 节点运行时间
关闭思考模式	空字符串	809	13.68 秒
开启思考模式，预算 512	1885 个字符	1013	18.08 秒

这里有一个很容易误解的细节：

LLM 节点输出了 reasoning_content，不代表"直接回复"节点会自动把它显示在聊天窗口。

如果"直接回复"只引用 LLM.text，Dify 预览区通常只显示最终答案。要展示独立思考区域，可以选择以下方式之一：

• 让前端从 SSE 的 LLM node_finished 事件读取 reasoning_content；
• 在流程中显式引用 LLM.reasoning_content，再交给后续节点或结束节点；
• 在"直接回复"中同时拼接思考和答案，但这种方式不利于前端折叠展示，也可能暴露不应公开的内部推理。

七、通过 API 和 SSE 提取 reasoning_content

1. 调用 Dify 流式接口

Chatflow 一般调用：

POST https://your-dify.example.com/v1/chat-messages
Authorization: Bearer app-REDACTED
Content-Type: application/json

{
  "inputs": {},
  "query": "用户问题",
  "response_mode": "streaming",
  "conversation_id": "",
  "user": "user-001"
}

普通 Workflow 一般调用 /v1/workflows/run。两类应用的请求结构不同，应以应用"访问 API"页面生成的示例为准。

安全上不要把 app-xxxx 直接写进浏览器代码。推荐由自己的后端代理请求 Dify，浏览器只连接业务后端的 SSE 接口。

2. 识别 node_finished 事件

真实运行中，LLM 节点完成事件的关键结构如下：

{
  "event": "node_finished",
  "data": {
    "node_id": "llm",
    "node_type": "llm",
    "status": "succeeded",
    "outputs": {
      "text": "最终回答",
      "reasoning_content": "模型思考过程"
    }
  }
}

最终回答通常还会通过 message 事件流式返回。前端可以分别处理：

• message：持续追加最终回答；
• node_finished：保存完整 reasoning_content；
• message_end：结束加载状态并读取用量信息。

Dify 1.11.4 的标准 reasoning_content 字段是在节点完成时稳定取得的。如果要求"思考内容逐 Token 实时流出"，还需要确认当前供应商插件和 Dify 事件实现是否提供独立推理分片，不能只依赖 node_finished。

3. 前端 SSE 解析示例

下面的代码假设浏览器请求的是自己的后端代理 /api/dify/chat：

async function streamDify(query, handlers) {
  const response = await fetch('/api/dify/chat', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ query })
  })

  if (!response.ok || !response.body) {
    throw new Error(`Dify request failed: ${response.status}`)
  }

  const reader = response.body.getReader()
  const decoder = new TextDecoder('utf-8')
  let buffer = ''

  while (true) {
    const { done, value } = await reader.read()
    if (done) break

    buffer += decoder.decode(value, { stream: true })
    const packets = buffer.split('\n\n')
    buffer = packets.pop() ?? ''

    for (const packet of packets) {
      const dataLine = packet
        .split('\n')
        .find(line => line.startsWith('data:'))

      if (!dataLine) continue

      const payload = JSON.parse(dataLine.slice(5).trim())

      if (payload.event === 'message') {
        handlers.onAnswerChunk?.(payload.answer ?? '')
      }

      if (
        payload.event === 'node_finished'
        && payload.data?.node_type === 'llm'
      ) {
        const outputs = payload.data.outputs ?? {}
        handlers.onReasoning?.(outputs.reasoning_content ?? '')
        handlers.onFinalText?.(outputs.text ?? '')
      }

      if (payload.event === 'message_end') {
        handlers.onFinished?.(payload.metadata ?? {})
      }
    }
  }
}

前端展示时，可以把思考过程放在默认折叠区域：

<details className="reasoning-panel">
  <summary>查看思考过程</summary>
  <pre>{reasoningContent}</pre>
</details>

<article className="answer-panel">
  {answer}
</article>

如果流程中有多个 LLM 节点，不能只判断 node_type === 'llm'，还应同时判断目标 node_id，否则可能把改写、分类或总结节点的推理内容展示给用户。

八、常见问题排查

1. LLM 参数中没有"思考模式"

依次检查：

1. 当前模型是否真的支持思考模式；
2. 模型供应商配置是否声明"仅支持思考"或"两种模式都支持"；
3. 通义或 OpenAI-compatible 插件是否需要更新；
4. 切换模型后是否重新保存了 LLM 节点。

2. 已经打开开关，但 reasoning_content 仍为空

优先在"上次运行"中检查运行快照和输出，不要只看编辑面板。重点确认：

• 实际运行参数是否为 enable_thinking=true；
• 是否打开"启用推理标签分离"；
• 模型返回中是否真的存在推理内容；
• OpenAI-compatible 服务是否丢弃了推理字段；
• 模型返回的 <think> 标签是否完整；
• 问题是否过于简单，模型主动省略了推理过程。

本文调试时就遇到过编辑脚本看似点开了开关，但运行快照中实际仍是 enable_thinking=false 的情况。判断依据应以"上次运行"数据为准。

3. text 中还有 <think> 标签

通常是"启用推理标签分离"没有打开，或者模型输出的标签格式不完整。开启分离后再次运行，并检查 reasoning_content 是否产生。

4. 节点有 reasoning_content，但聊天窗口没有"深度思考"

检查"直接回复"节点是否只引用了 LLM.text。reasoning_content 是独立输出，默认不会自动拼接进最终回复。前端应从 SSE 节点事件读取，或者在流程中显式传递它。

5. 通义提示鉴权失败或模型不存在

检查 DashScope Key 的地域、国际端点开关、模型是否已开通，以及服务器是否能访问对应 DashScope 地址。

6. 开启思考后响应明显变慢

这是正常现象。可以降低 thinking_budget、限制最大 Token，或只对复杂问题开启思考模式。生产环境还应监控超时、Token 成本和并发占用。

九、结论

在 Dify 1.11.4 中实现可供前端渲染的深度思考，需要同时打通四层：

1. 模型本身支持推理；
2. 模型供应商正确传递思考参数和推理内容；
3. LLM 节点开启思考模式与推理标签分离；
4. 前端从 LLM 节点事件中读取 reasoning_content，而不是只消费最终 message。

配置完成后，最可靠的验收方式不是观察回答是否"看起来更详细"，而是在 LLM 节点"上次运行"中确认：

{
  "text": "非空最终回答",
  "reasoning_content": "非空思考内容"
}

只要这两个字段稳定分离，前端就可以实现"思考中""查看思考过程"和"最终答案"等不同展示状态。