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和语音转文字要专门的模型；代码生成和通用聊天可能又各有所长。这时候就需要一个模型路由层，把所有模型接入统一封装，上层应用不直接依赖某一个模型品牌。

模型路由层要维护一份能力矩阵，大致像下面这样：

路由规则可以很朴素：按意图分类、按输入长度、按预算上限、按当前负载。真正要把多模型协作（也就是现在常说的多AI协作）落地，编排层还要定义模型输出的结构化协议——不能一个模型吐JSON、另一个模型吐纯文本，路由层之后必须跟着一个输出解析器，统一校验再往上层传。

2.4 工具与数据接入层：MCP式的统一协议

AI应用和传统应用最大的区别之一，是模型需要动态调用外部工具。查订单、发邮件、查天气、搜索知识库，这些能力不可能预设在模型里，必须通过工具调用来完成。

第2.4层就是把数据库、向量库、外部API、内部微服务统一封装成“工具”。我强烈建议这一层用统一协议来暴露，而不是每个工具一套接入方式。现在MCP（Model 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根本定位不了。

可观测子图要覆盖三类数据。第一类是链路追踪，每次请求从进入接入层开始，给每个关键节点埋一个span：Prompt组装耗时、模型调用起止、工具调用结果、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应用架构的你也有帮助。