企业官网建设流程全解析

我得先把话放前头：如果你刚接触开源大模型应用平台，大概率在第一次打开 Dify 的“编排”页时会愣住——为什么新建应用的时候要让我选 Chatflow 还是 Workflow？这俩英文名差不多，图标也像，到底该点哪个？我当年第一次搭智能客服的时候选错了，后面返工折腾了整整一个下午。这篇文章就是想把这两者的区别、适用场景、底层逻辑和实操案例一次讲透，让你看完就能直接上手，不用再像我当初那样走弯路。

Dify 作为目前社区里热度极高的 LLM 应用开发平台，核心能力就是把“大模型对话”和“业务逻辑处理”用可视化拖拽的方式串起来。而 Chatflow 和 Workflow，就是 Dify 里两种最基础、也最容易搞混的编排模式。简单来说：Chatflow 是“会聊天的流程”，适合做对话型应用；Workflow 是“会干活的流程”，适合做自动化任务。但这样说太笼统，真正理解它俩，得从设计思路、节点差异、部署方式和调试技巧几个层面逐层拆解。下面我分四大块慢慢讲，全文都是我在真实项目里踩过坑之后总结出来的东西。

1. 整体设计与思路拆解：Chatflow 和 Workflow 到底在设计上分道扬镳在哪里

1.1 两个 Flow 的核心定义与定位差异

先说 Workflow。它的英文直译就是“工作流”，在 Dify 里的定位是面向任务的确定性流程编排。你可以把它理解成一条自动化流水线：原料从入口进来，经过一台一台机器处理，最后从出口出去。每一台机器做什么事、按什么顺序启动，都清清楚楚。Workflow 没有“对话记忆”的概念，它不关心上一轮聊了什么，也不维护用户和助手之间的上下文，每一次运行都是一次独立、完整的任务执行。

Chatflow 则是“对话流”，定位是面向对话场景的交互式编排。它天然带一个聊天气泡界面，用户在网页端或 API 接入后，是一轮接一轮地对话。Chatflow 会维护多轮对话的会话标识（Conversation ID），把历史消息、用户输入、助手回复都保存下来，下一次用户提问时，模型能“记得”之前聊了什么。这就像你和一个真人客服聊天，对方手里有一份完整的聊天记录，不会你说完上一句他就忘光。

你说这俩是不是完全对立？也不是。Chatflow 里可以嵌套调用 Workflow，Workflow 里也可以调用模型做自然语言处理。但从设计哲学上看，一个偏“嘴”，一个偏“手”，理解这个定位差异，后面选型就不会错。

1.2 核心区别对比：输入、记忆、结束方式全解

为了让你一眼看明白，我把最关键的差异整理成了表格：

这个表格看着简单，但实际选型时能帮你省下大量返工时间。我记得有个朋友拿着 Workflow 去做客服机器人，结果做了一半发现用户问“你刚才说那个方案多少钱来着”，他的工作流完全答不上来，因为他压根没有“历史消息”这个概念。最后老老实实重建了一个 Chatflow，才把效果调好。

1.3 为什么 Dify 要同时提供两种模式

很多产品只给一种编排方式，Dify 给两种，不是因为开发者闲得慌，而是真实业务场景里，对话、任务这两类需求差异实在太大了。

拿“企业制度问答机器人”来举例：员工进来问“年假怎么算”，这是一个对话行为，需要上下文理解、需要追问“你是入职第几年”，所以适合 Chatflow。但同一套系统里，如果后台要每天定时抓取新制度文档、做切片向量化、更新知识库，这是一个纯任务流，没有任何人跟它对话，就适合 Workflow。

再比如电商售后场景：用户在对话框里说“我要退货”，Chatflow 负责理解这句口语、提取订单号、确认商品信息；一旦确认完毕，需要调用企业内部 ERP 的退货接口、填写工单、发通知邮件，这一步纯逻辑操作交给 Workflow 去执行更稳定。所以 Dify 在设计上让 Chatflow 里可以调用 Workflow 子流程，两者不是竞争关系，而是上下游协作关系。

用一句话总结就是：要跟人说话，用 Chatflow；要替人做事，用 Workflow。这两者组合起来，才能覆盖完整的智能应用形态。

2. 核心细节解析与实操要点：节点、变量、YAML 底层，逐一拆开说

2.1 节点体系一览：你会在画布里遇到哪些“积木块”

Dify 的可视化编排，本质上是把不同功能的“节点”拖到画布上，再用连线确定它们的前后依赖关系。理解每个节点的职责，是你用好 Chatflow 和 Workflow 的基础。

