Dify-8:对话系统

Dify Chatflow 多轮对话实现原理 AI开发,低代码平台,Dify,对话系统,Workflow引擎。 阅读详情

Dify 中的对话系统负责管理用户与人工智能应用之间的对话(聊天会话)以及所交换的消息。**它处理对话状态、历史记录跟踪、消息存储,以及用户反馈和注释等相关功能。**该系统是一个核心组件,与用于人工智能模型交互的模型提供方系统以及用于知识检索的 RAG 知识系统协同工作。

概述

对话系统管理用户与人工智能应用之间的交互,并对这些交互进行持续记录。它支持不同的应用类型(聊天、文本生成、基于智能体的交互和工作流驱动的交互),并为终端用户和管理员提供了与对话历史记录进行交互的机制。

核心数据模型

对话系统围绕两个主要数据模型构建:对话(Conversation)和消息(Message)。

对话模型

对话模型表示用户与人工智能应用之间的完整聊天会话。

关键属性包括:

属性描述
id对话的唯一标识符
app_id关联的应用程序 ID
app_model_config_id人工智能模型的配置 ID
mode应用模式(聊天、文本生成、智能体聊天等)
name对话的显示名称
summary对话的简要摘要
inputs对话的输入变量
status当前对话状态
from_source对话的来源(API、控制台等)
from_end_user_id终端用户的 ID(如果适用)
from_account_id账户用户的 ID(如果适用)
dialogue_count对话交流的次数
created_at创建时间戳
updated_at最后更新时间戳
is_deleted软删除标志

对话模型与以下内容存在关系:

  • 消息(一对多)
  • 消息注释(一对多)
  • 应用(多对一)
消息模型

消息模型表示对话中的单个交流内容。

关键属性包括:

属性描述
id消息的唯一标识符
app_id关联的应用程序 ID
conversation_id所属对话的 ID
inputs此消息的输入变量
query用户查询 / 提示
message原始消息内容(通常为 JSON 格式)
answer人工智能的回复文本
message_tokens输入的令牌数量
answer_tokens输出的令牌数量
provider_response_latency模型提供方的响应时间
status消息状态
from_source消息的来源
from_end_user_id终端用户的 ID(如果适用)
from_account_id账户用户的 ID(如果适用)
parent_message_id对于线程消息,为父消息的 ID
created_at创建时间戳
workflow_run_id关联的工作流运行 ID(如果适用)
agent_based基于智能体交互的标志
数据库模式

此图展示了对话系统中核心数据模型之间的关系:

对话生命周期

创建

当用户与人工智能应用发起交互时,会创建对话。创建过程因应用模式而异:

  • 聊天模式:在聊天会话开始时创建
  • 文本生成模式:为每个文本生成请求创建
  • 智能体聊天模式:为基于智能体的交互创建
  • 工作流模式:创建并关联到一个工作流运行
交互流程

服务层

对话系统通过多个服务类进行管理:

对话服务(ConversationService)

处理管理对话的核心功能:

  • 检索对话的分页功能
  • 对话删除(软删除)
  • 对话重命名(包括自动生成)
  • 单个对话的检索

ConversationService 中的关键方法:

pagination_by_last_id(session, app_model, user, last_id, limit, invoke_from, sort_by)
rename(app_model, conversation_id, user, name, auto_generate)
delete(app_model, conversation_id, user)
get_conversation(app_model, conversation_id, user)
Web 对话服务(WebConversationService)

在对话服务的基础上扩展了 Web 特定的功能:

  • 固定 / 取消固定对话
  • 按固定状态过滤对话

WebConversationService 中的关键方法:

pagination_by_last_id(session, app_model, user, last_id, limit, invoke_from, pinned, sort_by)
pin(app_model, conversation_id, user)
unpin(app_model, conversation_id, user)

API 端点

对话系统通过多个 API 端点提供不同的用例:

控制台 API

用于管理访问,包括查看和管理所有对话:

端点方法描述
/apps/<app_id>/chat-conversationsGET列出聊天对话
/apps/<app_id>/chat-conversations/<conversation_id>GET获取聊天对话详情
/apps/<app_id>/chat-conversations/<conversation_id>DELETE删除一个聊天对话
/apps/<app_id>/completion-conversationsGET列出文本生成对话
/apps/<app_id>/completion-conversations/<conversation_id>GET获取文本生成对话详情
/apps/<app_id>/completion-conversations/<conversation_id>DELETE删除一个文本生成对话
服务 API

