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应用的竞争不是比谁的模型更强而是比谁的架构能更快、更稳、更省地承载用户需求。从来没有一个架构可以靠一次画图一劳永逸但一张好的架构图至少能确保每一次迭代都朝着正确的方向奔跑。