Dify这个开源LLM应用开发平台我前面已经写过六篇入门文章从Docker部署、模型接入到知识库搭建一步步带着大家把基础功能玩明白。这一篇开始进入重头戏用拖拽连线替代代码5分钟搭一个AI工作流做一个实用的文本摘要器。先交代清楚一个概念工作流不等于聊天框。聊天框是一问一答的对话工作流是把输入-处理-输出拆成一张流程图你把LLM节点、知识库节点、条件分支节点、代码节点这些积木块拖到画布上用连线把数据流串起来Dify就会按照流程自动跑完整个任务。文本摘要器就是最典型的工作流场景之一它只做一件事给一段长文本返回一段精炼摘要。听起来简单但它能让你彻底理解工作流的核心机制。这篇文章适合谁两类人。一类是产品、运营、内容编辑这类非技术岗位你不需要会写代码但你想让AI替你批量总结文章、会议纪要、客户反馈另一类是开发同学你想在Dify上快速验证一个AI流程的可行性再决定要不要用Spring AI这类框架转成正式代码。两种需求用工作流模式都能覆盖。1. 先搞清楚Dify工作流到底解决什么问题很多人第一次打开Dify的工作流画布看到左下角一长串节点列表会有点懵。别急我们先从为什么要用工作流说起理解了这个后面的操作就都是顺理成章的事了。1.1 工作流和聊天助手的区别Dify控制台里有两种应用类型Chatflow聊天流和 Workflow工作流。我在之前的文章里详细讲过聊天助手这里简单做个对比。对比维度Chatflow聊天流Workflow工作流核心场景多轮对话、客服、AI助手自动化处理、批量任务、流程编排会话记忆有自动维护上下文无每次运行独立交互方式一问一答输入一个任务跑完输出结果典型节点对话历史、问题分类、Agent开始、LLM、条件分支、代码、知识检索适合人群做聊天机器人的团队做自动化工具的团队记住一个判断标准如果你要处理的是一段输入-一个输出的固定任务比如总结、分类、翻译、抽取信息直接选工作流如果你要做的是一来一回的对话助手选聊天流。我见过不少初学者把工作流当聊天框用在LLM节点里写请回答以下问题结果发现每次都要手动输入内容没有上下文体验很差。这就是没分清两者的定位。1.2 文本摘要器为什么适合当作工作流入门案例一个合格的入门案例需要满足三个条件流程简单但结构完整、应用场景普遍、出成果快。文本摘要器全都满足。从流程上看摘要器只需要三个核心节点开始节点接收原始文本LLM节点执行总结结束节点输出结果。但就是这三个节点能把工作流最重要的概念全部串起来——输入变量怎么定义、Prompt怎么传给模型、输出变量怎么结构化。从场景上看摘要的需求太普遍了。运营要总结当天的文章资讯法务要提炼合同要点研发要概括长邮件几乎每个岗位都有帮我看看这段内容说啥的需求。你自己做完这个摘要器立刻就能在工作里用上这种成就感是别的示例没法比的。从扩展性上看摘要器做出来之后加一个知识库检索节点就成了知识库问答摘要器加一个条件分支节点就能让AI先判断文本类型再选择摘要策略这些都是后面进阶的事。先把这个骨架搭起来什么都能往上挂。2. 环境准备把Dify本地跑起来做工作流之前你至少得有一个能登录的Dify实例。如果你还没装这一步是绕不过去的。装Dify的方式有好几种最省心的还是Docker Compose一条命令拉起全部组件。2.1 Docker Compose方式快速部署我这套步骤在云服务器和本地虚拟机上都验证过按照顺序执行基本没有问题。前置条件就两个Docker 19.0以上版本、Docker Compose插件可用。# 1. 拉取Dify官方源码仓库 git clone https://github.com/langgenius/dify.git # 2. 进入docker目录 cd dify/docker # 3. 复制环境变量模板 cp .env.example .env # 4. 启动所有容器首次需要拉镜像耐心等待 docker compose up -d等所有容器状态变成 healthy 之后浏览器访问http://你的服务器IP/install设置管理员账号密码完成初始化就能进控制台了。有个细节值得多说一句Dify的docker目录下有几十个容器定义包括API服务、Web前端、数据库、Redis、向量数据库等。新手第一次看到docker compose ps输出一排容器不要慌关注其中几个关键的就好——api、worker、web、db、redis健康就说明主流程没问题。2.2 模型接入建议先用Ollama本地模型工作流跑起来依赖大模型这一步很多人卡住。Dify本身不提供大模型能力它需要你接入模型供应商比如OpenAI、Anthropic、通义千问、DeepSeek。但在入门阶段我最推荐的是接入Ollama本地模型。理由很直接。第一Ollama完全跑在你自己的机器上不需要申请API Key不会有任何网络访问的顾虑。第二对于文本摘要这类任务7B量级的本地模型完全够用。第三用云端API一旦配置写错反复调试的每一个请求都要花钱本地模型随便调。Ollama安装非常简单装好之后先拉一个模型我常用的是qwen2.5:7b中英文摘要能力都不错。# 安装Ollama后拉取千问模型 ollama pull qwen2.5:7b # 启动Ollama服务默认端口11434 ollama serve然后在Dify控制台里操作设置 - 模型供应商 - 找到Ollama - 填Base URL为http://host.docker.internal:11434模型名称填qwen2.5:7b点保存。这里注意因为Dify跑在Docker容器里访问宿主机的Ollama不能用localhost而是要映射到宿主机地址。Docker Desktop环境下一般用host.docker.internalLinux服务器上可以直接填服务器的内网IP。2.3 部署阶段最容易翻车的三个坑安装过程我帮很多人排查过问题最集中的坑就三个第一个是镜像拉取失败。Dify涉及的镜像多、体积大在国内网络环境下经常中途卡住。最实用的解决办法是给Docker配置镜像加速源在Docker Daemon配置文件/etc/docker/daemon.json里添加 registry-mirrors 配置然后重启Docker服务。配置完再重新执行docker compose up -d拉取速度会明显改善。第二个是SSL证书相关的报错。这类报错通常出现在配置模型供应商或访问API时表现形式是类似证书验证失败的提示。多数情况是你所在的Docker环境或操作系统时间不同步导致证书校验异常先检查系统时钟设置好时间同步再审一遍。第三个是端口冲突和内存不足。Dify默认要占用80、443端口如果你的服务器上已经跑了Nginx或其他Web服务先把它们停掉或者修改.env文件里的EXPOSE_NGINX_PORT等参数换一个端口。内存方面Dify全家桶跑起来大致需要4GB左右的内存低于这个数值容易看到容器反复重启。3. 5分钟搭出摘要器拖拽连线的实操全流程环境就绪模型也接入了现在进入正题。打开Dify控制台点击创建应用选择工作流起个名字叫文本摘要器。画布会自动出现两个节点绿色的开始节点和红色的结束节点。接下来的一切就是在这两个节点之间加积木。3.1 认识工作流画布和节点库Dify的工作流画布和很多自动化工具类似中间是编排区域左侧是节点库列表。节点库内容很丰富我先把摘要器用到的和即将用到的分类说一下基础节点开始、结束、LLM、条件分支IF/ELSE、模板转换Template Transform、代码执行Code增强节点知识库检索Knowledge Retrieval、HTTP请求HTTP Request、迭代Iteration逻辑节点变量赋值、变量聚合、参数提取等文本摘要器需要用到最基础的三个开始节点负责接收外部传入的文本LLM节点负责与模型交互结束节点负责把结果返回给调用方。新手画布上第一眼容易慌记住一个原则数据从开始节点向左向右是流过去的每条连线代表上一个节点的输出变量可以作为下一个节点的输入变量。你不需要管理它内部怎么传输只要关心每个节点的输入输出端口就行。3.2 配置开始节点定义输入变量点击画布上的开始节点右侧会弹出配置面板。开始节点是所有数据的入口必须预先定义好这次工作流要接收什么数据。我在这里配置一个输入变量类型选段落变量名写content。为什么用段落类型因为摘要器要处理的是一长段文本段落类型可以容纳多行内容而文本类型更适用于短字符串。虽然字段名可以随便叫但建议用英文小写加下划线方便后续在Prompt里引用。这里有一个容易忽略的细节开始节点的变量名会成为整个工作流里的全局变量任何节点都能引用。所以把它当成一个接口契约定义清楚后面的节点都不用改。3.3 拖入LLM节点并连线工作流的核心环节从节点库里把LLM节点拖到画布上放在开始节点和结束节点中间。然后把开始节点右侧的连线和LLM节点的左侧输入端口连上再把LLM节点的右侧端口连到结束节点。连线成功后画布上就形成了一个完整的链路。点击LLM节点进入配置面板。这里要填的内容比较多我逐个说首先是模型供应商和模型名称。选择第二步接入的Ollama模型选qwen2.5:7b。如果你用的是云端模型这里会列出来你配置过的供应商。然后是上下文区域。这里有个关键操作点击变量输入框选择content变量。这意味着这个LLM节点能看到用户传入的原始文本。如果你不把内容变量传给LLM节点模型是拿不到任何输入的。3.4 编写Prompt模板决定摘要质量的一半LLM节点最核心的配置就是系统指令System Prompt。很多人到这里习惯性写一句请总结以下文本然后跑完发现效果很平庸。问题不在于模型不行而是Prompt太糙。我给摘要器写了一段经过多次迭代的Prompt模板你可以直接抄你是一名专业的中文内容编辑擅长提炼核心观点。请对用户输入的文本进行摘要。 要求 1. 先概括整体主题一句话说明这段文本在讲什么。 2. 提炼2-5条关键信息每条不超过30字使用编号分条列出。 3. 如果文本涉及数据、结论、行动项必须保留。 4. 输出总字数控制在150字以内。 5. 不要输出以下是摘要之类的废话开头。 用户输入的文本 {{content}}这个Prompt里有几处值得琢磨的设计第一我给了模型一个角色设定——专业中文内容编辑角色设定比干巴巴的请总结更能激活模型的输出能力。第二我用要求1、2、3限制了输出结构摘要不是散文分条的关键信息更好用。第三我明确禁止了废话开头很多模型在无约束时喜欢加以下是对您提供文本的摘要这在自动化场景里非常碍事。第四我用{{content}}引用了开始节点的变量这一步就是把动态数据注入Prompt的标准姿势。3.5 设置模型参数和输出格式LLM节点右侧还有一堆参数面板最常用的三个是温度、最大Token、输出变量。温度Temperature控制随机性0到2之间摘要任务建议调到0.2或者更低。以前0.7跑出来的摘要经常视角不一样同一个文本这次说A重点下次说B重点调到0.2以后稳定了很多。追求确定性任务就没有必要把温度拉高。最大TokenMax Tokens控制模型最多生成多长的内容。摘要输出一般不会太长设500足够了。注意这里的Token和中文字数不是一回事粗略估算一个汉字约占1.5到2个Token150字摘要大约需要300个Token500是一个安全余量。输出变量Output Variable在内存/输出区域配置我命名为summary。这个变量就是工作流跑完之后结束节点返回给调用方的结果。最后点击结束节点在输出变量配置里把 LLM 节点的summary加进去。这一步必须做不然结果在外面拿不到。在这之前还有一步要补在LLM节点的输出变量里也要配置summary因为LLM节点默认输出是文本内容我们需要显式命名它。全部配置完成后整个链路就是开始节点content - LLM节点含Prompt模板 - 结束节点summary保存工作流基础版的文本摘要器就搭好了。4. 调试、运行与发布把工作流变成真正能用的应用光搭好还不行得跑通、跑稳定、能给别人用才算完成整个工作流开发的闭环。这一节讲调试面板怎么用、报错怎么排查、发布怎么配置。4.1 用调试运行面板验证效果Dify工作流右上角有一个运行按钮点开后输入一段测试文本我建议你选一篇文章的前两三段大概几百字的长度。点击运行系统会弹出运行状态面板展示每个节点的状态、耗时和输出。首先观察开始节点的输出确认content变量确实接收到了你输入的文本。然后观察LLM节点的输出这里能展开完整的模型生成内容。最后看结束节点的summary变量。调试面板最有价值的地方是查看每个节点的输入输出这一特性。如果最终结果不对你可以逐级往回看模型没收到文本是开始节点变量传错了模型有输入但输出不对是Prompt问题输出在LLM节点里有但结束节点报错是输出变量没配对。这里我提醒一个高频低级错误很多人在LLM节点里配置好了Prompt但忘记把输入变量传给节点。结果运行的时候模型一直在处理一个空内容输出一段莫名其妙的泛泛而谈。你点看LLM节点的输入变量如果显示为空或者undefined基本就是这个原因。4.2 常见报错排查速查表我把Dify工作流运行中最常遇到的报错整理成了一张表照着排查省很多事。报错现象原因解决办法an error occurred during credentials validation模型供应商API Key或Base URL配置错误去设置-模型供应商里重新校验确认密钥和地址无误提示上下文超长Context Length Exceeded输入文本超过模型最大上下文长度分段输入、换支持更长上下文的模型、用迭代节点切分处理模型响应超时Ollama本地模型推理慢或服务器性能不足换更小的模型、确认没有其他任务占满GPU/内存输出变量为空结束节点没有关联LLM节点的输出变量在结束节点配置里选择对应的summary变量工作流运行成功但结果不正确Prompt指令太模糊参照本文3.4节的Prompt结构加角色、结构、限制要求关于上下文超长多说一句。摘要器最容易遇到的就是塞了一整本小说进去模型直接拒绝响应。Dify社区里有个很常见的进阶做法先用文本分段逻辑把长文章切成若干小段做分段摘要再调用一次LLM节点把分段摘要归纳成总摘要。这个思路我放在下一节细讲。4.3 发布把工作流变成WebApp和API工作流调试稳定后点页面顶部的发布选择发布为应用。发布之后这个工作流就可以被真正的用户使用了。Dify提供两套使用方式。一是生成一个WebApp页面像聊天框一样但底层是跑你的工作流你用浏览器打开链接就能用。适合内部工具、演示、给非技术同事用。二是发布API端点其他系统可以以HTTP方式调用它接入公司内部的系统、写成自动化的定时任务、或者给Spring AI之类的后端框架做集成。我个人强烈建议在你自己的系统集成Dify工作流时优先走API方式。原因在于API调用返回的是结构化的summary字段可以直接映射成JSON而WebApp的交互更适合人工手动使用。比如你把摘要器接入一个文章管理后台让每一篇文章入库时自动生成摘要这就是API方式的典型落地场景。5. 从能用到好用文本摘要器的三个进阶方向你要是只满足于一个基础摘要器看到这里就够了。但我猜大部分人做完第一步后很快会遇到两个问题短文本摘要效果ok但长文章一个LLM节点搞不定或者希望摘要器能结合公司的文档库一起工作。这就需要进阶了。5.1 长文本分段递归摘要突破上下文限制面对超长文本最粗暴的解法是换一个支持百万级上下文的模型但模型的成本和响应速度会明显上升。更工程化的做法是分段-摘要-合并三步走。在Dify工作流里你不必写代码实现分词可以直接在流程里做一个迭代节点先在开始节点输入整篇文章用模板转换或者参数提取节点把文本按段落切分然后在迭代节点里对每一段调一次LLM节点做分段摘要最后再让汇总节点把多个分段摘要合并成最终的总摘要。这样做的好处是每段文本长度可控任何模型都能处理坏处是工作流节点变多运行耗时增加。一个健康度的判断标准如果文章在5000字以内直接单LLM节点搞定超过5000字再考虑分段方案。5.2 结合知识库做定向摘要摘要器的另一种玩法是检索后摘要。比如你有一个公司制度知识库想让AI根据某个具体主题把相关制度条款提炼成一份摘要。这时候不是把整个知识库喂给模型而是在工作流里加一个知识检索节点。流程变为用户在开始节点输入一个主题知识检索节点先从知识库里检索相关块把命中的内容传给LLM节点LLM再根据这些内容生成摘要。这种方式不仅响应快而且摘要内容与用户意图强相关。这也是Dify知识库流水线的典型用法。这里有一个实践心得知识检索节点返回的结果往往带有分数、原文片段等元数据直接丢给LLM会让模型困惑。建议在模板转换节点里先把检索结果整理成来源1xxx来源2xxx的纯文本格式再传给LLM输出质量会干净很多。5.3 用代码节点做数据清洗不是非要纯拖拽Dify工作流的口号是拖拽连线替代代码但节点库里偏偏有个代码执行节点支持运行Python代码。它和整个工作流模式并不冲突反而是一对好搭档。比如你写的摘要器可能需要先清洗输入文本去掉HTML标签、多余换行、或者统计字数。这些事用Prompt让模型做既不精准又费Token用代码节点写一个简单的Python函数输入原始文本输出清理后的字符串几行代码解决运行速度毫秒级。用不用代码节点我的建议是能被模型轻松完成且不追求稳定性的任务交给Prompt涉及精确计算、数据清洗、格式转换的任务交给代码节点。初学者不要因为必须零代码就拒绝代码节点Dify给了你选择权目的是用最合适的方式解决问题。6. 实操经验总结我踩过的坑和建议这套摘要器从搭建到接入业务系统我在多个Dify版本和部署环境下走了一遍最后分享几个实在的经验希望能帮你少走弯路。6.1 节点版本与工作流兼容性Dify的更新速度很快社区版从1.x到2.x迭代了很多版本不同版本的节点能力差异不小。你照着教程做时如果发现找不到某个节点或者界面和教程对不上先确认你的Dify版本。建议做项目之前把Dify升级到当前稳定的社区版并定期关注官方更新说明否则很容易出现教学文档是2.0你用的是1.10的错位。这里还要提一个容易被忽略的点Dify本地部署后的升级操作并不复杂但升级前一定要先备份数据库和.env文件。我见过有人升级后向量数据库索引失效、工作流历史记录异常如果没有备份只能从头来过。6.2 Token成本控制不是小事如果你接入云端模型API摘要器的Token成本是肉眼可见的。一个3000字文档输入的Token可能就要消耗数千要是用分段递归摘要费用会成倍增加。控制成本的办法有三招。第一招尽量用本地Ollama模型跑基础摘要成本为零效果可接受。第二招给LLM节点设置合理的Max Tokens不要让模型自由发挥生成一大段太空文。第三招在转换节点里做文本去重和长度裁剪把无关信息在喂给模型前先删掉。别小看这几招我在一个批量摘要场景里用本地模型替代云端模型之后成本直接降了九成。6.3 分享一个Prompt优化的小技巧最后分享一个我在调摘要质量时学到的技巧永远先让模型思考再输出。给LLM节点写Prompt的时候不要在System Prompt里直接要求输出摘要而是分成两个步骤第一步把用户输入的文本拆解为若干核心信息的要点列表不要省略。 第二步基于要点列表写一段通顺的140字以内的摘要。为什么这样分两步因为直接一步让模型做摘要它容易跳步丢掉一些看来不重要但实际很关键的信息。先列出要点再写摘要输出质量明显更稳定。这个技巧可以套用到几乎所有需要总结、分类、抽取的工作流里。文本摘要器只是Dify工作流的一个入口。你掌握了开始节点、LLM节点、结束节点、变量传递、调试发布这几个核心概念后续不管是做文章分类器、给客服对话打标签、还是做自动化日报生成思路都是完全一样的画布上拖节点连线上传数据Prompt里讲清楚规则调试面板里看结果。工作流的本质就是给AI搭了一条生产线你画好流程它就替你干活。