当前位置：首页 > news >正文

Dify搭建Agent工作流：从本地部署到客服工单自动化实战

news 2026/8/30 15:00:33

每天早上快速浏览一遍 AI 圈子的最新动态，已经是很多开发者的固定习惯。今天这期日报里有三条值得关注的信息：Dify 社区版在 Agent 与工作流方向持续迭代，越来越多团队开始用它搭建可复用的人机协同流程；OpenAI 方面出现 Project Astra 暂停的社区传闻；Grok Image 2.0 疑似开始灰度推送，部分用户已经晒出了新生成的图像。三条消息看起来分散，指向的趋势却是一致的——AI 能力正在从“单点模型调用”走向“完整工作流编排”。本文不打算只做新闻搬运，而是以 Dify 搭建 Agent 工作流为主线，把背后的核心概念、部署方式、节点配置、常见报错和工程化建议完整拆开，尽量让读者从零开始也能搭出一条可运行的工作流。

1. AI日报速览：Agent 工具链正在成为焦点

1.1 今日三条核心动态

先快速看一下本期日报提到的三条消息，各自的背景和对开发者的潜在影响：

动态	大致背景	对开发者的影响
Dify 社区版持续迭代	开源 LLM 应用开发平台，工作流、Agent、知识库、RAG 能力不断更新，社区热度高	搭建 Agent 应用门槛进一步降低，成为个人开发者和中小团队的首选平台之一
OpenAI 被传暂停 Project Astra	社区流传 Astra 项目出现暂停迹象，具体原因尚未确认	声音助手类产品的研发路线可能调整，短期不必过度解读
Grok Image 2.0 疑似灰度推送	部分用户在社交平台反馈图像生成结果变化，推测是新版本开始灰度放量	图像生成赛道竞争加剧，应用侧接入多模态模型时可保持关注

这里要说明一下，Astra 暂停和 Grok Image 2.0 推送目前都还停留在社区讨论层面，官方没有给出完整的版本说明。做技术选型时，不要因为一条新闻就立刻换掉主力模型或重写应用架构，更合理的做法是持续观察，并在自己的测试环境里验证新能力。

1.2 日报背后的技术主线

这三条动态放在一起，可以发现一个共同点：模型能力再强，最终都要落到具体的业务流程里才有价值。

OpenAI、Grok 这些模型侧的新进展解决的是“模型能做什么”的问题，而 Dify 这类平台解决的是“如何把模型接入业务，并且让流程稳定可控”的问题。近年来 Agent 开发的热度持续上升，核心原因也在于此：大模型本身更像一个“能力单元”，Agent 则负责理解目标、拆解任务、调用工具、检查结果。要把这一套过程固化下来，不能只靠写 Prompt 或者在聊天窗口里反复试，而是需要一个可视化、可复用、可观测的编排环境。

Dify 的工作流功能正是从这个角度切入的。它允许开发者用画布的方式把 LLM 节点、知识检索节点、工具节点、条件分支节点串起来，形成一条具备业务语义的流水线。相比直接调用 API 写代码，工作流的优势在于修改逻辑时不用改代码、排错时有日志、发布后可以通过 API 和 Web 界面同时接入。这也是接下来全文要重点展开的内容。

2. Dify 与 Agent 工作流核心概念

2.1 Dify 是什么

Dify 是一个开源的大语言模型应用开发平台，通常被称为 LLMOps 平台。它把模型管理、Prompt 编排、知识库、Agent、工作流、应用发布等能力整合到同一个系统里，让开发者不需要从零搭建前后端和模型调用链路。

从使用方式上看，Dify 有两个明显的特点：

低代码甚至零代码：业务逻辑通过画布连线完成，不强制写代码，但又保留了代码节点，方便处理复杂逻辑。
模型无关：可以接入 OpenAI、Anthropic、通义千问、智谱、Ollama 本地模型等多种供应商，模型切换不用重写应用。

在企业级场景中，Dify 经常被用来做客服机器人、企业知识库问答、数据分析助手、自动化流程触发器等。它的社区版可以私有化部署，数据保存在自己的服务器里，这也是它受到国内开发者和企业欢迎的重要原因。

2.2 什么是 Agent，什么是工作流

这两个概念容易混淆，先做一个通俗解释。

Agent 可以理解为一个“有目标的智能体”。它不只是回答一个问题，而是能根据用户目标，自动规划步骤、选择合适的工具、执行操作，并根据执行结果决定是否需要调整策略。比如用户说“帮我查一下昨天订单异常的原因”，Agent 可能需要先查询订单系统、再对比日志、最后生成结论。

