1. 为什么现在要谈 AI Native 架构过去两年我参与过三个从零起步的 AI 项目也接手过两个“传统系统加挂 AI 模块”的改造项目。这两类项目的体感差异非常大前者从第一天就把模型当成系统的一等公民迭代速度、可观测性、成本控制都顺得多后者则像在老房子里改水电每加一个智能功能都要跟历史包袱搏斗。这也是我想认真聊聊AI Native 架构的原因——它不是把大模型 API 塞进现有业务里而是从系统设计的第一行代码开始就假设“智能”是核心能力而非外挂插件。先把概念说清楚。AI Native指的是系统的核心价值由模型能力驱动架构围绕模型的训练、推理、评估、迭代来组织而不是把模型当作一个可有可无的辅助工具。它和“AI Enabled”最大的区别在于前者如果拿掉模型系统就失去了存在意义后者拿掉模型业务照样跑只是少了点便利。这个判断标准很实用你在做架构决策时可以反复拿它来校准。这篇文章适合三类人看一是准备从零搭建 AI 产品的工程师和架构师二是正在做传统系统智能化改造的技术负责人三是对Agent 架构、LLM API 架构这些概念感兴趣但还没落地过的开发者。我会尽量把每个设计选择背后的“为什么”讲透而不是只给一堆结论。文中涉及的具体参数和工具选型都是基于我实际项目中的常见实践补充的你可以根据自己的场景调整。需要提前说明的是AI Native 架构目前没有唯一正确答案行业还在快速演进。我分享的是一套经过验证的思考框架和落地方法而不是教条。你在实际项目中一定要结合团队规模、业务阶段、成本预算来取舍。2. 核心设计思路与方案选型拆解2.1 从“功能中心”转向“能力中心”的思维切换传统系统设计的起点是功能列表用户要登录、要下单、要查询于是我们设计用户表、订单表、查询接口。AI Native 系统的起点应该是能力清单系统需要理解什么、生成什么、决策什么、记住什么。这个思维切换听起来抽象但落到架构上非常具体。举个例子一个智能客服系统。传统做法是设计工单表、会话表、知识库表然后加一个“调用大模型生成回复”的接口。AI Native 的做法是先定义能力意图识别能力、知识检索能力、回复生成能力、情绪感知能力、升级决策能力。每个能力对应一个独立的模块有自己的输入输出契约、评估指标和迭代节奏。模型不是某个接口的实现细节而是这些能力的核心载体。这样设计的好处是当你想换一个更强的模型或者想给某个能力加微调改动范围是可控的。我见过太多项目把模型调用散落在几十个业务函数里换模型时像拆炸弹。能力中心的思路强迫你在早期就做好边界划分这个投入非常值得。2.2 分层架构把模型层当成基础设施我推荐的 AI Native 分层大致是这样的最底层是模型层包括基础模型、微调模型、嵌入模型以及配套的推理服务往上是能力层把模型包装成可复用的原子能力比如摘要、分类、抽取、生成再往上是编排层负责把多个能力组合成业务流程这一层是Agent 架构的主战场最上面是应用层面向具体场景和用户界面。这个分层和传统微服务架构有相似之处但关键差异在于模型层的特殊性。模型推理有冷启动、有显存占用、有并发瓶颈不能像普通微服务那样随意扩缩容。所以模型层需要独立的资源池、独立的监控指标、独立的降级策略。我在项目里会把模型服务单独部署用队列做请求缓冲避免业务高峰把推理服务打挂。编排层是很多人容易低估的部分。当你的系统只有一两个模型调用时直接写在业务代码里没问题。但当你需要多步推理、需要工具调用、需要根据中间结果动态决策时就需要一个编排框架。这里的选择很多从轻量的函数编排到完整的Agent 架构都有。我的建议是先用最简单的方案等复杂度真的上来了再引入框架。过早引入重型编排框架调试成本会让你怀疑人生。2.3 数据流设计从请求响应到状态流转传统系统的数据流是请求-响应式的一次调用一次返回。AI Native 系统的数据流更像状态机一次用户交互可能触发多轮模型调用、多次工具执行、多次状态更新。这意味着架构上要支持长时任务、支持中间状态持久化、支持失败重试和断点续跑。我在设计时会引入一个“会话状态”的概念把整个交互过程的状态存在一个地方可以是 Redis也可以是数据库。每次模型调用前后都读写这个状态。这样做的好处是当某个步骤失败时可以从上一个稳定状态恢复而不是从头再来。对于涉及外部 API 调用的场景这个设计能省下大量重复计算和重复费用。还有一个容易被忽略的点流式输出。用户对 AI 产品的响应速度预期和传统软件不同他们能接受慢但不能接受“卡住没反应”。所以架构上要支持 token 级别的流式返回前端要能边收边渲染。这要求你的推理服务、网关、前端全链路都支持流式传输任何一环做了缓冲都会破坏体验。3. 核心模块的细节解析与实操要点3.1 模型接入层多模型路由与降级策略实际项目里很少只用一个模型。常见组合是一个强模型处理复杂推理一个快模型处理简单分类一个嵌入模型做检索。多模型路由是接入层的核心职责。路由策略我一般分三级第一级按任务类型路由分类任务走快模型生成任务走强模型第二级按负载路由某个模型排队过长时切到备用模型第三级按降级路由强模型不可用时用快模型兜底虽然质量下降但不至于服务中断。这个策略用配置文件就能实现不需要上复杂的服务网格。注意多模型路由一定要有统一的抽象接口。我见过团队每个模型写一套调用代码结果换模型时要改十几个地方。定义一个统一的generate和embed接口所有模型实现这个接口路由层只依赖接口。参数选择上温度、最大 token 数、超时时间这三个必须显式配置不能依赖默认值。温度影响输出稳定性生产环境建议 0.1 到 0.3最大 token 数要结合成本和场景客服回复 500 够用文档生成可能要 4000超时时间要略大于 P99 延迟我一般设 30 秒配合重试。3.2 能力封装层把 Prompt 当成代码来管理Prompt 是 AI Native 系统里最容易被轻视的资产。很多团队把 Prompt 硬编码在代码里改一个字就要发版。我的做法是把 Prompt 当成配置来管理存在数据库或配置中心支持版本管理和灰度发布。更进一步我会给每个 Prompt 定义输入输出契约。输入是结构化的变量输出是结构化的格式。比如一个信息抽取能力输入是文本和字段列表输出是 JSON。这样能力层对外暴露的是稳定的函数签名内部 Prompt 怎么改都不影响调用方。评估是能力层的另一个关键。每个能力都要有评估集哪怕只有几十条样本。每次改 Prompt 或换模型跑一遍评估集看准确率有没有下降。这个习惯能帮你避免很多“改好了这个坏了那个”的问题。评估集要覆盖典型场景和边界场景我一般会从线上日志里采样构建。3.3 编排层Agent 架构的取舍Agent 架构是当前的热点但我要泼一点冷水不是所有场景都需要 Agent。Agent 的核心价值在于动态决策——系统根据中间结果决定下一步做什么。如果你的流程是固定的用工作流引擎就够了Agent 只会增加不确定性和调试难度。判断标准很简单如果业务流程能用流程图完整画出来且分支条件都是确定的那就用工作流。如果流程需要模型来判断“下一步该查什么”“这个结果够不够”“要不要再问用户一句”那才需要 Agent。我在项目里通常是混合使用外层用工作流保证可控内层关键决策点用 Agent 增加灵活性。Agent 的工具调用要特别注意权限和幂等。模型可能会重复调用同一个工具也可能会调用不该调用的工具。我的做法是给每个工具定义明确的权限范围写操作必须幂等危险操作需要人工确认。这些约束要在工具定义里写清楚让模型知道边界。3.4 记忆与上下文管理别让上下文无限膨胀上下文窗口是有限资源也是成本大头。我见过项目把整个对话历史塞进每次请求结果 token 消耗爆炸响应还慢。正确的做法是分层管理记忆短期记忆是最近几轮对话中期记忆是摘要后的历史长期记忆是向量库里的知识。摘要策略我一般这样设计当对话超过 N 轮把最早的几轮交给模型做摘要摘要结果替换原始对话。N 的取值看场景客服场景 10 轮左右创作场景可以更长。摘要本身也是一次模型调用要算进成本。向量检索要注意分块策略。块太大检索不精准块太小丢失上下文。我的经验是 300 到 500 token 一块重叠 50 token。检索时先粗排再精排粗排用向量相似度精排可以用交叉编码器或者直接让模型判断相关性。这个两阶段设计能显著提升检索质量。4. 从零搭建的实操流程与关键环节4.1 环境准备与技术栈选型从零开始的第一步不是写代码而是确定技术栈。我的建议是编程语言选团队最熟的不要为了 AI 而换语言。Python 生态最丰富但如果团队是 Java 背景用 Java 调模型 API 也完全可行。框架选择上轻量优先FastAPI 或 Spring Boot 都能胜任。推理服务如果要用开源模型vLLM 是目前比较成熟的选择支持连续批处理和 PagedAttention吞吐量比朴素实现高好几倍。如果只用 API 模型那推理服务这块可以省掉直接对接供应商。数据库方面业务数据用关系型数据库向量数据用专门的向量库不要试图用关系库硬扛向量检索。部署环境要考虑 GPU 资源的弹性。如果用量波动大用容器化部署配合自动扩缩容。如果用量稳定固定资源更省钱。我一般会先估算峰值 QPS再反推需要的 GPU 数量留 30% 余量。4.2 最小可用系统的搭建步骤第一步搭一个最简单的端到端链路用户输入 - 模型调用 - 返回结果。不要加任何花哨功能先跑通。这一步能帮你验证 API 连通性、鉴权、计费这些基础问题。第二步加上会话管理。用一个简单的会话 ID 关联多轮对话状态存 Redis。这一步能让你开始测试多轮场景。第三步加上能力封装。把模型调用包装成有名字、有契约的函数。哪怕只有两个能力也要走这个流程养成习惯。第四步加上评估。建一个小的评估集写一个脚本能一键跑评估。这一步是分水岭有评估的团队和没评估的团队迭代质量差距会越来越大。第五步加上可观测性。记录每次调用的输入、输出、耗时、token 数、成本。这些数据是后续优化的基础。我一般用结构化日志方便后续分析。4.3 关键参数的计算与选择成本估算是绕不开的。假设你的应用日均 1 万次调用平均每次输入 1000 token、输出 500 token用某中档模型输入价格假设为每百万 token 若干元输出价格更高。你可以按这个公式估算月成本日均调用数 × 30 ×输入 token × 输入单价 输出 token × 输出单价。这个数字要提前算清楚否则上线后账单会让你措手不及。延迟预算也要提前分配。用户能接受的端到端延迟一般是 3 到 5 秒。这 5 秒要分给网络传输、检索、模型推理、后处理。模型推理通常占大头所以选模型时不能只看质量还要看延迟。我一般会准备一个快模型做兜底延迟敏感的场景优先用快模型。并发能力的估算单张 GPU 跑 7B 模型用 vLLM 优化后大概能支撑几十路并发。具体数字取决于输入输出长度和硬件型号一定要实测。我的做法是压测出单实例的 QPS 上限然后按峰值流量的 1.5 倍配置实例数。4.4 上线前的检查清单上线前我会过一遍这个清单模型降级策略是否生效、超时和重试是否配置、成本告警是否设置、敏感内容过滤是否开启、日志是否脱敏、评估集是否通过、压测是否达标。任何一项没过都不建议上线。还有一点准备一个“熔断开关”。当模型服务出现问题时能一键切换到降级模式比如返回预设话术或转人工。这个开关在事故时能救命。5. 常见问题与排查技巧实录5.1 模型输出不稳定的排查思路输出不稳定是最常见的问题。排查顺序我一般是先看温度参数是不是设太高了再看 Prompt是不是指令不够明确然后看输入是不是有歧义最后才怀疑模型本身。大部分不稳定问题出在 Prompt 上而不是模型。如果 Prompt 已经写得很清楚还是不稳定可以试试 few-shot给几个示例。示例要覆盖典型情况数量 3 到 5 个就够太多反而占上下文。还可以用结构化输出约束比如要求模型返回 JSON配合 schema 校验不合法就重试。5.2 成本超支的常见原因成本超支通常有几个原因上下文太长、重复调用、模型选型过强、缓存缺失。上下文问题前面说过了摘要和截断是基本操作。重复调用往往是架构问题比如同一个请求在多个模块各调一次模型应该在上层做结果缓存。模型选型过强是很多团队的隐性浪费。简单任务用强模型成本可能差十倍。我的做法是给每个能力标注“质量敏感度”低敏感度的用快模型高敏感度的才用强模型。缓存方面相同或相似的请求结果可以缓存尤其是检索类请求命中率往往很高。5.3 常见问题速查表问题现象可能原因排查方向解决建议响应超时模型排队、输入过长看推理服务队列长度、输入 token 数加实例、截断输入、换快模型输出格式错误Prompt 约束不足检查 Prompt 和输出解析逻辑加 schema 校验、加重试成本突然上涨调用量增加、上下文变长看调用日志和 token 统计加缓存、优化摘要策略检索不准分块不合理、嵌入模型不匹配检查分块大小和检索结果调整分块、换嵌入模型多轮对话失忆上下文管理有 bug检查状态读写逻辑修复状态持久化、加测试工具调用失败参数格式错误、权限不足看工具调用日志加参数校验、明确权限5.4 几个踩过的坑第一个坑把 Prompt 写在代码里。改一次发一次版效率极低。后来改成配置化效率提升明显。第二个坑没有评估集就上线。改了一个 Prompt以为变好了结果线上投诉变多。后来强制要求每个能力都有评估集改之前先跑评估。第三个坑忽略流式输出。用户以为系统卡死了其实是模型在慢慢生成。加上流式后体感好了很多。第四个坑没有成本告警。某天账单翻倍才发现有个循环调用 bug。后来加了日成本告警超过阈值就通知。第五个坑Agent 权限过大。模型调用了一个删除接口虽然测试环境没造成损失但吓出一身冷汗。后来所有写操作都加了确认和幂等。6. 迭代与演进的个人体会AI Native 系统不是一次设计到位的它更像一个持续演进的有机体。我的体会是早期不要追求架构完美先把端到端跑通然后根据实际痛点逐步优化。很多架构问题只有在真实流量下才会暴露过早优化是浪费。另一个体会是评估体系比模型选型更重要。模型会不断更新今天的最优解明天可能就过时了。但一套好的评估体系能让你快速判断新模型是否值得切换。我在项目里会把评估做成自动化流程新模型接入后自动跑评估用数据说话。最后分享一个小技巧给每个模型调用打上标签记录它属于哪个能力、哪个版本、哪个场景。这些标签在排查问题和分析成本时非常有用。我一般会在日志里带上能力名、Prompt 版本、模型名、会话 ID 这几个字段排查时能快速定位。这个方向后续还可以扩展的地方很多比如多模态能力的接入、模型微调的流程化、A/B 测试的自动化。但无论怎么扩展核心原则不变模型是系统的一等公民架构围绕能力组织评估驱动迭代。把这三点做好你的 AI Native 系统就有了扎实的地基。