1. 为什么现在要聊 AI Native 架构过去两年我参与过三个从零起步的系统项目最大的感受就是AI Native 架构这个词被说烂了但真正落地的时候大部分团队还是在做“传统系统 调个 API”的缝合怪。什么叫缝合怪就是业务逻辑还是老一套的 CRUD数据库还是那张大宽表只不过在某个环节塞了一个大模型调用然后对外宣称自己是 AI 原生。这种做法的结果通常是上线第一周效果惊艳第二周开始成本失控第三个月维护的人想跑路。我理解的 AI Native 架构核心不是“用了 AI”而是系统的第一性设计假设变了。传统系统假设输入是确定的、逻辑是穷举的、输出是可预测的AI Native 系统假设输入是模糊的、逻辑是概率的、输出是需要评估和兜底的。这个假设一变整个架构的骨架就得跟着变——数据层要能存向量和上下文服务层要能编排多模型和多 Agent交互层要能处理流式和非确定性返回运维层要能观测 Token 消耗和推理延迟。这篇文章适合三类人看一是正在做技术选型、准备从零搭一套 AI 应用的架构师二是手里有传统系统、想逐步改造成 AI Native 的研发负责人三是对 Agent、RAG、多模型编排这些概念有耳闻但没动手搭过的工程师。我会把我在实际项目里踩过的坑、做过的取舍、算过的账都摊开讲尽量让你看完能直接抄作业而不是又看了一篇概念科普。2. 整体架构设计与核心思路拆解2.1 从“功能驱动”到“意图驱动”的思维切换传统架构设计的起点是功能清单用户要下单那就设计订单表、写下单接口、做库存扣减。AI Native 架构的起点是意图用户说“帮我看看最近有什么值得买的”这句话背后可能涉及偏好理解、商品检索、比价、推荐排序、自然语言生成。你没法用一张表把“值得买”存下来因为它是动态的、因人而异的。所以我在设计时会把系统拆成两层确定性层和概率性层。确定性层负责账户、权限、支付、库存这些不能出错的部分用传统微服务那套完全没问题概率性层负责理解、生成、规划、检索用模型和 Agent 来驱动。两层之间通过明确的契约通信概率性层的输出必须经过校验才能进入确定性层。这个边界划清楚后面很多扯皮的事情就没了。提示不要试图让大模型直接操作数据库或调用支付接口。概率性输出必须经过规则引擎或人工确认才能触发不可逆操作这是底线。2.2 为什么选“编排层 能力层”而不是“大一统模型”很多团队一开始想用一个超大模型解决所有问题实测下来成本和延迟都扛不住。我现在的做法是编排层 能力层编排层负责意图识别、任务拆解、路由分发能力层是一组专用的小模型或 API比如一个负责文本嵌入、一个负责摘要、一个负责代码生成、一个负责图像理解。这样做的理由很直接第一成本可控简单任务不走大模型第二延迟可控嵌入和检索可以用本地小模型第三可替换某个能力层效果不好可以单独换不影响全局。编排层我一般用轻量级的规则 小模型分类器而不是再套一个大模型否则就是“用魔法打败魔法”延迟和成本都会失控。2.3 数据层的重新设计向量、上下文与事件流传统系统数据层就是关系库 缓存。AI Native 系统至少要多三样东西向量存储用于语义检索、上下文存储用于多轮对话和 Agent 记忆、事件流用于观测和回放。向量库我试过几种小规模用 pgvector 就够了数据量上到千万级再考虑专用向量库。上下文存储要注意过期策略不然存储成本会悄悄涨上去。事件流我强烈建议从第一天就加上把每次模型调用的输入、输出、Token 数、延迟都记下来后面做评估和优化全靠它。3. 核心模块拆解与实操要点3.1 编排层意图路由与任务拆解怎么做编排层是整个系统的大脑但我不建议一上来就搞复杂的 Agent 框架。我的做法是先用意图分类 槽位填充把 80% 的常见请求处理掉剩下 20% 的长尾再交给 Agent 规划。意图分类可以用小模型微调也可以用提示词加少样本示例实测下来几百条标注数据就能达到可用水平。任务拆解这块我踩过最大的坑是过度拆解。一开始我把每个步骤都拆成一个独立的模型调用结果一个用户请求触发了十几次调用延迟直接飙到十几秒。后来改成“能合并的合并、能并行的并行”把独立的检索和生成并行跑延迟降了一半以上。具体做法是用一个 DAG 来描述任务依赖没有依赖的节点并行执行有依赖的串行。# 简化的任务编排伪代码 async def handle_request(user_input): intent await classify_intent(user_input) if intent simple_qa: context await retrieve_context(user_input) return await generate_answer(user_input, context) elif intent complex_task: plan await decompose_task(user_input) results await execute_dag(plan) # 内部并行执行无依赖节点 return await synthesize_results(results)注意并行执行时一定要设置超时和降级策略。某个检索节点超时了不能让整个请求挂掉要有兜底返回。3.2 能力层模型选型与成本控制的真实账本能力层的模型选型我一般按三个维度打分效果、延迟、成本。效果用业务指标衡量比如检索召回率、生成准确率延迟看 P95成本按每千次调用算。我实际项目里的组合通常是嵌入用本地小模型几乎零边际成本分类和路由用中等模型最终生成用大模型但加缓存。成本控制有几个实操技巧。第一提示词压缩把系统提示里冗余的礼貌用语和重复说明砍掉我试过能省 20% 到 30% 的输入 Token。第二结果缓存相同或相似请求直接返回缓存用向量相似度做命中判断。第三分级响应简单问题走小模型复杂问题才升级到大模型。第四流式输出虽然不省 Token但能显著改善用户感知延迟。能力类型推荐模型规模延迟目标成本策略文本嵌入本地小模型P95 50ms本地部署零边际成本意图分类中等模型P95 300ms微调小模型或提示词内容生成大模型P95 3s缓存 流式 分级图像理解多模态模型P95 5s按需调用结果缓存3.3 数据层向量检索与上下文管理的落地细节向量检索这块分块策略比模型选型更重要。我试过固定长度分块、按段落分块、按语义分块最后发现按语义分块 重叠窗口效果最稳。具体做法是先用规则把文档切成语义完整的段落再在段落之间加 10% 到 20% 的重叠避免边界信息丢失。嵌入模型选型上中文场景我一般用支持中文的嵌入模型维度 768 或 1024 都够用维度太高存储和检索成本都会涨。上下文管理要解决三个问题存什么、存多久、怎么取。我一般只存最近 N 轮对话的摘要 关键实体而不是存完整原文。摘要用模型生成关键实体用规则抽取。过期策略按业务定客服场景可能保留 7 天个人助手场景保留 30 天。取的时候用向量相似度 时间衰减越近的对话权重越高。4. 实操过程与核心环节实现4.1 从零搭建的最小可行架构如果你现在就要动手我建议先搭一个最小可行版本包含四个组件API 网关、编排服务、能力服务、向量库。API 网关负责鉴权和限流编排服务负责意图路由和任务拆解能力服务封装模型调用向量库负责检索。这四个组件用 Docker Compose 就能跑起来不需要一上来就上 Kubernetes。具体步骤第一步先把向量库跑起来导入一批测试数据验证检索效果。第二步写一个最简单的编排服务只支持一种意图跑通端到端。第三步加入第二个意图验证路由逻辑。第四步加入事件流记录把每次调用的输入输出存下来。第五步基于事件流做评估找出效果差的环节逐个优化。这个顺序的好处是每一步都有可验证的产出不会出现“搭了半个月还不知道效果怎么样”的情况。4.2 关键参数的计算与选择过程举一个实际例子假设你的系统每天有 10 万次请求其中 60% 是简单问答30% 是中等复杂度任务10% 是复杂任务。简单问答用本地小模型成本忽略不计中等任务用中等模型每次约 0.002 元复杂任务用大模型每次约 0.02 元。那么每天成本是 10万 × 30% × 0.002 10万 × 10% × 0.02 60 200 260 元一个月约 7800 元。如果你把所有请求都走大模型成本是 10万 × 0.02 2000 元每天一个月 6 万。这个账算清楚你就知道分级响应有多重要。延迟方面假设嵌入 50ms、检索 100ms、生成 2s串行总延迟约 2.15s。如果把检索和生成的部分步骤并行能压到 1.8s 左右。别小看这 300ms用户感知上差别很明显。4.3 流式输出与前端交互的配合流式输出是 AI Native 应用的标配但实现上有几个坑。第一分块边界模型返回的 Token 可能把一个词切成两半前端要做缓冲拼接。第二错误处理流到一半模型报错了前端要能优雅地显示已生成部分并提示重试。第三取消机制用户切换页面或发送新消息时要能取消正在进行的流。我一般用 SSE 做流式传输前端用 ReadableStream 读取配合 AbortController 做取消。// 前端流式读取的简化示例 const controller new AbortController(); const response await fetch(/api/chat, { method: POST, body: JSON.stringify({ message }), signal: controller.signal }); const reader response.body.getReader(); const decoder new TextDecoder(); let buffer ; while (true) { const { done, value } await reader.read(); if (done) break; buffer decoder.decode(value, { stream: true }); // 按行或按标记解析并渲染 }提示流式接口一定要设置合理的超时时间并且在后端记录每次流的完成状态方便排查“流到一半断了”的问题。5. 常见问题与排查技巧实录5.1 效果不稳定为什么昨天好用今天不行这是 AI Native 系统最典型的问题。原因通常有三个模型版本更新、提示词漂移、数据分布变化。模型版本更新你控制不了但可以做版本锁定和回归测试。提示词漂移往往是团队多人修改导致的建议把提示词纳入版本管理每次修改都跑一遍评估集。数据分布变化要靠监控比如统计每天请求的意图分布发现某个意图突然增多就要警惕。排查步骤先看事件流里最近的输入输出对比历史正常样本再检查提示词和模型版本有没有变最后跑一遍评估集看指标有没有下降。我一般会保留一个 200 条左右的黄金评估集每次变更都跑一遍指标下降超过 5% 就回滚。5.2 成本突然飙升的排查思路成本飙升通常来自三个地方请求量涨了、单次 Token 涨了、缓存失效了。先看请求量如果是正常增长那没办法如果是异常增长可能是被刷了或者有死循环调用。再看单次 Token可能是上下文越堆越长或者检索返回的内容太多。最后看缓存命中率缓存失效可能是键设计有问题或者数据更新太频繁。我遇到过一次成本翻倍最后发现是上下文管理没做过期历史对话越堆越长每次请求都带着几万 Token 的历史。加上摘要和过期策略后成本直接降回正常水平。这个坑很隐蔽因为功能上没问题只是账单悄悄涨。5.3 常见问题速查表问题现象可能原因排查方法解决方向响应延迟突然变高模型服务限流、检索数据量增大看 P95 延迟分布、检索耗时加缓存、优化索引、降级生成内容质量下降提示词变更、模型版本更新对比历史输出、跑评估集回滚提示词、锁定模型版本成本异常增长上下文过长、缓存失效看 Token 统计、缓存命中率加摘要、优化缓存键流式输出中断网络抖动、后端超时看后端日志、前端错误加重试、调整超时检索结果不相关分块策略差、嵌入模型不匹配人工抽查检索结果调整分块、换嵌入模型5.4 我踩过的三个印象最深的坑第一个坑是过度依赖大模型做路由。一开始我用大模型判断用户意图结果每次请求光路由就花 1 秒多成本也高。后来换成小模型分类器准确率只降了 2%延迟降到 50ms 以内。第二个坑是忽略冷启动。新系统上线时没有历史数据向量检索效果很差用户问什么都是“我不知道”。后来加了一个规则兜底和热门问题缓存体验才稳住。第三个坑是没有做输出校验。有一次模型生成了格式错误的 JSON下游解析直接崩了。后来所有模型输出都过一遍 schema 校验不通过就重试或降级。6. 演进路线与长期维护建议6.1 从 MVP 到生产级的三个阶段第一阶段是功能验证目标是把端到端跑通不追求效果和性能。这个阶段可以用最简单的模型和最小的数据集重点是验证架构可行性。第二阶段是效果优化目标是让核心指标达到可用水平。这个阶段要建评估集、做 A/B 测试、优化提示词和检索策略。第三阶段是规模化目标是支撑高并发和低成本。这个阶段要做缓存、分级响应、监控告警、自动化评估。每个阶段的重点不同不要跳步。我见过团队一上来就追求规模化结果效果还没调好就忙着优化性能最后两头都没做好。6.2 监控与评估体系的搭建AI Native 系统的监控比传统系统复杂因为多了“效果”这个维度。我一般监控四类指标技术指标延迟、错误率、吞吐、成本指标Token 消耗、缓存命中率、效果指标准确率、召回率、用户反馈、业务指标转化率、留存率。技术指标用常规监控工具效果指标靠评估集和人工抽检业务指标看产品数据。评估集要持续维护每次发现 bad case 就加进去定期清理过时的样本。我一般每两周跑一次全量评估每天跑一次抽样评估。评估结果要可视化让团队每个人都能看到效果变化。6.3 团队协作与提示词管理提示词是 AI Native 系统的核心资产但很多团队把它散落在代码里改起来很乱。我的做法是把提示词抽出来单独管理用版本控制每次修改都要走评审和评估。提示词模板里用变量占位运行时填充。不同环境的提示词可以不同但要有明确的切换机制。团队分工上我建议设一个“AI 效果负责人”的角色专门盯评估指标和 bad case而不是让每个开发各自为战。这个角色不一定是算法工程师但要对业务和模型都有理解。6.4 我个人在实际项目中的体会做了几个 AI Native 项目下来最大的体会是架构的确定性比模型的先进性更重要。模型每天都在更新但你的架构骨架要能稳定支撑三五年。把边界划清楚、把兜底做好、把观测做全比追最新模型有价值得多。另一个体会是不要追求一次做对AI 系统的效果是迭代出来的先上线再优化比憋大招靠谱。最后成本意识要贯穿始终很多 AI 项目不是死于效果不好而是死于成本失控。后续如果要做扩展我建议优先考虑多 Agent 协作和自动化评估。多 Agent 适合复杂任务拆解但要注意通信开销和死循环自动化评估能大幅降低人工成本但评估集的质量是关键。这两块我还在持续摸索有新进展再分享。
