最近帮团队做企业内部知识助手的技术评审我发现一个很有意思的现象几乎所有候选人都能讲明白自己的技术选型但一到白板上画AI应用架构图就集体露怯。要么画成传统三层Web应用再加个“大模型”方块要么把所有东西堆在一个椭圆里写个“AI能力”谁也看不懂边界在哪儿。这种混乱的根源是很多人还拿老一套“请求-响应”的确定性思维去设计AI应用而AI应用架构设计本质上面对的是不确定计算模型的输出不能保证正确、不能保证格式、甚至不能保证不“胡说”。架构图如果画不出这种不确定性那这张图就是自欺欺人的。这篇内容我按自己的实战经验把AI应用架构设计拆开讲透重点说说怎么把一张复杂架构图画得既有层次、又能指导落地。适合正在做AI应用落地的工程师、技术负责人也适合刚入门想建立整体视图的开发者。1. 为什么AI应用架构图和传统架构图不一样1.1 从“请求-响应”到“不确定计算”传统应用架构核心是确定性处理。客户端发一个请求服务端查数据库、算一下、返回结果整个过程可预期、可追踪、可复现。所以在画图的时候你只需要把组件间的依赖关系和调用链标清楚箭头从A到BB再串到C基本就完事了。AI应用里中间的“计算”变成了模型推理。模型不是一个按固定逻辑执行的服务它是一个概率系统同样的输入温度参数调一下输出就变了同一个Prompt放在不同版本的模型上可能完全翻车。这意味着架构图里不能只画“服务A调用模型B”还要画出“如果模型B给出了不合格输出系统该怎么办”的兜底路径。我见过很多团队画的第一个版本AI架构图就是一个用户框、一个大模型框、一根箭头看着简洁实际毫无设计含量。真正的架构设计恰恰要从这根箭头两侧展开左边要解决怎么把用户的复杂诉求拆成模型能理解的任务右边要解决怎么让模型的输出可控、可用、可验证。这张图里的每个分支、每条失败返回路径才是设计功力所在。1.2 AI架构图必须画的“四层一闭环”我自己的习惯画AI应用架构图时不会只画系统边界内的组件而是固定按四层一闭环去检查和补全交互接入层App、Web、IM、API解决的是怎么把不同入口的请求统一收进来。编排协调层任务规划、上下文组装、工具调用、流程控制。这是AI应用区别于传统应用最核心的一层。模型与能力层大模型、小模型、多模态模型、外部API以及模型网关。数据知识层业务数据库、文档、向量库、缓存、外部知识源。一闭环从用户请求开始到模型输出、校验、反馈、再评估整个质量闭环。很多架构图缺的不是组件而是闭环。请求从左边流进、右边流出看起来通畅但输出质量没人管效果回归没人做这图就是画了个寂寞。画图的时候我建议在右下角单独圈出一块“评估与观测”画上离线评测、线上埋点、反馈回流再由这里拉一条虚线回到Prompt和数据层表示“根据结果持续调整”。有了这条虚线这张架构图才是一张活的AI应用架构图。1.3 画图的第一原则组件不是盒子是决策点有人在白板上画AI架构特别痴迷于把每个技术名词都画成一个框LangChain一个框、Chroma一个框、Dify一个框甚至某个插件也占一个框。满屏盒子最后没人说得清哪个框是必须的、哪个框可以去掉。这就是把组件当盒子画而不是当决策点画。我自己的原则是架构图上的每一个框都对应一个重要决策点。比如“路由/编排”这个框背后要回答的是“这条请求到底需不需要大模型还是直接走规则”“向量库”这个框背后要回答的是“我们到底靠什么找知识是向量相似度还是关键词命中”如果一个问题不值得单独决策那就不配单独占一个框。按照这个标准去画图很多花哨的组件会被砍掉留下来的每一层都经得起追问。2. 交互与接入层把模型藏在后面2.1 入口形态与多模态适配对架构的影响接入层是所有请求的第一站但它绝不只是一个“API网关”那么简单。AI应用的入口形态直接决定了后续编排层的复杂程度。文本聊天框是一种方式但更多业务场景里用户是通过按钮、表单、语音、图片来“提出需求”的。比如企业助手如果只做成了对话框用户什么都得打字体验就很差真正好用的方式是给用户场景化的操作入口比如“一键总结会议纪要”“上传合同后自动提取条款”。把这些入口收拢到统一接入层架构上要做两件事一是把不同入口的输入统一转换成内部标准消息格式二是识别输入类型判断是否需要调用多模态模型做预处理。比如用户传了一张截图接入层可能需要先调用OCR模型把文字抽出来再进入编排层。如果这张图里没有画“预处理/输入标准化”这个节点后面所有层都会为混乱的请求格式付出代价。画图时我建议在接入层画两条横线一条连接不同入口到统一网关一条从网关引出“输入转换”虚线框只保留必要的转换操作。这个框里能解决“图文混排怎么处理”“语音转写放哪里”避免后面业务逻辑里到处写入口判断。2.2 会话管理与上下文窗口的矛盾对话类AI应用一定会遇到会话管理。表面上看这跟传统Web应用的Session差不多但实际差很远。传统Session存的是用户登录态、购物车这种短结构数据AI应用得存对话历史、引用片段、临时状态、用户偏好而且这些数据还要不断被塞进Prompt里送给模型。这里的架构冲突在于历史越长模型理解越完整但上下文窗口和token成本也在涨。很多团队一开始贪方便把最近20轮对话全量拼接结果提示词越来越长响应越来越慢费用越来越高最后模型反而被无关信息干扰。解决这个矛盾的常见做法是加一层“上下文管理组件”它的职责不是存聊天记录而是决定“当前这轮该把哪些历史摘要、哪些检索片段、哪些工具结果放进Prompt”。所以我在架构图上习惯在编排层旁边画一个“上下文包管理器”它和会话存储、向量库都有虚线连接。画出来之后团队讨论就容易聚焦了上下文管理器是拼接字符串还是动态模板历史摘要需要单独摘要模型还是复用主模型这些落到图上就都是一目了然的决策。2.3 成本控制前置限流、配额与优先级AI应用的成本控制一定不能等到账单出来才处理要前置到接入层做。大模型调用和普通API不一样慢且贵一旦业务放量一个不受限的聊天入口很可能一天烧掉几万块。而且单用户狂刷、异常流量、恶意批量调用普通限流阈值很难识别。我通常会在接入层画两个组件配额网关和策略中心。配额网关按用户、部门、功能点分别设置token和QPS配额策略中心则维护优先级规则比如“内部知识问答优先于闲聊”“运营批量分析任务放到夜间低峰执行”。这样做的好处是成本预算可以在架构层被执行而不是靠运维事后封账号。画图的时候别只画“限流中间件”这么笼统。把限流维度细化出来按用户限、按模型限、按功能限、按并发限分别用什么算法。哪怕图上只写几个字落地时团队就有据可依。3. 编排层决定AI应用聪明程度的枢纽3.1 从规则路由到提示词路由编排层是我在评审时最先看的地方。很多团队所谓的编排就是在代码里写一堆if-else判断意图再调用一下大模型。这种模式说实话只能应付演示业务复杂度一上去就崩。更实用的做法是规则与模型混合路由。简单、高频、确定性强的请求比如“查快递单号”“查询余额”直接走规则或轻量模型不必要每次都调大型模型复杂、开放、语义模糊的请求比如帮用户梳理一份合同的风险条款才路由到强推理模型。路由本身既可以是传统的意图分类模型也可以让大模型来做“闸门判断”。我在画编排层时会先画一个“意图解析与路由”节点左侧接上下文管理器右侧接多个内部处理流程包括规则服务、Agent流程、直连模型。这个节点是整张图里最关键的决策汇聚点。判断它的设计好不好就一个问题新增一个业务场景需要改代码还是只需要调配置关联如果还要加if-else那这个节点迟早会变成维护噩梦。3.2 Agent化之后规划、工具调用与循环控制编排层的另一个重要演进是Agent化。传统的编排是一次请求一次模型调用Agent化之后变成“模型自己规划调用哪些工具、执行哪些步骤、根据结果决定下一步”。这对架构设计的影响非常大因为请求处理时间从秒级变成了分钟级调用链从一条直线变成了一棵可能分叉的树。画Agent架构时我要求团队必须额外画“循环边界”和“工具调用集合”。循环边界说的是Agent最多循环几轮、什么条件下强制终止。没有这条边界的Agent线上很容易出现死循环或失控开销。工具调用集合要列出Agent能访问哪些外部能力比如检索工具、计算器、数据库查询、第三方API每个工具的入参、出参格式必须明确。这实际上是在给模型的自主性画笼子。我自己的经验是工具不要给多给精。给Agent十个工具它不一定会用但一定会出格式错误。初始版本给三到五个边界清晰的工具跑通了再加这个节奏在架构上更容易控制。3.3 异步编排与失败重试的设计AI应用如果只有一问一答编排层可以做成同步的。但现在很多真实场景是后台任务比如“批量盘点合同里的风险条款”“每周自动生成运营周报”这类任务必须走异步编排。同步调用模型动辄几十秒前端一直转圈体验和架构都撑不住。异步编排的核心是任务队列加状态机。请求进来先落库状态置为pending编排器消费队列后逐步推进规划 - 检索 - 模型调用 - 输出校验。每个步骤的中间状态都要能查询、能断点续跑。我见过踩得最多的坑是任务执行到一半模型超时整套流程直接失败数据不落库、状态不更新用户第二天一问系统一脸懵。画架构图的时候要给编排层补一个“任务状态存储”的框并且把所有箭头都画成可以往回退的。不要画成一条从入队到完成的光滑横线一定要画出超时、重试、人工介入的分支。那张图才是真实的。4. 模型层接入别让应用绑死在某个大模型上4.1 模型网关的职责边界我觉得AI应用架构设计里最容易被低估的就是模型网关。很多小团队起步的时候直接写死调用某一家大模型API等到业务量上来、价格涨了、效果不稳定了想换模型才发现Prompt模板、解析逻辑、降级策略全都跟这家模型绑死了替换成本高到离谱。模型网关的职责是给上层提供一个统一的大模型接口屏蔽不同模型在协议、参数、返回格式上的差异。它不只是一个转发代理还应该有模型路由、限流熔断、超时重试、结果缓存、成本统计。上层业务只认识“模型名”和“消息结构”具体背后是哪个厂商的哪个版本由网关决定。我建议网关上的模型名做成逻辑名而不是物理名。比如业务侧只写primary-llm、fast-llm、embedding-model网关再映射到真实模型。这样哪天某家模型升级或下线你只需要改网关配置不需要动业务代码。画架构图的时候务必把网关放在模型层的最前面业务组件不要直接连模型API。4.2 Prompt与模型的版本管理模型层的第二个重点是Prompt模板的管理。很多人把Prompt写在业务代码里或者散落在各个配置项里版本全靠脑子记。等到模型一更新同样的Prompt效果可能就变了你想回滚都不知道上一个Prompt长什么样。我自己习惯把Prompt当作一等代码资产来管理。一个完整的Prompt版本应该包含模板内容、配套模型版本、温度采样参数、输入变量说明、示例few-shot。Prompt和模型版本要绑定记录因为同一个Prompt在GPT-4和开源模型上的表现完全不同回滚的时候必须一起回滚。架构图上这里要画一个“Prompt仓库/版本中心”的小节点所有调用模型的路径都从这里取模板禁止在代码里硬编码。虽然这是小事但实际维护时能省掉大量调试时间。配合模型网关即使上线后Prompt出了问题也可以在几分钟内切回旧版本。4.3 多模型切换、降级与灰度依赖单一模型是另一种绑定风险。大型模型偶尔也会有服务波动、限流、或者效果回退。把可用性完全押在一家上架构就太脆了。模型层设计时要有降级链。比如主模型是商用大模型降级链可以是“同级别备用模型 - 更小更快模型 - 规则兜底”。判断降级的触发条件不是只等报错还要关注响应超时、连续返回不符合格式、成本超预算。画图的时候模型网关旁边要画一条降级链线上运行时就按这条链自动走。灰度切换同样重要。新模型版本上线前不要全量切先放5%的流量做对比。对比指标不能只盯着回答满意度要看任务完成率、Prompt解析成功率、工具调用正确率。所以模型网关需要支持按比例分流并且把流量标识串到后面的评估系统。没有这条灰度路径的架构图等于没有安全网。5. 知识与数据层RAG不是简单塞进向量库就行5.1 数据接入、清洗与切分RAG检索增强生成是现在AI应用架构里的标配但很多人对RAG的理解就是“把文档存进向量库问答时检索一下”。真做起来就会发现检索质量七分靠前处理三分靠模型。数据接入层要做的事比想象中多得多各种格式的文档解析PDF、Word、HTML、扫描件表格结构还原敏感信息脱敏重复文档去重旧版本失效标记。这些不做干净后面的向量检索就是垃圾进垃圾出。切分这一步最考验经验切得太碎语义被切断检索不到完整上下文切得太大噪音太多还浪费token。比较稳妥的起点是每块256到512个token设置少量重叠再根据实际检索效果微调。架构图上数据层前面要画出“解析-清洗-切分”链路后面再连向量库和索引库。很多团队跳过了前面这段直接画文档进向量库这图等于省略了最容易出问题的部分。5.2 混合检索向量、关键词与重排纯向量检索不是万能的。它在处理同义改写、语义理解上很强但在处理精确匹配、编号、产品型号、代码片段时经常失灵。你问“CL-2024-03这个合同编号在哪个文档里”向量搜索的结果可能不如一个普通关键词搜索准确。所以我现在做知识检索默认就设计成混合检索向量检索召回语义相似的片段BM25/关键词检索召回精确命中的片段两边结果合并后再过一次重排模型把最相关的几条排到前面。重排这一步看着又多一次模型调用但它对回答质量的提升非常明显这个成本值得花。画数据层时不要把“向量库”画成唯一知识来源。要画一个“检索服务”节点它同时连接向量库、倒排索引和重排模块。业务编排层只认检索服务这个接口不关心底层到底存了几种库。这样做也方便以后替换底层存储。5.3 更新链路与时效性保障知识库最怕的是“新知识进不来、旧知识删不掉”。很多RAG系统上线时效果好运行一个月后效果明显下降就是因为知识更新链路没设计好。文档更新了向量库里旧片段还留着模型检索时新旧信息混在一起回答自然错乱。架构上要把知识更新画成一条独立的链路变更感知 - 解析新文档 - 生成新的向量与索引 - 标记旧版本失效 - 清理或降权旧数据。另外要处理更新的优先级比如高频更新的业务规则文档要能单独触发增量索引而不是所有知识一个月重建一次。我在数据层画图时一定会留一个“更新队列”并注明更新频率和延迟要求。这个细节看起来不起眼但它决定了你的AI应用回答的是上个月的问题还是昨天的问题。时效性就是系统可信度的一部分。6. 可观测性与安全护栏上线后真正花时间的部分6.1 三点观测延迟、成本与回答质量传统应用看监控主要看QPS、错误率、P99延迟但这些对AI应用远远不够。AI应用有三个指标必须单独观测端到端延迟、单次调用成本、回答质量。延迟还好理解模型推理慢用户等不起成本前面已经强调过不观测就会被账单教育回答质量最麻烦因为它是非确定性的不能只看一个状态码。我给团队的默认要求是每一步模型调用都要有独立的埋点数据模型名、输入token数、输出token数、耗时、重试次数、是否触发降级。这既是为了算成本也是为了出问题时能回放。回答质量则通过用户反馈按钮、人工抽检、离线评测三路采集。架构图上这些埋点统一汇入一个“AI观测平台”而不是散落在各种日志系统里。画图时观测平台的框一定要从接入层拉到模型层和数据层覆盖全链路。这里最忌讳只画一个“日志”方块因为日志不等于是可观测性。你需要能随时回答上周Prompt模板V2上线后回答好评率到底升了还是降了。6.2 输出校验与内容护栏大模型的输出不能直接透传给用户这是AI应用架构的铁律。输出校验层要做的事包括格式校验JSON、Markdown、表格、敏感信息过滤、事实一致性粗校验、内容安全过滤。一个很常见的需求是模型明明只被要求输出三条合同风险结果多编了一条不存在的条款。这是大模型的“幻觉”问题光靠调试Prompt无法根除必须靠系统和知识约束。我会在编排层和接入层之间画一个“输出防火墙”节点。所有模型返回的内容都必须先过这一层校验不通过就触发重试或修正。重试不是简单地让模型再来一次而是把校验失败原因返回给模型让它知道哪里错了、怎么改比如“你输出的第四条不在检索到的原文中请只基于原文重写”。这样护栏就成了模型改进的反馈而不是一根只会喊停的棍子。6.3 离线评测与灰度回归线上效果稳定之后离线评测就是AI应用持续迭代的压舱石。没有评测集的AI项目后期改Prompt、换模型、调检索参数全凭感觉上线靠赌。我建议从项目一开始就维护一个评测集哪怕只有一两百条真实问题每条标注好正确答案或验收标准。评测集的使用要固化到发布流程里。每次改动Prompt、调整检索策略、切换模型版本先在离线评测集上跑一遍对比通过率、未答率、格式错误率再决定要不要上灰度。我在架构图上会把离线评测和线上灰度并排放二者构成一条完整的迭代闭环改配置 - 离线评测 - 小流量灰度 - 线上观测 - 反馈回数据集。这个部分最容易被年轻团队忽略但恰恰是AI应用架构和Demo的分水岭。Demo只需要能亮眼上线的系统需要能证明自己没变差。架构图里没有评测闭环那这份设计其实还停留在演示阶段。7. 一张图看懂完整案例企业知识助手架构拆解7.1 架构节点图文字版为了把前面几层串起来我以一个典型的企业知识助手为例把整体架构的关键节点用文字图方式列出来。你画图的时候照这个结构扩展就行用户入口企业微信 / Web / 内部App / API v 接入网关鉴权、配额、限流、输入标准化 v 编排层意图路由 - 上下文管理 - 任务规划 |--- 规则服务高频固定问题 |--- Agent流程多步复杂任务 |--- 直连模型开放问答 v 检索服务混合检索向量 关键词- 重排 - 组装上下文 v 模型网关逻辑模型映射 - 主模型 / 备用模型 / 降级链 v 输出防火墙格式校验、敏感过滤、事实核对、安全护栏 v 返回用户 全链路埋点 - AI观测平台 - 离线评测 - 反馈回流这张图的右侧还要挂一个“知识更新链路”新文档上传 - 解析清洗 - 切分 - 向量化 - 更新索引底部挂一条“评估闭环”线上反馈和离线评测结果反向影响Prompt模板、检索参数和知识库整理策略。7.2 关键配置与参数选型同样的架构图不同团队落地的差距就在细节参数上。以这个知识助手为例我给出几组实测过的配置参考真实项目中可以按自己的场景调整文本切分按语义段落优先每块约384 token重叠64 token。向量模型初期直接选商用的文本向量模型维度在768到1536之间足够不要一上来就自己训练向量模型性价比很低。混合检索召回Top 20候选向量和关键词各10重排后保留Top 5再组装Prompt。上下文窗口预算给单次生成预留最多4000 token输入其中检索片段不超过2000 token历史对话摘要不超过1500 token剩余留给指令和示例。降级链主模型超时3秒或连续失败2次自动切备用模型检索不可用时直接拒绝回答“知识库暂不可用”不要让模型硬编。这些参数不是拍脑袋都是从成本和效果之间试出来的。画图的时候把参数标在对应节点的旁边这张图才真正可执行不然别人看了图也不知道该怎么配。7.3 画这张图时我踩过的三个坑第一个坑一开始把Agent画得特别理想化工具调用、多步规划、自动反思全画上了实际开发时发现工具调用格式一直不稳定光调试工具解析就浪费了两周。后来我砍掉了两个不常用的工具把工具数量收敛到四个并且严格要求每个工具的出参必须是结构化JSON问题立刻少了一大半。现在我在架构图上都会特意标注工具调用边界一定要明确宁可少不可滥。第二个坑没有把“上下文管理”单独画成一个组件。前两版架构图我直接把历史记录和检索片段都塞在“编排层”里结果做开发时每个人对“该把哪些内容给模型”的理解都不同有人拼全部历史有人只拼最后一轮。后面把上下文管理器独立成一个框明确它的输入、输出、大小限制整个团队的沟通成本瞬间降下来了。这让我更确信架构图上每一个框都必须代表一个清晰职责边界。第三个坑低估了输出校验的重要性。第一个版本上线模型经常在回答末尾自己补一段“以上内容仅供参考不构成任何建议”虽然无害但很影响企业场景的专业感。更严重的是它会自己编造不存在的文档编号。后来加了输出防火墙强制校验引用的编号必须在检索原文中存在否则重写这个问题基本绝迹。这个校验逻辑现在已经是所有AI应用的标准组件了。如果现在让我只留一张AI应用架构图我会留那张带完整失败分支、降级路径和评估闭环的图。因为流顺畅的图谁都会画能在每个不确定节点上给出兜底方案的架构才是真正能上线运营的架构。AI应用架构设计本来就不是一次画完的静态蓝图它更像是跟着模型能力、业务场景和线上反馈一块儿生长的过程把每一个决策点画清楚团队才不至于在快速迭代里走散。