Dify 工作流搭起来以后，很多人第一反应是继续加节点、加知识库、加模型能力。但真正上线后，成本问题很快会出现：一次用户提问带出很长上下文，知识库召回片段太多，模型输出没有长度限制，日志又没人复盘，最后账单变成一笔糊涂账。
Dify 工作流成本控制，不是简单换一个便宜模型，而是从流程设计开始减少浪费。你可以把本文和 AI智能体与自动化专题、老达AI实践专题 一起看，尤其适合正在交付客服问答、线索分流、资料整理和内部自动化流程的人。
先看成本从哪里来
一个 Dify 工作流的成本，通常不只来自最终 LLM 节点。你至少要看五个来源：
- 用户输入：问题越长、历史对话越多，输入 Token 越高。
- 知识库召回：top-k 太大、片段太长，会把大量资料塞进上下文。
- 模型调用：每多一个分类、总结、改写、评分节点，都会增加调用次数。
- 输出长度：没有限制输出，模型可能把简单回答扩成一篇文章。
- 失败重试：超时、限流、节点报错后的重复执行，也会消耗预算。
所以，不要只问“Dify 用哪个模型便宜”。更应该问：这个流程到底需要几次模型调用，每次喂了多少上下文，哪些回答可以复用，哪些步骤必须人工确认。
第一步：给不同任务分模型层级
很多流程一开始就把所有节点都接到同一个强模型，这是最常见的浪费。实际上，Dify 工作流里的任务可以分层。
- 低成本模型：用于分类、标签、简单摘要、格式整理。
- 主力模型：用于常规问答、客服回复草稿、资料总结。
- 高能力模型：只用于复杂推理、重要客户、长文分析和高价值任务。
例如销售线索评分可以先用低成本模型做初筛，只把高意向线索交给更强模型分析原因。站内 Dify销售线索评分流程 讲的是业务设计，本文这里补的是成本视角：不要让每一条低价值输入都走最贵路径。
第二步：控制知识库召回数量
知识库不是召回越多越好。top-k 设置太大、分段太长、资料重复太多，都会把上下文撑大。成本变高只是一个问题，更麻烦的是模型读到太多相似片段后，答案反而容易摇摆。
建议从这几项开始调：
- 先用较小 top-k 测试，例如 3 到 5 条，再根据命中率增加。
- 清理重复资料，不要把同一份政策的多个旧版本都放进去。
- 按业务边界拆知识库，避免售后、销售、内部资料混在一起。
- 对长文档做好分段，让每个片段只解决一个明确问题。
如果你已经遇到答偏问题，可以继续看 Dify知识库命中率低怎么办 和 Dify多知识库路由教程。召回准了，成本和质量通常会一起改善。
第三步：给输出设置长度边界
很多 Dify 成本浪费发生在输出端。用户问一句“退换货怎么处理”，模型写出 800 字；销售只需要一句跟进建议，模型生成一份完整方案。这类回答看起来认真，实际既贵又不好用。
提示词里要写清输出长度和结构：
请用不超过 120 字回答客户问题。先给结论，再给 2 条必要说明。如果资料不足，请回复“需要人工确认”，不要自行补充政策。
对内部流程，也可以按场景设置不同输出：客服回复短一点，日报总结可以长一点，交付报告再完整一点。不要让所有节点都生成长文。
第四步：能缓存的内容不要重复问模型
很多业务问题是重复的：营业时间、服务范围、退换货政策、套餐说明、常见故障。对于高频问题，不一定每次都要完整走一遍模型生成。
可以考虑三类复用：
- 固定答案复用：完全标准的问题，直接返回预设答案或知识库原文摘要。
- 检索结果复用：同类问题命中同一组资料时，复用已审核过的回答模板。
- 人工审核复用：人工确认过的高质量答案，沉淀成 FAQ 或提示词示例。
缓存不是为了偷懒，而是避免同一类问题反复消耗模型。对本地商家、小团队客服和内部知识库来说，这一步很容易省钱。
第五步：日志要记录到能复盘成本
如果日志只记录“成功/失败”，后面很难知道钱花在哪里。建议每次关键调用至少记录这些字段：
- 工作流名称和版本；
- 节点名称和模型名称；
- 输入来源和业务场景；
- 输入长度、输出长度或平台可提供的 Token 用量；
- 是否命中知识库、召回片段数量；
- 是否转人工、是否重试、是否失败。
这些字段不一定都要在 Dify 内完成，也可以写到表格、日志系统或 n8n 流程里。重点是能回答三个问题：哪个流程最贵，哪个节点最容易重试，哪些用户问题消耗高但价值低。
第六步：设置预算线和人工告警
成本控制一定要有预算线。比如每天最多处理多少条、单次问题最长多少字、单个用户每天最多触发多少次、某个工作流月度预算是多少。超过预算时，不要继续静默运行。
一个简单的预算策略可以这样设计：
- 低风险流程超过日预算，降级为只返回资料链接或进入人工队列。
- 高风险流程超过预算，暂停自动回复，只保留人工提醒。
- 异常重试超过 3 次，停止继续调用模型并发送错误通知。
- 每周汇总一次高成本问题，决定是补知识库、改提示词还是限制入口。
这一步可以和 Dify工作流上线后监控、Dify工作流测试用例 连起来。测试负责上线前发现问题，监控负责上线后持续发现成本异常。
一份上线前成本检查清单
- 每个 LLM 节点是否真的必要，能否合并或改成规则判断？
- 知识库 top-k、分段长度和重复资料是否已经检查？
- 输出是否有字数、结构和拒答边界？
- 是否记录模型、节点、输入输出长度和失败重试？
- 是否给高频问题设计 FAQ、模板或缓存复用？
- 是否设置日预算、月预算、异常告警和人工兜底？
如果流程还涉及外部 API、OpenAI 或其他模型平台，也可以参考 OpenAI API成本控制清单。不同平台计费方式会变，但控制思路是一致的：减少无效输入，限制输出长度，记录用量，及时告警。
老达点评
Dify 工作流的成本控制，本质是让每一次模型调用都有理由。能用规则解决的，不一定要用大模型；能用短回答解决的，不要生成长文；能沉淀成 FAQ 的，不要每天重复消耗。
我的建议是：新工作流上线前，先用 20 条真实样例跑一遍成本复盘。看每条平均调用几次模型、召回多少片段、哪些节点最贵。把这件事做完，Dify 才不只是“能跑”，而是更接近一个能长期交付、能持续维护的 AI Agent 项目。