工作流则是把一整套执行过程固定下来，用节点和连线表达“先做什么、再做什么、满足什么条件走哪条分支”。它更像是流程引擎：由开发者预先定义节点顺序，用户输入进来后按照固定流程流转。

两者之间的关系可以这样理解：

工作流适合流程相对稳定、规则清晰、结果可预期的场景。
Agent 适合开放性强、需要模型自主决策、工具组合不确定的场景。
在 Dify 中，两者不是对立的。你可以搭建一个纯工作流，也可以搭建 Agent 应用，还可以把 Agent 能力封装成一个节点放进工作流里。

实际项目中，更常见的做法是“工作流为主、Agent 为辅”：用工作流保证流程稳定性和可维护性，只在需要动态决策的地方交给 Agent。这样既避免了完全自由的 Agent 不可控，又避免了纯工作流不够灵活的问题。

2.3 Agent 开发学习路线中的 Dify 定位

很多初学者会问：学 Agent 开发，应该直接从 LangChain 开始，还是先学 Dify？这里给一个比较务实的建议：

如果目标是快速做原型、验证业务逻辑、交付一个可演示的应用，Dify 的效率和性价比非常高。
如果目标是深入理解 Agent 内部原理、做底层框架开发、研究模型调优，需要学习 LangChain、LlamaIndex 或直接阅读模型 API 文档。
更合理的路线是先用 Dify 建立全局认知，理解节点、数据流、工具、知识库这些概念，再回到代码层面看具体实现。

也就是说，Dify 不只是“拖拽工具”，它能把 Agent 开发中的核心要素全部具象化。弄懂了 Dify 工作流，再去看 LangChain 里的 Chain、Tool、Memory，会有一种“原来对应的是同一个东西”的感觉。

3. 环境准备：本地部署 Dify 社区版

3.1 两种使用方式

Dify 提供两种主流使用方式：

云服务版：直接访问 Dify 官网创建账号，无需自己部署，适合快速体验和小规模测试。
社区版自部署：通过 Docker Compose 部署在自己的服务器或本机，适合数据敏感、需要二次开发、长期稳定使用的场景。

如果只是学习，可以先试云服务版。如果希望跟随本文搭建更完整的开发环境，或者把工作流接入自己的私有数据，建议选择自部署。自部署的版本差异相对灵活，本文以 Docker Compose 方式为例，版本需要根据你的项目实际情况调整，重点演示配置思路。

3.2 Docker Compose 部署步骤

自部署 Dify 最常用的方式是 Docker Compose，整套依赖包括 API 服务、Worker、Web 前端、PostgreSQL、Redis、Weaviate 等。部署步骤如下：

第一步，克隆 Dify 官方仓库并进入 docker 目录：

git clone https://github.com/langgenius/dify.git cd dify/docker

如果在国内访问 GitHub 比较慢，也可以把仓库下载为压缩包再上传到服务器解压。这里顺便提醒一句：部署时请确保服务器具备正常的网络访问能力，能够拉取 Docker 镜像，后续启动过程才不会卡在镜像下载环节。

第二步，复制环境变量文件：

cp .env.example .env

.env 文件里包含数据库密码、密钥、中间件配置等参数，默认值可以直接用，但生产环境建议修改默认密码。

第三步，启动服务：

docker compose up -d

启动过程会拉取多个镜像，耗时取决于网络状况。看到所有容器状态为 running 后，访问http://服务器IP即可打开 Dify 控制台。

通过以下命令可以查看容器状态：

docker compose ps

第一次访问时会引导创建管理员账号，设置好邮箱和密码后即可登录。

3.3 配置模型供应商

Dify 本身不提供大模型能力，需要在后台配置模型供应商，工作流里的 LLM 节点才能被调用。

登录控制台后，进入“设置”页面，找到“模型供应商”。这里支持 OpenAI、Anthropic、Azure OpenAI、智谱、通义千问、Ollama 等多种渠道。

以配置 OpenAI 为例，需要准备 API Key，并在供应商页面对应位置填写。如果是国内可直连的模型服务，选择对应供应商后，通常在模型列表里能看到可选的模型名称。配置完成后，可以在“模型供应商”页面点击测试，确认调用正常。

