1. 为什么AI Native不是给旧系统加个模型接口这两年AI Native这个词被用得很泛很多团队的做法是在已有的业务系统里塞一个模型调用接口然后对外宣称完成了 AI 化改造。我见过不止一个项目后端还是那套跑了五六年的 CRUD 服务只是在某个环节加了一次大模型请求结果上线之后问题一堆延迟不可控、成本算不清、模型输出没法回滚、业务逻辑和推理逻辑搅在一起改一处崩三处。我的判断很直接AI Native 的核心不是用了 AI而是系统的组织方式从第一天起就把模型当成一等公民来设计。这两者的差别类似于给马车装个发动机和从头设计一辆汽车。前者能跑但跑不快也跑不远后者才是真正的架构升级。具体来说传统系统里一个请求的处理路径是确定的输入 → 校验 → 业务规则 → 数据库 → 输出。每一步的耗时、结果、副作用都是可预测的。而 AI Native 系统里核心处理环节变成了一个概率性的推理过程同样的输入可能得到不同的输出耗时可能从 200ms 跳到 8s成本可能因为一次上下文膨胀而翻十倍。如果你还用确定性系统的思路去套它架构层面必然处处别扭。所以这篇文章我想聊的不是怎么调某个模型的 API而是从零构建一个以 AI 为核心的系统时架构上到底要做哪些不一样的决定。适合正在做 AI 产品从 0 到 1 的工程师、技术负责人也适合那些已经把模型接进系统、但感觉越做越乱、想回头重构的团队。我会尽量把每个设计选择背后的为什么讲清楚而不是丢一堆名词。在展开之前先明确一个前提AI Native 不等于全都要用大模型。有些环节用规则引擎反而更稳、更便宜。真正的 AI Native 是知道哪些环节该交给模型、哪些环节必须用确定性逻辑兜底并且让这两者在架构上能干净地协作。2. 把不确定性当成架构的第一约束来设计2.1 确定性系统与概率性系统的根本差异传统后端架构的很多设计假设在 AI 场景下是直接失效的。我列一个对照表这是我踩过坑之后总结出来的基本覆盖了日常最容易翻车的地方维度传统确定性系统AI Native 系统输出唯一、可复现概率性、可能每次不同延迟稳定、可预估波动大长尾明显成本基本固定与 token、调用次数强相关失败模式抛异常、返回错误码静默给出看起来对但错的结果可测试性单元测试覆盖需要评估集 打分机制版本管理代码版本即行为代码 模型 提示词三者共同决定行为这张表里最要命的是失败模式那一行。传统系统出错会报错你能立刻知道AI 系统出错往往是一本正经地胡说接口返回 200日志一切正常但结果是错的。这意味着你的监控体系、告警体系、测试体系都得重新设计。2.2 延迟与成本必须在一开始就纳入容量规划我做过一个客服辅助的项目最初没做任何限流和缓存上线第一周就遇到一次流量高峰模型调用并发直接打满账单当天涨了平时一周的量。后来复盘问题出在架构上根本没有成本这个维度。正确的做法是把每一次模型调用都当成一次有成本的资源消耗来管理。具体落地时我会做三件事给每个调用点打上业务标签哪个功能、哪个用户、哪个租户方便按维度算账设置单请求的 token 上限和超时上限超了就走降级逻辑对高频且结果稳定的请求做缓存缓存键要包含模型版本和提示词版本否则模型一升级缓存就脏了。延迟方面长尾是常态。P50 可能只有 800ms但 P99 能到 10s 以上。如果你的上游有同步等待必须设置合理的超时和兜底文案不能让用户干等。我一般会把超时设成 P95 的 1.5 倍左右超过就返回一个正在处理的中间态用异步方式补结果。2.3 用评估集替代传统单元测试的思路确定性系统里一个函数输入 A 必然输出 B写个断言就完事。AI 系统做不到这一点所以测试范式要换。我的做法是维护一个评估集一批有代表性的输入加上人工标注的期望输出或评分标准每次改动提示词、换模型、调参数都跑一遍评估集看整体得分有没有退化。评估集不用很大初期 50 到 100 条就能覆盖主要场景关键是要包含边界 case 和历史上出过错的 case。我习惯把线上发现的 bad case 定期补进评估集这样它就成了一个不断进化的回归测试集。评分可以用规则比如关键词命中、格式校验加人工抽检结合纯靠模型自评容易失真。提示评估集一定要版本化和代码一起进仓库。否则你根本说不清这次效果变好是因为改了提示词还是因为换了评估标准。3. 分层架构让模型、编排、业务各归其位3.1 为什么要把模型调用和业务逻辑彻底分开我见过最乱的一种写法是在业务 service 里直接拼提示词、直接调 SDK、直接解析返回。这种代码三个月后就没人敢动了因为提示词和业务规则缠在一起改一个标点都可能影响业务判断。AI Native 架构里我会强制分三层模型接入层统一封装不同模型的调用处理鉴权、重试、限流、超时、token 计数。上层不关心用的是哪家模型。编排层负责提示词组装、上下文管理、多步推理的流程控制、工具调用function calling的调度。这一层是 AI 系统的大脑。业务层只关心业务语义比如给这个订单生成一段推荐话术它调用编排层的能力拿到结果后做业务校验和落库。这样分的好处是换模型只动接入层改提示词只动编排层业务规则变化只动业务层。三者解耦各自可以独立测试和迭代。3.2 编排层是整个系统最需要精心设计的地方编排层听起来抽象其实它解决的是一个很实际的问题一次用户请求往往需要多步模型交互才能完成。比如一个文档问答可能要先把文档切片、检索相关片段、拼进上下文、调用模型、解析引用、再校验答案是否有据可依。如果把这些步骤硬编码在一个函数里很快就会变成几百行的意大利面。我的做法是把每个步骤抽象成一个可组合的节点用一条流程把它们串起来。节点之间传递的是结构化的中间状态而不是裸字符串。这样每一步都可以单独打日志、单独重试、单独替换。这里有个经验中间状态一定要结构化。我早期图省事节点之间传的是拼接好的字符串结果调试时根本看不出哪部分是检索来的、哪部分是模型生成的排查问题极其痛苦。后来改成传 JSON 对象每个字段来源清晰问题定位效率提升非常明显。3.3 上下文管理是容易被低估的工程难点大模型的上下文窗口是有限资源而且直接和成本挂钩。很多团队一开始不管上下文把所有历史对话一股脑塞进去结果就是成本飙升、延迟变长、模型还容易被无关信息干扰。我在实际项目里会做几件事来控制上下文分层记忆近期对话保留原文久远对话做摘要压缩关键事实单独存成结构化字段按需检索不是所有历史都相关用检索的方式只取当前问题需要的片段预算控制给每次调用设定 token 预算超了就按优先级裁剪优先保留系统指令和最近几轮。注意摘要压缩本身也是一次模型调用有成本和延迟。别为了省 token 反而引入了更多调用要算总账。4. 数据流与状态管理AI 系统的记忆怎么存4.1 会话状态、业务状态、模型状态要分开存一个常见的混乱来源是把所有状态混在一起。我会明确区分三类状态会话状态对话历史、当前上下文特点是读写频繁、生命周期短、可以容忍一定丢失业务状态订单、工单、用户资料这类特点是强一致、要持久化、不能丢模型状态模型版本、提示词版本、评估结果特点是变更不频繁但影响全局。这三类状态的存储选型、一致性要求、清理策略都不一样。会话状态可以放内存或带 TTL 的缓存业务状态进关系库模型状态进配置中心或版本库。混在一起存后期一定会遇到清缓存把业务数据清了或者业务事务把会话锁死了这类问题。4.2 幂等与重试模型调用必须可重放模型调用会因为网络、限流、超时等原因失败重试是必须的。但重试会带来一个新问题如果第一次调用其实成功了只是响应没收到重试就会产生重复副作用。比如重复扣费、重复发消息。解决办法是给每次调用生成一个幂等键服务端记录已处理的键重复请求直接返回上次结果。对于有副作用的操作比如模型生成的内容要写库要么保证操作本身幂等要么把生成和落库分成两步生成结果先暂存确认后再落库。4.3 流式输出对状态管理的额外要求现在很多 AI 产品都用流式输出用户能边生成边看到内容。体验是好但对状态管理提出了新要求流式过程中连接可能断断了之后要能续上。我的处理方式是服务端把流式生成的内容持续写入一个临时缓冲区并记录已发送的偏移量。客户端断线重连时带上偏移量服务端从断点继续推。这样即使用户网络抖动也不会丢掉已经生成的内容更不会重复计费。5. 可观测性看不见的模型行为等于失控5.1 传统监控指标不够用要补哪些CPU、内存、QPS 这些传统指标当然还要但对 AI 系统来说远远不够。我会额外关注这几类token 消耗按功能、按租户、按模型维度统计这是成本的直接来源首 token 延迟和总延迟流式场景下首 token 延迟直接决定用户体感调用成功率与降级率区分是模型报错、超时还是被限流输出质量指标比如格式合规率、被业务校验拦截的比例。这些指标要能下钻到单次请求否则出了问题只能干瞪眼。5.2 全链路追踪要能还原模型看到了什么排查 AI 问题时最关键的信息是模型当时到底收到了什么输入。所以追踪系统里必须记录完整的提示词脱敏后、检索到的上下文、模型返回的原始内容。我一般会给每次调用分配一个 trace id把这几样东西关联起来。这里有个隐私上的坑提示词里可能包含用户敏感信息直接全量记录有合规风险。我的做法是记录时做脱敏敏感字段用占位符替换同时保留一个加密的原始副本只有授权人员能解密查看。5.3 用影子流量验证新版本换模型或改提示词之前我会用影子流量的方式验证把线上真实请求复制一份同时打到新旧两个版本上对比输出差异。这样能在不影响真实用户的前提下提前发现新版本的问题。差异大的 case 人工 review确认是改进还是退化。6. 从零搭建时的技术选型与落地顺序6.1 别一上来就追求全家桶我见过不少团队项目还没跑通就先搭了一套复杂的向量库、编排框架、评估平台结果核心功能迟迟出不来。我的建议是按需引入先跑通最小闭环。一个务实的落地顺序是这样的先用最直接的方式调通模型验证核心场景可行把模型调用封装成独立的一层加上超时、重试、日志引入编排层把多步流程结构化加上评估集和基础监控再根据实际瓶颈引入缓存、检索、多模型路由等能力。每一步都是被真实需求驱动的而不是为了架构好看。6.2 模型路由不要把所有请求都打给最贵的模型不同任务对模型能力的要求差别很大。简单分类、格式转换用轻量模型就够复杂推理才需要上大模型。我会在接入层做一个路由根据任务类型、输入长度、历史成功率选择模型。这样能在保证效果的前提下把成本压下来。路由策略要可配置、可灰度别写死在代码里。因为模型的能力和价格都在变今天的最优解下个月可能就不是了。6.3 降级方案必须提前设计模型服务不是 100% 可用的限流、故障、超时都会发生。没有降级方案的 AI 系统是不完整的。降级可以是切换到备用模型返回缓存的历史结果走规则引擎的兜底逻辑明确告诉用户暂时无法处理请稍后重试。关键是降级要快、要可观测不能悄悄降级让用户以为得到的是正常结果。7. 我在实际项目里踩过的几个坑第一个坑是提示词硬编码在代码里。早期为了快提示词直接写在 Python 字符串里改一次要发一次版。后来遇到紧急调整发版流程走完黄花菜都凉了。现在我会把提示词抽到配置文件或配置中心支持热更新并且带版本号方便回滚。第二个坑是忽略 token 计数的边界。有一次用户上传了一个超长文档直接拼进上下文结果超出模型窗口被截断模型基于残缺信息给出了错误答案用户还以为是系统 bug。后来我在入口就做了长度校验和分片处理超长内容先切分再检索不再无脑拼接。第三个坑是评估集长期不更新。项目上线半年后业务场景已经变了很多但评估集还是最初那批 case导致评估结果和真实体验脱节。现在我强制要求每个迭代周期都补充新的 bad case 进评估集保持它的代表性。第四个坑是多租户场景下没做资源隔离。一个租户的突发流量把模型配额打满影响了其他所有租户。后来按租户做了配额和优先级重要租户有保底配额普通租户超限就排队或降级。8. 关于 AI Native 架构我个人的几条经验做了几个 AI 项目之后我越来越觉得AI Native 架构的难点不在 AI而在架构。模型能力是外部给定的你能控制的是怎么把它组织进系统、怎么管理它的不确定性、怎么在它出错时兜住。如果让我给正在起步的团队一句建议那就是先把不确定性当成第一约束再谈其他。延迟、成本、失败模式、可测试性这四件事想清楚了架构的大方向就不会错。至于用哪个框架、哪个向量库都是次要的随时可以换。还有一点别迷信一步到位。AI 这个领域变化太快今天的最佳实践可能半年后就过时了。与其追求一个完美的架构不如把系统设计成容易替换、容易观测、容易降级的样子这样无论底层怎么变你都能快速跟上。