说实话我看过不少团队的AI应用架构图第一眼感觉都挺完整——用户、模型、向量库、API网关框框连线配色统一。但只要追问几个问题就露馅了换一个模型要动哪一层工具超时了回退到哪条链路用户上下文存在哪个存储里回答不上来的基本可以断定图画的是“功能接线图”不是架构图。真正的AI应用架构设计核心不是把组件堆上去而是把边界划清楚。这篇文章我会用图解的思路把我自己在多个AI应用落地项目里反复用的一套拆法讲透AI应用架构分层怎么划、Agent编排在图里到底该占多大篇幅、哪四条链路必须单独放大画子图以及图纸之外真正折磨人的工程细节到底是什么。内容不涉及大模型内部原理适合后端研发、产品经理、算法工程师和所有想搞懂AI应用内部结构的同学。我尽量讲得能直接抄作业而不是停留在概念层。1. 我理解的图解AI应用架构不是画画是划边界1.1 一张架构图该回答的三个问题很多人的架构图是照着“组件清单”画的——把用到的技术挨个列出来然后用箭头连起来。这种图最大的问题是没有边界感。边界感是什么就是任何一次改动团队所有人都能准确说出“这个改动会影响哪一层、不应该影响哪一层”。我判断一张AI应用架构图能不能用只看三件事。第一改动定位。换模型、改Prompt、加RAG、换向量库这四次操作应该分别落在图里的不同层次。如果一次Prompt改动要牵扯代码发布或者换模型要改业务逻辑图的边界一定画错了。AI应用的典型特征就是“模型层、Prompt层、应用逻辑层”三者高度耦合架构图的核心任务之一就是把这层耦合切开。第二数据流动。一次请求从进来到返回中间要经过哪些处理、每个处理环节写不写存储、上下文在哪一步拼装、模型返回结果后还要做什么后处理。这些流动关系必须能从图上看出来而不是靠脑补。第三降级路径。模型服务超时怎么办工具调用失败怎么办知识库没检索到结果怎么办架构图里如果没有明确的降级链路上线后排障只能靠猜。这三个问题对应到画法上就是一句话先画边界再画组件先画路径再画细节。1.2 开发态架构图和运行态架构图两种都得画我见过一个很有意思的分歧。研发负责人画架构图画的是模块依赖关系——服务A依赖服务B服务B调用模型网关。这种叫开发态架构图它的作用是指导代码组织告诉团队新代码应该写在哪。但到了线上出问题的时候开发态架构图帮不上忙。模型API偶发超时、SSE连接中断、Agent循环卡死这些问题都发生在“运行态”。运行态架构图画的是请求和数据的流转路径每个节点要标注超时时间、并发上限、存储位置、监控埋点。所以我的习惯是每个项目至少画两套图。主图用开发态视角把五层结构和依赖关系画清楚另外再画一套运行态的关键链路子图重点标出超时、重试、队列、降级这些运行期属性。前者用于架构评审后者用于值班排障。两套图加起来成本不高但能避免“架构图锁在文档里吃灰”的尴尬。2. 一套实用的AI应用五层架构边界、职责与接口先亮出我常用的主图。整个AI应用从上到下分成五层接入与体验层、工作流编排层、模型路由层、工具与数据接入层、模型基础设施层。下面逐层拆。2.1 接入与体验层流式接口是第一生产力这一层是用户能触达的一切入口Web页面、小程序、IM机器人、语音助手、第三方开放API。很多架构图在这层就画一个“前端”框太粗糙了。真正要画清楚的是接口形态。现在是个AI应用就必须支持流式返回。用户看到“一个字一个字蹦出来”的背后其实是模型在持续生成token数据通过WebSocket或SSE长连接推送到前端。这不只是体验问题它直接决定了架构的形态。流式接口对网关提出了特殊要求。普通的Nginx反代遇到长时间挂起的连接会配置超时断开你需要专门的流式网关或对现有网关做长连接调优。同时前端UI需要把模型返回的增量字节流解析成可以渲染的文本块、Markdown结构、引用片段。这部分逻辑放在接入层不要让模型层的原始输出直接渗透到页面。如果应用要支持音视频输入接入层还要负责音频流转文字、视频切帧提取关键画面这些预处理任务往往是异步的接到任务队列而不是同步调用链上。2.2 工作流编排层AI应用的“操作系统”如果只让我在架构图里选一个最核心的层我会选工作流编排层。它的角色相当于AI应用的“操作系统”负责管理一次对话从开始到结束的全生命周期状态。具体拆开这层至少承担五件事会话状态管理这个用户当前在哪个流程节点已经填了哪些信息还需要什么上下文拼装把系统提示词、历史对话、检索片段、工具返回结果按序组装成给模型的最终输入工具调用编排决定模型是否要调用工具、调用哪个工具、参数如何校验回退策略模型输出异常、工具超时、上下文超限时如何降级或重新规划人工确认流程哪些操作需要用户二次确认确认状态如何流转。这里给个简单例子。一个“AI客服工单助手”在处理“帮我查订单并申请退款”时编排层会维护一个状态机初始状态→调用订单查询工具→拿到订单状态→判断是否需要人工审核→生成退款方案→等待用户确认→执行退款。这个状态机的每个转换都依赖上层模型的理解能力和工具返回的真实数据而状态本身必须存在编排层里不能依赖模型自己记住。我用一个简化的JSON描述这种状态{ session_id: sess_202501_001, current_node: awaiting_user_confirm, collected_data: { order_no: A123456, order_status: delivered, apply_refund: true }, pending_tool_calls: [], history_summary: 用户申请退款已核实订单已签收 }会话状态要存到Redis这类外部存储里原因后面第3章讲Agent并发时会展开。2.3 模型路由层多模型并存不是选择题是常态很多团队一开始只接一个模型API架构图里也就画一个模型框。但真实业务跑起来以后很快会发现“一个模型打天下”行不通。不同任务对模型的要求差异极大。简短分类用大模型纯属浪费复杂的逻辑推理需要最强模型OCR和语音转文字要专门的模型代码生成和通用聊天可能又各有所长。这时候就需要一个模型路由层把所有模型接入统一封装上层应用不直接依赖某一个模型品牌。模型路由层要维护一份能力矩阵大致像下面这样任务类型推荐模型类别时延预算成本档位备注闲聊、意图分类轻量级模型1秒低不需要复杂推理复杂推理、多步规划旗舰级模型2-5秒高需要长上下文代码解释与生成代码专项模型2-4秒中需要结构化输出语音转写专用音频模型依赖音频长度中通常异步处理图像理解多模态模型2-4秒高单图场景路由规则可以很朴素按意图分类、按输入长度、按预算上限、按当前负载。真正要把多模型协作也就是现在常说的多AI协作落地编排层还要定义模型输出的结构化协议——不能一个模型吐JSON、另一个模型吐纯文本路由层之后必须跟着一个输出解析器统一校验再往上层传。2.4 工具与数据接入层MCP式的统一协议AI应用和传统应用最大的区别之一是模型需要动态调用外部工具。查订单、发邮件、查天气、搜索知识库这些能力不可能预设在模型里必须通过工具调用来完成。第2.4层就是把数据库、向量库、外部API、内部微服务统一封装成“工具”。我强烈建议这一层用统一协议来暴露而不是每个工具一套接入方式。现在MCPModel Context Protocol这类协议已经很普及核心价值就是把工具描述、参数Schema、调用结果格式变成标准结构模型只需要理解一套语法就能调用所有工具。统一协议解决的不只是接入麻烦更重要的是可控性。工具描述文件里写清楚“这个工具是干嘛的、需要哪些参数、有什么限制”模型才能正确调用。工具返回结果要经过校验层防止模型被恶意结果误导或把异常数据带入下轮上下文。这个放在架构图里就是一层工具注册中心、工具调用鉴权、结果格式化。所有外部能力都从这一层出去不许业务代码直接裸连外部API。2.5 模型基础设施层让模型服务变成可靠依赖最底层是模型服务本身。这里要画的不只是一个“模型”框而是围绕模型的一切基础设施。首先是模型API或自建推理服务。无论用云厂商的模型API还是自建推理服务都要封装成独立的模型网关统一处理鉴权、限流、超时、重试、缓存。其次要考虑上下文计算和Token预算输入的每一轮对话都要消耗Token超长之后要么截断要么压缩这层要有专门的处理器。包含内容安全的护栏也要放在这层。输入侧做敏感内容过滤输出侧做合规检查这不是可选项而是AI应用上线的必选项。模型返回内容在到达用户之前要过一道输出安全过滤。这里能直观看到成本压力。假设一个请求平均消耗2000个输入Token和800个输出Token按通用模型API价格粗算单次成本可能在一两分钱到几毛钱不等。单个请求看不见钱但日活一万、每天几百万次调用时成本就是日结账的数字。所以模型基础设施层一定要带“Token计量和成本看板”不然到月底财务找上门才意识到问题就晚了。3. Agent编排是架构图里最容易“画小了”的部分3.1 Agent runtime做对的四件事现在聊AI应用离不开Agent。但很多架构图把Agent画成一个简单的调用链用户输入→LLM→工具→返回这就把Agent画小了。一个能跑稳定的Agent runtime核心是四件事。第一循环控制。Agent的本质是模型和工具之间的多轮互动模型提出要调工具工具返回结果模型再根据结果决定下一步。这个循环必须有硬上限——最多调用多少次工具、整个任务最长执行多长时间。我见过不加循环上限的Agent模型在修正一个错误参数时反复尝试七八次浪费调用次数用户还在干等。第二状态持久化。Agent的任务进度不能只存在内存里。实例重启、用户刷新页面、任务长时间挂起都需要能从外部存储恢复进度。Agent每完成一个步骤就把当前状态写入会话存储。第三工具调用的可靠性。工具不是百分百成功的。网络超时、参数被模型填错、第三方服务返回异常Agent必须能识别失败类型并决定重试、换工具还是向用户求助。这里要给每个工具定义清晰的错误码。第四安全护栏。模型在循环调用工具时存在被提示词注入利用的风险——一段混在输入文本里的恶意指令试图诱导模型调用不必要的工具。Agent runtime要对输入内容做隔离对工具调用权限做最小化授权对敏感操作强制人工确认。3.2 Agent并发治理把Agent当作有状态服务来设计“AI客服并发扛不住”是大家常讨论的问题这里的根子多数时候不在模型API而在Agent编排层的设计。很多人直观地把Agent理解为“一次用户请求模型回答结束”。但实际上一个Agent任务往往包含多次模型调用和多次工具调用。比如一个数据处理Agent可能要经历“理解需求→调用查询工具→分析结果→再次调用筛选工具→生成报告”一次任务里模型被调用5到8次。并发一高模型API的QPS消耗会成倍放大。我在设计并发方案时核心思路是Agent实例无状态会话状态进外部存储。所有Agent worker可以随意水平扩缩容任意实例接手任意会话都能从存储里恢复进度。这样并发瓶颈就从“Agent服务本身”转移到了两个可控点——模型API的吞吐上限和状态存储的性能。算一笔账。假设某个模型API的并发上限是每分钟处理6000次推理请求平均每个Agent任务要调用模型8次。那么这套API能支撑的并发Agent任务数就是一分钟内750个任务同时处于活跃执行中。如果业务峰值预期是2000个并发会话要么提高模型吞吐、要么减少单任务的模型调用次数。这种数字必须先算清楚再决定架构规模。长任务的背压处理也很关键。同步请求路径只适合交互性强的短任务像“帮我整理一个月的数据报表”这种长任务应该走异步任务队列用户提交任务编排层入队队列消费者拿任务后调度Agent去执行执行进度通过WebSocket或轮询回传。这样前端不会因为长时间等待而断连后端也能按照队列深度平滑控制并发。3.3 人机确认点架构图里要专门画“人”这个细节我吃过亏多说一句。两年多前做一个自动化流程应用当时图里把Agent设计成“从理解到执行全自动”上线前产品才说要加人工审核环节结果只能在主流程里硬塞一个审核状态直接破坏了原有状态机。现在我在架构图里一定会专门画一条回路Agent执行到敏感操作→进入确认队列→等待用户在界面上点击确认→确认后继续执行。这条回路要作为一等公民出现在图里而不是事后补丁。哪些操作需要人工确认在设计阶段就要列清单涉及资金的操作、对外发送消息、删除数据、修改权限都属于高危动作。4. 四张子图把关键链路单独放大否则主图没法看主图画五层结构没问题但如果所有细节都堆在主图上图就变成“蜘蛛网”了没人看得懂。我会给四条关键链路各画一张子图每张图聚焦一个流动过程。4.1 RAG链路子图召回-重排-生成不是串联那么简单RAG检索增强生成是AI应用最常见的知识增强方案。很多架构图就画三个框文档库→向量检索→LLM生成。但实际跑起来根本不是一条直线。完整链路应该是用户提问→查询改写用模型把模糊问题改写成更适合检索的形式→并行检索向量检索关键词检索→合并结果→重排用重排模型把相关性低的片段排掉→上下文拼装→生成回答。这中间有两个关键分支。第一检索结果为空或相关性都很低时要不要如实告诉用户“知识库里没有相关内容”而不是让模型编造第二检索片段拼装后超过模型上下文窗口怎么办——是要截断、摘要压缩还是分层注入架构图里要把“知识更新链路”画出来文档上传→解析→切块→向量化→写入向量库→版本管理。很多应用只画了查询链路没画更新链路结果就是上线后知识库里永远是旧数据。我建议RAG子图至少标注两个数据存储向量库存语义索引关系型或文档库存知识原文和引用信息。生成回答时要能溯源到原始文档位置否则用户追问“你凭什么这么说”时无从查起。4.2 流式响应链路子图从模型字节流到前端事件流式子图要画清楚一段字节流的完整旅程。模型推理服务不断吐出增量token这些内容不能一股脑儿直接丢给前端。流式网关要做几件事缓存必要的事件元数据、把累计文本转换成前端可消费的事件流、处理断线重连。前端收到增量内容后要渲染出打字机效果同时处理Markdown格式化、代码块折叠、引用标注。这条链路里最隐蔽的坑是“中间层缓存整个响应”。有些团队为了让日志更完整在网关层把整个模型输出缓存下来再转发结果第一个token延迟增加了用户体感明显变慢。流式传输的设计原则是数据过手不留日志和审计用旁路异步处理。画这条子图时标注清哪一段是双向通信用户发消息和接收流式返回哪一段是单向流即可。4.3 记忆链路子图短期记忆和长期画像必须分开存AI应用对记忆的需求越来越普遍。但记忆不能是一个模糊概念架构上至少要拆成两级。短期记忆对应当前会话内的上下文。存在Redis这类高速缓存里设置过期时间默认比如30分钟无操作就失效。这类记忆内容原文存储即可不需要做提炼。长期记忆对应跨会话的用户偏好、历史事实。比如用户喜欢的语言风格、常居住的城市、之前提过的重要信息。这类记忆要存储在关系型数据库或文档数据库里写入时做结构化抽取读取时按需只检索当前相关的片段。记忆的写入不能同步阻塞对话生成。模型回复完之后可以异步触发记忆更新任务——解析对话、抽取关键事实、更新用户画像。这条异步链路要在记忆子图里单独画出来不然排查“为什么用户上一轮说了喜欢简洁风格这轮回答还是啰嗦”时完全找不到入口。4.4 可观测链路子图没有Trace的AI架构图等于没画AI应用比传统应用难排查得多。原因很简单同样的用户输入模型今天和明天的回答可能不同工具偶发超时RAG召回质量波动。这些问题没有Trace根本定位不了。可观测子图要覆盖三类数据。第一类是链路追踪每次请求从进入接入层开始给每个关键节点埋一个spanPrompt组装耗时、模型调用起止、工具调用结果、RAG各个环节的耗时和召回数量。第二类是质量评估用户对回答点了赞还是踩、有没有复制结果、有没有追问修正这些反馈信号要回流到评估系统。第三类是成本观测按业务线、按功能模块统计Token消耗和费用每周出报表。评估体系的建设要跟测开配合。我在项目里会把评估测试集纳入代码仓库每次Prompt或工具调整都在CI里跑一遍回归测试用测试集里的标准答案计算准确率和格式合规率。线上准备流量回放环境把真实请求离线重放对比不同模型版本的回答质量。这套东西看着重但不做的话AI应用基本处于“改完不知道好坏”的裸奔状态。5. 画完架构图之后真正折磨人的是这几个小问题5.1 Prompt和工具描述要进版本库和代码走同一条评审线有次线上用户反馈回答风格突变查了半天原因是产品经理直接改了线上Prompt配置没经过任何评审。Prompt是AI应用的“逻辑的一部分”它和代码一样有副作用、需要回滚、需要测试。我现在要求所有Prompt模板和工具描述以配置文件形式纳入版本库。改动也走代码评审流程合并后通过配置中心发布支持一键回退。5.2 上下文窗口本质是昂贵的临时内存每次把内容塞进上下文都是在消耗Token预算。很多团队设计时没算这笔账结果上下文越来越大延迟越来越高成本成倍翻。我给应用设每个请求的Token预算上限。系统指令固定占多少、结构化数据占多少、历史对话占多少、RAG片段占多少各分一块。预算超了就得做取舍优先保留系统指令和与当前任务直接相关的数据历史对话可以做摘要压缩示例可以砍掉。动态预算比固定值更实用简单任务用小预算复杂任务放开大预算不同模型能力对应不同预算档位。这个配置要落在每一轮请求的组装逻辑里而不是写死在代码中。5.3 部署形态必须影响架构图里的内容同一套逻辑部署方式不同架构重点完全不同。用云上模型API架构图的重心在编排层和模型路由层要重点画API边界、限流、成本控制。自建开源模型推理基础设施层变成重点要画GPU资源、队列调度、并发吞吐。端侧小参数量模型架构图要把模型画进客户端里编排逻辑下沉到App端云端只负责同步和兜底。最怕的是架构不区分部署形态一套图上画“云API自建端侧”混在一起看着全面实际没指导意义。架构演进我建议渐进式第一版先跑通“接入层编排层单模型API”的极简链路第二版再插入RAG和工具调用第三版再把Agent编排和记忆系统做进去。每次只动一层排查问题就永远有清晰边界。5.4 最后说点个人体会AI应用架构设计跟传统后端架构最大的不同是“不确定性”无处不在。模型输出不保证稳定、工具调用可能失败、检索质量波动明显、成本随流量放大。架构图唯一的目的是把不确定性约束在有限的层和链路内让团队每次只需要面对一个不确定性而不是所有不确定性同时爆发。我自己画架构图时还有一个习惯先用很窄的布局把MVP链路画通再逐步加宽加厚。接口和边界先定死组件和模型随便换。这套思路帮我跨过了不少项目从Demo到生产的坎儿希望能对正在设计AI应用架构的你也有帮助。
说实话我看过不少团队的AI应用架构图第一眼感觉都挺完整——用户、模型、向量库、API网关框框连线配色统一。但只要追问几个问题就露馅了换一个模型要动哪一层工具超时了回退到哪条链路用户上下文存在哪个存储里回答不上来的基本可以断定图画的是“功能接线图”不是架构图。真正的AI应用架构设计核心不是把组件堆上去而是把边界划清楚。这篇文章我会用图解的思路把我自己在多个AI应用落地项目里反复用的一套拆法讲透AI应用架构分层怎么划、Agent编排在图里到底该占多大篇幅、哪四条链路必须单独放大画子图以及图纸之外真正折磨人的工程细节到底是什么。内容不涉及大模型内部原理适合后端研发、产品经理、算法工程师和所有想搞懂AI应用内部结构的同学。我尽量讲得能直接抄作业而不是停留在概念层。1. 我理解的图解AI应用架构不是画画是划边界1.1 一张架构图该回答的三个问题很多人的架构图是照着“组件清单”画的——把用到的技术挨个列出来然后用箭头连起来。这种图最大的问题是没有边界感。边界感是什么就是任何一次改动团队所有人都能准确说出“这个改动会影响哪一层、不应该影响哪一层”。我判断一张AI应用架构图能不能用只看三件事。第一改动定位。换模型、改Prompt、加RAG、换向量库这四次操作应该分别落在图里的不同层次。如果一次Prompt改动要牵扯代码发布或者换模型要改业务逻辑图的边界一定画错了。AI应用的典型特征就是“模型层、Prompt层、应用逻辑层”三者高度耦合架构图的核心任务之一就是把这层耦合切开。第二数据流动。一次请求从进来到返回中间要经过哪些处理、每个处理环节写不写存储、上下文在哪一步拼装、模型返回结果后还要做什么后处理。这些流动关系必须能从图上看出来而不是靠脑补。第三降级路径。模型服务超时怎么办工具调用失败怎么办知识库没检索到结果怎么办架构图里如果没有明确的降级链路上线后排障只能靠猜。这三个问题对应到画法上就是一句话先画边界再画组件先画路径再画细节。1.2 开发态架构图和运行态架构图两种都得画我见过一个很有意思的分歧。研发负责人画架构图画的是模块依赖关系——服务A依赖服务B服务B调用模型网关。这种叫开发态架构图它的作用是指导代码组织告诉团队新代码应该写在哪。但到了线上出问题的时候开发态架构图帮不上忙。模型API偶发超时、SSE连接中断、Agent循环卡死这些问题都发生在“运行态”。运行态架构图画的是请求和数据的流转路径每个节点要标注超时时间、并发上限、存储位置、监控埋点。所以我的习惯是每个项目至少画两套图。主图用开发态视角把五层结构和依赖关系画清楚另外再画一套运行态的关键链路子图重点标出超时、重试、队列、降级这些运行期属性。前者用于架构评审后者用于值班排障。两套图加起来成本不高但能避免“架构图锁在文档里吃灰”的尴尬。2. 一套实用的AI应用五层架构边界、职责与接口先亮出我常用的主图。整个AI应用从上到下分成五层接入与体验层、工作流编排层、模型路由层、工具与数据接入层、模型基础设施层。下面逐层拆。2.1 接入与体验层流式接口是第一生产力这一层是用户能触达的一切入口Web页面、小程序、IM机器人、语音助手、第三方开放API。很多架构图在这层就画一个“前端”框太粗糙了。真正要画清楚的是接口形态。现在是个AI应用就必须支持流式返回。用户看到“一个字一个字蹦出来”的背后其实是模型在持续生成token数据通过WebSocket或SSE长连接推送到前端。这不只是体验问题它直接决定了架构的形态。流式接口对网关提出了特殊要求。普通的Nginx反代遇到长时间挂起的连接会配置超时断开你需要专门的流式网关或对现有网关做长连接调优。同时前端UI需要把模型返回的增量字节流解析成可以渲染的文本块、Markdown结构、引用片段。这部分逻辑放在接入层不要让模型层的原始输出直接渗透到页面。如果应用要支持音视频输入接入层还要负责音频流转文字、视频切帧提取关键画面这些预处理任务往往是异步的接到任务队列而不是同步调用链上。2.2 工作流编排层AI应用的“操作系统”如果只让我在架构图里选一个最核心的层我会选工作流编排层。它的角色相当于AI应用的“操作系统”负责管理一次对话从开始到结束的全生命周期状态。具体拆开这层至少承担五件事会话状态管理这个用户当前在哪个流程节点已经填了哪些信息还需要什么上下文拼装把系统提示词、历史对话、检索片段、工具返回结果按序组装成给模型的最终输入工具调用编排决定模型是否要调用工具、调用哪个工具、参数如何校验回退策略模型输出异常、工具超时、上下文超限时如何降级或重新规划人工确认流程哪些操作需要用户二次确认确认状态如何流转。这里给个简单例子。一个“AI客服工单助手”在处理“帮我查订单并申请退款”时编排层会维护一个状态机初始状态→调用订单查询工具→拿到订单状态→判断是否需要人工审核→生成退款方案→等待用户确认→执行退款。这个状态机的每个转换都依赖上层模型的理解能力和工具返回的真实数据而状态本身必须存在编排层里不能依赖模型自己记住。我用一个简化的JSON描述这种状态{ session_id: sess_202501_001, current_node: awaiting_user_confirm, collected_data: { order_no: A123456, order_status: delivered, apply_refund: true }, pending_tool_calls: [], history_summary: 用户申请退款已核实订单已签收 }会话状态要存到Redis这类外部存储里原因后面第3章讲Agent并发时会展开。2.3 模型路由层多模型并存不是选择题是常态很多团队一开始只接一个模型API架构图里也就画一个模型框。但真实业务跑起来以后很快会发现“一个模型打天下”行不通。不同任务对模型的要求差异极大。简短分类用大模型纯属浪费复杂的逻辑推理需要最强模型OCR和语音转文字要专门的模型代码生成和通用聊天可能又各有所长。这时候就需要一个模型路由层把所有模型接入统一封装上层应用不直接依赖某一个模型品牌。模型路由层要维护一份能力矩阵大致像下面这样任务类型推荐模型类别时延预算成本档位备注闲聊、意图分类轻量级模型1秒低不需要复杂推理复杂推理、多步规划旗舰级模型2-5秒高需要长上下文代码解释与生成代码专项模型2-4秒中需要结构化输出语音转写专用音频模型依赖音频长度中通常异步处理图像理解多模态模型2-4秒高单图场景路由规则可以很朴素按意图分类、按输入长度、按预算上限、按当前负载。真正要把多模型协作也就是现在常说的多AI协作落地编排层还要定义模型输出的结构化协议——不能一个模型吐JSON、另一个模型吐纯文本路由层之后必须跟着一个输出解析器统一校验再往上层传。2.4 工具与数据接入层MCP式的统一协议AI应用和传统应用最大的区别之一是模型需要动态调用外部工具。查订单、发邮件、查天气、搜索知识库这些能力不可能预设在模型里必须通过工具调用来完成。第2.4层就是把数据库、向量库、外部API、内部微服务统一封装成“工具”。我强烈建议这一层用统一协议来暴露而不是每个工具一套接入方式。现在MCPModel Context Protocol这类协议已经很普及核心价值就是把工具描述、参数Schema、调用结果格式变成标准结构模型只需要理解一套语法就能调用所有工具。统一协议解决的不只是接入麻烦更重要的是可控性。工具描述文件里写清楚“这个工具是干嘛的、需要哪些参数、有什么限制”模型才能正确调用。工具返回结果要经过校验层防止模型被恶意结果误导或把异常数据带入下轮上下文。这个放在架构图里就是一层工具注册中心、工具调用鉴权、结果格式化。所有外部能力都从这一层出去不许业务代码直接裸连外部API。2.5 模型基础设施层让模型服务变成可靠依赖最底层是模型服务本身。这里要画的不只是一个“模型”框而是围绕模型的一切基础设施。首先是模型API或自建推理服务。无论用云厂商的模型API还是自建推理服务都要封装成独立的模型网关统一处理鉴权、限流、超时、重试、缓存。其次要考虑上下文计算和Token预算输入的每一轮对话都要消耗Token超长之后要么截断要么压缩这层要有专门的处理器。包含内容安全的护栏也要放在这层。输入侧做敏感内容过滤输出侧做合规检查这不是可选项而是AI应用上线的必选项。模型返回内容在到达用户之前要过一道输出安全过滤。这里能直观看到成本压力。假设一个请求平均消耗2000个输入Token和800个输出Token按通用模型API价格粗算单次成本可能在一两分钱到几毛钱不等。单个请求看不见钱但日活一万、每天几百万次调用时成本就是日结账的数字。所以模型基础设施层一定要带“Token计量和成本看板”不然到月底财务找上门才意识到问题就晚了。3. Agent编排是架构图里最容易“画小了”的部分3.1 Agent runtime做对的四件事现在聊AI应用离不开Agent。但很多架构图把Agent画成一个简单的调用链用户输入→LLM→工具→返回这就把Agent画小了。一个能跑稳定的Agent runtime核心是四件事。第一循环控制。Agent的本质是模型和工具之间的多轮互动模型提出要调工具工具返回结果模型再根据结果决定下一步。这个循环必须有硬上限——最多调用多少次工具、整个任务最长执行多长时间。我见过不加循环上限的Agent模型在修正一个错误参数时反复尝试七八次浪费调用次数用户还在干等。第二状态持久化。Agent的任务进度不能只存在内存里。实例重启、用户刷新页面、任务长时间挂起都需要能从外部存储恢复进度。Agent每完成一个步骤就把当前状态写入会话存储。第三工具调用的可靠性。工具不是百分百成功的。网络超时、参数被模型填错、第三方服务返回异常Agent必须能识别失败类型并决定重试、换工具还是向用户求助。这里要给每个工具定义清晰的错误码。第四安全护栏。模型在循环调用工具时存在被提示词注入利用的风险——一段混在输入文本里的恶意指令试图诱导模型调用不必要的工具。Agent runtime要对输入内容做隔离对工具调用权限做最小化授权对敏感操作强制人工确认。3.2 Agent并发治理把Agent当作有状态服务来设计“AI客服并发扛不住”是大家常讨论的问题这里的根子多数时候不在模型API而在Agent编排层的设计。很多人直观地把Agent理解为“一次用户请求模型回答结束”。但实际上一个Agent任务往往包含多次模型调用和多次工具调用。比如一个数据处理Agent可能要经历“理解需求→调用查询工具→分析结果→再次调用筛选工具→生成报告”一次任务里模型被调用5到8次。并发一高模型API的QPS消耗会成倍放大。我在设计并发方案时核心思路是Agent实例无状态会话状态进外部存储。所有Agent worker可以随意水平扩缩容任意实例接手任意会话都能从存储里恢复进度。这样并发瓶颈就从“Agent服务本身”转移到了两个可控点——模型API的吞吐上限和状态存储的性能。算一笔账。假设某个模型API的并发上限是每分钟处理6000次推理请求平均每个Agent任务要调用模型8次。那么这套API能支撑的并发Agent任务数就是一分钟内750个任务同时处于活跃执行中。如果业务峰值预期是2000个并发会话要么提高模型吞吐、要么减少单任务的模型调用次数。这种数字必须先算清楚再决定架构规模。长任务的背压处理也很关键。同步请求路径只适合交互性强的短任务像“帮我整理一个月的数据报表”这种长任务应该走异步任务队列用户提交任务编排层入队队列消费者拿任务后调度Agent去执行执行进度通过WebSocket或轮询回传。这样前端不会因为长时间等待而断连后端也能按照队列深度平滑控制并发。3.3 人机确认点架构图里要专门画“人”这个细节我吃过亏多说一句。两年多前做一个自动化流程应用当时图里把Agent设计成“从理解到执行全自动”上线前产品才说要加人工审核环节结果只能在主流程里硬塞一个审核状态直接破坏了原有状态机。现在我在架构图里一定会专门画一条回路Agent执行到敏感操作→进入确认队列→等待用户在界面上点击确认→确认后继续执行。这条回路要作为一等公民出现在图里而不是事后补丁。哪些操作需要人工确认在设计阶段就要列清单涉及资金的操作、对外发送消息、删除数据、修改权限都属于高危动作。4. 四张子图把关键链路单独放大否则主图没法看主图画五层结构没问题但如果所有细节都堆在主图上图就变成“蜘蛛网”了没人看得懂。我会给四条关键链路各画一张子图每张图聚焦一个流动过程。4.1 RAG链路子图召回-重排-生成不是串联那么简单RAG检索增强生成是AI应用最常见的知识增强方案。很多架构图就画三个框文档库→向量检索→LLM生成。但实际跑起来根本不是一条直线。完整链路应该是用户提问→查询改写用模型把模糊问题改写成更适合检索的形式→并行检索向量检索关键词检索→合并结果→重排用重排模型把相关性低的片段排掉→上下文拼装→生成回答。这中间有两个关键分支。第一检索结果为空或相关性都很低时要不要如实告诉用户“知识库里没有相关内容”而不是让模型编造第二检索片段拼装后超过模型上下文窗口怎么办——是要截断、摘要压缩还是分层注入架构图里要把“知识更新链路”画出来文档上传→解析→切块→向量化→写入向量库→版本管理。很多应用只画了查询链路没画更新链路结果就是上线后知识库里永远是旧数据。我建议RAG子图至少标注两个数据存储向量库存语义索引关系型或文档库存知识原文和引用信息。生成回答时要能溯源到原始文档位置否则用户追问“你凭什么这么说”时无从查起。4.2 流式响应链路子图从模型字节流到前端事件流式子图要画清楚一段字节流的完整旅程。模型推理服务不断吐出增量token这些内容不能一股脑儿直接丢给前端。流式网关要做几件事缓存必要的事件元数据、把累计文本转换成前端可消费的事件流、处理断线重连。前端收到增量内容后要渲染出打字机效果同时处理Markdown格式化、代码块折叠、引用标注。这条链路里最隐蔽的坑是“中间层缓存整个响应”。有些团队为了让日志更完整在网关层把整个模型输出缓存下来再转发结果第一个token延迟增加了用户体感明显变慢。流式传输的设计原则是数据过手不留日志和审计用旁路异步处理。画这条子图时标注清哪一段是双向通信用户发消息和接收流式返回哪一段是单向流即可。4.3 记忆链路子图短期记忆和长期画像必须分开存AI应用对记忆的需求越来越普遍。但记忆不能是一个模糊概念架构上至少要拆成两级。短期记忆对应当前会话内的上下文。存在Redis这类高速缓存里设置过期时间默认比如30分钟无操作就失效。这类记忆内容原文存储即可不需要做提炼。长期记忆对应跨会话的用户偏好、历史事实。比如用户喜欢的语言风格、常居住的城市、之前提过的重要信息。这类记忆要存储在关系型数据库或文档数据库里写入时做结构化抽取读取时按需只检索当前相关的片段。记忆的写入不能同步阻塞对话生成。模型回复完之后可以异步触发记忆更新任务——解析对话、抽取关键事实、更新用户画像。这条异步链路要在记忆子图里单独画出来不然排查“为什么用户上一轮说了喜欢简洁风格这轮回答还是啰嗦”时完全找不到入口。4.4 可观测链路子图没有Trace的AI架构图等于没画AI应用比传统应用难排查得多。原因很简单同样的用户输入模型今天和明天的回答可能不同工具偶发超时RAG召回质量波动。这些问题没有Trace根本定位不了。可观测子图要覆盖三类数据。第一类是链路追踪每次请求从进入接入层开始给每个关键节点埋一个spanPrompt组装耗时、模型调用起止、工具调用结果、RAG各个环节的耗时和召回数量。第二类是质量评估用户对回答点了赞还是踩、有没有复制结果、有没有追问修正这些反馈信号要回流到评估系统。第三类是成本观测按业务线、按功能模块统计Token消耗和费用每周出报表。评估体系的建设要跟测开配合。我在项目里会把评估测试集纳入代码仓库每次Prompt或工具调整都在CI里跑一遍回归测试用测试集里的标准答案计算准确率和格式合规率。线上准备流量回放环境把真实请求离线重放对比不同模型版本的回答质量。这套东西看着重但不做的话AI应用基本处于“改完不知道好坏”的裸奔状态。5. 画完架构图之后真正折磨人的是这几个小问题5.1 Prompt和工具描述要进版本库和代码走同一条评审线有次线上用户反馈回答风格突变查了半天原因是产品经理直接改了线上Prompt配置没经过任何评审。Prompt是AI应用的“逻辑的一部分”它和代码一样有副作用、需要回滚、需要测试。我现在要求所有Prompt模板和工具描述以配置文件形式纳入版本库。改动也走代码评审流程合并后通过配置中心发布支持一键回退。5.2 上下文窗口本质是昂贵的临时内存每次把内容塞进上下文都是在消耗Token预算。很多团队设计时没算这笔账结果上下文越来越大延迟越来越高成本成倍翻。我给应用设每个请求的Token预算上限。系统指令固定占多少、结构化数据占多少、历史对话占多少、RAG片段占多少各分一块。预算超了就得做取舍优先保留系统指令和与当前任务直接相关的数据历史对话可以做摘要压缩示例可以砍掉。动态预算比固定值更实用简单任务用小预算复杂任务放开大预算不同模型能力对应不同预算档位。这个配置要落在每一轮请求的组装逻辑里而不是写死在代码中。5.3 部署形态必须影响架构图里的内容同一套逻辑部署方式不同架构重点完全不同。用云上模型API架构图的重心在编排层和模型路由层要重点画API边界、限流、成本控制。自建开源模型推理基础设施层变成重点要画GPU资源、队列调度、并发吞吐。端侧小参数量模型架构图要把模型画进客户端里编排逻辑下沉到App端云端只负责同步和兜底。最怕的是架构不区分部署形态一套图上画“云API自建端侧”混在一起看着全面实际没指导意义。架构演进我建议渐进式第一版先跑通“接入层编排层单模型API”的极简链路第二版再插入RAG和工具调用第三版再把Agent编排和记忆系统做进去。每次只动一层排查问题就永远有清晰边界。5.4 最后说点个人体会AI应用架构设计跟传统后端架构最大的不同是“不确定性”无处不在。模型输出不保证稳定、工具调用可能失败、检索质量波动明显、成本随流量放大。架构图唯一的目的是把不确定性约束在有限的层和链路内让团队每次只需要面对一个不确定性而不是所有不确定性同时爆发。我自己画架构图时还有一个习惯先用很窄的布局把MVP链路画通再逐步加宽加厚。接口和边界先定死组件和模型随便换。这套思路帮我跨过了不少项目从Demo到生产的坎儿希望能对正在设计AI应用架构的你也有帮助。
