很多人一听到“AI应用架构设计”第一反应是这不就是调一个模型接口的事吗需求进来Prompt一拼调用大模型拿结果返回收工。如果你只是做个Demo、跑个原型这么说没毛病。但一旦这个应用要面对真实用户、要扛住生产流量、要保证输出质量稳定你就会发现模型本身只是整个系统里的一环围绕它还需要一层又一层的基础设施和治理机制。这篇文章我想用图解的方式把AI应用架构这件事从头到尾拆一遍——不写代码只画图、讲原理、说人话。内容偏工程实践适合正在从“原型”往“产品”过渡的开发者、技术负责人以及所有想搞清楚“一个生产级AI应用到底由哪些部件组成”的人。1. 先把丑话说在前面AI应用架构到底在架构什么聊架构之前我们先对齐一个前提AI应用和传统软件应用在架构设计上有一个根本性的差异——传统系统追求确定性AI系统必须拥抱概率性。传统后端请求进来、逻辑执行、数据落库、响应返回每一步都是可预期、可复现的。你输入11它永远不会返回3。但AI应用不是这样。同一个Prompt同一个模型同一次调用结果都可能不同。这就带来一系列连锁反应你的数据流不再是简单的“输入-处理-输出”而是变成了“语义流”——每一层都在做理解、判断、转换中间任何一环出现偏差最终结果都可能跑偏。所以AI应用架构真正要解决的不是“怎么把模型跑起来”而是“在模型输出不可控的前提下怎么搭出一个可控的系统”。我画架构图的时候特别喜欢用一个类比模型是发动机架构是整辆车。发动机决定上限但底盘、悬挂、刹车、仪表盘决定这辆车能不能安全、平稳、舒适地抵达目的地。你见过有人把F1发动机装在买菜车上的吗那就是典型的“模型选型猛如虎周边架构原地杵”。有了这个前提下面每一层你都能看懂了。1.1 传统架构的“确定性底座”在AI这里失效了传统架构里你可以用单元测试覆盖绝大多数逻辑分支因为行为是可枚举的。AI应用不行你没法穷举所有用户输入。这就意味着你以前习惯的很多手段会失效报错堆栈变成了“输出不符合预期”线上Bug从“必现”变成了“偶发”回归测试从“跑一遍用例”变成了“跑一遍评测集人工抽检”。这不是说传统架构的经验没用了而是说AI应用需要在传统架构之上叠加一层专门应对“不确定性”的机制。这一层包含哪些东西后面每一节都会展开。1.2 你的系统里流动的不只是数据还有“语义”传统架构里字段就是字段字符串就是字符串A系统的输出可以无缝作为B系统的输入。AI架构里模型输出的自然语言文本对下一个模块来说只是“半成品”——它需要被解析、校验、转成结构化数据或者直接被当作语义片段传给下一个模型调用。你从数据库里查出来一条记录那是确定的你从向量数据库里召回一批“相似片段”那只能说是“可能相关”。这种从“精确”到“模糊”的转变是整个架构设计里最需要习惯、也最需要专门处理的地方。1.3 组织一次架构时我通常会画这五层为了不让讨论停留在概念层我给自己定了一个分层框架每次画图都先落这五层接入层用户的请求入口负责多模态输入处理、会话管理、权限校验。编排层理解用户意图拆解任务决定调用哪些模型和工具。模型服务层实际托管和调度大模型、小模型、多供应商模型。知识层业务数据、记忆、RAG检索、向量库等与领域知识相关的能力。治理层评测、护栏、可观测性、成本控制贯穿所有层。有了这个骨架再往里面填细节就会清晰很多。接下来我从一次真实请求说起把这五层串起来。2. 从一次用户请求出发看完整条调用链路怎么走纸上谈兵没有意义我们直接追一次请求的完整生命周期。假设你做了一个AI客服应用用户提了一个问题“你们的产品支持信用卡分期吗我上个月账单还能分吗”这个问题到你的系统里会经历什么2.1 请求入口别让用户直接面对模型第一站是接入层。用户的话先进网关做几件基础但重要的事身份鉴权、频控、内容合规预检。为什么不能让用户请求直接打到模型因为模型是无状态的、昂贵的、且不设防的。没有接入层的保护和协议转换你根本没法做后面的编排。接入层还会做一件事判断这次请求是不是走模型。很多AI应用里高达30%-50%的问题其实可以靠规则、常见问题知识库直接命中根本不需要触发大模型调用。在接入层做一次轻量分类能省下真金白银。2.2 链路复盘每一步都在“翻译”和“决策”请求通过接入层之后进入编排层。这里通常是架构里最核心、也最复杂的部分意图识别先判断用户是不是在问账单分期相关的问题还是想投诉、想转人工。这一步可以用模型也可以用规则模型组合。任务拆解如果问题涉及“上个月账单”就需要先去订单系统或账单服务查询数据再结合产品规则回答。于是任务被拆成两步调用查询工具、再生成回答。知识检索如果模型需要业务知识比如分期规则编排层会触发知识检索从向量库里召回相关业务文档片段。模型调用把用户问题、检索到的资料、历史对话摘要拼成Prompt调用大模型。工具调用模型判断需要查账单于是返回一个结构化指令系统去执行真实的查询接口拿到数据后再回填给模型。输出校验模型给出最终答案之后系统还要做格式检查、敏感词过滤、答案与检索内容的引用一致性校验。每一步都环环相扣。任何一个环节出错用户看到的就是“答非所问”或者“完全跑偏”。2.3 一次典型请求的耗时和失败点分布我给自己画的架构图做过一次线上耗时拆解大概是这样的比例环节耗时占比主要风险接入层5%鉴权失败、限流失效意图识别10%分类错误导致后续全部走偏知识检索15%召回内容与问题不相关模型调用50%输出延迟、超时、结果不稳定工具调用15%外部接口慢、返回数据格式变化输出校验5%误杀正常回答、漏检风险内容这张表告诉我们一个残酷的事实模型调用只占一半时间但失败点却分布在每一个环节。架构设计的重点不是把模型调用做到极致而是把每个环节的失败概率降下来并在失败时能快速定位、优雅降级。这就是后面要聊的模型网关和可观测性的价值所在。3. 模型网关比想象中更早该引入的一层很多团队一开始没有“模型网关”这个概念直到某天主模型服务挂了或者账单飞涨才意识到自己需要一层“模型路由器”。我的建议是只要你的应用开始接入第二个模型或者你开始关心线上成本就应该上模型网关。3.1 模型网关到底解决什么问题简单说四个字统一、治理。再展开一点统一接口上游业务方不用关心你接的是哪个供应商的模型、是自研还是第三方的只要按一个标准协议调用就行。多模型路由同一个请求按业务场景、用户等级、成本策略路由到不同模型。便宜的模型能干的事绝不动用贵模型。高可用降级主模型超时或报错时自动切到备用模型或备用通道。成本与配额控制给不同部门、不同业务线设定Token配额、并发上限防止一个疯狂调用拖垮整个账户。语义缓存命中缓存直接返回省掉一次真实模型调用。我们线上有段时间缓存命中率到30%成本直接降了一大截。3.2 网关的形态选择什么时候不需要、什么时候必须上阶段不同方案完全不同阶段模型数量推送的复杂度推荐形态原型Demo1极低直接写代码拉起SDK产品早期2-3中低在应用代码里封装一层路由规模生产3高独立网关服务统一接入有一个很常见的错误一上来就搭一个非常复杂的模型网关平台结果业务还没跑起来光维护网关就累死人。网关的复杂度应该跟着业务复杂度走不要超前设计。等到你真的被某个供应商的故障坑过一次你就会心甘情愿把网关的优先级提上来。3.3 网关落地时最容易被忽略的细节我踩过几个坑值得说道说道第一超时和重试的设计。模型接口不是数据库重试的代价极高。主模型超时3秒你重试一次用户已经等了6秒体验已经坏了。我的经验是第一轮超时设短一点快速失败降级到备用模型时再放宽超时阈值。第二流式响应的缓存策略。模型走流式输出时你没法直接套用普通缓存需要做增量缓存和流式回放这个复杂度比你想象得高不少。第三Token统计口径要统一。不同供应商对Token的计费口径不同网关一定要做标准化的Token计量否则成本分析全是糊涂账。4. 上下文与记忆管理AI应用的“内存系统”如果你把一个AI应用比作一个人模型是这个人的大脑上下文和记忆管理就是他的工作记忆和长期记忆。没有记忆的AI应用就像金鱼——用户上一句话刚说完它转头就忘了。4.1 上下文窗口的物理限制决定了你没法“全记住”模型有上下文窗口限制这不是软件Bug是物理约束。你不可能把用户所有的历史消息、所有的知识文档都塞进去。所以上下文管理的第一课是学会做“预算”。我给团队定的简单预算规则一次模型调用的上下文分为三块——系统指令、对话历史、 Retrieval内容。其中系统指令是固定的对话历史控制在一个滑动窗口内Retrieval内容要做精简精排。每一块的Token都要分配上限超过上限就要截断、压缩、或者用更早的摘要替代。4.2 短期会话记忆把最近几轮对话留住短期内对话历史是直接拼进Prompt的。这里有一个很多人忽略的细节不是所有历史都要原样保留。用户说“那个”的时候你需要能指代消解到前文里提到的某个具体对象。所以优质的短期记忆不只是存“用户说了什么”还要存“当前会话状态”——上一次对话涉及的主题、实体、动作卡片。我会在架构图里把会话状态单独画一个存储层用实时的键值存储保存。每轮对话结束后把“状态摘要”更新一次。这样即使模型没有记忆能力应用本身也能做到“知道你在说什么”。4.3 长期记忆摘要与向量双轨并行超过滑动窗口的内容或者跨会话的内容就要进入长期记忆。长期记忆我推荐双轨方案摘要轨定期对历史对话生成结构化摘要存成JSON或Markdown。下次会话开始时把摘要注入Prompt。这个方案便宜、快、足够用。向量轨把关键信息以向量形式存入向量库需要时做相似度检索。这个方案更精确但复杂度和成本更高。务实建议绝大多数客服、助手类应用摘要轨就能覆盖80%的需求。向量轨等业务确实需要“从海量记忆中精确找细节”时再上别一开始就给自己找麻烦。4.4 上下文工程比Prompt工程更值得投入比起钻研“花样Prompt”我更建议把时间花在上下文工程上。上下文工程的核心就是把什么内容放进上下文、什么不放、以什么顺序放、放多少。我在实际项目中常用的几个策略关键信息前置把用户核心需求、系统状态放在Prompt开头减少模型在长文本中“迷失重要信息”的概率。不去重读全文引用历史摘要时只摘与当前话题相关的部分。压缩过时内容用户已经明确改主意了旧的信息就不再塞入上下文。结构化代替散文能用列表、键值对表达的就不要用一段段自然语言。这些做下来你会发现同样一个模型回答的准确率和稳定性能明显提升。这比换个更大参数的模型性价比高得多。5. 知识注入与RAG从“会聊天”到“懂业务”无论你的模型多强它都不会自动知道你公司的产品规则、历史工单、私有文档。让AI应用“懂业务”目前最主流、最可控的方案就是RAG——检索增强生成。但RAG不是简单地接一个向量数据库就完事它是一个完整的管线。5.1 RAG管线拆解每一步都有讲究一个能用的RAG管线至少包含这样几段文档解析PDF、Word、网页、表格每种格式都要转成可检索的文本。表格尤其容易出问题解析成纯文本后就丢失了结构信息检索效果会大幅下降。分块Chunking不是均匀切块那么简单的。理想的分块是语义完整的段落并且要适当包含小标题、上下文锚点。我们做过实验按固定300字切块召回准确率比按章节语义切块低十几个百分点。嵌入Embedding把文本转成向量。这一步的模型选择也很关键通用嵌入模型对你的垂直领域可能效果一般有预算的话在领域语料上微调一下嵌入模型提升很明显。召回Retrieval从向量库里找出Top-K相关片段。这里有一个隐蔽坑——向量检索对短文本、专有名词的召回经常不准所以现在主流做法是“混合检索”向量检索关键词检索重排。重排Rerank召回回来的Top-50用一个轻量模型重新打分挑出Top-5再喂给大模型。重排是性价比极高的一环强烈建议加上。5.2 混合检索向量不是银弹很多人以为向量检索是万能的其实不是。用户问“你们怎么退款”数据库里存的是“售后处理流程”两者语义上相关但关键词完全不同向量能兜住可如果用户问的是产品型号“A-3000”文档里恰好写的是“A3000”没有那个连字符向量检索很可能召回失败关键词检索却能精准命中。所以我在架构里画的检索模块永远是三路并联向量路、关键词路、还有一路规则路比如通过产品型号字典直接查表。三路结果合并后再重排。实测下来综合召回率比单路向量检索高出一截。5.3 缓存与新鲜度知识更新的矛盾RAG系统里知识的源头是你的业务数据库和文档库。这里有一个经典矛盾数据更新得越勤Cache命中率越低Cache太久用户又可能拿到过期信息。我的经验是分两级热门通用知识走缓存命中高、更新频率低涉及具体订单、用户数据等实时信息一律绕过缓存直查。不要试图对所有内容做统一缓存策略按数据新鲜度要求分类处理才是正道。6. Agent化改造让应用从“被动回答”到“主动完成”RAG解决的是“懂业务”Agent要解决的是“能干事儿”。AI应用架构演进到一定阶段你一定会遇到这样的需求用户不只是想知道退货规则还希望系统帮他把退货申请提交了、把退款进度查出来。这时候简单的一问一答就不够了你需要引入Agent机制。6.1 从“说”到“做”工具调用的本质Agent的核心能力是工具调用。模型输出一段结构化的“行动指令”比如{ action: query_refund_status, params: { order_id: 20250115001, customer_level: vip } }系统解析这段指令调用真实的业务接口拿到结果再把这个结果作为新的上下文回传给模型让模型决定下一步。这就是一个“感知-决策-行动-再感知”的循环业界一般叫ReAct模式。这个机制本身不复杂复杂的是两个点一是怎么让模型输出稳定、可解析的结构化指令二是怎么让工具结果的回填不把上下文撑爆。前者靠有效的工具注册表和清晰的函数描述后者靠第4节说的上下文管理。6.2 工具注册表让模型知道“你有什么工具”很多Agent翻车不是因为模型笨而是因为模型根本不知道你有什么工具、工具是干什么的、参数怎么填。所以工具注册表很重要每个工具都要有明确的名称、描述、参数Schema、调用约束。值得注意的小技巧工具描述要写“对人类有用的信息”比如“该工具用于查询近三个月的账单明细适合回答与消费记录相关的问题”而不是只写“查询账单”。描述越具体模型选对工具的概率越高。此外工具数量不是越多越好。我们做过一次测试把工具从20个加到50个模型选错工具的比率几乎翻倍。工具超过10个以后建议做一层工具路由先按意图把候选工具缩小到3-5个再让模型做最终选择。6.3 边界与护栏Agent最大的威胁是“过度自信”Agent给系统带来能动性的同时也带来新的风险。模型自作主张调用了不该调用的接口、模型在不确定参数时瞎猜了一个值、多轮工具调用导致失控——这些都是线上真实会遇到的翻车现场。我总结了三道基本护栏权限最小化Agent能调用的工具、能触达的数据面都必须显式授权。不该碰的接口直接从工具注册表里拿掉。人工确认机制涉及资金操作、数据删除、外发通知等敏感动作必须经过用户确认或业务审批。调用链上限限制Agent单次任务的最多工具调用轮数超过即停止防止模型陷入死循环。Agent不是越自由越好一个“戴着镣铐跳舞”的Agent往往比一个“全自由”的Agent更让人放心。7. 质量与稳定性评测、护栏、可观测性一个都不能少架构搭得再漂亮如果回答质量不稳定用户照样会跑。AI应用和传统应用的另一个大区别是你没法靠“上线前测一遍”来保证质量因为输入空间近乎无限。这时候需要把质量保障做成一套持续性机制。7.1 评测集你的“试金石”和“回归网”没有评测集就去优化Prompt基本等于摸黑开车。评测集不是随手收集几个问题就行我建议至少包含这几类标准问答集覆盖核心业务场景的经典问题每个问题配参考答案和评分标准。边界输入集空输入、超长输入、敏感话题、方言口语、中英混杂等。工具调用集明确需要调用某个工具的请求检验Agent路由和参数提取准确率。困难负例集模型容易答错或乱编的题型防止回归。有了评测集每一次改动都可以离线跑分用数据说话。优秀的标准是核心指标不下降的前提下再去优化体验细节。7.2 输入输出护栏把风险挡在系统之外模型本身自带一定的内容合规能力但远远不够。生产级的AI应用必须有独立的输入输出护栏输入侧鉴权、限流、敏感内容识别、Prompt注入攻击检测。Prompt注入是AI应用特有的安全风险用户可能用“忽略之前所有指令”来试图操纵模型护栏要识别这类模式。输出侧格式校验、敏感信息过滤、幻觉检测。幻觉检测可以简单做“答案与检索内容一致性比对”——如果模型答案里的关键实体不在参考文档里就要标记出来人工复核。7.3 可观测性AI应用比传统系统更需要“黑匣子”传统应用出问题你看日志看链路能很快定位。AI应用出问题你面对的是“一段自然语言回答不太好说是对是错”。所以可观测性要记录的不只是调用日志还要记录Prompt快照这次请求实际发了什么内容给模型包括填充了什么上下文、用了哪条系统指令。模型输出原始数据不要只存最终返回给用户的话还要存模型的原始输出和中间思考步骤。评测打分结果这条回答在离线评测体系里能得多少分、哪一项丢分了。成本明细每次请求消耗了多少Token、多少钱撑爆预算的元凶是谁。排查线上质量问题时这套“黑匣子”能救你无数次。7.4 线上监控别让“回答质量”成为黑盒我习惯用一套阶梯式监控策略监控层级关注指标预警方式系统层请求成功率、时延、并发实时告警模型层Token消耗、供应商错误率、重试率日报异常告警质量层评测集抽样得分、用户反馈负面率周报趋势分析业务层转化率、用户留存、客服转人工率周报质量层的监控需要设计抽样机制每天自动抽取一批线上对话跑一遍评测打分分数下滑就触发复盘。这样你就能把“感觉最近变差了”变成“本周质量分从87降到82原因是什么”从根本上消灭玄学。8. 一张图收尾完整架构蓝图与分阶段落地方案说了一堆我们回到标题里的关键词——“图解”。下面是我心目中一个相对完整、但又不至于过度设计的生产级AI应用架构蓝图。它不一定适合所有人但可以作为你画自己架构图时的起点----------------------------------------------- | 治理层评测 / 护栏 / 追踪 / 成本 | ----------------------------------------------- | 用户 → 接入层(鉴权/限流/合规) → 编排层(意图/任务/路由) → 模型网关 → 大模型服务(多供应商) | | | | | ---------- ------ ---v--- | | 知识/记忆层 | | 工具层 | | 侧路模型 | ----------------→| RAG/向量/缓存|←--------- 业务API |-----------| 嵌入/重排| ------------- ------- -------图要怎么看三层纵向上面是治理层横向贯穿所有环节中间是核心调用链从左到右一次请求的路径下面承接支撑层包括知识、工具、模型服务。注意画图时别把治理层画成“挂在边上的一块”它应该像一张网罩住所有环节。8.1 分阶段落地别一口吃成胖子如果你从零开始搭一个AI应用我的建议是不用一步到位按节奏演进阶段一最小闭环模型Prompt几个手工拼的上下文逻辑先跑通一个核心场景积累真实问题和评测集。这个阶段不要上任何重型组件。阶段二稳定化引入模型网关、加RAG管线、建立基础评测集目的只有一个——让核心场景的回答稳定且可复现。阶段三规模化再加入Agent、工具调用、更精细的记忆管理、可观测性平台开始做成本优化和复杂任务处理。阶段四治理化护栏、合规、灰度发布、持续评测让系统能承受更大规模、更复杂业务的考验。关于演进路线我见过太多团队死在“阶段一就想把架构搭完整”结果拖慢上线节奏、消耗信心。记住架构是为业务服务的不是用来炫技的。先活下来再变强。8.2 小团队的落地次序建议如果你所在的团队不大资源有限最值得优先投入的顺序是模型网关降本高可用→ 评测集防止瞎优化→ 上下文管理提升核心质量→ RAG扩展业务能力→ 护栏守住底线→ 剩下的按需补位。把预算花在这几个方向长期回报都很好。最后再分享一点个人心得做了这么多AI应用架构的梳理和验证我自己最大的感受是不要把“架构设计”想成一个一次性画图的工作它更像是在持续演进中不断画图、推翻、再画的过程。我的工作习惯是每过一个迭代周期就把架构图重新画一遍删掉那些已经不需要的组件、补上新出现的需求点。画图不是为了好看而是为了逼自己想清楚每个模块为什么存在、边界在哪里、依赖谁、如果它挂了会发生什么。如果你正在为自己的AI应用做架构我的建议很朴素先不要沉迷于各种新概念回到那张五层图上看哪一层最薄弱就优先补哪一层。模型会不断进化框架会不断涌现但架构的底层逻辑——管理不确定性、控制成本、保障质量——会长期有效。希望这篇图解能给你提供一个靠谱的思考框架少走一些我们走过的弯路。
很多人一听到“AI应用架构设计”第一反应是这不就是调一个模型接口的事吗需求进来Prompt一拼调用大模型拿结果返回收工。如果你只是做个Demo、跑个原型这么说没毛病。但一旦这个应用要面对真实用户、要扛住生产流量、要保证输出质量稳定你就会发现模型本身只是整个系统里的一环围绕它还需要一层又一层的基础设施和治理机制。这篇文章我想用图解的方式把AI应用架构这件事从头到尾拆一遍——不写代码只画图、讲原理、说人话。内容偏工程实践适合正在从“原型”往“产品”过渡的开发者、技术负责人以及所有想搞清楚“一个生产级AI应用到底由哪些部件组成”的人。1. 先把丑话说在前面AI应用架构到底在架构什么聊架构之前我们先对齐一个前提AI应用和传统软件应用在架构设计上有一个根本性的差异——传统系统追求确定性AI系统必须拥抱概率性。传统后端请求进来、逻辑执行、数据落库、响应返回每一步都是可预期、可复现的。你输入11它永远不会返回3。但AI应用不是这样。同一个Prompt同一个模型同一次调用结果都可能不同。这就带来一系列连锁反应你的数据流不再是简单的“输入-处理-输出”而是变成了“语义流”——每一层都在做理解、判断、转换中间任何一环出现偏差最终结果都可能跑偏。所以AI应用架构真正要解决的不是“怎么把模型跑起来”而是“在模型输出不可控的前提下怎么搭出一个可控的系统”。我画架构图的时候特别喜欢用一个类比模型是发动机架构是整辆车。发动机决定上限但底盘、悬挂、刹车、仪表盘决定这辆车能不能安全、平稳、舒适地抵达目的地。你见过有人把F1发动机装在买菜车上的吗那就是典型的“模型选型猛如虎周边架构原地杵”。有了这个前提下面每一层你都能看懂了。1.1 传统架构的“确定性底座”在AI这里失效了传统架构里你可以用单元测试覆盖绝大多数逻辑分支因为行为是可枚举的。AI应用不行你没法穷举所有用户输入。这就意味着你以前习惯的很多手段会失效报错堆栈变成了“输出不符合预期”线上Bug从“必现”变成了“偶发”回归测试从“跑一遍用例”变成了“跑一遍评测集人工抽检”。这不是说传统架构的经验没用了而是说AI应用需要在传统架构之上叠加一层专门应对“不确定性”的机制。这一层包含哪些东西后面每一节都会展开。1.2 你的系统里流动的不只是数据还有“语义”传统架构里字段就是字段字符串就是字符串A系统的输出可以无缝作为B系统的输入。AI架构里模型输出的自然语言文本对下一个模块来说只是“半成品”——它需要被解析、校验、转成结构化数据或者直接被当作语义片段传给下一个模型调用。你从数据库里查出来一条记录那是确定的你从向量数据库里召回一批“相似片段”那只能说是“可能相关”。这种从“精确”到“模糊”的转变是整个架构设计里最需要习惯、也最需要专门处理的地方。1.3 组织一次架构时我通常会画这五层为了不让讨论停留在概念层我给自己定了一个分层框架每次画图都先落这五层接入层用户的请求入口负责多模态输入处理、会话管理、权限校验。编排层理解用户意图拆解任务决定调用哪些模型和工具。模型服务层实际托管和调度大模型、小模型、多供应商模型。知识层业务数据、记忆、RAG检索、向量库等与领域知识相关的能力。治理层评测、护栏、可观测性、成本控制贯穿所有层。有了这个骨架再往里面填细节就会清晰很多。接下来我从一次真实请求说起把这五层串起来。2. 从一次用户请求出发看完整条调用链路怎么走纸上谈兵没有意义我们直接追一次请求的完整生命周期。假设你做了一个AI客服应用用户提了一个问题“你们的产品支持信用卡分期吗我上个月账单还能分吗”这个问题到你的系统里会经历什么2.1 请求入口别让用户直接面对模型第一站是接入层。用户的话先进网关做几件基础但重要的事身份鉴权、频控、内容合规预检。为什么不能让用户请求直接打到模型因为模型是无状态的、昂贵的、且不设防的。没有接入层的保护和协议转换你根本没法做后面的编排。接入层还会做一件事判断这次请求是不是走模型。很多AI应用里高达30%-50%的问题其实可以靠规则、常见问题知识库直接命中根本不需要触发大模型调用。在接入层做一次轻量分类能省下真金白银。2.2 链路复盘每一步都在“翻译”和“决策”请求通过接入层之后进入编排层。这里通常是架构里最核心、也最复杂的部分意图识别先判断用户是不是在问账单分期相关的问题还是想投诉、想转人工。这一步可以用模型也可以用规则模型组合。任务拆解如果问题涉及“上个月账单”就需要先去订单系统或账单服务查询数据再结合产品规则回答。于是任务被拆成两步调用查询工具、再生成回答。知识检索如果模型需要业务知识比如分期规则编排层会触发知识检索从向量库里召回相关业务文档片段。模型调用把用户问题、检索到的资料、历史对话摘要拼成Prompt调用大模型。工具调用模型判断需要查账单于是返回一个结构化指令系统去执行真实的查询接口拿到数据后再回填给模型。输出校验模型给出最终答案之后系统还要做格式检查、敏感词过滤、答案与检索内容的引用一致性校验。每一步都环环相扣。任何一个环节出错用户看到的就是“答非所问”或者“完全跑偏”。2.3 一次典型请求的耗时和失败点分布我给自己画的架构图做过一次线上耗时拆解大概是这样的比例环节耗时占比主要风险接入层5%鉴权失败、限流失效意图识别10%分类错误导致后续全部走偏知识检索15%召回内容与问题不相关模型调用50%输出延迟、超时、结果不稳定工具调用15%外部接口慢、返回数据格式变化输出校验5%误杀正常回答、漏检风险内容这张表告诉我们一个残酷的事实模型调用只占一半时间但失败点却分布在每一个环节。架构设计的重点不是把模型调用做到极致而是把每个环节的失败概率降下来并在失败时能快速定位、优雅降级。这就是后面要聊的模型网关和可观测性的价值所在。3. 模型网关比想象中更早该引入的一层很多团队一开始没有“模型网关”这个概念直到某天主模型服务挂了或者账单飞涨才意识到自己需要一层“模型路由器”。我的建议是只要你的应用开始接入第二个模型或者你开始关心线上成本就应该上模型网关。3.1 模型网关到底解决什么问题简单说四个字统一、治理。再展开一点统一接口上游业务方不用关心你接的是哪个供应商的模型、是自研还是第三方的只要按一个标准协议调用就行。多模型路由同一个请求按业务场景、用户等级、成本策略路由到不同模型。便宜的模型能干的事绝不动用贵模型。高可用降级主模型超时或报错时自动切到备用模型或备用通道。成本与配额控制给不同部门、不同业务线设定Token配额、并发上限防止一个疯狂调用拖垮整个账户。语义缓存命中缓存直接返回省掉一次真实模型调用。我们线上有段时间缓存命中率到30%成本直接降了一大截。3.2 网关的形态选择什么时候不需要、什么时候必须上阶段不同方案完全不同阶段模型数量推送的复杂度推荐形态原型Demo1极低直接写代码拉起SDK产品早期2-3中低在应用代码里封装一层路由规模生产3高独立网关服务统一接入有一个很常见的错误一上来就搭一个非常复杂的模型网关平台结果业务还没跑起来光维护网关就累死人。网关的复杂度应该跟着业务复杂度走不要超前设计。等到你真的被某个供应商的故障坑过一次你就会心甘情愿把网关的优先级提上来。3.3 网关落地时最容易被忽略的细节我踩过几个坑值得说道说道第一超时和重试的设计。模型接口不是数据库重试的代价极高。主模型超时3秒你重试一次用户已经等了6秒体验已经坏了。我的经验是第一轮超时设短一点快速失败降级到备用模型时再放宽超时阈值。第二流式响应的缓存策略。模型走流式输出时你没法直接套用普通缓存需要做增量缓存和流式回放这个复杂度比你想象得高不少。第三Token统计口径要统一。不同供应商对Token的计费口径不同网关一定要做标准化的Token计量否则成本分析全是糊涂账。4. 上下文与记忆管理AI应用的“内存系统”如果你把一个AI应用比作一个人模型是这个人的大脑上下文和记忆管理就是他的工作记忆和长期记忆。没有记忆的AI应用就像金鱼——用户上一句话刚说完它转头就忘了。4.1 上下文窗口的物理限制决定了你没法“全记住”模型有上下文窗口限制这不是软件Bug是物理约束。你不可能把用户所有的历史消息、所有的知识文档都塞进去。所以上下文管理的第一课是学会做“预算”。我给团队定的简单预算规则一次模型调用的上下文分为三块——系统指令、对话历史、 Retrieval内容。其中系统指令是固定的对话历史控制在一个滑动窗口内Retrieval内容要做精简精排。每一块的Token都要分配上限超过上限就要截断、压缩、或者用更早的摘要替代。4.2 短期会话记忆把最近几轮对话留住短期内对话历史是直接拼进Prompt的。这里有一个很多人忽略的细节不是所有历史都要原样保留。用户说“那个”的时候你需要能指代消解到前文里提到的某个具体对象。所以优质的短期记忆不只是存“用户说了什么”还要存“当前会话状态”——上一次对话涉及的主题、实体、动作卡片。我会在架构图里把会话状态单独画一个存储层用实时的键值存储保存。每轮对话结束后把“状态摘要”更新一次。这样即使模型没有记忆能力应用本身也能做到“知道你在说什么”。4.3 长期记忆摘要与向量双轨并行超过滑动窗口的内容或者跨会话的内容就要进入长期记忆。长期记忆我推荐双轨方案摘要轨定期对历史对话生成结构化摘要存成JSON或Markdown。下次会话开始时把摘要注入Prompt。这个方案便宜、快、足够用。向量轨把关键信息以向量形式存入向量库需要时做相似度检索。这个方案更精确但复杂度和成本更高。务实建议绝大多数客服、助手类应用摘要轨就能覆盖80%的需求。向量轨等业务确实需要“从海量记忆中精确找细节”时再上别一开始就给自己找麻烦。4.4 上下文工程比Prompt工程更值得投入比起钻研“花样Prompt”我更建议把时间花在上下文工程上。上下文工程的核心就是把什么内容放进上下文、什么不放、以什么顺序放、放多少。我在实际项目中常用的几个策略关键信息前置把用户核心需求、系统状态放在Prompt开头减少模型在长文本中“迷失重要信息”的概率。不去重读全文引用历史摘要时只摘与当前话题相关的部分。压缩过时内容用户已经明确改主意了旧的信息就不再塞入上下文。结构化代替散文能用列表、键值对表达的就不要用一段段自然语言。这些做下来你会发现同样一个模型回答的准确率和稳定性能明显提升。这比换个更大参数的模型性价比高得多。5. 知识注入与RAG从“会聊天”到“懂业务”无论你的模型多强它都不会自动知道你公司的产品规则、历史工单、私有文档。让AI应用“懂业务”目前最主流、最可控的方案就是RAG——检索增强生成。但RAG不是简单地接一个向量数据库就完事它是一个完整的管线。5.1 RAG管线拆解每一步都有讲究一个能用的RAG管线至少包含这样几段文档解析PDF、Word、网页、表格每种格式都要转成可检索的文本。表格尤其容易出问题解析成纯文本后就丢失了结构信息检索效果会大幅下降。分块Chunking不是均匀切块那么简单的。理想的分块是语义完整的段落并且要适当包含小标题、上下文锚点。我们做过实验按固定300字切块召回准确率比按章节语义切块低十几个百分点。嵌入Embedding把文本转成向量。这一步的模型选择也很关键通用嵌入模型对你的垂直领域可能效果一般有预算的话在领域语料上微调一下嵌入模型提升很明显。召回Retrieval从向量库里找出Top-K相关片段。这里有一个隐蔽坑——向量检索对短文本、专有名词的召回经常不准所以现在主流做法是“混合检索”向量检索关键词检索重排。重排Rerank召回回来的Top-50用一个轻量模型重新打分挑出Top-5再喂给大模型。重排是性价比极高的一环强烈建议加上。5.2 混合检索向量不是银弹很多人以为向量检索是万能的其实不是。用户问“你们怎么退款”数据库里存的是“售后处理流程”两者语义上相关但关键词完全不同向量能兜住可如果用户问的是产品型号“A-3000”文档里恰好写的是“A3000”没有那个连字符向量检索很可能召回失败关键词检索却能精准命中。所以我在架构里画的检索模块永远是三路并联向量路、关键词路、还有一路规则路比如通过产品型号字典直接查表。三路结果合并后再重排。实测下来综合召回率比单路向量检索高出一截。5.3 缓存与新鲜度知识更新的矛盾RAG系统里知识的源头是你的业务数据库和文档库。这里有一个经典矛盾数据更新得越勤Cache命中率越低Cache太久用户又可能拿到过期信息。我的经验是分两级热门通用知识走缓存命中高、更新频率低涉及具体订单、用户数据等实时信息一律绕过缓存直查。不要试图对所有内容做统一缓存策略按数据新鲜度要求分类处理才是正道。6. Agent化改造让应用从“被动回答”到“主动完成”RAG解决的是“懂业务”Agent要解决的是“能干事儿”。AI应用架构演进到一定阶段你一定会遇到这样的需求用户不只是想知道退货规则还希望系统帮他把退货申请提交了、把退款进度查出来。这时候简单的一问一答就不够了你需要引入Agent机制。6.1 从“说”到“做”工具调用的本质Agent的核心能力是工具调用。模型输出一段结构化的“行动指令”比如{ action: query_refund_status, params: { order_id: 20250115001, customer_level: vip } }系统解析这段指令调用真实的业务接口拿到结果再把这个结果作为新的上下文回传给模型让模型决定下一步。这就是一个“感知-决策-行动-再感知”的循环业界一般叫ReAct模式。这个机制本身不复杂复杂的是两个点一是怎么让模型输出稳定、可解析的结构化指令二是怎么让工具结果的回填不把上下文撑爆。前者靠有效的工具注册表和清晰的函数描述后者靠第4节说的上下文管理。6.2 工具注册表让模型知道“你有什么工具”很多Agent翻车不是因为模型笨而是因为模型根本不知道你有什么工具、工具是干什么的、参数怎么填。所以工具注册表很重要每个工具都要有明确的名称、描述、参数Schema、调用约束。值得注意的小技巧工具描述要写“对人类有用的信息”比如“该工具用于查询近三个月的账单明细适合回答与消费记录相关的问题”而不是只写“查询账单”。描述越具体模型选对工具的概率越高。此外工具数量不是越多越好。我们做过一次测试把工具从20个加到50个模型选错工具的比率几乎翻倍。工具超过10个以后建议做一层工具路由先按意图把候选工具缩小到3-5个再让模型做最终选择。6.3 边界与护栏Agent最大的威胁是“过度自信”Agent给系统带来能动性的同时也带来新的风险。模型自作主张调用了不该调用的接口、模型在不确定参数时瞎猜了一个值、多轮工具调用导致失控——这些都是线上真实会遇到的翻车现场。我总结了三道基本护栏权限最小化Agent能调用的工具、能触达的数据面都必须显式授权。不该碰的接口直接从工具注册表里拿掉。人工确认机制涉及资金操作、数据删除、外发通知等敏感动作必须经过用户确认或业务审批。调用链上限限制Agent单次任务的最多工具调用轮数超过即停止防止模型陷入死循环。Agent不是越自由越好一个“戴着镣铐跳舞”的Agent往往比一个“全自由”的Agent更让人放心。7. 质量与稳定性评测、护栏、可观测性一个都不能少架构搭得再漂亮如果回答质量不稳定用户照样会跑。AI应用和传统应用的另一个大区别是你没法靠“上线前测一遍”来保证质量因为输入空间近乎无限。这时候需要把质量保障做成一套持续性机制。7.1 评测集你的“试金石”和“回归网”没有评测集就去优化Prompt基本等于摸黑开车。评测集不是随手收集几个问题就行我建议至少包含这几类标准问答集覆盖核心业务场景的经典问题每个问题配参考答案和评分标准。边界输入集空输入、超长输入、敏感话题、方言口语、中英混杂等。工具调用集明确需要调用某个工具的请求检验Agent路由和参数提取准确率。困难负例集模型容易答错或乱编的题型防止回归。有了评测集每一次改动都可以离线跑分用数据说话。优秀的标准是核心指标不下降的前提下再去优化体验细节。7.2 输入输出护栏把风险挡在系统之外模型本身自带一定的内容合规能力但远远不够。生产级的AI应用必须有独立的输入输出护栏输入侧鉴权、限流、敏感内容识别、Prompt注入攻击检测。Prompt注入是AI应用特有的安全风险用户可能用“忽略之前所有指令”来试图操纵模型护栏要识别这类模式。输出侧格式校验、敏感信息过滤、幻觉检测。幻觉检测可以简单做“答案与检索内容一致性比对”——如果模型答案里的关键实体不在参考文档里就要标记出来人工复核。7.3 可观测性AI应用比传统系统更需要“黑匣子”传统应用出问题你看日志看链路能很快定位。AI应用出问题你面对的是“一段自然语言回答不太好说是对是错”。所以可观测性要记录的不只是调用日志还要记录Prompt快照这次请求实际发了什么内容给模型包括填充了什么上下文、用了哪条系统指令。模型输出原始数据不要只存最终返回给用户的话还要存模型的原始输出和中间思考步骤。评测打分结果这条回答在离线评测体系里能得多少分、哪一项丢分了。成本明细每次请求消耗了多少Token、多少钱撑爆预算的元凶是谁。排查线上质量问题时这套“黑匣子”能救你无数次。7.4 线上监控别让“回答质量”成为黑盒我习惯用一套阶梯式监控策略监控层级关注指标预警方式系统层请求成功率、时延、并发实时告警模型层Token消耗、供应商错误率、重试率日报异常告警质量层评测集抽样得分、用户反馈负面率周报趋势分析业务层转化率、用户留存、客服转人工率周报质量层的监控需要设计抽样机制每天自动抽取一批线上对话跑一遍评测打分分数下滑就触发复盘。这样你就能把“感觉最近变差了”变成“本周质量分从87降到82原因是什么”从根本上消灭玄学。8. 一张图收尾完整架构蓝图与分阶段落地方案说了一堆我们回到标题里的关键词——“图解”。下面是我心目中一个相对完整、但又不至于过度设计的生产级AI应用架构蓝图。它不一定适合所有人但可以作为你画自己架构图时的起点----------------------------------------------- | 治理层评测 / 护栏 / 追踪 / 成本 | ----------------------------------------------- | 用户 → 接入层(鉴权/限流/合规) → 编排层(意图/任务/路由) → 模型网关 → 大模型服务(多供应商) | | | | | ---------- ------ ---v--- | | 知识/记忆层 | | 工具层 | | 侧路模型 | ----------------→| RAG/向量/缓存|←--------- 业务API |-----------| 嵌入/重排| ------------- ------- -------图要怎么看三层纵向上面是治理层横向贯穿所有环节中间是核心调用链从左到右一次请求的路径下面承接支撑层包括知识、工具、模型服务。注意画图时别把治理层画成“挂在边上的一块”它应该像一张网罩住所有环节。8.1 分阶段落地别一口吃成胖子如果你从零开始搭一个AI应用我的建议是不用一步到位按节奏演进阶段一最小闭环模型Prompt几个手工拼的上下文逻辑先跑通一个核心场景积累真实问题和评测集。这个阶段不要上任何重型组件。阶段二稳定化引入模型网关、加RAG管线、建立基础评测集目的只有一个——让核心场景的回答稳定且可复现。阶段三规模化再加入Agent、工具调用、更精细的记忆管理、可观测性平台开始做成本优化和复杂任务处理。阶段四治理化护栏、合规、灰度发布、持续评测让系统能承受更大规模、更复杂业务的考验。关于演进路线我见过太多团队死在“阶段一就想把架构搭完整”结果拖慢上线节奏、消耗信心。记住架构是为业务服务的不是用来炫技的。先活下来再变强。8.2 小团队的落地次序建议如果你所在的团队不大资源有限最值得优先投入的顺序是模型网关降本高可用→ 评测集防止瞎优化→ 上下文管理提升核心质量→ RAG扩展业务能力→ 护栏守住底线→ 剩下的按需补位。把预算花在这几个方向长期回报都很好。最后再分享一点个人心得做了这么多AI应用架构的梳理和验证我自己最大的感受是不要把“架构设计”想成一个一次性画图的工作它更像是在持续演进中不断画图、推翻、再画的过程。我的工作习惯是每过一个迭代周期就把架构图重新画一遍删掉那些已经不需要的组件、补上新出现的需求点。画图不是为了好看而是为了逼自己想清楚每个模块为什么存在、边界在哪里、依赖谁、如果它挂了会发生什么。如果你正在为自己的AI应用做架构我的建议很朴素先不要沉迷于各种新概念回到那张五层图上看哪一层最薄弱就优先补哪一层。模型会不断进化框架会不断涌现但架构的底层逻辑——管理不确定性、控制成本、保障质量——会长期有效。希望这篇图解能给你提供一个靠谱的思考框架少走一些我们走过的弯路。
