★ FEATURED ARTICLE 1. 为什么现在必须重新思考系统架构的起点过去十多年我们做系统架构的默认路径几乎没变过先定数据库表结构再写服务层然后暴露 API最后前端对接。这套流程在“人操作界面、界面调用接口、接口读写数据库”的范式下运转得很好。但最近两年我参与的几个项目都遇到了同一个尴尬系统上线后业务方第一句话不是“功能好不好用”而是“能不能让 AI 直接帮我处理这件事”。这时候回头一看我们的架构里 AI 只是一个外挂模块——单独部署一个推理服务通过 HTTP 调用数据要来回搬运上下文要手动拼装权限要重新做一套。改造成本极高体验还割裂。AI Native 架构要解决的就是这个根本问题不是“在系统里加 AI”而是“从第一行代码开始就把 AI 当作系统的核心参与者来设计”。这意味着数据流、控制流、状态管理、权限模型、可观测性全部要围绕“AI 可能参与每一个环节”这个前提来重新组织。它适合谁参考我认为三类人最需要一是正在做新系统从零搭建的技术负责人二是手里有存量系统但被业务逼着做智能化改造的架构师三是想理解“AI 原生”到底和“AI 集成”有什么区别的开发者。这篇文章不打算讲空泛的概念。我会按一个真实项目从零搭建的顺序把每个阶段的关键决策、参数选择、踩过的坑和验证过的做法都摊开说。你不需要有 AI 算法背景但需要对后端架构、数据流和基本的大模型调用方式有概念。读完你至少能判断自己的系统适不适合走 AI Native 路线如果走第一步该动哪里。2. 整体设计思路把 AI 当作“一等公民”而不是“外部服务”2.1 传统 AI 集成与 AI Native 的本质区别先把这个核心问题说透不然后面所有设计都会走偏。传统做法我称之为“AI as a Service”业务系统正常运转遇到需要智能处理的节点时调用一个独立的 AI 服务。这个 AI 服务通常有自己的数据存储、自己的鉴权、自己的日志。好处是解耦坏处是上下文断裂——AI 看不到业务系统的实时状态业务系统也不清楚 AI 内部发生了什么。AI Native 的做法是“AI as a Participant”AI 能力不是某个外部接口而是系统内部的一种可编排的处理单元。它和普通业务逻辑一样能读取系统状态、能写入处理结果、能触发后续流程。区别只在于它的“计算方式”是模型推理而不是确定性代码。这个定位一变架构上的连锁反应非常大。我画不出图但可以用一个类比传统集成像是公司请了一个外部顾问每次有问题就打电话问顾问看不到公司内部系统只能靠你口述AI Native 像是公司内部设了一个顾问工位他能直接查系统、看报表、在权限范围内直接操作。显然后者的响应速度和准确度完全不是一个量级。2.2 核心设计原则上下文优先、状态可追溯、能力可编排基于上面这个定位我总结了三条必须贯穿始终的原则。上下文优先。AI 的输出质量极度依赖输入上下文。传统集成里上下文是调用方临时拼的往往残缺。AI Native 要求系统在任何 AI 参与节点都能自动组装出完整、结构化、带元数据的上下文。这意味着数据模型设计时就要考虑“哪些字段是 AI 需要的”而不是事后补。状态可追溯。AI 的决策过程是概率性的出了问题必须能回放。所以每一次 AI 参与的处理都要记录输入上下文快照、模型版本、关键参数、输出结果、后续动作。这不是可选项是必选项。我见过太多项目上线后 AI 偶尔“抽风”但因为没有完整日志根本查不出原因。能力可编排。AI 能力不能写死在代码里。今天用这个模型做摘要明天可能换一个今天这个节点需要 AI明天可能规则就够了。所以 AI 调用要抽象成可配置的“能力单元”通过编排层决定在什么条件下、用什么模型、传什么上下文、结果怎么用。2.3 技术选型背后的取舍逻辑选型这块我不给具体产品名给判断标准。模型层优先考虑推理延迟可控和输出格式稳定。很多团队一上来追求最强模型结果延迟 3 秒以上交互体验直接崩。我的经验是交互式场景延迟超过 1.5 秒就要考虑流式输出或降级策略批处理场景可以放宽到 10 秒以上。存储层AI Native 系统需要同时处理结构化业务数据和非结构化上下文数据。我的做法是业务数据继续用关系库上下文和 AI 处理记录用文档型存储两者通过业务 ID 关联。不要试图用一套存储解决所有问题那是给自己挖坑。编排层轻量优先。早期不要上重型工作流引擎一个配置表加一个执行器就够。等流程复杂到配置表管不住了再升级。我见过团队一开始就上复杂编排框架结果 80% 的功能用不上维护成本还高。3. 核心细节解析数据流、上下文与权限的重新设计3.1 数据模型要为 AI 预留“上下文视图”传统数据模型是给人和业务逻辑看的字段命名和结构都偏业务语义。AI 需要的是语义完整、冗余适度、带时间戳和来源标记的上下文。这两者不冲突但需要在设计时多走一步。我的做法是在核心业务实体上增加一个“上下文投影”层。比如一个订单实体业务表里存的是订单号、金额、状态、客户 ID。上下文投影会把它扩展成订单基本信息、客户历史行为摘要、当前处理阶段、最近三次交互记录、相关规则说明。这些数据大部分是派生出来的不额外存储而是在需要时由投影层实时组装。这样做的好处是AI 拿到的上下文是标准化的不需要每个调用点自己拼业务表保持干净不被 AI 需求污染。代价是投影层需要维护但相比在每个调用点写拼装逻辑维护成本低得多。3.2 上下文组装的三个关键参数组装上下文时有三个参数必须显式控制否则要么信息不足要么 token 爆炸。时间窗口。上下文不是越多越好。我的经验是交互式场景取最近 5 到 10 轮相关记录批处理场景取最近 30 天但做摘要压缩。时间窗口要可配置不同场景用不同值。相关性阈值。不是所有关联数据都值得放进上下文。我会给每个数据源算一个相关性分数低于阈值的直接丢弃。阈值初期可以设低一点观察 AI 输出质量后再调。Token 预算。这是硬约束。我通常把单次调用的上下文控制在模型最大 token 的 60% 以内留出空间给输出和系统提示。超预算时按优先级截断核心业务数据优先历史交互其次规则说明最后。3.3 权限模型AI 的权限必须比人更细这是最容易被忽视但最危险的地方。传统系统里权限是给人设计的角色、资源、操作。AI 参与后权限粒度必须更细因为 AI 可能在不该读的时候读了数据或者在不该写的时候写了数据。我的做法是给 AI 单独一套权限标识和用户权限解耦。AI 的每一次数据访问都带三个标记触发者身份是谁发起的、AI 能力标识用的是哪个能力单元、数据敏感级别。访问控制层根据这三个标记决定是否放行。比如一个普通用户触发的摘要能力只能读该用户有权限的数据一个系统定时触发的分析能力可以读聚合数据但不能读个人明细。注意千万不要让 AI 继承调用者的全部权限。调用者可能是一个高权限管理员但 AI 能力本身只需要读某几个字段。按最小必要原则授权出问题时影响面可控。4. 实操过程从零搭建一个 AI Native 系统的关键步骤4.1 第一步定义 AI 参与点而不是先写代码项目启动后不要急着建工程。先做一件事把业务流程从头到尾过一遍标记出所有“需要判断、生成、总结、分类、提取”的节点。这些就是候选的 AI 参与点。标记时用统一格式节点名称、输入是什么、期望输出是什么、失败时怎么办、延迟要求多少。我通常会用一张表管理类似这样节点名称输入期望输出失败降级延迟要求工单分类工单标题描述分类标签默认标签800ms回复建议工单上下文建议文本不显示建议1.5s日报摘要当日处理记录摘要段落显示原始列表5s这张表就是后续所有设计的依据。没有它你会陷入“哪里都想加 AI哪里都加不好”的困境。4.2 第二步搭建上下文组装服务这是 AI Native 架构里最核心的基础设施。它对外暴露一个简单接口传入业务实体 ID 和场景标识返回组装好的上下文对象。实现上分三层。数据采集层负责从各个业务库拉取原始数据注意这里要用只读连接避免影响业务。投影转换层把原始数据转成 AI 友好的格式比如把状态码转成自然语言描述把时间戳转成相对时间。预算控制层做 token 估算和截断确保不超预算。我实测下来这个服务用最简单的同步实现就够不要一上来搞异步消息队列。上下文组装通常在 50ms 内完成不值得为它引入复杂度。等 QPS 上来了再优化。4.3 第三步实现能力单元与编排执行器能力单元是 AI 调用的封装。每个单元包含提示词模板、模型参数、输入输出格式定义、降级策略。提示词模板不要硬编码在代码里放配置文件或数据库方便调整。编排执行器负责按流程调用能力单元。我的做法是用一个简单的状态机每个节点定义前置条件、执行动作、后置处理。执行器按顺序跑遇到 AI 节点就调对应能力单元。状态机配置用 JSON 存改流程不用重新部署。这里有个关键细节AI 节点的输出必须做格式校验。模型可能返回不符合预期的格式执行器要能识别并触发降级。我通常要求能力单元的输出要么是严格 JSON要么是带明确分隔符的文本校验失败就走降级路径。4.4 第四步建立可观测性体系AI Native 系统的可观测性和传统系统不同。除了常规的请求量、延迟、错误率还要记录上下文命中率有多少请求成功组装了完整上下文、降级触发率AI 失败走降级的比例、输出采纳率AI 输出被最终使用的比例。输出采纳率这个指标特别重要。它直接反映 AI 到底有没有产生价值。我见过系统 AI 调用量很大但采纳率不到 10%说明大部分调用是无效的。这时候要么优化提示词要么重新评估这个节点该不该用 AI。日志方面每次 AI 调用记录完整快照输入上下文、模型版本、参数、原始输出、校验结果、最终动作。存储上可以用文档库按时间分区保留 30 到 90 天。查询时按业务 ID 或追踪 ID 检索。5. 常见问题与排查技巧实录5.1 上下文组装超时或数据缺失这是上线初期最常见的问题。表现是 AI 输出质量不稳定有时很好有时很差。排查时先看上下文组装日志重点检查两个地方数据源响应时间和空值率。数据源响应慢通常是查询没走索引或者关联了太多表。我的经验是上下文组装涉及的查询必须单独优化不能复用业务查询。空值率高说明投影逻辑有漏洞某些字段在特定状态下取不到值。这时候要么补默认值要么调整投影逻辑。实操心得给上下文组装服务加一个“调试模式”传入业务 ID 后返回完整上下文和每个字段的来源。排查问题时直接看比翻日志快得多。5.2 AI 输出格式不稳定导致解析失败模型输出格式漂移是常态尤其是免费或小参数模型。解决方法分三层提示词里明确格式要求并给示例输出后用正则或 JSON 解析器校验校验失败时重试一次再失败走降级。重试时不要原样重发要在提示词里加上“上次输出格式错误请严格按示例格式返回”。我实测这个技巧能把重试成功率提高不少。如果某个能力单元频繁格式失败考虑换模型或调整温度参数。温度设 0 到 0.3 之间格式稳定性明显更好。5.3 延迟波动大影响用户体验AI 调用延迟天然有波动。解决思路是分级降级延迟超过阈值一切换到更小更快的模型超过阈值二直接走规则降级超过阈值三返回兜底结果。阈值设定要看场景。交互式场景我通常设 800ms 和 1.5s 两档。批处理场景可以放宽到 5s 和 10s。关键是降级要快不能让用户干等。流式输出也是好办法首 token 返回后用户就有感知整体等待感会降低很多。5.4 常见问题速查表问题现象可能原因排查动作解决方向AI 输出质量忽好忽坏上下文不完整查组装日志空值率补投影逻辑或默认值格式解析频繁失败提示词不明确看原始输出加格式示例降温度延迟突然升高模型服务波动看分模型延迟切备用模型或降级采纳率持续偏低场景不适合 AI看采纳率趋势重新评估节点或优化提示词权限报错增多AI 权限配置过严查权限日志按最小必要调整授权5.5 几个我踩过的坑第一个坑早期把提示词写在代码里改一次要发版。后来全部外置到配置中心改提示词实时生效迭代速度完全不一样。第二个坑没有做输出采纳率统计上线一个月都不知道 AI 到底有没有用。后来补上这个指标发现两个节点采纳率不到 5%直接下线省了资源还减少了故障面。第三个坑AI 权限直接复用了调用者权限结果一个管理员触发的批量操作让 AI 读到了大量敏感数据。后来改成独立权限模型按能力单元授权问题才解决。6. 关于 AI Native 架构的个人体会这套架构我完整落地过两个项目一个是从零新建一个是在存量系统上改造。新建的项目从第一天就按 AI Native 设计后期加 AI 能力基本是配置工作一两天就能上线一个节点。存量改造那个就痛苦得多数据模型、权限、日志都要动前后花了三个月才达到可接受的状态。所以我的建议很明确如果系统还没建或者还在早期一定要按 AI Native 的思路设计如果已经跑了好几年先挑一两个独立场景试点验证价值后再逐步扩展。还有一个体会是关于团队能力的。AI Native 架构对开发者的要求不是“会调模型”而是“会设计上下文”和“会做降级”。这两件事听起来简单做起来需要大量实践。我通常会让团队先在一个非核心场景练手把上下文组装、格式校验、降级、可观测性这套流程跑通再上核心业务。最后分享一个实用技巧给每个 AI 能力单元设一个“影子模式”。新能力上线时先不真正使用输出只记录如果用了会是什么结果。跑一周后对比采纳率和人工判断确认没问题再切正式模式。这个做法帮我避免了好几次线上事故强烈推荐。
阅读完成 · 觉得有帮助？