如果希望通过本地模型做开发调试，可以配置 Ollama。在服务器上安装 Ollama 并拉取模型后，在 Dify 模型供应商页面选择 Ollama，填写 Ollama 服务的地址和模型名称即可。这种方式的好处是不依赖外部 API，适合隐私要求高的实验场景。

模型配置是整个工作流运转的前提，建议在进入画布编排之前先完成这一步，否则后续调试时每个 LLM 节点都可能报“模型未配置”或“凭证无效”的错误。

4. 搭建 Agent 工作流核心节点

4.1 工作流控制台基本认识

在 Dify 工作台创建一个新应用时，应用类型选择“工作流编排”，进入后可以看到一块画布。画布左侧是节点面板，画布上是开始节点和结束节点。通过拖动节点并连线，可以把不同能力串起来。

工作流的运行逻辑可以理解为数据流：用户输入从开始节点进入，经过各节点处理后，最终由结束节点输出。每个节点有输入和输出，后一个节点可以引用前一个节点的输出变量。Dify 会在参数配置区提供变量选择器，选中前置节点后会自动生成引用表达式，不需要手写复杂的变量路径。

工作流的调试方式也很直观：右上角可以填写测试输入并运行，系统会逐步展示每个节点的输入输出。这个特性在排错时非常有用。

4.2 开始节点与结束节点

开始节点是工作流的入口，通常定义用户输入字段，比如“用户问题”“用户ID”“会话上下文”。它的作用是把外部传入的参数绑定为工作流变量。

结束节点决定工作流的最终输出内容，可以是固定文本，也可以引用前面某个节点的输出。比如客服场景中，可以最终返回 LLM 节点生成的回答文本。

这部分需要特别注意：结束节点的输出格式，直接决定了 API 调用方拿到的响应结构。如果对接到前端聊天组件，输出通常应为模型回复的字符串；如果对接到业务系统，可以输出 JSON 结构，方便后续程序解析。

4.3 LLM 节点与提示词编排

LLM 节点是工作流中最常用的节点，作用就是调用大模型执行某个明确的任务。

在 LLM 节点配置中，需要关注几个关键部分：

模型选择：不同模型的推理能力和响应速度差异很大，简单场景用轻量模型可以节省成本。
上下文：可以引用开始节点的用户输入，也可以引用前面节点的输出。
Prompt 体系：系统提示词定义模型角色和行为边界，用户消息部分传入实际需要处理的文本。

举个例子，一个意图识别节点可以这样写系统提示词：

你是一个意图识别助手。根据用户问题，输出以下分类之一：aftersales、presales、chat。 只返回分类名称，不要输出其他内容。

用户消息部分传入{{开始节点中的用户输入}}，LLM 的输出就是我们需要的分类。这里需要说明的是，变量选择器会自动生成引用表达式，实际显示形式以画布中的变量选择结果为准。

LLM 节点是工作流中最核心的“智能”来源，它可以承担文本分类、内容生成、信息抽取、多轮对话等各种任务。一个复杂工作流往往会包含多个 LLM 节点，分别承担不同职责。

4.4 知识检索节点

知识检索节点用于从知识库中召回与用户问题相关的文档片段，是大模型结合私有数据的关键节点。它解决的问题是：模型没有学习过的内部资料，如何通过检索增强生成的方式让模型基于资料回答。

使用知识检索节点前，需要先在“知识库”模块创建数据集并上传文档。Dify 会自动对文档切片、向量化，建立索引。检索节点配置时，需要选择数据集，并设置召回数量 TopK 和相似度阈值等参数。

TopK 决定了召回多少条相关片段，值越大，模型能看到的信息越多，但噪声也可能增加；相似度阈值用于过滤低相关片段，阈值越高召回越严格。建议根据测试结果调整，不要在第一次配置时就追求极端值。

知识检索节点输出的通常是文档片段列表，在后续 LLM 节点中，需要把检索结果拼接到 Prompt 里，让模型基于这些片段生成回答。设计 Prompt 时，应明确提示模型“只基于给定的资料回答，不要编造”，从而减少幻觉。

4.5 工具节点、条件分支与代码节点

工具节点让工作流具备了调用外部系统的能力。它可以是 Dify 内置的工具，也可以是通过 OpenAPI Schema 定义的自定义工具。实际项目中，常见的工具包括：查询订单接口、创建工单接口、获取天气信息、调用搜索服务等。

条件分支节点用于流程的分流。它基于某个变量的值进行判断，满足条件则走对应分支。比如意图识别后，如果意图为“售后”就走知识库查询分支，如果意图为“售前”就走商品推荐分支。