用于以编程方式访问对话:

端点方法描述
/conversationsGET列出用户的对话
/conversations/<conversation_id>DELETE删除一个对话
/conversations/<conversation_id>/namePOST重命名一个对话
Web API

用于 Web 应用程序访问:

端点方法描述
/conversationsGET列出用户的对话
/conversations/<conversation_id>DELETE删除一个对话
/conversations/<conversation_id>/namePOST重命名一个对话
/conversations/<conversation_id>/pinPATCH固定一个对话
/conversations/<conversation_id>/unpinPATCH取消固定一个对话

特殊功能

对话固定

用户可以固定重要对话以便更轻松地访问。这通过固定对话模型(PinnedConversation model)和 Web 对话服务方法实现:

  • 固定对话:WebConversationService.pin (app_model, conversation_id, user)
  • 取消固定对话:WebConversationService.unpin (app_model, conversation_id, user)
消息反馈和注释

用户和管理员可以对消息提供反馈并添加注释(修正或改进内容):

  • 反馈:点赞 / 点踩评分,并可添加评论
  • 注释:由管理员提供的修正或附加信息

文件附件

消息可以包含文件附件,支持多种文件类型:

  • 用于视觉模型的图像
  • 用于提供上下文的文档
  • 根据配置支持的其他文件类型

文件上传功能通过文件上传配置管理器(FileUploadConfigManager)进行配置,该管理器控制允许上传的文件类型以及上传方式。

与工作流系统集成

对话系统通过消息模型中的 workflow_run_id 字段与工作流系统集成。这使得可以跟踪哪些消息与特定的工作流运行相关联。

Web 界面

Web 界面提供了一种用户友好的方式来查看和与对话进行交互。它包括以下功能:

  • 带有固定功能的对话列表
  • 带有反馈选项的消息显示
  • 文件附件预览
  • 工作流运行状态可视化

该界面使用 React 组件来显示对话和消息,并支持用于分页的无限滚动。

使用模式

聊天应用

对于聊天应用,对话系统会维护包含多条消息的持续聊天历史记录。

文本生成应用

对于文本生成应用,每次交互通常会创建一个包含单个消息的新对话。

【Dify精讲】第10章:会话管理与上下文保持 Dify的会话管理架构采用分层设计,核心数据模型支持多源用户区分和配置快照机制,确保会话一致性。会话服务层提供智能分页查询、高级过滤等功能,通过状态追踪和游标分页优化用户体验。系统采用Token优化策略和上下文压缩技术,平衡性能与成本,实现高效的长期会话管理。 阅读详情

相关推荐

Dify与n8n对比:AI开发与自动化工具选型指南

在AI应用开发和自动化工具领域,低代码平台和自动化工作流引擎正成为技术热点。Dify作为AI优先的低代码平台,通过可视化编排和模型抽象层,大幅降低了AI应用开发门槛,特别适合快速验证AI创意和构建知识库增强型应用。n8n则以节点化设计和分布式执行为核心,成为跨系统数据同步和复杂业务流程自动化的首选工具。从技术原理看,Dify优化了AI工作流的全生命周期管理,而n8n专注于构建可靠的自动化管道。在实际应用中,智能客服系统等AI驱动场景适合采用Dify,而CRM到ERP的数据同步等任务则更适合n8n。数据显示,

weixin_30247307的博客 380

关于Dify聊天对话名称无法自动生成的原因和解决方法

摘要:本文分析了Dify平台对话名称生成问题的原因与解决方法。主要问题包括默认生成"newconversation"名称、中英文不匹配等,其根源在于系统模型配置不当。解决方案包括:(1)改用非推理模型;(2)修改源码正则逻辑。作者建议使用8B以上模型,并发现直接采用首个问题作为名称更实用。通过调整提示词和修改生成函数,最终实现了自定义对话名称功能。

Orange_sparkle的博客 1326

AI:Coze、Dify、n8n:三款低代码工具如何选?

Coze、Dify、n8n:三款低代码工具如何选?

Kant2048的博客 2806

3个高效步骤:Dify工作流Web交互界面从入门到企业级部署

