写AI应用架构最怕的就是上来就贴一张五颜六色的架构图然后指着每个方块说“这是接入层、这是模型层”听众点头如捣蒜回去自己动手时照样一脸迷茫。我这两年带过不少从零搭建AI产品的团队也复盘过好几个从PoC走向生产的项目一个很深的感触是AI应用的架构设计难点不在于“画出那张图”而在于想清楚这张图里每条连线的含义——什么数据在流动、谁在决策、模型在什么情况下会被调用、调用失败了对业务意味着什么。这篇文章不打算再复述那些“ChatGPT套壳”或“LangChain Demo”级别的架构而是想把我在实际项目中反复迭代过的一套AI应用架构设计思路用“看图说话”的方式拆开讲一遍。适合正在从“调API做原型”往“做可上线、可维护、可靠AI系统”方向迁移的工程师、技术负责人也适合需要和研发对齐认知的产品经理。先给个结论AI应用的架构图本质上是画一张“人机协作的决策链路图”LLM大语言模型只是这条链路上的一个组件而不是整个系统的灵魂。1. 从一张总览图开始AI应用架构的底座其实一直是“老一套三角色”我先说一个可能让不少人意外的判断AI应用架构最底层的东西和十年前做互联网应用没什么两样——你仍然需要用户端、服务端、数据端这三块。模型API、Agent框架、向量数据库这些新鲜名词的加入并没有推翻这个底座它们只是在服务端和用户端之间、在服务端和数据端之间插入了更多的“智能中间层”而已。画图的时候我会习惯性地先画三块大区域再往里面填充AI特有的模块。1.1 用户接入层的变与不变这一层本质上负责解决“用户怎么触达系统”的问题。传统Web应用可能是浏览器页面、小程序、移动AppAI应用则多出了对话式界面、语音入口以及最容易被忽略的“Agent调用入口”——也就是你的AI服务被另一个程序通过API调用的场景。我在实际设计时强烈建议大家把“对话界面”和“程序化调用入口”分开考虑。原因有二第一它们的并发模型、限流策略、超时要求完全不同人聊天可以等5秒程序调用等待超过2秒就可能导致上游超时第二它们对无状态性的要求不同对话界面通常需要保存会话上下文而程序化调用最好做到每次请求都自包含方便水平扩展。画图的时候这两条路最好从第一层就分叉后面接的网关、鉴权、流量治理策略也完全不同。1.2 中间智能层的模块划分这一层是AI应用架构图的“主战场”通常包括路由编排、模型网关、Agent执行器、记忆与上下文管理、工具调用协议等模块。很多初学者喜欢把所有逻辑塞进一个巨大的“AI服务”方块里这是架构图最容易翻车的地方。我一般会把中间层拆成至少四个独立的方块编排层Orchestrator负责理解用户请求、拆解任务、选择执行策略相当于“大脑的决策中枢”。模型接入层Model Gateway统一封装对各类LLM的调用负责密钥管理、模型路由、重试、降级、计费统计。它是架构图里最不该被省略的方块因为它决定了你后续换模型、灰度新模型时是否需要推倒重来。工具与插件层Tool/Plugin Layer封装API调用、数据库查询、搜索、代码执行等能力把外部系统“翻译”成LLM可以理解的工具函数。记忆与状态层Memory/State Layer管理对话历史、短期工作记忆、长期向量记忆、用户画像与偏好。这层在架构图上往往只画一个“向量数据库”就算完但真实落地时短期状态的管理比向量检索更麻烦。1.3 模型与数据支撑层底座是各类模型服务闭源API、开源部署、微调模型和企业内部数据源业务数据库、文档库、知识库、搜索索引。很多人把这一层当作“外部依赖”随手一画但实际上这一层的就绪程度往往决定了整个AI应用的天花板——模型能力的上限、知识数据的质量、更新频率都会直接传导到用户感知到的“智能程度”。所以我的建议是第一版架构图必须把这五层——接入层、编排层、模型网关层、工具层、数据层——画全哪怕有些方块先不实现也要在图上占一个位置。因为架构图本质上是一张“产品能力地图”它不只要描述现状还要标出未来半年的扩展方向。2. 模型服务编排所有画图的人最容易在这里绕晕问题的根源是没分清“直连”和“编排链”模型服务是整个AI应用架构图里的主角但主角不等于“所有问题都在模型层解决”。我在评审过很多份架构图之后发现翻车几乎都源于一个共同的错误把LLM当成一台可以直接访问的“业务核心数据库”所有链路都直连模型中间没有任何路由、重试和上下文管理。这就像早年间的单体应用把所有代码塞进一个文件里一样前期很爽后期很疼。2.1 模型层直接对接的三大隐患第一厂商锁定。今天你接的模型服务可能是一个对话API明天你发现业务需要更强的函数调用能力或者某个开源模型在隐私方面更有优势你要换供应商。如果每个业务模块都直接调用了模型SDK替换成本几乎是重写核心代码。第二无法灰度。新版本模型可能有推理能力提升也有概率引入回退。你希望在5%的流量上验证新模型再慢慢放大比例没有中间层很难干净利落地做这种动态切流。第三成本失控。不同模型的价格差异可以到几十倍同一个请求用GPT级别的模型回答和用轻量模型回答成本天差地别。没有统一的计费与配额控制复盘账单时很容易“爆表”。所以我在架构图里永远放一个“模型网关”方块。它的职责很简单但价值巨大统一鉴权一次配置处处调用密钥永不进入业务代码。统一协议把OpenAI、Anthropic、开源模型的自建服务等各种协议转换成内部统一的一个调用接口业务侧甚至不需要知道今天用得是哪家模型。统一重试与降级上游模型超时了网关按策略切换到备用模型业务请求不会直接报错。统一观测每次调用都留下日志记录模型、token消耗、延迟、结果质量这是后面做评估和成本优化的数据底座。2.2 三种主流编排模式的取舍直连、路由、Agent式架构图上最常见的编排模式有三种很多新入行的朋友分不清区别这里用大白话拆一下单模型直连用户请求进来直接发送给一个大模型拿结果返回。适合简单问答、文案生成、翻译等单轮、确定性高的场景。优点是链路极短延迟低、调试容易缺点是完全不涉及“多步处理”一旦任务里包含“先查点什么、再思考、再回答”单模型直连就力不从心了。路由分发Categorized Routing先用一个轻量模型或规则对用户请求做分类再根据分类把请求分发给不同专用模型或不同提示词模板。比如“闲聊”走轻量模型“专业法律问题”走更强的模型并搭配特定知识库“要读网页”则加上搜索工具。这种模式在架构图上会呈现为“一个分流器加多条处理链”比较适合客服、助理类产品既兼顾体验又控制成本。Agent式编排把任务拆解成多步每一步都由LLM决定调用什么工具、如何继续。这是架构图最复杂的形态也是当前各类“AI Agent应用”的热点。呈现在图上就是一个“规划-执行-观察-再规划”的循环中间挂着工具集和记忆模块。适合复杂任务执行、多步骤信息检索、自主决策类场景代价是链路长、状态复杂、token消耗高、可观测性要求高。我的个人经验是架构图不要一开始就往Agent式去画。先尝试“路由分发单模型”把系统跑通上线再看哪些用户请求真的需要多步推理把它们单独拆出来走Agent链路。很多失败的AI项目都是因为首版就上了全自由度的Agent循环结果连“用户到底要什么”都没搞清楚就陷在无穷的自动纠错里。2.3 路由分发怎么画才不容易歪这里实际操作的经验是不要试图让路由模型“一次判断全部事情”。画路由的时候给它拆成“需要”和“不需要”两个问题第一这个请求需不需要工具/知识增强第二如果需要应该用哪个工具集或知识库然后画一个决策表请求意图为“闲聊”走轻量模型不挂工具。请求意图为“问答但知识库可能有关键答案”走检索增强链路先查向量库再送模型。请求意图为“完成多步任务”走Agent链路。这种拆分比让路由模型输出“我该走哪一个分支”要稳定得多因为它把不确定的“分类问题”变成了更窄的“是否问题”模型出错率低很多。3. 数据与记忆架构图里画得最少实际坑最多我看过太多AI应用架构图数据层就画一个云厂商的数据库图标旁边写个“向量库”然后就没了。结果到了线上问题全从这里冒出来召回的内容驴唇不对马嘴、知识更新了一版用户问的还是旧内容、多轮会话中模型忘掉了前面的关键约束。老实讲数据与记忆这一层在AI应用架构里决定了“体验下限”——模型能力决定上限数据和记忆决定下限这句话值得写在架构图旁边。3.1 向量检索的架构定位它是记忆的索引不是全部的数据库很多人对向量数据库寄予厚望觉得把文档切碎丢进去一个AI知识库就搞定了。实际上向量检索只是“记忆的粗筛层”。正确的链路通常是这样用户问题进来先做意图理解和关键词抽取。用这些信息对向量库做召回拿到一批候选片段。再用重排序Rerank模型或规则在这些候选中挑出真正相关的内容。最后把精选内容和用户问题一起拼装成提示词送进LLM。架构图上一定要把“召回”“重排”“拼装”这三步分开画。因为在实际调优时你会发现返回质量差的问题八成不是模型不行而是召回条件太宽或重排策略太弱。分开画你才能知道该调哪一个方块。3.2 会话记忆的短期与长期分层对话类AI应用必须处理记忆而记忆至少分两层短期会话记忆当前对话轮次的上下文通常放在Redis或内存态里设置合理的过期时间。短路了模型会丢上下文太长token成本爆炸。长期用户记忆用户偏好、历史事实、之前对话中主动提供的个人信息存放在独立的数据库按用户ID组织。需要的时候以摘要的形式注入短期上下文。画图时常见错误是把所有记忆都塞进一个“向量数据库”。短期记忆讲究的是快速读写和准确覆盖长期记忆讲究的是持久化和跨会话检索二者对存储引擎的要求不一样拆开画才能避免后续为性能头疼。3.3 知识更新的链条入库、索引、生效企业级AI应用一定会涉及“知识库更新”的事情。这块有一个大家容易忽视的细节从文档上传到向量库里的内容真正能被检索到中间通常需要经过解析、清洗、切分、向量化、写入、索引刷新等多个环节。任何一环出了问题用户都会觉得“系统没更新”。架构图上我建议专门画一条“数据接入与更新链路”而不是只画一个静态的知识库方块。因为这里的延迟和失败率直接决定了你对用户说“文档已上传成功”这句话是否真的属实。实际做过的朋友应该有体会上传后立刻检索却什么都搜不到十有八九就是切分和向量化任务在后台还没跑完这是排队、异步处理要考虑清楚的事情。4. Agent与工具调用架构图上最花哨的部分也是我踩坑最多的地方聊到AI应用架构Agent是绕不开的。很多架构图画到Agent就开始放飞自我一个循环左边挂个“代码解释器”右边挂个“浏览器”中间拿个数据库看起来非常智能。但真上线后Agent经常会陷入一种“看起来在努力实际在空转”的状态不断调用工具、不断报错、不断重试最后给用户一个不知所云的答案。4.1 工具调用的本质是“协议”不是“魔法”在架构设计层面我们需要想清楚LLM本身并不会“调用”工具它只会输出一段结构化的文本——比如“我要调用查机票API参数是上海到北京、明天”。真正去执行这个调用的是你的代码。所以Agent架构的核心是一套“让LLM的意图输出与你的代码动作对齐”的协议。我在图里会专门画一个“工具注册中心”方块。每个工具都有一份JSON Schema描述包括工具能做什么、参数格式是什么、什么时候适合用、什么时候千万别用。Agent循环从注册中心取到这批描述拼进系统提示词。LLM在决策时就是从这个“工具的菜单”里挑菜。与其说是智能模型在驾驭工具不如说是一套精心设计的菜单在引导模型做出可用决策。画这个图的时候切记不要画成“Agent直接连接所有系统”。中间必须有“工具注册中心”这一层否则每新增一个API你都要修改Agent循环的核心代码维护成本会直线上升。4.2 规划-执行-反思循环的工程实现Agent执行链路的架构图最经典的画法是一个循环三个环节规划Plan、执行Act、观察Observe。但在工程落地上需要给每个环节加上限流和护栏规划环节模型基于当前任务和工具列表输出一个行动计划。这里要控制的是“规划的粒度”太粗会跳过必要步骤太细则token消耗爆炸。我的经验是把规划限制在两到五步内不要一开始就让模型输出二十步的超长计划后续执行中根据观察再动态调整。执行环节代码真正调用工具等待结果。这里要格外关注“超时机制”。工具调用可能挂住模型可能返回无效参数这些都必须有兜底。我见过很多Agent项目挂在“某次工具调用永远没有返回”上。观察环节把工具返回的结果重新整理成文本送回模型。这一环容易被忽视但往往决定成败工具返回的可能是一个巨大的JSON直接塞给模型既不经济又容易“迷失重点”。正确做法是在观察环节做摘要或筛选只把关键信息放进上下文。4.3 多Agent协作的构图陷阱顺着热搜词里“多AI协作”的趋势现在很多架构图开始画“多个Agent互相聊天”的场景。我对此的态度是可以画但要想清楚它们之间靠什么协作。是靠共享同一份任务清单还是靠消息队列传递事件还是靠一个主Agent统一调度我的建议是多Agent协作的架构图至少有两种画法可以在视觉上更清楚——第一种是“主从模式”一个主Agent负责任务拆解和结果汇总多个子Agent各自负责一个子任务彼此不直接通信。第二种是“流水线模式”任务按阶段传递上一个Agent的输出是下一个Agent的输入适合文档处理、内容生产这类有明确先后顺序的流程。最不建议的构图是把所有Agent画成一团互相连接的网状结构。协作链路一旦是网状状态复现和问题排查就会变得极其困难而且任何一个Agent的行为偏差都会像多米诺骨牌一样传导到整个系统。5. 工程化落地架构图从纸面到生产的断点清单架构图画得再漂亮最终还是要接受生产环境的拷问。我把它称为“断点清单”——每一条都是真实项目里踩过的坑写出来给大家参考。5.1 可观测性你要监视的指标远不止延迟和错误率传统应用看QPS、P99延迟、错误率AI应用除此之外还要看这些Token消耗分布同一类请求是哪个链路环节吃掉了最多token往往是上下文管理出错历史消息无限堆积。工具调用成功率Agent每调用一次工具成功还是失败失败原因是工具本身不可用还是模型产生了无效参数内容质量抽检答案是否准确、是否有幻觉、是否遵循了系统约束。质量无法完全自动化衡量但至少要保留对话样本供人工抽检。架构图上最好给每个核心链路都画上一个“观测点”小标记。不要等到上线后再补上线后再补意味着你失去了最早期的调优数据。5.2 优雅降级模型不可用的时候你的系统怎么办很多AI应用架构图里LLM是唯一的“大脑”。一旦模型服务商抖动或超时整个应用就瘫痪了。生产级架构必须考虑降级路径。我在架构图里会额外画一条“降级支线”当主模型不可用时先把服务切换到备用模型备用模型也不可用时返回已缓存的历史答案连缓存也没有就向用户展示“当前服务繁忙请稍后再试”而不是让请求在后台无限重试拖垮整个应用。画这条支线只花一分钟但能在真实的故障演练中救你一次。5.3 评估与回归体系没有评估集的AI架构是空中楼阁最后这块特别想多说一句。普通代码有单元测试和集成测试AI应用也要有“评估集”Eval Set。它就是一组精心标注过的“用户问题-预期表现”样本每次改模型、改提示词、改检索逻辑都要拿这批样本跑一遍对比回答质量的变化。架构图上我会把评估体系画在最外层像一个“质量护栏”包围整个系统。它不是一个功能模块但它是整个架构能够持续迭代的前提。没有评估集你会陷入“今天优化了一个case明天弄坏三个case”的窘境而且毫无察觉。6. 一张完整的小型产品架构图示例讲了这么多最后给一个可以直接拿去改的架构示例。假设我们要做一个“企业内部文档问答与自动化助手”它的架构图从上到下是这样的接入层企业微信/钉钉机器人入口还有一个用于其他系统集成的OpenAPI入口。网关层鉴权、限流、请求上下文解析。编排层路由判断。简单闲聊走轻量模型知识类问题走RAG链路涉及跨系统操作的任务走Agent链路。RAG链路召回向量检索关键词检索、重排、上下文拼装。Agent链路工具注册中心连接企业Wiki系统CRM系统工单系统、规划-执行-观察循环、任务状态存储。模型网关统一封装主模型、备用模型、速答模型的路由记录token用量。数据层向量库、业务数据库、会话存储、用户长期记忆库。质量护栏评估集、日志平台、人工抽检工具。这个架构的好处是每一层都能独立扩缩容每一层的失败都有相对明确的兜底策略。如果未来要接入语音助手只需要在接入层加一个语音转写模块如果要支持更复杂的业务自动化也只需要在工具注册中心注册新工具。画图的顺序建议是先用一个晚上在白板上把“用户请求从哪里进来到哪里结束”这条主线画出来再填充支线和降级路径。别一上来就画得很满留白是给未来的故障准备的。最后分享一个我自己的体会好的AI应用架构图不是说上面用了多新的模型、多智能的Agent编排而是“当你半夜被电话叫醒处理故障时能凭这张图在五分钟内定位到是哪个环节出了问题”。画图不是写文档它是逼迫你把自己的系统想清楚的一种方式。每次画完一张架构图我都会发现至少两三个之前完全没有想清楚的细节这大概就是画图这项“老本事”在AI时代仍然有用的原因。