做AI应用架构设计这几年最让我头疼的从来不是技术选型而是把架构画出来。有一次评审会我盯着投影仪上一张AI应用架构图看了五分钟愣是没找到用户请求是从哪个框进去的。七层嵌套的容器、三十几个带箭头的方框、三个不同风格的图例说明看起来信息量十足可真正到了模型返回的结果怎么回到客户端这个问题讲方案的人自己也要沿着箭头找半天。这种场景我见过太多次了。图解AI应用架构设计说白了就是两件事一是知道AI应用架构里该画哪些组件和关系二是知道怎么画才能让评审人、开发、产品在五分钟内达成共识。AI应用架构设计和传统软件架构有个很大的不同系统里多了模型服务、向量检索、提示词管理、RAG链路这些新角色。传统架构图里一个接口调用就能说清楚的事到这里往往还牵涉到上下文组装、知识库命中、流式返回这些新维度。这篇文章我就顺着该画什么和怎么画两条线把我这些年画过、改过、评审过的一堆架构图经验包括范式选型、工具选择和评审追问一次讲透。1. 先别急着画框一张AI架构图到底在替谁说话1.1 三种读者三种画法我见过很多人接到画一张架构图的需求后第一反应是打开画图工具开始拖框。这其实是一个本末倒置的动作。AI应用架构图的读者按我自己的分类至少有三种开发工程师想知道这个系统由哪些服务组成、接口怎么调、数据从哪里来关心的是照着这张图能不能写出代码架构评审或技术负责人关心的是数据流是否闭环、有没有单点故障、权限边界有没有画清楚、成本瓶颈在哪一条链路上产品或业务伙伴基本不看技术框他们想确认这个系统能做到什么、不能做什么、模型答不上来时怎么办。同一张图想同时满足这三种人结果通常是三种都满足不了。所以拿到需求的第一件事不是画而是问一句这张图给谁看要支撑什么决策如果给开发看组件粒度要落到服务名和接口数据流要标上协议如果给评审看要突出异常路径、兜底方案和数据边界如果给产品看把模型层画成一个能力网关就够了把精力放在用户流程的闭环上。我自己的习惯是早期讨论用手绘草图正式评审前再出一版面向评审的结构图每次只服务一类读者图才不会变成一堆谁都不愿意看的方块。1.2 AI架构图与传统架构图的三处本质差异传统Web架构图大多是请求-响应模型客户端打到接入层接入层转发到业务服务业务服务读写数据库返回结果。这种图哪怕不标注数据流方向大家也知道大概怎么走。AI应用架构图没那么宽容它有三个传统架构里很少出现的新特性。第一是链路编排代替了单纯的服务调用。以RAG为例一个用户问题进来可能要经历意图判断、查询改写、向量检索、重排、上下文裁剪、模型调用、流式返回每一步都有独立组件。如果你不把这条链路按顺序编号画出来看图的人根本不知道先发生什么、后发生什么。第二是不确定性组件需要兜底设计。模型可能答错、检索可能没命中、第三方模型服务可能超时。传统架构图可以假设正常路径AI架构图必须把失败路径画出来否则评审时一定会被问死。第三是状态与记忆问题。Agent场景里系统要在多轮对话中维护记忆还要循环调用工具架构图的表达方式从一条直线变成带环的回路箭头怎么画、循环从哪进从哪出都需要额外设计。1.3 我判断一张架构图合格的唯一标准这些年我看过的AI架构图少说也有几十张最后总结出的验收标准特别简单找一个没参与过这个项目的人给他三分钟让他说出用户请求从哪进来经过哪些组件最后结果怎么回来以及某个环节挂了系统会怎样。如果他说不出来不是他理解力有问题是你的图没画清楚。这个标准我一直沿用简单粗暴但比任何规范都好使。这三分钟里最常翻车的两种情况一种是组件太多找不到主链路另一种是所有箭头都没有编号和方向。前者说明画图的人没做取舍后者说明他压根没在画数据流只是把一堆系统摆在一起。本质上架构图是数据流的故事不是组件的全家福。2. 画图之前先拆骨架AI应用架构的四层组件地图2.1 数据与知识层别只画一个孤零零的数据库这一层是最容易被画秃的。很多人画AI架构时数据层就画一个数据库框旁边连着一个向量库。实际进入过AI应用的人都知道数据层至少得回答三个问题数据怎么进的、存在哪、怎么保持最新。先说数据怎么进。以知识库问答为例原始数据可能是内部的规范文档、商品信息、工单记录。这些数据源要先经过解析、清洗、格式统一、分块、向量化最后写入向量库。这条处理管线在图上应该用虚线画在离线侧很多新手会漏掉导致看图的人以为文档一上传系统就自动懂了。再说存在哪。需要画的通常有三类存储业务数据所在的传统数据库、用于语义检索的向量库、用于命中缓存的热数据存储。向量库和业务库之间不要画一条直连的线然后什么都不写它们之间往往隔着分块向量化这个转换动作这个动作必须画出来。最后是保持最新。文档更新后是增量刷新还是全量重建对系统实时性影响巨大。我建议在图上明确标注数据更新的触发方式和频率比如文档发布事件触发增量入向量库每夜全量校准。这部分画不画直接决定了别人是否会误判你的数据时效性。2.2 模型服务与推理层模型不是万能黑盒模型层的主语不是某个大模型而是模型服务。很多架构图把LLM画成一朵云标注大模型然后所有业务都指向它这种画法和当年把数据库画成一个大桶没有本质区别。模型层的组件至少包括模型服务入口自部署的推理服务或API接入、模型网关负责路由、限流、密钥管理、提示词管理模板版本、系统提示词、few-shot样例、上下文与输出控制窗口裁剪、停止符、温度。其中提示词管理经常被忽视但它对系统行为影响最大。生产环境里提示词应该是可配置、可版本化的架构图上至少要画出提示词模板这个组件否则后续优化时你根本说不清线上跑的是哪一版提示词。调用方式也要如实画是同步请求还是流式并发上限是多少超时设多少这些参数不需要写进图里但评审时通常会被追问。你可以用注释标注在组件旁边比如模型服务P95 2s超时3s并发上限50比框里只写LLM要扎实得多。2.3 业务编排与调度层AI应用真正的大脑这一层承载的是意图识别、路由选择、工具调用、多轮记忆、重试和兜底逻辑。简单问答系统里它是判断是否需要检索的路由器Agent系统里它是循环调度的主循环。我的经验是大多数AI应用复杂度最高的部分恰恰在这一层但画图的人往往只用一个大框AI平台把它包起来。这样画虽然整洁可一旦评审问到模型回答出现幻觉怎么办检索没结果怎么处理这个大框就变成黑盒什么也答不上来。我的建议是把编排层的关键决策点拆开画先画路由决策用户问题是否包含事实性追问是则走检索否则走直答再画工具或检索调用最后画结果校验与兜底。哪怕只是为了评审也要让看图的人明白大模型不是直接对着用户输出中间还有一层业务逻辑在管着它。2.4 交互与反馈层流式输出与体验闭环这一层关系到用户体验和系统的自我进化。AI应用与普通API应用最大的体验差异是流式输出架构图上要画出WebSocket或SSE这条独立通道而不是把返回结果简单画成一个HTTP响应。同时要标注首字延迟这类关键体验指标。反馈闭环也很重要用户对回答的点赞、点踩、纠错这些信号最终要汇入评估管道经过人工抽检或自动化评测再反馈到提示词、知识库甚至模型微调。这个回路在架构图上往往要画成一条从交互层回到数据层或模型层的环形线。没有这条线的AI架构本质上还是一次性的模型壳子谈不上应用级的架构设计。3. 三种主流范式图解对比RAG、Agent、微调流水线3.1 RAG范式离线管道和在线检索必须分开画RAG是目前落地最广的范式。图解RAG的第一个原则就是把两条链路分开离线数据管道走虚线在线推理走实线。离线链路从数据源出发经过解析、分块、向量化写入向量库在线链路从用户问题出发经过查询改写、向量召回、重排把Top-K结果和问题一起组装成上下文再交给模型生成回答。这里有两个细节值得单独标注。一是查询改写组件很多人一开始不画它但线上检索效果不好的时候问题往往出在用户口语化表达和文档术语不匹配查询改写就是干这个的。二是重排组件向量召回是粗筛重排才是精排这两步不分开画的话看图的人会误以为向量库直接决定了回答质量。RAG的图解重点是在线链路的顺序和上下文组装的位置。我最常看到的问题是有人把向量检索画在模型服务调用之后还有人干脆把知识库和向量库混成一个框这些都是结构上的硬伤评审时一眼就能看出来。3.2 Agent范式循环、记忆与工具边界Agent架构画起来比RAG复杂一个量级因为它不是线性链路而是循环决策。核心组件包括主控模型负责规划下一步、记忆存储短期对话记忆与长期用户画像、工具注册表可用工具及参数描述、执行引擎真正调用外部工具。图解Agent时我建议把循环画成带编号的回路第1步模型决定调用哪个工具第2步执行引擎调用工具并返回结果第3步结果写回记忆并再次交给模型决策循环直到模型认为任务完成或达到最大轮次。如果整张图只有一到两个循环可以把它画成主循环工具子层的结构如果工具很多建议单独画一张工具总览图不要在核心架构图里堆所有工具。还有一个容易疏漏的边界是人工介入点。Agent和纯自动化系统不同关键操作比如下单、发消息通常需要人在回路里确认。架构图上要把这个确认节点画清楚否则评审时安全相关的追问会把你问懵。3.3 微调与模型运维范式把版本当一等公民第三类范式围绕训练-评估-发布展开多见于要用私有领域数据微调模型的团队。它的核心不是推理而是数据与模型版本的管理。图解要点是画清楚这样一条流水线训练数据准备采集、清洗、标注、脱敏- 微调任务基座模型数据版本超参数- 离线评估评测集、指标- 模型注册模型版本、指标报告- 部署发布灰度、回滚。这条流水线上最容易被画丢的是数据版本和评估关卡。没有数据版本你无法复现一次训练的效果没有评估关卡你无法回答新模型凭什么敢上线。发布阶段的灰度路径也要明确比如新模型服务先接10%流量监控回答质量与延迟达标后再逐步全量。这张图里的模型服务不再是单一本体而是一个带版本号的部署单元。3.4 三种范式的选型速查表范式典型适用场景图解核心组件最容易被忽略的要素RAG知识库问答、文档辅助、企业搜索离线数据管道、向量检索、重排、上下文组装查询改写、数据更新机制Agent任务型助手、自动化流程、多工具协作主控模型、记忆、工具注册表、执行引擎最大循环轮次、人工介入点微调流水线垂直领域模型、私有数据训练数据管道、训练任务、评估关卡、模型注册数据版本、灰度与回滚路径选型时不要只看热闹要落到自己最痛的那件事上回答不准就先补RAG流程复杂需要自主决策才上Agent数据分布特殊才考虑微调。三个范式也可以混用但架构图上必须能分清哪条链路是检索、哪条链路是决策、哪条链路是训练。4. 实战从空白画布到一张可评审的智能问答RAG架构图4.1 第一步先画主数据流用户问题怎么走完一圈我带过的新人画架构图最常见的毛病是一上来就画全部组件画到一半发现线怎么连都别扭只好全删了重来。这个问题出在顺序上没有主数据的先后顺序所有组件都只是浮在画布上的孤儿。正确的顺序是先把主数据流画通再逐步往骨架上挂组件。以智能问答RAG为例主链路从左上到右下依次是用户在App输入问题。API网关统一鉴权、限流把请求转发到编排服务。编排服务执行意图判断简单寒暄走直答事实性问题进入检索流程。查询改写后生成向量在向量库召回Top-K相关片段。重排后取最优结果与问题、历史会话一起组装提示词。模型服务流式生成回答经网关转发回App。画到这步这张图作为骨架已经立住了。你会发现真正决定图质量的不是框的数量而是这6个箭头的顺序和编号是否清晰。不管未来组件有多复杂这六步会一直占据图中最显眼的位置。4.2 第二步补上离线管道、缓存和兜底主链路完成后再加配角。离线侧画一条虚线链路管理员上传文档 - 文档解析 - 分块 - 向量化 - 写入向量库再标一个更新触发文档发布事件 每日校准。这一条虚线会让评审的人立刻明白知识库数据不是凭空出现的。缓存可以画在编排服务和模型服务之间标注相同或相似问题命中缓存后直接返回不发起模型调用能省下大量调用成本。兜底路径要画两条检索结果为空时返回未找到相关资料的话术并转人工模型调用超时或失败时系统降级为固定提示语。这两条路径在图上一旦缺失评审时模型挂了怎么办这个问题会非常难回答。4.3 第三步用标注做减法而不是用组件做加法架构图最常见的失控就是组件无限膨胀。经验法则是每一层最多画5个组件组件与组件之间只画必要的关系。如果某个细节只有你自己觉得重要那就是不应该画上去应该挪到图下方的注释区里。注释区放三类信息协议与数据格式HTTP/JSON、SSE流式、关键SLA首字延迟500ms内、P95总耗时3s内、安全控制点API网关鉴权、数据权限过滤。用注释代替堆组件图会清爽很多信息的层级也会更合理。另外可以约定一些通用图形符号实线代表同步调用虚线代表异步或离线任务加粗或特殊颜色代表异常与兜底路径。一套符号用到底比任何花哨的画法都重要。4.4 第四步交付前的自查清单我把自查清单压成了五条每次画完图就当复盘用主数据流是否有编号看图的人能不能不看文字描述就说清先后顺序。每个关键决策点路由、重排、兜底是否都在图上有对应组件离线管道和在线链路是否用线型区分开了数据权限、模型超时、失败降级这三件事有没有至少标注一处找一个没参与项目的人让他用三分钟复述这张图看是否卡壳。这五条都打钩图基本就可以进评审了。如果哪条打不了钩宁可晚一点交付也别拿一张自己都讲不清的图去开会。5. 画图工具怎么选三种流派和我的实测感受5.1 手绘风讨论阶段的神器白板或者手绘风格工具适合画想法草图。我早期做方案讨论时最喜欢这种方式拉着评审人十分钟内画出主数据流和异常路径当场讨论、当场改。手绘风的优势是逼格低因为线条歪歪扭扭大家下意识会把它当草稿去讨论而不会纠结一个框的位置一旦用了精致的模板人反而会把注意力放在好不好看上而不是对不对上。这个阶段不用纠结组件规范重点是讨论本身。5.2 结构化工具正式架构图的主流选择进入正式文档阶段我比较推荐用开源的结构化绘图工具比如draw.io这类支持图层、自定义形状库和多端协作导出的SVG或PNG清晰度足够放进文档。它在团队协作里的好处是单文件就能承载整张架构图可以放进代码仓库或在线文档改一处保存一处不会出现聊天记录里找最新一版这种鬼故事。用这类工具时我的个人习惯是先定画布尺寸和配色背景用白色或浅灰业务组件用蓝色系数据存储用绿色系异常路径用橙色系字体统一用14号以上保证投影时看得清。颜色不是装饰是信息编码。5.3 代码式绘图把架构图当代码来维护如果团队工程化意识强或者架构图需要频繁跟着代码迭代代码式绘图工具比如用文本描述图形的方式会很合适。它最大的优点是能放进版本控制里做差异对比代码评审时可以看到架构图随代码一起变更维护流程也顺理成章。缺点也很明显表达能力受语法限制画复杂回路和嵌套结构会比较痛苦非技术人员基本没法直接上手改。我的取舍建议是项目早期用代码式画出结构骨架稳定后再导入结构化工具精修或者反过来精修稿定期回写代码式版本。没有完美的工具只有适不适合当前阶段的工具。5.4 团队的图一致性经验比起工具团队协作中真正困扰人的是图的风格混乱有人用箭头表示依赖有人用箭头表示数据流有人把同一种组件画成三种形状。我建议团队内部约定一个极简规范两三条就够标准组件样式、同步与异步线型、异常路径标注方式。规范越短越容易被遵守长规范只会变成没人看的文档。另外架构图要跟着代码一起版本化。不要只在评审时导出一张图片扔到文档里要保留源文件并且让每次架构调整都有记录。我见过太多系统代码重构了三轮架构图还停留在第一轮最后那张图的作用只剩下误导新人。6. 评审现场你的图必须能回答的四个追问6.1 模型挂了这条路还能走吗评审人最常问的第一句话是模型服务不可用了怎么办。一张成熟的架构图应该能指着某条路径回答缓存命中先顶上、检索兜底话术接管、人工通道保留。这三个降级层在图上至少要有一个是显式的。如果图上只有一条实线直连模型服务没有任何分支那评审结果大概率是回去把降级方案补上。我见过一个做得比较好的案例图上把模型网关和降级服务画成并联结构模型网关检测到连续超时就把流量切到降级服务降级服务返回固定话术并给用户提供人工入口。设计不见得多复杂但画出来之后评审现场几乎没人再追问容灾问题。6.2 数据权限在哪一层生效AI应用引入向量库后数据权限成了评审的高频焦点。你要能在图上指出权限边界是在API网关层控制用户身份还是在向量检索时按租户过滤或者在结果返回前做脱敏。最怕的情况是图上一片空白翻代码才找到权限逻辑。数据权限画不清楚等于告诉评审人我们还没认真想过数据安全。我的建议是至少在数据与知识层画一个权限过滤组件并标注生效位置检索前过滤还是检索后过滤。这个细节看似小但往往最能体现一个架构设计是否真的经过推敲。6.3 成本和延迟的大头在哪一段模型调用是AI应用里成本与延迟最集中的一环。评审时要有能力指着图中编排服务到模型服务这一段说出大致的成本构成输入Token数、输出Token数、缓存命中率。延迟同理检索是毫秒级模型输出是秒级瓶颈明摆着就在模型调用这一步。如果你的图把模型服务画得和其他组件一样大、一样平常那说明你没有暴露最关键的性能特征。我通常在图上把模型调用这一段用特殊描边或加粗并标注主要成本与延迟来源几个字。这样做的好处是评审人不用猜就知道优化应该往哪里使劲先做检索质量减少无效Token再做缓存提高命中率最后才考虑换模型。6.4 从用户反馈到系统改进闭环画了吗AI应用不是上线就结束的问答质量要持续迭代。最后一个高频追问是你怎么知道系统变好了还是变差了。架构图上如果有一条从用户反馈埋点到评估服务再到提示词版本更新的回路哪怕只画一条带箭头的虚线加上评测样本回流几个字也能证明你考虑了迭代机制。我管这条回路叫AI应用的呼吸系统。没有呼吸系统的架构只能算一次性demo有了它系统才有持续进化的能力。画的时候不需要复杂能回答反馈从哪收集、由谁评估、改进落在哪一层这三个问题即可。最后顺着这个话题分享一个我自己的习惯画架构图永远先画一个最丑的版本越丑越好——丑图不会让你舍不得改画完主数据流和异常路径之后再花二十分钟做美化。真正重要的永远是那根主数据流的顺序、那几条兜底路径的存在以及你能否在三分钟内讲清楚它。工具、配色、符号规范都只是辅助别让它们喧宾夺主。