常用节点我罗列一下，顺带标注它们最常出现的场景：

• 开始节点：每个 Flow 的入口。Workflow 的开始节点是表单，你定义什么字段，调用方就得传什么字段；Chatflow 的开始节点是系统固定的，除了 sys.query（用户当前输入），还带着上下文信息。
• LLM 节点：调用大模型生成回复，最核心的节点。可以配置模型、System Prompt、用户 Prompt 和变量引用。
• 知识检索节点：从知识库里检索相关文本片段（RAG 的核心），返回的结果可供 LLM 节点引用。做知识库问答几乎必用。
• 条件分支节点（IF/ELSE）：像程序里的 if else，根据变量值走向不同分支。
• 代码节点（Code）：用 Python/Node.js 写一段脚本处理数据，灵活度最高。
• HTTP 请求节点：调用外部 API，比如企业内部系统、第三方服务。
• 模板转换节点：把变量拼进一个文本模板里，多用于生成提示词或消息内容。
• 参数提取节点：用模型从用户输入里固定抽取结构化字段（比如订单号、日期）。
• 迭代节点：对数组里的每个元素循环执行一组操作。
• 变量聚合节点：把多个分支的变量汇总到一个变量里。
• 结束节点：流程终止，声明哪些变量作为最终输出。

这十来个节点听起来多，但你上手做两个例子之后就会形成肌肉记忆——哪个环节卡住了，就加对应的节点。本质上跟搭乐高一样，关键是得懂每个积木的卡扣形状。

2.2 聊天记忆是怎么存的：Chatflow 的会话变量与上下文机制

这是 Chatflow 和 Workflow 最本质的分水岭。Workflow 每次跑完就结束，所有中间变量随运行实例销毁；Chatflow 则会在一次会话内持续保留对话历史。

Dify Chatflow 里有两类和记忆相关的变量，你必须在设计时想清楚：

第一类是会话变量（Conversation Variables），存在整个会话期间，比如用户姓名、登录状态、购物车内容。这类变量可以在流程中多次写入、读取，跨多轮对话有效。

第二类是临时变量，仅当次对话轮次内有效，下一轮用户说话就清空。通常用来存“这轮提问检索出来的文档列表”“这轮模型生成的中间结果”。

实际操作中最容易犯的错，是把临时变量当会话变量用。我以前做过一个多轮信息收集表单：第一轮问用户姓名，用临时变量存了；第二轮问手机号，模型根本记不住上一轮的姓名，因为临时变量已经没了。改成会话变量，数据才稳定跨轮传递。

另外 Dify 的 LLM 节点会自动把该会话的历史消息作为上下文带进新的请求，只要你在模型参数里设置好“记忆轮数”（比如带最近 10 轮）。这里有个性能取舍：记忆轮数越多，模型看到的上下文越长，效果越好，但 token 消耗和响应延迟也会上升。实际项目里我会先在 6~10 轮之间调整，看效果和成本哪个更合适。

2.3 从可视化到 YAML：AI Workflow 的解析执行逻辑

很多人不知道，你在 Dify 画布上拖出来的流程图，按下“发布”那一瞬间，会编译成一份结构化的 YAML 配置文件。Dify 工作流引擎拿到这份 YAML 之后，会按节点顺序解析执行。

Dify 的 workflow YAML 大致长这样：

app: mode: chatflow name: 商品问答助手 nodes: - id: node_start type: start data: inputs: - variable: sys.query - id: node_retrieval type: knowledge-retrieval data: query_variable: sys.query dataset_ids: - 商品知识库 ID - id: node_llm type: llm data: prompt_template: - role: system text: 你是商品顾问 - role: user text: "根据资料回答：{{#node_retrieval.output#}}"