在当今快速发展的AI应用领域,构建专业的用户交互界面是提升用户体验的关键。作为低代码开发的重要实践,Dify工作流提供了强大的表单交互和用户认证流程支持,让开发者无需深入前端技术即可实现企业级界面。本文将通过"问题-方案-实践"三段式框架,带你掌握从表单设计到登录验证的完整实现路径,解决实际开发中遇到的交互设计难题。 ## 问题诊断:Web交互界面开发的常见痛点 你是否遇到过这些问题:设计的表

gitblog_00110的博客 644

智能体应用开发平台终极选型指南dify、refly、bisheng、n8n等

Dify低代码AI应用开发平台,支持快速构建基于大模型的智能体(Agents)和工作流,提供可视化编排界面和API管理功能,适合企业级AI应用开发。n8n开源工作流自动化平台,通过节点式编排连接各类服务(含AI模型),侧重通用业务流程自动化,支持500+应用集成。Refly专注对话式AI的智能体开发平台,提供预置行业模板和强化学习优化能力,擅长构建客服、营销等对话场景应用。Bisheng开源LLM应用开发框架,提供从模型微调到应用部署的全流程工具链,适合需要深度定制AI能力的开发者。

随笔记录-分享&记忆 3209

Dify、Coze、n8n 对比分析与选型建议

Dify在AI深度开发与灵活性上占优,适合技术驱动的企业;Coze以易用性和生态整合见长,适合快速原型和C端应用;n8n则填补了非AI自动化领域的空白,适合通用业务流程优化。建议根据具体需求优先级(如技术能力、预算、生态依赖)综合评估。例如,若需同时兼顾AI与自动化,可组合使用Dify(AI核心)+n8n(流程集成)。

2401_83450572的博客 5492

0代码,5分钟,搭建出企业级文档处理MCP Agent

文档质量决定了大模型理解的上限。当你正在构建知识库或者搭建文档审核相关的Agent,可以考虑将TextIn MCP Server嵌入到你的搭建工作流中,成为你的文档处理引擎。

z551646的博客 1387

VOLTE信令流程-IMS注册篇(五)

目录 VOLTE信令流程-IMS 注册 VOLTE信令流程-IMS 注册/注销 VOLTE信令流程-VoLTE呼叫流程 VoLTE-VoLTE VoLTE-CS CS-VoLTE CS-CS VOLTE信令流程 VOLTE信令流程-VOLTE-VOLTE信令 VOLTE信令流程-INVITE详细信息 VOLTE信令流程-eSRVCC信令流程 VOLTE信令流程-IP短信 VOLTE信令流程-IMS 注册 IMS注册流程简述  获取鉴权向量 IMS用户将注...

gender123的博客 2万+

Qwen3-8B私有化部署全攻略:搭配Dify,实现数据不出内网的AI对话系统

本文介绍了如何在星图GPU平台上自动化部署Qwen3-8B镜像,快速搭建私有化AI对话系统。该方案结合Dify平台,可实现数据不出内网的企业级智能问答应用,例如构建员工政策问答机器人,安全高效地处理内部知识查询。

weixin_34511754的博客 117

Labview调用C++ dll之字符串数组传递

做项目的时候碰到了一个需求,有一个复杂的运算,用labview实现非常的麻烦,但是如果用C++实现,就会灵活很多。尝试着采用Labview调用C++编写的动态链接库方式解决,兼顾Labview的便利和C++的灵活性。 运算好说,主要难点是Labview与C++之间的数据对应关系,因为我最后的结果是既有字符串又有数字,对于单纯的数字来说,直接通过调用数组的方式就能解决,这里主要记录一下字符串数组...

bgbgx的博客 6809

手把手教你用OpenCompass评估Qwen1.5-1.8B模型(含数据集配置详解)

本文提供了使用OpenCompass评估Qwen1.5-1.8B-Chat模型的详细实战教程。内容涵盖从创建独立Python环境、下载模型与核心数据集,到编写配置文件、执行评测命令及解读结果的完整流程。重点解析了模型与数据集的配置细节,并分享了性能调优与常见问题排查方法,旨在帮助开发者快速上手系统化的模型评估。

weixin_29228781的博客 138

Qwen3-0.6B-FP8极速对话工具:Dify平台集成与自动化部署

本文介绍了如何在星图GPU平台自动化部署⚡ Qwen3-0.6B-FP8极速对话工具镜像,并集成至Dify可视化开发平台。该方案能快速搭建高性能对话应用,适用于智能客服、内容生成等场景,显著降低部署复杂度并提升开发效率。

