1. 为什么AI Native不是给旧系统加个模型接口这两年AI Native这个词被用得很泛很多团队的做法是在已有的业务系统里塞一个模型调用接口然后对外宣称完成了 AI 化改造。我见过不少这样的项目上线三个月后模型调用量趋近于零因为整个系统的数据流、状态管理、交互方式还是围绕人点按钮设计的模型在里面只是个装饰品。真正的 AI Native 架构核心判断标准只有一条如果把模型从系统里拿掉整个系统是否还能正常运转。如果答案是能只是少了点智能功能那这就是 AI Enhanced不是 AI Native。AI Native 的系统模型是决策中枢是流程的驱动者去掉它系统直接瘫痪。这个区别决定了架构设计的起点完全不同。传统架构里我们设计的是数据怎么存、接口怎么调、页面怎么渲染AI Native 架构里我们首先要设计的是意图怎么表达、上下文怎么组织、模型怎么被约束和验证。前者是确定性的工程问题后者是概率性的系统工程问题。我参与过一个客服工单系统的重构最初版本就是在原有工单流转上加了个AI 自动分类按钮。结果运营发现分类准确率只有 60% 多人工还得复核一遍反而增加了工作量。后来我们把架构反过来做工单进来先由模型理解意图、提取实体、判断优先级、生成处理建议人工只在模型置信度低于阈值时介入。整个工单表结构、状态机、权限模型全部重写。改造后人工介入率降到 18%这才是 AI Native 该有的样子。所以这篇文章不讲怎么调 API讲的是从零开始搭一个以模型为核心的系统时那些真正会卡住你的架构决策点。2. 意图层设计把用户想干什么变成一等公民2.1 传统接口契约和意图契约的本质差异传统系统设计里接口契约是明确的POST /orders带一组固定字段服务端校验字段类型和必填项然后执行。这套东西稳定、可测试、可文档化。但 AI Native 系统面对的是自然语言输入用户说帮我看看上周那个还没发货的订单能不能退这里面包含了时间范围、订单状态、操作意图三个维度的信息而且表达方式千变万化。如果你还想着用正则或者关键词匹配去解析那基本是在给自己挖坑。正确的做法是定义一个意图契约明确系统支持哪些意图类型每个意图需要哪些槽位slot槽位的类型和约束是什么。这个契约不是给用户看的是给模型看的也是给下游执行器看的。我通常会把意图契约写成结构化的 schema比如{ intent: order_refund_query, slots: { time_range: {type: date_range, required: false}, order_status: {type: enum, values: [pending, shipped, delivered], required: false}, order_id: {type: string, required: false} }, fallback: clarify }模型的任务就是把自然语言映射到这个结构上。注意required全是 false因为用户可能只说了一部分信息系统需要有能力追问或者用默认值补全。这个设计思路和传统表单校验完全相反——传统是缺字段就报错AI Native 是缺信息就主动获取。2.2 槽位填充的置信度传播机制意图识别出来只是第一步槽位填充的准确性直接决定后续执行的对错。这里有个容易被忽略的问题槽位的置信度需要向下游传播。举个例子用户说退掉那个贵的模型可能把order_id填成最近一笔高金额订单置信度 0.7。如果下游退款服务不关心这个置信度直接执行万一用户指的是另一笔订单就是资损事故。我的做法是在意图契约里给每个槽位附带置信度执行层根据置信度决定是直接执行、二次确认还是转人工。置信度阈值怎么定没有万能答案但有个经验公式阈值 错误执行的代价 / (错误执行的代价 二次确认的体验损失)。退款这种资损操作阈值可以设到 0.95查询类操作0.6 就够了。这个计算不需要精确但要有意识地去区分不同意图的风险等级。2.3 多轮对话中的意图漂移处理真实场景里用户不会一次把话说清楚。第一轮说我要退款第二轮说算了还是换货吧第三轮又说有没有别的颜色。意图在对话过程中是漂移的如果每轮都独立做意图识别系统会精神分裂。我的处理方式是在会话状态里维护一个意图栈而不是单个当前意图。新意图进来时先判断它是替换栈顶、压栈还是出栈。判断依据是意图之间的语义关联度和用户表达的明确程度。比如算了这种词通常意味着出栈另外意味着压栈。这个逻辑可以用规则做也可以让模型输出一个操作类型实测下来混合方案最稳规则处理高频模式模型兜底长尾情况。3. 上下文工程比提示词重要一百倍的东西3.1 上下文窗口不是越大越好很多人一上来就想把所有相关信息塞进上下文觉得信息越多模型判断越准。实际恰恰相反上下文里塞入无关信息会显著降低模型的表现这个现象在业界被称为lost in the middle——模型对上下文中间部分的信息利用率明显低于开头和结尾。我在做一个合同审查系统时踩过这个坑。最初把整份合同加所有历史修订记录一起塞进去模型经常漏掉关键条款。后来改成两阶段先用检索定位到相关条款段落再把这些段落按重要性排序后放入上下文准确率从 71% 提到 89%。上下文的质量远比数量重要。具体怎么组织上下文我一般按这个优先级排优先级内容类型位置理由1系统指令与约束开头模型对开头指令遵循度最高2当前任务相关事实开头之后紧接指令关联性强3少量示例中间示例是辅助放中间即可4历史对话摘要结尾前提供连续性但不干扰主任务5当前用户输入结尾结尾位置模型注意力集中3.2 动态上下文组装的实际做法静态拼接上下文只能应付 demo生产系统需要动态组装。我的做法是建一个上下文编排器它接收当前意图、会话历史、检索结果、用户画像等输入输出一个经过裁剪和排序的上下文块。编排器的核心逻辑包括去重同一信息不要出现两次、压缩长文档先摘要再放入、时效性加权越新的信息权重越高、冲突检测如果检索结果和用户画像矛盾标记出来让模型注意。这套东西听起来复杂但用简单的规则引擎就能实现 80% 的效果剩下 20% 再用模型做语义压缩。有个细节值得说上下文的 token 预算要留 buffer。我一般按模型最大窗口的 70% 来规划内容剩下 30% 留给模型输出和意外情况。曾经有个项目把上下文塞到 95%结果模型输出被截断返回了半句话下游解析直接崩了。3.3 长期记忆的存储与召回AI Native 系统如果每次对话都从零开始用户体验会很割裂。长期记忆的设计要解决三个问题存什么、怎么存、什么时候取。存什么不是所有对话都值得记。我通常只存三类——用户明确表达的偏好、已经确认的事实、未完成的待办。其他闲聊内容不存避免噪声。怎么存结构化字段存数据库非结构化内容存向量库。比如用户偏好顺丰快递存成{user_id, preference_key: carrier, value: SF}用户上次说家里有只猫存成向量。两者通过 user_id 关联。什么时候取不是每次都全量召回。我的策略是意图驱动召回——当前意图是物流相关就召回配送偏好是售后相关就召回历史工单。这样既保证相关性又控制上下文长度。4. 模型编排单模型打天下是不现实的4.1 什么任务该用什么模型一个 AI Native 系统里通常不会只有一个模型。意图识别可以用小模型甚至微调过的分类模型速度快成本低复杂推理用大模型结构化抽取用专门微调过的模型准确率更高。关键是根据任务特性选型而不是无脑上最大的模型。我一般按这个维度来分延迟敏感 任务简单小模型或规则比如意图粗分类、敏感词检测准确率敏感 可接受延迟中等规模模型比如槽位抽取、情感判断复杂推理 低频调用大模型比如多步规划、复杂问答格式严格 高频调用微调小模型比如固定 schema 的信息抽取成本差异是数量级的。一个每天调用百万次的任务用大模型和小模型的成本可能差两个数量级。架构设计时就要把模型选择做成可配置的方便后续根据效果和成本动态调整。4.2 模型级联与降级策略生产系统必须考虑模型不可用的情况。我的做法是设计模型级联主模型失败或超时自动降级到备用模型备用也失败降级到规则兜底。级联的触发条件要明确超时阈值、错误码、输出格式校验失败、置信度低于阈值。每个条件对应不同的降级路径。比如格式校验失败可以重试一次同模型超时则直接切备用模型。这里有个坑降级不能静默。我见过系统降级到规则后用户完全无感知结果体验断崖式下跌但没人发现。正确做法是降级时记录详细日志并触发告警同时在响应里标记降级状态让前端可以给用户适当的提示。4.3 多模型协作的编排模式复杂任务往往需要多个模型接力。常见的编排模式有三种串行链模型 A 的输出作为模型 B 的输入。适合有明确依赖关系的任务比如先抽取再推理。风险是错误会累积所以每个环节都要有校验。并行投票多个模型同时处理同一任务取多数结果或加权结果。适合对准确率要求极高的场景成本也高。我一般只在关键决策点用比如金额计算。路由分发一个轻量路由器根据输入特征决定交给哪个模型。适合任务类型差异大的场景。路由本身可以用规则或小模型实现。实际系统里这三种模式会混合使用。我的经验是先用最简单的串行链跑通遇到准确率瓶颈再引入并行投票遇到性能瓶颈再引入路由。5. 输出可靠性让概率性系统产出确定性结果5.1 结构化输出的强制约束模型输出是自然语言但下游系统需要结构化数据。这个鸿沟必须填上。最直接的做法是在提示词里要求模型输出 JSON但实测下来模型经常加 markdown 代码块标记、加解释性文字、字段名拼错。我的做法是三层保障第一层提示词里给出严格的 schema 和示例第二层用模型的 structured output 能力如果支持或 JSON mode第三层输出后做 schema 校验失败则触发重试或修复。重试不是简单重发而是把校验错误信息一起发回去让模型修正。比如你上次输出的order_id字段缺失请补充。这样重试成功率能到 90% 以上。5.2 幻觉检测的工程化手段幻觉是概率性系统的固有属性不可能完全消除但可以检测和缓解。工程上我常用这几种手段事实一致性校验模型输出的事实性内容去知识库或数据库里核对。比如模型说订单金额 299 元就去订单表查实际金额。不一致就标记。自洽性检查让模型对同一问题生成多个答案如果答案之间矛盾说明模型不确定需要人工介入。引用溯源要求模型输出时附带信息来源然后校验来源是否真实存在。这个对 RAG 场景特别有效。置信度校准模型自报的置信度往往不准需要用历史数据做校准。我一般会收集一批标注数据拟合一个校准曲线把模型置信度映射到真实准确率。5.3 人机协同的介入点设计AI Native 不等于无人化。合理的架构应该明确哪些环节必须人工介入。我的原则是高风险、低置信、无先例三种情况必须人工。高风险指涉及资金、法律、安全的操作低置信指模型置信度低于阈值无先例指输入模式在训练数据或历史记录中从未出现过。介入点的设计要考虑效率。如果每个低置信都弹窗让人确认人工会被淹没。我的做法是分级置信度 0.8 以上自动执行0.5 到 0.8 之间异步审核不阻塞流程事后抽查0.5 以下同步人工。这样既保证安全又不牺牲效率。6. 数据飞轮让系统越用越聪明6.1 反馈信号的采集设计AI Native 系统的价值在于持续进化而进化的燃料是反馈数据。反馈分显式和隐式显式是用户点赞点踩、修改模型输出隐式是用户采纳了建议、跳过了推荐、重复问了同一个问题。隐式反馈往往比显式更真实因为用户懒得点赞但会用脚投票。我在系统里会埋这些点模型输出的采纳率、用户修改率、任务完成率、平均交互轮次。这些指标下降就是模型退化的信号。采集反馈时要注意不要打断用户。我见过系统每次输出都弹这个回答有帮助吗用户烦到直接关掉。正确做法是把反馈入口做轻比如修改模型输出时自动记录 diff这本身就是最强的反馈信号。6.2 从反馈到模型迭代的闭环采集到反馈只是第一步关键是怎么用。我的闭环是这样的反馈数据先做清洗和标注然后分两类处理——一类是提示词能解决的直接更新提示词模板一类是需要模型能力提升的积累到一定量后做微调。提示词迭代要快我一般每周 review 一次失败案例把高频问题总结成新的提示词约束。微调要慢因为微调成本高且可能引入回归我一般积累到几千条高质量样本才做一次。这里有个反直觉的经验不是所有反馈都值得学。用户的修改不一定对可能是用户自己搞错了。所以反馈数据要经过质量筛选我一般会看修改后的结果是否真的更好比如后续流程是否顺利只保留正向案例。6.3 评估体系的建立没有评估就没有迭代。AI Native 系统的评估比传统系统难因为输出是开放的。我的做法是建三层评估单元评估针对单个模型任务用标注数据集测准确率、召回率。这个可以自动化每次模型或提示词变更都跑。端到端评估模拟真实用户场景测任务完成率、平均轮次、用户满意度。这个需要人工参与频率低一些。在线评估A/B 测试新版本和旧版本同时跑看业务指标差异。这个最真实但成本最高只在大版本更新时做。评估指标要和业务目标对齐。技术指标好不代表业务指标好。我见过模型准确率提升但用户满意度下降的案例因为模型变得更谨慎了动不动就追问用户觉得啰嗦。7. 一些踩过坑之后的实在建议架构设计最怕的是过度设计。我见过团队一上来就搞多模型编排、向量数据库、微调流水线结果三个月没跑通一个完整流程。AI Native 架构的正确打开方式是从最小闭环开始一个意图、一个模型、一个执行器跑通之后再逐步扩展。技术选型上能用现成的不要自己造。向量库、编排框架、评估工具都有成熟方案自研的投入产出比很低。真正需要自研的是业务相关的部分意图契约、上下文编排逻辑、反馈闭环这些是核心竞争力。还有一点很重要给模型的不确定性留出架构空间。传统架构假设每个环节都是确定的AI Native 架构必须假设每个环节都可能出错所以要有校验、重试、降级、人工兜底。这不是不信任模型而是尊重概率性系统的客观规律。最后说个我自己的体会AI Native 架构最难的不是技术是思维方式的转变。从我要系统做什么变成我要系统理解什么从定义流程变成定义约束从消除不确定性变成管理不确定性。这个转变完成了技术方案自然就清晰了。