做AI应用架构设计这几年，我最大的感触是：很多时候团队里吵得不可开交的问题，不是模型选得不对，也不是代码写得不好，而是大家脑子里的架构图不一样。算法同学说的“模型层”可能是权重文件，后端同学说的“模型层”可能是推理服务容器，产品同学理解的“Agent”又完全是另一套东西。真正能让大家坐下来对齐的，往往不是几十页文档，而是一张画得足够清楚、足够准确的架构图。
这篇文章就把我总结的“图解AI应用架构设计”这套方法完整拆开。我会先讲为什么画图是第一步，再拆解AI应用架构的核心组件、画图的具体套路、工具选型，最后用一个企业知识库问答系统的真实案例走一遍端到端流程。不管是正在做AI应用落地、Agent系统设计，还是想把手头项目理清楚的同学，都可以参考这套思路直接动手。
1. 为什么说“图解”是AI架构设计的第一步
1.1 一张图解决的最大问题：信息对齐
我参与过的AI项目里，最常见的失败不是模型能力不行，而是各方对系统边界理解不一致。架构师说“这里走大模型API”，研发以为把Prompt拼好调一次就行；运维以为要自己部署GPU推理服务；产品以为回答一定是实时的、准确的、免费的。为什么会有这种偏差？因为文字描述天然存在歧义，“模型”“服务”“向量库”这些词在每个人脑子里映射到的组件完全不同。
而图能把这种抽象落到具体。同一个“模型服务”节点，在图上代表的是一个独立部署的推理服务，它有自己的API、负载、限流策略和超时时间。只要你把组件画出来、把连接线画出来，群里的讨论就会从“模型怎么接”变成“这个服务由谁维护、QPS多少、挂了怎么办”。这个转变非常关键，它意味着团队从感性的技术讨论进入可执行的工程决策。
我自己踩过的坑是：曾经有一个项目，研发团队和算法团队花了三周做“多AI协作调度”，对接时才发现，算法提交的模型接口没有统一网关，后端只能直连，每次升级模型就要改代码。如果当时先画一张部署视图，把模型网关这一层补上，就不会走这段弯路。
1.2 架构图在什么时候最有用
很多人觉得架构图是“评审会交差用的”，实际恰恰相反。基于我的经验，有四类场景画图的收益最高。
第一是立项评审。新项目要不要用Agent？用几个模型？数据从哪来？这些问题在图上扫一眼就能看出是不是拍脑袋。第二是容量规划。每个节点的期望QPS、响应时间、Token消耗，在图上标清楚之后，估算成本和机器资源会容易很多。第三是故障复盘。线上出现超时或答案变差，把链路图拿出来，逐段排查比翻日志高效得多。第四是技术演进。比如从单体服务转向多Agent协作，从调用API转向私有化部署，架构图能提前暴露兼容性和数据流问题，避免重构到一半才发现链路是断的。
我个人的习惯是“先画图再写代码”。哪怕只是一个两周的Demo，我也会花半小时画一张组件图和一张部署图。这不是仪式感，而是在画的过程中，你会被迫回答“这里的数据从哪来”“这个服务依赖谁”“目标延时多少”这些问题。提前暴露问题，比上线后救火便宜太多。
2. 图解AI应用架构的核心组件：一张图先画这五层
2.1 交互层与应用层：用户看到的AI
想画AI应用架构，第一步不是画模型，而是画用户怎么接触这个系统。交互层负责的是用户输入和系统输出，典型形态有Web聊天框、IM机器人、移动端语音助手、自动化任务脚本等。这里有个容易忽略的点：交互层不只是UI，还包括输入校验、输出格式清洗、多模态数据的统一封装。
在架构图上，交互层要明确几个属性：支持什么输入类型（文本、图片、语音、文件）、采用什么传输协议（HTTP、WebSocket、gRPC）、是否需要流式返回。流式输出对体验影响巨大，用户问了一句五百字的问题，如果模型要跑三秒才一次性返回，体验会很差。走SSE流式返回，用户能看到逐字生成，体感延迟会降低一大截。这个细节在架构图上最好标注出来，否则后端很容易默认做成普通JSON接口。
应用层则更偏向业务逻辑。一个企业知识库助手，应用层要处理工单查询、规章制度检索、消息通知这些具体业务；一个代码生成工具，应用层要把IDE事件、代码上下文、模型输出串起来。画图的时候应用层通常是一个或多个服务，它调用编排层能力，同时把结果按业务规则加工后交给交互层。
交互层和应用层之间，我建议在图上明确画出“校验与护栏”这个节点。它的职责是：限制用户输入长度、过滤明显恶意内容、检测提示注入、校验模型输出格式。这不是可有可无的环节，而是AI应用工程化的基本底线。模型输出不可控，就必须靠这一层兜底。
2.2 编排层与Agent：AI的“大脑中枢”
编排层是整个AI应用架构里最值得花时间画的组件。在很多现代AI应用里，编排层由Agent承担。Agent和普通API调用最大的区别是：它不是“调用一次模型拿结果”，而是具备目标拆解、工具调用、多步推理、自我校验能力的循环过程。
画Agent相关节点时，先别急着画花哨的能力，我总结过一张图里至少要包括这4个东西：
- 规划模块：负责把用户目标拆成步骤或子任务
- 记忆模块：短期记忆（当前对话上下文）和长期记忆（向量库或结构化存储）
- 工具调用模块：能访问哪些外部API、函数、数据库，按什么JSON Schema传参
- 反思与校验模块：判断结果是否满足要求，不满足时重新生成或调用工具
多AI协作在架构图上表现为多个Agent节点之间通过事件或消息通信。常见的拓扑有两种：一种是“主从模式”，一个主Agent负责任务分配，多个子Agent分别调用不同工具，最后汇总；另一种是“流水线模式”，一个Agent处理完结果，把中间产物传给下一个Agent继续处理。画图时我会把Agent之间的通信方式标注清楚，是用HTTP同步调用，还是走消息队列异步流转。选同步还是异步，直接决定整套系统在高并发下的稳定性，异步削峰效果更好，但会增加最终一致性的复杂度。
2.3 模型层与推理层：能力上限所在
模型层是很多人最先想到的，但在架构图上它反而不是最复杂的节点。这一层做两件事：选什么模型、模型跑在哪里。
模型可以是外部大模型API，也可以是通过推理框架私有化部署的开源模型。私有化部署的开源模型现在很常见，比如Qwen、Llama、DeepSeek系列，但要跑得稳，绕不开推理框架和显存规划。这里有个非常粗略但实用的显存估算公式：
模型显存约等于“参数量×每个参数的字节数”。FP16精度下，每个参数约占2字节，所以一个7B模型光权重就约需14GB显存。再加上KV Cache、中间激活值和推理框架的预留，实际单卡建议选24GB以上显存。
我试过一个7B模型在4090上跑并发，如果batch size开得太高，显存很快被打满，响应时间反而恶化。所以在部署图的模型节点旁边，一定要标注“并发数上限、显存占用、目标P99延迟”这三个数值。
推理层还有一个容易被忽略的组件：模型网关。模型中转了多个模型时，网关负责路由、限流、重试、降级。比如按业务场景分流，简单问题走小模型，复杂推理走大模型；某一路API超时，网关自动切换到备用模型。架构图上的模型节点不应该直接裸露给上层服务，中间隔一层网关，整个系统的弹性和可维护性会好很多。
2.4 数据与知识层：容易被低估的底座
如果只能给AI应用架构选一个“决定成败”的层，我会选数据与知识层。模型能力再强，没有对的数据和知识入口，产出也会飘。
这一层通常包含：原始数据源、数据管道、文档解析与切分、向量化（Embedding）、向量数据库、检索与重排、缓存。在图上它们不能只画成一个写着“数据库”的圆柱，那样会掩盖很多工程细节。
我现在画RAG链路时，数据层会拆成两条线。离线线：原始文档经过格式解析、去重、按语义切分，然后批量生成向量，写入向量库，并记录版本号；在线线：用户查询向量化后从向量库召回候选文档，再用重排模型精排，取前N段作为上下文。为什么需要重排这一步？向量召回追求的是“别漏”，结果里会有不少噪声；重排追求的是“更准”，把真正对答案有帮助的片段顶到前面。两者各司其职。
向量数据库选型也是架构图上的关键决策点。轻量场景用pgvector（直接复用PostgreSQL，少一个组件），中大规模用Qdrant或Milvus，Redis Vector适合做缓存型检索，但别把它当成主力向量库。总之要根据数据量和召回QPS来选，而不是追新。
3. 怎么画一张真正能落地的AI应用架构图
3.1 画图前的四个问题，先想清楚边界
动笔之前，我会先问自己四个问题，想不清楚就先不画。
第一，系统边界在哪。哪些是大系统内部的组件，哪些是外部依赖？用户、第三方API、企业IM这些都必须明确画在边界外。第二，用户是谁。是终端用户还是企业员工？他们的使用频率、最大并发、可接受的响应时间是多少？这些非功能需求直接决定架构的形态。第三，哪些组件是可替换的。比如Embedding模型、主模型、向量库，这类组件迭代频率高，图上要清楚画出它们与其他组件的依赖关系，方便未来替换。第四，要画哪种视图。是逻辑组件图、部署物理图，还是数据流图？不同视图解决不同问题，别指望一张图画完所有东西。
这四个问题问完，其实你已经完成了大半架构思考。图只是把答案画出来而已。
3.2 分层、连线与标注：我常用的画图套路
经过多次尝试，我沉淀了一套比较顺手的画图顺序：
- 画最外层边界矩形，标注“内部系统”和“外部系统/用户”。先把所有不归你管的元素隔离在外部。
- 从左上角的用户节点开始，画第一条主链路：用户请求经过哪些组件，最终回到用户。这条主链路是整个架构图的主心骨。
- 再画支撑链路：比如RAG里的离线文档处理链路、日志监控链路、模型部署链路。它们不直接参与用户请求，但决定系统能不能长期运转。
- 给节点之间连线标注协议或数据格式，HTTP/REST、gRPC、WebSocket、异步消息。
- 在关键节点旁边标注量化指标：QPS、P99延迟、并发数、显存、模型名称、成本阈值。
- 用醒目的颜色标出风险和瓶颈区域，比如“这里未来可能要拆成独立服务”“这里依赖外部API不稳定”。
原则上，一张组件图的主节点不要超过15个，连线不要超过20条。超过之后图会失去沟通价值，这时候就应该拆分视图，而不是继续往上堆。把细节写进节点备注或文档，图上只留关键信息，这是我在很多团队推行后反馈最好的做法。
3.3 工具选型：从轻量到企业级的实测对比
画图工具的争议非常大，但工具真的没那么重要，重要的是团队能不能共同编辑、版本差异能不能评审。我用过不少，简单说下各家的感受。
draw.io（现在叫diagrams.net）免费、能和Git仓库很好配合，适合团队把架构图作为代码仓库的一部分管理，我用它做大多数架构图的落地。Excalidraw画风自然、上手极快，适合白板讨论和早期方案，但不适合作为长期维护的正式文档。Figma适合交互设计强的团队，能把UI流程图和系统架构图统一在同一画布上，但对后端同学来说学习成本偏高。ProcessOn是国内访问速度不错的在线工具，分享方便，模板也多。C4模型的方法论很值得学，它把架构图分成层层缩放的四个层次，也就是System Context、Container、Component、Code，这种“多视图分离”的思路放到AI应用里同样适用。
我个人的工作流是：先用Excalidraw或白板快速画草稿，讨论清楚组件和链路，再在draw.io里整理成正式版，放进仓库docs目录，同时导出一份PNG放到团队Wiki。这样既有讨论效率，又有长期沉淀，不会出现“架构图一张都没有”的失控局面。
4. 实战拆解：企业知识库问答系统的架构图解
4.1 需求与性能目标：先定量，再画图
拿一个具体的例子来走一遍。假设要给一家公司做内部知识库问答系统，员工通过企业IM或Web端提问，系统基于公司制度文档、项目文档、运维手册等资料给出答案，要求答案附上引用来源。
先定需求：资料总量大约2万篇文档，每天约5000次问答请求，高并发时段约50 QPS，用户可接受响应时间是5秒以内，首字返回越短越好。成本要求是单次问答的Token消耗要可估算、可控。
这些数字不是拍脑袋，它们决定了架构里要不要加缓存、要不要用小模型做路由、向量库需要扛多少并发。按50 QPS算，平均每条请求需检索一次向量库，一次重排，一次LLM生成，其中LLM生成往往是耗时大头。为了保证5秒内返回，我从一开始就把检索链路设计成异步并行：向量召回和重排并行执行，同时LLM预热连接复用。
4.2 端到端链路：从用户提问到答案返回
在这个案例里，我会画出三层核心链路。
主链路：用户通过IM或Web发送问题，请求先进API网关，做鉴权和限流；网关把请求转发给编排服务。编排服务先做两件事：判断意图（这个问题要不要走知识库，还是可以直接闲聊），以及判断要不要触发Agent工具。对于知识检索类问题，编排服务会调用检索Agent。
检索Agent的流程是：把用户原始问题送入Embedding模型生成查询向量；向量库按相似度召回Top20候选片段；重排模型对这20个候选按相关性精排，取Top5；这5段内容加上原始问题、系统提示词一起组装成大模型请求；大模型流式生成答案并附上引用编号。整个过程里，向量召回控制在30毫秒以内，重排控制在80毫秒以内，大模型首Token争取在1秒内，整体才有机会压进5秒。
质检Agent在拿到答案后做一次轻量校验：检查答案与引用片段是否一致、是否存在与问题无关的输出。如果质量不达标，系统可以选择重新生成或给出“暂不确定”的兜底回复。这里就是多AI协作的一个典型实践：两个Agent分工，一个主攻检索与生成，一个主攻校验与兜底，比单个Agent更可控。
支撑链路方面，离线文档管道每天从内部文档系统拉取增量文件，完成解析、切分、向量化、写入向量库，并打上版本号。这样图上就能清楚区分“用户在线问答”和“知识同步”两条数据流，它们互不阻塞，但都决定系统成效。
4.3 关键参数测算：并发、Token成本与响应时间
这个案例里，Token成本是最容易被忽视的陷阱。我通常会拿单个请求的平均Token数反推成本。假设每个请求平均输入包含：问题50 Token、系统提示200 Token、检索上下文1500 Token，输出平均300 Token。那么单次请求约消耗输入1750 Token，输出300 Token。
按市面上常见大模型API价格粗略估算，输入约每百万Token 1到2元，输出约每百万Token 5到8元。取一个中等偏保守的价格：输入1.5元/百万Token，输出6元/百万Token。那么单次请求成本约为：
输入成本：1750 / 1,000,000 × 1.5 = 0.002625元 输出成本：300 / 1,000,000 × 6 = 0.0018元 单次合计约0.0044元
如果完全不考虑缓存和降级，50 QPS跑满一天是432万次请求，单日Token成本接近1.9万元，这个数字会让绝大多数企业预算瞬间爆炸。当然实际场景不会每时每刻都满负荷，而且必须通过缓存和路由来压低成本，比如命中缓存直接返回、简单问题走廉价小模型、检索上下文动态裁剪。架构图上如果不标这些策略，评审时只看功能，上线后等成本的只能是你自己。
响应时间也要分层看。架构图上每一跳都要有预算：网关15毫秒，编排服务判断50毫秒，Embedding生成80毫秒，向量召回30毫秒，重排80毫秒，大模型首Token 1000到1500毫秒，整体串行很难达标。所以我会在编排层设计并行执行，把检索和重排与部分模型预处理重叠起来，这比单纯优化某一段更有效。
5. 画图踩坑实录：那些藏在架构图后面的问题
5.1 画着画着发现架构有问题的三种典型迹象
我经常在帮团队评审架构图时看到三类问题，这三类都能直接从图上判断出来。
第一种，模型节点被画得满天飞。同一个大模型被五六个服务直接调用，没有网关，没有统一凭证管理，没有限流。这种图说明系统的模型接入是“野路子”，一旦模型侧限流或价格上涨，所有服务一起遭殃。
第二种，数据流是断的。用户提问到答案返回的链路很清晰，但问到“知识多久更新一次”“模型版本怎么回滚”“日志存在哪”，图上找不到对应节点。画图的时候一定要顺着每条线走一遍，看数据从哪产生、流向哪、在哪里沉淀，断点就是未来出问题的地方。
第三种，所有节点都是方方正正的方框，没有任何性能指标。没有QPS、没有延迟、没有并发数。这种图画完基本没有决策价值，因为它不回答“这个架构扛不扛得住”的问题。至少在最容易出现瓶颈的节点上标注估算值。
就算是一张看起来正常的架构图，我也会额外问一句：这条链路上如果某个供应商API挂了，降级方案在哪？如果答案质量下降，怎么报警、怎么回滚到上一个模型版本？这些问题在图上没有答案，架构就不算闭环。
5.2 延迟、成本、稳定性：架构层面的排查清单
延迟超标的排查思路，是从最便宜的环节开始排除。先看有没有跨地域的网络调用，比如模型API在国外、数据库在另外的云，这会让基础延迟翻倍；再看向量召回有没有走索引、有没有全量扫描；然后看上下文是否被塞得太长，长度越大首Token越慢；最后才怀疑模型本身慢。很多时候不是模型慢，而是链路里不加Cache、不做并行。
成本失控的排查，逻辑是打开Token统计，按请求路径拆。哪条链路贡献了最大Token消耗，往往是检索上下文过长或输出太长。一个很实用的调整为：把固定系统提示词Count出来，能精简就精简；把检索TopK从10降到5，并对片段做截断；给输出长度做上限。另一个常用策略就是“模型分级路由”，日常问题走7B模型，复杂推理走大模型，成本能降一半以上，体验损失不明显。
稳定性问题的排查，重点看依赖和超时。外部模型API、向量库、文件解析服务都是潜在单点，没有熔断器和超时控制，一个小问题会被放大成全局雪崩。我强烈建议在架构图的服务节点上明确标注超时时间和重试次数，比如模型调用超时设2500毫秒，不重试或最多一次重试；向量库超时设200毫秒。有了这些数字，运维和研发就不会凭感觉调了。
5.3 架构图更新策略与团队协作
架构图最怕画完一张就再也不动。一个持续迭代的AI应用，两周后可能换了Embedding模型、加了缓存层、调整了Agent结构，如果图不更新，它就会从“事实”退化成“历史文档”，失去参考价值。
我们团队现在的做法是把架构图当作代码的一部分维护，放在仓库的docs/architecture目录下。每次技术方案变更评审时，必须同步更新对应视图并提交更新说明。CI里甚至可以加一条简单检查：架构文档的修改时间是否早于代码合并时间，如果代码合了很久架构图还没动，就提醒管理员更新。
另外我会在图上增加一个“变更记录”标注区，不是那种大段落，而是几行关键历史：什么时候加了模型网关、什么时候切换了向量库、什么时候缓存命中率调整到了什么水平。团队新人看这张图时，能快速理解现有架构是经过哪些决策演化来的，比自己翻代码问人要快得多。
6. 最后分享我的几个实践体会
6.1 一些值得长期坚持的画图习惯
我用了很长的绘图工作流之后，留下来几个固定习惯。先画主链路，再补支撑链路，最后才画监控和运维，这个顺序能避免一开始就陷入细节。每一张图都必须有“用户”和“边界”，没有用户的架构图通常是自嗨。关键节点标数字，QPS、延迟、显存、成本都要有估算值，哪怕一开始不确定，估算也比空白好。每张图配一个不超过十行的说明文档，写清楚“这张图回答什么问题”，免得讨论时发散。
还有一个我特别推荐的细节：在线路连线上标注“同步调用”还是“异步消息”。很多架构图只画箭头，不标调用方式，结果讨论静态结构时还可以，一聊到并发和故障，大家才发现理解的模型完全不一样。同步和异步在AI应用里体验差别极大，异步流转适合多Agent协作和重试机制，但也会带来最终一致性的问题，必须在图上明确。
6.2 给刚起步团队的建议
如果你现在刚要开始做AI应用或Agent系统，我的建议是不要一上来就设计一个包含五个Agent、十几个模型的宏大架构。第一天画图，只画三条线：用户的输入从哪里来，系统怎么处理，答案怎么回去。就这三条线，足够引导整个项目启动了。第二周再根据实际迭代加入模型网关、向量库、缓存、监控这些支撑节点。架构是长出来的，不是一开始规划出来的。
很多人觉得AI应用架构设计很难，核心是没有把问题落到图上。模型和Agent看起来复杂，但架构设计的方法论还是那套：分层、解耦、定指标、找瓶颈。把图画出来，AI应用的神秘感会少一半，而工程上的可控性会多一大截。我自己现在做新项目，第一件事依然会是打开绘图工具，把那个写着“用户”的方框放到画布左上角，然后顺着请求流走下去。