weixin_32535825的博客 88

嵌入式学习笔记——EEPROM(M24M01)

M24M01是ST公司出品的1Mbit(128Kbyte)I2C兼容EEPROM,兼容所有I2C总线模式(1MHz、400kHz、100kHz),Page大小为256字节,支持硬件写保护,超过400万次写入操作,超过200年的数据留存通过模块化设计,涵盖了 M24M01-RMN6P 的功能介绍、引脚架构、硬件连线、模块化代码以及性能优化思路,我们将 M24M01 EEPROM 与 STM32 的集成变得高效而可靠。希望能帮你在 STM32 上快速上手,并让你的项目存储管理更高效可靠。

2301_80488241的博客 1657

基于Dify的智能体客服助手搭建实战:从零构建高效对话系统

踩坑两周,我们把双十一高峰的 8 分钟响应压到 50 秒以内,客服人数降 40%,机器人解决率 83%,成本直接腰斩。去年双十一前,公司客服组被一波“我的优惠券去哪了”冲垮:平均响应时间 8 分钟,排队 200+,人工坐席从 30 稀里哗啦加到 80,成本直接飙到 6 位数。建议读者把对话日志与业务日志(下单、支付、物流)join 后做决策树可视化,找出“机器人→人工”高 dropout 节点,持续剪枝,比纯调阈值收益更高。再往下调 0.05,转人工率掉到 5%,但误答率升到 7%,需权衡。

2600_94959948的博客 443

从防御者视角复盘:用WinArpAttacker和Wireshark在Windows上模拟并检测ARP欺骗攻击

本文详细解析了Windows平台下的ARP欺骗攻击与防御策略,通过WinArpAttacker和Wireshark工具模拟攻击并检测异常流量。文章涵盖实验环境搭建、攻击原理深度解析、流量特征分析及企业级防御方案,帮助安全运维人员全面掌握ARP攻击检测与防护技术。

weixin_30918633的博客 121

JS逆向-B站评论数据w_rid参数和wts参数

本文是该专栏的第69篇,后面会持续分享python爬虫干货知识。本文以B站的评论数据为例,通过JS逆向获取其中的w_rid参数以及wts参数生成规律。具体的“逆向”思路逻辑,笔者将会详细介绍每个步骤,并且将在正文结合“完整代码”来详细介绍。废话不多说,具体细节部分以及详细思路逻辑,笔者将在正文结合完整代码进行详细说明。(附带完整代码)

Python进阶专栏《爬虫实战进阶》,《Pyppeteer从入门到精通》原创作者 2049

一站式AI应用开发:在PyTorch 2.8环境中集成Dify打造智能助手

本文介绍了如何在星图GPU平台上自动化部署PyTorch 2.8 深度学习镜像 | RTX4090D 24G CUDA12.4 通用优化版,并集成Dify平台快速构建AI应用。该方案特别适用于开发智能客服系统,通过可视化界面配置对话流程和知识库,显著提升响应效率并降低人工成本,助力企业快速实现AI技术落地。

weixin_33531560的博客 81

【数字IC设计】芯片设计中的RDC

在芯片设计中,RDC是的缩写,类似于CDC(clock domain crossing),由于现在SOC芯片是有很多ECUs组成,为了使整个系统能够快速从复位中恢复, 用户希望SOC里面每个ECU模块都可以有自己独立的异步复位信号,这样可以在出问题的时候只复位有错误逻辑的模块,而使其它模块保持正常工作。

qq_40268672的博客 2186

基于dify平台搭建智能客服对话系统的架构设计与实战避坑指南

dify 不是银弹,但它把“标注 → 训练 → 上线”压缩成“拖文件 → 点发布”,让算法、运营、后端终于能用同一套界面说话。只要守住中文分词、会话超时、循环保护这三个坑,再按 4-worker 规格部署,智能客服就能在两周内灰度上线,QPS 轻松翻 3 倍。下一步,不妨把 LLM 质检、多模态图文问答也接进来,让客服机器人从“能回答”走向“答得好”。

2600_94960102的博客 337

Arch Linux 命令大全,值得收藏!

