做AI应用架构设计最难的不是模型选型也不是调提示词而是把整套东西给团队讲清楚。我上周帮一个团队评审AI客服的架构方案前前后后聊了两个小时大家各说各话最后我把四张图画出来争论立刻少了一半。今天围绕“图解AI应用架构设计”这个主题把我拆架构、画架构图的思路完整梳理一遍覆盖分层框架、参考架构、实操步骤和避坑经验。适合刚接触AI应用架构的同学建立整体认知也适合正在带团队评审技术方案、推进AI项目落地的人参考。1. 先对齐核心概念AI应用架构到底是什么很多人一提到架构设计脑子里浮现的是微服务拆分、网关路由、消息队列那一套。AI应用架构确实脱胎于传统后端架构但多了一个最关键的变量大模型。大模型不是一个普通的接口它有上下文长度限制、输出不稳定、响应时间波动大、成本随Token数变化这些特性直接影响架构图该怎么画。如果不把这点想透画出来的图和真实系统是两张皮。1.1 从一个最小可运行的AI应用讲起一个最简单的AI应用其实只有三个部分前端页面、后端服务、大模型API。用户在前端输入问题后端收到后拼好提示词调用大模型API再把结果返回前端。就这么简单很多企业内部的小工具就是这么跑的。但这个“最小架构”很快就不够用了。用户问第二句话时模型记不住上文用户上传了一份PDF模型没法直接读业务方要求回答必须引用公司知识库不能靠模型自由发挥管理员要看每天调用了多少Token、谁在频繁提问。于是架构图开始一层层变厚出现了向量数据库、会话存储、Model Gateway、Agent编排、可观测平台。图解的价值就是把“为了满足这些需求多出来的每一层是干什么的”讲明白。1.2 一个通用框架三层一横我画AI应用架构图默认按“三层一横”去落笔任何复杂的AI应用基本都能塞进这个框架。交互与接入层Web端、App端、IM渠道、API对外开放负责接收用户输入和展示结果。编排与业务层会话管理、提示词组装、Agent编排、状态流转、业务逻辑、工具调用。模型与数据层大模型网关、各模型API、向量库、知识库、文件存储、历史会话。横切治理可观测性、安全合规、成本控制、灰度发布。画图的时候先画这三层一横再把具体组件填进去。这样做的好处是不管听众是产品经理还是后端工程师都能在图上快速定位自己关心的区域。产品经理看交互层和业务层后端看编排和数据层SRE看横切治理模型团队看模型层。1.3 一张架构图必须回答的五个问题画图之前先自问这张图能不能回答以下五个问题。回答不了说明图还没画完整。用户输入从进入到最终返回完整走了一遍哪些节点大模型调用发生在哪个环节是同步还是异步会话状态和业务数据存在哪里生命周期怎么管理知识库、工具、外部API这些依赖分别由谁提供、如何被调用如果模型超时、限流或返回格式错误系统的降级路径是什么这些问题对应着架构设计里最核心的“数据流、状态、依赖、失败模式”。一张图如果只画出组件框不画数据和调用关系那只能叫拓扑图不算架构图。2. 拆解典型AI应用参考架构为了让概念落地我拆一个典型的企业级AI应用参考架构。这类应用现在很常见对外提供智能问答、文档处理、自动生成报告等能力背后有私有知识库有一定用户并发需要对接审计和权限体系。我把这个架构按层拆开讲。2.1 交互与接入层这一层是用户能直接触达的部分也是架构图里“最上面”的入口。形态上可以是网页聊天窗口、移动端App、企业IM机器人、API接口甚至电话语音入口。不同渠道对应不同协议和鉴权方式所以这一层通常要有一个接入适配层把渠道差异消化掉统一转换成内部请求格式。我在画图时会在这一层标注一个容易被忽略的点流式输出。大模型生成文本是流式的用户希望看到逐字输出体验才好。这意味着接入层和编排层之间不是普通的HTTP请求-响应还要支持SSE或WebSocket长连接。很多从传统后端转过来的人会在这一步踩坑把模型回复当成一次性JSON返回导致前端体验很差。架构图上交互层和下层之间应当画一条标注“流式通道”的实线而不只是一根普通箭头。2.2 编排与状态管理层这一层是AI应用架构的核心地带也是和传统后端差异最大的一层。传统后端的业务逻辑是确定性的比如下单、支付、库存扣减每一步都定义清楚。而AI应用里用户输入不可控模型输出不稳定业务过程往往需要动态决策。这就催生了Agent编排的概念系统要决定先调用哪个工具、要不要查知识库、要不要追问澄清、什么时候把控制权交回给用户。画这一层时我会把组件拆成三块会话管理、工作流编排、上下文组装。会话管理负责多轮对话的会话ID、历史消息存取、用户会话过期策略。上下文组装负责把系统提示词、知识库检索结果、历史消息、工具返回结果组合成一次完整的模型输入。工作流编排就是Agent运行时的核心负责循环执行“推理-调用-观察-再推理”的过程。状态管理尤其要画清楚。AI应用有两种状态一种是会话状态就是用户说了什么、模型答了什么另一种是业务流程状态就是当前Agent跑到哪一步了、还差哪些信息。这两种状态的位置不一样会话状态通常放Redis或数据库业务流程状态可能需要在编排引擎内部管理也可能需要持久化到数据库用于异常恢复。如果图上不标清楚状态放哪团队会经常改代码改出“上下文串号”的诡异问题。2.3 模型与能力层模型与能力层是AI应用区别于其他应用最直观的一层。它不是简单画一个“大模型”框就完事。我一般分四块画模型网关、模型实例、知识增强、工具能力。模型网关是这一层的重要组件。企业不太可能从头训练一个模型而是调用多个模型服务有的来自云服务厂商有的是开源模型私有化部署有的针对不同任务选不同的模型。模型网关统一封装这些调用承担路由、限流、重试、成本统计的功能。画图时把它画成所有模型调用的唯一入口能避免架构图上出现“前端直接调模型API”这种错误结构。知识增强就是RAG相关组件文档解析、切片、向量化、向量检索库、重排序。这一套在图上通常占挺大位置因为知识库往往是企业内部AI应用的核心资产。工具能力则是指模型能够调用的外部动作比如查天气、查订单、写数据库、发邮件这些在架构图上画成“工具服务”标注协议类型OpenAPI、gRPC、内部RPC和鉴权方式。2.4 数据与持久化层AI应用的数据层除了传统的关系型数据库还有几个特有组件。向量数据库用来存知识库的向量化结果支持近似最近邻检索。会话历史存储用来保存多轮对话消息。有的系统还会存“完备的调用日志”每条用户消息对应哪个会话、用了哪个模型、检索了哪些文档、最后输出是什么这份数据既要满足审计要求也要用来做质量分析和数据集沉淀。画数据层时最容易犯的错误是只画“数据库”一个框不区分用途。我在图上习惯用不同颜色或按组件名称区分MySQL放业务数据Redis放会话状态和缓存向量库放知识索引对象存储放原始文件。这样谁负责哪个存储一目了然。数据流向也要标清楚知识库里的原始文件进了解析队列切片向量化后写入向量库查询时从向量库检索候选片段再拼入Prompt。2.5 可观测与安全保障AI应用的可观测性和安全治理和传统Web应用有差异但又是必须画的横切层。可观测不上只有传统指标比如请求量、错误率、延迟还要看Token消耗、模型调用次数、每次调用的上下文长度、每个用户平均对话轮数。这些指标直接和成本挂钩。有一天账单突然从一天一千涨到一天一万很可能就是某个用户输了一段超长文本或是某个Agent陷入了死循环反复调用模型。架构图上要把日志和指标采集链路从接入层一路贯穿到模型层标注采集点位置。安全方面一是内容安全需要对用户输入和模型输出做敏感信息审核二是权限控制不是所有用户都能问所有知识库内容也不是所有工具都能随便调用三是防止提示词注入用户输入里可能夹带“忽略之前的指令”系统要有校验机制。安全组件在图上贯穿所有层和业务组件交叉。我第一次画安全时只把它放在入口网关后来发现模型输出侧同样需要审核才意识到安全是要画成“围绕系统一圈”的横切层而不是一个点。3. 实操从需求到画出一张架构图很多同学看了不少架构图轮到自己画的时候却不知道第一笔落在哪。我分享一下自己的画图流程这次用一个具体场景串起来某企业要做一个内部知识库问答助手接入了企业微信入口需要对员工开放需要回答制度、流程类问题并且回答要引用来源文档。3.1 先把约束和要求列清楚动手画图之前我先和业务方确认几件事用户入口企业微信机器人、网页端还是都有知识库规模一万篇文档还是一百万篇这决定切片策略和向量库选型。并发量级几十人内部试用还是几千人同时用答案要求是否必须标注来源是否允许模型联网数据安全知识库能不能出内网模型用公有云还是私有化部署这些约束直接影响架构图的内容。比如知识库不能出内网那么大模型就不能是公有云API要么私有化部署开源模型要么走内网专线接入云服务。比如答案必须标注来源那RAG链路就是必需组件并且要在图上画清楚“引用来源如何从向量检索结果映射回原始文档”。3.2 按五步落笔画图我会按下面五个步骤一步步把图画出来。第一步画用户入口。先把企业微信机器人、网页端图标放在画布最上面入口之间是并列关系画法上保持一致。第二步画核心链路。从用户入口往下先画接入层再画编排层再画模型层这条主链路用粗实线画。这条线上标注的是用户消息-接入适配-会话管理-上下文组装-模型网关-大模型-流式返回。第三步标出数据依赖。主链路之外把知识库的解析流程画在左侧原始文档-解析服务-切片-向量化-向量库然后用带箭头的虚线从“上下文组装”引到“向量库”表示“查询时检索”。第四步补异步任务。文档解析、文件转码这类耗时操作不能落在主链路上要在图上用异步队列区表示标注消息队列服务。第五步标注失败与降级。用灰色或虚线框画出兜底路径比如模型调用失败时返回“暂时无法回答”并记录日志知识库检索为空时走重路由或提示用户换个问法。3.3 两种图例拆解对话式RAG与异步Agent流水线第一种是典型的对话式RAG架构最常见的同步链路。企业微信入口 - API接入 - 会话管理 - 上下文组装 - 向量检索 - 模型网关 - 大模型 | | 向量库(知识索引) 流式响应回前端这张图的关键在于上下文组装环节它同时接收会话历史、向量检索结果、系统提示词拼好之后送进模型。很多团队刚做RAG时架构图画的是“用户-大模型”一条线完全没体现上下文组装这个环节导致后面接知识库时改动很大。正确的画法必须把上下文组装作为一个独立节点画出来因为它是所有信息汇合的枢纽也是未来最常改动的地方。第二种是异步Agent流水线架构适合处理耗时任务比如“分析这个季度的销售报表并生成PPT大纲”。这种任务不可能在一个同步请求里等大模型一分钟算完需要拆成异步流水线。用户提交任务 - API接入 - 任务队列 - Agent编排引擎 - 工具调用 - 结果审核 - 通知用户 | | 状态存储(流程状态) 模型网关/大模型这张图里Agent编排引擎独立于同步链路存在状态存储单独画出来用户提交后立即返回“任务已受理”Agent在工作线程里逐步执行。任务执行过程中需要调用订单查询、报表解析等工具每一步的工具结果都写入状态存储。任务结束后再通过消息或轮询通知用户结果。这张图最大的价值是让大家一眼看出用户触发的不是一次模型调用而是一个被编排的多步骤流程。画清楚了开发在实现时就不会把Agent流程硬塞进HTTP请求里。4. 画图背后的选型逻辑架构图上的每一个框、每一条线背后都是取舍。不懂取舍画的图要么“什么都有”要么“什么都缺”。我挑四个最常见的选择题讲讲图背后的逻辑。4.1 同步还是异步这是画图时第一个要回答的问题用户发起请求后要不要一直等结果同步链路适合需要实时交互的场景比如聊天助手、问答系统。用户体验要求必须立即回应响应时间控制在几秒内。异步链路适合耗时操作比如批量总结、文档处理、数据分析。画图时如果拿不准就按“用户最长能等多久”来判断。超过10秒甚至几十秒的操作基本都要拆成异步否则并发一上来连接池直接打爆。很多线下运维事故的根源就是一个同步接口里调了一个慢模型最后把整个服务拖垮。异步链路也不是不用同步。用户提交任务后队列返回“受理成功”是同步的后台执行结果是异步的。架构图上两种箭头要画得不同同步链路用粗实线异步任务用虚线加消息队列节点。很多人画图习惯性全部用箭头连接同步异步不区分结果评审时谁也说不清哪个环节会阻塞。4.2 状态放在哪里AI应用的状态问题是开发过程中最容易扯皮的点。会话状态放在内存里重启就丢放在Redis里要设计序列化和过期策略业务流程状态放在编排引擎内部还是外部存储更是直接影响故障恢复能力。我画图时默认这样分配会话上下文放Redis因为需要快速读写且自然过期业务流程状态放数据库或专门的状态存储因为Agent流程执行过程中可能因模型超时、工具失败而中断需要把每一步的执行结果记录下来才能从失败处续跑。用户对话历史放数据库冷存储用于审计和后续分析。判断标准就一句话丢了会怎样丢了聊天记录影响体验但业务流程状态丢了会导致任务“不知道执行到哪一步”这个后果严重得多。所以越关键的状态越要画在靠近持久化存储的位置并标注持久化标识。4.3 模型网关与多模型协作现在几乎没有哪个正经AI应用只调一个模型。日常问答用通用大模型复杂推理用更贵更强的模型快速分类用小模型知识库召回后的重排序又用另一个模型。如果每次在代码里判断用哪个模型时间久了就是一团乱麻。模型网关就是为了把“选谁、怎么调、花多少钱”统一管起来。画图时模型网关画在编排层和模型实例之间所有AI调用都必须经过它。它做三件事路由选择、限流重试、成本统计。实际设计时还可以在网关上做模型灰度比如新版本模型先服务10%的流量观察质量指标再逐步放开。这个机制对架构保障很重要因为模型供应商更新模型后效果可能有波动直接全量切换风险很大。4.4 延迟、成本与可用性的取舍大模型调用的延迟和成本和普通接口完全不是一个量级。一次普通API调用几毫秒一次大模型调用可能两秒钟还按Token收费。这决定了AI应用架构必须具备“按需分层”的意识能用小模型解决的就不要用大模型能用缓存复用的就不要重复调用能用本地规则处理的就不走模型。我画图时会专门加一个“智能路由”节点前置规则引擎先判断请求难度。比如用户问“你们公司几点上班”规则库直接命中不需要模型调用只有规则库无法命中的需求才进入模型链路。这样做的架构意义很明显大幅降低成本和延迟同时提高系统的稳定性。这张图上多画的一个小框往往比后面多少优化都顶用。可用性方面要考虑模型服务不可用怎么办。现代架构的做法是引入多路模型容灾模型网关在A模型超时或限流时切换到B模型。画图时这个切换逻辑必须画出来否则测试时根本不会测到这条路等到真正故障时才发现“备用模型没有接入权限”或“切换逻辑根本没实现”。5. 常见问题与排查技巧实录画AI应用架构图这件事画多了就知道哪里容易翻车。我把自己踩过和见过的坑写出来做成一个针对性的排查清单。5.1 架构图与实现脱节的三个信号第一图上有的组件代码里找不到对应模块。最典型的是“上下文组装”只在图上有代码里没人专门负责提示词到处拼。这是大忌。图上的每个框必须能在代码仓库里找到归属团队或模块。第二图上没有的组件代码里反而很重。比如图上没画限流代码里却有一堆半路加的降级逻辑说明架构已经跟不上实现。第三数据流箭头和真实调用关系对不上。图上画的是A-B-C实际代码是A直接调CB只是个空壳Service。这种图趁早改不然新同学照着图排查问题一定会被带沟里。5.2 典型“画错图”现场我整理几个常见的画错情况方便对照自查。把API网关画成Agent编排器。API网关负责路由和鉴权它不负责Agent的推理循环。如果图上把业务编排的逻辑都塞进网关说明分层没有分清楚。把向量库画在模型前面。正确的链路是上下文组装根据用户问题先从向量库检索候选内容再把检索结果拼进Prompt送给模型。有些图画成用户消息直接进向量库再进模型不仅流程错误还会让人误以为向量库是模型的一部分。漏掉缓存层。很多人第一次画AI架构图满脑子都是模型、知识库、Agent把缓存忘了。实际上高频通用问题的答案完全可以缓存节省大量成本。删掉缓存架构图反而不完整。把“人工审核”画成可有可无的点。在AI自动生成内容的场景人工审核是业务闭环的必经环节。不画人工审核相当于默认模型输出可以直接对外发布这在企业级应用里是有很大风险的。架构图上人工审核要作为一个明确的节点标注审核通过后内容才进入对外渠道。5.3 推荐的绘图工具与标注习惯工具方面我主要用过三类。Excalidraw和Draw.io适合快速画草图和评审讨论上手快协作方便。ProcessOn和Visio适合做正式文档输出图形库丰富。还有Astah这种偏UML建模的工具适合需要严格表达架构元模型的时候普通项目没必要上。工具不是重点标注规范才是。我固定使用四种线型粗实线表示同步调用虚线表示异步消息细实线表示数据访问带锁图标表示鉴权链路。组件框标注按“组件名所属层/负责人”格式比如“会话管理编排层/张三”这样评审时能直接找到人。颜色规范也要统一一张图里不要出现超过四种颜色我的习惯是交互层偏蓝、编排层偏绿、数据层偏黄、横切治理偏灰看多了容易形成肌肉记忆。5.4 一点个人经验画了这么多次AI应用架构图我的体会是架构图不是画给别人看的首先是给自己看的。画不出来的部分往往就是没想清楚的部分。如果你觉得某个环节画不清楚比如Agent循环怎么退出、知识库更新时怎么保证检索一致性那说明设计还没到火候这时候停一停把问题解决了再继续画。每次评审之前我习惯把架构图对着代码快速过一遍确保每个框都能找到归属。这个过程很费时间但能提前发现很多实现和设计脱节的问题省掉后面线上故障的麻烦。