代码节点支持运行 Python 或 Node.js 代码，适合处理复杂的数据转换、字符串拼接、逻辑计算等场景。它接收输入变量，代码执行后返回输出变量。下面是一个简单的 Python 代码节点示意：

# 这是一个代码节点示例 # 输入变量：intent, query # 输出变量：message def main(intent: str, query: str) -> dict: if intent == "aftersales": message = f"售后问题已收到：{query}" elif intent == "presales": message = "正在为您查询商品信息..." else: message = "感谢您的咨询，请补充更多信息。" return {"message": message}

代码节点的好处是灵活，可以完成很多低代码节点难以实现的逻辑，但也要注意不要写过于复杂的逻辑，否则会导致工作流难以维护。保持每个节点职责单一，是工作流设计的重要原则。

5. 实战：搭建一个客服工单 Agent 工作流

5.1 需求分析与流程设计

为了把上面的节点概念串联起来，这里设计一个“智能客服工单 Agent”案例。

业务背景：一家电商平台需要自动处理用户的咨询和售后问题。用户发送消息后，系统要判断用户意图，并从知识库中寻找解决办法。如果知识库无法解决，则自动创建人工工单，随后通知用户人工客服将介入。

这个需求如果只用单个 LLM 节点提示词完成，所有逻辑都会混在 Prompt 里，难以维护；如果全部交给 Agent 自主决策，又可能出现不可控的工具调用。因此，采用工作流方式，把流程拆成明确步骤。

工作流设计如下：

开始节点：接收用户问题。
LLM 节点：对用户问题进行意图识别，输出售后、售前、闲聊三类意图。
条件分支节点：根据意图走不同分支。
售后分支：知识检索 → 判断是否有高置信度答案 → 有则直接回答，无则调用工单 API 创建工单。
售前分支：LLM 节点根据商品知识生成推荐回复。
闲聊分支：LLM 节点直接生成闲聊回复。
结束节点：输出最终回复文本。

这个流程虽然不复杂，但已经覆盖了工作流最常见的核心要素：LLM、知识库、条件分支、工具调用、输出聚合。

5.2 各节点配置过程详解

下面展开说明每个节点的配置要点。

开始节点配置：

输入字段	类型	说明
query	字符串	用户输入的问题文本
user_id	字符串	用户的唯一标识，供后续创建工单使用

LLM 意图识别节点配置：

模型：选择一个响应速度较快的模型。
系统提示词：要求模型只输出分类名称，例如aftersales、presales、chat。
用户消息：引用开始节点中的query。

条件分支节点配置：

判断变量：引用 LLM 节点的输出text。
分支条件：
- 等于aftersales，走售后分支。
- 等于presales，走售前分支。
- 默认走闲聊分支。

售后分支中的知识检索节点配置：

选择数据集：商品售后 FAQ 知识库。
TopK：设置为 3。
相似度阈值：0.5 到 0.65 之间，需要测试调整。

知识检索后，接一个 LLM 节点生成最终回答。系统提示词强调“只基于给定资料回答”，上下文同时引用检索结果和用户原始问题。

如果检索置信度低，需要创建工单。这里可以设计一个条件分支，判断检索结果是否为空或置信度是否低于阈值，如果满足条件则进入 HTTP 请求节点或代码节点，模拟调用外部工单系统。下面是一个 HTTP 请求节点的配置思路：

请求方法：POST。
请求地址：例如https://api.example.com/tickets。
Headers：包含认证 Token。
Body：包含用户 ID 和问题描述，变量引用开始节点的user_id和query。

售前分支的 LLM 节点相对简单，只需要让模型根据商品描述生成推荐回复，并提示允许追问。

结束节点统一输出售后分支、售前分支或闲聊分支的最终 LLM 输出。

5.3 工作流逻辑概念示意

Dify 工作流是用画布连线完成的，不需要编写整套代码。但为了帮助理解节点之间的数据流向，下面给出一段概念示意 Python 代码。它不用于替代 Dify 配置，只表示逻辑：

# 工作流逻辑示意（非Dify源码，仅用于理解流程） def workflow(query, user_id): # 开始节点 user_input = query # LLM节点：意图识别 intent = llm_classify(user_input) # 返回 aftersales / presales / chat # 条件分支 if intent == "aftersales": faq_docs = knowledge_retrieve(user_input, top_k=3) if len(faq_docs) == 0: ticket_id = create_ticket(user_id, user_input) answer = f"已为您创建人工工单，编号：{ticket_id}" else: answer = llm_answer_with_docs(user_input, faq_docs) elif intent == "presales": answer = llm_recommend(user_input) else: answer = llm_chat(user_input) # 结束节点 return answer

