企业官网建设流程全解析

最近在梳理一个内部小项目，我发现自己越来越依赖用 Dify 可视化工作流来连接 LLM 与工具。以前调模型、接API、写判断逻辑，总要埋头啃半天的代码，现在把节点往画布上一拖，连上线，一个能跑的业务流程就出来了。这篇文章我就用“三步上手”的节奏，把整个思路和实操过程掰开揉碎讲给你听，包括怎么搭第一层LLM对话流、怎么把外部工具接进流程、怎么用条件分支让工作流自己做判断，最后再聊聊我踩过的坑和排查问题的经验。

这不是一篇劝你“放弃代码”的文章。可视化工作流解决的是“快速串联、快速验证、快速修改”的问题，尤其适合团队里已经有点子但还没形成方案的探索阶段。如果你刚接触 Dify，或者正在LLM应用和业务工具之间反复拉扯，这篇文章应该能帮你少走不少弯路。

1. 为什么我建议用可视化工作流连接 LLM 与工具

1.1 从“写代码串流程”到“拖拽连线改逻辑”

直接用代码把 LLM 和工具串起来，听起来很自由，但一旦流程复杂起来，痛苦也是实打实的。你要自己处理 Prompt 的拼接、工具调用的顺序、分支条件的判断、超时重试、中间结果的缓存，甚至还得分心去设计日志格式，方便出了问题以后排查。很多时候，真正核心的业务逻辑只占代码的一小部分，剩下大量时间都被“胶水代码”吃掉了。

Dify 可视化工作流的好处，是把这层“胶水”变成了画布上的节点和连线。模型调用是节点，工具请求是节点，知识库检索是节点，条件判断还是节点。你不需要关心数据在节点之间怎么传递，只需要用变量引用把上一节点的输出接到下一节点的输入。这个思路和搭积木很像：每一块积木只负责一件事，但组合起来能完成非常复杂的任务。

这种模式的价值在改动需求的时候最能体现。以前改一个流程分支，可能要翻遍代码找到对应的 if 块，然后小心翼翼地改完再跑一遍回归测试。现在只需要在画布上调整连线，或者改一个节点的配置，保存之后马上就能在调试面板里验证。

1.2 可视化工作流适合哪些场景

我不是说所有 LLM 应用都应该用可视化工作流来做。它更适合下面这几种情况：

• 业务流程清晰、但代码实现成本高：比如多步工具调用、需要条件判断的客服机器人、带知识库引用的工单助手。
• 需要快速验证产品想法的 MVP 阶段：画布上拖几下就能做出一个可交互的原型，拿去给业务方确认，比写几百行代码再沟通要高效得多。
• 由偏业务的人参与设计流程：运营同学可以直接看懂“这个节点是查知识库的，那个分支是判断用户情绪是否负面”的逻辑，沟通成本明显降低。
• 需要嵌入到现有业务系统的内部工具：Dify 部署在自己这边，数据不出内网，权限可控。

反过来，如果你需要深度定制模型的采样参数、实现极其复杂的多轮状态管理，或者对推理性能有极其苛刻的要求，那还是回到代码方案更直接。可视化工作流解决的的是“80% 的通用需求”，剩下的 20% 才交给代码去补齐。

1.3 在 Dify 里组织 LLM 和工具的基本单元

在 Dify 里，工作流编排主要围绕几个基础单元展开：开始节点、LLM 节点、工具节点、条件分支节点、知识检索节点和结束节点。每个节点都有自己的输入输出，节点通过连线连接，数据通过变量在节点之间流动。

开始节点定义了整个工作流的入口参数，比如用户的提问、上下文信息。LLM 节点负责调用大模型，输入是系统 Prompt 和用户消息，输出是模型生成的文本。工具节点负责调用外部能力，比如 HTTP 请求、内置的网页解析、内容生成工具等。条件分支节点则用来做逻辑判断，根据前面的中间结果决定走哪条路径。结束节点把最终结果返回给调用方。

理解这些概念之后，你会发现所谓“连接 LLM 与工具”，本质就是定好“用户输入从哪进来—模型怎么理解—工具怎么执行—结果怎么返回”这条链路，然后把每一步落到对应节点上。

2. 上手前必须搞懂的三个关键点：模型接入、节点配置、变量传递

2.1 模型接入：没有模型连接，一切无从谈起