Arch Linux 是一款轻量级、高度可定制的 Linux 发行版,以其简洁和强大的特性深受高级用户喜爱。但对于新手来说,完全掌握 Arch Linux 的操作需要时间和实践。本文将为您详细介绍常用的 Arch Linux 命令,涵盖系统管理、文件操作、用户管理、软件安装与管理、网络配置和磁盘管理等内容,帮助您更高效地使用 Arch Linux。

网络技术联盟站 974

锂电池充电器电路设计 里面有电路

锂电池充电器电路设计 里面有电路 3.7V升压到5V电路设计。

Dify平台任务型对话系统搭建教程

通过Dify平台的可视化编排、提示词管理、RAG集成与Agent架构,快速构建能执行退货、查询等实际任务的智能客服系统,降低开发门槛并提升业务自动化能力。

weixin_35390379的博客 660

VB摄像头监控

该VB模块可对摄像头捕获的画面进行录像等,可在创建的窗口进行控制

RexUniNLU对话系统:基于Dify的多轮对话引擎

本文介绍了如何在星图GPU平台上自动化部署中文NLP综合分析系统(RexUniNLU零样本通用自然语言理解)镜像,构建智能多轮对话引擎。该镜像具备强大的零样本理解和上下文处理能力,可应用于银行客服场景,自动识别用户意图并处理账户查询、信用卡服务等复杂对话任务,显著提升服务效率与用户体验。

weixin_35756373的博客 464

复分析 阿尔福斯(Ahlfors) 第三版答案 英文

答案分为十章,有部分习题没有答案,全英文复分析阿尔福斯(Ahlfors) 第三版答案

IMSL CNL 7.0.0 (x86-64)Crack

IMSL CNL 7.0.0 (x86-64)Crack intel的算法库破解文件,这是C++版本的破解文件

5步构建智能客服对话系统:Dify工作流的可视化编程革命

在智能客服系统开发领域,我们发现技术团队普遍存在三个认知误区,这些误区直接导致开发效率低下和系统性能瓶颈。通过对20个企业级客服项目的调研,我们实验表明,这些问题在传统开发模式下几乎难以避免。 **误区一:"代码越多越灵活"的迷思** 78%的开发团队认为自定义代码能解决所有复杂逻辑,却忽略了维护成本的指数级增长。某电商平台的客服系统在迭代12个版本后,代码量达到15万行,新增一个意图识别功

gitblog_00542的博客 1095

n8n、Dify、Coze 详细对比

n8n、Dify、Coze 详细对比

爱的叹息的专栏 4659

n8n 与 Dify 的核心区别对比

n8n 和 Dify 是两款功能定位截然不同的工具,分别专注于流程自动化和AI应用开发。n8n 的核心目标是跨系统数据流转和流程自动化,适合开发者和技术团队,支持复杂数据处理和API串联,适用于跨系统自动化、IT运维和传统业务自动化等场景。Dify 则以大语言模型(LLM)为基础,专注于AI驱动的应用开发,适合业务人员和非技术用户,支持智能问答、内容生成和知识库检索等任务,适用于AI驱动应用开发、知识库智能检索和内容生成等场景。两者在技术实现、适用场景、成本和用户学习门槛上存在显著差异,但可以互补使用,形成

学亮编程手记 5541

dify案例分享-独家揭秘:N8N+Dify 打造新闻定时推送流

热点新闻是指在特定时间段内,受到公众广泛关注和讨论的新闻事件或话题。这些新闻通常具有时效性、影响力和传播性,能够引发社会的广泛关注和讨论。热点新闻不仅反映了当前社会的热点问题,也体现了公众的兴趣和关注点。 在当今信息化浪潮席卷的时代,海量媒体资讯如潮水般每日涌来。然而,受制于有限的时间与精力,人们往往更倾向于聚焦两类信息:一类是与自身兴趣深度契合的个性化新闻,另一类则是当下全网热议的焦点事件。在此背景下,能否快速、精准地捕捉实时热点资讯,成为现代人高效获取信息、把握时代脉搏的关键所在。

Gaga246的博客 1631
上一篇: Dify-7: RAG 知识系统
下一篇: Dify-9:模型提供方系统
uncle_ll
uncle_ll 领域专家: 人工智能技术领域 领域专家: 人工智能技术领域
博客等级 码龄13年 5864粉丝 946原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

uncle_ll

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

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

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

打赏作者

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

抵扣说明:

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

余额充值