注意这些{{#node_id.output#}}格式的引用语法，它是整个流程里变量传递的关键。A 节点的输出要传给 B 节点，B 节点里的字段就得写这个引用串。很多新手排查了半天发现模型回答不对，原因就是这里拼错了变量名或者搞错了节点 ID。

理解这层之后你会发现一件事：Dify 的可视化画布只是壳，真正决定流程能不能跑通的，是节点间变量引用关系是否准确、节点类型选得对不对、分支条件写没写全。可视化帮你看清逻辑，但底层本质跟你写代码一样，是数据和控制的流转。这也是为什么调试 Flow 时，我习惯手动改 YAML 的引用语法结构去排查问题。

2.4 开始与结束节点：输入输出的形态差异含义

这是选型时最容易判断错的地方，我再展开说一说。

Workflow 的开始节点是“表单式”的，你定义三个字段：手机号、商品 ID、问题描述，那么外部调用方每次触发这个 Flow，都必须按你定义的 schema 传参。它适合被别的系统当作 API 使用，属于程序化输入。

Chatflow 的开始节点则完全不是表单。用户从对话框发来任何一句话，系统自动把它放进 sys.query 变量里，再附带会话 ID、用户 ID 等预订字段，直接进入流程。这就意味着，Chatflow 天生适合“开放式、非结构化输入”，也就是人话。

这两个模式对输出的要求也不同。Workflow 的结束节点通常输出结构化数据（JSON、表格、状态码），方便对接企业系统写入数据库；Chatflow 的结束节点则要输出给用户看的自然语言回复，还可以配置几个“建议提问”，让对话能顺滑延续下去。

我做数据报表时用得最多的是 Workflow：早上 9 点定时触发，读取业务库数据，调用模型写分析摘要，再把摘要推送进钉钉群。整个过程没有人跟它发消息，只需要表单里的几个查询参数。反过来，给 HR 做一个“员工入职咨询机器人”，那就必须 Chatflow——员工的表达千奇百怪，得靠对话理解来兜底。

3. 实操过程与核心环节实现：两个真实案例，带着参数一步步搭

3.1 Workflow 实例：入群申请自动审核机器人

我先用一个 Workflow 实战案例，让你体会纯任务流的完整链路。场景是：公司社群每天有上百人申请入群，需要根据申请理由自动审核是否通过，审核结果同步到企业微信群机器人。

第 1 步，创建空白工作流。在 Dify 控制台选“工作流编排”，新建空白应用，模式选 Workflow，名字就叫“入群申请审核”。

第 2 步，配置开始节点。定义两个输入字段：applicant_name（申请人姓名，类型 String）、apply_reason（申请理由，类型 Paragraph）。这里你可以填测试值，方便后面调试。

第 3 步，加一个 LLM 节点做意图判定。模型选择我用的是 DeepSeek-V3 或者 Qwen-Max 都行（本地有部署也可以接 Ollama），关键是 System Prompt 要写清楚判断规则：

你是群管理员助理。根据申请人填写的入群理由，判断是否通过审核。 规则：理由包含具体的业务合作意向、真实工作场景、明确的交流目的，则通过；理由空洞、疑似广告、含有外链，则拒绝。 输出格式：只输出 JSON，格式为 {"result": "approve" 或 "reject", "reason": "一句话说明"}

LLM 节点的输入变量把apply_reason传进去，这样模型就能基于实际申请理由做判断。

第 4 步，加代码节点解析 JSON。大模型输出的内容是字符串，直接用条件分支判断会很不方便，所以先用代码节点把它转成字典：

import json def main(response: str) -> dict: try: data = json.loads(response.strip("```json").strip("```").strip()) return {"result": data.get("result", "reject"), "reason": data.get("reason", "")} except Exception as e: return {"result": "reject", "reason": f"解析失败: {str(e)}"}

这个节点输入变量是llm_node.text，输出一个字典，后续就能取result和reason了。

第 5 步，条件分支。加一个条件分支节点，判断code_node.result是否等于approve。等于就走进“通过”分支，否则进入“拒绝”分支。

第 6 步，两条分支各自接 HTTP 请求节点和结束节点。HTTP 请求节点里配置企业微信机器人的 Webhook 地址，把申请人和审核结果拼进消息体。最后结束节点分别输出“已通知通过”“已通知拒绝”。

这个流程跑起来之后，每天一百条申请几分钟内就能审完，而且每一条都有据可查。用好 Workflow 的核心就一句话：把流程拆成节点，把判断交给规则，把特殊情况留给代码处理。

3.2 Chatflow 实例：政企内部知识库问答机器人

第二个案例是很多人关心的“RAG 知识库问答”场景，我帮某个单位做过内部制度问答机器人，用的就是 Chatflow。需求很明确：员工在对话框提问，机器人从资料库检索相关段落，用大模型组织自然语言回答，答不上来就引导人工处理。

第 1 步，先准备知识库。这步不在 Flow 编排里，但 Chatflow 最依赖的就是它。把制度文档整理成 PDF/TXT，上传到 Dify“知识库”，选择分段模式和索引方式。经验值是单段 500 个字符左右、重叠 50~100 字符，检索效果比较稳。嵌入模型我用的是本地部署的 BGE-M3，中文语义理解比很多在线模型更扎实，而且数据不出内网，安全可控。

第 2 步，新建 Chatflow 应用。在“创建应用”里选“对话型应用（Chatflow）”，从模板里选“知识库问答”起步。

第 3 步，设置开始节点后的知识检索节点。这是 Chatflow 和 RAG 衔接的核心：

第 4 步，加 LLM 节点组织回答。System Prompt 我这样写：

你是企业内部制度知识问答助手。请严格依据"知识检索"节点提供的资料回答员工问题。 如果资料与问题无关，请回复："抱歉，我没有在现行制度库中检索到相关信息，请转人工咨询。" 回答结构：先直接给出结论，再补充依据条款与原文引用。

注意把知识检索节点的输出变量作为上下文传入 LLM 节点，我在实践里发现，显式告诉模型“只依据检索资料回答”能显著降低一本正经地胡说八道的情况。

第 5 步，Faiss 不行就多轮追问。员工提问经常信息不全，比如只问“年假能休几天”，但制度里区分了工龄。这时可以在 LLM 节点后加一个“问题分类”分支：检索到多条不同标准时，回复追问“请问您入职满几年了？”并把员工的回答存入会话变量，再触发二次检索。这就是 Chatflow 相对 Workflow 的独家优势——多轮澄清能力。我建议在 bot 发布前，多准备几组包含模糊提问、指代不明、口语化表达的测试用例。

第 6 步，配置结束节点的引导问题。在回复末尾带上“如何申请年假”之类建议问题，能提升对话留存率。发布后嵌入企业内部网页或者企业微信菜单栏，员工问起来完全无感，但后台能看到每条提问命中了哪段制度。

3.3 本地部署与模型接入的注意点

很多人问 Dify 到底怎么本地部署、Ollama 怎么接。我自己在 Windows 和 Linux 上都部署过，踩过一轮坑之后说几个要点。

Dify 官方推荐用 Docker Compose 一键部署。到 GitHub 上拿最新 release 的docker-compose.yaml，在项目目录执行docker compose up -d，等镜像拉完，浏览器访问http://localhost/install初始化管理员账号就行。国内服务器拉镜像慢的话，给 Docker 配好国内镜像加速源，一次能省一半时间。

本地模型这块，Ollama 拉取bge-m3做嵌入模型、拉qwen2.5或deepseek-r1做对话模型，然后在 Dify 后台“设置 - 模型供应商 - Ollama”里填 API 地址。注意容器内的localhost指向的是容器自己，不是宿主机，要填http://host.docker.internal:11434，这是 Windows/Mac 上极易踩的坑。

如果你用本地模型做 RAG，建议把知识库索引的 Embedding 模型和查询时用的嵌入模型保持同一个，否则向量空间不一致，检索效果会崩坏。这是我当时排查了一天发现的问题。

3.4 调试与发布：上线前必须做这几步

Dify 的编排界面自带“预览调试”面板。对 Workflow，你直接填一组模拟输入，点运行，画布上会高亮显示走到了哪条分支、每个节点的输入输出值。这一步别跳过，要看三个地方：每个节点的输出是否符合预期、变量引用有没有空值、条件分支有没有走向意外路线。

对 Chatflow，调试面板会模拟聊天窗口。多轮对话是重点：连续问几个关联问题，检查模型是否记得前文；故意给一个谁都听不懂的输入，看知识库检索能不能兜住。我习惯准备一个 20 条左右的测试集，包含正常提问、模糊提问、反事实提问、超长文本，全部跑通了再发布。

发布时 Chatflow 可以生成网页嵌入代码，或者发布为 API 供自己的系统调用；Workflow 则通常发布为服务端点，在外部系统里通过 HTTP 请求触发。上线之后别关日志，Dify 的“运行日志”面板保留每次运行的节点级数据，出了故障快速定位到具体节点。

4. 常见问题与排查技巧实录：把我踩过的坑都摆出来

4.1 知识库报 internal server error，改一次崩一次

搜索记录里很多人遇到“升级后无法保存知识库，或者修改知识库时报 internal server error”。我也遇到过，而且是在 Dify 社区版升级之后突然出现的。

排查思路按顺序走：

1. 先看 Dify 后端容器日志：docker compose logs api -f --tail=100，多数的报错原因会直接打在日志里。
2. 大概率是数据库迁移没跑完全。升级时执行的docker compose up -d会自动跑迁移，但偶尔会因旧数据格式不兼容而中断。解决办法是手动执行 API 容器里的迁移命令，或者备份后重建知识库的索引表。
3. 还有一种可能是插件冲突。Dify 1.x 之后插件升级频繁，部分社区插件不兼容会拖垮知识库路由。检查插件列表，禁用近期安装的未验证插件再试试。

最稳的兜底方案：升级前完整备份 docker 挂载的 volumes 目录（包括 postgres 数据库、redis、vector db），升级出问题直接回滚。这个习惯能救你很多次。

4.2 客服连续对话，聊着聊着模型就“失忆”了

用 Chatflow 做客服连贯对话，最典型的问题是：前两轮记得，第三轮突然忘了前面说过什么。

先检查记忆轮数配置。在 LLM 节点的“上下文”里，看是否启用了“对话历史”注入，并确认Message Window不是 0。如果记忆轮数开了但还失忆，多半是会话 ID 没用对——外部接入时每次请求都生成新会话 ID，聊天室就变成每次都初见的陌生人。

再有，你得区分“长对话超 token”和“真失忆”。长对话累计历史太多，超出模型上下文窗口后，Dify 默认策略会丢弃最早的消息。这种情况不是失忆，是容量不够。解法一是调低记忆轮数，二是用“会话变量”手动抽取关键信息（比如用户姓名、问题类型）进行持久化，不依赖完整原始消息。

4.3 RAG 检索明明建了库，回答却驴唇不对马嘴

知识库建了、内容传了、问答却答非所问，这是高频问题。原因通常有三个：

1. 分段不合理。一段 2000 字混着多个主题，检索出来的片段不聚焦，答案自然稀碎。把分段调小到 300~500 字，并确保每个分段有相对完整的意义单元。
2. Embedding 模型不给力。通用在线模型对垂直领域术语理解较弱。换成 BGE-M3 这类中文专用模型，通常立竿见影。
3. Score 阈值没调好。阈值太高，该召回的被过滤；阈值太低，垃圾片段混进上下文。上线前跑几组测试，找到同类问题稳定通过的分界线。

还有一个容易被忽略的点：检索模式。纯向量模式适合语义匹配，纯全文模式适合关键词精确匹配，而混合检索能兼顾两者。默认建议混合，尤其在制度类文档这种关键词有大量“省略号式说法”的语料中，混合检索效果明显好。

4.4 代码节点报错、HTTP 请求超时，怎么快速定位

代码节点报错，最常见的原因是传入变量类型不是代码里预期的类型。Dify 的变量类型比较严格，比如 LLM 节点的输出是字符串，你不能直接拿去做字典操作。解决方式是在代码开头加类型转换和 try-except，把异常信息作为流程输出返回出来，而不是让节点直接红掉。

HTTP 请求节点超时，先判断是内网地址不通，还是目标服务响应太慢。内网地址问题多半是容器网络没打通，这点跟之前说的host.docker.internal一个道理。目标服务慢，就把请求节点的“超时时间”从默认 10 秒调到 30 秒，同时加上错误分支做降级处理，避免一个外部服务挂了导致整条流程中断。

4.5 排查技巧速查表

最后再分享一个我在实战里摸索出来的经验

做了一年多 Dify 项目之后，我的体感是：新手最容易过度设计。拿到需求先想哪个节点更炫、要不要上多分支，结果一个简单问答愣是搭出十几步。真正稳的流程设计，永远是“先跑通再优化，先满足 80% 的核心场景，再往边缘情况上补分支”。

就比如我现在做一个新的智能应用，会强制自己先画出输入和输出是什么、要不要多轮记忆、处理逻辑是否确定，三个问题答完，选 Chatflow 还是 Workflow 基本就有答案了。然后先在预览面板里用最直白的方式跑通主链路，再加分支，再补异常处理。流程越简单，调试越轻松，上线后也越不容易出冷门故障。

另外一个很实用的小技巧：版本管理要早早做。Dify 的流程本身支持发布版本回滚，但你最好在本地把导出的 DSL（YAML 文件）按日期存一份到 Git 仓库里。改坏了随时对比差异，哪里变了、是不是手滑删了节点，一目了然。我靠这个习惯挽救过不止一次被自己玩坏的流程。

Chatflow 和 Workflow 的真正价值，不是谁比谁高级，而是你能不能把正确的需求交给正确的模式。闲下来的时候，可以拿公司的真实业务练练手，从搭一个 10 分钟能跑通的小流程开始，慢慢你就会有感觉了。