在开始画工作流之前，先把模型接进来。Dify 支持接入不同来源的大模型，包括各类云服务商提供的 API，也可以通过自托管的模型网关接入本地推理服务。第一次配置时，只需要找到设置里模型提供商的位置，填上服务地址和 API 密钥，再选一个模型实例，就可以在工作流里选用了。

这里有一个容易被忽略的细节：模型接入之后，在不同的节点里引用的是同一个“模型连接配置”，但节点的温度、最大 Token 数这些参数却是独立的。所以在设计工作流之初，就要想清楚哪些节点需要“标准回答”，哪些节点需要“高创造性的发散输出”，分别设置合适的参数，而不是所有节点都沿用一套默认值。

我自己的习惯是，给每个模型配置起一个能看懂的名字，比如“主对话模型”“意图判断模型”“摘要模型”，这样在节点下拉菜单里选模型的时候，一眼就能看出这个节点是用来干什么的。否则模型一多，光靠 API 地址根本分不清谁是谁。

2.2 节点配置：从“输入—处理—输出”的角度去理解

每个节点都可以拆成三部分来看：输入配置、处理逻辑、输出数据。

以 LLM 节点为例，输入配置是系统 Prompt 和用户消息，处理逻辑是模型推理，输出数据是生成的文本。模型到底怎么理解这段输入，取决于你的 Prompt 怎么组织。我在实际项目里发现，与其在 Prompt 里堆一大堆角色设定，不如把关键上下文变量直接插进 Prompt 模板里，让模型始终能看到最新数据。

工具节点的配置稍微复杂一点。比如一个 HTTP 请求工具，除了 URL、请求方法以外，还要定义请求头、请求体和响应解析。这里有个经验：工具节点的输入参数里，凡是涉及用户动态输入的字段，都建议设置成从前面节点的变量里自动读取，而不是写成固定值。这样你之后调整流程，只需要改上游节点，工具节点本身不用动。

2.3 变量传递：工作流的“血管”与“神经”

变量是可视化工作流里最容易踩坑的地方，但理解了它，整个画布的逻辑就清晰了。Dify 里每个节点的输出都会产生变量，比如 LLM 节点的输出文本、知识检索节点的分段列表、工具节点的返回体。当你把两个节点连线之后，下游节点就可以引用上游节点的输出变量。

