在深入探讨事件驱动架构跟 AI 结合前，我们先梳理一下 AI 应用的现状。

从应用架构层面，大致可以把 AI 应用分为以下三类：

1）基于基础模型的扩展应用，典型的如 ChatGpt（文本生成）、StableDiffusion（图像生成）、CosyVoice（声音生成）等，这类应用通常会以模型能力为核心，提供相对原子化的服务。

2）智能知识库应用，如 Langchain chatchat，这类应用是以 LLM 为核心，基于 RAG（增强检索技术）构建的具有广泛的业务场景的应用。

说到“原生”二字，它代表的是对某种概念的广泛认知，比如提移动原生应用立马可以联想到手机端的 APP，提云原生应用很多开发者立马可以想到容器化等，而对于 AI “原生”，除了 ChatGpt，Midjourney 等几款头部 AI 应用，我们似乎还没有看到像移动应用那样广泛的“原生”应用被定义出来，当然今天也没有办法给出明确的结论，只是通过一些事实，帮大家推演 AI “原生”的方向，希望能够帮助慢慢凝聚在内心中那个对“AI 原生”的影像。

当 AI 能力加入后，我们的应用架构发生了较大的变化。RAG，Agent 等编程范式被引入，传统的工作流也因为有了 AI 节点，变得与以往有所不同。

AI 应用架构-RAG

AI 应用架构-Agent

加入 AI 节点的工作流

从观察知名 AI 厂商的产品形态演进看，AI 应用由前面提到的基础模型扩展、智能知识库、智能体三类叠加又相对分离，在慢慢向由智能体统一管控约束的方向发展。

比如 Open AI 的 Canvas，Claude Artifacts，Vercel v0 等产品特性。它们都表现出了一系列的共性：智能内核，多模态，LUI 交互。

这里并不是单纯为了追求技术的先进性而使用事件驱动架构，是因为实践中顺序式的架构有时候无法满足业务需求。

顺序调用无法保障推理体验

模型服务的推理耗时远高于传统意义的网络服务调用，比如在文生图这个场景下使用 StableDiffusion 服务，即使经过算法优化后最快也是秒级，并发量较大的时候，会很容易导致服务器宕机。此外如声音的合成，数字人的合成等耗时可能是分钟级的，此时顺序调用明显就不太合适。选择事件驱动的架构可以快速响应用户，推理服务按需执行，这样既能够保障用户体验，同时也降低系统宕机风险。

顺序调用无法支持实时数据构建的需求

在智能问答系统中，结果的好坏跟数据有很大的关系。问答召回数据的实时性和准确性很大程度影响着智能问答系统的用户体验，从系统架构层面，问答和数据的更新是分开的。靠人工去更新海量数据不现实，通过设置定时任务以及构建知识库数据更新的工作流能够更加有效的解决数据实时更新的问题，事件驱动架构在这个场景下优势非常明显。

双向互动场景无法实现

在问答服务场景下，拟人化的行为能够得到用户好感从而扩展商机，传统的问答式应用架构相对机械死板，而使用消息队列作为信息传输可以有效主动触达用户，通过合理的意图判断，主动向用户问好，是有效的留存手段。

接下来分享一下基于事件驱动架构构建的 AI 应用的一些实践。

这是一个相对复杂的应用，使用者可以通过语音跟背后的智能问答服务实时对话，同时还能够接收到来自智能服务的主动询问。