基于多模态多 AI 模型的 有限状态机框架

（ Multi-modal Multi-model FST

Framework）

前言

随着目前大模型的进化，在各个领域，各个模态都有着各个模型在涌现，同时超级大语言
模型，如 ChatGPT 等在各领域文本生成领域产生了惊人的生产力。然而当前缺乏对多个 AI
模型进行整合、串联以松耦合的方式调用的框架。仅仅有个别框架以串行链的方式进行调
用，在系统开发的复杂度、可维护性、可扩展性上都有极大的缺陷。

本文主要讲述了一种异步、松耦合、高灵活度、高效开发维护的框架，通过 FST 将各种 AI

模型和业务控制模块组合起来，可在高效利用 AI 模型和快速进行严肃业务流程扩展上做到
了很好的平衡。
总体设计

总体架构图如下所示：
该架构由以下几个部分组成：
1. Client，即服务调用方，通过 Gateway 像服务发送请求，和接收响应。
2. Gateway，提供对外服务的接口，接收外部请求，发布到系统内部请求队列。Gateway
和 Client 通信协议是匹配的。最简单的就是 HTTP 轮询，支持多种灵活协议。对于
3. Request Dispatcher，请求调度器。从请求队列里面拿到消息，根据 FST Configuration 的
配置，决定将消息继续转发到下一个消息队列中。 Request Dispatcher 可以是静态的，
也可以通过扩展，以条件概率的形式进行跳转。（后面有其他文档进行说明）
4. FST Configuration，保存每一个业务的消息流转配置。可以是确定性的流程，也可以是
概率跳转。修改一个业务的 FST 跳转配置，会直接改变请求在各个服务中流转的流程。
5. Cache，用于保存每个请求当前的上下文信息。通过 requestID 来存取，用于在服务流
程中各个环节进行数据传递。这里我们选择 Redis 作为缓存。
6. Service，每个 Service 仅负责单一业务。Service 实例启动的时候，订阅该 Service 生命
的的 Topic，从该 Topic 获得请求之后，从 Cache 里面拿到该请求当前上下文数据，业
务完成之后，将请求完成消息发布到 Request Topic 里面，由 Request Dispatcher 继续调
度。Service 对所用的编程语言不敏感，业务方可以根据自己的需求选择开发语言，只
 要可以与消息队列和缓存交互即可。
7. 消息队列用于保存消息，只需要支持多订阅即可。这里我们用 RabbitMQ 作为消息队列。

消息体结构设计

消息体结构决定了框架具备的功能和框架的能力。消息体结构分为两个部分：
1. Cache 中的结构
Cache 用于在会话过程中，做数据传递。也可被 Dispatcher 获取，用于决定转发策略的
输入参数。

Cache State 维护了在多轮会话的数据。List 是按顺序保存的会话数据。单条数据可以是

文本、图像、语音任意一种模态。对于 Cache 来说，只需要有 Set/Get 方法即可。同时
缓 存 数 据 通 过 LRU 自 动 清 理 。 使 用 Cache 的 用 户 包 括 ： Gateway ， Request
Dispatcher，Service。
Request Status 则是可以让客户端可以查询当前 Request 处于哪个处理环节，或者是否已
经处理完成。
2. Queue 中的结构
整个系统中，Queue 分为三个类型：
2.1 Request Queue ， 由 Request Dispatcher 消 费 ， Request Dispatcher 负 责 根 据 Cache
State 内容分发 Request 到 Service Queue，或者 Response Queue。
2.2 Service Queue，一个类型的 Service 服务实例，订阅一个主题。Service 服务实例需
要从 Cache State 中获取需要的数据，进行服务，保存服务结果（如果有的话）到
Cache 里 面 ， 即 更 新 该 Request_ID 的 Contexts 内 容 。 服 务 完 成 之 后 ， 再 发 布
Request Id 回 Request Queue，由 Request Dispatcher 调度。
2.3 Response Queue，由 Gateway 消费，Request Dispatcher 根据当前状态决定是否发布
到 Response Queue。Gateway 负责维护和 Client 之间的连接。负责将响应分发给请
求的 Client。
综上，无论在哪个 Queue 里面，数据结构都只有一种，即该 Request_ID
系统流程序列图

下面分以下几个部分，详细讲述请求流转的流程。
1， Client-Gateway 交互

0. Client 连接上 Gateway，发送请求给 Gateway。

1. Gateway 先为该请求生成唯一的 RequestID。
2. 将请求数据，发送到 Cache 中保存。
3. 发布 Request ID 到 Request Queue。
4. 返回 Request ID 给 Client，Client 凭借该 ID 获取 Response。

关于 Client 如何异步获取 Response，有两种做法：

1. Client 和 Gateway 之间是无状态的连接，拿到 RequestID 之后，Client 通过定期轮询
Gateway 来查询是否完成请求，如未完成，则返回该请求所处的状态。
2. Client 和 Gateway 之间维护长连接，Gateway 订阅 Response Queu，拿到请求之后，主动
推送给 Client。
通常内网服务环境，采用第二种方式更高效。而如果给更多外部用户提供服务，则第一种
方式容错性更强。
Client 和 Gateway 交 互 还 有 一 种 情 况 ， 就 是 同 一 个 Request ID ， Client 新 增 会 话 数 据 ，
Gateway 负 责 更 新 Cache Data ， 同 时 发 布 RequestID 到 Request Queue 里 面 ， 由 Request
Dispatcher 继续进行调度。

2， Request Dispatcher 消息调度

0. Request Dispatcher 从 Request Queue 里面拿到一个 Request ID。

1. 从 Cache 里面获得当前 Context Data。
2. 根据 Context Data 计算出该请求的下一个业务 Service Queue。
a) 如果下一个 Queue 是 Service Queue，则选择发布 Request ID 到该业务 Service
Queue。
b) 如果计算该次会话结束，则发布 Request ID 到 Response Queue。
3. 继续获取下一个要调度的 Request ID
Request Dispatcher 是业务流控制的核心模块。实现算法可以是普通的，通过配置文件配置
来调度工作流。也可以根据 Context 上下文内容用模型计算选择。这是一个可配置的算法
模块。
3， Service 实例消费
 0. Service 实例从 Service Queue 中取出一个 Request ID。
1. 从 Cache 中获取 Context Data。
2. 基于当前 Context Data，执行业务操作。
3. 更新 Context Data。
4. 发布 Request ID 到 Request Queue。由 Request Dispatcher 进行下一轮调度。
5. 继续获取下一个 Request ID。
4， Gateway 消费 Response Queue

0. Gateway 从 Response Queue 获取一个完成的 Request ID

1. 更新在 Cache 中的 Context Data，标志该请求已经完成。
2. 如果是有状态连接，则主动通知客户端。如果是无状态连接，则可以等客户端来
查询的时候，将结果返回给 Client。