图解AI应用架构设计：分层、数据流与绘制实践

“图解AI应用架构设计”这句话放到我们日常语境里其实有两层意思先把这个系统画出来再让人通过图看懂它。两层是一回事。我复盘过不少次自己经手的AI应用架构设计也看过很多团队分享出来的架构图发现真正能沉淀下来的图并不是把所有模块都塞进一张大图而是把系统独有的形态画清楚把共性分层画出差异把最容易让人绕晕的链路画成一眼能读懂的走向。这篇文章想聊的就是我一般用什么思路来做图解AI应用架构为什么按这个顺序画以及画完之后如何让这张图真正被团队复用起来。1. 图解AI应用架构的第一步先选对要画的是什么图很多人一听到“架构图”三个字就直接打开画板从左上角开始摆框。这样画出来的东西大概率只是一张堆模块的示意图。我需要先停下来聊一个基础问题你要画的到底是应用架构、部署架构、数据流架构还是调用链时序图这个选择题如果没做好后面所有的框和线都容易失去真正的含义。对AI应用来说这个问题尤其容易被忽略。因为今天聊AI应用的话题大家自然而然会想起模型、Agent、向量库这些概念恨不得把它们全部放进同一张图里。结果图越画越满信息量却越来越低。我自己的经验是动笔前先问三个问题系统边界在哪里主干链路是什么关键控制点放在哪。这三个问题答案清楚了图才有骨架。边界不画清楚读者不知道哪些部分是你要设计的哪些是外部依赖主干链路不画清楚读者看完图不知道一次请求到底是怎么走完的控制点不画清楚读者看不出权限校验、模型选择、知识召回这些关键决策发生在哪个环节。放到AI应用场景里这三个问题会变得更具体。边界问题会变成哪些交互属于用户入口哪些任务属于后台异步哪些能力依赖外部模型接口哪些数据来自业务系统。主干链路问题会变成用户输入从接入层进来之后经过意图识别、上下文组装、工具调用、模型生成最后生成结果返回这条路径上的每一步由谁负责。控制点问题会变成在哪个节点做权限校验在哪个节点决定调用哪个模型在哪个节点召回知识在哪个节点对模型输出做校验。我还发现架构图的类型选择容易被“一锅烩”。有的图把系统部署在最下层标注云主机又把模块依赖关系画在中层还把一次对话时序画在右侧一张图恨不得承载三张图的使命。这里给大家拉了一个简单的对比方便画之前先定调。图的类型表达核心适用场景应用模块图系统由哪些模块组成模块之间依赖关系向新同学介绍系统全貌做技术方案评审部署架构图服务实例、网络分区、环境关系运维讨论、容量规划、故障排查数据流图数据如何产生、流转、存储和消费讨论消息队列、管道、RAG数据处理时序链路图一次请求按时间顺序经过的环节排查慢请求、讨论接口交互、Agent编排这四类图不冲突但最好不要画在同一张图里。图解AI应用架构设计首要任务就是让读者快速建立正确的心智模型。一张图塞太多层次的后果是新同学看了抓不住重点评审专家看了找不到决策点运维同学看了不知道该看哪一层。从一张图的读者视角倒推内容取舍是画图最值得投入时间的地方。2. 分层图怎么画接入层、编排层、模型层和数据层的边界选好图类型之后真正落到画布上时我最常用的主框架是纵向四层接入层、编排层、模型接入层、数据与知识层。这四层并不稀奇但每一层在AI应用里都有和传统业务系统不太一样的地方。先用一个简单的纵剖面建立整体感接入与展示层 | v 编排与状态层 | v 模型服务与网关层 | v 数据与知识层实际图里每个层下面还会有横向拆开的组件块但大框架建议保持这个顺序。顺序意味着依赖方向上层依赖下层下层不反向依赖上层。严格画箭头的时候我不会把“数据层主动调用模型层”这种反向依赖画错位置。2.1 接入层把交互方式抽象成统一入口接入层是用户与系统接触的地方。Web端、移动端、小程序、企业聊天工具、API开放接口都可能出现在这里。很多人画接入层时只画一堆入口图标这是最浪费画布空间的做法。入口形态当然重要但架构图上更值得画的是“接入适配”这件事多个入口进来之后如何统一成一套系统内部能理解的请求语义。我经手过的几个AI应用接入层通常会放一个协议转换或API网关组件。它的职责不只转发请求还包括身份认证、频率限制、参数校验、把不同来源的请求统一成标准格式。比如聊天窗口来的消息和API直接来的请求内部都有可能转成同一个会话对象。这段转换逻辑看似简单却决定了后面的编排层能不能保持纯粹所以值得在图上单独给一个组件框。接入层还有一个容易漏画的点流式与非流式接口。模型生成结果往往是流式返回的但传统接口设计默认一次请求一次完整响应。架构图上如果不表达出这条差异后端同学实现时很容易按普通接口设计等到前端需要打字机效果时再回过来补一层缓冲和推送逻辑。所以我在接入层的组件说明里会顺手标注“文本流式”四个字。2.2 编排层真正体现AI应用个性的部分四层结构里我最看重的是编排层。业务系统架构讲服务拆分、领域模型、事务边界而AI应用架构在服务之上多了一个粘合层它负责把用户意图翻译成一组可执行的步骤并且管理这个过程中的状态。Agent、工作流、提示词模板、工具调度这些概念在架构图上都应当落进编排层。以我熟悉的一个知识助手类应用来看编排层内部大致有四个节点意图识别与路由、上下文组装、工具调用协调、输出校验。意图识别决定这次请求该走简单问答、知识检索、多轮澄清还是调用某个内部工具。上下文组装负责把会话历史、用户画像、检索到的知识片段拼成一个结构化的请求。工具调用协调负责判断是否需要调用外部系统比如查询订单状态、提交审批并且处理工具返回的结果。输出校验在生成内容之后做一轮规则检查防止模型输出明显不合法或格式错误的内容。编排层还藏着一个关键概念循环。Agent类应用不是一次模型调用就结束的它可能先调用模型得到一个计划再执行工具然后带着工具结果再调用一次模型继续推理。这个循环如果不画出来图面上看起来就像一条直通车读者很难理解系统真正的运行逻辑。我一般会在编排层画一个带回边的组件示意或者在组件下方用一行文字写明“最多循环N轮”之类的边界条件避免图看起来像无限循环。状态管理也是编排层的重要组成部分。会话状态放在哪里、任务执行状态是否持久化、Agent运行过程中的记忆存在哪个存储里这些问题是图里绕不开的。很多AI应用做大了之后最容易出问题的不是模型调不通而是状态丢了、步骤乱了、用户刷新页面之后不知道任务进行到哪一步。所以编排层的图例里我会特意标出一个“状态存储”小框哪怕它只是逻辑上归属于编排层。2.3 模型接入层用一个网关收口模型可以理解为AI应用的核心计算资源但它不该散落在各个业务模块直接调用。资源统一接入统一管理。所以模型接入层本质上是一个网关组件参考传统架构里的BFF或API网关设计思路。我在图上画模型网关时会标出四项职责。第一统一接口对外只暴露一种调用方式内部可以把请求适配到不同模型格式。第二路由与降级根据任务类型、成本预算、模型质量要求决定走哪个模型哪个模型失败时自动降级到备选模型。第三限流与配额控制不同业务方的调用量防止单个任务耗尽资源配额。第四观测点在这里统一记录模型响应时间、Token消耗、错误率为后续成本分析和质量评估提供数据。曾有一位同事问我模型网关是不是可有可无直接用配置中心做映射就够了。我回答他说如果系统只有一条业务线、一个模型调用场景那确实可以简化。但只要涉及两个以上场景复用模型能力或者需要切换模型提供商网关的收口价值就体现出来了。它不只是转发请求更是集中处理策略的地方。图上线越少越是集中体现系统设计成熟度的地方。2.4 数据与知识层RAG和向量库在架构图中放在哪里数据与知识层是AI应用相对传统应用多出来的一大块。传统应用的数据层主要存业务数据AI应用还要存知识、存向量、存会话历史、存提示词模板。这个层次如果画得乱整张图会显得特别臃肿。我倾向把数据与知识层拆成三类存储来画。第一类是业务数据存储存放用户资料、订单信息、系统配置这部分和传统业务系统的数据库没有本质区别。第二类是知识库存储包括经过解析切分的文档片段、向量化后的索引、知识库的元数据这就是支持RAG的基础设施。第三类是缓存与临时存储包括会话上下文缓存、模型响应缓存、临时任务状态。三类存储不要混在一个数据库框里因为它们的数据生命周期和访问模式差别很大。RAG不能只画一个向量库。我曾见过不少图中间放一个向量数据库的图标然后用一条箭头连接用户请求就算完事。实际上RAG是一条链路包括文档入库时的接入解析、切分、向量化、索引更新也包括在线请求时的查询改写、向量检索、相关度过滤、重排序。图解时至少要表达出“离线索引过程”和“在线召回过程”两条路径才能让读者理解知识是怎么进到系统里的又是怎么被检索出来的。我在图上会用品红色或不同颜色的虚线区分这两条路径这样一张图就能把数据流和计算流同时讲清楚。3. 数据流视角让静态图“动”起来的关键分层图解决了“系统有哪些部分”的问题但它看起来是静态的。架构图的真正价值往往要在加上数据流之后才展现出来。很多人看图时会下意识地顺着箭头走一遍流程如果箭头画得含糊、路径残缺读者就会卡壳。所以我把数据流视为架构图的生命线。3.1 主请求链路从输入到响应的完整顺序任何AI应用都有一条主请求链路从用户发起请求到系统返回响应。图解时我会把这条主链路画成比较粗的实线并且尽量从头到尾连完整不要中途消失。一条典型链路是用户在入口提交文本或语音接入层做鉴权和参数校验编排层做意图识别必要时从知识层召回资料组装提示词后调用模型网关模型返回结果后经过输出校验再通过接入层返回给用户。这条链路每经过一个节点都会产生新的依赖。比如召回资料时编排层需要先知道提问对应的用户身份否则知识授权就无从谈起。比如调用模型时编排层要先把会话历史和检索到的片段拼接成完整的上下文拼接顺序有时直接影响生成质量。这些细节不一定全画在图上但图上每个节点的输入输出要能对得上不能出现一个节点输出了一堆东西下一个节点却没用它的情况。主链路还有一个容易被忽视的分支多轮会话。用户在一次对话中会连续提问后一个问题可能依赖前一轮的上下文。如果架构图上的会话状态是悬空的没有指向任何存储节点读者就理解不了多轮对话是如何实现的。我会在状态存储上画一条回边标明“会话上下文读取”和“会话上下文更新”让图的主链路呈现出一种循环感而不是一条直线。3.2 观测与反馈链路日志、评估和用户行为模型调用引入的不确定性让AI应用的观测变得比传统应用更重要。传统系统只要关注报错、耗时、容量AI应用还要关注生成质量、上下文长度、Token消耗、安全风险。因此架构图上应当有一条专门给观测反馈用的链路不能只在角落里画一个日志图标就算应付过去。观测链路一般分为两路。一路是智能体运行时观测记录编排层每个环节的执行时间、调用次数、模型输入输出摘要、工具返回状态。另一路是质量评估链路把一部分线上请求采样后送入评估系统对生成结果做自动评估或人工标注评估结果再循环回提示词模板、检索召回策略或模型选型的优化中。图上至少要把这两路画出来否则“持续优化”对于读者来说就只是一句口号而不是一条可追踪的数据流。用户反馈也很重要。点赞、点踩、复制结果、“这个问题没解决”之类的信号应当进入反馈系统。反馈数据的价值不只是统计满意度还可以作为强化学习的输入信号或评测集样本。我在画图时会把这些信号画成一条从接入层右侧流出的支线指向一个反馈与评测存储节点避免它和主链路混在一起导致视觉混乱。3.3 异步与事件驱动不能被主链路顺序掩盖的节点并非AI应用里所有流程都是同步请求-响应链路。知识更新、文档解析、批量任务、模型微调、异步回调这些都是后台执行的在图上如果全画成主线会把顺序关系表达得不准。我的处理方法是在数据与知识层旁边额外画出一条异步作业流。比如一个文档入库任务用户上传文件后就返回任务ID后台解析线程负责抽取文本、切分、生成向量、写入索引库。这条异步链路和实时问答的主链路走的是不同的箭头线型我会用虚线表示并且在线旁边标注“异步”字样。还有一类异步来自Agent的自主执行。Agent在推理过程中可能决定调用某个需要长时间运行的工具比如生成一份报表、发起一次数据同步。这时主线程不能一直阻塞等待架构图上也应该表现一个“任务挂起-异步完成-结果回填”的环。这个环不画清楚开发同学容易把Agent编排设计成同步阻塞导致系统整体吞吐受限。异步链路对架构图的完整性影响很大因为它把“系统内部模块”之外的时间维度和任务维度都加了进来让读者看到的不只是一个空间上的结构还有一个运行时的节奏。4. 按顺序画图从边界到节点再到连线的私用做法选好类型、分清层次、理出数据流之后剩下的问题是具体怎么画我见过很多同学直接在画布上从数据库开始摆摆着摆着就把自己绕晕了。这里分享一套我反复验证过的绘制顺序配合工具选型一起说。4.1 画图工具选型的考量画AI应用架构图的工具五花八门我大概把它们分成三类。第一类是白板协作工具适合方案讨论期快速画结构画完还能多人实时标注缺点是难以进行严格版本管理。第二类是桌面绘图工具适合精细化制图图面更工整但在团队协作和版本追溯上比较弱。第三类是代码化图表工具本质是用文本描述图结构可以入库做diff适合长期维护和多人协作。工具类型优势不足推荐使用阶段白板协作工具上手快互动自由适合头脑风暴图容易乱版本不可控前期方案讨论桌面绘图工具排版精细视觉美观协作弱单人维护产出正式汇报图代码化图表工具文本入库可diff多人协作好有一定学习门槛随项目维护的长期架构图我自己的习惯是讨论期用白板沉淀期转到代码化工具。特别是团队规模变大之后架构图拉进代码仓库每次修改都走评审全员对图的信任度反而会增加。很多人觉得画图工具越强大越好我的观点正好相反架构图是要维护的而维护成本主要由工具协作能力决定不是由颜值决定。4.2 确定绘制顺序先边界再节点后连线我的绘制顺序大致是六步。第一步先画系统边界用一个大的虚线框圈出你要设计的系统范围框外只放用户、外部模型、外部业务系统、第三方服务。这一步能倒逼自己想清楚哪些东西是自己能改的哪些是依赖别人的。第二步在边界框内画出纵向各层以及每层的主要模块节点这个阶段只画框不连线避免一开始就被细节缠住。第三步把跨层的常驻组件补齐如状态存储、日志平台、权限中心这些组件往往不属于某单层需要放在侧边。第四步画出主链路的粗实线从接入到编排到模型网关到知识层确保主路径清晰。第五步补充异步虚线、反馈回路、事件流。第六步给节点加简短注释比如在模型网关旁边写“路由、降级、限流”在向量库旁边写“知识索引与召回”让每个节点不是孤立名字。这个顺序的核心思想是先建立画布的“世界观”再填充具体内容。很多图之所以画乱是因为连线和节点交错生长画到后面自己都忘了当初为什么在这里加箭头。按顺序画每一步完成之后回头看都能判断图是否还处于可控状态。另外我倾向于让主链路的箭头沿着画布主流方向走要么从上到下要么从左到右。我见过不少优秀的图非要走对角线和绕弯视觉上很炫但给读者制造了不必要的阅读障碍。架构图不是艺术展品清晰到一眼扫完才算合格。4.3 给图加上的小惯例颜色、线型和版本标记长期维护的架构图需要有一套自己的视觉约定否则每次都靠人肉解释。我常用的惯例有四个第一主请求链路用粗实线异步流程用细虚线事件广播用点划线三种线型足够覆盖多数情况。第二除了系统边界我很少用大面积的填充色颜色只用来标记重点组件或风险组件。第三每个组件框尽量只保留一个名称和一句职责说明说明放在框下方或工具注释中不放一堆参数。第四图角上写清楚适用范围和最后更新日期比如“知识助手-逻辑架构-202501”方便团队判断这张图是否需要重新审阅。这些约定看起来琐碎但效果非常明显。团队里一旦形成统一的画图方言代码评审、架构评审、新人入职沟通的效率都会提升。我甚至见过团队把架构图的线型和配色写进内部文档规范因为大家真的在乎。5. 图解AI架构时最容易踩的坑画架构图的过程也是检验自己理解是否透彻的过程。我在这一项上踩过的坑做个如实复盘。5.1 过度抽象图里全是通用名词我第一次给某个AI应用画架构图时图里摆满了LLM、Agent、RAG、VectorDB这些词看起来很专业实际什么也没说。因为这些词只告诉你用了什么技术没告诉你系统里到底哪里用了它怎么用的。一个节点旁边写着“LLM”和写着一句话“入口意图识别场景用模型A知识问答场景用模型B”差别非常大。过度抽象的根源往往在于画图人自己就没想清楚模块边界。解决办法是把每个节点当作一个“岗位”来写想想它在系统里到底负责什么输入是什么输出是什么和谁打交道。写不清楚的节点大概率是你还没想清楚的模块那就先不留着它。5.2 过度细节把设计图画成运维手册反过来还有一种坑就是把一张逻辑架构图当成运维手册来画图里塞满了RDS实例规格、缓存集群分片数、K8s命名空间、Pod副本数。这类信息不是不能展示而是不该挤在同一张逻辑架构图里。当你满屏都是部署细节时读者根本看不到系统设计的核心逻辑。更好的做法是分层切片。第一层是逻辑架构图展示模块和职责第二层是部署架构图展示实例和环境第三层是核心链路详图展示具体交互和数据结构。三张图各司其职比一张巨型图可阅读性高得多。我曾用这个思路重构过一份混乱的架构文档评审会用初版图从半小时缩短到十分钟因为大家终于知道该聚焦在哪张图上了。5.3 一致性问题名称和粒度没有对齐还有一类坑会出现在图被多人编辑之后同一模块今天叫“意图服务”明天变成“NLU模块”后天可能又改成“路由引擎”。同一张图里在不同版本之间名称不一致讨论时的成本会急剧上升。号。我现在的习惯是和抽象命名一同进入文档库并且尽量用同一个词描述同一个组件图、代码注释、接口文档、评审材料都保持同一个称呼。粒度不一致也很常见。一张图里某个节点画到Pod级别另一个节点却还停留在系统名级别读图的人会在脑子里来回切换非常累。画图之前给自己定一个统一粒度层级比如逻辑架构只画到服务或模块级别不要在模块旁边又深挖一段详细类图。6. 图完成之后让架构图进化为团队的设计依据图画完不是终点。我见过太多架构图画得工整漂亮但发布一次之后就再也没被翻出来看过成了画布上的化石。要让架构图真正产生价值需要在图之外加上几层配套信息。6.1 架构图与接口、数据契约结合单张架构图能承载的信息终究有限但它可以成为团队文档的导航入口。我画完图后会给关键节点补充一个外部文档链接对应接口定义、数据模型或者核心类说明。看图的人点一下节点就应该能跳到对应的代码仓库、接口文档或数据库设计文档。架构图因此变成了一个“目录页”而不是一个只能被围观的孤立文件。数据契约尤其不能缺。模型网关的请求响应结构、工具调用的入参出参、知识召回结果的数据格式这些都有必要在文档里固定下来。如果只画了一个箭头不说清楚箭头上传的是什么读者会产生新的歧义协作时就会冒出各种自行猜测的异常情况。6.2 架构图中隐藏的权衡决策每一个架构选择背后都有权衡。为什么在模型层前面放一个网关为什么用向量召回而不是直接靠关键词为什么Agent循环最多跑三轮为什么异步任务用事件队列而不是定时扫描这些“为什么”是架构图最有价值的部分但图上通常不会写或者说写不下。我的做法是给架构图配一份轻量级决策记录每条决策记三句话当时发生了什么、考虑过哪些选项、最终为什么这么选。决策记录不追求长篇大论三五条之内完全够用。几个月后当自己回头看这张图时会发现最令人头疼的不是看不懂结构而是想不起来当初为什么要做某个设置。决策记录把“现在是什么”和“为什么是这样”绑在一起让架构图从一张状态快照变成一份有来龙去脉的设计文档。6.3 找“活文档”的平衡点而不是追着图改最后说说维护。我见过有人追求架构图永远和代码同步这几乎不可能也没必要。真正需要保持同步的往往是核心链路、关键边界和重要决策而不是每个模块的内部实现细节。我的做法是每次发生会影响外部依赖或跨模块交互的变动时才去更新架构图只改了一个类内部逻辑或者只调整了某个参数则不需要改动。每次更新时顺手把这次变更的理由写进决策记录这是回报率很高的一个习惯。三个月后回看你能很清楚地看到架构是怎么一步步从单体简化到分层设计又为什么在某个阶段加了新的异步链路。图解AI应用架构设计的最终目的不是画出一张完美的全景图而是让团队在讨论系统时有一张共同认可的底稿并且能顺着这张底稿持续演化下去。