1. 为什么架构师都在画图图解AI应用架构的核心价值做了十多年后台开发团队里带过不少新人我自己也面试过几百个候选人。这些年聊起AI应用大家经常出现一种很诡异的情况方案评审时每个人都能把自己的模块讲得头头是道但一旦追问数据和请求的完整链路是什么你的Agent挂了之后重试机制在哪一层会议室里立刻安静下来。这种讲了半小时还讲不清楚系统长什么样的尴尬几乎都源于同一个根因——没有把AI应用架构设计摆到和算法调优同等重要的位置上。AI应用架构设计本质上是在解决一个矛盾大模型的能力强但它是无状态的、有概率性的、边界模糊的而你做的业务系统需要有状态的、确定性的、边界清晰的交付。架构设计就是在这两层之间搭桥。而图解这两个字是这座桥的施工图纸。为什么必须落到画图上我自己的体会是语言描述对复杂系统的表达是线性展开的你讲完数据源、向量库、模型调用、缓存策略、回调逻辑之后听的人已经忘了你五分钟前说的是什么。但一张图能同时呈现层次关系、时序关系、依赖关系三种维度这恰好是AI应用架构里最需要被同步理解的三个维度。说白了图不只是给别人看的交付物更是自己梳理设计时逼着你把模糊想法显性化的工具。每次我画不出一张结构清晰的架构图基本都能倒推出某个环节的设计是含糊的。这篇文章不打算讲那些形而上的架构理念我直接把我这些年做AI应用架构设计的拆解套路、画图规范和落地经验整理出来。无论是准备用大模型做内部工具、做面向C端的智能助手还是做企业级知识问答系统这篇内容都能帮你从心里大概有数推进到图纸上清清楚楚。2. 图解AI应用的第一性原则先理解AI应用与互联网应用的架构差异很多团队做AI应用架构踩的第一个坑就是把传统Web架构的经验直接搬过来。结果模型一上线就发现各种地方不对劲每秒并发上去了模型服务扛不住、上下文长了响应时间飘忽不定、Agent逻辑复杂了根本没法调试。2.1 确定性系统与概率性系统的架构思维冲突做传统应用时你写的每一行代码几乎都是确定性的传参正确、逻辑正确结果就正确。你可以用单元测试覆盖大部分分支可以做精确的容量评估。但到了AI应用大模型是概率性的——同一个Prompt同样的参数两次输出可能完全不同。这个本质差异带来的架构影响是深远的。首先你的系统必须容忍不正确的输出。传统应用调用一个函数返回值不对那就是BugAI应用调用大模型输出不合理是常态。架构上必须有一层约束、校验、兜底机制。我见过不少团队把大模型调用裸放在核心业务链路里输出解析失败直接抛异常导致整个交易流程崩溃。这属于架构层面的设计失误不是算法问题。其次延迟分布完全不一样。传统微服务的P99延迟可能比平均值高两三倍但大模型推理的延迟方差可以大到离谱。同一个模型简单问题两百毫秒复杂推理可能五秒以上。如果你的架构里把模型调用放在同步链路上端到端延迟就完全不可控。这种场景下架构师要考虑的是哪些路径必须走实时模型、哪些可以异步化、哪些可以先用缓存命中再走推理兜底。2.2 状态管理的重新定义有状态服务与无状态模型的结合传统服务的状态要么在数据库、要么在Redis逻辑清晰。AI应用的状态管理要复杂得多——对话历史、向量索引的更新状态、Agent执行到哪一步、工具调用的中间结果这些都属于状态。而大模型本身是无状态的你给它的上下文决定了它的行为。架构上的核心命题就变成了如何把系统状态组织好喂给无状态的模型。这里有三个层级的实践短期状态比如单轮或多轮对话的上下文窗口管理通常存在内存或Redis按会话维度组织中期状态比如Agent的规划结果、已执行步骤、待办任务清单这类状态会跨多次模型调用需要持久化长期状态比如用户画像、领域知识、历史行为偏好这部分通常落在向量数据库或传统关系型数据库里。画架构图的时候这三类状态必须清清楚楚地标在图上分别连接到哪些组件由哪一层负责读写过期策略是什么。图示表达出一个完整的状态流转路径比写一百行注释都管用。2.3 AI应用架构的通用分层模型基于上面这些差异我画AI应用架构图时通常遵循一套分层模型大家在参考时可以直接拿来当骨架层级职责典型组件接入层处理外部请求、会话管理、鉴权、限流API Gateway、WebSocket服务、移动端SDK编排层意图识别、任务规划、Agent调度、多模型路由LangChain/LlamaIndex、自研Agent框架、工作流引擎模型层大模型推理、微调服务、多模型切换OpenAI API兼容网关、自托管推理服务、内部小模型数据层知识库、向量检索、业务数据、操作日志向量数据库、对象存储、关系型数据库、消息队列基础设施层监控告警、日志追踪、资源调度、安全防护Prometheus、Jaeger、Kubernetes、WAF这个分层模型几乎能覆盖市面上九成以上的AI应用架构。你可以根据自己系统的复杂度增删层但核心思想不变让每一层的职责单一、边界清晰、可替换。比如模型层做成统一网关之后底层从GPT-4切换到国产开源模型上层业务代码几乎不用改。3. Agent智能体架构的关键图解要素规划、记忆、工具说完了通用分层聊聊现在最火热的Agent架构。很多团队在Agent架构设计上最常犯的错就是脑子里只有一个模糊概念画出来的图全是云和框看不出推理的内在逻辑。3.1 Agent的循环决策单元怎么画一个最小的Agent决策循环包括四个步骤感知输入、规划下一步、调用工具、消化结果。这个循环会反复执行直到任务完成。画图时我会用一个明确的循环箭头把这四步串起来观感上像一个决策回路而不是一条线性流程。这个循环里有一个经常被忽略的环节——消化结果。模型调用完工具拿到返回值之后不是直接拼进上下文就算完事它需要判断这是最终答案还是中间结果决定继续执行还是返回给用户。我看过很多Agent框架的代码初期设计时没有单独表达这个判断节点结果任务一旦偏离预期路径Agent就进入死循环或者直接放弃。架构图上把决策判断节点画出来能逼着你想清楚失败分支的存在。3.2 记忆分层短期记忆、长期记忆、外部知识库Agent的记忆体系可以分成三个物理层每一层在架构图上必须有明确的读写连接工作记忆对应模型上下文窗口也就是当前这轮任务中所有可见的信息。它的特点是容量有限、用完即弃。架构设计上要注意上下文管理——哪些信息进上下文、哪些信息被裁剪直接关系到模型输出的质量情境记忆对应会话级别的历史信息通常存在Redis或内存数据库里按用户维度组织。对话系统里特别依赖这个层面长期记忆对应跨会话的知识沉淀可以是用户的偏好、历史决策记录、领域术语表这部分通常需要做向量化处理存进向量数据库供检索使用。画Agent架构图时我一般会在Agent核心外圈画三层存储环用不同颜色标注每一层记忆的读写路径。这三层之间的数据流最容易画乱我实操中的经验是先画写入路径再画读取路径两条路径不要交叉成网状否则整个图会失去可读性。3.3 工具调用的协议设计与纠错机制Agent让人惊艳的核心能力之一是调工具工具层在架构图里应该是一组带协议描述的服务节点。设计工具接口时最重要的不是功能有多强而是工具的描述文档能不能被模型正确理解。一个工具的描述写得含糊模型就不知道什么时候该调用它这跟函数命名不好导致人看不懂是类似的道理。架构图层面工具层要表达清楚三件事有哪些工具可用、每个工具的入参出参结构是什么、工具调用的错误码体系是什么。特别是错误码——LLM在接收到工具报错之后能不能理解错误原因并决定下一步动作取决于错误信息的结构化程度。建议工具返回统一使用JSON结构包含code、message、retriable三个字段其中retriable决定Agent要不要重试。4. RAG架构中的关键链路图解检索、重排、生成的编排RAG是目前落地最广泛的AI应用形态。把RAG架构画明白需要比文档切块、向量化、检索、拼接、生成这种粗糙描述更细一档的粒度。4.1 离线索引链路与在线检索链路的分离RAG系统在架构层面有两条完全不同的链路很多架构图把这两条链路画成一条导致从设计上就埋了坑。离线链路负责文档接入、清洗、切分、向量化、写入向量数据库。这条链路的特征是延迟不敏感、吞吐量大、失败可以重试适合用异步任务队列去驱动。在线链路负责接收用户问题、向量化Query、检索TopK、重排、拼装Prompt、调用大模型生成回答。这条链路的特征是延迟敏感、并发可控、需要有缓存和兜底。画图时一定要把两条链路用不同的颜色或区域隔开中间通过向量数据库和元数据存储连接。我见过一个很典型的架构事故团队把文档切分直接放在在线链路里做用户上传一个知识库文件接口要等好几分钟才能返回。这个不是模型不行纯粹是架构设计时没有区分离线链路和在线链路的节奏差异。4.2 检索质量的三级保障召回、重排、上下文精炼现在很多RAG系统的瓶颈不在模型在检索质量。画架构图时检索部分我会单独画出三个模块并按数据流的先后顺序排布召回阶段用向量相似度检索Top50甚至Top100候选文档块。这个阶段追求高召回率宁可捞回一些无关内容也不能漏掉真正有用的信息重排阶段用重排序模型比如bge-reranker对候选文档块做精细的相关性打分取Top5到Top10。这个阶段是决定回答质量的关键很多团队跳过了它直接取相似度最高的TopK效果会差一截上下文精炼阶段对选出的文档块做冗余消除、相关性过滤、长度裁剪控制在模型上下文窗口的安全范围内。这套三级保障链路画下来RAG的架构图就显得立体了。而且每个阶段都有明确的输入输出边界写代码时模块职责也清晰调试时可以直接定位是召回问题、重排问题还是上下文构建问题。4.3 多路召回的技术选型与图示表达单一向量检索不是万能的尤其是面对精确匹配需求产品型号、订单号、人名混合检索几乎是必选项。架构图上我会把检索模块画成并联接线的形式一路是向量检索一路是BM25全文检索或者ES的倒排索引两路结果做分数融合再统一进入重排模块。这个并在架构图里是一个很简单的视觉表达但我知道很多团队在落地时会纠结要不要引入ES还是继续用向量库的混合检索能力我的建议很简单如果你的搜索场景涉及大量精确字段匹配或者长尾关键词ES的成熟度和生态仍然更可靠至少在高版本中支持良好事务能力有保障。纯粹做语义搜索的话向量数据库原生支持的混合检索足够用。架构图上把两路输入、一个融合节点画清楚后面做性能调优时排查范围会小很多。5. 图解工具的选型与实际操作从白板图到可维护的架构图讲了这么多怎么设计架构还得说说怎么真正把图画出来。工具这块仁者见仁我分享一下自己踩过坑之后的组合方案。5.1 常用工具对比与适用场景画架构图的工具五花八门我按使用场景做了一组对照表基于我自己的实际体验和团队反馈整理工具适用场景优点缺点Excalidraw快速原型、方案讨论免费、上手快、手绘风组件库有限不适合复杂系统draw.io (diagrams.net)中大型架构图模板多、可嵌入Git仓库UI稍显老旧但功能完整Figma跨团队协作设计协作体验好、样式灵活架构图功能需要摸索偏设计工具Mermaid文档内嵌图、代码库维护文本即图、适合版本管理复杂图排版困难学习曲线缓PlantUML强调UML建模的场景开发友好、时序图结构清晰样式老旧想美观要花时间ProcessOn国内团队协作中文友好、模板丰富免费版受限我个人的主力方案是方案讨论阶段用Excalidraw速度快随画随改定稿之后的正式架构图用draw.io编辑导出成SVG放入项目的docs目录或知识库。如果是代码仓库的README需要的架构图我倾向于用Mermaid以代码块的形式撰写好处是架构图和代码一起走CR流程改动有记录可查。5.2 架构图的信息组织技巧分层、分区、配色很多架构图画出来像一团乱麻根源不是工具不好用而是信息组织混乱。这里有几个标准化的组织技巧直接套用能让图的清晰度提升一大截第一统一布局方向。建议按数据流向从左到右排布最左侧是用户和接入层中间是编排层和模型层最右侧是数据层和基础设施。读者看一眼图就能顺着方向的自然流动跟上思路。第二用泳道区分层次。在很多专业架构图工具里都支持泳道不同层级放到不同泳道里层级间的依赖关系用跨越泳道的连线表示。泳道越多说明系统分层越清晰如果泳道画不出来或者跨层连线乱成一团多半是职责边界没设计好。第三颜色用来辅助理解而不是装饰。建议用低饱和度配色接入层统一用冷灰、编排层用蓝、数据层用绿、非功能性组件用橙。颜色的语义全图保持一致不要把每个框都涂不同的颜色那会让视觉重点消失。第四关键的交互用数字标注时序。系统内的关键调用按顺序编号比如①用户输入→②识别意图→③检索知识库→④组装Prompt→⑤调用大模型→⑥返回结果。这样看图的人就能同时理解结构和执行顺序。5.3 从草稿到文档保持架构图的版本管理习惯架构图和代码一样是会腐烂的。系统演进半年之后架构图如果不更新它就失去了参考价值甚至成为误导新人的错误信息源。我建议团队把架构图纳入版本管理强调文档即代码的实践正式的架构图源文件draw.io的XML、Mermaid的文本存放在docs目录下或者专门的文档仓库里。每次架构调整架构图和对应的代码变更在同一个PR里提交。这样评审人能看到改了存储方案这件事在图上的直观反映而不是事后补一张不知道是否还有效的示意图。更新架构图确实枯燥但如果这个习惯没有养成半年后的新同学一定会拿着旧的架构图来问你为什么我们的数据流和图上画的不一样。那时候花的时间远大于定期维护一张图的成本。6. 非功能性需求的图解性能、可用性、成本、安全画在哪里聊架构设计光画功能组件远远不够。AI应用的非功能性需求变更比传统系统更隐蔽——流量上来了模型响应慢、第三方模型服务不稳定、Token成本不受控这些问题在架构图上都要有明确的位置。6.1 模型层的弹性和降级设计AI应用架构里模型层的弹性设计和传统服务的弹性设计有个本质区别模型推理的扩缩容受限于显存和推理集群容量不像普通微服务可以轻松横向扩展。架构图上要画出模型层的容量边界和降级路径。降级路径有三条常见的思路需要架构图明确表达模型降级主模型超时或不可用时切换到备用的轻量模型比如从大模型降级到小模型保证核心功能可用功能降级模型链路故障时降级到预设规则或知识库直接检索虽然回复质量下降但系统不宕机请求熔断连续调用失败达到阈值时直接在接入层熔断避免流量持续冲击模型服务。这三条路径在架构图上应该用虚线和实线区分表示。实线是主路径虚线是降级路径故障场景下流量如何切换到虚线路径需要在图上有清晰的标注。很多团队把降级方案写在文档里但图上没有体现结果真正出故障时没有人记得有降级方案这回事。6.2 可观测性体系在AI应用中的扩展传统可观测性的三件套——指标、日志、链路追踪在AI应用里都需要针对模型调用的特殊性做扩展。架构图上可观测性不只是挂在边缘的监控盒子它需要横跨所有层级。我的实际做法是在图的右侧或者底部画一条贯穿全图的观测总线所有在线服务都把链路追踪数据输出到同一套收集器按请求维度聚合。其中四个指标是我的必监控项建议每个团队都关注模型调用端的到端延迟含排队时间Token消耗速率分钟级上下文窗口使用率防止意外打满导致请求失败工具调用的成功率这个最能反映Agent的任务完成质量。6.3 成本治理的图示Token预算与数据缓存的边界Token成本是AI应用特有的成本项传统架构图里完全不存在。做架构设计时就要把成本边界画出来我通常在图里加一个成本控制面的模块它控制三个环节缓存策略相同或相似的请求优先命中缓存语义缓存、精准缓存减少重复模型调用模型路由策略简单问题走轻量模型复杂任务才调用大模型动态判断上下文压缩长对话场景及时压缩历史消息将关键信息做成摘要避免Token浪费在这部分的消耗上。这个模块在架构图上和数据层、模型层都有连接表达的是读缓存、选模型、控上下文三个动作。把成本治理放进架构图设计评审时大家才会认真讨论这部分而不是上线之后才发现费用超了预算再回头改。7. 从架构图到可运行的系统工程落地的认知对齐我见过很多团队花大力气画了漂亮的架构图最后实现出来的系统却和图纸出入极大。这种情况通常不是因为团队能力不行而是架构图缺少一个转化为代码的桥梁。7.1 架构图如何拆解为开发任务我的经验是在架构设计定稿之后追加一版模块依赖矩阵或者接口契约文档明确标注每个模块对外暴露的接口、依赖的下游服务、以及失败时的行为。这比架构图更加贴近开发落地但它本质上是从架构图中推导出来的。架构图上每一个连线落下来都是代码里的一个依赖关系。比如编排层→模型网关的箭头落地时对应的是编排层代码里对模型网关SDK的调用以及模型网关暴露的REST接口。如果一个连线在图上画了但在模块依赖矩阵里找不到对应接口说明要么图上有多余的组件要么接口设计遗漏了。7.2 架构模块的边界定义接口第一还是实现第一后续开发中一个常见的争议是架构图中的组件谁来负责实现如果多人协作时边界不清会出现A开发和B开发各自实现了相似的功能浪费了工作量或者甲认为某模块由乙负责但乙并不知情的情况。我的建议是在项目启动时用架构图做一个快速的模块认领会每个人的名字对应架构图上的一个或几个模块区域并明确这些模块之间的接口契约。这里给出的架构图和最终代码结构需要保持一致契约才能成立。7.3 小步验证优于大爆炸式落地最后分享一个具体的工程建议AI应用架构的落地不要直接做完整实现按价值切片分步交付会稳妥得多。这里举一个我自己实际采用的节奏安排第一步只做模型层和接入层让用户提问—模型回答的最小闭环先跑通。这个阶段验证的是模型能力与体验基线第二步接入数据层和检索链路建立RAG的能力验证知识库检索的质量。这个阶段观察检索对回答质量的增益是否符合预期第三步再实现Agent编排和工作流逻辑加入工具调用。这个阶段最复杂因为涉及多步推理和状态管理。通过前两步打下的基础展开这步时整体可控。这种小步策略配合架构图的分期标注非常实用在图上用不同颜色的标签标出Phase 1、Phase 2、Phase 3范围团队始终知道那一阶段在做哪些组件。相比拿到一张大图从头开始全部实现这种节奏的工程风险要低得多每阶段结束都能获得可以演示和反馈的成果。我在实际做架构落地时还有一个体会架构图永远是简化过的模型真实系统的复杂细节远多过图上的表达。但正因为是简化模型它才能起到统一认知的作用。当团队所有成员的认知对齐到同一张图纸上时后续的编码、排查、协作都会顺畅很多。每次新项目启动只要花足够的时间把第一版架构图画明白、讲清楚后面省下的时间远超前期投入。