实时会议转文字场景中dify的局限；
对于实时会议转文字（Real-time Transcription）且涉及多模型并行处理的场景，Dify 原生架构确实不够用，甚至可以说它不是为此类高并发流式任务设计的。
通信协议问题
-
Dify 的逻辑（HTTP/SSE）
客户端发一个大包，Dify 处理完分批吐出来。
每秒钟有几十个数据切片（Chunks）像流水一样涌入，需要一个永远开启的管道。
Dify 的架构设计里没有“持续接收并实时处理二进制流”的接口。 -
持续接收并实时处理二进制流需求（WebSocket/UDP）
Dify 的工作流（Workflow）本质上是顺序执行或简单的条件分支。
它无法实现“一边收数据，一边让多个模型同时处理同一秒钟的数据，并将结果实时合并推回”。
这种高并发的内存级数据共享，Dify 做不到。
模型并行处理
Dify 的工作流（Workflow）本质上是顺序执行或简单的条件分支。
它无法实现“一边收数据，一边让四个模型同时处理同一秒钟的数据，并将结果实时合并推回”。
这种高并发的内存级数据共享，Dify 做不到。
缺乏“中间状态”的记忆
专业的流式引擎会根据上下文撤回之前的错误转写，然后推送最终修正结果。
Dify 是“原子化”的。每调一次接口，它都倾向于看作一次独立的输入输出。
延迟（Latency）
Dify 作为一个中间平台，它本身有一层很厚的 API 封装和逻辑校验，这些操作会产生高延迟：
Dify 鉴权 -> 2. 解析 DSL 工作流 -> 3. 调度模型 API -> 4. 处理结果并返回。
ai平台的任务配置config设计模式：工厂模式；
单个任务涉及到的模型越多，所需的任务配置类就阅读，创建复杂任务配置类时就越复杂
虽然现在的任务配置还没有很复杂，少数字段就能搞定，所以暂时没有用工厂模式来装配配置类
为了防止过度设计，工厂模式在任务配置中需要在以下几种场景中才有意义：
- 从环境变量读配置
- 根据场景切换模型
- 做统一配置入口
- 做合并配置
目前主要涉及到的是合并配置，因为1不同的模型都有各自不同的配置，在我这系统中核心的就是多个模型的配置合并
这还有个重要的架构思想就是：
任务配置负责语义输入，模型配置只管模型参数。
- 任务配置描述“我要干什么”
- 模型配置描述“用什么参数去做”