从这段示意代码可以看出，工作流的本质就是把这种“顺序 + 分支 + 工具调用”的逻辑固化成可视化流程。在 Dify 画布中，你不写这段代码，但节点之间的数据依赖关系与它一致。

5.4 发布与 API 调用

工作流调试通过后，点击发布，Dify 会生成一个可访问的应用版本。发布后，可以通过 Web 端聊天组件直接体验，也可以通过 API 接口集成到自己的业务系统。

API 调用的方式通常是在应用“访问 API”页面获取 API 密钥，然后向/chat-messages端点发送 POST 请求。下面是一个 Python 调用示例：

import requests API_ENDPOINT = "http://你的服务器地址/v1/chat-messages" API_KEY = "app-xxxxxxxxxxxxxxxx" payload = { "inputs": {}, "query": "我的订单已经付款了，为什么还没有发货？", "response_mode": "blocking", "conversation_id": "", "user": "demo-user" } headers = { "Authorization": f"Bearer {API_KEY}" } response = requests.post( API_ENDPOINT, json=payload, headers=headers, timeout=30 ) print(response.status_code) print(response.json())

运行后，如果工作流配置正确，响应中会包含最终的回答文本，也就是结束节点输出的内容。这里需要提醒：API 地址、请求字段在不同 Dify 版本中可能有细微差异，实际使用以你自己部署的版本为准。

5.5 运行验证与效果观察

在正式接入前，建议用多组测试数据进行验证：

售后类问题：例如“如何申请退货”，预期是触发知识库检索，返回 FAQ 答案。
知识库覆盖不到的问题：预期是创建工单，并返回工单编号。
售前类问题：例如“这款手机有 256G 版本吗”，预期进入售前推荐分支。
闲聊类问题：例如“你好”，预期走闲聊分支。

运行调试时，Dify 会展示每个节点的输入和输出。如果结果不符合预期，重点检查两个地方：一是条件分支里的判断值是否与 LLM 节点实际输出完全一致，比如模型输出了多余空格导致匹配失败；二是知识检索是否召回了正确内容，以及阈值是否设置合理。

6. 常见问题与排查思路

搭建 Dify 工作流的过程中，比较容易遇到下面几类问题。

问题现象	常见原因	解决思路
工作流导入或运行时提示“缺失节点或缺少依赖包”	使用了自定义节点，但 Python 环境中缺少依赖	根据提示在对应环境中安装依赖，或改用平台内置节点
Agent 执行器超时，提示 provider did not respond in time	模型推理速度慢、网络不稳定、模型配置不可用	更换轻量模型，检查网络连通性，适当调大超时时间
知识库检索结果不准确，回答经常答非所问	文档切片粒度不合理、TopK 偏大、相似度阈值过低	清洗数据，调整切片长度和 TopK，提高相似度阈值
HTTP 节点调用外部接口失败	接口地址错误、认证失败、返回体格式不符	先用 curl 或 Postman 单独测试接口，再检查节点配置
发布后 API 调用返回 401	API 密钥未配置或已失效	在应用访问 API 页面重新生成密钥并更新请求 Header
条件分支总是走到默认分支	LLM 节点输出与条件值不匹配，存在空格或大小写差异	打印 LLM 节点实际输出，在 Prompt 中约束输出格式

6.1 工作流导入提示“请安装缺失的包”

这个报错在引入社区插件或自定义节点时经常出现。它的核心原因是：当前 Dify 运行环境的 Python 包列表与节点要求不一致。解决思路是定位报错信息中提到的包名，在 Dify 容器或宿主机对应 Python 环境中安装依赖，再重启服务。

需要提醒的是，不要在生产环境随意安装来源不明的包。如果某个自定义节点长期维护不良，更好的方案是阅读它的源码，确认逻辑后自己实现，或直接改用平台内置节点。

6.2 Agent 执行器未及时响应

“the agent execution provider did not respond in time”这类超时提示，通常不是因为工作流逻辑写错，而是模型侧没有在预期时间内返回结果。可能原因包括：选择了大参数模型导致推理慢、模型服务所在区域网络延迟高、API 限流等。

