基于Dify工作流的AI查单助手实践

原创 G.D. 拍码场

2025年02月12日 03:18

1. 前言

在线下渠道业务场景中，业务经由各个渠道的一线业务员从渠道侧获客，通过渠道准入校验后进行借款流程。在一线业务员跟单的过程中，会遇到一些卡单的问题，如渠道侧信息填写错误、用户证件绑定在其他账号、用户无法登录等。

通常遇到问题时，一线业务员会第一时间反馈给客服，客服无法解决的会继续反馈，最终无法解决的问题会抛给研发。在拍周转上线初期和每个新渠道接入的初期研发会收到较多问题反馈，占用大量研发资源。为了节约研发资源，提升卡单问题排查效率，我们决定做一款给客服使用的工具，以便快速解决客服的问题，同时将研发从简单问题排查中释放出来。

研发排查问题通常是先拿到企业名称，然后根据企业名称查DB中的进件记录，根据当前订单状态进行分析，通过查表、查日志等方式找到卡单的原因给客服答复。我们认为这一系列【查询-分析】的流程是可以通过【工作流-LLM】的方式来实现的。我们在Dify平台快速走通了POC流程，于是决定使用Dify工作流搭建一个AI查单助手。

2. 认识Dify工作流

Dify 工作流通过将复杂的任务分解为较小的步骤（即节点），从而降低系统的复杂度。这种方式不仅减少了对复杂提示词技术和模型推理能力的依赖，还显著提高了大语言模型（LLM）在应对复杂任务时的性能。此外，它还能提升系统的可解释性、稳定性和容错性。

Dify 工作流有两种主要类型：

Workflow：适用于自动化和批处理情境，适合于高质量翻译、数据分析、内容生成以及电子邮件自动化等应用。
Chatflow：针对对话类场景，包括客户服务、语义搜索以及其他需要多步逻辑处理的对话式应用程序。

典型的应用场景包括：

客户服务：通过将 LLM 集成到客户服务系统中，可以实现常见问题的自动化回答，减轻支持团队的负担。LLM 能理解客户查询的上下文和意图，并实时生成准确且有帮助的回答。
内容生成：无论是博客文章、产品描述还是营销材料，LLM 都能帮助生成高质量的内容。只需提供一个大纲或主题，LLM 将利用其广泛的知识库创建引人入胜、信息丰富且结构良好的内容。
任务自动化：可以集成到各种任务管理系统，实现项目和任务管理的自动化。通过自然语言处理，LLM 理解和解释用户输入，创建任务、更新状态及分配优先级，无需手动干预。
数据分析和报告：LLM 能分析大型知识库并生成报告或摘要。通过为 LLM 提供相关信息，它可以识别趋势、模式和洞察，将原始数据转化为可执行的情报。对于希望做出数据驱动决策的企业来说，这种能力尤其有价值。
邮件自动化处理：LLM 可以用于撰写电子邮件、社交媒体更新及其他沟通形式。用户只需提供大纲或关键要点，LLM 就能生成结构良好、连贯且上下文相关的信息。这节省了大量时间，并确保回复的清晰性和专业性。

3. 查单助手1.0的实践--Agent+Workflow

在AI查单助手设计的初期，我们调研了如下3种方式：

接入方式	说明	优点	缺点
纯 Workflow 方式	在最开始的 POC 流程种就是采用这种方案，编排好 Workflow 之后直接发布，直接使用	可简单快速接入，有固定输入格式	Workflow 的每一步中间数据会展示在前端，有数据泄露风险
Workflow + API 方式	编排好 Workflow 之后以 API 的形式发布，可供前端/后端调用，响应模式支持 streaming 和 blocking 两种	对外暴露 API，接入方式较为灵活	要给客服使用，还需要前端基于 API 进行开发
Workflow + Agent方式	编排好 Workflow 之后发布为工具，供 Agent 使用	通过 Agent 接入，无需页面改造，可直接将 Agent 嵌入到现有站点	增加一个 Agent，提高了成本和复杂度，降低了召回率

考虑到 ①数据泄露风险是不可接受的 ②基于API做展示侧的二次开发性价比不高，最终我们在AI查单助手1.0版本中采取的方案是 Workflow + Agent方式，其整体架构如下图所示：

在流程编排部分使用 Workflow 的功能处理核心业务逻辑，Workflow 中会查询 DB、日志、埋点数据，查到的数据按照不同的订单状态继续做对应的查询，然后做敏感信息混淆，将脱敏后的数据交给 LLM 分析卡单原因，经过 LLM 分析结合异常场景知识库给出最终卡单原因排查结论。编排完成的 Workflow 生成工具，供 Agent 使用，然后将 Agent 嵌入到渠道管理后台站点中。

3.1 Workflow 编排

Workflow 编排整体如下图所示：

其中，核心节点实现的功能如下：

开始：设置输入字段、系统变量等，业务一般是设置输入的企业名称、订单号等
代码执行：业务参数处理、json 解析、敏感字段混淆等
HTTP请求：调用相关业务查询接口、日志查询接口、异常场景通知接口等
条件分支：根据接口查询情况、订单状态等决策不同情况下的分析策略
变量赋值：用于向可写入变量进行变量赋值，用于后续对话的引用
模板转换：通过 Jinja2 模板引擎处理相关变量
问题分类：定义分类描述，问题分类器根据输入，使用 LLM 推理并输出分类结果，根据结果选择执行后续节点
LLM调用：调用大模型的能力，自定义系统提示词，处理包含前置节点输出的变量（主要为混淆后的日志信息）的用户提示词，给出有效的回应信息
知识检索：查得异常场景时，LLM 知识库中检索出异常码对应的客服解释文案
结束：Workflow 执行完成后至少需要一个结束节点，结束节点将最终要输出的文案以 json 的形式输出

