【Dify工作流避坑：LLM思考标签造成大量Token浪费！90%开发者都忽略的核心优化】-平芜编程栈

前言

很多开发者在使用Dify搭建AI工作流时，都会遇到一个诡异问题：
聊天页面前端输出干净整洁，只有最终答案；但工作流下游节点，却会完整接收模型的思考过程。
不管切换DeepSeek、Qwen、LLaMA等各类推理模型，问题始终存在。大部分人误以为是模型Bug、配置问题，实则是Dify前后端机制不一致导致的隐性Token损耗。
这也是绝大多数Dify工作流Token消耗高、响应慢、链路推理冗余的核心隐藏原因，本文彻底讲透原理、危害、一站式解决方案。

一、现象复现：前后端输出不一致

1.1 前端聊天页面（干净输出）

用户对话交互时，只会展示模型最终结果，无任何思考过程：

WR STU001

1.2 工作流下游节点（脏数据输出）

工作流中LLM节点的完整输出数据如下，思考过程和最终答案全部透传：

"query": "<think>\n用户的输入是STU001 张明，需要转换成WR STU001。首先按照要求，直接输出WR STU001就好了，不要加其他东西。检查一下，没错，就直接返回WR STU001。\n</think>WR STU001" }

看似微小的差异，在多节点串联的工作流中，会造成成倍的Token浪费。

二、核心原理：不是模型Bug，是Dify机制差异

2.1 为什么前端干净？

Dify前端内置了专门的清洗逻辑（preprocessThinkTag）：

流式接收模型数据时，自动识别、剥离、折叠思考块
仅对用户展示最终有效答案，隐藏所有推理过程
前端默认强制清洗，无需人工干预

2.2 为什么工作流脏数据？

Dify后端工作流的设计逻辑和前端完全相反：

Workflow LLM节点默认原样透传模型原始输出
为了保留完整推理数据，后端默认不做任何字段剥离与清洗
所有推理型模型输出的思考标签、冗余推理文本，会全部传入下游节点

2.3 换模型无效的根本原因

目前主流开源/商用推理模型（DeepSeek-R1、Qwen3、LLaMA-Reasoning等），训练对齐逻辑一致：默认输出带<think>推理块的完整内容。
所以无论切换多少模型，只要工作流未做清洗，冗余思考Token必然存在。

三、隐形危害：90%开发者都在白白浪费Token

很多人觉得“多一点文本无所谓”，但在多节点串联、循环调用、多轮推理的工作流中，危害被无限放大：

3.1 无效Token重复计费

场景：模型输出100Token思考过程 + 5Token有效答案
未优化时，下游LLM、代码、检索节点，会把105Token全部作为输入重新计费，有效Token占比不足5%，95%的Token都是无效消耗。

3.2 工作流响应速度变慢

输入文本越长，模型推理、节点数据解析耗时越久，冗余文本会直接拖慢整条工作流的执行速度。

3.3 干扰下游业务逻辑

若下游是数据格式化、关键词提取、数据库写入、接口推送节点，多余的思考文本会导致格式报错、数据错乱、匹配失败，极大降低工作流稳定性。

四、两种最优解决方案（全覆盖、零坑）

根据你的Dify版本，选择对应方案，彻底根治思考标签冗余问题。

方案一：官方原生分离思考模式（推荐，Dify 1.9+）

Dify 1.9及以上版本新增推理格式分离能力，官方原生支持剥离思考过程，无需代码：

编辑LLM节点，打开「高级设置」
找到思考模式/推理格式（Reasoning Format）
将默认的 tagged（混合输出）改为 separated（分离输出）
开启后节点会拆分出两个独立字段：

text：纯干净最终答案（无任何思考标签）
reasoning_content：独立存储完整思考过程
下游节点直接引用 {{llm.text}} 即可，零冗余、零代码、最稳定。

方案二：代码节点正则清洗（万能适配，全版本通用）

适用于Dify 1.9以下旧版本，兼容所有模型，100%剥离思考内容，适配所有工作流场景。

使用步骤

LLM节点后新增「代码节点」
输入变量绑定上游LLM的输出字段（如query）
粘贴以下通用清洗代码

通用清洗代码

importredefmain(query:str)->dict:# 全局匹配并剥离完整think标签及内部所有内容clean_text=re.sub(r'<think>[\s\S]*?</think>','',query)# 清除首尾多余换行、空格clean_text=clean_text.strip()return{"clean_result":clean_text}