很多人找我咨询的时候手里已经有一个跑得不错的 AI Demo 了。Prompt 写得很溜模型也调得很熟能单轮对话也能接点工具但一聊到“你打算怎么把它做成一个真正能上生产、能多人协作、能持续迭代的系统”对方往往就卡壳了。这不是能力问题而是视角问题——做 Demo 的时候你只需要让模型在当前这台机器上跑通做产品的时候你要让整个系统在任何一次输入、任何一种负载、任何一个陌生运维手里都尽量不出错。围绕“AI 应用架构设计”这件事我这些年画过几十张架构图也亲手拆过不少 AI 项目的骨架。这篇文章想用“图解”的思路把 AI 应用从需求到上线过程中最关键的几个结构性问题拆开讲清楚模型层怎么选、服务层怎么围、Agent 怎么编、数据怎么管、部署怎么定。不管你是刚接触大模型开发的工程师还是已经在做 RAG、Agent 项目的技术负责人这套图谱应该都能帮你把散落的知识点串成一张可落地的地图。1. AI 应用架构到底是什么图解到底解什么1.1 从“调接口”到“做架构”的转变我现在把 AI 应用拆成五个层级来看接入层、编排层、模型层、数据层、运维层。没有哪个架构是唯一正确答案但这五层足够覆盖绝大多数的 AI 应用场景。接入层负责解决“用户怎么进来”的问题。Web 界面、移动端、IM 机器人、内部系统 API都可能成为入口。很多初阶设计只把它当成一个普通的 Web 层其实在 AI 应用里接入层的差异化在于交互形态既有用户主动输入又有系统回调、流式推送、长任务状态查询。这个层不复杂但它决定了上下游的协议边界。编排层是 AI 应用相对传统系统最不同的地方。一个复杂任务往往不是一次模型调用能完成的它需要规划、拆解、调用工具、拼接结果、自我校验。这一层就是通常说的 Agent 逻辑所在。我见过很多项目把 Agent 逻辑全部堆在函数里几千行代码塞一个 service初期跑得欢后面改一个 prompt 都要提心吊胆。架构设计要解决的就是把“思考”和“执行”拆开让编排可以被可视化可以被测试。模型层负责承载大模型本身模型选择、推理部署、上下文窗口、微调策略、提示词模板。数据层负责管理应用运行所需的语料、向量索引、对话历史、用户画像和业务数据库。运维层则涵盖监控、日志、成本、安全、限流和告警。这五个层次之间用明确的 API 或消息通道连接每一层都有清晰的边界这样出问题的时候你能快速判断是模型抽风了还是编排逻辑出 bug 了。1.2 一张好图的三个标准我判断一张 AI 应用架构图有没有价值主要看三个标准。第一边界是否清楚。每个方框代表什么、归属哪个团队、数据从哪进从哪出看图的人能一眼对应到代码模块。如果一张图里只有“前端”“后端”“模型”三个大方块那它只适合给老板汇报用不适合做设计交付。第二数据流是否被标出来。一个请求从命中 prompt到检索向量库到调用模型到写入数据库再到返回流式结果中间每一跳都是潜在宕机点。架构图里没有数据流就谈不上排查问题。第三部署边界是否可见。同一个组件放在客户端、内网服务端、第三方云服务成本和安全属性完全不同。架构图里应该体现这些边界最好还能标注出哪些环节依赖外部供应商哪些环节可以私有化。画图的目的不是把图做得好看而是逼自己把系统里所有的关系说清楚。我经常在画图的过程中发现某个模块职责不明或者某个调用方向画反了这些问题如果等代码上线后再发现成本就完全不是一个量级了。2. 模型层与服务层地基怎么打2.1 模型选型与基础理论模型层是整个架构中和“大模型基础理论”最接近的一环。很多人一上来就问“用哪个模型好”其实这个问题应该拆成三个模型的能力边界能不能覆盖任务复杂度模型的上下文窗口能不能覆盖业务数据长度模型的单位成本能不能覆盖业务毛利。我习惯把任务分成三类对话理解类、工具调用类、长文档推理类。对话理解类对模型的基础能力要求不高小模型就够了工具调用类要求模型能严格输出结构化指令更看重函数调用能力长文档推理类则对上下文长度和注意力机制有硬性要求。你要知道开源模型和闭源模型各自的优势在哪闭源 API 胜在开箱即用能力稳定开源模型胜在数据可控、可私有化、可微调适合数据敏感的行业。这些其实都属于基础理论在工程上的延伸。我建议团队里至少有一个成员能把注意力机制、上下文窗口、温度采样这些概念讲清楚否则后面做提示词优化的时候就只能靠玄学。2.2 服务层网关、鉴权与限流服务层我通常建议做三层保护。最外层是 API 网关负责路由、鉴权、SSL 终止中间层是业务服务负责组装 prompt、调用模型、解析结果内层是模型代理负责对接不同的模型供应商或者私有化推理服务。鉴权的设计要区分“用户身份”和“模型配额”。同一个企业客户下的不同部门可能共享一个模型账户你需要在前端做用户鉴权在模型代理层做二次配额校验避免单个调用方把整个团队的模型额度打爆。限流要按模型供应商、用户、业务接口三个维度同时做。我见过一个真实事故某个内部工具接了大模型 API没有做限流测试阶段跑了一个双层循环的自动化脚本直接把月度预算烧掉了大半。所以服务层绝不能只做接口限流还要在模型代理层做每分钟请求数、Token 消耗速率的双重限制。此外服务层要处理好流式与非流式的统一。前端需要打字机效果时后端要走流式接口内部需要批处理时又要走普通接口。我的做法是用一个统一的模型调用抽象接口内部根据场景切换流式和非流式实现上层业务完全不感知。2.3 编排层Agent 与多 AI 协作编排层是 AI 应用架构设计里最有意思的部分。单个模型调用解决不了的问题就要交给 Agent。Agent 的核心能力可以拆成四块规划把目标拆成步骤、记忆记住之前的上下文、工具调用选择并执行外部动作、反思检查结果是否合理。我用一个最简单的套路来设计 Agent状态机 工具注册表。状态机负责控制任务流转工具注册表负责维护模型可以调用的所有能力。Agent 每一步做完把结果刷新到状态机里同时把关键信息写回上下文。这种方式的好处是每一步都可观测、可回滚。多 AI 协作是最近大家都在探索的方向我的看法是分工比堆数量重要。大模型负责全局规划和最终生成小模型负责特定子任务比如分类、抽取、打分多个模型之间最好通过消息队列或事件总线解耦千万不要把所有模型的调用都串在一个同步链路里否则一个模型抖动整个流程就全部卡死。提醒一点Agent 不是越复杂越好。很多业务场景用一次模型调用加一次检索就能解决硬拆成多轮规划反而是把简单问题复杂化还增加了延迟和成本。架构设计要服务于业务而不是服务于概念。3. 数据与记忆AI 应用的差异化护城河3.1 RAG 的工程化流程RAG检索增强生成已经是 AI 应用架构里的标配了。但 RAG 的难点其实不在检索本身而在数据链路。数据链路分采集、清洗、切分、向量化、索引更新。采集要处理 PDF、Word、Markdown、数据库等多种来源清洗要做格式归一化、去重、敏感信息过滤切分要按语义段落而不是按固定长度硬切否则检索出来的片段会断章取义。向量化要选 embedding 模型注意和主模型的上下文策略匹配。索引更新要兼顾实时增量与定期全量不能每次更新都全量重建。这里我给一个切分经验切片大小要结合下游模型的上下文窗口来定。如果主模型上下文是 8K你一个切片放 3000 token检索三个片段就满了后面还要拼接用户问题和历史根本没有空间。切得太大浪费上下文切得太小信息不完整我一般会先跑一轮测试集看切片的命中率和答案完整性再确定最终参数。3.2 短期记忆与长期记忆对话类 AI 应用绕不开记忆管理。短期记忆指当前对话窗口里的上下文直接决定模型对用户意图的理解质量。短期记忆的关键是“怎么塞不爆”滑动窗口截断、关键信息摘要、指代消解。我常做的是三级管理最近三轮对话原文超过三轮的做摘要摘要再超长就全量压缩成向量存起来。长期记忆则是指跨会话的用户偏好、历史事实、业务知识。长期记忆通常落在向量数据库和业务数据库里。要考虑的点包括记忆什么时候写入、什么时候更新、什么时候过期以及写入时要不要对敏感信息做脱敏。架构上的建议是把记忆读写做成独立服务应用层通过 MemoryClient 统一访问。这样无论是换向量库还是调整摘要策略都不会影响上层业务逻辑。3.3 向量库选型与召回质量向量库选型直接决定 RAG 的上限。市面上的方案大致分三类独立向量数据库、带向量插件的传统数据库、云厂商的向量检索服务。独立向量库性能好但引入了一个新的存储组件需要额外的运维成本传统数据库的向量插件胜在架构统一适合数据量不大、不想多维护一套系统的团队云厂商的服务则适合不想自己处理扩缩容的场景。召回质量不能只看 top-k 的准确率。我在实际项目里更关注三个指标召回内容的平均相关性、检索片段的去重率、以及答案对检索内容的利用率。经常出现的情况是检索结果相关但字面相似度很低导致大模型没有引用到关键信息。解决办法是采用混合检索向量相似度加关键词匹配加权同时尝试用重排序模型对候选集做二次精排每次检索召回 20 个候选再重排取前 5 个。代价是多了一次重排调用但答案质量的提升往往非常明显。4. 模型部署与推理优化4.1 云 API 与私有化部署的取舍模型部署是“AI 应用架构设计”里最需要算经济账的部分。选云端 API 还是私有化部署要考虑数据合规、成本模型、推理延迟和团队运维能力。我做了一张对比表对比维度云端 API私有化部署首期成本低按量付费高要买 GPU 服务器数据合规数据经过第三方数据不出内网运维成本低供应商负责高需要自己管推理引擎能力迭代快版本自动更新慢升级和微调都要自己做推理延迟取决于网络距离可控内网调用延迟低适合阶段验证期、调用量不确定稳定期、调用量大、数据敏感我自己的判断标准很简单如果业务数据敏感度高或者调用量大到能摊平硬件成本就私有化如果还在验证阶段、调用量不确定就用云端 API。很多团队一上来就买 GPU 卡跑开源模型结果业务跑不起来机器闲置成本压力直接变成了团队压力。私有化部署也不等于买一张显卡就完事。你要处理推理框架选型、显存分配、量化精度、并发控制、模型版本加载。这里我推荐先想清楚三个参数显存需求、吞吐要求、延迟上限然后再决定是用 vLLM、TGI还是直接用大厂推理平台。4.2 推理成本与缓存策略大模型推理成本是 AI 应用能跑多久的关键。我常用的手段有三个。一是结果缓存。对相同或相似的请求直接把结果返回。缓存键不能只按用户输入哈希要加上系统提示词版本和模型版本否则提示词一改缓存全部失效。二是模型分级。简单问题走小模型复杂问题走大模型用路由模型判断复杂度。这个策略能省下大量成本但也容易引入判断不准的问题所以要给路由模型设置阈值和 fallback 逻辑判断结果低于置信度时直接走大模型。三是请求合并和批处理。把多个短请求合并成一个批次发送能显著提升吞吐、降低单位成本。类似推荐系统里的排序服务非实时的请求尽量攒批。另外流式响应能减少用户等待感但会占用更多连接资源架构上要注意超时和连接池设计。很多团队上线后遇到的“卡顿”其实不是模型慢了是网关的连接数被打满了。5. 从设计到落地一个客服助手实例5.1 需求拆解与技术选型实际动手前我会先从需求拆技术。这里举一个 AI 客服助手的例子用户通过 Web 或微信渠道咨询系统需要结合企业知识库回答问答解决不了的转人工所有对话记录需要落库。技术选型就清晰了上游接 WebSocket 和 HTTP 回调编排层用 Agent 状态机内置意图识别、知识检索、人工转接三个节点模型层用云端大模型 私有化小模型组合意图识别走小模型答案生成走大模型数据层用 Postgres 存业务数据用向量库存知识库切片再用 Redis 做会话缓存。5.2 核心流程与关键配置我把核心流程画成下面这个样子用户消息进来后Agent 先把消息丢给意图识别小模型得到意图标签如果是产品咨询就带着用户问题去向量库检索检索回来的 top-k 片段和用户问题一起组装成最终的 prompt大模型生成答案后流式返回给前端同时异步任务把对话写入历史表。这里有一个最重要的配置prompt 模板。我把 prompt 拆成四个部分系统角色、参考材料、用户问题、输出约束。参考材料一栏就是 RAG 检索结果这一栏尤其要强调“如果没有相关内容请明确告知用户不要编造”。伪代码大概是这样的async def handle_message(user_id, message): session memory_client.get_session(user_id) intent intent_model.classify(message) handler registry.get(intent) if handler is None: return await fallback_human(session, message) handler.load_context(session) result await handler.run(message) session.append(result) memory_client.save(session) await audit_log.write(user_id, message, result) return result你可以看到这个流程里每一步都绑定到架构图里的一个模块排查问题的时候只需要沿着数据流一路看过去。5.3 可观测性与测试AI 应用的可观测性比传统应用复杂因为多了一个不可控的模型变量。我要求每个模型调用都要记录模型版本、提示词内容、温度、最大 token 数、输入输出 token 数、延迟、耗时分布、最终结果。只记录结果不记录提示词等于没有日志。测试方面我建议建立三层测试单元测试覆盖工具函数和解析器回归测试用固定的评测集跑模型输出线上测试用灰度流量对比新旧版本。模型输出的评测不能只看覆盖率要人工抽查和自动化评分结合评分维度包括准确率、完整度、格式合规性。这里尤其要说AI 应用的测试集建设越早越好。项目启动的第一周就应该把典型问题、边界问题、陷阱问题整理成 50 条以上的测试用例。后面改提示词、换模型、调整 RAG 参数好不好、有没有退化跑一遍就知道而不是靠“感觉变好了”。6. 常见问题与排查技巧6.1 请求超时与重试模型接口超时是排在第一位的日常问题。很多团队直接在调用模型处加了三倍重试结果模型供应商因为负载均衡把请求全都分发到了边缘节点反而拖垮了系统。正确做法是设置短超时、少量重试、重试时退避、增加熔断。我通常把首超时设成 5 秒重试最多一次间隔 1 秒连续失败五次就熔断 30 秒。如果模型供应商频繁超时还要结合业务场景降级。比如客服助手模型出问题时可以自动降级为“只检索不生成”把知识库里的相关片段直接推给用户并提示“当前智能回复暂时不可用”。这个降级方案比反复重试要体面得多用户基本无感。6.2 上下文错乱问题上下文错乱很常见症状是模型回复突然张冠李戴。原因往往是多轮对话里把不同用户的上下文串了或者摘要压缩丢失了关键信息。排查步骤很简单先把日志里的上下文 dump 下来用输入比对看是切错、摘错还是写库写错。我见过一次排查最后发现是 Redis 的 key 用了没有加用户标识的会话 ID两个用户共享了一串上下文排查了两天才定位。所以架构设计里要强制性约定所有记忆相关 key 必须带 user_id 和 session_id 双层命名空间这个约定要写进团队规范并且 code review 的时候重点关注。6.3 Agent 死循环与容错Agent 死循环多出现在工具调用类任务中Agent 反复调用同一个工具参数一模一样就是不退出。我的解法有两个一是设置最大迭代次数默认 5 次二是检测到连续两次调用相同工具且结果未变化时强制切换策略或转人工。还要给 Agent 加兜底输出当模型返回的格式不符合预期时重试一次并调整 prompt 强调输出格式再失败就给出固定错误模板不要任由模型自由发挥。症状排查方向处置建议模型返回空内容检查输入是否为空、prompt 是否被截断增加非空校验和默认回复输出格式总是跑偏看 system prompt 格式约束是否被用户输入覆盖把格式约束放在用户输入之后、使用结构化输出工具调用参数错乱检查工具注册表 JSON Schema 是否正确用 JSON Schema 校验工具参数失败则报明确错误请求频繁 429看限流分配是否合理设置配额告警接近阈值时降低并发注意当用户输入和系统 prompt 冲突时绝大多数模型会顺从用户输入。所以架构层面要把安全边界和系统提示词都放在下游再组装一次而不是无脑拼接用户输入。写在最后让架构图跟着线上事故一起生长我自己画图和解 Bug 这么多年最大的体会是AI 应用架构设计不是一次性画出来的而是被线上事故、成本账单和用户投诉一步步逼出来的。一个架构先能用再稳定然后才谈得上优雅。别追求一开始就上最复杂的编排框架先把你现在的调用流画在纸上标出每一跳的失败风险补上你能控制的保护措施再让这个图跟着真实负载慢慢生长。最后分享一个我常用的方法论每次架构评审都让负责的同事把架构图讲给一个不熟悉项目的后端听如果讲不清楚说明边界和职责还没理清如果听的人能顺着数据流说出“哪一步做错了会发生什么”这张图才算及格。好的架构图不是给老板看的而是给下一个加班的同学看的。