1. 先把架构图想明白AI应用的分层模型与演进路径这两年做AI应用身边问得最多的问题已经不再是“哪个模型效果更好”而是“我的AI应用到底该怎么搭架构”。很多人用大模型API写完demo只花了一个下午但一旦要考虑多用户、多场景、多模型、可观测、可回滚项目就瞬间卡壳。我见过不少团队连一个完整的AI应用架构图都画不出来更没有想清楚每一层到底该放什么、不该放什么。AI应用架构设计这件事听起来像架构师专属话题实际上任何一个AI应用开发、运维或技术负责人都应该至少建立一套自己的分层认知。这套认知的核心说起来并不玄乎AI应用本质上还是一个软件系统只不过多了一个“会生成内容的模型逻辑”和一套围绕模型展开的配套链路。架构设计要解决的不是把模型接进来那么简单而是把会话、知识、工具、数据、评测、监控全部组织成可以稳定运转的系统。1.1 从“会跑”到“能扛”架构设计的三个转折点我习惯把AI应用的成熟度分成三个阶段。第一个阶段是“脚本阶段”代码写在一个Python文件里通过终端敲几行命令调一次模型接口拿到结果后打印出来。这个阶段没有会话管理没有用户概念更没有延迟和成本意识。第二个阶段是“服务阶段”AI应用被包装成Web API或后端服务开始有独立的模型调用模块、会话存储、密钥管理这个时候架构问题开始暴露。第三个阶段是“平台阶段”同一个系统要支撑多条业务线每个业务线又有自己的提示词、知识库和工具集还要求可观测、可灰度、能告警。大多数团队卡在第二到第三阶段之间。从“能跑”到“能扛”中间隔着的就是“架构设计”这四个字。具体说来要跨过三个转折点第一个转折点是“模型无关化”代码不能绑定某一个模型厂商今天用的模型和明天要换的模型之间要有一层隔离第二个转折点是“上下文可管理化”不能每次请求都把整个对话历史无脑拼接给模型而是要有明确的上下文窗口管理策略第三个转折点是“能力可编排化”大模型不再只做聊天而是能调用搜索、数据库、业务API这些外部工具整个流程变成可控的执行链。这三个转折点单靠某一个开发框架解决不了必须在架构层面提前设计。否则等业务量上来再回头改代价极高。1.2 一张架构图到底画什么请求链路与关键模块我每次讲AI应用架构都会先画一张分层图。这张图不复杂核心就六层但每一层都有明确职责。用文字把图描述出来大致长这样客户端Web / App / IM | v 接入层鉴权、限流、会话管理 | v 模型网关多模型路由、密钥管理、超时控制 | v 编排层Prompt模板 / 知识库检索 / Agent工具 | v 模型服务Chat模型 / Embedding模型 / 多模态模型这张图里的每一层都对应一组必须回答的问题。接入层要回答“这个请求是谁发来的有没有权限频率是否异常”模型网关要回答“这次请求该用哪个模型如果主模型超时或不可用该怎么办”编排层要回答“用户这句话是不是需要检索知识库需不需要调用某个工具历史对话哪些该保留”模型服务则负责真正生成结果。所有层叠在一起才是完整的AI应用架构。还有一个容易被忽略的部分是“支撑面”。架构不能只有一条请求链路还要有数据存储、可观测性、评测系统、版本管理。这些支撑组件挂在请求链路旁边平时不直接参与每一次调用但决定了系统能不能长期演进。1.3 为什么“分层”是AI应用架构的地基给不懂分层的朋友打个比方一个不分层AI系统就像一家没有前厅、后厨、仓库划分的餐厅。厨师要自己去接待客人自己记账自己跑出去买菜。一个人开的小店能转一旦客流量上来了立刻乱成一团。分层就是给系统划出明确的部门和交接规则。在AI应用里分层最大的收益是“隔离变化”。模型厂商升级接口只会影响模型网关这一层不需要改动业务逻辑提示词频繁调整只影响Prompt管理模块不必动到核心代码知识库从向量库换成新一代检索组件也只影响知识检索模块。这种隔离让一个三人小团队也能稳定维护一个庞杂的AI系统。更重要的是分层能让你在排查问题时快速定位。我见过太多没有分层的单体AI应用日志里只有一行“调模型失败”但到底是鉴权失败、网络超时、模型限流还是Prompt bug完全分不清楚。分层架构配合每层的指标采集才能把故障点从“系统坏了”缩小到“网关这层出了问题”。2. 模型网关、上下文与知识库三个必须扣死的设计细节把架构图铺开之后真正考验设计功底的是细节。模型网关、上下文管理和知识库检索是三个最容易被低估的模块。很多人以为它们只是“封装一下API”“把历史消息拼起来”“调一下向量库”实际做起来坑比想象中多得多。2.1 模型网关统一接入、路由与降级模型网关是AI应用架构里的“交通枢纽”所有模型请求都从这里进出。它的第一职责是统一接入不同模型厂商的API格式千差万别请求签名、超时时间、错误格式都不一样如果不做统一封装业务代码里会到处散落着厂商SDK调用换一家模型供应商就像动一次大手术。第二个职责是路由。同一个应用里简单问题可以让小模型回答复杂推理场景再切到旗舰模型白天调用量高可以按比例把部分请求切到另一个后端模型分流某个业务线用了新模型没验证充分可以通过网关做灰度先放5%流量过去观察。路由规则可以写死在配置里也可以用简单的权重策略动态调整。第三个职责是降级和容错。模型服务有时会因为限流、负载过高或证书过期等原因返回错误。好的网关至少要支持“主模型失败后自动切换备用模型”的兜底策略。这里有一个经验备用模型的回答质量和风格可能和主模型有明显差异降级触发时最好在响应里打一个标记方便后续数据分析时看到“这条请求其实走了备用模型”。否则你对比线上效果时会把模型质量的差异误判成业务逻辑的问题。2.2 多轮上下文状态不是靠“拼字符串”解决大模型本身是无状态的多轮对话能力完全靠应用层维护上下文。最简单的做法是把历史消息全部转成文本拼进去但这只是“能用”不是“可维护”。真正的上下文管理要解决两个问题第一个是“哪些内容该进上下文”第二个是“上下文满了怎么办”。对于第一个问题核心是区分“任务目标”和“历史痕迹”。系统提示词、用户当前问题、必要的知识召回片段属于任务目标不利于目标达成的寒暄、无关历史、上一轮工具执行的中间噪音都可以不进入上下文。对于第二个问题常见策略有三种截断、摘要、结构化遗忘。截断是最直接的方式保留最近N轮消息但要注意消息长度并不等于Token数中英文差距很大最好按字符数或Token数估算后动态截断。摘要适用于长对话场景每聊一段就把历史总结成一段短文再作为后续上下文的一部分。结构化遗忘则适合Agent场景把已完成的工具调用记录收进“执行日志”只把最终结果传递进上下文中从而避免工具中间过程塞满上下文窗口。我还建议所有上下文操作都走统一管理模块而不是散落在业务代码里到处拼接。这样你后续想引入摘要、滑动窗口或持久化历史恢复时只改一个模块就够了。2.3 知识外挂RAG召回链路中的向量库、重排与上下文裁剪RAG属于AI应用架构里绕不开的一环因为大模型的训练数据总有截止时间企业内部的文档和实时数据更需要外挂知识库来解决。RAG看起来就两步先召回、再生成。实际链路里至少有“文档解析、切片、向量化、召回、重排、上下文裁剪、生成”这些环节每一环都可能成为瓶颈。文档解析是第一步也是翻车率最高的一步。PDF、Word、PPT里的内容不是天然适合切片表格、多栏排版、复杂页眉页脚都会切割出大量语义不完整的碎片。我踩过的坑是直接按固定字符数切片后一个SQL查询示例被从中间切断生成回答时模型看到一段不完整的代码只能靠猜。更稳妥的做法是先按结构块切分段落下再按句组拆分每个切片尽量保持语义完整并保留标题路径作为检索时的位置信息。召回之后的重排同样关键。向量检索只负责把候选集捞回来真正的精度往往要靠重排模型或者基于规则的过滤器。举个例子用户问“退款多久到账”向量召回很可能把“如何申请退款”“退款政策说明”都捞出来但其中一些文档并没有讲“到账时间”这时就需要重排阶段把无关内容压下去。2.4 提示词管理从硬编码到模板化与版本化提示词在架构中的地位常常被低估。很多人今天直接在代码里改一句Prompt明天又回滚下午又覆盖完全没有版本概念。一个正规的AI应用架构提示词必须独立于代码管理。基础做法是模板化把系统提示词拆成“角色设定、任务说明、约束条件、输出格式、示例”等独立段各业务线通过配置组合。进阶做法是版本化每次修改建议都生成一个新版本可以随时回退也可以做A/B对比。再进一步可以把不同业务场景的提示词放在独立的配置中心非开发人员也能在后台微调而不需要动代码重新发布。还要留意提示词里的“变量注入”链路。用户信息、当前时间、知识库召回内容、工具返回结果这些变量从哪来、格式如何、如何拼接都值得在设计时明确。变量源头不稳定后面的模型输出就会跟着不稳定。3. Agent智能体应用与工作流编排架构里的“动线”如果说普通AI应用是一问一答Agent类应用就是在架构里加了一条“动线”模型不仅能说话还能决定要不要调用工具、调用哪个工具、工具结果如何影响下一步。这也是当前AI应用开发最热的方向像扣子这类可视化Agent平台能火起来本质上就是因为把Agent的编排门槛大幅降低了。但热度归热度Agent的架构设计比普通对话应用要复杂得多。3.1 Agent不是魔法是把“决策”显式化很多刚接触Agent开发的人以为Agent是一个“智能到能自主思考”的神秘组件。从架构角度看Agent的核心是“决策循环”根据当前任务模型选择下一步动作可能是直接回答也可能是调用某个工具应用层执行该动作并把结果交还给模型模型再判断是否继续操作直到达到终态。这个循环在代码上不复杂困难的是让它稳定。比如“该调用工具还是该直接回答”这个决策模型可能今天判断对了明天换了模型或改了提示词就频繁误调用。把决策显式化意味着每一步循环都要记录“模型想干什么、工具执行结果如何、模型最终基于什么信息作答”。只有这样你才能定位到“模型决策错了”还是“工具执行结果误导了模型”。我在实际项目中会比较克制地限定Agent的工具数量。工具数量越多模型需要理解的工具描述就越多选错工具的概率也越高。能用两三个工具解决的任务不要为了热闹接七八个。工具不在于多而在于每个工具的边界描述足够清晰。3.2 工具注册、参数校验与执行回放Agent调工具看起来是“模型直接调函数”实际上中间必须有一层工具注册与执行引擎。工具注册要求你为每个外部能力定义一个名称、一段自然语言描述、一套参数Schema。这段描述至关重要模型靠它来决定是否调用、传什么参数。描述写得太简单模型会在需要时想不起来有这工具描述写得太复杂模型又会抓不住重点。参数校验也是一道必不可少的工序。模型输出经常会出现参数缺漏、格式不合法、枚举值不对的情况。不要默认模型永远输出JSON执行引擎一定要做Schema校验不合法就带着错误信息回传给模型让模型自己纠正最多重试两到三次。执行回放则是指每次Agent运行时把模型决策、工具调用入参、工具返回结果都完整落日志。一旦线上Agent任务失败你可以像回放录像一样把整条决策链看一遍而不是只看到一句冰冷的报错。这里分享一个教训工具超时时间务必单独设置。有的外部API本身就要5秒才能返回如果统一沿用HTTP接口的3秒超时Agent第一轮就误判工具失败可能反复重试白白浪费Token。按工具属性单独配置超时时间比全局一刀切更合理。3.3 可视化编排平台与自研编排的取舍现在想搭Agent应用你面前有几条路用扣子这类可视化Agent平台用Dify这类开源低代码平台用LangChain/LangGraph这类开发框架或者纯自研编排引擎。这其实是架构选型问题没有绝对的好坏只有团队情况和业务诉求的不同。可视化平台的最大优势是上手快。把已封装好的节点拖来拖去就能在一天内搭出一个Agent原型特别适合业务验证阶段。它的坑在于当你需要做细粒度定制、访问私有数据、或者和已有系统做深度集成时平台抽象层可能会成为限制。开源框架则适合有一定研发能力的团队灵活度高但你需要自己消化版本升级的兼容性问题。自研编排是最后的选择只有当业务场景极其特殊、现有框架完全无法满足时才建议考虑因为投入成本确实不小。我给出一个相对稳当的选型建议验证阶段用可视化平台跑通业务逻辑生产阶段优先考虑开源框架或自研封装。不要把一个验证用的平台Demo直接推到生产环境否则后续每一次定制都像是在别人地基上盖楼牵一发动全身。3.4 一个客服问答场景的完整架构落地过程用一个具体场景把这些串起来假设我们要做一个售前客服Agent用户会问产品功能、价格、使用问题Agent需要检索商品文档还要能查询订单状态。接入层负责用户鉴权和会话创建模型网关统一接入大模型并配置多模型路由编排层先判断用户意图如果只是产品咨询走RAG链路如果涉及订单触发订单查询工具工具执行引擎按Schema校验参数后调用订单API拿到结果再整理给模型回复。实际落地时编排层会再拆两个子模块意图识别模块和任务执行模块。意图识别可以用分类模型或者让主模型顺带判断不建议单独起一个外部请求去判断意图那样会增加一次模型调用和额外延迟。任务执行模块内部维护“当前状态机”明确当前处于“等待用户提问”“检索知识库”“等待工具返回”还是“生成最终回答”的状态这样每一步都可以被跟踪和监控。整个链路走下来才能算一个具备生产价值的Agent应用。只调一次模型接口返回一段话的那种不叫Agent架构。4. 从开发到上线参数配置、成本估算与可观测性架构设计最终要落到生产环境。有几个问题开发环境里完全感受不到一旦上线就会立刻暴露参数没调好、成本失控、线上问题找不到线索。这一章专门讲“开发到上线”这个环节的实操细节。4.1 关键参数配置清单与Token成本计算公式先说模型参数。Temperature、Top P决定输出的随机性。客服场景建议Temperature设为0.3以下避免同一个问题每次回答五花八门创意文案场景可以调到0.7以上。Max Tokens要结合业务需要限制不是越大越好Output长度限制过大一方面增加成本另一方面无限制生成长文很容易跑偏。我整理了一份常用参考配置可以直接抄参数客服知识问答Agent工具调用创意写作Temperature0.2 - 0.40.0 - 0.20.7 - 0.9Top P0.90.80.95Max Tokens500 - 800800 - 12001500重试次数222成本估算一定要在架构设计阶段就做否则等账单出来再优化就晚了。每次调用的Token数大致等于“系统提示词 历史上下文 召回内容 工具描述 用户输入 模型输出”。在实际项目里系统提示词和工具描述每次请求都会消耗加起来可能是大头。计算公式不复杂单次调用成本 Token总量 / 1000 × 每千Token单价月度成本 预估日调用量 × 30 × 单次调用成本。举个例子一个客服Agent系统提示词加上工具描述约1000 Token每次带5轮历史约1000 Token用户当前输入约300 Token输出约400 Token总计约2700 Token。假设每千Token的综合成本比较低的情况下日调用量5000次一个月下来也是一笔可见的开支。如果业务量再翻几倍单靠省提示词就能省下不少钱。4.2 量化评估离线评测集、线上埋点与回归AI应用架构里评测系统经常晚于架构一起补上这是很多团队的常态。很多人上线后只靠“感觉回答变好了”来判断效果这种方式完全不可持续。我建议把评测拆成两层离线评测和线上监控。离线评测的关键是建一个评测集把典型问题、边界问题、对抗样本都放进去。每次改动Prompt或切换模型时跑一遍评测集对比回答质量。线上监控的关键是在响应日志里记录每一轮的完整链路信息包括模型名称、Token数、延迟、是否走知识库、是否调用工具、用户是否点了“有帮助”按钮。线上真实反馈是最有价值的数据不要忽略。还有一点大模型应用的回归不像传统软件那样非黑即白。答案可能“语义正确但不精确”或“风格变了但内容没变”所以建议在评测时设计一个简单的评分维度准确度、完整性、相关性、格式合规性每个维度打1到5分长期看分数变化趋势即可。4.3 性能与稳定性限流、缓存、异步化与降级AI应用上线一定要注意模型服务端的限流。模型接口并不是无限并发可用你这边突增的流量会直接触发限流错误。接入层做用户级限流模型网关做总量级限流两层配合才能保护后端模型服务。缓存是优化成本和延迟的利器。对于固定FAQ类问题完全可以用缓存把常用回答直接命中跳过模型调用成本直接降到零。但缓存需要设计一个相似度判断层精确命中太苛刻用向量相似度或文本归一化做近似匹配更实用。耗时较长的操作建议改成异步任务。比如Agent需要在多轮工具调用之间循环如果同步等待用户界面会一直转圈。把任务提交进队列后台执行完成后通过消息通道推送结果体验会好很多。降级方案更是必不可少主模型不可用时至少要有一个“熔断后走备用模型”或者“提示用户稍后再试”的兜底策略。5. 架构上线后最容易踩的坑故障实录与排查速查表前面讲的都是设计层面的东西这一章我整理一份实战故障记录。这些坑我基本都踩过有些甚至在线上环境才暴露。对照速查表排查能省掉不少定位时间。5.1 上下文长度失控与生成中断现象对话轮数一多请求报错“上下文超出最大长度”或者模型回答到一半被截断。排查思路先看日志里记录的每次请求Token数找到哪个环节的Token增长最快。通常是历史消息无限制堆积或工具返回的中间结果被无脑塞进上下文。解决建议为上下文模块配置Token预算比如总预算8000 Token内系统和当前问题占3000剩余用来放历史和知识。超出预算时用滑动窗口或对话摘要顶替旧消息。生成中断则要关注Max Tokens设置客服场景控制在较低值如果业务需要长回答可以在前端做流式输出让用户先看到内容而不是等完整结果。5.2 向量召回不准与幻觉难除现象用户问的明明是售后政策模型却从产品说明文档里找了一段相关但答非所问的内容还有模型一本正经地编造不存在的退货时间。排查思路先定位召回链路看召回切片内容和原始文档是否一致判断切片是否完整再看重排有没有把真正相关的片段放到最前面最后看生成时的提示词是否约束“仅使用参考资料”。解决建议召回精度优先保证切片质量结构块切分比固定长度切分更稳。重排模型不是万能的先把规则过滤做好再谈模型重排。生成阶段一定要在提示词里写明参考资料中没有相关信息时明确回答“未知”不要编造。这个约束对客服场景尤其重要。5.3 工具调用失败与Agent死循环现象Agent一直在“调用工具-拿结果-再调用工具”之间打转Token消耗飙升用户却迟迟等不到最终回答。排查思路把决策链日志完整拉出来看每轮模型决策落到哪个工具、入参是否合法、工具返回内容是什么。判断是模型选错了工具还是工具返回格式导致模型无法判断下一步。解决建议给Agent循环设置最大轮数限制比如4到6轮超时直接结束并输出兜底文案。工具返回内容在交还模型之前做一次结构化整理把关键信息压缩成简洁摘要减少模型被冗长的原始JSON干扰的概率。同时要求模型每次决策都在“最终回答”和“工具调用”之间二选一不要给第三个模糊选项。5.4 线上延迟突增与模型限流现象业务高峰期接口响应从2秒涨到10秒甚至大量超时部分请求返回模型限流错误。排查思路分三块看。先看模型网关日志确认是否命中限流再看缓存命中率如果缓存率低且流量大说明高频重复问题没有被缓存覆盖最后看编排层是否有同步串行调用比如先调一次模型做意图判断又调一次模型做结果生成两次都等待则总耗时叠加。解决建议能缓存的热门问题尽量缓存能并行的工具调用尽量并行比如同时查询产品详情和库存而不是串行等待。模型网关要做排队策略和熔断当错误率超过阈值时快速切到备用模型或直接返回提示。这个场景运维工程师一定要盯紧链路日志别只看模型服务本身的指标AI应用卡顿往往卡在业务编排层而不是模型层。最后再分享一个我个人的实际体会画架构图不要为了画而画不要追求画得好看、完整追求的是让团队每个人对请求从入口到出口的路径达成共识。哪怕一开始只有一张潦草的框图只要它能解释清楚数据从哪里来、经过哪些环节、出问题看哪块日志它就已经比一份精美的PPT有价值。AI应用的架构设计本质上是在不确定性里搭出确定性骨架而骨架牢固与否决定了上层业务能跑多远。