1. 图解不是画流程图架构设计为什么需要“图”1.1 我踩过的“图不对文”的坑先说一个我自己的真实经历。前两年做企业内部AI助手的时候需求文档写了好几版技术方案评审的时候开发、产品、算法三方各拿一份文档各说各话。开发说“这里走队列异步”产品问“那用户多久能看到结果”算法说“模型返回格式不一定”三方在会议室僵了快一个小时。后来我把方案画成一张图——从用户输入到鉴权到模型调用到知识库检索再到结果解析回传每个环节的入参出参标清楚、超时和失败分支标清楚会议十分钟结束后面开发全程按图施工。这件事给我一个很深的印象AI应用架构设计最核心的问题不是“用什么模型”而是“怎么把模型放对位置”。而位置这件事用文字说不清楚只能靠图画。图解AI应用架构设计本质上是用一种可讨论、可评审、可演进的方式把一个充满不确定性的系统变成一张大家都能看懂的协作地图。1.2 一张好图必须具备的三个层次很多新手画架构图画出来的其实是一张“组件堆叠图”——把模型、数据库、缓存、消息队列画在一张画布上用箭头连起来就称之为架构。这种图的问题在于它只能回答“有什么”回答不了“怎么跑”更回答不了“挂了怎么办”。我自己的习惯是把一套AI应用的架构图拆成三个层次去看。第一层是静态结构回答“系统由哪些部分组成”。这一层要标清楚组件、模块、外部依赖以及它们之间的连接关系。对AI应用来说这里至少要包含模型服务或模型API、应用服务、数据存储业务库与向量库、外部工具调用等几个基本要素。第二层是动态时序回答“一次请求是怎么流转的”。这一层是AI应用架构跟传统Web应用差异最大的地方。传统Web的请求链基本固定但AI应用的请求会走到模型调用模型可能去调工具、查知识库、多轮反问甚至多个Agent之间协作链路是动态的。这一层画不清楚开发就只能靠猜。第三层是运行视角回答“系统怎么保障稳定与质量”。包括超时、重试、限流、降级、缓存、审计这些横切关注点。AI应用尤其要重视这一层因为模型推理的延迟方差很大、输出不可控、成本也高架构图上不体现这些系统上线后必然出问题。三层图对应三个不同角色静态结构图给后端开发和运维看动态时序图给算法和联调测试看运行视角图给SRE和负责人看。一张图全兼容是不可能的但基于同一个系统拆成三个视图就能让每个角色都找到自己需要的信息。1.3 画图工具与图示语法选型工具方面我实测下来最顺手的是Draw.io现在叫Diagrams.net免费、支持中文、能导出SVG和XML配合Git做版本管理很舒服。复杂一点可以用Figma或专业绘图工具但团队协作场景下我倾向于用能嵌入代码仓库的工具这样架构图跟着代码评审走不会出现“文档里的架构早过期了”的情况。图示语法上很多人一上手就想着用标准UML结果把自己框死了。我推荐的做法是混合使用系统架构图用简单的方框实线箭头强调模块边界请求链路用类似时序图的画法但不用严格UML的格式状态流转用状态机图但只画出核心状态不追求完整覆盖。核心原则是让读者在十秒内看懂主链路而不是让读者花十分钟研究图例。2. AI应用架构的分层从模型到用户价值的四个横切面2.1 接入层统一入口与多端适配任何AI应用的第一层都是接入层。这个层面要做的事情跟传统Web网关差不多——身份认证、限流、协议转换、参数校验——但有一个AI应用特有的痛点请求的格式和返回格式都很不稳定。用户可能在对话框里输入一句话也可能上传一份PDF、一张图片模型可能返回纯文本也可能返回JSON、Markdown、甚至一段可直接执行的代码。所以接入层的一个关键设计是把AI的输入和输出做标准化封装。输入侧统一解析成“消息附件上下文”的结构输出侧解析成“内容结构化元数据操作指令”的结构。这样上层业务才不会被模型的输出格式绑架。我自己见过不少项目因为没做这层封装业务代码里到处是解析模型输出的临时逻辑换个模型就碎一地。接入层还要承担一个容易被忽略的职责多模型路由。同一个应用可能需要不同模型处理不同类型的问题比如简单闲聊走轻量模型复杂推理走更强模型。这个路由决策最好放在接入层做而不是让上层业务代码自己选。2.2 智能层模型调用与Agent编排智能层是整个AI应用的心脏。这一层如果只是简单地封装一下模型API那其实没什么架构可言。真正的架构设计难点在于调用方式的选择一次请求是直接调模型还是需要走“规划-调用工具-观察结果-再规划”的循环是单模型单轮搞定还是多个模型协作我的经验是先从最简单的直接调用看能不能解决业务问题不要一上来就上Agent框架。很多实际场景一个设计良好的提示词加上带few-shot的示例效果比强行上ReAct框架要稳定得多、成本也低得多。等到需要读外部数据、操作外部系统、多步推理的时候再引入工具调用和Agent编排也不迟。智能层的第二个难点是上下文管理。模型的上下文窗口是有限资源你在图里必须明确标出“当前请求携带了哪些上下文”“这些上下文从哪来”“超出窗口之后怎么截断”。上下文管理直接关系到回答质量和成本架构评审时这是必问的问题。还有一个常被忽视的点智能层要有降级策略。模型服务随时可能超时、限流、返回异常架构图上必须画出一条“模型挂了之后走什么逻辑”的路径。最简单的降级是返回兜底文案好一点的是切到备用模型再好一点是缓存相似问题的历史答案。别等线上炸了才想降级方案。2.3 业务与数据层更核心的其实是人说完模型再往下看业务逻辑这层承担着把模型输出落地为具体业务动作的职责。比如一个AI客服模型判断用户要退款之后业务层需要调用订单服务执行退款流程一个AI写作助手模型生成文本后业务层需要做敏感词过滤、排版、保存草稿。没有业务层的约束模型给的只是“内容”而不是“结果”。数据层是另一个关键领域。AI应用的数据通常分成几类一是业务数据存在传统的关系型数据库或业务系统的API里二是知识数据存在向量数据库里用于检索增强三是会话数据记录用户历史交互。这三类数据在图里要分清楚因为它们有不同的生命周期、不同的访问模式、不同的治理要求。这里说一个容易被忽略的治理问题AI应用的每个请求都在产生数据这些数据既包含用户隐私也包含模型输入输出。架构设计阶段就要明确数据的保留期限、脱敏规则、谁的合规团队负责审核。我见过不止一个项目模型效果做得很好但因为数据留存不合规上线被卡住这完全是可以提前规避的。3. 从静态到动态Agent与多AI协作的架构表达3.1 Agent的静态角色划分随着“AI Agent”这几年成为热词很多团队开始设计Agent架构。但Agent是什么我偏好的定义是Agent是一个能独立完成目标导向任务的闭环系统它至少包含“感知输入—规划步骤—调用工具—审视结果”这串基本循环。在静态图上我会把Agent画成三个核心子模块记忆模块负责短期会话记忆和长期知识记忆、规划模块负责拆解任务、决定下一步动作、工具执行模块负责实际调用外部系统或API。这三个模块通过一个内部总线连接模型的角色是大脑但大脑不能凭空做事需要记忆和工具配合。静态图上还要标清楚Agent之间谁主谁从。很多团队一上来就设计一堆Agent主管Agent、执行Agent、审核Agent、翻译Agent看起来分工明确实际跑起来发现上下文流转混乱、成本翻倍。我强烈建议从单Agent工具的架构起步只有在明确需要专业化分工、并且你画得出每一步的消息流转时才考虑多Agent协作。3.2 多Agent协作的时序图怎么画多Agent协作的时序是整个AI应用架构图中最容易画乱的部分。原因在于Agent的下一步动作经常依赖模型推理结果而模型推理结果不可预知。你没法像传统时序图那样把每一步都画死必须留出分支和回环。我的做法是时序图不画“所有可能的路径”而是画“一条最典型的主路径若干关键异常路径”。主路径用连线说明消息顺序比如“User - 主管Agent - 执行Agent - 工具 - 执行Agent - 主管Agent - User”。异常路径单独列表说明比如“工具调用失败后执行Agent是否重试还是直接上报给主管”这样画图面干净评审时也容易聚焦。多Agent协作的另一个设计要点是共享上下文协议。不同Agent之间传递的到底是什么建议在设计阶段就约定一个统一的上下文对象格式包含任务目标、已有发现、约束条件、日志链路等字段。否则Agent之间传话靠“塞进系统提示词”最后任何一个Agent状态回溯都不可能。3.3 避免“蜘蛛网”闭环与回路的边界控制画多了Agent架构图之后很容易画成一张蜘蛛网——每个Agent都跟其他所有Agent相连每两个模块之间有箭线图面混乱到无法评审。这种图暴露出一个真实的设计问题模块之间的耦合过高。控制Agent之间连接的密度有个好用的原则信息通过数据总线流动不通过Agent之间的直接调用流动。也就是说Agent A产生的结果写入共享内存或消息队列Agent B按需订阅或查询而不是A直接调用B。这样架构图会变成星型结构和总线结构而不是蜘蛛网。执行效率上可能略有损失但换来的是可维护性和可观测性的巨大提升。我实测过用消息总线串起多个Agent之后出问题时的排查速度快了很多。因为每个Agent只跟总线交互只要监控总线里的消息流就能定位是哪一步断了、哪一步卡住了。这一点在AI系统里尤其重要——模型输出天然不稳定你必须在架构层面提供一个稳定的排查锚点。4. 模型部署与服务化架构图必须回答的成本问题4.1 部署选型的一个对比模型部署方式的选择是AI应用架构设计里最影响后续成本与迭代速度的决策。三种主流方案各有利弊很难一概而论哪种最好部署方案适用场景优点主要风险直接调用商业API快速验证、非核心场景零运维成本、上手快数据出域、QPS受限于供应商限额、单价随调用量上升私有化部署开源模型数据敏感、高频调用数据内部闭环、单次调用边际成本低需要GPU资源与运维能力、模型能力有上限混合架构核心高频长尾低频并存兼顾成本与质量路由与稳定性设计复杂、双链路都要维护架构图上一个值得认真画的部分是模型路由策略。它的目标是用低成本路径处理简单请求用最合适路径处理复杂请求。我见过一个项目两条模型链路共用一个入口先请求轻量模型并附带一个“置信度评分”低于阈值才升级到重量模型整体成本降了将近一半用户体验几乎没劣化。这类逻辑必须画进架构图否则开发联调的时候根本不知道“为什么有的请求快、有的请求慢”。4.2 服务化改造网关、队列与缓存模型能力设计好之后还需要把它容器化后再作为微服务接入业务系统。这第一步里最容易踩的坑是把模型服务当成一个大单体所有上游业务直接调它。正确的做法是给模型服务套一个独立的模型网关层统一处理三件事鉴权、限流、路由。限流尤其值得注意。模型推理是计算密集型操作压垮GPU的方法之一就是突发流量。在模型网关落地一个“令牌桶限流排队机制”能有效避免把后端推理服务打崩。另有队列机制也很实用对非实时场景如离线批量文档解析建议直接把请求写入消息队列由消费端按真实推理吞吐能力慢慢处理而不是同步等待模型返回。图中完全可以直接标出同步调用和异步消息队列两种路径分开走。缓存策略也是必须画的。模型输出具有不确定性看起来完全不能缓存但实际很多场景中相似的输入可以复用相似输出。最简单的是结果缓存对完全相同的请求直接返回历史结果进阶一点的是检索缓存在RAG链路里把知识检索结果缓存下来向量查询的耗时和成本远低于模型推理但缓存后的响应速度提升非常明显。4.3 资源规划与成本估算架构图上每多一条链路背后都是真金白银。我经常看到团队做完架构设计模型效果不错但一算每天GPU成本傻眼了。原因在于架构图里没有做成本标注。估算成本其实不复杂这里用一个简化的例子说明关键算法思路。假设你用的是按Token计费的商业模型API项目中用户平均每次请求约2000个输入Token500个输出Token目标并发量是日均1万次请求。单次请求成本大约是(2000500) × 单价假如单价为每百万Token 20元单次消耗约0.05元日成本约500元月成本约1.5万元。如果换成私有化部署需要根据QPS和模型规模估算GPU显存与用量再除以有效利用率去平摊折旧。两种方案在不同调用量下有完全不同的经济性架构设计时就得先做这个判断。更值得画进图里的是成本控制开关是否对所有请求做日志全量留存、是否每次都带全量知识库片段到上下文、是否启用了多轮反思机制这些功能点一个个垒起来Token消耗会成倍放大。这里的取舍必须在架构评审阶段面对而不是等月底账单出来再“优化”。5. RAG链路与上下文工程数据流层面的架构设计5.1 RAG链路的标准画法RAG检索增强生成是当前AI应用里最主流的架构模式它解决的问题是模型不会知道你的私有数据但你可以把私有数据“喂”给它。喂的方式不是把所有数据塞进上下文而是先检索再拼接。这条链路的架构图画法熟练之后基本是固定套路用户请求 → 查询改写 → 向量化 → 向量检索 → 结果重排 → 拼装上下文 → 模型生成 → 输出校验很多团队在画这条链路时把整个流程画成一串从起点到终点的直线。但在实际系统里这里每两个环节之间都是一个返回点。举个例子查询改写环节不一定要用模型改写如果用户输入本身已经清晰直接走原文向量化即可。再比如检索如果召回为空系统可以直接给一个“没有答案”的兜底响应不需要硬走生成环节。因此在图里一定要画清楚分支与条件而不是一条直线走到底。5.2 上下文窗口与信息密度的权衡任何RAG链路的核心瓶颈都是上下文窗口的有限容量。就算现在的大模型普遍支持百万级Token上下文你把检索到的所有文档都塞进去效果也不会更好——信息密度过低时模型容易被噪声带偏。这就是为什么“重排”环节在RAG架构里这么重要先粗召回几百段再用重排模型精筛出最相关的三五段保证塞进上下文的是高价值信息。这里我分享一个具体案例。我们曾经做一个企业知识库问答系统最初召回就直接按向量相似度取Top10拼进上下文模型回答经常“答非所问”因为10段里有两三段是不相关但向量距离近的旧文档。加入重排环节后从Top50里重排取Top5回答准确率明显提升Token成本反而降下来了。这说明架构取舍一定要配套实际评测不能凭感觉。从成本角度还要在架构图上标清楚“上下文组织”的逻辑。比如历史会话压缩多轮对话场景下逐轮把新问题与历史摘要关联而不是把完整聊天记录全量塞进上下文。从“全量会话”改为“摘要最近对话”之后实测能大幅降低Token消耗同时多轮追问的效果也能维持住。5.3 数据流上的监控点与瓶颈定位RAG链路相对于简单的单模型调用最大的问题就是链路长了每一环都可能成为瓶颈。架构设计阶段就应该在数据流的关键节点落好监控点。我自己的习惯是至少监控四个指标查询改写耗时、向量检索耗时并行/串行排名、模型生成首字延迟、整链路总耗时和成功率。另一个经常被忽略的监控项是空回答率。很多RAG系统的知识库并不完整用户问的内容根本没有被召回模型只能编造答案。空回答率过高说明知识库覆盖有问题靠调整提示词无法根治。把这个指标反映到架构图的反馈环里知识库运营团队才会认真去做内容补充与更新。6. 安全与合规必须画进架构图的两个框6.1 内容安全不是只靠模型自带能力模型训练时通常做了对齐不会回答明显违法或有害的内容但业务场景下的安全问题远比这个更复杂。由于上下文注入攻击的存在用户精心构造的输入可能诱导模型执行危险指令系统自己拼接的外部知识库文档也可能掺入恶意文本。因此架构设计里必须画一个独立的内容安全组件在模型输入前和输出后进行双向检查。安全网关层面建议做到三层过滤第一层是基础词表与规则引擎处理明显的违规内容和通用风险信号第二层是分类模型检测处理语义层面的有害内容第三层是业务自定义策略比如某些场景下限制模型谈论特定话题。这三层全部通过后内容才会流向对话对用户输出。6.2 权限模型与租户隔离企业级AI应用里权限设计是绕不开的主题。最常见的错误是认为“模型不知道权限所以权限只能靠业务层控制”。这句话对了一半模型确实不理解你的RBAC权限体系但架构设计里可以在两个层面同时做权限控制。第一层是数据访问控制在RAG检索阶段先根据当前用户的身份和角色过滤知识库文档只检索他权限范围内的内容。第二层是回答内容校验模型生成答案后有个模块做“服务端权限复核”例如检测回答中是否包含了用户无权访问的信息或具体条目。两层都过了才算一个完整的权限闭环。多租户场景还要注意向量库的隔离方案。最稳妥是每个租户独立一个Collection其次是在一个Collection里加租户字段做过滤但检索召回时容易因向量近邻导致数据交叉。做AI应用架构评审的时候建议直接追问一句租户A的用户有没有可能通过RAG检索到租户B的知识片段。6.3 审计链路AI应用的审计日志比传统应用更复杂因为它既要记录业务操作也要追溯模型的关键决策依据。建议在架构图上单独画一个审计服务接住三类事件应用层记录“用户做了什么”、智能层记录“模型收到了什么上下文、输出了什么结果”、服务层记录“系统调用了哪些工具、命中哪些策略”。三类事件用统一的traceID串联这样上线之后的每次争议都能完整回溯。关于审计数据的流转我的建议是原始日志只作为合规基石完成脱敏与聚合后进入分析系统做质量评估而从分析系统得出的规律、案例、混淆样本再回流到系统做针对性优化改进。整个闭环必须在架构设计阶段定义清楚否则等功能上线恶意事件已经发生了日志却残缺不全。7. 质量保障与评估让架构图支撑反馈闭环7.1 评测集没有评估就没有优化很多AI应用团队有一个通病模型接入很快但上线后只能靠用户反馈来发现问题。这远远不够架构里必须要有一个评测模块提前把质量门槛立起来。我建议准备三类评测集标准集覆盖高频业务场景用于版本回归对抗集主动测试系统在恶意输入、模糊指令、情绪化表达下的表现边界集覆盖极端与长尾场景比如超长文本、空输入、多语言混合。三类评测集的数据配比根据业务风险确定风险高的场景加大对抗集比例。7.2 灰度发布与影子评测架构图上模型版本上线不能走“替换”路径而要走“影子对比”路径。具体做法是新模型与旧模型同时接收线上真实请求但新模型的输出写入日志不直接影响用户。经过一段时间的对比分析确认新版本在核心指标上不劣于旧版本再把流量切过去。这个过程在架构设计里要画出两条支路和“版本比对”模块没有这张图开发很可能就把升级做成了覆盖。这里有一个教训用旧逻辑执行“一次一票”的硬对比在很多场景下会误判。比如新模型回答质量可能更高但更多地把“拒绝回答”换成了“委婉引导”这也是一种改进。所以影子评测不仅要对比“对错”还要业务方参与人工打分配套在评测维度里。7.3 线上可观测性与持续迭代机制架构图接近完工时要明确线上监控面板的设计维度。除了可用性这类常规技术指标AI应用还需要关注质量指标与业务指标的关联。举几个具体例子用户追问率的高低反映了首答是否解决问题用户纠错按钮的点击次数展示了模型回答的实际接受度从切换到人工坐席的比例大小反映出AI服务上限。这些业务指标比单看准确率更贴近真实体验架构设计时必须预留事件上报点。持续迭代机制也要画进图里。线上收集到的低质量案例、用户投诉、评测失败的样本应该自动或半自动沉淀为“待标注数据集”经人工标注后扩充到评测集和微调数据池。这套反馈机制应该是一个显式的回路结构。每轮模型优化的目标来自线上数据新模型又经评测集评估后再进入影子评测形成一个可重复的迭代循环。架构图如果画成了单向的流水线说明设计还没到位。8. 实例复盘一个客服Agent的架构图解全过程8.1 需求拆解与边界确定用一个实际落地过的例子来串一下前面的所有概念。项目背景是一个电商客服Agent目标是在人工客服下班时段自动处理售后咨询。需求文档很长但核心其实就是几条能识别退换货意图、能查询订单状态、能在退款规则内操作退款、高风险的客诉必须转人工且不能让用户等太久。业务边界也定了Agent只负责售后退款相关场景不碰价格谈判、不碰优惠券发放、不做主动营销推荐。这个边界看着简单但它直接影响架构设计的复杂度——每多一个业务领域授权的工具集合、知识库范围、审核规则都会成倍增长。8.2 架构图的分段落笔这个客服Agent最终的架构图分成了四段来画。第一段是入口与识别。用户进来先经过内容安全网关和意图识别系统判断这是“退款咨询”“订单查询”还是“投诉转人工”。为了降低成本意图识别走的是轻量模型只有识别到复杂诉求才升级到满血大模型。第二段是Agent主循环。Agent主导解析用户诉求先通过订单接口拿到订单状态与售后政策再根据规则决定是直接给出退款方案还是询问更多信息。这一段的图上要标清楚循环出口如果某个环节重复三次仍不能获得关键信息就不再追问直接转人工。第三段是数据访问。订单数据从业务库实时查询售后政策从向量库检索退款执行结果回写业务系统。权限过滤在前、审计日志在后保证每一步操作都有据可查。第四段是兜底链路。用户情绪异常触发敏感词规则时立即转人工并携带完整上下文摘要人工接管后Agent自动停止继续回复避免两个“客服”同时在线上发生冲突。8.3 复盘时发现的问题第一个问题是重试风暴。模型偶尔超时应用层统一做了重试结果高并发时同一个用户请求把模型网关打出一串重复调用。后来在网关层加了幂等判断和重试预算一次用户请求最多触发两次模型调用超出就降级转人工。第二个问题是知识库更新不及时。售后政策一改Agent还用旧政策回答被用户投诉了好几次。架构上必须画一条“政策发布—数据管道—向量库更新”的自动同步链路并定期校准缓存策略才从根本上解决这个问题。第三个问题是人工评审样本不够。模型跑了一个月真正被人工纠错的对话记录很少评测集扩充不动。后来把客服后台的聊天页签和Agent建议框钉在一起——客服每改一次建议就自动沉淀一条负样本。这类建立在真实业务实践上的反馈桥接比增加评测集数量更有效。这个项目的完整迭代过程远比我在这里写的复杂但架构图的四段拆法让每一次评审、每一个问题定位都变得高效。画图不是为了好看是为了让决策有据可依、让协作有共同语言。这一点在我做过的AI项目里唯独它是最值得坚持的。