建议排查顺序是：先手动测试模型供应商配置是否正常，再切换到一个速度更快的模型，最后调整客户端或服务端的超时配置。把超时时间设置得过长并不是好方案，因为用户侧体验会变差，适当设置超时并在超时后返回兜底文案，是更稳妥的做法。

6.3 知识库检索质量差

知识库问答的效果很大程度取决于“数据进得怎么样”。如果文档本身包含大量无关内容、切片后片段语义不完整、Embedding 模型与实际场景不匹配，检索质量一定不会好。

建议从三个方向优化：

数据质量：删除无关章节，统一格式，按业务模块拆分文档。
切片策略：针对不同文档类型调整切片长度和重叠长度，让每个片段语义相对完整。
检索参数：通过测试调整 TopK 和相似度阈值，观察不同参数对回答质量的影响。

知识库优化是一个反复迭代的过程，不要指望一次上传就能获得理想效果。Dify 后续版本在知识库流水线方向也有持续更新，建议关注官方 Release Notes。

7. 最佳实践与工程建议

工作流做到能跑只是第一步，做到可维护、可扩展、可治理，才是工程化的关键。下面结合实战经验，给出几条具体建议。

7.1 从简单流程开始，逐步扩展

新手很容易在第一次搭建时就把十几个节点连成一张大网，结果调试时根本不知道问题出在哪个节点。更推荐的做法是：先搭一条最小链路，比如“开始 → LLM → 结束”，让整条链路跑通后，再逐步加入知识检索、条件分支、工具节点等。

每加一个节点，就运行一次测试，确认新的节点输出符合预期。这样排错范围会小很多。工作流不是越复杂越好，稳定的简单流程，远胜于脆弱的复杂流程。

7.2 节点命名要具备业务语义

默认的节点名称通常是“LLM”“LLM2”“条件分支”，节点一多根本分不清。建议创建节点后立即重命名，比如：

intent_classify_llm：意图识别模型节点。
faq_retrieve：FAQ 知识库检索节点。
create_ticket_http：创建工单 HTTP 节点。
is_aftersales：售后判断条件分支。

命名规范不需要太复杂，做到“看到名字就知道这个节点的作用”即可。这对后续维护、交接、排查都有很大帮助。

7.3 模型分级与成本控制

不是所有节点都要用最强模型。意图识别、文本分类这类简单任务，可以使用响应更快的轻量模型；知识库总结、长文生成这类复杂任务，再使用更强的大模型。在 Dify 中，不同 LLM 节点可以选择不同模型，这一点为成本优化提供了空间。

实际项目中，可以通过流量监控了解每个节点的调用量，优先优化调用量最大的节点模型。如果某个节点长期占用高成本模型，但业务收益不明显，就值得重新评估它的模型选择。

7.4 工具调用必须做好权限与输入校验

当工作流需要调用外部系统时，必须考虑安全问题。以下几点建议一定要重视：

API 密钥不要写死在前端代码或请求 URL 中，尽量由服务端统一保管。
对所有用户输入做合法性校验，防止通过 Prompt 注入的方式让模型执行非预期操作。
涉及创建订单、删除数据、转账等敏感操作时，建议增加人工确认环节，不要让工作流自动执行高风险动作。
对生产环境变更保持谨慎，任何工作流调整都先在测试环境验证。

技术工具本身是中性的，是否能安全使用取决于工程规范。把权限边界、操作审计、异常兜底设计好，工作流才能从“玩具”变成“生产工具”。

7.5 保留日志，持续观测

Dify 后台提供了运行日志和链路追踪能力。生产环境建议定期查看节点执行记录，关注以下指标：

节点失败率：哪个节点最容易失败。
平均响应时间：用户从发起到收到回复耗时。
工具调用成功率：外部接口是否稳定。
知识库命中率：检索是否经常为空。

这些数据是优化工作流的重要依据。没有观测，就没有改进方向。

8. 总结与学习路线

这篇文章从 AI 日报的三条动态切入，重点落在 Dify 搭建 Agent 工作流这条技术主线上。你在本文中应该已经掌握了几个关键点：Dify 在大模型应用开发中的定位，Agent 与工作流的关系，Docker Compose 部署 Dify 社区版的方法，工作流核心节点的作用，以及如何把一个客服工单 Agent 的流程从设计到发布完整落地。常见报错的排查思路和工程化建议，也可以直接在后续项目中复用。

下一步如果你打算继续深入学习，可以沿着这几个方向走：