1. 先搞明白Chatflow和Workflow到底是干什么的第一次打开Dify控制台看到“创建空白应用”里那两个选项——Chatflow和Workflow很多人会愣一下。这两个东西名字像图标像进去之后画布也像都是拖节点连线那凭什么分成两个入口选错了会怎样先说结论选错入口不会让你做不出东西但会让你做出来的东西用起来很别扭。我刚开始接触这个平台的时候也是随手选了个Workflow吭哧吭哧搭了一个客服问答流程跑起来倒是没问题。结果一测试发现用户问完一句“你好”它回完就结束了根本没有多轮对话的概念。这时候我才意识到Chatflow和Workflow的根本区别不在“流程怎么画”而在“这个流程是给谁用的”。Chatflow是给“对话场景”用的。用户通过聊天窗口跟你的应用交互每一次输入都是一句话系统需要结合上下文来理解然后产出回答。这是一个有状态的过程。Workflow是给“任务场景”用的。输入是一份数据、一条记录、一个文件系统跑完整个流程输出一个结果。这是一个无状态的过程。这个区分直接决定了你该选哪个入口。如果你的最终用户是人人在聊天框里跟你的应用说话那大概率需要Chatflow。如果你的最终消费者是一个系统、一个脚本、一个批处理任务输入输出都是结构化数据那Workflow更合适。为了好记我一直用一个类比Chatflow像是一个前台接待员你得跟它来回对话它才能帮你办成事Workflow像是一条流水线你把原材料放上去机器从头跑到尾出来的是成品中间没人跟它聊天。这句话基本能解决90%的选型困惑。但真正用起来还有不少细节值得展开。1.1 两者的核心差异有状态和无状态“有状态”和“无状态”这两个词听起来有点像后端开发的黑话但拆开看其实很好懂。Chatflow从诞生那天起就是为“会话”而生的。每次用户发来一条消息Dify会把这个会话的历史消息一起带到工作区里。你在编排的时候可以随时在某个节点里引用上文的用户问题、AI回答、甚至中间提取到的关键信息。这意味着对话可以“记得住”。举个例子。用户说“我想订一张明天去北京的机票”你的Chatflow可以在理解节点里抽出“北京、明天”这两个实体存在变量里。接着用户再说“那帮我查一下早上九点左右的航班”此时Chatflow知道“那个地方”是“北京”“第二天”还是“明天”因为上下文变量还在。这就是有状态的价值。Workflow没有这个能力。它只认你喂给它的输入跑完就结束不会记得上一次你调用了什么。但它也有自己的优势结构简单、执行高效、结果可重复。你可以把一个耗时的数据加工流程封装成Workflow然后通过API让任何系统去调用它每次调用都是一次干净的、独立的执行。理解了这个本质区别你再看Dify官方的文档分类就顺了。官方文档里Chatflow的功能特性写的是“对话管理、上下文记忆、多轮指令”Workflow写的是“批处理、API调用、自动化流程”。一个往“聊”的方向做深一个往“干”的方向做专。1.2 用真实场景来判断该用哪个理论说多了容易晕直接看场景。我做过一个客户案例他们想做一个售前咨询助手挂在官网上用户进来问产品参数、价格、货期。这个场景必须用Chatflow。因为用户不会一句话问完所有问题他会先问“你们有没有支持POE供电的型号”看完推荐又问“这个型号多少钱”接着问“那跟另一个型号有什么区别”。每一轮都依赖前一轮的上下文。如果用Workflow用户第二句话就变成了无头苍蝇系统根本不知道“这个型号”指什么。另一个客户的需求是把销售发来的订单邮件自动解析提取产品名、数量、金额回填到ERP系统里。这明显是Workflow。输入是一封固定格式的邮件每一步操作都跟“聊天”无关跑完一个批次就给结果。做成Chatflow反而是画蛇添足。有一个很实用的判断原则如果你的输入可以被一个JSON对象完整描述输出也可以被一个JSON对象完整描述那就用Workflow。如果你的输入是“用户的一句话”且输出要服务用户“下一句话”那就用Chatflow。听起来简单但我在社区里确实见过有人在Workflow里强行模拟对话记忆的——把历史消息塞进输入变量里LLM节点上下文拼接了老长一串效果又差又费token。这个坑真没必要踩换个入口就全解决了。1.3 Chatflow和Workflow的选型对照表维度ChatflowWorkflow交互形式对话式一问一答任务式输入输出状态管理有状态记忆上下文无状态每次独立执行运行触发聊天输入API调用、定时、事件典型场景客服、助手、教育陪练数据清洗、内容生成、系统集成调试方式对话式调试可模拟用户单次运行检查输出变量使用会话变量系统变量输入输出变量用这张表对照自己的需求基本一眼就能定。2. 动手前的准备部署和模型接入确定好该用哪个类型之后接下来就是环境问题。Dify这平台有SaaS版也支持本地部署。我个人的习惯是涉及真实业务数据、需要深度定制插件、或者要对知识库做安全管控的一律本地部署。只是来学习体验的话先去云端控制台玩玩就行不用一上来就折腾Docker。但如果你确定要本地部署我建议先想清楚一个事你是用Docker Compose一把梭还是用源码方式跑。官方推荐的Docker Compose方式最省心。拉下代码仓库dify/docker目录下直接docker compose up -d等镜像拉完就能用。我推荐至少分配4核CPU、8G内存给这个环境因为你背后还要跑模型。磁盘看你的知识库规模默认50G起步比较稳妥。部署完成后要改的配置有这么几个重点.env环境变量文件里SECRET_KEY必须改掉这是生产环境的基本素养。如果需要外部访问调整nginx的server_name和https证书配置。如果打算接本地大模型提前确认你的Ollama服务地址能被Dify容器访问到别用localhost。2.1 模型接入Ollama本地部署与云端API的取舍模型是Dify的灵魂没有模型画布上那些节点全部是摆设。Dify模型接入的选项很多OpenAI、Anthropic、Azure OpenAI、通义千问、DeepSeek、Ollama等等。我在本地环境里最喜欢用的是Ollama。Ollama本身不做模型它是模型运行时管理工具可以拉取各种开源模型在本地跑。Dify接入Ollama的步骤其实很简单但我每次帮别人排查都会发现几个共性问题第一Ollama的IP地址不能写localhost。因为Dify和Ollama通常跑在不同的容器里你在Dify的模型配置页填localhostDify访问的是它自己的容器内部永远连不上宿主机。正确写法是填宿主机在局域网里的IP。如果你是在跟Dify同一个宿主机上跑Ollama那在Linux下可以填docker0网桥的IP这个在终端里执行ip addr show docker0就能看到。Windows用户填WSL的IP或局域网IP都行。第二模型名称必须写对。Ollama里的模型ID和你在Dify里填的模型名称要完全一致大小写都不能差。很多人填了个“qwen”,拉的是“qwen2.5”那肯定报404。先在终端里执行ollama list看清楚有哪些模型再去配置。第三Ollama服务要监听0.0.0.0。Ollama默认只监听127.0.0.1Dify容器从外部访问会失败。在启动Ollama前设置环境变量OLLAMA_HOST0.0.0.0或者在systemd服务配置里加上EnvironmentOLLAMA_HOST0.0.0.0。还有人问我是选云端API还是本地模型。我的观点很直接做产品原型、要出效果给客户看用云端大模型API省钱省事效果还好。做数据敏感的内部系统、或者对长尾成本有强诉求的用本地模型。本地模型的劣势也客观存在一个7B的量化模型在普通消费级GPU上生成速度和中英文理解能力确实不如云端商用模型。但在知识库问答这类可控性强的场景里本地模型表现已经够用。关键是看你舍得花多少时间调教。2.2 创建应用的第一步入口选择部署好了模型接好了接下来就是创建应用。Dify的“创建空白应用”页面除了之前说的Chatflow和Workflow还有一个“聊天助手”。很多人在这里又分不清了。聊天助手本质上是没有工作流编排的纯LLM对话应用只能在提示词层面做文章。Chatflow则是把对话能力跟工作流节点结合可以做复杂的意图识别、条件分支、工具调用、知识库检索。我的建议是只要你的需求超过了一问一答哪怕只是多了一个“查知识库再回答”就直接用Chatflow。聊天助手太单薄后面想加功能还得重建。创建入口选择之后你面对的是一个空白画布。第一次打开画布的人经常懵这些节点是干嘛的我应该先放哪个别慌第三章我会一步步拆一个Chatflow的实操案例。第四章再拆Workflow你会发现套路是相通的——无非是“进变量、做处理、调模型、看结果”这四步的变体。3. Chatflow实操从零搭建一个带记忆的客服助手很多教程会把Chatflow讲得很玄什么Agent节点、知识检索节点、条件分支节点各来一段。但我自己的学习路径是先做一个最小可用产品再逐步加复杂度。所以我先带大家做一个纯对话风格的客服助手核心功能就两个会打招呼、能查产品库。3.1 配置Chatflow画布的基础节点打开Chatflow画布左侧是节点库中间是画布区默认已经帮你放好了“开始”节点和“直接回复”节点。我们需要再添加三个关键节点LLM节点、知识检索节点、条件分支节点。先看连线顺序。最简单的结构是开始 - LLM - 直接回复。开始节点接收用户的原始输入LLM节点根据系统提示词和用户问题生成回答直接回复把结果返回给用户。这条链路跑通之后再加知识库。LLM节点里要填几个东西模型选择。这里选你在“设置-模型供应商”里配置好的那个。System Prompt。这是系统的角色设定。比如“你是一个电子产品售前客服请根据提供的产品信息回答客户问题。如果信息不足告知客户转人工。”上下文。把变量sys.query填进去这是用户当前的问题。这里有个很实用的细节LLM节点的上下文是支持引用变量的。除了sys.query你还可以引用知识检索节点的输出、问题分类节点的结果等等。这意味着你可以用多个节点处理完信息后再让LLM做最终回答的整合。3.2 让对话拥有记忆开启对话变量接下来就是Chatflow最出彩的地方——对话记忆。你不需要手动把历史消息拼进提示词里。Dify在Chatflow的应用编排页右侧有个“对话变量”区域你可以提前声明一个变量比如chat_history然后在LLM节点的上下文里把chat_history放进去。Dify会自动把多轮对话的历史填充到这个变量中。实测下来这个机制很稳。用户说“我要订房”你把它抽取成“意图订房”存进会话变量。用户下一句“明天晚上”进来时LLM节点看到上下文里有“订房”意图就能推断出“明天晚上”是入住时间。我自己有个心得会话变量设置要克制不要每个数据都往里塞。只存那些跨多轮对话还有用的关键信息比如用户意图、已选产品ID、省份城市等。一些临时性的中间结果用临时变量就够了否则画布会变得很难维护。3.3 加一个知识库私域数据问答的底气客服助手光靠模型常识不够必须接入你自己的产品库。Dify把这块做成了“知识库”你上传文档、分段、配置检索方式然后在Chatflow里加一个“知识检索”节点就能实现“先检索再回答”。知识检索节点的配置核心是选知识库和检索策略。Dify的混合检索很好用它把向量召回和关键字召回结果做了融合再走Rerank步骤。这里我建议打开“Rerank”开关它能显著提升检索结果的相关性代价是增加一点延迟和token消耗。检索结果以变量形式供后续节点引用。你在LLM节点的上下文里加上“知识检索结果”同时把System Prompt改成“请根据以下资料内容回答用户问题”。说白了就一句话LLM负责“怎么把话说好”知识检索负责“拿什么来说”。3.4 意图分类和条件分支让助手学会分流一个稍微复杂点的客服助手不可能只回答产品问题它还要处理退换货、物流查询、人工客服求助。如果所有问题都一股脑丢给LLM问答回答质量会很飘。这时候就需要意图分类。Dify内置了“问题分类”节点。你给它几组分类标签和对应的分类描述它会调用LLM把用户问题归到某一类。然后后面接一个条件分支节点按分类字段分别走不同的处理逻辑。我在实际项目里总是把“转人工”作为一种意图处理。当用户表现出明显不满情绪或问题已经超出机器人能力范围时干脆利落地转给人工体验反而更好。不要为了追求机器解决率而硬撑。条件分支节点是按字段值来路由的后面可以接不同的子流程。这样整个Chatflow画布看起来就像一棵树主干是用户入口枝干是不同业务场景的独立处理链。3.5 上线前的调试方法与测试要点Dify画布右上角有“运行”按钮是单步调试模式。它会让你填用户输入然后逐步看到每个节点的输入输出。这个调试器太重要了尤其是定位“为什么LLM回答得不对”的时候。我的调试习惯是先看知识检索节点返回了什么。很多回答质量差的问题根因根本不在于模型而在于知识库检索结果压根没召回该有的内容。你盯着知识检索节点的输出结果马上就能确认是不是这块出了问题。另一个测试要点是多轮对话测试。单轮回答正常不代表多轮下正常尤其是你用了会话变量之后。我见过有人的会话变量在第二轮就被覆盖成空字符串导致整个对话断上下文。一定要把至少五轮以上的对话脚本跑一遍。4. Workflow实操搭建一个“简历筛选”的批处理流程Chatflow搞定了我们来看Workflow。我拿一个平时很多人问的需求举例简历筛选。假设HR每天收到几百份简历希望让AI帮忙解析简历文本、提取关键信息、给候选人打个初筛评分、输出结构化结果。这就是典型的Workflow场景。4.1 配置Workflow的输入变量和发起方式创建Workflow之后第一件事是配置“开始”节点的输入变量。简历筛选的输入可以是简历原文文本也可以是文件上传。我用的是字符串变量resume_text因为可以直接用API传JSON调用来测试。Workflow的运行方式比较灵活。开发阶段直接点右上角“运行”填一个测试输入就行。生产阶段一般通过“API访问”来调用Dify会生成一个独立的API端点你把参数传进去就能拿到结果。也支持定时触发和事件触发但简历筛选这种往往是外部系统调API所以API方式最常用。4.2 文本处理巧用模板节点组装提示词第一步是把原始简历文本塞给LLM。直接用LLM节点也可以但为了后边步骤方便我建议先用“模板转换”节点把整段提示词拼好。Dify的模板转换节点非常强大你可以在里面引用变量、写Python语法、循环处理字段。简历筛选场景的模板大概是这个意思你是资深HR请根据以下简历内容完成信息提取和评分。 简历内容 {{resume_text}} 输出格式要求候选人姓名、工作年限、关键技能、匹配度评分0-100分、推荐建议。这里有个细节别把大段提示词直接写在LLM节点的System Prompt里。用模板节点拼装的好处是灵活你可以在不同分支里复用同一个LLM节点只用换模板的内容。维护成本低很多。4.3 结构化输出用代码节点处理返回结果LLM节点跑完返回的内容是一段文本。如果要把结果入库或者对接HR系统得把这段文本转成JSON。这里有两个选择。第一个选择是在LLM节点里设置输出格式为JSON并给一个JSON Schema作为参考让模型按照指定的键输出。这个方案简单但是不太稳模型偶尔会输出多余的markdown标记或者解释文字。第二个方案是接一个“代码”节点Python脚本直接清洗返回文本截取JSON片段再解析。我在生产环境里都是这个套路。import json def main(response_text: str) - dict: text response_text.strip() if in text: text text.split()[1] if text.startswith(json): text text[4:] return json.loads(text)代码节点的好处是你能做很多后处理逻辑比如字段校验、缺失值填充、格式转换。这在Workflow里是硬需求因为下游系统对数据格式的要求往往很苛刻。4.4 多分支流程与错误兜底真实业务里简历筛选一般会按岗位类型分流程。工程师岗位要看技术栈、框架深度销售岗位要看业绩数据、客户资源。如果都走同一个LLM提示词效果一定差。所以Workflow里典型的做法是先用LLM节点或代码节点做岗位分类然后接条件分支不同分支各自跑独立的LLM节点和模板。这样画布主干清晰每个分支之间完全隔离调试时直接单独跑某一条路径即可。另外一定要给Workflow留错误兜底。Dify的条件分支支持ELSE默认路径所有非预期的输入都走到兜底逻辑比如返回“未能识别岗位类型”。没有兜底路径一条脏数据就会让整个流程报错非常尴尬。4.5 Workflow的批量测试方法Workflow单条测试通过之后一定要做批量测试。Dify的“运行”按钮是单条调用的但生产环境你会碰到各种各样格式的输入。我在本地写了一个简单的Python脚本循环读取测试数据文件逐个调用Dify Workflow的API把结果统一存下来。这么做能一次性暴露很多单测发现不了的问题比如某个输入触发了LLM返回格式异常。某个岗位分类没被任何分支匹配到。某些简历文本过长导致token超限。批量测试跑完再针对失败样本做看板统计基本可以把Workflow的鲁棒性拉到上线标准。5. 常见问题与排坑指南写到这里应该有不少人已经打开Dify在试了。这里整理几个我遇到过的典型问题覆盖面从部署到使用应该能帮大家少走一些弯路。5.1 模型相关本地Ollama接入老失败凡是本地部署Dify Ollama 的组合百分之八九十的问题出在地址或模型名上。这里再强调一遍检查三件事Ollama服务是否监听0.0.0.0。Dify填的地址是否是宿主机局域网IP而不是localhost。Dify填的模型名是否与ollama list输出完全一致。如果这三项都对再去Dify的模型供应商页面点“测试”按钮看报错信息具体指向哪。Dify的报错一般写得比较清楚至少能定位出是连接层还是鉴权层的问题。5.2 知识库相关升级后报internal server error有很多用户在社区反馈“dify升级后发现知识库打不开或者改知识库配置时报internal server error”我遇到过一次。这个问题的常见原因是升级过程中数据库迁移没完整执行尤其是老版本的数据表结构变化比较大时。处理思路是先检查Dify容器状态确认api、worker、db这些容器都是healthy。然后手动执行数据库迁移脚本而不是只重启容器。具体命令在官方文档里有就是一句docker compose exec api flask db upgrade。执行完再重启相关容器即可。还有一个容易被忽略的点向量索引用的数据库组件版本不兼容。Dify默认用的是Weaviate升级后有时候镜像tag没跟着更新索引状态会出错。检查一下你的向量数据库容器版本必要时重建索引。5.3 应用编排相关Chatflow多轮对话串场有朋友做过客服机器人发现线上跑的时候A用户的问题回答到B用户头上去了。这个十有八九是会话变量的作用域没设置好。Dify的会话变量是按会话隔离的但你要确认自己的会话ID是否每次新建。如果你在API里复用了同一个会话ID那变量就会串场。前端每次进入页面时应该生成一个新的会话ID或者调用Dify的会话清除接口。5.4 插件相关离线安装插件的姿势Dify的插件市场确实方便但在内网环境或者网络受限的环境里在线安装经常失败。Dify支持手动插件安装你可以从插件市场下载.difypkg格式的文件然后在“插件-通过本地文件安装”里上传安装。不过我建议能用docker方式装插件的时候尽量用docker方式。很多插件依赖外部的Python包、API密钥和回调端点离线环境下光是把这些依赖配齐就很费劲。先把网络环境的问题解决掉再谈插件安装会顺很多。5.5 一步到位的避坑建议最后说点掏心窝的大白话。第一先在Dify云端把流程逻辑完全跑通再去做本地部署。本地部署会牵扯模型推理性能、容器网络、存储方案等一大圈问题不应该在流程还没验证的时候同时进行。第二同一个平台不要既跑Workflow又跑Chatflow混着用。不是说平台不支持而是项目结构会乱。把对话类和应用类拆成两个Dify项目各自维护各自的变量和插件排查问题的时候清爽很多。第三控制每个节点的复杂度。一个LLM节点的提示词写几千字后面调试的时候没人救得了你。尽量把大任务拆成多个小节点每个节点只做一件事。输出用JSON格式方便下游节点使用。Dify的Chatflow和Workflow表面上是两种画布模板本质上是对“对话”和“任务”这两种截然不同的业务形态的抽象。把这两者的边界想清楚了你的应用架构思路自然就清晰了。以后哪怕换别的平台甚至自己写代码编排这套取舍逻辑都一样适用。