上个月帮一家创业公司做架构评审他们已经把大模型API接得相当顺了聊天、总结、写SQL样样都能跑。可当我请他们在白板上画出整个系统的架构图时会议室安静了十几分钟——交互层、Agent任务分解、上下文记忆、模型网关、评测反馈全混成一团谁也说不清一条用户消息到底经过了哪些模块。这大概是我近一年反复见到的AI应用架构通病模型接得越深系统反而越看不见。所以我想把“AI应用架构设计”这件事摊开来用图解的方式拆成一张张能看懂的骨架图。无论你是在做AI客服、AI编程助手、知识库问答还是准备把Agent推向生产这套分层逻辑基本都适用。这篇文章不是给你讲某个框架的API怎么调而是帮你建立“画得出架构图”的全局视图。1. 先把六层骨架画出来AI应用架构的整体视图1.1 为什么不能用“写单体Web服务”的思路设计AI应用传统后端应用有一个确定的请求-响应模型用户发请求服务端查数据库、算逻辑、返回固定结构。开发者的心智负担在于“把流程写对”。但AI应用完全不是这么回事——模型输出是概率性的同一个问题今天答和明天答可能不一样请求处理过程中还经常要穿插工具调用、知识检索、多轮上下文拼接不同模型的接口参数、能力边界、成本结构也各不相同。如果还沿用单体Web的思路把大模型调用直接写在业务方法里短期看很方便长期看全是债。我见过一个项目OpenAI SDK直接散落在各个service里后来要换供应商、加语义缓存、做成本统计时几乎每个业务模块都要改一遍。单体思维最要命的点在于它把“模型调用”和“应用逻辑”耦合死了而AI应用的迭代恰恰最容易发生在模型层。1.2 六层骨架的分工与依赖关系我习惯把AI应用架构画成六层每层只解决一类问题。整体视图如下┌─────────────────────────────────────────────────────┐ │ 用户触点层 Web / 桌面端 / 移动端 / API / 协作工具 │ └─────────────────────────────────────────────────────┘ │ ┌─────────────────────────────────────────────────────┐ │ 接入与治理层 鉴权 / 限流 / 会话保持 / 审计日志 │ └─────────────────────────────────────────────────────┘ │ ┌─────────────────────────────────────────────────────┐ │ 编排与控制层 意图识别 / 任务规划 / 工具调度 / 状态 │ └─────────────────────────────────────────────────────┘ │ ┌─────────────────────────────────────────────────────┐ │ 模型服务层 模型路由 / 供应商封装 / 流式 / 降级 │ └─────────────────────────────────────────────────────┘ │ ┌─────────────────────────────────────────────────────┐ │ 记忆与知识层 上下文管理 / 向量知识库 / 长短记忆 │ └─────────────────────────────────────────────────────┘ │ ┌─────────────────────────────────────────────────────┐ │ 支撑体系 可观测性 / 评测反馈 / 安全治理 / 成本 │ └─────────────────────────────────────────────────────┘这张图的核心思想是用户触点层、接入治理层解决“谁来用、怎么进”的问题编排控制层解决“AI要干什么、怎么干”的问题模型服务层解决“调用谁、怎么调”的问题记忆与知识层解决“模型凭什么知道这些”的问题支撑体系则贯穿全局保证系统可运维、可评估、可控制。用表格把各层职责和常见误区整理一下层级核心职责关键组件最常见误区用户触点层多端交互体验Web端、移动端、API、语音助手只在单一入口做忽略API与端之间的一致性接入治理层鉴权、限流、会话、审计网关、Redis、会话存储把session丢在应用进程内存里编排控制层意图识别、任务分解、工具调度Agent状态机、工具注册表把所有逻辑写成prompt里的“请按步骤做”模型服务层多模型封装、路由、流式模型网关、适配器业务代码直连供应商SDK记忆知识层上下文、检索、知识注入Redis、向量库、RAG链路不压缩上下文、不过滤检索结果支撑体系观测、评估、安全、成本Trace、评测集、审计等到线上出问题才补1.3 这张架构图在不同团队规模下怎么裁剪我不是让你一上来就照着六层全铺。三人小团队做MVP三层可能就够用户端直接连模型网关编排逻辑用提示词和简单函数调用凑合记忆暂时不做全面RAG。但有一个前提——你必须在代码里画清楚层与层之间的边界。比如模型网关这一层哪怕只有一个函数也要独立成模块因为后面的路由、缓存、降级都要在这里长出来。我做过一个客服问答机器人最开始就是单体里的一百多行代码后来用户量上来开始需要会话记忆又需要接入企业知识库再后来要限制不同用户可触达的工具权限最后硬生生从一团代码里“长出”了完整的六层结构。裁剪原则很简单先有边界再决定每层做多厚。边界不清后面每一次加需求都是在偿还前期欠下的架构债。2. 接入层SSE、会话状态与多端协议跨不过去就谈不上体验2.1 流式响应的架构影响不做SSE的AI应用是半成品大模型推理需要时间即使是最快的模型完整生成一段回答往往也要数秒。如果应用像传统接口一样等待完整结果返回用户的体验就是“转圈十秒突然冒出一大段文字”——这在交互上几乎是灾难。为什么SSEServer-Sent Events成了AI应用事实上的标配因为服务端可以一边推理一边把token推给前端用户几百毫秒内就能看到第一个字后续文字逐字出现感知延迟被大幅降低。但SSE在架构上坑不少。我踩过最实际的一个反向代理默认会缓冲响应nginx如果不把proxy_buffering off关掉SSE的流会被攒在代理层前端依旧要等全部收完才看到内容。另外网关的连接超时时间要按“模型最坏耗时”来设而不是按传统接口的几秒钟来设否则长回答生成到一半会被网关切断。流式模式还有一个容易被忽视的点架构链路里的所有中间件都必须支持“边收边转”不能让某一段把整个流缓冲完了再往下传。2.2 会话状态该放在哪无状态服务与外部会话存储AI应用大多是强会话场景用户会连续追问后一问依赖前一问的上下文。但如果你的业务服务是有状态部署——把会话数据存在进程内存里——一旦服务重启或者多实例扩容用户要么会话丢失要么请求被路由到另一台机器上导致上下文对不上。这个问题在传统Web里可能只是“登录态丢了”在AI应用里就是“AI失忆了”体验伤害更大。我建议业务服务保持无状态把所有会话状态外置。具体来说前端在发起请求时带上会话ID后端网关从Redis里读出该会话的历史消息索引模型服务再按需拼装上下文完整的消息记录落到数据库用于审计和长期记忆。会话存储的关键不只是“存下来”而是消息必须按时间稳定排序且能支持跨设备恢复。这样无论请求打到哪个副本AI都能记得住上下文。2.3 多端接入的统一协议设计AI能力很少只在一个入口使用。网页聊天、App、小程序、开放API、甚至内部办公系统都会来对接同一个Agent。如果每一端都独立实现一遍编排逻辑维护成本会飞快膨胀。更合理的方式是把AI能力收敛成一个内部标准协议所有端都通过同一个网关走同一条链路。实际操作中有一种很优雅的做法把Agent能力封装成OpenAI兼容的HTTP接口。内部系统想用AI时把它当成一个“外部模型”来调用就行消息结构、流式格式、工具声明都用同一套规范。这个设计让AI能力从“业务项目内部的私有代码”升级成了企业内部的公共服务谁接入都只需要写一层很薄的客户端代码。我突然觉得很多团队做AI应用做不好不是模型选得不对而是从一开始就没有把这套接入层当成架构设计的一部分。3. 编排层从“调模型”到“Agent干活”应用逻辑真正发生的地方3.1 意图识别与任务分解把用户一句话变成执行计划传统聊天机器人拿到用户输入后通常是“理解意图-给回复”两步完事。但到了Agent时代用户的一句话往往需要多个步骤才能完成。举一个很常见的例子“帮我分析这份销售数据并生成周报。”这句话背后至少包含读取数据、清洗数据、统计分析、生成图表、拼装周报五个子任务。架构上要做的就是把“让模型一口气输出答案”改成“让模型先输出计划再由程序按计划执行”。计划结构可以设计成一组带依赖关系的任务每个任务有ID、工具名、输入参数、输出结果、执行状态。执行层用一个状态机去驱动任务就绪了就去执行执行完把结果写回共享状态再激活下一个依赖任务。任务失败时要有重试和回滚策略不能因为中间一步失败就让整个会话卡死。这一步是很多Agent Demo与生产系统差距最大的地方——Demo让模型自己按顺序乱调生产系统必须有确定性的执行框架。3.2 工具调用Function Calling的正确打开方式模型本身不执行任何操作它只能决定“我要调什么工具、传什么参数”。真正干活的是程序侧的工具函数。所以工具调用层是整个编排层的核心基础设施。它的关键点不是“让模型能调用工具”而是“让工具调用可控”。我总结出几个实操要点第一工具的描述和参数Schema必须写清楚描述含糊会导致模型传错参数第二程序侧必须做参数校验和白名单校验不能信任模型输出的任何字段第三工具执行结果如果太大不要整段塞回上下文先让模型读摘要或结构化提炼第四工具异常时要返回结构化错误信息让模型知道发生了什么这样它才有机会自行修正。有一段时间我在项目里把所有工具调用都赶进一个invoke_tool的统一入口日志、鉴权、限流、审计全部收口在这一处。之后工具数量从十几个涨到六七十个编排逻辑几乎没怎么改。工具调用最怕散落在各处一旦散落安全边界和观测口径就全没了。3.3 多Agent协作的通信、分工与仲裁单个Agent处理简单任务足够了但复杂任务经常在长链路中“迷失目标”——计划做得很好执行到一半就忘了最初的目标。现在多Agent协作成了主流解法比如Planner负责拆解任务Worker负责执行具体步骤Reviewer负责检查结果。多Agent的架构设计很容易被做成“让Agent互相发消息”这是最糟糕的模型——消息满天飞状态无人管最后谁也不知道现在进行到哪一步了。更可靠的模式是共享任务状态存储所有Agent不直接通信而是读写同一份任务表通过事件通知比如Redis Stream感知状态变化。每有一个任务完成状态机推进相关Agent被唤醒继续下一步。还要设计超时仲裁机制某个Worker卡住超过阈值要有重试或降级路径。对于重要结果我习惯加一个Reviewer角色用另一个模型做交叉验证比如让一个“代码Review Agent”检查另一个Agent生成的SQL准确率提升非常明显。4. 模型网关当调用模型变成一种需要治理的基础设施4.1 多模型供应商的下沉封装生产环境里你会同时面临模型服务频控、供应商故障、新模型发布、价格调整甚至合规要求变化。如果每个业务模块都直连某个供应商的SDK每一次切换和配置变更都会变成全局风险。所以无论项目多小我都建议把模型调用下沉到一个网关层。这个网关的核心工作是统一输入输出格式。上游业务只按标准消息结构传入对话内容网关负责适配OpenAI、Anthropic、国产大模型、自部署开源模型等不同协议。每个供应商对应一个适配器模块新增供应商只是增加一个适配器的事。维护这种网关时我会特别注意“接口语义的抽象程度”别把各家SDK的私有特性暴露给上层但也不要为了统一而砍掉流式、工具调用这些AI应用刚需能力。4.2 模型路由与分级不是所有请求都值得用最强模型我测过多个业务场景发现真实流量里有六到七成的请求属于“简单任务”文本分类、实体抽取、摘要、格式转换。这类任务用最强的旗舰模型性价比极低延迟高、成本高回答质量其实和轻量模型差别不大。模型网关里加一个路由层就可以把请求分门别类送进不同的模型。实现方式很直接接一个轻量的意图或复杂度分类器对每个请求打标然后决定它走fast轻量模型、standard中型模型还是power最强模型。比如日常闲聊和简单问答走轻量模型复杂推理才走旗舰模型。网关层还要在日志里记录模型路由标记不然你没法按月复盘成本优化效果。很多团队降成本只盯着提示词压缩忽略了最开始的模型分级其实分级往往是最先见效、改动最小的杠杆。4.3 超时、重试、降级与流式直传模型供应商不稳定是常态不是异常。所以模型网关必须把“故障处理”当成一等公民来设计。非流式请求的超时一般设30秒左右流式请求要看首字延迟一般设5到10秒总时长按业务场景放宽。遇到429或5xx按指数退避重试重试次数要有上限防止雪崩。连续失败达到阈值时要触发熔断快速失败而不是让所有请求都阻塞在模型调用上。降级策略也很重要主模型供应商出问题时可以一键切到备用供应商或备用模型业务侧无感知。流式场景还有一个特别容易被忽略的细节——网关必须做“流式直传”收到上游的SSE流要边收边转发给前端而不是攒完整段再吐给客户端。一旦网关缓冲首字延迟就会层层累加用户感知会从“流畅打字”变成“卡顿输出”。我自己见过不止一个项目把这块忽略最后换来的就是用户大量流失。5. 记忆与知识层决定AI“记不记得住、答得准不准”的存储设计5.1 上下文窗口管理为什么你的AI越聊越“笨”很多用户抱怨AI“越聊越笨”研发排查半天模型没问题问题往往出在上下文窗口被塞爆了。模型注意力是有限的上下文拉得太长早期信息会被稀释最新指令也会被一堆无关历史干扰。更现实的是Token成本会线性上涨——你让模型每次多读一千字历史成本就跟着涨一千字。合理做法是做上下文预算管理。我一般会按“最近N轮完整消息 更早内容的摘要 关键结构化事实”来组上下文。比固定窗口更有效的是摘要压缩每当对话超过一定轮数就调用模型把前面的对话内容总结成一段摘要替换原始历史。同时把用户姓名、偏好、关键业务约束这类信息抽成结构化字段每次都注入而不是让模型在历史里自己找。5.2 RAG检索增强的工程化设计嵌入、召回、重排、拼装RAG已经是知识库问答、企业私域问答的标准做法但“加个向量库”远不是全部。一个完整的RAG链路包括文档切分、文本嵌入、向量入库、候选召回、重排序、提示词拼装六步。每一步都会影响最终回答质量。几个实操经验文档切分要按语义块切不能只按字符数硬切否则一个完整知识点会被切断embedding模型要匹配你的语料场景中文、代码、多语言要选对应擅长的模型召回阶段先取一个较大的候选集比如50条再用rerank模型精排到5条以内精确率会有质的提升最终注入提示词的知识片段要标注来源降低模型幻觉风险。RAG项目上线前一定要先建一批带标准答案的知识问答集跑一遍硬指标——召回率、准确率、无答案率。不然你改了切分参数都不知道是变好了还是变坏了。5.3 短记忆、长记忆与外部记忆的分层存储对话记忆不该一把梭。我习惯把记忆分成三层短期记忆存放在当前会话上下文里用Redis存一个会话窗口的消息索引长期记忆是跨会话的用户画像比如姓名、偏好、历史诉求存在用户档案库里外部记忆是业务数据和知识文档放在SQL、对象存储、向量库里。三层之间不是互相替代而是按场景选择性地读取。新会话开始时先从长期记忆拉取用户画像做初始化注入再根据当前问题从外部记忆检索知识片段。不要试图把所有历史都塞进上下文——那既贵又噪声巨大。记忆层设计最容易犯的错就是“贪多”什么都想记住结果模型被无关信息淹没。架构上给记忆加一层“读取策略”根据当前用户意图决定要注入哪部分记忆是记忆层设计的核心。6. 质量与安全体系生产环境里最容易被砍掉却又最不该砍的两块6.1 LLM可观测性从传统日志到Span级别的推理轨迹传统日志记录的是“谁在什么时间调了哪个接口”。AI应用需要更完整的推理轨迹用户原话是什么、编排层做了哪些决策、调用了哪个工具、工具返回什么、最终喂给模型的完整上下文是什么、模型输出是什么、消耗了多少Token、耗时多久。没有这条链路线上用户说“回答不对”时你根本没法判断是哪一环出了问题——是检索没召回是工具返回错了是模型理解偏了我习惯采用Span/Trace模型来记录这些信息遵循OpenTelemetry的GenAI语义约定把一次用户请求从入口到模型到工具到出口串成一条完整链路。出现问题时可以通过Trace快速定位到“检索错误、工具错误、模型错误”三种根因中的哪一种。这里提一个实操经验全量Trace的成本和存储都很高生产环境可以做采样比如默认采样10%、异常链路全量采样。6.2 评估闭环离线评测集与线上反馈如何配合如果上线靠几个人肉测几个case后面改模型、调提示词、换检索策略你根本不敢动——因为你不知道改动到底是变好了还是变坏了。我的做法是搭一个轻量的评估闭环先建一个离线评测集覆盖常见的用户问题每个问题标注期望的答案要点再加自动判分规则。每次改提示词、换模型、调RAG参数都在评测集上跑一遍看整体分值是升还是降。线上同时加反馈入口用户点“有帮助/没帮助”之后数据回流到评测集让测试集跟着真实需求一起演化。灰度发布时新模型版本先服务5%到10%流量对比延迟、成本、反馈得分稳定后再全量。这套流程在一个知识问答项目里把准确率从74%拉到了90%以上。6.3 三道安全闸门输入脱敏、输出过滤、权限收敛AI应用的安全不能只靠“关键词审核”这种粗粒度手段因为风险不只是违规内容还包括隐私泄露、提示注入、越权操作。我会在架构里设三道闸门输入侧、输出侧、权限侧。输入侧对用户的原始输入做审计和脱敏手机号、身份证号这类PII在进入模型前就要处理掉避免隐私数据流进模型上下文同时要识别和阻断明显的提示注入攻击防止用户通过对话套出系统提示词或绕过权限。输出侧按业务规则做敏感信息过滤和格式校验比如让模型输出JSON时必须校验合法性不合法就走修正逻辑。权限侧是很多人忽略的模型能触达的工具必须收敛到最小权限用户身份要透传到工具调用层绝不能让Agent越权读取不属于当前用户的数据。这三道闸门在架构图里是贯穿层嵌入网关、编排层、工具调用入口三个位置。7. 部署与成本治理从Demo到生产要跨过哪些坎7.1 托管API、自部署与混合部署的选型逻辑AI应用部署选型没有标准答案只有适合当前阶段的答案。托管API的优势是上手快、稳定性好、省运维适合快速验证缺点是高频调用下成本攀升快数据要出域某些行业过不了合规审计。自部署用vLLM这类推理引擎跑开源模型前期硬件和运维成本高但单Token成本随规模下降明显数据完全可控。混合部署是我见过最多生产系统的最终形态简单任务走本地轻量模型复杂推理走外部大模型API敏感数据链路完全留在私有环境。选型判断主要看四个因素调用量、数据敏感级别、合规要求、团队运维能力。一个实际项目里我们把高频简单任务迁移到本地小模型、低频复杂任务保留外部大模型月度API成本降了40%以上延迟也改善了。7.2 成本治理的四个杠杆缓存、分级、压缩与批处理AI应用的成本大头就是Token控制Token就是控制成本。我常用四个杠杆叠加使用效果很好。第一是语义缓存相同或近似的问题直接命中缓存不重复调用模型这是见效最快的第二是模型分级简单请求走轻量模型复杂请求才走旗舰模型第三是上下文压缩进入模型前把历史消息摘要化减少每次调用的Token数第四是批处理异步场景下把多个短任务合并成一次模型调用比如一批电商评论一起做情感分类。落地时可以先把前两个做掉成本立刻能看到变化。但前提是模型网关里要记录模型名、Token数、成本估算、缓存命中标记没有这些监控字段成本优化就是一笔糊涂账。我见过一个团队拿着账单说“成本高”但完全说不清钱花在哪类请求上最后建了这套标记之后才发现80%的支出来自一批已经重复了无数次的相似问题。7.3 一条可落地的渐进式架构演进路径最后给一条我反复验证过的实施路径避免一上来就照搬大厂架构。第一步先跑通核心链路客户端直连模型API但提示词模板和业务逻辑要分开存第二步加入模型网关把供应商调用全部收口这一步之后切换模型、加缓存都不会动业务代码第三步把会话状态外置到Redis和数据库支持多实例扩容与多端接入第四步出现“多步骤任务”需求时再引入编排层用状态机管理任务执行第五步补上评测集和Trace让质量数据跑起来第六步做成本治理加语义缓存和模型分级。每一步都有一个明确的触发条件没有多步骤需求就不要过早引入Agent框架调用量没有超过一台机器的承载就不要急着微服务化。架构演进应该跟着业务复杂度走而不是跟着概念热度走。有人问过我AI应用架构设计和传统后端架构最大的区别到底在哪。我的体会是传统后端是在一个约束相对确定的世界里做编排而AI应用是在一个概率性的世界里做编排。所以架构设计的首要目标不是追求一次画到位的“完美方案”而是围绕“不确定性”留出观测、回退、演进的余地。我踩过的最深的坑就是早期没有给模型层和编排层划边界结果每次想换模型、调策略都要把整个应用翻个底朝天。希望这份图解版的拆解能帮你把AI应用的第一根骨架搭得正一点。
