[RFC] 064 - Dify Integration | Dify 接入

[cy948]

背景

Dify is an open-source LLM app development platform. Its intuitive interface combines AI workflow, RAG pipeline, agent capabilities, model management, observability features and more.

Dify 提供了一套完全服务化的API接入，使得纯前端接入方案成为可能。本地只需持久化“身份信息、API鉴权信息、聊天”信息，其余均可从Dify API Endpoint获取。

挑战

以下从这几方面记录 Dify 接入的挑战

• Dify 的身份信息管理
• Dify 的聊天信息管理
• Dify Model Provider

Dify 的身份管理

Dify 在进行每个请求时都需要身份信息。目前的临时实现把信息存在了原来的 Agent 设置中。目前身份信息包括：

• baseUrl: Dify 服务 baseUrl，应该支持用户配置多个不同 baseUrl 的服务
• token: 用户访问服务的 token。token仅用于访问，和用户不耦合。
• user: 用户id，由客户端自定。

Dify 的聊天信息管理

1. Topic (对应 Dify 中的 conversation)

• Dify 依靠 conversation id 去标识每一次会话，若不传则创建新会话，创建时不能指定 conversation id。
• Lobe 在新建 topic 时会自动分配本地 id，该 id 需要在第一次回复后被后端回传的改为dify分配的 conversation id。

2. ChatMessage (对应 Dify 中的 event.message )
   前端需要对后端返回的 Dify 信息流进行处理，包括

• message 切分，dify 默认把一次 query 和 answer 合并为一个 message SSE stream chunk 。
• event 展示，目前 event 有：node, workflow, files。

Dify Model Provider

1. 前后端传参问题
   问题源于Dify官方Saas的POST跨域。前端需给后端传递的参数有 userid, topicId?, baseurl, token

2. 流处理问题
   Dify 需要对SSE流进行处理，而 Dify 的流不兼容 OpenAI 格式，需要单独处理。

• Dify 返回的message流在message end时会传输一个含所有 message 的chunk，含多个 data: 前缀的 chunk，同时这个chunk不能被随意丢弃，因为它含有最有一个 character 。
• Dify 返回的事件有支持未被支持的类型：
  • Tool using: Agent 正在使用外部工具
  • Thoughts: Agent 正在使用节点中的 CoT 生成判断
  • Workflow: Agent invoke 了一个 worlflow 事件

2024/10/27 Dify 的流又出问题了，ReadableStream无法对其进行切分，可能是因为单步 event stream 达到了最大长度而被截断。以下是处理错误时对单个 buffer 的打印：

", "data": {  ...省略... l}}  // mark1
data: {"event": ...省略... "crea   // mark2

• mark1: 此处的 data 已经是一个完整的 event 了，按道理这个 stream 应该被终止；
• mark2: 此处又有一个 event 跟随， 并且因为在一个 event stream 中塞入了两个 data，导致整个 event 超出了长度从而被截断