跳至主要內容

Dify对话机制解析

pptg大约 2 分钟

写AI真好玩，能自己决定技术栈真好。可以接触到很多非CRUD的东西。

Dify版本：1.4.3

1. 前言

Dify作为一个快速验证思路的工具，还是非常不错的。但是也正因为可视化的拖拽，导致灵活性大大降低。所以最近一直在用langchain/langgraph自研AI平台。

在Dify这里还是吸收了不少经验，最开始Chat这块我是打算一路yield到底的，后面流程复杂了之后，发现各种消息乱飘，调试起来非常复杂。于是参考了Dify的架构进行了重构。

2. Dify接口解析

2.1 message-chat

Dify的一次MessageChat，从请求开始到流式响应结束，经过了以下主要节点：

  1. Api:api层会把请求的参数解析好，并调用AppGenerateService.generate方法来获取一个Generator
  2. AppGenerateService.generate:进行账单、流量控制，并根据app模式（workflow、agent、chat等等）的不同，最终调用不同AppGenerator.generate
  3. AppGenerator: 获取模型配置文件，生成会话ID、任务ID并初始化3个主要的实例PipeLine、QueueManager、AppRunner
    • PipeLine: 主线程运行，持有QueueManager，负责监听消息并生成返回结果
    • AppRunner: 子线程运行，持有同一个QueueManager，负责执行最终的AI流程(Memory、History、RAG、Token等)，并将相关信息publish到QueueManager中
    • QueueManager: 消息队列

2.2 stop

有了上面的机制，stop理解的就比较简单了 在chat的流式返回中，会将AppGenerator产生的TaskID传递到接口中

前端通过传递该ID，可以将任务进行中断：

  1. QueueManager: 调用stop接口，对该TaskID对应的Redis打上stop标识
  2. PipeLine: 监听到该stop标识，调用一系列方法进行记录、停止