做AI应用到现在最让我头疼的往往不是模型效果不够好而是架构图上画不清一条失败的链路该怎么走。有一次评审AI客服的架构方案PPT里分层图非常漂亮接入层、服务层、模型层、数据层框和框之间的箭头全是笔直的实线。我提了一个很普通的问题——如果大模型输出了一段语气流畅但完全错误的内容这段错误由谁发现、由谁兜底、怎么回到上游修正会议室安静了很久。不是大家不懂技术而是图上根本没有数据回流的路默认模型永远是对的。这件事我复盘了很久。AI应用架构设计和传统后端架构最大的差异不是多了一个模型框而是整个系统的确定性假设被打破了。数据库查询是确定的函数调用是确定的大模型生成却是概率性的。承认这一点之后所有架构决策都不一样了路由要留降级推理要留校验数据要留闭环。这篇文章用图解的方式把一张AI应用架构图从下到上拆开讲清楚每一层该放什么、为什么这么放、链路里哪些位置最容易出事以及从单体Prompt围绕到多Agent协作的演进路径。适合正在画架构图、做技术选型的工程师和架构师也适合想搞明白AI项目为什么这么复杂的产品和技术负责人。1. 先说清楚一件事AI应用架构和普通后端架构的根本分歧在哪1.1 确定性系统与概率系统的架构代差传统后端系统的架构设计基础是确定性。参数校验通过就执行执行就有结果结果固定可复现。也正因为每个模块的输入输出都可预期拆解服务边界才容易用户、订单、支付、库存彼此之间依赖清晰架构师主要解决流量、容错、一致性这三件事就够了。AI应用不一样。一个对话系统、一个知识问答、一个智能客服核心输出是模型生成的文本和结构化数据这个结果在概率上可能正确也可能不正确。模块之间的调用关系不再是你传数据我给确定结果而是你传意图我尽力生成结果同时附带不确定性风险。于是架构上出现了传统系统几乎不用考虑的三样东西校验层、兜底分支、反馈闭环。落到画图上我的习惯是每个AI结果的出口都画一个菱形校验节点每个校验节点至少引出一条旁路——要么是兜底话术要么是旧的规则引擎结果要么是人工交接——而不是直接把模型输出画成实线指向下一个框。很多团队架构评审被挑战往往就是漏了这条旁路。1.2 概率性输出带来的三个架构硬约束第一个约束是延迟不可控。同样一个用户问题模型推理的耗时不是固定值上下文越长、生成token越多时延越高波动也越大。业务层不能用同步等着拿结果的心态来设计得给异步化、流式输出、并行检索留空间。第二个约束是成本随调用量线性膨胀。每一次推理都对应GPU或API费用token就是钱。如果架构层面对上下文不做裁剪、对缓存不做命中率设计成本会在流量上涨后迅速反噬。我见过不止一个项目业务跑赢了流量成本却跑死了利润。第三个约束是错误模式不可穷举。传统Bug有明确的位置AI的错误来自模型本身可能表现为幻觉、格式不符、内容安全、答非所问靠try/catch解决不了必须在链路里嵌入校验和回退策略。这三个约束几乎决定了后面每一层的设计原则。1.3 架构图最该画出来的是边界与退路坦白讲我看过很多AI生成的架构图框很多线很均匀但信息量有限。一张真正有价值的架构图应该回答三个问题流量入口是谁主处理链路上每个节点出错后退路在哪数据最终怎么回流到数据集和评测里。如果一张图画完这三个问题有一个答不上来那图就只是装饰品。所以后面所有章节我都围绕这三个问题来讲分层怎么分数据流怎么走阻塞点怎么处理以及Agent化之后整个图要发生什么变化。2. 全景图四层架构从下到上每一层都放该放的东西2.1 接入层多模态入口的归一化与护栏今天的AI应用入口远不止一个文本框Web、App、企业微信、呼叫中心、语音、图片形态各不相同。接入层的职责有两个协议归一和护栏设置。协议归一好理解把不同渠道的请求转换成统一的内部事件结构避免下游被渠道差异绑架。护栏则容易被忽略限流、鉴权、输入长度控制、敏感内容过滤必须在第一道口子上完成。我特别强调输入长度控制。很多线上事故不是模型不行而是用户把上万字文本直接塞进prompt推理时延飙升、成本爆炸。接入层加字符数上限、附件大小限制、并发配额用最笨的手段把风险挡在门外。画图时接入层放在最上面旁边接限流中间件和格式转换器这两块没有太多花活但它们是整个架构的门卫。没有护栏的接入层相当于把门敞开让流量直接冲击模型出事只是时间问题。2.2 编排层最容易被低估的大脑编排层很多资料里叫Agent层或逻辑层几乎决定了AI应用聪明不聪明。它负责理解意图、拆解任务、决定调用哪个模型、判断要不要检索、怎么组织上下文、如何调用外部工具、如何校验模型输出并决定重试还是降级。为什么它重要因为大模型本质上是技能包它不知道自己下一步该做什么。编排层把这些技能包按业务目标组织起来。你可以把它想象成机场塔台模型是跑道上的飞机飞哪条航线、降落在哪个跑道、天气不好怎么备降都由塔台调度。很多团队第一版架构里没有独立的编排层把逻辑写在业务代码里业务一复杂就成了面条代码。架构图上编排层是实线箭头最密集的地方。我建议在这个框内单独画出三个组件上下文管理器管短期记忆和token配额、工具调度器管外部API调用、校验策略器管输出审核。这三个组件分别对应Agent系统的记忆、工具、自我检查能力。2.3 模型层路由、部署与降级策略模型层是大多数人最关注的实际踩坑也最多。这一层有两个决策模型路由和部署方式。模型路由解决什么问题用什么模型。简单任务可以用规则复杂场景要综合成本、任务类型、历史成功率来路由。比如复杂推理走大参数模型意图分类这类简单任务走中等模型没必要所有流量都压在高成本模型上。部署方式则是一道规划题调用云API还是私有化部署。私有化部署意味着自己管GPU、弹性扩缩容、推理引擎优化好处是数据可控、长链路成本可控云API的好处是上线快、不用运维适合快速验证阶段。模型层还必须有降级。我实际项目里一定会画一个虚线分支主模型超时或不可用自动切到备用模型或本地轻量模型再不行就退到规则引擎或人工。没有降级的模型层等于把业务的开关完全交给了第三方。这一点做模型部署和运维的人体会最深。2.4 数据层向量检索、记忆与评测的落脚点数据层不只是数据库。对AI应用来说它至少承担四个职能业务数据存储、向量检索召回相关知识片段、历史会话存储供上下文学习和评测回放、评测样本集。向量库pgvector、Milvus、Qdrant等解决语义召回围绕它的还有文本切片策略、embedding模型选择、重排逻辑。这里说一个容易忽略的点评测数据必须入库。架构演进过程中没有历史数据就说不清新方案到底比旧方案好多少。我会在数据层单独划一块评测与运营数据集把线上真实反馈、badcase、人工标注结果沉淀下来。这是后续一切优化和架构演进的燃料。2.5 实线与虚线的语言如何在一张图里表达主链路与兜底链路画架构图要有一套自己的绘图语言团队内部最好约定统一实线箭头表示正常流量必走路径虚线表示降级、旁路或异步回写路径菱形节点表示条件判断颜色区分模型服务和业务服务。这样一张图的信息量立刻翻倍。举个例子编排层正常路径是工具调用→模型生成但工具超时时虚线分支指向直接让模型凭已有上下文回答主模型不可用模型层的虚线分支指向备用模型或规则引擎。这套语言不统一审图时就会为这条线什么意思吵半天。画完图站在图前把请求流程走一遍每条实线都走通每条虚线都走到这张架构图才算有底气。3. 数据流才是心脏一次AI请求的完整旅程3.1 从用户问题到上下文拼装RAG链路的五个关键跳点RAG检索增强生成是当前AI应用最主流的增强手段。一次典型请求的数据流我习惯画成五个跳点。第一步问题解析。接入层拆解用户这句话到底想问什么可能附带意图分类结果。很多系统在这里做查询改写把口语问题改写成适合检索的短查询。第二步向量召回。把查询转成向量到向量库取TopK相关片段这个阶段追求召回率宁多勿缺。第三步重排。对候选片段用重排模型或规则精排挑出最相关的片段过滤低分内容。第四步上下文拼装。把选出来的片段、历史会话、系统提示词拼成一个prompt这一步决定模型看到什么直接影响答案质量。第五步推理与校验。模型生成回答过格式校验、关键信息核对才算完成。这五个跳点里前四个很容易在架构图上被简化成一个RAG框但真正出问题的往往在拼装环节——片段冲突、token超限、历史会话污染。所以我画图会把上下文拼装单独画一个节点旁边标注token占用估算值。这一处细节救过我好几次。3.2 流式输出如何改变架构的每一根神经AI对话系统几乎都要流式输出token逐个或逐段返回不然用户等待感太强体验直接崩。但这会给架构带来一连串变化网关不能做聚合缓冲等单一响应要支持协议转发和中间过程透传编排层不能等完整结果再决策要能边生成边校验日志系统也不能只记一个最终响应。首字时延TTFB成为新的核心指标。模型推理之前的检索、拼装、鉴权都得压缩在几百毫秒内完成否则用户先看到转圈圈已经想关页面了。我做架构评审时会重点看检索和拼装是否并行路由决策是否在进入模型前完成。这些时序关系我建议在架构图旁边配一条时间轴把检索耗时、路由耗时、首字耗时、总耗时标注清楚。这个习惯对定位问题极其有帮助。3.3 可观测性设计让一次问题定位在五分钟内完成AI应用排障比传统系统痛苦得多一个问题可能是检索错了、prompt拼错了、模型幻觉了也可能是工具调用失败肉眼很难看出来。我的方案是全链路trace_id从接入层开始为每个请求生成全局ID贯穿编排、检索、推理、输出校验。日志里记录每个节点的输入摘要和输出摘要尤其要记录prompt内容方便事后复现。还要记录成本指标一次请求消耗多少token、调用哪个模型、耗时多少。当用户投诉为什么越来越慢时这些数据能快速定位是上下文膨胀、模型路由错误还是检索耗时上升。在架构图上可观测性不是某一个框的职责是横向贯穿所有层的横切面可以用一条横向色带标出链路埋点。这块缺失的架构图运维时会非常痛苦。4. 请求链路上的三个阻塞点以及架构解法4.1 模型推理时延并发、排队与首字耗时多个用户同时请求大模型时最容易出现的问题是排队和超时。模型推理是算力消耗型操作并发能力有限尤其私有化部署GPU卡数有限请求一多就排队P99时延直线上升。架构层面的解法我有四类。异步化把不要求实时的任务丢进队列慢慢处理。流式化让用户先看到首字缓解等待感。语义缓存对相同或相似问题直接返回缓存结果大幅降低真实模型调用量缓存命中率做好的服务能省40%以上成本。批处理把多个短请求凑一起推理提高吞吐但延迟敏感场景要慎用。画图上怎么表现模型层到模型API的连接要加并发限流标签旁边画一个独立队列节点编排层在调用模型前先查语义缓存命中则直接绕开模型层。这些都是小改动但能在高峰期保住系统的命。4.2 上下文窗口的成本膨胀短期记忆与长期记忆分层多轮对话里每轮把所有历史都塞进prompt是最常见也最昂贵的做法。token数随轮次线性增长成本随之上升上下文接近窗口上限时模型理解质量反而下降。解法是把记忆分层。短期记忆只保留最近两三轮对话直接拼进prompt保证连贯性。中期记忆最近二十轮以内的对话做摘要用压缩后的摘要替代冗长原文。长期记忆用户画像、关键偏好、重要历史事实写进向量库按需检索。架构把什么都记得改成用的时候才想起来成本和效果都更优。画这部分架构图我会把记忆模块画在编排层内部分别对接短期缓存、摘要存储和向量库三条连线。很多Agent跑着跑着变蠢不是模型变笨了是上下文被无关历史对话灌满了。记忆分层几乎是必做的一步。4.3 工具调用的不可控性超时、熔断与降级回退Agent调用外部API时第三方服务的延迟和稳定性完全不可控。我见过不少事故Agent调用一个外部接口卡死整个操作转圈到超时用户以为系统挂了。工具调用的架构设计有三个关键词超时、熔断、回退。超时设置要分级别连接超时、响应超时、整体调用超时每个级别都有对应处理动作。熔断是连续失败到阈值后暂时停止调用该工具避免故障放大。回退是工具不可用时编排层快速换路天气查询失败引导用户看静态页股票数据失败退化成纯文本回答。工具调度器旁边至少要有两条虚线分支每条都指向一个没有这个工具也能继续的出口。4.4 三个阻塞点对照表阻塞点核心表现根因架构解法推理时延P99飙升、大量超时模型推理耗时高、并发有限、请求排队异步化、流式输出、语义缓存、批处理上下文膨胀成本线性上涨、回答变差历史对话无限拼接、token超限短期/中期/长期记忆分层工具不可控第三方接口卡死、整个链路失败外部API无SLA保障、无保护策略分级超时、熔断、多路径回退这张表可以直接贴在架构图旁边当作评审时的检查单。每次新服务上线前对着表问一遍能省掉不少线上事故。5. 从单模型到多Agent协作架构的Agent化改造5.1 编排方式的变化从单轮Prompt到计划-执行循环最初级的AI应用就是一个Prompt请求过去、一个响应回来架构上完全没有计划概念。到了Agent阶段系统自己拆任务、自己排计划、自己决定调哪些工具本质上是把原来写死在代码里的业务流程交给编排层动态决策。架构上的变化在于模型从被调用方变成了参与决策方。原来用代码写死的if/else分支变成模型动态生成的步骤序列。这意味着架构需要一个Plan状态存储。我画Agent架构时会把编排层内部拆成三个组件Planner负责生成计划Executor负责按计划执行工具调用或子任务Memory负责每轮执行后更新状态。这套拆法对应了Agent工程实践里最常讨论的计划、执行、记忆三角色。5.2 主从式、流水线、群聊式多Agent协作的三种常见拓扑多AI协作在架构上大致有三种拓扑。主从式最简单一个主Agent负责意图解析和任务分解把子任务派发给若干子Agent子Agent完成后结果收拢回来。适合角色分工明确的场景比如一个写代码、一个审查代码、一个做测试。流水线式任务按固定顺序在多个Agent间传递每个Agent只处理自己负责的阶段适合内容生产流程比如资料收集、提纲生成、初稿、校对。群聊式多个Agent通过共享消息总线互相对话各自基于收到的消息做下一步动作灵活但控制难度大。三种拓扑在架构图上都是消息总线多个Agent节点的变体。我的经验是团队尽量从主从式起步不要一上来就群聊式否则Bug排查会让你崩溃。5.3 多Agent通信的协议选择与工程底线Agent之间通信用什么我见过直接用自然语言来回传的简单但脆弱解析不可控。更稳的方式是给每个Agent定义结构化输入输出协议比如JSON Schema把意图、参数、环境状态格式化传递只有真正需要生成内容时才放开自然语言。工程底线还有几条必须有父任务ID做链路追踪否则多Agent间的问题根本没法定位必须有步骤上限和超时总控防止Agent陷入自我循环每次Agent决策都要落日志让它的意识流可回放。这些底线不加多Agent架构就是一场技术事故预备役。好消息是基础设施可以直接复用消息队列和任务调度系统不必重造轮子。6. 演进路线先能跑再能扛最后能进化6.1 阶段一单体Prompt应用带病快速启动不要一开始就追求完美架构。先用单体Prompt做的页面和接口把业务跑起来验证需求成不成立。这个阶段架构图很简单接入层、调用一个模型、返回结果。它的问题很多但它能让你快速获得真实用户反馈。即使这个阶段也应该保留基础的评测样本记录把用户疑似badcase单独存下来。这些数据就是后续架构演进的种子没有它们后面的优化都靠拍脑袋。6.2 阶段二数据层独立RAG与检索进场当知识问答、客服类场景出现模型不知道领域知识的问题时RAG就要上场。这个阶段架构图上出现向量库和检索链路编排层开始承担组织检索结果的职责。最容易犯的错误是把所有知识都塞进向量库而不做切片和精排优化。我的建议是先人工挑200个典型问题和回答做评测集每改一次配置就回放一次看真实效果是否有提升而不是凭感觉调参。这一步很笨但长远看最省时间。6.3 阶段三编排层浮出水面Agent化落地当业务要求AI完成多步操作——订个会议、查个天气、写个周报——单体Prompt撑不住了。编排层独立出来引入Planner、Executor、Memory和工具调度器架构图上多出虚线降级分支和工具节点。这个阶段的核心是控制给Agent上缰绳限步、限时、限预算确保它不脱缰。我见过不少团队在这个阶段才回头补接口超时、补失败重试、补日志埋点导致重构阵痛。如果前两个阶段把数据层和评测集基础打好Agent化的过程会平滑很多。6.4 阶段四多模型路由与反馈闭环架构真正长出手脚最后模型不再只有一个路由、灰度、成本矩阵上线。同时把线上反馈通过评测回流到数据层形成上线、收集badcase、评测、调优、再上线的闭环。架构图在这一步达到完整接入层、编排层、模型层、数据层齐备实线虚线交织链路埋点贯穿每一层。这一阶段的价值在于业务的每一次抱怨都能变成评测集里的一个样本转化为下一次迭代的燃料。我用一个表格总结四阶段阶段核心架构特征主要目标最容易踩的坑单体Prompt接入层模型验证需求上线后没有数据沉淀RAG引入向量库检索链路补领域知识不做切片精排全塞向量库Agent化编排层工具调度多步任务没有限时和链路追踪多模型闭环路由评测闭环成本控制与持续优化反馈数据不回流演进过程中我特别想提醒一句架构是长出来的不是设计出来的。越复杂的AI应用越需要靠真实流量和真实badcase倒逼重构。没有反馈闭环的架构图再漂亮也只是静态装饰。根据我个人的实操体会最后再分享一个心得AI架构图里最难画的永远是那几条虚线。实线代表我打算这么走虚线代表这条路断了怎么办。从单体Prompt演进到多Agent协作真正让系统变可靠的不是模型换了多强的参数而是虚线的密度和长度。每画一条新的实线就多问自己一句它的虚线备好了吗这个习惯比任何架构方法论都值钱。