1. 为什么现在要聊 AI Native 架构过去两年我参与过三个从零起步的 AI 项目也接手过两个传统系统加个模型接口的改造项目。这两类项目的结局差异非常大前者上线三个月后迭代速度依然很快后者则在半年内陷入改一处崩三处的泥潭。复盘下来问题几乎都出在架构起点上——AI Native 不是给旧系统接一个大模型 API而是从第一天起就把模型当成系统的一等公民来设计。这篇文章想聊的就是这件事如果你现在要做一个以 AI 为核心的系统从零开始应该怎么搭骨架。核心关键词是AI Native、架构、系统但我不想写成概念科普而是按一个真实项目的推进顺序把每个决策背后的取舍讲清楚。适合正在做 AI 产品、准备重构老系统、或者单纯想搞明白AI Native 到底和普通架构差在哪的开发者阅读。哪怕你只写过 CRUD也能看懂因为我会尽量用生活化的类比来解释。先说结论性的判断AI Native 架构和传统架构最大的区别不在于用了什么框架而在于不确定性被提升为架构的一等约束。传统系统里一个函数输入 A 必然输出 BAI 系统里同样的输入可能给出 B、C 或者一个看起来像 B 但其实是错的答案。你的整个架构本质上是在为这种不确定性设计缓冲、验证和兜底机制。想明白这一点后面所有的技术选型都会顺理成章。2. AI Native 架构的整体设计与思路拆解2.1 先搞清楚 AI Native 和AI 加持的本质区别我见过太多团队把在系统里调用一次大模型当成 AI Native结果做出来的东西本质上还是个规则引擎模型只是个装饰。真正的区别可以用一个类比说明传统系统像自动售货机投币选货出货口必然掉出你选的那瓶水AI Native 系统更像请了一个新员工你得给他交代任务、检查他的产出、在他犯错时兜底还要让他随着经验积累越做越好。落到架构上这个区别体现为四个层面的重构。第一是控制流传统系统是确定的分支和循环AI 系统是模型决策 程序约束的混合控制流。第二是数据流传统系统的数据是结构化、可校验的AI 系统的输入输出大量是非结构化文本、图像、向量。第三是状态管理传统系统的状态是明确的数据库记录AI 系统还要管理上下文、记忆、会话历史。第四是质量保障传统系统靠单元测试AI 系统还得加上评估集、回归测试、人工反馈闭环。我个人的经验是判断一个系统是不是 AI Native就问一个问题如果把模型换成一个更弱的版本系统会不会整体崩掉如果会说明模型是核心架构是围绕它建的如果不会那模型只是个可选插件你做的还是传统架构。2.2 分层设计把不确定性关进笼子基于上面的判断我推荐的 AI Native 架构大致分五层从下往上依次是基础设施层、模型接入层、能力编排层、业务逻辑层、交互层。这个分层不是照搬教科书而是我在实际项目里反复调整后觉得最顺手的切法。基础设施层负责算力、存储、网络这些底座。这里的关键决策是自建还是用云、用哪种推理硬件。我的建议是早期一律用云把精力留给上层等业务模型稳定了再考虑成本优化。模型接入层是 AI Native 特有的传统架构里没有这一层。它的职责是把各种模型大语言模型、图像模型、语音模型、传统机器学习模型统一成一套调用接口同时处理重试、限流、降级、缓存。这一层做得好上层业务就感觉不到模型供应商的差异。能力编排层是很多人忽略但极其重要的一层。单个模型调用往往不够真实业务需要检索 推理 工具调用 结果校验的组合。这一层负责把这些原子能力编排成可复用的工作流也就是现在常说的 Agent 架构的落脚点。业务逻辑层是传统意义上的业务代码但它现在要处理的是模型给出的不确定结果所以需要大量的校验、转换、兜底逻辑。交互层负责和用户打交道包括流式输出、进度反馈、结果确认这些 AI 产品特有的交互模式。提示分层的目的不是画得好看而是让每一层的变化不会污染其他层。模型换代只动接入层业务规则变化只动业务层这是分层的真正价值。2.3 为什么不做大一统的单体架构有朋友会问早期项目直接写一个单体应用把所有逻辑塞在一起不是更快吗我的回答是AI 系统的迭代速度决定了你必须提前分层。传统系统可能半年才改一次核心逻辑AI 系统可能每周都在调 prompt、换模型、加工具。如果所有东西耦合在一起每次调整都要全量回归测试迭代速度会被拖垮。但我也反对一上来就搞微服务。我踩过的坑是早期把模型接入、编排、业务拆成三个独立服务结果一个请求要跨三次网络调试时日志散落各处排查一个问题要开四个终端。后来改成单体应用 清晰模块边界等某个模块真的成为瓶颈了再拆出去。这个度怎么把握我的经验是模块边界要清晰物理部署可以先合后分。3. 核心细节解析与实操要点3.1 模型接入层统一抽象是省心的关键模型接入层最容易犯的错是让业务代码直接调用各家 SDK。今天用 A 家的接口明天想换 B 家结果发现业务代码里到处是 A 家的参数格式。解决办法是定义一个统一的内部接口把所有模型差异挡在外面。我通常定义的接口长这样伪代码示意class ModelClient: def complete(self, messages, toolsNone, **kwargs) - ModelResponse: 统一的对话补全接口 ... def embed(self, texts) - list[list[float]]: 统一的向量化接口 ...关键在于ModelResponse这个返回结构要设计得足够通用能容纳文本、工具调用请求、token 用量、结束原因这些信息。不同供应商的原始返回在这里被归一化上层拿到的永远是同一套结构。这里有个实操细节重试策略要区分错误类型。网络超时、限流这类错误可以重试但内容审核拒绝、参数错误这类重试也没用反而浪费额度。我在接入层里维护了一张错误码映射表把各家供应商的错误码统一成可重试和不可重试两类这个表是踩了无数次坑才攒出来的。3.2 能力编排层Agent 架构的落地要点能力编排层是 AI Native 架构里最有技术含量的部分。现在流行的 Agent 架构本质上就是让模型自己决定调用哪些工具、按什么顺序调用。但纯靠模型自主决策在生产环境里非常危险我的做法是给模型划定一个受控的决策空间。具体来说我会把编排拆成三种模式。第一种是固定流程适合步骤明确的场景比如先检索知识库再让模型总结最后格式化输出这种根本不需要模型决策用代码写死就行稳定又便宜。第二种是有限分支模型在几个预设路径里选一个比如客服场景里判断是查订单还是退换货。第三种才是自由 Agent模型自主规划多步工具调用这种我只在探索性场景用生产环境慎用。注意自由 Agent 的调试成本极高。我做过一个统计一个五步的自主 Agent 任务失败时定位是哪一步出错平均要花 40 分钟。能用固定流程解决的绝不上自由 Agent。编排层还需要处理上下文管理。多轮对话里历史消息会越来越长直接全塞给模型既贵又容易超上下文。我的策略是分层处理最近几轮完整保留较早的对话做摘要压缩更早的直接丢弃或转成向量检索。这个策略要根据业务特点调客服场景可能需要保留更长的历史工具调用场景则只需要保留最近的状态。3.3 业务逻辑层为不确定性设计校验业务逻辑层在 AI Native 架构里的核心任务是把模型的概率性输出转成确定性结果。我总结了三道防线。第一道是格式校验。如果业务要求模型输出 JSON那就必须用结构化输出能力或者严格的解析加修复逻辑。我见过太多因为模型偶尔多输出一句话导致整个流程崩溃的案例。第二道是语义校验。格式对了不代表内容对。比如模型返回了一个订单号格式是合法的但这个订单号在数据库里根本不存在。这类校验必须结合业务数据做。第三道是置信度兜底。当模型自己都不确定时比如返回了低置信度或者明确表示无法回答系统要能优雅降级而不是硬着头皮输出错误答案。降级的策略可以是转人工、返回默认值、或者引导用户换个问法。3.4 交互层流式输出与进度反馈AI 产品的交互和传统产品差别很大最典型的就是响应时间长且不确定。一个复杂任务可能要几十秒用户盯着转圈圈会焦虑。解决办法是流式输出加进度反馈。流式输出现在各家模型都支持但要注意的是流式场景下的错误处理更麻烦——你可能已经吐了一半内容才发现后面出错了。我的做法是在流式过程中维护一个缓冲区如果中途出错要么补一个明确的错误提示要么用兜底内容把话说完绝不能让用户看到半截话就断了。进度反馈则要区分模型在思考和工具在执行。前者可以显示正在分析后者可以显示正在查询订单系统。这种细粒度的反馈能显著降低用户的等待焦虑实测下来用户对同样时长的等待有进度反馈的满意度明显更高。4. 实操过程与核心环节实现4.1 从零搭建的最小可行架构假设你现在要做一个智能文档问答系统我按实际推进顺序讲一遍怎么搭。第一步是确定核心链路。这个系统的核心链路是用户提问 → 检索相关文档片段 → 模型基于片段生成回答 → 返回并标注来源。这条链路里检索和生成是两个核心能力来源标注是业务要求。第二步是搭建模型接入层。我会先封装一个统一的模型客户端支持对话和向量化两个接口。向量化用于文档索引和查询对话用于生成回答。这里要提前考虑好向量维度、批量大小这些参数因为一旦文档索引建好换向量模型就要重建整个索引成本很高。第三步是实现检索能力。文档先切块每块做向量化存进向量库。查询时把问题向量化做相似度检索取 top-k 个片段。这里的参数 k 很关键k 太小可能漏掉关键信息k 太大则噪声多且费 token。我的经验是先用 k5 起步根据评估结果调整。第四步是实现生成能力。把检索到的片段和用户问题拼成 prompt调用对话模型。prompt 里要明确要求模型只基于给定片段回答无法回答时明确说明这是减少幻觉的关键。第五步是加上来源标注。让模型在回答里引用片段编号系统再把编号映射回原始文档位置。这一步看似简单但模型经常引用错编号所以还需要一层校验。4.2 关键参数的计算与选择上面提到的几个参数我展开讲讲怎么定。文档切块大小太小则语义不完整太大则检索精度下降。我一般按 300 到 500 个 token 切块之间留 10% 到 20% 的重叠避免关键信息被切断。这个值不是拍脑袋而是根据文档类型调的——技术文档段落长可以切大点对话记录短就切小点。检索 top-k这个要看评估。我会准备一个测试集里面是问题 标准答案 应该命中的文档块然后测不同 k 值下的召回率。实测下来k 从 3 加到 5 召回率提升明显从 5 加到 10 提升就很小了但 token 成本翻倍所以 5 是个比较划算的点。上下文预算分配模型有上下文上限检索片段、历史对话、系统提示都要占额度。我的分配原则是系统提示不超过 20%检索片段不超过 50%历史对话不超过 20%剩下 10% 留给模型输出。这个比例要根据业务调但一定要有预算意识否则很容易超限。4.3 评估体系的搭建AI 系统没有评估体系就是盲人摸象。我在每个项目里都会建三套评估。离线评估集人工标注的输入 期望输出对每次改动后跑一遍看通过率有没有下降。这个集子要持续维护把线上发现的 bad case 加进去。在线指标用户采纳率、追问率、人工转接率这些。追问率高说明回答质量不行人工转接率高说明兜底没做好。回归测试每次换模型、改 prompt 都要跑防止修好一个坏了一片。我踩过的坑是改了一个 prompt 让某类问题回答变好了结果另一类问题全崩了就是因为没做回归。4.4 部署与灰度AI 系统的部署有个特殊点模型版本和 prompt 版本都要能独立回滚。我把 prompt 当成配置管理每次改动都有版本号出问题能秒回滚。模型切换则走灰度先放 5% 流量观察指标正常再逐步放量。提示prompt 一定要版本化并且和代码版本解耦。我见过把 prompt 硬编码在代码里的项目改一句话要走完整发布流程效率极低。5. 常见问题与排查技巧实录5.1 高频问题速查表问题现象可能原因排查方向解决思路回答内容与文档不符检索没命中或模型幻觉检查检索结果、检查 prompt 约束调 top-k、强化 prompt 约束、加校验响应特别慢上下文过长或模型负载高看 token 用量、看模型延迟压缩上下文、换更快的模型、加缓存同样问题答案不稳定模型温度参数过高检查 temperature 设置降低温度、固定随机种子工具调用频繁失败参数格式错误或工具超时看工具调用日志加参数校验、加超时重试成本超预期上下文浪费或重复调用统计 token 消耗分布加缓存、精简 prompt、批处理多轮对话丢失上下文历史管理策略问题检查历史压缩逻辑调整保留轮数、优化摘要策略5.2 几个我踩过的坑坑一过度依赖模型自主决策。早期我做过一个完全自主的 Agent让它自己决定查什么、怎么查。结果它在简单问题上绕圈子在复杂问题上又漏步骤。后来改成关键步骤固定、细节让模型填稳定性立刻上来了。教训是模型擅长处理模糊不擅长处理流程。坑二忽略 token 成本。有个项目上线第一个月账单超预算三倍排查发现是历史对话没做压缩每轮都把全部历史塞进去。加上摘要压缩后成本降了 60%。这件事让我养成了习惯任何进模型的内容都要问一句这真的必要吗。坑三评估集和线上分布不一致。离线评估通过率 90%上线后用户投诉不断。原因是评估集是我自己造的和真实用户问法差很远。后来改成从线上日志里采样真实问题做评估才反映出真实水平。教训是评估集必须来自真实场景。坑四没有降级方案。有次模型服务商故障整个系统直接不可用。后来加了降级逻辑主模型不可用时切备用模型都不可用时返回缓存结果或引导用户稍后再试。可用性从 99% 提到了 99.9%。5.3 独家避坑技巧第一个技巧是给模型输出加自检环节。让模型在给出答案后自己再检查一遍是否符合要求。这个自检可以是同一个模型做也可以是另一个模型做。实测下来能减少不少低级错误代价是多一次调用。第二个技巧是用结构化输出替代自然语言解析。如果业务需要从模型输出里提取字段尽量用结构化输出能力而不是让模型自由发挥再正则解析。前者稳定得多。第三个技巧是建立 bad case 快速通道。线上发现的问题一键加入评估集下次改动自动回归。这个机制能让系统越用越稳而不是越改越乱。6. 关于 AI Native 架构的一点个人体会做 AI 系统这几年我最大的感受是架构的价值不在于用了多先进的技术而在于把不确定性管理得有多好。传统架构师追求的是设计一个不会出错的系统AI Native 架构师要接受的是系统一定会出错关键是怎么快速发现、优雅兜底、持续改进。所以如果你现在要启动一个 AI Native 项目我的建议是先把评估体系和兜底机制搭起来再去做功能。听起来反直觉但这才是让系统能长期活下去的根基。功能可以慢慢加但如果没有评估和兜底你根本不知道系统是在变好还是变坏。最后分享一个我一直在用的小习惯每次上线新功能前我都会问自己三个问题——模型出错时用户会看到什么我怎么知道它出错了出错后多久能修好这三个问题答不上来功能就先别上。这个习惯帮我躲过了不少线上事故也希望对你有用。