AI Agent开发第48课-DIFY中利用AI动态判断下一步流程-DIFY调用API、REDIS、LLM

开篇

之前我们在《AI Agent开发第47课-DIFY处理多步流程慢?你确认用对了?》中讲述了DIFY的设计中在整合多步LLM时如避免过多调用LLM的良好设计,并给出了AI工作流的相应设计手法。今天我们要在上一篇的基础上把“上门维修预约”这个流程进一步按照实际业务需求加入用户在整个问答过程中加入AI用行为判断来根据用户当的输入是:【确认】还是【取消】判断下一步流程到底如何“流向”的实际真实案例怎么走,甚至我们加入了即不是“确认”也不是“取消”的第三种状态的AI判断(取自本人为某巨型物业公司制作的AI自动派工单系统)。

从现实需求出发来设计

用户的现实需求

用户在派工单场景中的第一步:提述求

当一个客户在向AI述求“我家的煤气气有股子臭鸡蛋味”时,此时意为煤气有泄漏。此时作为客服人员需要把用户的问题记录下来。

同时,它要查看这个用户的信息是否完整,如果已经完整了就不用用户再回答一遍个人信息了,如果不完整那么需要让用户提供完整信息中缺失的那一块就可以了。

用户在派工单场景中的第二步:

<think>嗯,用户现在在找Dify项目的Mermaid流程图案例。我需要先确认Dify的官方文档里有没有相关的例子。用户之前提到了Dify的Helm Chart教程和迁移到Rill-Flow的情况,可能他们现在想用Mermaid来画工作流或者部署流程。 首先,我应该检查Dify的官方文档,比如他们的GitHub仓库或者用户手册。根据引用[2],Dify的Helm Chart项目地址是gitcode上的一个镜像,可能里面会有部署流程的说明,但不一定有Mermaid图。另外,引用[1]提到他们从Dify迁移到Rill-Flow,但保留了界面兼容,所以可能用户需要的是工作流引擎的流程图示例。 如果官方文档里没有现成的Mermaid案例,可能需要根据Dify工作流程自行创建。比如,用户构建应用的过程可能包括创建应用、配置LLM、设置知识库、部署这几个步骤。或者部署架构可能涉及前端、后端、数据库等组件。 另外,用户可能是在寻找如何将Dify工作流用Mermaid表示,比如数据处理流程AI模型调用流程。这时候需要参考Dify工作流设计,结合Mermaid的语法来构建示例。 还要考虑到用户可能不太熟悉Mermaid,所以提供的示例应该简单明了,语法正确,方便他们修改使用。同时,建议他们查阅Dify的官方文档和社区资源,可能会有更多案例。</think>目前Dify项目的公开文档中未直接提供Mermaid流程图案例,但根据其架构和工作流设计特点,可构建以下两种典型场景的流程图示例: ### 示例1:Dify应用构建流程(Mermaid语法) ```mermaid graph TD A[创建新应用] --> B[配置LLM提供商] B --> C{选择模型类型} C -->|对话型| D[设置对话开场白] C -->|文本生成型| E[配置prompt模板] D --> F[添加知识库] E --> F F --> G[测试预览] G --> H[发布应用] ``` ### 示例2:Dify部署架构图(基于Helm Chart)[^2] ```mermaid flowchart LR subgraph Kubernetes集群 A[Ingress] --> B[Dify-Web] A --> C[Dify-API] B --> D[PostgreSQL] C --> D C --> E[Redis] C --> F[MinIO] end G[外部LLM服务] --> C ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

TGITCIC

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值