1. 为什么我们画的架构图总让人看不懂
上周有个老朋友把一张他团队画的AI应用架构图发给我，让我帮忙看看。图很大，分了八九层，从上到下分别是用户、网关、服务、模型、向量库、缓存、日志……箭头密密麻麻，一眼看过去像是某种电路板的微距照片。他说这图画了两个星期，改过十几版，结果给技术评审会上一放，合伙人只问了一句：“这个图我看完之后，不知道我们做的东西跟智谱、OpenAI的ChatGPT有什么区别？”
这个问题非常扎心，但不是他画得不好，而是他用错了画图的方法。传统软件的架构图，核心表达的是“模块之间的依赖和调用关系”；到了AI应用这里，架构图的使命完全变了，它要表达的是“人的意图如何被理解，模型在什么地方接管，又把什么结果交还给用户”。你看，这说的已经不是图的事，是一个完整架构设计逻辑的偏移。
如果你现在打开一个AI项目的白板，大概率所有人都在讨论模型选型、提示词怎么写、RAG的召回率有多高。但这里面最大的一个误区是：架构没有立住，所有局部优化最后都会变成无效努力。模型、提示词、检索、Agent，每个部件单独拿出来都有非常成熟的方案，但拼在一起之后，没有一张图能够帮助团队回答“为什么这个模块放在这里”“用户的一次请求到底经过了哪些环节”“哪个环节最脆弱、最贵”。这才是“图解AI应用架构设计”真正要做的事情。
这篇文章我想用我实际画过的架构、踩过的坑，来讲清楚三件事：AI应用架构图和传统架构图本质区别在哪里；一张实战级AI架构图应该有哪些必备组件，各自承担什么职责；以及你应该怎么一步步把图画出来，让不同背景的人都能一眼看懂。
2. 传统软件架构的“分层思维”，在这儿为什么卡壳了
2.1 分层架构的前提是确定性，而AI应用的命根子是不确定性
先聊聊传统软件。我刚开始写代码那些年，画架构图非常顺手，因为脑子里有一套固定的章法。前端、网关、业务层、数据库，七层也好五层也好，逻辑是确定的：请求进来，走哪条路由，调哪个接口，返回什么结构，全部写死在代码里。每一层是什么、干什么、谁调用谁，清清楚楚。画出来的图哪怕复杂，大家也能顺着箭头把一条请求从前到后理一遍。
AI应用打破了这个前提。一个用户说“帮我写个邮件回复客户的投诉”，模型究竟会不会输出你预期的那段文案？它今天可能回复得特别好，明天换个表述可能就离题万里。这中间没有确定的分支逻辑，只有概率。那这种不确定性应该画在哪一层？你会发现常规分层的格子根本装不下它，因为不确定性是横跨所有层的，从输入文本的解析开始，一直到最后的输出校验，每一环都有概率性的成分在里面。
这就是为什么很多人画AI架构图总觉得哪里怪怪的：你仍然在用确定性分层思维去表达一个确定性的流程，而这个流程本身是概率性的。于是图画出来非常像样，但失真。
2.2 “数据流图”和“决策流图”只能二选一？这个开关很多人没想明白
还有个常见的困惑是：架构图上到底应该画数据流还是决策流？传统系统里数据流和决策流通常是重叠的：请求带着参数进来，代码在该分支的地方做判断，然后往下走。但在AI应用里，数据流和决策流经常分叉。
举个我实际遇到的例子。我们做一个合同审查工具，用户上传一份PDF合同。数据流很简单：文件上传、解析、文本化、切片、向量化、存入向量库。但决策流呢？合同里有没有异常条款？这个判断是由模型完成的，可是“要不要让模型来判”，这是一个前置的决策。如果一份五页的小合同也走RAG检索再进大模型，那延迟和成本都压不住。我们最后单独做了一个轻量级分类模型，根据合同页数和文本密度，判断是否需要检索，还是直接甩给模型就看完了。
你看，数据流走的是文件路径，决策流走的是“谁来分析”的判断路径。两张流混在一张图里，画出来就是一团麻。架构设计的真正任务，其实是先分清“什么东西在流动”和“什么逻辑在做判断”，然后在图上用不同形态的线把它们分开。可惜大部分人画图的时候没有做这个区分，结果拿到评审会上被质疑的往往不是细节，而是整体逻辑。
3. 一张实战级AI应用架构图，至少要有六根柱子
3.1 模型出口与多模型路由：你的图里不该只有一个大模型
很多朋友画AI应用架构，直接就是一个图框写“大模型”三个字，完事。这是我看过最普遍的问题。真实生产里，大模型旁边必须有“路由”这个组件，否则性能和成本根本平衡不了。
一个现成的例子：同样是改写一段周报，旗舰模型的输出质量上限确实高，但用它处理“帮我改一下错别字”这种简单任务，就是杀鸡用牛刀。好的架构图应该画出两条路：一条走旗舰模型，给复杂推理；另一条走轻量级模型，给机械任务。路由这个框会做意图判定，根据请求复杂度把流量分发到不同出口。
画图的时候，模型层不要只画一个云服务商标，要画出口粒度。我当时做AI客服系统时，开头画的架构图里就一个大圈，后来拆成了“生成主模型 + 意图分类小模型 + 精简任务小模型”三个出口，路由画在最上面。那张图拿到后端团队面前，所有人第一反应是“哦，原来我们要部署不止一个模型”。如果没有把这一层拆开，很多人会默认架构上只需要接一个API，这是后面所有部署冲突的起点。
3.2 上下文工程区：这不是一个文件夹，是整个系统的心脏地带
接下来是最重要的部分——上下文工程区。很多架构图把提示词、向量检索、记忆当三条辅助线来处理，随便挂在模型边上。实际上它们应该被画成一个独立区域，我习惯叫它上下文工程区，标准的叫法是Context Engineering。
这里有一个我趟过的大坑。早期我们做行业问答AI，架构图画的是“用户输入→拼接系统提示词→调大模型”。图很简单，上线也能跑，但回答质量非常飘。后来排查发现，系统提示词里有很长的企业背景介绍，还有大量历史对话摘要，这些东西一股脑堆在上下文里，模型注意力被严重稀释。
后面架构图改成这样：上下文区域里分三格——静态指令（系统提示词，内容固定）、动态结果（从向量库里召回的知识片段，按相关性排序）、记忆槽（历史对话摘要，按时间衰减）。画完这张图的第二天，团队看问题的方式就变了：之前是“提示词写得不好，改提示词”，现在变成了“从召回结果里带进来的噪声太多，得调检索阈值”“记忆槽只有最后五轮，用户一周前说过什么根本记不住”。一个架构图的调整，直接改变了团队排查问题的视角，这个价值比什么图好看重要得多。
3.3 工具与插件边界：模型决定不了的事故，工具区要摊开说
再往下是工具层，也就是Function Calling、外部API这一坨。架构图上这一层最大的作用不是炫技术，而是明确一个边界：模型对什么事情只有建议权，什么事情有执行权。
我们项目里让AI助手去操作公司内部工单系统。架构图我故意把工具层画成单独的框，而且边上注了一句话：“工具执行前，必须经过网关校验参数。”画完之后安全团队主动来找我确认校验逻辑，这个在以前是根本不会发生的对话。
工具区还要画出失败语义。外部API超时了怎么办？返回什么给用户？这里一定要写清楚。很多AI应用出事，不是模型判断错了，而是工具执行得不对，系统还继续往下走，把错的结果包装成正确的结果返回用户。架构图上如果没有显式标注工具不可用时的降级路径，那就等于把地雷埋在了线上。
3.4 安全护栏与输出校验：不能只指望模型“良心发现”
AI应用的第四个关键区域，是安全护栏。一个绝对不能省略的框。
很多架构图把“内容安全”做成一个小角标，甚至根本不画。但真实运维里，模型输出是不可控的，没有精准的输入输出校验层，测试阶段可能好好的，上了一波奇怪的话术直接翻车。安全护栏不只指屏蔽敏感词，更核心的是“输出格式校验”和“行为边界校验”。
什么叫行为边界校验？系统提示词里告诉模型“不许用搜索工具查天气”，但如果用户绕弯子说“我明天去上海要带伞吗”，模型可能直接调用搜索工具。没有行为边界校验，这种问题就靠运气。架构图上这个框，需要画在模型出口和用户之间，必要时双保险：一边拦截异常输入，一边校验模型输出。
3.5 人机协同位置：所有图都绕不开“人在环上”四个字
第五个区域，“人在环上”。AI应用发展到现在，没有哪个严肃项目敢于声称全链路无人工介入。画架构图的时候，人机协同的位置不标清楚，后面上线一定会有伦理和运营上的双重麻烦。
比如我们做智能审核助手，架构图里凸显一条规则：所有对外发布的审核结果，必须经过人工抽检，置信度低于阈值的自动转人工。这张图画完，业务方、研发、测试终于在一个频道上了：谁对最终结果负责，图上一眼就能看出来。而初始版本没画清楚，研发觉得自己写了个完美系统，业务方担心砸了自己的招牌，两边都对但就是交流不下去。
3.6 成本与延迟标识：这些数字不写上去，图就是一张概念画
最后一根柱子，是成本与延迟标识。很多人画的架构图像教室里的结构示意图，节点和箭头一个个都很规范，就是没有任何数字。生产级架构图不是这样的，它至少要在关键路径上标注预期延迟、在模型节点标注单次调用成本。
我之前帮一个创业团队评审架构，他们的图很完整，但我指着模型的框问：一次普通请求大概多少钱？他们愣了，说没算过。我当场打开他们选的模型的定价页面大致算了一下：假设每天一万次请求，其中八成都走旗舰模型，一天的模型调用成本就好几百。对创业团队来说这个数字足够改变技术选型。没有这个数字，架构图只能算示意图，不能拿来做决策。
4. 从空白画布开始，一步步把AI应用架构画出来
4.1 第一步：锁死场景和用户角色，这决定了图的边界和层次
说了这么多组件，具体落笔时怎么开始？我建议先从确定边界开始。拿一张白板，画出场景范围和用户角色。你可以把自己当导演，开拍前先看剧本是发生在哪间屋子、有哪些人物。
比如你做一个面向中小企业HR的简历筛选助手，那场景就是“HR上传简历→AI提取候选人亮点→HR筛选→发起面试邀请”。用户角色只有HR一个。别把求职者也画进来，阶段不同、权限不同，场景全混进去图就没法看。
边界一定是刻意缩小的。当时我们做合同审查，开始恨不得把“合同全生命周期管理”都画进去，后来切成一次审查、一个环节，图上每个节点都变得有实际指涉，不再是为了占格子而存在。
4.2 第二步：画三张草图，比反复修改一张详图有效得多
正式动笔前，先用三张草图做快速探索。这三张各代表一种架构形态，我常用的组合是：
- 直通型：用户输入直接进大模型，输出返回。这是最简单的，也是MVP最喜欢用的。
- 路由型：输入先进行意图判断，再分流到不同模型或知识库。
- 协作型：多个Agent分工协作，各自有工具，输出汇聚后再进入下一个阶段。
这三张图不要画得太细，粗线条、半小时搞定。它们的核心作用是让参与架构讨论的人在“到底选哪种形态”上达成初步共识，而不是一上来就陷入“向量库要不要加缓存”这种细节。
直通型适合什么？适用于需求明确、对性能压力不大的内部工具。路由型适合大多数对外产品：意图判断先行，简单任务走小模型，复杂任务走旗舰模型。协作型适合流程复杂、需要拆解的任务链，但它对系统可靠性的要求会上一个等级。
4.3 第三步：从关键路径开始填充，把细枝末节全部扣掉
选完形态，现在才开始真正画图。这时候有人会打开Visio或者draw.io，开始画边框、拉箭头。我的建议是先从关键路径画起：用户发出请求，这个请求经历的第一个组件是什么，往下走会遇到什么，最后怎么把结果送回来。
关键路径画完，再往旁边加分支。比如知识检索，不是每次请求都需要走的，只在部分场景触发，那它就应该画成旁路，而不是画在最粗的主线上。这一条特别重要：架构图的可读性，取决于你是否有勇气把很多有必要的组件摆到次要位置。
当时我们给智能客服画图，团队最初版本把所有旁路功能全部画成等宽的大框，连“日志清理任务”都占了很大空间。我第一刀就是把这些功能砍一半留一半，放到底部工具区。新同学看图的反应完全不同，他们一眼抓住了主链路，想了解细节的时候再往下面翻，层次感就出来了。
4.4 第四步：给关键的箭头和数据流，老老实实写上载体和频率
画完节点，剩下的工作就是标数据流。但这里有个细节，很多人把箭头画出来就认为自己表达清楚了。其实没有，箭头至少需要附带两个信息：数据通过什么形式流动、流动的频率级别。
这个怎么标？举个例子，“用户输入→意图路由”这条线，旁边可以标“JSON，每请求一次”，“向量库→上下文拼装”这条线，可以标“Top-K召回，每请求0到8段”。标完这些，整个系统的负载画像就浮出了。
有一次我给别人做架构评审，看到一个“定时任务→模型总结”的箭头，我问了一个很基础的问题：这个任务是每分钟跑一次还是每天跑一次？对方说每天，我算了一下，每天调模型1440次和1次，成本差了三个数量级。不标频率的架构图，等于没标成本，等于没法决策。这个习惯值得养成：每个数据流写清楚载体和频次，会逼着所有人把模糊的架构讨论变成可计算的工程决策。
5. 为什么你的架构图仍然在评审会上被打回：三个致命短板
5.1 图里全是组件，没有“失败语义”
我发现一个高发问题：绝大多数架构图只画了成功路径，没画失败路径。系统不会永远成功的。模型可能超时、向量库可能连不上、外部工具可能宕机。
传统架构图我们习惯把失败处理画在各种“异常分支”，而在AI应用架构图里，失败语义应该直接写在关键组件上。比如模型调用这个节点旁边，写清楚“失败后降级：返回标准话术并发告警”和“失败后重试：最多两次，指数退避”。每个关键组件都能回答“你挂了怎么办”这个问题，架构图才算是能扛事的图。
5.2 图里没有“观察性”的概念：谁在看这个系统？
还有一个经常被忽略：可观测性。系统跑起来之后，总得知道每个环节的调用量、延迟、成本、异常率。架构图上要有观测数据流，它不是实时业务数据的一部分，但它是从各个组件向外输出的一段元数据。
有个非常经典的场景：AI客服上线之后，要追踪“意图路由分发到小模型”的比例是否合理。如果没有可观测设计，这个数据根本采集不到，你想调优路由的权重都没有依据。我在架构图里一般会在最底部画一条虚线，把所有组件连到一个名“日志/指标/追踪”的框。这条虚线看似多余，但在上线后救了我很多次。
比如模型在加班高峰期突然变慢，如果不是图上提前准备了指标来源，团队根本不知道是该扩容模型网关，还是模型供应商那边的问题，还是上下文拼装环节太慢。可观测不是加不加的问题，是加在哪个位置的问题。
5.3 图里没有版本演进的空间，画成一潭死水
最后，很多架构图画完就当成“最终稿”存档了，这是一个非常严重的误判。AI应用的架构是高度迭代的，你可能过了两周就要把路由规则调整一下、把记忆机制增强一下、把某个Agent拆成两个。一张架构图应该像你代码仓库里的文件一样，有版本号，有改动日期，有负责维护的人。
我当时推进过一个原则：架构图必须跟着项目里程碑一起更新，每次上线新功能，架构图同步更新，并且在图下方标注版本变更记录。谁说“图已经画完了”这种话，团队就会问一句：那你功能迭代完不更新图，三个月之后新人来了看什么？这个图不叫最终稿，它叫当前稿。如果你希望它有价值，就得让它一直活在项目演进的过程里。
6. 两种真实场景的架构图拆解：“客服助手”和“代码评审Bot”
6.1 客服助手的图：取舍目标是“省钱”和“不被客户骂”
客服助手是我做过很多次的场景，它的架构图体现的核心策略是“分层分流”。用户的每条消息进来后，先经过意图路由判断一下：这个问题是常见FAQ、流程咨询，还是投诉、需要人工介入。简单任务直接走轻量模型，配合与预设的FAQ向量库做个快速检索就行；只有复杂任务才进大模型，让它提取情绪和意图，再生成回复方案。
这个图的关键点在于：模型输出之后，必须经过一个“置信度评估”环节。模型自己说“我很确定”不算数，我们要设定规则，多少分以下必须转人工，并且客服工作台会自动弹窗提醒。架构图上要把这条线画得非常粗：转人工不是一个灰溜溜的操作，而是系统设计里最高优先级的安全通道。
做客服架构时成本上千元一天的教训让我明白，图纸上没有标注成本分层，等量冲到一定量级，老板看到账单会非常痛苦。客服场景的架构图如果你只标一个优雅的模型调用链不标分流，账面根本扛不住。所以客服架构图的灵魂，就是“利用分层分流策略，实现成本与体验的平衡”。
6.2 代码评审Bot的图：取舍目标是“可信”和“不误报”
代码评审Bot和图又不一样。这个场景最大的矛盾是：AI提供代码审查建议不难，难的是开发和团队凭什么信任它。如果AI每十条建议里有两条是误报，整个系统信任感就崩塌了。
所以代码评审Bot的架构图，人机协同位置必须非常显眼。我的设计是这样：代码提交事件触发→拉取代码差异→调用模型做静态缺陷识别和风格分析→输出问题列表和严重程度分级→进人工复核队列。架构图最底部标注一条硬规则：严重级别高的建议，必须经过至少一名资深工程师确认后才能推送给提交者，模型输出本身不自动生效。
模型在这里不具备“下结论”的资格，它只负责“发现问题”。架构图画清楚这条线之后，产品、研发、测试三方的预期就对齐了。后续在运维中团队提出不如“让模型直接帮我们标记高危问题”，但看架构图我一句话就说服了对方：那条“人工确认”链路就是我们最大的信任资产，砍掉它省了人工，失了信用。
7. 架构图推进的节奏把握：从单体到多Agent的路该怎么走
7.1 起步期：宁可粗、不可乱，单体结构是最好的谈判起点
不要第一版架构图就上来画四个Agent，五个知识库。起步阶段，单体结构的直通型架构往往是最合适的：一个模型，一个提示词，一个输出。图画出来像一个水龙头：用户进来，流水出来。
单体结构的好处是可控性极高。技术选型、成本计算、故障排查都简单。而且单体阶段的架构图是最好的“谈判起点”：面对老板你不必解释Agent是怎么协作的，面对投资人你直接演示产品价值即可。很多团队一上来就堆复杂架构，直播翻车的多，真正的核心功能连原型都没跑通，复杂度倒是先建立起来了。
7.2 扩展期：先加路由，再加记忆，最后再上多Agent
当单体结构跑通，你才有资格考虑扩展。我建议的扩展顺序是：先加路由，再加记忆，最后才考虑多Agent。这个顺序来自一条很朴素的原则：哪个组件带来的确定性收益最大，就先加哪个。
路由解决了“什么请求该走什么模型”的问题，收益立竿见影，成本下降、性能上升。记忆解决了“用户连续对话的语境保持”问题，体验会明显变好。多Agent是最后一个选项，因为它带来的不确定性和运维复杂度最高，只有在路由和记忆都无法满足业务需求时再考虑。很多团队反着来，一上来就整多Agent协作，成本烧得飞快，稳定性和效果却迟迟跟不上，最后把Agent这个词都快做成了贬义词。
7.3 成熟期：架构治理不是写在文档里的，是画在图上的
当系统进入成熟期，架构图开始承担治理职能。它不只是一张供人浏览的图，还是一份所有人都必须遵守的“契约”。
我自己比较推崇把架构图的改动和权限绑定：任何涉及到数据流、模型出口、安全护栏的改动，都需要走架构评审，图必须同步更新。这个机制听起来像行政管理，但它真正保护的是研发效率。因为AI应用太容易“东改一个提示词、西改一个阈值”了，没有架构治理，三个月后系统变成一个谁也说不清的黑盒子。架构图就是那个让失控过程能随时被定位的锚点。
8. 画一张能帮团队做对决策的图，这三个习惯最重要
最后分享三个我个人的实操习惯，都是吃过亏换回来的。
第一个习惯：画图用的是“决策视角”，不是“实现视角”。所谓决策视角，就是每画一个节点都要问自己“这笔有什么可决策的？是成本、延迟、准确率还是安全？”如果这个节点不存在任何需要权衡的决策，它很可能就不配出现在主架构图上。影响决策的组件放主屏，纯实现细节扔进附录即可。
第二个习惯：注释语言统一用“如果……那么……”的句式。比如“如果意图路由置信度低于0.6，那么转人工”“如果工具调用超时，那么降级为告知用户稍后重试”。这种句式强迫你把架构图里模糊的逻辑判断显式写出来，看起来可能很啰嗦，但比画一堆看不懂的图例有用得多。
第三个习惯：每个季度把架构图翻出来做一次“复盘压力测试”。故意问自己：如果这个月模型调用量翻十倍，图上哪个模块会先崩？如果主模型要换供应商，哪些节点会受影响？拿这些问题反复测图，测出来的代价就是团队的下一次优化方向。架构图不能是静态的，它必须陪着系统一起呼吸。
我个人实际带团队的经验是，现在AI应用的竞争不是比谁的模型更强，而是比谁的架构能更快、更稳、更省地承载用户需求。从来没有一个架构可以靠一次画图一劳永逸，但一张好的架构图，至少能确保每一次迭代都朝着正确的方向奔跑。