架构图不是画出来的是推演出来的。这些年我画过不少AI应用架构图也评审过团队里其他人的设计一个很深的感触是很多人把架构图当成了PPT配图画出来好看但经不起推敲——别人问一句这个模块挂了怎么办数据流到这里延时多少Agent在这步推理失败回不退路就答不上来了。这次借着图解AI应用架构设计这个话题把我自己画图、拆图、用图的完整思路梳理一遍。我会从一张图应该怎么分层讲起再聊数据流怎么在图上推演然后重点说Agent形态和传统AI应用在架构上的本质区别最后复盘几个实际踩过的坑。内容不追求面面俱到但求每一点都能落到工程实操上。1. 先搞清楚AI应用架构和传统应用架构差在哪很多从传统后端转来做AI应用的工程师上手第一件事就是把以前的Spring Cloud那套搬过来——网关、微服务、消息队列、数据库一样不少。不能说完全错但很容易把最核心的东西给架空了。1.1 传统架构的确定性 vs AI架构的不确定性传统应用架构的核心假设是确定性同一个输入同一个处理流程必然产生同一个输出。所以架构设计的重心放在状态管理、事务一致性、服务发现、负载均衡这些维度上——因为系统行为是可预期的复杂度的主要来源是规模和协作。AI应用架构的核心假设彻底变了模型本身的输出是概率性的同一个Prompt问两次结果可能不一样同一个文档切出来喂给RAGRecall的结果可能不同甚至模型服务本身还有Token限流、上下文窗口溢出、推理超时这些传统架构里根本不存在的故障模式。这就导致架构设计的重心发生了根本位移传统架构关注请求能不能被正确处理AI架构还要关注请求能不能被合理拒绝传统架构关注服务高可用AI架构还要关注模型幻觉兜底传统架构关注数据一致性AI架构还要关注上下文一致性传统架构的瓶颈在数据库连接和线程池AI架构的瓶颈常在Token消耗和推理延迟这四组差异直接决定了架构图中的模块划分、连线方式和数据流向。如果不先把这层想明白后面画的图就是传统架构换了身AI皮。1.2 我画AI架构图的三个前提在动笔画之前我习惯先问自己三个问题答不上来就先不画这张图给谁看给老板看重点是分层清楚、能讲清业务闭环给开发看重点是模块职责、接口边界、数据流向给自己看重点是发现设计漏洞。同一套系统三种画法。系统的核心不确定性在哪是模型效果不行需要人在环反馈还是上下文管理复杂需要状态编排还是外部工具调用不可靠需要重试和降级架构图一定要把不确定性最集中的地方画成视觉焦点。边界画到哪一层是画到微服务级别还是画到类/函数级别架构图永远不是越细越好画到能支撑当前讨论决策的粒度就停。这三个前提定了后面的分层和连线才不会跑偏。2. 一张可用架构图的基本分层从应用入口到模型底座我自己画AI应用架构图一般自顶向下拆五个层次每一层聚焦一个核心问题。2.1 接入与交互层不只是HTTP接口这一层是用户或上游系统触达AI能力的入口。很多人以为就是Nginx API Gateway但在AI应用里没那么简单。这一层至少要承载四类差异化流量流量类型特点架构关注点同步请求低延迟、短连接超时控制、流式响应流式请求SSE/WebSocket长连接连接管理、心跳保活、断线续推异步任务文档解析、批量生成任务队列、回调通知、状态查询多模态输入图片/音频/视频上传文件上传、格式校验、预处理流水线实际画图时这一层要明确标出SSEServer-Sent Events的处理路径。很多首次接触大模型应用的团队会在流式响应上栽跟头——网关层默认缓冲响应导致前端等了很久才看到第一个Token交互体验直接废掉。正确做法是网关对AI服务接口关闭缓冲或者直接用支持流式转发的独立入口。2.2 编排与业务层AI应用的大脑皮层这一层是整个架构图最核心的部分也是AI应用和传统应用拉开差距的地方。它解决的核心问题是一个用户请求如何拆解成一次或多次模型调用以及这些调用之间怎么组织。在这一层我通常画出三个子模块任务拆解器。把用户意图拆成可执行的子任务。比如帮我总结这份合同的风险条款这个请求拆解后可能是调用LLM判断文档类型调用文档解析服务抽取正文再调用LLM按风险维度做结构化总结。这个拆解可以是规则驱动意图分类模型 模板映射也可以是LLM驱动让模型自己产出子任务列表架构图上不需要写算法细节但一定要画出拆解结果的落点。上下文管理器。这是最容易画漏、但实际最重要的一个模块。LLM的上下文窗口是有限的多轮对话、长文档分析、Agent多步推理都依赖一个统一的上下文管理层来组织哪些内容进System Prompt、哪些进历史消息、哪些做向量化检索、哪些在超出窗口时被压缩或丢弃。架构图上要把这个模块画成独立的框和业务逻辑解耦。服务适配层。不是所有能力都直接调大模型。有些走RAG检索、有些走传统规则引擎、有些走外部API比如查天气、查数据库这些异构能力需要一个统一的适配层把语义化的工具调用翻译成具体的技术实现。画图的时侯这层的连线和下游依赖最多也是评审时被问得最密集的区域。2.3 模型接入层别让模型供应商绑死你的架构模型接入层是AI架构里最动荡的一层。今天我接的是GPT-4o明天可能就换成文心一言后天可能上一个开源模型微调版本。如果架构图上把业务代码和某个具体模型供应商的SDK直接画实线那基本就等着重构吧。比较务实的画法是在模型接入层抽象出一层协议转换层统一Prompt模板管理同一个任务不同模型用不同的Prompt模板统一模型元信息上下文窗口大小、支持的Tool格式、多模态能力统一错误码映射模型限流、内容审核拒绝、超时转成应用层可理解的异常统一评估追踪每条请求用了哪个模型、多少个Token、效果如何——这些数据是后续模型选型的依据这层的主要作用是把模型能力差异挡在业务之外。架构图上看起来只是薄薄一层实际代码量往往不小。2.4 数据与记忆层AI应用的地基这一层画的是所有喂给模型的内容和模型产生的内容的存储方案。具体包括四类存储数据类型典型存储说明结构化业务数据MySQL/PostgreSQL用户信息、任务状态、计费记录向量数据pgvector/Milvus/OpenSearch文档切片Embedding后的向量索引原始文档与中间产物对象存储/MinIO原始PDF、Word、切分后的片段会话与消息记录Redis 冷存多轮对话上下文需要快速存取画图时要注意一件事很多团队会把向量数据库当成AI应用的标配到处用其实不是。如果业务里没有真正的语义检索需求只是简单的根据用户ID查记录那用MySQL加个LIKE查询就够了完全不需要引入向量库。架构图上的每一个存储节点都应该是被需求逼出来的不是被概念炫出来的。2.5 基础层与可观测支撑所有上层的那条底线基础层包括模型服务本身的部署形态托管API还是私有化部署GPU集群以及底层的计算资源、容器集群、消息队列等。这层在架构图上通常是地基的存在看起来不起眼但决定了整个系统的成本上限和故障半径。比基础层更需要单独画一块的是可观测性。AI应用的可观测比传统应用多两个维度Token消耗追踪每个用户、每个会话、每个功能的Token成本一目了然这是AI应用成本治理的生命线模型效果追踪同样的输入在不同的模型版本下的输出对比、用户的最终反馈点赞/点踩/重试是否对齐这两块数据光是看日志是不够的通常需要单独的数据管道做采集和聚合。我在架构图上习惯把可观测模块画在右侧独立一列和主数据流分开避免主线被扯乱。3. 数据流控架构图上最容易被看穿的地方分层是骨架数据流是血管。一张AI架构图经不经得起推敲基本看数据流画得清不清楚。3.1 主数据流从用户请求到Token返回的完整路径以最典型的RAG应用为例主数据流是用户请求进入接入层鉴权、限流确认用户身份和配额请求进入编排层任务拆解器判断这个问题需要检索知识库上下文管理器把用户的原始Query改写成适合检索的形式这一步叫Query改写实际工程里很关键直接决定Recall效果改写后的Query向量化去向量库检索Top-K相关文档片段检索结果拼进Prompt连同会话历史一起组装成模型输入模型服务返回结果经过答案校验可选后流式返回给用户整个过程产生的Token用量、检索耗时、模型延迟全部落可观测系统这七步看起来直接但实际画图的时候有几个细节经常画错我后来都会专门核对Query改写在架构图上要有明确的位置。很多人直接跳过RAG图里的Query改写这一步把用户的原始Query直接拿去做向量检索所以画图时根本没有体现这一步。但真实系统里用户的原始表述往往口语化、无主语、代词多直接检索效果很差。架构图上如果漏掉这个环节说明设计的时候压根没考虑过这个问题——评审时我必抓。Retrieved上下文和用户历史消息的拼接顺序要画出语义。是历史消息在前还是检索片段在前两条路径在图上如果只是模糊地汇成一团说明设计者没想过Prompt模板的细节。兜底路径必须画。如果向量检索结果为空或相关度低于阈值系统是直接告诉用户没找到还是退化成无检索的纯LLM回答这条路径必须在图上明确画出否则遇到边界情况开发会临时拍脑袋效果无法保证。3.2 反馈与控制流不只是调用模型这么简单数据流画完之后我还会在图上叠一层控制流。控制流解决的是什么时候可以调模型、什么时候不能调、调了之后怎么处理结果。举个具体场景。用户提交了一个帮我分析这份财报的请求控制流的走向是文档是否上传成功、格式是否支持——不支持就直接拒绝不用走模型文档是否需要权限检查——没权限就返回403不走模型文档内容是否涉及敏感信息——命中敏感规则就拦截不走模型文档是否超过上下文可承载的长度——需要切片走RAG还是递归摘要模型输出的分析结果是否包含虚假的财务数字——和原始文档做交叉验证结果返回后用户点了没用这个反馈怎么回流到系统这些决策点都应该以分支或网关的形式体现在架构图里。如果一张AI架构图只有用户-模型-返回这条线性路径没有任何判断分支那它反映的就不是真实系统而是演示Demo。我见过太多团队架构图看起来很AI但实际跑起来效果不稳定最后定位原因就是控制流缺失——该拦截的请求没有拦截不该调模型的场景调了模型结果效果差还烧钱。控制流就是AI应用的安全阀和成本阀。4. Agent形态下的架构演进从一问一答到多步自主传统AI应用和Agent应用的最大差别用一句话概括就是前者是单次推理后者是多轮决策循环。这个区别反映在架构图上变化是根本性的。4.1 从线性管道到循环引擎传统AI应用的架构图是线性的输入-处理-输出一步到位。Agent应用的架构图必须画出循环结构用户请求 - 规划器 - 工具调用 - 结果观察 - 更新上下文 - 再规划 - ... - 最终输出这个循环在图上一定要突出因为它改变了一切设计假设超时设计变了Agent一次完整任务可能是几十次LLM调用不能按单次请求的5秒超时去卡要做整体任务超时加单步超时两层上下文管理变了每一步的观察结果都要拼进历史上下文窗口可能很快就满了需要压缩、裁剪、摘要幂等性设计变了同一个子任务可能因为Agent判断失误被多次执行架构上要求所有对外部系统的副作用操作发邮件、写数据库、创建订单都具备幂等能力成本控制变了一个Agent任务烧掉的Token可能是普通对话的几十倍必须在循环入口设置预算开关超过预算就强制终止我在画Agent架构图时习惯把终止条件明确画出来。一个没有终止条件的Agent循环在图上看起来是无限箭头这样的系统上线就是灾难。4.2 工具层Agent的手和脚Agent架构里比传统AI应用多出来的一个重要层次是工具层。工具层是Agent和环境交互的桥梁可以是内部API、外部第三方服务、代码解释器、数据库查询器。工具层的架构设计有几个关键点工具注册与发现。每个工具需要声明自己的名称、功能描述、参数Schema。Agent通过LLM的函数调用来决定用哪个工具、传什么参数。工具描述写得好不好直接决定Agent调用的准确率——这块在实际工程里需要反复磨架构图上体现为工具注册中心。工具调用的沙箱与权限。Agent调工具和你写代码调接口不一样Agent的入参是模型生成的可能完全超乎预期。所以工具层必须做参数校验、白名单控制、超时熔断。给Agent用的工具默认按不可信输入处理。我见过一个Agent因为参数异常把生产环境的测试数据清掉的案例血泪教训。工具结果的标准化。不同工具返回的数据格式五花八门有JSON有纯文本有二进制。工具层要把结果统一转成LLM友好的文本格式或特定结构化格式这一步不处理好Agent的观察环节就是一团乱麻。4.3 多Agent协作画图上容易失控的地方现在多AI协作、多Agent协作很热。说实话单Agent系统架构都没做扎实就上多Agent大概率是灾难。但如果在架构层面能看清协作模式多Agent也不是玄学。多Agent协作在架构上主要画三种拓扑指挥/汇报模式一个主Agent负责任务拆解把子任务分给多个专业Agent执行,结果汇总回主Agent。这种模式控制最简单主Agent是唯一的决策中心但主Agent容易成为瓶颈流水线模式Agent A的输出直接作为Agent B的输入前一个的结果是后一个的上下文。这种模式链条清晰但中间任何一步失败都要整条重来架构上要有断点续跑机制去中心化协商模式多个Agent共享一个消息总线自由发布任务和认领任务。这种模式最灵活但也是最难控制——架构上必须有全局的监控、审计和熔断开关不管哪种拓扑多Agent架构图上必须画三样东西共享上下文存储、全局任务状态中心、冲突仲裁逻辑。这三样少了任何一样多Agent系统跑几天就会乱成一锅粥。我自己的实际建议是能用单Agent工具解决的问题绝不上多Agent。多Agent的复杂度和成本是指数级上升的。架构图上的每多一个框都是未来的一份债务——加框很容易填坑很难。5. 图解复盘几个真实项目中踩过的架构坑最后这部分聊几个我实际经历过的架构设计教训。这些问题如果只靠画图推演往往发现不了必须结合真实运行数据才能暴露但一旦暴露回头改架构图的成本是巨大的。5.1 坑一把检索画成了查询RAG的架构位置放错了这个项目是给客户做企业知识库问答。第一版架构图我们画得很传统用户请求 - 文档检索 - 拼Prompt - LLM生成 - 返回。看起来没什么问题但上线后效果一直不好用户问的问题经常答非所问。后来逐层排查发现卡点不在检索本身而在检索的前一步。用户的自然语言问句直接拿去向量检索意图和文档内容之间隔了一道语义鸿沟。比如用户问我们公司的年假政策是什么但知识库文档里的原文是休假管理办法直接检索根本匹配不上。这个问题的根源就是架构图上漏掉了Query改写和多路检索两个环节。后面我们重画了这一段的架构把检索前处理单独画成一个模块拆成了意图识别、Query改写、关键词检索向量检索双通道、结果融合重排。架构调整之后Recall的效果提升非常明显。这件事之后我养成了一个习惯架构图上凡是有检索这个动作的一定先从图上往下追问三层——检索之前有没有预处理检索之后有没有重排检索失败了走什么兜底5.2 坑二上下文管理没有独立模块多轮对话越跑越笨这个项目是做一个业务辅助问答助手支持多轮对话。初期架构图里会话历史直接存在Redis里每次请求简单拼接最近的N条消息一起送给模型。一开始用着还行但对话轮次一多问题暴露了用户的问法越来越笨——明明是同样的意思模型好像忘了之前的上下文。排查原因就是无脑拼接历史消息导致的无关的历史消息占用了宝贵的上下文窗口关键的上下文用户刚才提到的某个具体实体被挤出了窗口Model之间的系统指令和用户历史混杂语义被稀释了这个项目后期对架构做了一个大手术把上下文管理从业务代码里抽出来单独做了一个对话状态管理层负责实体记忆从历史对话里抽取核心实体客户名、项目名、日期区间动态注入上下文窗口裁剪按Token数和重要性双维度裁剪历史保证关键信息不被挤出摘要压缩对话超过窗口上限时前半部分压成摘要保留这个改动没法在架构图上加两个框就完事它实际上重做了整个编排层的设计。从那以后我画任何AI应用架构图都会问一句上下文管理器在哪没有独立上下文管理的多轮对话系统架构图我直接打回。5.3 坑三Agent的手没有套安全壳测试阶段报了生产数据这是一个Agent自动化报表的项目。Agent会自动调用数据查询工具生成周报。测试阶段一切正常结果灰度放量之后某一次Agent在规划时把参数表和生产明细表搞混了触发了全量数据的聚合查询直接把数据库的IO打满。后面复盘问题就出在工具层的设计Agent调用数据查询工具时只有功能验证没有做资源级的安全控制。如果架构图上把工具层画成一个独立的安全边界——所有工具入参过白名单、所有查询任务强制带分区条件、敏感表离线隔离这次的故障完全能避免。现在我对Agent类应用有个硬性要求架构图上必须画出工具层之外的工具安全网关。这个网关不参与业务逻辑专注做三件事参数合法性校验、副作用行为审批比如批量删除、全量查询、对外发送消息、资源配额掐断。Agent的能力越强这个网关就要画得越重。5.4 坑四可观测画成了日志收集Token成本失控无人知最后一个坑也是很多团队会踩的架构图上可观测画得很大气但实际落地就只是一个日志收集管道ELK一把梭。我们这个项目问题暴露得很讽刺——是财务那边先发现的某个客户的上月账单Token消耗异常高逼近整个平台其他客户的消耗总和。排查之后发现这个客户的会话里挂着一个高频定时任务每隔几分钟就自动调一次LLM做监测判断一个月攒下来烧了几十万Token。而平台的监控面板上Token成本是看不到的——因为设计时只做了功能日志没做成本维度的聚合。架构图中可观测模块的正确画法应该至少包含三条独立链路链路追踪一次请求从进入网关到模型返回的每一跳耗时质量监控模型输出与用户反馈的关联分析幻觉用例的采样收集成本监控Token消耗按用户、按会话、按功能多维聚合超预算实时告警三条链路在架构图上看起来都在可观测这个框里但底层的数据管道分别是不同索引、不同聚合逻辑不能混在一个日志流里糊过去。这部分的教训是AI应用的架构图不能只画功能流还要画出钱流和质量流。这两个维度恰恰是AI应用和传统应用在运维层面最大的差异。画AI应用架构图说到底是在画一个不确定性管理系统的设计方案。模型输出的不确定、工具调用的不确定、上下文边界的动态变化、运行成本随流量非线性膨胀——架构图的每一笔连线本质上都是在回答一个问题当不确定性发生时系统如何优雅地应对。把这些年踩过的坑都画进图里图自然就有价值了。