3.2 工具

上文提到，由于中间数据直接对客展示，直接给客服使用 Workflow 可能存在数据泄露风险，所以我们需要以 Agent 的形式给客服展示。然而，Agent 是无法直接使用 Workflow 的，但 Agent 能够使用工具，所以将 Workflow 封装为工具供 Agent 使用。

工具是什么

工具可以扩展 LLM 的能力，比如联网搜索、科学计算或绘制图片，赋予并增强了 LLM 连接外部世界的能力。工具使用户可以在 Dify 上创建更强大的 AI 应用，如你可以为智能助理型应用（Agent）编排合适的工具，它可以通过任务推理、步骤拆解、调用工具完成复杂任务。方便将你的应用与其他系统或服务连接，与外部环境交互，如代码执行、对专属信息源的访问等。Dify 提供了三种工具类型：内置工具、自定义工具和工作流工具。

内置工具

Dify 平台提供了丰富的内置工具，可以直接添加到 Agent 或工作流中，方便快速接入。

自定义工具

若内置工具无法满足需求，还可以导入自定义的 API 工具（目前支持 OpenAPI / Swagger 和 OpenAI Plugin 规范）。

工作流工具

在AI查单助手的构建中，我们希望 Agent 能够使用工作流，Dify 平台也实现了只需简单配置即可将工作流发布为工具。

发布后的工具可以被一个或多个外部实体（如 Agent 或工作流）多次使用。

3.3 Agent

以 Agent 的形式对客展示，需要在 Agent 上填写合适的提示词，包括

输入校验：确保只处理用户的查单问题，拒绝回答其他任何问题
查询关键词提取：提取用户输入的企业名称、订单号等相关信息
使用工具约束：确保每次提问的处理，Agent 都需要使用一次工具
回答内容约束：确保 Agent 取得 Workflow 输出的结果后，不做多余的加工

最后，在 Agent 中添加前置发布完成的工作流工具即可。

3.4 LLM 的选用与性能测试

在调试中，基于性能和成本的考量我们选用了 doubao-pro-128k 和 gpt-4-turbo 进行测试，发现在 Workflow 的日志分析节点中 doubao-pro-128k 和 gpt-4-turbo 均有很好的表现。考虑到成本因素，日志分析节点我们最终选择了 doubao-pro-128k。

在 Agent 的调试中，我们发现 doubao-pro-128k 无法正确地使用工具，gpt-4-turbo 能很好地使用工具，因此我们选择了 gpt-4-turbo。

4. 查单助手2.0的实践--Chatflow

在以 Workflow + Agent 方式构建的AI查单助手1.0经过了半个月的试用和优化，统计到共提问 26 次，有 14 次得到了满意的答案，召回率约为 53.8%。查看查单助手无法给出答案的对话日志，我们发现有 3 条是由于 Agent 没有能正确提取关键词导致后续 Workflow 无法正常工作。同时，计算 Token 消耗情况，得出每个问题的成本约为 0.31 元。

4.1 从 Agent+工具+Workflow 到 Chatflow

为了成本控制和性能提升，在AI查单助手1.0的基础上，我们构建了一套基于 Chatflow 的AI查单助手2.0，使用 Chatflow 替代了原本 Agent+工具+Workflow 的模式。Chatflow 会将用户输入以 sys.query 字符串变量的形式填充到 开始 节点中。如下图所示，Chatflow 使用 直接回复 替代了 Workflow 的 结束 节点，直接回复 节点除了直接将文本以回答的形式展示到对话框，还提供了文本格式化的功能，支持 markdown 和 html 格式，因此 Workflow 中使用 Jinja2 模板引擎的 模板转换 节点也被替换掉了。

原本 Agent 中实现的功能，我们也需要在 Chatflow 中找到替代方案。输入校验环节，在 Chatflow 中我们采用了问题分类器，若用户输入的不是查单相关问题，问题分类器会流转到下一个节点直接回复，而不会进入常规查单流程。查询关键词提取环节，doubao-pro-128k 完全能够胜任，不再需要使用 gpt-4-turbo 了。Chatflow 的整体架构将聊天助手和工作流耦合在一起，因而不再需要使用工具约束和回答内容约束了。

4.2 Chatflow 集成到渠道管理后台

Chatflow 可以很方便地嵌入任何你需要嵌入的站点

最终呈现的效果如下：

在 AI查单助手的协助下，客服在应对无法处理的“卡单问题”时，由过去的寻求运营、产品、测试、研发等同事的帮助转变为直接向 AI 提问，解决问题的时效也由 10-30 分钟缩短至约 10 秒。确保了每一笔订单的准确性和客户满意度，为客户提供了更加快捷的服务体验。

4.3 成本和性能验证

AI查单助手2.0 经过半个月的试用后，开放给客服使用，统计半个月客服提问情况，共提问 56 次，其中有 39 次得到了满意的答案，召回率约为 69.6%，较AI查单助手1.0提升约 16 个百分点。计算 Token 消耗情况，得出每个问题的成本约为 0.006 元，较AI查单助手1.0节约成本 0.3 元。