AI应用架构图怎么画？部署、协作、数据流、编排四图详解

上周我参加了一个AI项目的内部评审项目组花了三周做了一个多智能体协作系统上线前拉我过去帮忙看架构。PPT打开第一页架构图是三个云朵、两条连线、一个数据库图标——标准的模板图。我问了几个问题模型并发突增时请求走哪里多个Agent结果冲突时谁做裁决上下文拼接在哪一步完成对方翻了好几页PPT都答不上来。图是错的架构大概率也是错的。这件事让我特别想写一篇关于AI应用架构设计的图解经验。近一年我看了几十个AI项目从RAG问答到多Agent工作流从内容生成到客服机器人能顺利上线的项目有一个共性架构图不是画出来应付评审的而是真能指导落地、支撑排障的。这篇文章不聊概念只讲我实际画图踩过的坑、固定要画哪几张图以及这些图怎么驱动代码、接口和容量设计。如果你正在做AI Agent、智能问答、内容生成类应用或者刚被多AI协作这类的方案搞晕这篇应该对你有用。1. 为什么AI应用架构图很难用老一套画法1.1 传统架构图画的是确定性边界传统Web应用里用户请求经过网关、业务服务、数据库每一步的处理逻辑都是确定的库存扣减就是扣减订单状态更新就是更新。你画一张部署架构图基本能推出请求会走哪条链路也能量出哪个环节可能出现瓶颈。那时候架构图的核心作用是画边界——系统边界、模块边界、依赖边界边界清楚了工程实现就顺理成章。但AI应用接入大模型之后这条确定性的链条被打破了。模型推理不是一个固定耗时的操作。同一个接口输入简单可能2秒返回输入复杂可能要30秒同一个Prompt多次调用返回的文本长度、内容质量都不完全相同。这不是代码的Bug而是生成式模型本身的特性。如果架构图还按传统思维只画请求—响应线很多问题根本暴露不出来。我见过一个项目把大模型封装在同步HTTP接口里上层业务用传统方式同步等待响应。功能演示的时候一切正常一压测就炸数据库连接池被打满网关超时重试引发雪崩。后来看他们的架构图上面根本没有队列、没有流式返回、没有超时兜底。问题不在代码在架构图阶段就已经埋下了。1.2 接入大模型后架构图上必须追加的不确定性传统架构图表达的是确定性的调用路径AI应用架构图至少要追加三类信息异步通道、流式通道、降级与重试策略。这三类信息不是可有可无的装饰而是整个架构能否稳定运行的关键。举一个典型的例子。用户发了一个需求根据这20页文档写一份周报。如果系统同步调用大模型让HTTP请求一直挂着等结果体验和稳定性都会出问题。正确做法是创建任务后立刻返回任务ID后台Worker异步消费完成后通过轮询或者WebSocket推送结果。这个模式不是新鲜事但很多做AI应用的人第一版就是想不到因为他们架构图上没画这一条异步通路。再比如流式输出。大模型生成文本是逐Token返回的ChatGPT式的打字机效果体验很好但如果架构上把所有内容都攒到最后一个响应里才返回用户等待时间会被拉长到不可接受。SSEServer-Sent Events通道需要在架构图上单独画出来标注清楚哪些链路走同步、哪些走流式、哪些走异步。我整理过一个对比表传统后端和接入大模型的后端在架构设计上关注的维度完全不一样维度传统后端架构接入大模型后的架构响应延迟稳定在毫秒级秒级到几十秒波动极大输出结果结构化、可预期生成式、概率性结果主要瓶颈数据库连接池、业务逻辑模型网关、上下文组装、推理成本架构图重点模块边界与依赖异步队列、流式通道、重试兜底排障手段查看日志链路、追踪调用链回放上下文快照、检查Prompt构成这张表基本解释了我为什么说老一套画法不够用——不是图不好看是信息维度缺失设计者根本没意识到这些环节的存在。1.3 Agent引入后架构图还要表达协作与委托如果说大模型让链路从同步变成了异步和流式那么Agent的引入让架构从调用关系升级为协作关系。传统微服务架构里服务A调用服务BA是调用方B是被调用方责任边界非常清楚。多Agent架构不一样一个主Agent可能需要拆分任务、委托给子Agent子Agent之间可能需要交换结果某个Agent产出的结论可能要被另一个Agent复核、驳回甚至修正。这种多AI协作关系很难用简单的箭头表达清楚。我在图上需要标清楚三件事谁发起协作、谁产出结果、谁拥有最终决策权。常见的一个错误是把所有Agent画成一个环互相连线结果图上全是箭头真正出问题时根本看不出哪个Agent该为最终结果负责。所以遇到多Agent项目我的习惯是先回答一个问题如果两个Agent的结论冲突谁说了算这个问题的答案会直接决定架构图的结构——是有明确的编排器充当决策中心还是通过某种评审Agent来做仲裁还是每次都要人工干预。画不清这个代码大概率也要写成一团浆糊。2. 我给AI应用画架构图时固定要画的四张图如果你问我一套AI应用架构到底要画几张图我的答案是四张部署拓扑图、Agent协作图、数据流与上下文图、流程编排图。四张图各管一个层面的问题缺一张后期都会踩坑。2.1 部署拓扑图先画边界再画盒子部署拓扑图回答的是系统跑在哪、请求怎么走、扩容加哪些机器。我见过很多人一上来就从大模型开始画把中间依赖全部省略最后画出来的图跟一个API调用示意图差不多。正确顺序是先画边界再画盒子。我通常先圈出环境边界用户端、网关层、Agent运行时、模型网关、外部模型API、向量库、工具服务、数据存储。然后往每个边界里填具体的服务盒子。下面是一张简化版的连接骨架我用Graphviz描述方便你直接拿去改digraph ai_arch { rankdirLR; node [shapebox]; User - APIGateway; APIGateway - AgentRuntime; AgentRuntime - ModelGateway; ModelGateway - LLMProvider; AgentRuntime - VectorDB; AgentRuntime - ToolService; AgentRuntime - Queue; Queue - WorkerAgent; WorkerAgent - ModelGateway; }这张骨架图的核心不在连线上而在节点之间的隐藏信息。每个部署节点旁边我一般会标三样东西部署环境云服务器、K8s、Serverless、协议HTTPS、gRPC、SSE、并发状态有状态还是无状态。有了这三项你才能判断哪个服务可以横向扩容哪个服务扩不了。这里特别说一下AI Agent怎么扛并发的问题。很多人以为并发瓶颈在大模型本身实际上大模型API吞吐量是有限的你不可能无限并发调用。真正的削峰手段是在Agent运行时和模型网关之间插入任务队列。用户请求只负责创建任务立刻返回后台Worker从队列里拉任务并发调用模型网关。这样即使模型API限流请求也只是在队列里排队不会把整个系统拖垮。这个队列必须在部署拓扑图里画出来不画的话上线第一天流量一来就会有人跳脚。2.2 Agent协作图表达谁发现谁、谁托付谁、谁决策Agent协作图是我见过最多人画不明白的一张图。大多数人直接画一个中央调度器然后四面八方连Agent看起来很强壮实则什么都没说清楚。我的画法会比较刻板但有效椭圆表示Agent矩形表示工具/外部服务菱形表示判定节点虚线表示事件回调或异步消息。这样的好处是评审时大家有一套共同语言不用你解释半天。从协作模式上多Agent系统我通常分三类来画路由式一个主Agent理解用户意图把任务分发给不同专长的子Agent子Agent结果汇总后由主Agent统一输出。大多数客服、企业知识问答系统属于这一类画图时核心是主Agent的分发逻辑和每个子Agent的能力边界。流水线式任务按阶段依次加工上一个Agent的输出是下一个Agent的输入。内容生成、代码审查类系统经常用这种模式画图时要重点标注每个阶段的输入输出协议。评审式一个Agent产出结果另一些Agent负责检查、打分、驳回。这是多AI协作里最难画的一种因为有反馈回路画普通过程图根本表达不清楚。下面是一个客服场景的Agent协作示意用PlantUML描述重点看评审这个环节startuml actor User control Orchestrator entity ResearchAgent entity WriteAgent entity ReviewAgent database ToolRegistry User - Orchestrator: 用户问题 Orchestrator - ResearchAgent: 理解意图并规划检索 ResearchAgent - ToolRegistry: 调用搜索/知识库工具 ResearchAgent -- Orchestrator: 返回检索结论 Orchestrator - WriteAgent: 生成回答初稿 WriteAgent - ReviewAgent: 质量复核 ReviewAgent - WriteAgent: 驳回并附修改意见 ReviewAgent - Orchestrator: 复核通过 Orchestrator - User: 返回最终回答 enduml画这张图的时候我最想强调一个原则不要让Agent之间直接互相连线。所有的协作关系尽量通过编排器转接实在需要直连的画成带编号的虚线并在图例里说明。原因很简单Agent之间的直接调用是后期维护的地狱排查问题时你根本不知道哪条线是真实路径哪条线只是临时的消息通知。2.3 数据流与上下文图AI应用最容易画错的地方部署拓扑图管系统在哪Agent协作图管谁在干什么第三张图管数据怎么流、上下文怎么拼。这张图是我认为AI应用架构设计里最容易被忽略也最影响排障效率的一张。传统数据流图画的是数据流转方向订单信息从Web层到Service层到数据库。AI应用的数据流图多了一个关键节点上下文组装。你发给大模型的不是裸数据而是把系统Prompt、用户输入、检索到的文档片段、历史会话记录按一定策略拼接成的一段文本——这段文本直接决定了模型输出的质量。以一个RAG问答系统为例我会把数据流画成下面几段文档导入阶段原始文档切分成片段 → Embedding模型转向量 → 写入向量数据库。用户提问阶段用户输入问题 → Embedding模型转成问题向量 → 在向量库做相似度检索。上下文构建阶段检索到的文档片段 系统Prompt 历史会话摘要 用户问题 → 组装上下文 → 发送给大模型。输出阶段模型生成内容 → 流式返回给用户 → 异步记录到会话存储。这张图里最重要的不是那些存储组件而是第三个阶段——上下文构建。我会在这个节点旁边单独列出组成上下文的各个区块标注Token预算和截断策略。比如系统Prompt占500 Token检索片段最多3000 Token历史摘要滚动窗口保留最近10轮对话。这些参数写在架构图上开发和算法都有据可依。排障的时候这张图的优势特别明显。用户反馈模型回答跑偏了你第一件事就是要确认模型到底看到了什么上下文。如果架构图上有上下文组装这个节点你就能直接找到日志打印那一刻实际发出去的消息体。没有这张图你只能在代码里翻半天还不知道该去哪里找线索。顺带提一句如果你做的是AI图片生成类应用数据流图里需要画出模型的输入条件Prompt、参考图、参数和输出产物图片文件、缩略图、审核记录之间的流转路径还要画出采样步数、尺寸等参数对生成结果的影响链路。AI应用的架构图不要求你画模型的内部结构但必须画清楚模型与外部数据交互的边界。2.4 流程编排图把不可控的模型变成可控的状态机第四张图是流程编排图核心是把Agent任务定义成有限状态机而不是画成普通的业务流程图。大模型输出不稳定某个步骤失败、超时、格式不符合预期都是常态。传统代码里你可以依赖异常和重试AI应用里一个Agent步骤的输出格式都可能变化运行到一半被工具调用堵住也很常见。所以架构上要明确所有的状态流转、重试策略和人工接管路径。一个典型的Agent任务状态机包含这些状态class AgentTaskStatus(str, Enum): PENDING pending # 已创建等待执行 RUNNING running # 正在执行 AWAITING_TOOL awaiting_tool # 等待工具调用返回 NEEDS_HUMAN needs_human # 需要人工审核 COMPLETED completed # 已完成 FAILED failed # 失败无法自动恢复 CANCELLED cancelled # 已取消画状态机图的时候有几个节点要特别用心。第一个是人工审批节点这在金融、医疗、法务这些场景里几乎是必须的——模型生成的内容在发给用户之前必须经过人工确认。第二个是重试与降级节点模型调用失败时是换一个模型、降低参数还是直接返回兜底话术这个决策应该在架构图上画出来而不是等代码写一半再拍脑袋。流程编排图还有一个很重要的价值就是帮你搞清楚有状态还是无状态。编排器必须维护任务状态不然任务执行到一半服务重启所有上下文全部丢失。这不等于说每个Agent执行器都要有状态——执行器可以是无状态的从队列里拿任务、执行、回写结果但编排器一定要有状态持久化。这个状态是任务状态不是用户Session两者别混淆。3. 画图时最容易翻车的三个误区3.1 误区一把业务流程图当架构图有一次评审同事做了个AI助手架构图是用户输入 → 大模型 → 输出三个框。我当时问了三个问题模型部署在哪如果QPS翻十倍哪个节点先崩如果要加一个新Agent改哪条线他一个都答不上来。他画的是用户操作流程不是架构设计。判别一张图是不是架构图有一个很实用的标准你能不能基于它做容量评估、故障排查、模块拆分。如果这张图只能回答用户怎么用系统那它是业务流程图架构图必须回答系统怎么运转、边界在哪、瓶颈在哪、改动会影响谁。正确的做法是把一个业务流程拆成多张架构图部署图管物理分布协作图管分工数据流图管信息流动状态图管任务生命周期。一张图画不完所有事硬画反而什么都表达不清。3.2 误区二把所有细节塞进一张图我见过最夸张的一张图里面有几十个实体、上百条连线用投影仪放出来字号调满全屏依然看不清。画图的人很委屈说所有东西都画出来了乱是乱了点但信息完整啊。信息完整不等于信息有效人的工作记忆大约只能同时处理7个信息块一张图超过这个量级看图的人根本抓不住重点。正确思路是像地图APP一样做缩放宏观地图看城市交通拉到最大看街道楼栋两者不塞在同一层。架构图也一样部署拓扑是宏观层Agent协作是中观层数据流和上下文组装是微观层。想看哪一层就切哪一层而不是一张图从地心画到房顶。我的实操习惯是一张图的主干节点控制在7个以内超过就拆视角。运维关心部署研发关心协作算法关心数据和上下文谁也别看谁的完整版。3.3 误区三只画模型不画上下文与状态有一次排查一个多Agent客服系统Agent B生成了完全错误的回答内容里引用了用户很久以前的聊天记录。代码里找了很久都没找到那段历史对话是从哪里被拼接进来的。后来才发现上下文组装逻辑藏在编排器的某个工具函数里架构图上根本没有这个节点。这个问题普遍存在原因是不少人默认大模型有记忆。大模型本身完全无状态所谓记忆全靠外部把历史记录拼进上下文。既然上下文是模型唯一的信息来源架构图里却不标它在哪里构建、从哪里取数、占用多少Token那排障时你就等于在黑暗里找东西。修正方法也很简单数据流图必须画出完整的上下文组装节点标注上下文来源列表、拼接顺序、截断策略。Debug Prompt问题最有效的方式是打印实际发送给模型的完整消息体。架构图里有上下文组装节点你才知道这份日志应该看哪里否则只能盲猜。4. 从图到落地一套架构图如何驱动工程实现架构图不是画完就束之高阁的文档它最大的价值在于能直接指导工程落地。我做项目时基本按一套流程走先画图再从图推导模块、接口和容量计划。4.1 图驱动的模块划分与目录结构部署拓扑图上的每一个盒子基本对应一个服务或模块。我见过的AI应用项目建议目录结构长这样apps/ user_api/ # 用户入口API对应网关后第一层 orchestrator/ # 编排器服务维护任务状态和Agent调度 agents/ # 各Agent执行器按业务能力拆分 model_gateway/ # 模型网关统一封装上游模型供应商 worker/ # 异步任务消费者从队列取任务执行 libs/ context_builder/ # Prompt上下文组装与截断 memory_backend/ # 会话记忆与历史存储 infra/ queue/ # 任务队列定义 vector_db/ # 向量库迁移脚本这里有一个划分原则很关键按变化频率划分模块而不是按业务功能划分。模型供应商会变、Agent策略会变、业务端点会变这三类变化频率最高的东西必须各自独立成模块。反过来稳定不变的鉴权、日志、监控可以放公共基础设施里。这样的好处是今天要换一个模型供应商只改模型网关要加一个新Agent只加agents目录下的一个单元不碰编排器。4.2 图驱动的接口设计与并发估算从数据流图上能直接推导出API的形态。我一般这样定义POST /v1/tasks创建异步任务返回任务ID。GET /v1/tasks/{id}轮询任务状态。POST /v1/chat/complete实时对话走SSE流式返回。POST /v1/model/generate模型网关内部接口所有上游模型统一用这一个签名。判断用同步还是异步我有一条经验任何需要等待大模型结果超过3秒的请求都应该走异步任务模式实时交互对话场景用SSE流式输出。别指望用一个同步接口扛住所有场景模型推理时间是客观的不是代码能绕过去的。关于AI Agent怎么扛并发我一般用这个公式粗算模型侧并发数 (高峰小时请求数 / 3600) × 平均单次推理响应时间 × 单请求平均调用模型次数。举个例子假设每天1万次请求高峰集中在每小时2000次平均单次推理8秒一个用户请求平均触发3次模型调用。那模型侧的并发压力就是(2000/3600) × 8 × 3 ≈ 13.3个并发请求。听起来不多但13个并发调一个限流阈值为10的模型API系统已经会出现排队超时了。算完这个数你会发现架构图里如果没有队列和限流这个系统上线必出问题。4.3 图驱动的测试与上线清单架构图画好后我习惯从中梳理一份上线检查清单。这张清单负责把架构图里的每一个要素都变成可验收的工程项检查项验收标准模型网关超时设置已配置连接超时、读取超时超时后有降级方案模型网关重试策略已限定最大重试次数避免雪崩上下文组装截断已设置Token预算超长时按策略截断流式连接管理SSE断线重连、客户端断开后服务端能主动停止生成任务状态持久化任务执行中服务重启状态可从数据库恢复人工审批逻辑高风险场景模型产出未审批前不会下发到用户这套清单把图和工程真正钉在了一起。测试团队拿到这张清单才知道哪些环节需要Mock模型返回、哪些环节需要记录真实输出做回归比对这就是AI测试开发里的核心工作。没有架构图测试只能对着需求文档猜。5. 让架构图活下来的协作工作流5.1 工具链推荐从白板到可维护的图画图工具我有几条实际建议。探索阶段用白板或Excalidraw怎么快怎么来别在意规范方案定型后用Draw.io或Graphviz做规范化输出最终版本一定要落成文本描述格式入库。我个人的偏好是Graphviz和PlantUML因为它们是纯文本可以进Git仓库、可以Diff、可以自动生成比截图可靠得多。现在很多AI辅助编程工具也能直接生成图描述你描述清楚模块和箭头它能快速帮你起一个PlantUML框架。但生成的图一定要人工核对AI没法理解你的边界划分逻辑它只是把你的文字描成了图语义对不对还是要你判断。5.2 架构评审的正确姿势按图攻击架构评审时我一般不看PPT只看图并且照着下面几个问题攻击设计者如果模型供应商挂了降级链路是什么如果某个Agent陷入循环疯狂重试熔断机制在哪如果上下文超长截断策略是什么会不会影响回答质量如果并发翻十倍哪个节点先瓶颈扩容方案是什么如果两个Agent结论冲突谁有最终决策权这些问题不用全答对但架构图必须让你能把问题问出来。一张不能产生问题的架构图基本就是一张装饰画。5.3 架构图的更新节奏与代码同步演进最后说一个我自己的铁律架构图源码和接口定义放在同一个仓库MR评审时图和代码一起看图没改代码改了要打回。AI应用迭代太快Agent策略、模型参数、上下文规则经常变架构图跟不上代码比没有图更危险——新人照着旧图理解系统直接理解偏。我的经验是AI应用架构图看起来是几个框和箭头但本质是逼着你在动手前把不确定性摊到桌面上。模型波动、Agent之间的决策冲突、并发尖峰、上下文超长这些问题不会因为你没画在图里就消失只会在你上线之后用事故报告的形式重新出现在你面前。先画图别的可以后面再调这句话是我这几年做AI应用最想分享的体会。