图解AI应用架构设计
去年下半年开始，我密集地帮几个团队做AI应用的技术方案评审，发现一个很有意思的现象：大家张口闭口都是大模型、Agent、RAG，可真到要画一张纸的架构图时，全都卡住了。有人画出来的是一堆箭头指向同一个框，有人画出来的跟传统CRUD系统几乎没区别。问题出在哪？不是技术不够，而是脑子里缺少一张完整的AI应用架构地图。
这篇文章我就拿自己画过、也迭代过无数次的架构图当例子，把AI应用从接入层到模型层、从上下文管理到Agent编排，一层一层拆开讲。不讲虚的概念，只讲你在真实落地时必须在架构图上体现的东西。适合正在做技术选型、画方案图、或者已经写完Demo准备往生产环境推的工程师和技术负责人。
1. AI应用架构与传统架构的分水岭在哪里
先说一个最反直觉的结论：AI应用的架构设计，核心难点根本不是模型本身，而是模型之外的“接口设计”和“状态管理”。
传统互联网架构的底座是数据库，一切围绕确定性事务。用户点了个按钮，后端查表、校验、写库、返回JSON，每一步都是可预测的。你可以用ER图描述数据模型，用接口文档描述契约，用链路追踪描述请求走向。
AI应用完全不是这个玩法。你对着模型说了一句话，它返回的是一段概率分布采样出来的结果，同样的入参可能产出完全不同的响应。这带来三个传统架构里几乎不需要操心的问题：
- 响应不可控：模型输出的格式、内容长度、语气都可能漂移，你的下游代码必须对“不稳定的上游”做防御。
- 状态不在数据库里：多轮对话、上下文窗口、向量索引，这些状态的载体从MySQL变成了Memory、Redis、Vector DB的组合体。
- 成本不像CPU那样恒定：一次接口调用消耗多少Token，取决于用户输入多长、模型思考多久、你塞了多少历史上下文，账单波动极其剧烈。
所以AI应用架构图不能照搬经典的分层架构。洋葱模型、六边形架构那一套不是不能用，而是必须再加一层“模型网关”和“上下文管理层”，整个图才立得住。
这也是为什么我建议团队在画架构图之前，先统一一个认知：AI应用架构本质上是“能力编排架构”，不是“数据流转架构”。核心问题不是你有哪些数据表，而是你如何把用户意图拆解成对模型、对工具、对知识库的调用序列。
2. 一张架构图的六个层次，每个层次解决一个核心问题
我习惯把AI应用架构图拆成六层，从下往上依次是接入层、编排层、模型层、上下文层、工具层、可观测层。注意，这个顺序不是从上到下调用，而是从底层能力往上层业务推演，画图的时候你把用户放在最顶上，从上往下画调用关系，但设计推演的时候从下往上思考。
这六个层次我逐一展开说一下，每一层在架构图上都必须有明确的组件和边界，不然出了故障你连锅都找不到。
2.1 接入层：别只画一个Chat窗口
接入层是用户跟你的AI应用之间的通道。很多入门架构图只画一个Web页面加一个API，这远远不够。真实场景里，你的AI能力可能同时服务C端聊天、B端工单助手、内部知识库问答、甚至自动化脚本批处理，每个入口对响应时间、并发量、认证方式的要求完全不同。
我在架构图上会把接入层拆成三块：交互终端（Web/H5/IM/API）、网关路由、会话管理。网关路由负责把不同来源的请求分发到对应的编排流程，会话管理负责维护用户级的状态标识。这里很容易被忽略的是流式响应的接入设计，大模型生成内容动辄好几秒，用户端几乎都要求流式输出（SSE或者WebSocket），传统HTTP短连接根本扛不住。接入层的架构选型必须前置把流式通道设计进去，否则后期改造会非常痛苦。
2.2 编排层：整个架构图的灵魂
如果说传统架构的核心是业务逻辑层，AI应用的灵魂就是编排层。编排层回答了架构图上最关键的几根连线：用户的一个请求，该调用哪套流程？流程里哪些步骤走LLM，哪些步骤走确定性代码，哪些步骤调外部工具？
以实际场景举例，一个合同审核助手，用户上传一份合同，你期望它做的事包括：解析合同文本、抽取关键条款、比对公司合规标准、生成风险报告。这些步骤不能一股脑塞给一个大模型让它自由发挥，你得编排成一条链路：
# 伪代码示意：审核流程编排 def review_contract(file): content = parse_document(file) # 确定性步骤：解析格式 terms = llm.extract_terms(content) # LLM步骤：抽取关键字段 risks = matcher.check(terms, rules) # 确定性步骤：规则校验 report = llm.generate_report(risks) # LLM步骤：生成报告 return report这种“LLM加上确定性代码交替执行”的编排，就是Agent工作流的基础形态。架构图上的编排层，需要画出流程节点、节点间的数据流、每个节点使用的是模型还是工具，以及最关键的分支切换逻辑（什么时候需要用户确认，什么时候自动放行）。画清楚这张图，你的AI应用就不再是黑盒。
2.3 模型层：不止一个大模型框
模型层在架构图上最容易被画成“一个模型框”就完事，这是大忌。我在评审方案时，只看这个团队在架构图里画了几个模型框，大概就能判断他们对生产的理解程度。
成熟的模型层应该画出至少三类模型服务：主力对话模型（负责理解和生成）、辅助模型（负责分类、提取、总结这类确定性较高的子任务）、Embedding模型（负责向量化）。为什么要拆？因为不同任务的性价比差别太大了。复杂推理用大参数模型，简单分类用小模型，向量化用专用模型，成本和效果都能兼顾。更进一步，架构图上还应该画出模型路由机制——根据任务类型、用户等级、实时成本，把请求动态调度到不同模型服务商或者不同规格的模型上。
2.4 上下文层：最容易低估的一个层次
模型本身是无状态的，你上一轮跟它说了什么，这轮它全忘了。多轮对话、知识库问答、跨会话记忆，全靠上下文层兜着。这个层在架构图上通常由三部分组成：短期会话上下文、向量数据库、长期记忆存储。
我可以很直接地说，十个做AI应用研发的团队里，至少有五个是把所有历史消息一股脑拼到Prompt里塞给模型。前几轮没问题，到了第20轮Token爆炸，账单爆炸，响应也变慢。正确的做法是在上下文层做策略性管理：短期上下文放Redis或者进程内存，做滑动窗口截断；需要长期参考的信息做摘要压缩或向量化存进向量库；用户的偏好和事实性信息写进记忆库，按需加载。
2.5 工具层：AI从聊天走向行动的必经之路
工具层就是你给模型配的“手和脚”。模型再聪明，它也没法自己去查天气、查库存、发邮件、改订单状态，这些动作全部要通过工具调用（Function Calling/Tool Use）来实现。
架构图上的工具层，需要画出工具注册中心、工具的认证鉴权、工具调用的审计日志。还有一个很多人忽视的问题：工具调用的可靠性。模型返回的JSON参数不一定合法，工具本身可能超时或报错，你需要一层“工具执行器”来做参数校验、重试、降级。我在系统里习惯在工具层和模型层之间加一道中间层，模型只负责生成工具调用意图，真正的执行和校验由中间层完成，这样模型就算抽风了，也不会把脏数据打进你的核心系统。
2.6 可观测层：没有它，AI应用就是盲人摸象
传统应用的可观测性看QPS、延迟、错误率就够了，AI应用远远不够。你还得看Token消耗、模型响应质量、上下文利用率、工具调用成功率。更关键的是，模型每一次输出都可能不一样，这个“不一样”本身需要被追踪和评估。
我在架构图里一定会在最右侧放一条纵向的数据通道，把每一轮请求的输入输出全部落日志，同时采集打分结果和用户反馈数据，输出到评估系统。否则你就无法回答两个最基本的问题：这个版本改动到底变好了还是变差了？那些说AI不靠谱的用户，到底是卡在哪个环节？
3. Token不是网络带宽，是每一张架构图都要标注的预算线
很多团队画完架构图之后，连预估成本都做不出来，原因就是没有在图上的关键链路标注Token消耗。Token这东西有点像云服务器的流量费——平时毫不起眼，一到月底账单吓死人。但比流量费更麻烦的是，Token的消耗直接决定了你的产品该不该做某项功能。
我拿知识库问答举个典型场景。假设你的架构图上画了“召回-重排-生成”三段式RAG流程：
![RAG流程文字示意] 用户问题 → Embedding检索Top-K → 重排模型筛选 → 拼装上下文 → 大模型生成
每一段都在消耗Token，其中最容易忽略的是重排环节和日志记录环节。有些团队用的上下文7000多Token，把全部召回结果塞进去让大模型自己挑，看似省了重排服务费，实际上每轮都多了几倍的输入Token成本。架构设计阶段，你就得在图上把每一跳的Token成本写出来，然后对比“全量塞入”和“先重排再拼接”这两种方案的成本曲线。
还有一个更隐蔽的坑：Embedding模型产生的Token，很多人以为是免费的，其实每次向量化都在计费，而且通常按百万Token计价。知识库动辄几万个文档，全量重建索引的投入相当可观。架构图上必须画出“数据入库”和“数据更新”这两个离线流程的性价比考量——多久全量刷新一次，增量更新怎么触发。
Token预算线还会反过来决定你的业务设计。比如你设计一个客服助手，如果用户问一句平均要消耗5000 Token，单次成本大约几毛钱，那么日活一万用户的话，光模型成本就高得吓人。这时候架构上就得引入分类路由：简单问题走轻量模型（几十Token成本），复杂问题再走大模型。这个设计不是在代码层面做的，是在架构图阶段就要画出来的决策节点。
4. Agent工作流怎么落图：编排、并发与多Agent协作
热搜词里有个“AI agent怎么扛并发”，正好戳中很多团队的真实焦虑。单机版Agent Demo跑得很好，一上线被几百个用户同时点爆，各种超时和重试把资源全部拖死。要解决这个问题，你得先把Agent工作流从架构上拆开。
Agent的本质是“感知-决策-行动”的循环体。感知靠模型理解输入，决策靠推理规划步骤，行动靠调用工具。这三个阶段在架构图上对应的组件完全不同，链路也呈波浪形——不是一条直线跑完，而是循环多次、动态跳转的。既然链路是动态的，你就不能用传统同步调用把所有步骤串在一起，否则线程被无限期占用，并发一上来必挂。
我的经验是：把Agent执行过程拆成有状态任务，放到消息队列里异步跑。用户请求进来先创建任务，立刻返回“任务已接收”，真正的Agent编排通过队列分发给工作节点执行。中间状态的保存放在Redis里，每一步编排结果都有checkpoint，这样就算Worker挂了，任务还能从断点恢复，而不是整条链路重来。
关于多Agent协作（多AI协作），架构图上要特别注意区分“并行”和“协作”两类模式。
- 并行模式：多个Agent各干各的活，比如一个做资料检索，一个做数据分析，最后合并结果。这种模式架构相对简单，核心设计点是结果合并的时序。
- 协作模式：Agent之间有依赖关系，前一个Agent的输出作为后一个Agent的输入，比如一个Agent负责拆解任务，另一个Agent负责执行具体步骤。这种模式在架构图上必须画出状态轮转和消息传递的通道。
不管是哪种模式，我都建议设置一个“协调者”角色，负责统一管理子任务的创建、合并、超时和取消。否则Agent一多，互相等待、重复执行、死锁问题全都会冒出来。
5. 模型与工具之间的“胶水层”：降级、兜底和灰度
架构图画到模型层和工具层之后，真正拉开差距的是“胶水层”设计——也就是模型路由、降级策略、灰度发布机制。这一层在很多架构图里根本没体现，但它恰恰决定了你系统在真实故障场景下能不能活下来。
模型服务商的API稳定性，说实话，没有哪家敢跟你保证100%。网络抖动、限流、服务升级导致接口异常，这些在AI应用里比传统系统更常见，因为你的关键依赖是一个你完全没有掌控力的外部服务。架构图上必须画出多供应商容灾通道：
| 故障场景 | 应对策略 | 架构上的落点 |
|---|---|---|
| 主力模型超时 | 自动切换备用模型 | 模型路由层维护健康度状态 |
| 备用模型也失败 | 返回兜底话术/简化模型 | 降级逻辑在编排层预埋分支 |
| Embedding服务异常 | 暂时跳过向量检索，走关键词 | 上下文层降级开关 |
| 单次请求Token超限 | 上下文压缩或截断 | 上下文管理层触发压缩策略 |
灰度发布这一块也特别值得画进架构图。大模型的升级不像代码发布，你没法准确预测换了模型后端之后线上效果会怎么变。所以正规的做法是模型路由层支持按用户比例分流：把5%的流量切到新模型上，跑一段时间看评估指标，再慢慢放大到全量。这个流程必须在架构图上体现出来，否则就会变成“直接改配置切全量”这种高风险操作。
另外，你在胶水层还应该设计一个“输出校验器”。大模型不像传统函数那样按契约返回数据，它有可能生成格式错误的JSON、幻觉出来的实体、或者违反约束的敏感内容。我见过太多团队把模型输出直接用，结果下游解析报错、数据库写入脏数据，最后只能靠人工清理。输出校验器可以做三件事：JSON Schema校验、关键指纹匹配、非法内容过滤。校验不通过就触发一次重生成，还是不行就走兜底逻辑。这个设计放进架构图，你的系统稳定性能上一大截。
6. 可观测性不止是日志，要把“模型表现”当一等公民来监控
最后重点说说可观测性这块，因为这是AI应用架构图里最容易被画成“加个监控就行”的部分。传统监控体系看的是系统指标，AI应用还得加一个维度：模型表现指标。
我在系统里把AI可观测性拆成四个层面：
第一层是系统指标。QPS、延迟、错误率、GPU或API配额使用率，这部分用传统的Prometheus加Grafana就能解决，不再赘述。
第二层是成本指标。Token消耗量、按模型维度的花费、按用户维度的花费、按功能维度的花费。我强烈建议从第一天就把Token计量埋进去，否则后期根本算不过来账。很多产品卖的是包月套餐，如果不按功能看成本，你根本不知道哪些用户是“吞Token怪兽”，哪些功能是亏本在跑。
第三层是质量指标。这是AI应用特有的，包括用户反馈、点赞点踩、答案采纳率、语义相似度比对。架构图上需要画出一条数据回流路径，把线上样本定期收集到评估集里做离线评测。
第四层是交互过程追踪。模型每一步的调用顺序、工具输入输出、上下文快照，全部都要能追溯。大模型出了问题，你没法像查堆栈一样查到准确的那一行代码，只能靠完整的链路回放来定位。所以日志里不仅要记请求响应，还要记Prompt快照和当时用的上下文。
“AI测试开发”这个方向现在越来越重要，本质上就是把评估流程工程化。架构图里画评估系统，不需要复杂到端到端自动化，但至少要有一个样本库、一个标注界面、一个跑批任务的服务。每次模型升级或者Prompt调整，都拿同一批样本跑一遍对比，形成分数报告。没有这套机制，你的所有优化都是靠感觉。
对于一个刚开始做AI应用的小团队，我建议可观测性先从最小闭环开始：每一项模型调用打印结构化日志，包含模型名称、Token数、延迟、用户ID；每天晚上跑一个脚本把当天日志汇总成成本报表；每周人工抽样看20条典型对话做质量评估。坚持一个月，你对系统的理解会远超那些接了API就开始开发的团队。
总结
这篇文章从一个实际存在的痛点出发——看着身边很多AI应用的项目复盘，团队成员对怎么画架构图、怎么定位边界、怎么管理模型与代码的交互，依然是一头雾水。架构图不是画给评审看的摆件，它是你把一个模糊的“用AI做点什么”的念头，变成一台确定性机器的过程。
从接入层到编排层，从上下文到工具链，从Token预算到可观测性，我画过太多版本，也推翻过太多版本。现在的习惯是：每接一个新项目，先不写代码，直接坐下来把六层架构和关键连线画满一张白板纸。画不清楚的地方，就是设计还没想清楚的地方。
下次你的团队里再有人问“AI应用架构到底怎么设计”，你可以把这篇文章转给他，然后开个会，一起在纸上把六层画全。一张图画完，项目大概率就成了一半。