变量引用的语法看起来是{{#节点ID#字段名#}}这种形式。如果你不习惯这种写法，可以在配置输入框里直接点击可用的变量去插入，比较省事。但有一个原则要记住：下游节点只能读取已连线且执行完毕的上游节点的输出。如果你在某个节点里引用了另一个分支的变量，很可能会得到空值，因为那个节点在当前的执行路径上根本没跑过。

处理多分支场景时，我建议在关键节点后加一个“变量聚合”的动作，把当前路径上真正存在的变量重新归一化，避免下游节点面对一堆未定义的引用。这在后面讲条件分支时会再次提到。

3. 第一步：用三个节点搭出第一条 LLM 对话流

3.1 创建应用并选择工作流类型

在 Dify 平台里新建应用时，通常可以选择“聊天助手”“文本生成”等模版，也有从空白工作流开始的入口。要做“连接 LLM 与工具”的流程，我更推荐从空白流程开始，因为后续按业务需求自由组合节点的空间更大。

第一次创建时，你会在画布上看到开始节点和结束节点，它们默认已经存在了。开始节点里通常预设了一个sys.query这样的变量，代表用户的当前输入。如果只是做一个最简对话流，你甚至不需要改开始节点的配置，直接用默认输入就行。

这里要留一个心：工作流类型不要选错。“聊天助手”类型适合多轮对话场景，因为它天然带会话上下文的概念；普通“工作流”类型更适合一次性的批量处理任务。我们的目标是“连接 LLM 与工具”，并且希望对话语义能延续，所以我建议选择带会话机制的“聊天助手”类工作流，或者至少在设计时把历史消息作为输入变量传进来。

3.2 接入第一个 LLM 节点

从左侧节点面板拖出一个 LLM 节点，放到开始节点和结束节点之间，连上连线。然后配置三样东西：模型实例、系统 Prompt、用户消息。

系统 Prompt 里要写清楚你希望模型扮演的角色以及输出格式要求。比如如果你要做一个能判断“用户是否想要查天气”的节点，Prompt 可以写成下面这样：

你是意图判断助手。你只输出一个单词： - weather: 表示用户想查询天气 - other: 表示用户的问题与天气无关 用户说：{{#sys.query#}}

用户消息那里同样引用开始节点的sys.query。这样一来，模型每次收到的输入都会是最新的用户问题，而不会把历史问题重复塞进去。

这里有个关键点，Prompt 中的变量引用要确保拼写正确。Dify 在配置面板里一般会提供可插入变量列表，直接点击插入就好了。手工敲变量名非常容易因为多一个空格或者少一个符号而出问题，排查起来还特别隐蔽。

3.3 配置结束节点并完成第一次测试

结束节点负责把结果返回给调用方。你可以把 LLM 节点的输出文本直接映射到结束节点的输出参数上，名字叫result或answer都行。测试的时候，点击“运行”按钮，输入一句“今天北京天气怎么样”，观察整个链路是否正常走通。

如果一切正常，你会看到开始节点 → LLM 节点 → 结束节点依次执行，LLM 节点的输出框里会出现判断结果。如果结果不符合预期，第一反应不是换模型，而是回去检查 Prompt 是否足够明确。模型表现不稳定，大概率是喂进去的指令有歧义，而不是模型能力不行。

这一步看起来很简单，但它验证了最关键的事：你已经能把用户的输入成功送入 LLM，并把模型的输出成功取回来。后续所有工具调用、分支逻辑，都建立在这条最基础的通路之上。

4. 第二步：把外部工具作为一个节点接进工作流

4.1 工具的两种来源：内置工具与自定义工具

Dify 里的工具节点可以来自两个渠道：一个是平台自带的内置工具，比如网页抓取、文生图、内容识别之类的通用能力；另一个是自己上传或配置的自定义工具，最典型的就是 OpenAPI Schema 定义的一组 API。

把工具接进工作流的思路是一样的：在画布上添加一个“工具”类型节点，选好要用的工具，然后把上游节点的输出映射到工具的输入参数上。工具执行完之后，它的返回结果会变成该节点的输出变量，供下游节点使用。

我比较推荐优先选择自定义工具。因为内置工具虽然简单，但往往为了通用性做了很多妥协，不一定完全贴合你的业务。而自定义工具就是“你的系统对外暴露的一个 API”，你完全掌控它的入参和出参。后面接企业内部系统、接数据库查询、接消息推送，走的都是同一条路径。

4.2 实操示例：用 HTTP 请求节点封装一个天气查询工具

为了演示得更具体，我们现场做一个“天气查询”工具。假设你已经有一个可以返回城市天气的 HTTP 接口，地址类似这样（这里用占位演示）：

https://api.example.com/weather?city={{city}}

在自定义工具配置里，把请求方法设置成 GET，请求路径填上面的 URL，参数city设置成从上游变量读取。然后给这个工具定义好返回结构：一个 JSON 对象，包含city、temperature、condition字段。

接下来在工作流里这样串联：

1. 开始节点收到用户输入，比如“北京天气怎么样”。
2. LLM 节点借助一个极简的 Prompt，从用户输入中提取出城市名。
3. 工具节点接收 LLM 节点输出的city值，发起天气查询请求。
4. 工具节点返回天气 JSON。
5. LLM 节点再根据天气 JSON，整理成一段自然语言回答。

这一步的重点是：工具节点不是孤立执行的，它需要上游告诉它“调用哪个参数”。如果没有从用户输入里提取城市名这一步，工具节点就没有办法完成请求。这也是“LLM 连接工具”中最核心的含义：让模型理解用户的意图，把它转成工具可以执行的参数。

4.3 工具超时、失败重试与日志观察

工具调用最常见的两个问题是超时和报错。外部 API 不稳定的情况比我们想象中频繁得多。为此，在工具节点的配置里可以考虑设置合理的超时时间，并在节点后接入一个“分支”来判断调用是否成功。

我习惯的做法是，查看工具节点的返回状态码或返回体标志。如果是0或某种约定俗成的成功标志，就往下走正常处理逻辑；如果返回异常，就进入一个兜底分支，让 LLM 直接回复“暂时查询不到数据，请稍后再试”，而不是让整个流程报错中断。这个兜底逻辑看上去很简单，但它在生产环境里的价值非常大，至少不会让用户面对一段冰冷的报错信息。

排查工具节点问题时，直接在调试面板里看该节点的原始输入和原始输出。Dify 的节点运行日志一般会记录请求的 URL、请求体、响应体，你一眼就能看出到底是参数传错了，还是接口本身返回了异常。如果整个流程因为工具节点直接中断，建议先单独测试这个工具能不能正常调用，排除掉接口本身的问题，再回到工作流里排查上游变量映射。

5. 第三步：用条件分支让工作流自己决定要不要调工具

5.1 为什么需要条件分支

按照第一步和第二步的搭建，整个链路已经能跑通了：用户提问 → LLM 提取参数 → 工具查询 → LLM 组织回答。但这里有一个非常明显的浪费：如果用户只是随口问了一句“你好”，整个流程也会先跑一遍天气查询，白白浪费一次 API 调用，还会让回答变得莫名其妙。

更合理的做法是让工作流先判断“用户是否真的问了天气”，如果没问，就直接让模型正常回复；如果问了，才进入工具调用路径。这就是条件分支节点存在的意义：根据意图判断结果，决定后续的流程走向。

这个设计思想放在真实业务里非常实用。比如你要做一个客服助手，用户可能是来问退货政策的，也可能是查订单状态的，还可能是骂人的。每种情况对应的工作流路径完全不同。你总不可能让所有问题都走一遍订单查询、走一遍知识库检索。用条件分支将不同意图分流，既省资源又让回答更精准。

5.2 实操：用意图判断节点 + 条件分支实现分流

我们继续用“天气查询助手”这个例子。

先加一个 LLM 节点，命名为“意图判断”，Prompt 让它输出两个单词之一：weather或other。然后在它后面添加条件分支节点，配置两个分支条件：

• 分支 A：意图判断节点的输出文本 ==weather
• 分支 B：其他情况，也就是 ==other

分支 A 连接到“提取城市名 → 天气查询 → 生成回答”这条路径；分支 B 直接连接到结束节点，输出一句“我目前只会查天气，有其他需要请告诉我”。

运行一下，输入“北京天气怎么样”，你会看到流程进入分支 A，正常调用了天气工具；输入“今天中午吃什么”，流程进入分支 B，没有调用任何工具。这样工具的调用时机完全由工作流内部的判断逻辑控制，不会因为无关输入而产生多余的开销。

这里有个实操经验：条件分支的判断条件尽量用“等于某个固定值”，而不要用“包含某个关键词”。因为 LLM 输出虽然稳定，但偶尔还是会冒出多一个空格、多一个句号的情况。如果你担心输出不完全可控，可以配合 LLM 节点 Prompt 里的“必须只输出一个单词，没有任何标点”来约束。即便如此，条件分支里的值最好设置成与 LLM 输出完全一致的样子，两边不要出现差异。

5.3 把“三步”串起来后，整个流程长什么样

经过第三步的调整，整个可视化工作流的逻辑已经比较完整了。用文字描述一下整体结构：

1. 开始节点接收用户输入。
2. LLM 节点（意图判断）判断用户意图。
3. 条件分支按意图分流：非天气问题直接回复；天气问题进入下一步。
4. LLM 节点（提取城市名）从问题中提取城市。
5. 工具节点调用天气 API 获取数据。
6. LLM 节点（生成回答）根据天气数据生成自然语言回复。
7. 结束节点返回最终结果。

整个链路里有两个 LLM 节点、一个工具节点、一个条件分支节点。你可能会想：为什么需要两个 LLM 节点？能不能让一个 LLM 节点同时做“意图判断”和“城市提取”？

在简单场景里当然可以。但随着业务复杂度增加，把职责拆分开通常更划算：意图判断只需要极少的输出，城市提取则是另一个维度的信息抽取。拆开之后，你可以在意图判断节点用更小的模型，在城市提取节点用更强的模型，这样成本控制更精细。这也是可视化工作流的灵活之处——你可以自由编排不同节点组合出合适的链路。

6. 调试实操：常见报错、排查方法与优化心得

6.1 我最常遇到的三个报错现象

在实际搭建和运行工作流的过程中，有几个问题是我反复遇到的，值得单独拿出来讲。

第一个是“变量未定义”的问题。典型表现是节点配置里引用了某个变量，但运行时报错说找不到这个值。原因多半是上一步节点没有执行成功，或者引用的变量名拼写与节点输出里的字段名不一致。我的处理方法是：先在调试面板里展开上游节点的输出，找到真实存在的字段名，再回到下游节点的输入里重新引用。

第二个是“工具节点请求超时”。这个往往是外部接口响应太慢导致的，不一定是工作流配置问题。建议在工具节点设置合理的超时时间，同时在工作流里增加失败兜底分支。如果接口经常超时，优先排查接口自身的性能，而不是每次都在工作流里做重试。

第三个是“LLM 节点输出格式不稳定”。比如你要求它输出 JSON，它偶尔会在 JSON 前后加一句解释文字，导致下游工具节点解析失败。解决方案是在 Prompt 里给出明确的格式规范，并提示“不要输出任何其他内容”。如果还不稳定，可以再搭配一个代码节点做 JSON 提取，把大模型回答中的 JSON 片段剥离出来。

6.2 官方调试工具的使用顺序

Dify 工作流编辑器里通常自带调试面板和日志功能。我排查问题的固定顺序很简单：

1. 先跑通整条链路，确认没有节点级报错。
2. 如果某一步结果不对，点开该节点的运行日志，查看输入和输出。
3. 根据输入判断是不是上游变量传错了，或 Prompt 不够精确。
4. 修改配置之后，重新运行，不要跳步观察。

这样做看起来朴素，却是最快定位问题的方式。比起盯着画布猜逻辑，直接在日志里看数据更实在。很多时候，你以为问题出在“模型不理解”，实际上却是“参数没传进去”。

6.3 流程优化的三个方向

当工作流能稳定跑通以后，下一步就是优化。我总结下来，主要从三个方向入手：

• 减少不必要的模型调用：如果一句话能靠规则判断出来，就不要交给 LLM。条件分支里也可以用关键词快速命中，省掉一次大模型调用，节省成本也降低延迟。
• 控制 Prompt 长度：不要把大段历史聊天记录全部塞进每个 LLM 节点。尽量只传递与当前步骤相关的中间结果。上下文越长，费用越高，响应也越慢。
• 把可复用的子流程抽出来：如果好几个流程里都有“用 LLM 提取 JSON 字段”这种操作，可以考虑单独做成一个子流程，在多个工作流里复用。后续要改提取逻辑，改一处即可。

这些优化点做下来，整个工作流的执行效率和可维护性都会明显提升。我也见过一些团队一开始图省事把所有逻辑塞在一个节点里，后来每次调整都头痛。可视化工作流的优势之一就是“分而治之”，前提是你愿意花一点时间把节点职责理清楚。

6.4 从实验到上线：发布前检查清单

无论工作流在编辑器里跑得多顺畅，真正发布前我都会过一遍自己的检查清单：

• [ ] 所有外部 API 密钥是不是放在安全的环境变量里，而不是在节点配置里写死。
• [ ] 工具节点异常时有没有兜底分支，是否会直接暴露错误信息给最终用户。
• [ ] 结束节点的输出字段是不是和调用方约定的一致。
• [ ] 发布前有没有用一批真实用户的输入做过回归测试。
• [ ] 时间敏感的接口调用有没有设置合理的超时时间。

这些内容不一定写在 Dify 的官方教程里，但对于实际上线运行非常重要。可视化工作流把搭建门槛降低了，但在正式业务里，工程化思维仍然一个都不能少。

我个人在实际操作中的体会是，Dify 这类可视化工具最值钱的地方，不是省掉了几行代码，而是把“想清楚流程”这件事的难度大大降低了。以前你要先写代码再验证思路，现在你可以在画布上一遍遍调整分支和节点，五分钟就能把想法变成一条可运行的链路。这套“三步走”的思路——先打通 LLM 基础链路，再接工具，再加判断逻辑——几乎可以套用到任何工作流的设计中去。等你搭过一两个完整的流程之后，再回头看那些复杂的业务，思路会很自然地拆解成一个个节点和一条条连线。最后再分享一个小技巧：第一次搭建时别急着把流程做得太大，先让最小链路跑通，再往上面加节点加分支。每一步的修改都是有据可查的，出了问题也知道从哪儿下手。可视化工作流的魅力就在于“随时调整、立刻看到效果”，这个特性值得充分利用起来。