Dify 企业级实验05Token 成本控制——AI 应用省钱改造怎么做Dify 实验系列 · 企业级 05/12 | 实验编号DIFY-104-05基于 Dify 1.16.1 实测2026-081. 业务场景先讲一个我们实际遇到的场景。AI 应用上线后老板每个月都要看一张账单客服问答工作流每月 5 万次调用单次平均消耗 2.8 万 Token——Token 是持续支出不是一次性开发成本调用量越大账单越吓人。我们第一次接这类需求时第一反应也是「省钱不就是压缩 prompt 字数嘛」。真正动手才发现——prompt 省那 1000 Token杯水车薪真正烧钱的是「用错了工具」规则能算的用 LLM 生成分类器能判的用 LLM 生成。省钱不是抠门是把每个环节放到它该在的位置上。同一个结果用 LLM 生成要花钱用规则算一分钱不花用 LLM 生成要花钱用分类器判只要零头。区别只在于「这个环节值不值得用 LLM」。这不是个例。任何「LLM 调用量大、跑在真实业务上」的应用都是这个模式能省的环节没省钱就在看不见的地方流走。2. 场景痛点这个流程的痛点在每个月看账单的老板身上体现得最直接每月固定支出5 万次 × 2.8 万 Token月消耗千万级 Token成本随调用量线性上涨业务增长反而变成成本负担。杀鸡用牛刀情感分析用 LLM 生成关键词评分表就能算意图识别用 LLM 生成分类器判得更便宜——贵在「用错了工具」。隐性浪费回答生成的 prompt 又长又固定每轮固定消耗 1000 Token省不出来。降本怕伤质量改了规则怕回答质量下降、用户投诉于是一动不敢动。本质上成本不是「省」出来的是「这个环节值不值得用 LLM」设计出来的。3. 方案为什么是逐节点审计 结构化替代Dify 的 code 节点、Question Classifier 与 LLM 节点并存正好支持「先审计、再分类改造」。选它的理由先审计再动手逐节点统计 Token 消耗先找到「烧钱」的节点再决定改谁结构化替代规则能算的情感用 code、分类能判的意图用 Question ClassifierLLM 只保留核心生成——三次 LLM 调用压成一次质量回归兜底改造后跑四层用例回归降本不降质敢改也敢验。这篇文章我们就用它把客服问答工作流做一次「省钱改造」从 3 次 LLM 调用压到 1 次。4. 整体架构【改造后】开始情感分析关键词规则 code0 token意图识别问题分类器 QC回答生成LLM 精简结束【改造前】开始情感分析LLM意图识别LLM回答生成LLM结束改造前是 3 次 LLM 串行改造后情感分析与意图识别并行执行结果合并进回答生成的 prompt全程只有 1 次 LLM 调用。链路设计的要点先把「值不值得用 LLM」的判断做在结构上再谈 prompt 细节。5. 模块设计5.1 开始变量start 变量user_message段落必填max_length 10000两个应用完全一致方便 A/B 对比。5.2 改造前基线改造前三个 LLM 节点串行各自带独立 system prompt回答生成的 prompt 很长每轮固定消耗 1000 Token。5.3 改造后三个核心节点改造后核心节点情感分析改为 code 节点关键词评分表零成本defmain(user_message:str)-dict:textuser_messageorpos[满意,好,赞,喜欢,感谢,棒,不错]neg[差,坏,烂,投诉,生气,失望,退款,垃圾]scoresum(1forkinposifkintext)-sum(1forkinnegifkintext)sentimentpositiveifscore0else(negativeifscore0elseneutral)return{sentiment:sentiment,score:str(score)}意图识别改为问题分类器Question Classifier四类意图的指令必须带定义与示例instruction:|对用户消息的意图进行分类只能归为以下四类之一 - 咨询inquiry产品咨询、价格、功能、使用方法 - 购买purchase下单、购买、优惠、活动 - 售后after_sale退换货、维修、保修、发票 - 投诉complaint质量差、损坏、服务态度差、表达不满 按意图判断无法归入前三类的归入最接近的一类。classes:[咨询 inquiry,购买 purchase,售后 after_sale,投诉 complaint]completion_params:{max_tokens:2000,temperature:0.1}回答生成 LLM 精简 prompt把前面两个节点的结果作为上下文喂进去不再让模型重复理解原文prompt_template:-role:systemtext:你是电商客服。基于已知信息直接回答不超过 100 字。-role:usertext:|用户消息{{#start.user_message#}} 情感{{#cd_senti.sentiment#}} 意图{{#qc_intent.class_name#}}6. 运行验证输入预期结果同一句含「差/投诉」的客服消息改造后情感negative、意图售后、回答质量不降sentimentnegative规则命中「差/投诉」、intent售后QC 分类正确回答质量达标四层回归用例确定性/内容/语义/边界全部 PASS分类准确率 ≥95%全部 PASS分类准确率保持改造前单次约 2.8 万 Tokens降本 40%改造后 1 次 LLM 2 个非 LLM 节点约 1.5 万 Tokens/次-46%环境Dify 1.16.1Docker Compose模型 DeepSeek deepseek-v4-flash。两个 DSL 均导入发布通过用 Service API 冒烟验证。7. 实战坑坑现象修复code 节点沙箱禁写文件在 code 里写 /tmp 报 PermissionError所有「文件模拟」存储改本机 KV 模拟服务docker 容器 dify104-kv172.19.0.50:8123生产换 Redis/DB拓扑不变规则替代后质量下降边界用例答错改造后必须跑四层用例回归不达标就补关键词/回退 LLM实测边界用例兜底分类器指令无示例词表准确率低指令里给每类定义示例temperature 压到 0.1实测 102-03 经验只优化 prompt 忽略结构性浪费省 1000 Token 也省不出 46%先做逐节点成本审计把规则能算的情感和分类器能判的意图从 LLM 拆出去实测 102 批量经验8. 实验文档及源码获取实验文档DIFY-104-05Token成本控制——AI应用省钱改造.md源码一改造前dify104_05_01_成本控制-改造前.yml源码二改造后dify104_05_02_成本控制-改造后.yml源码目录dify-104/dsl文章聚焦核心配置与采坑点完整分步操作与回归用例见实验文档原文。下一篇Dify 企业级实验06可观测性体系——日志埋点与监控告警如何落地 你在这个实验的场景里踩过什么坑欢迎评论区分享你的实战经验。 Dify 企业级实验05Token 成本控制——AI 应用省钱改造怎么做Dify 实验系列 · 企业级 05/12 | 实验编号DIFY-104-05基于 Dify 1.16.1 实测2026-081. 业务场景先讲一个我们实际遇到的场景。AI 应用上线后老板每个月都要看一张账单客服问答工作流每月 5 万次调用单次平均消耗 2.8 万 Token——Token 是持续支出不是一次性开发成本调用量越大账单越吓人。我们第一次接这类需求时第一反应也是「省钱不就是压缩 prompt 字数嘛」。真正动手才发现——prompt 省那 1000 Token杯水车薪真正烧钱的是「用错了工具」规则能算的用 LLM 生成分类器能判的用 LLM 生成。省钱不是抠门是把每个环节放到它该在的位置上。同一个结果用 LLM 生成要花钱用规则算一分钱不花用 LLM 生成要花钱用分类器判只要零头。区别只在于「这个环节值不值得用 LLM」。这不是个例。任何「LLM 调用量大、跑在真实业务上」的应用都是这个模式能省的环节没省钱就在看不见的地方流走。2. 场景痛点这个流程的痛点在每个月看账单的老板身上体现得最直接每月固定支出5 万次 × 2.8 万 Token月消耗千万级 Token成本随调用量线性上涨业务增长反而变成成本负担。杀鸡用牛刀情感分析用 LLM 生成关键词评分表就能算意图识别用 LLM 生成分类器判得更便宜——贵在「用错了工具」。隐性浪费回答生成的 prompt 又长又固定每轮固定消耗 1000 Token省不出来。降本怕伤质量改了规则怕回答质量下降、用户投诉于是一动不敢动。本质上成本不是「省」出来的是「这个环节值不值得用 LLM」设计出来的。3. 方案为什么是逐节点审计 结构化替代Dify 的 code 节点、Question Classifier 与 LLM 节点并存正好支持「先审计、再分类改造」。选它的理由先审计再动手逐节点统计 Token 消耗先找到「烧钱」的节点再决定改谁结构化替代规则能算的情感用 code、分类能判的意图用 Question ClassifierLLM 只保留核心生成——三次 LLM 调用压成一次质量回归兜底改造后跑四层用例回归降本不降质敢改也敢验。这篇文章我们就用它把客服问答工作流做一次「省钱改造」从 3 次 LLM 调用压到 1 次。4. 整体架构【改造后】开始情感分析关键词规则 code0 token意图识别问题分类器 QC回答生成LLM 精简结束【改造前】开始情感分析LLM意图识别LLM回答生成LLM结束改造前是 3 次 LLM 串行改造后情感分析与意图识别并行执行结果合并进回答生成的 prompt全程只有 1 次 LLM 调用。链路设计的要点先把「值不值得用 LLM」的判断做在结构上再谈 prompt 细节。5. 模块设计5.1 开始变量start 变量user_message段落必填max_length 10000两个应用完全一致方便 A/B 对比。5.2 改造前基线改造前三个 LLM 节点串行各自带独立 system prompt回答生成的 prompt 很长每轮固定消耗 1000 Token。5.3 改造后三个核心节点改造后核心节点情感分析改为 code 节点关键词评分表零成本defmain(user_message:str)-dict:textuser_messageorpos[满意,好,赞,喜欢,感谢,棒,不错]neg[差,坏,烂,投诉,生气,失望,退款,垃圾]scoresum(1forkinposifkintext)-sum(1forkinnegifkintext)sentimentpositiveifscore0else(negativeifscore0elseneutral)return{sentiment:sentiment,score:str(score)}意图识别改为问题分类器Question Classifier四类意图的指令必须带定义与示例instruction:|对用户消息的意图进行分类只能归为以下四类之一 - 咨询inquiry产品咨询、价格、功能、使用方法 - 购买purchase下单、购买、优惠、活动 - 售后after_sale退换货、维修、保修、发票 - 投诉complaint质量差、损坏、服务态度差、表达不满 按意图判断无法归入前三类的归入最接近的一类。classes:[咨询 inquiry,购买 purchase,售后 after_sale,投诉 complaint]completion_params:{max_tokens:2000,temperature:0.1}回答生成 LLM 精简 prompt把前面两个节点的结果作为上下文喂进去不再让模型重复理解原文prompt_template:-role:systemtext:你是电商客服。基于已知信息直接回答不超过 100 字。-role:usertext:|用户消息{{#start.user_message#}} 情感{{#cd_senti.sentiment#}} 意图{{#qc_intent.class_name#}}6. 运行验证输入预期结果同一句含「差/投诉」的客服消息改造后情感negative、意图售后、回答质量不降sentimentnegative规则命中「差/投诉」、intent售后QC 分类正确回答质量达标四层回归用例确定性/内容/语义/边界全部 PASS分类准确率 ≥95%全部 PASS分类准确率保持改造前单次约 2.8 万 Tokens降本 40%改造后 1 次 LLM 2 个非 LLM 节点约 1.5 万 Tokens/次-46%环境Dify 1.16.1Docker Compose模型 DeepSeek deepseek-v4-flash。两个 DSL 均导入发布通过用 Service API 冒烟验证。7. 实战坑坑现象修复code 节点沙箱禁写文件在 code 里写 /tmp 报 PermissionError所有「文件模拟」存储改本机 KV 模拟服务docker 容器 dify104-kv172.19.0.50:8123生产换 Redis/DB拓扑不变规则替代后质量下降边界用例答错改造后必须跑四层用例回归不达标就补关键词/回退 LLM实测边界用例兜底分类器指令无示例词表准确率低指令里给每类定义示例temperature 压到 0.1实测 102-03 经验只优化 prompt 忽略结构性浪费省 1000 Token 也省不出 46%先做逐节点成本审计把规则能算的情感和分类器能判的意图从 LLM 拆出去实测 102 批量经验8. 实验文档及源码获取实验文档DIFY-104-05Token成本控制——AI应用省钱改造.md源码一改造前dify104_05_01_成本控制-改造前.yml源码二改造后dify104_05_02_成本控制-改造后.yml源码目录dify-104/dsl文章聚焦核心配置与采坑点完整分步操作与回归用例见实验文档原文。下一篇Dify 企业级实验06可观测性体系——日志埋点与监控告警如何落地 你在这个实验的场景里踩过什么坑欢迎评论区分享你的实战经验。 
