1. 为什么现在要聊 AI Native 架构过去两年我参与过三个从零起步的 AI 项目也接手过两个传统系统加个 AI 接口的改造项目。这两类项目的体感差异非常大前者迭代速度快、功能边界清晰、模型升级几乎无痛后者每次换模型都像拆炸弹Prompt 散落在业务代码里评测靠人肉点上线靠祈祷。踩过几次坑之后我越来越确信一件事——AI Native 不是用了大模型而是系统的组织方式从第一天起就围绕模型的不确定性来设计。这篇文章想解决的问题很具体如果你现在要起一个新系统或者要把手里的老系统往 AI 方向重构架构上到底该怎么分层、哪些东西必须提前定、哪些坑可以绕开。我会按整体设计思路 → 核心模块拆解 → 落地实操 → 问题排查的顺序讲中间穿插我自己项目里的参数选择过程和真实踩坑记录。适合正在做 AI 应用的后端、算法、全栈同学也适合技术负责人做方案评审时对照检查。文中涉及的工具选型都是基于常见工程实践的合理补充不是唯一答案你可以按自己团队的技术栈替换。先给一个我自己的定义方便后面展开AI Native 系统 以模型推理为核心能力、以 Agent 为编排单元、以数据飞轮为进化机制的应用系统。这三个词分别对应架构里的三层——推理层、编排层、数据层。下面逐层拆。2. 整体架构设计与思路拆解2.1 从AI 增强到AI Native的本质区别很多人把这两个概念混着用但架构上的差别是根本性的。AI 增强型系统的典型结构是业务逻辑是主干AI 是一个被调用的工具函数输入输出都被严格约束在某个函数签名里。这种结构的问题在于模型的能力上限被业务代码的假设锁死了——你写def classify(text) - label模型就只能做分类哪怕它其实能顺便抽取实体、判断情绪、生成回复。AI Native 的思路反过来模型是主干业务逻辑是围绕模型能力边界做的约束和兜底。具体表现为三点差异。第一接口从函数调用变成意图声明你告诉系统我要完成退款处理而不是调用退款分类器。第二状态管理从请求-响应变成会话-记忆Agent 需要跨轮次保持上下文。第三错误处理从抛异常变成降级与重试策略因为模型输出天然有概率性你不能假设它一定返回合法结构。我做过一个对比实验同一个客服场景AI 增强版用规则分类模型AI Native 版用 Agent 编排。前者在标准问题上准确率更高98% vs 91%但遇到没见过的长尾问题时前者直接失败后者能通过工具调用和追问把问题解决掉。长期看AI Native 的维护成本低得多因为新增能力只需要加工具和改 Prompt不用改主干代码。2.2 三层架构的划分逻辑我推荐的骨架是三层加两个横切关注点。三层是推理层、编排层、数据层横切的是可观测性和安全护栏。推理层负责模型调用本身包括模型路由、Prompt 组装、输出解析、缓存。这一层的核心设计目标是可替换——今天用 A 模型明天换 B 模型上层代码不该感知。编排层负责 Agent 的决策循环包括工具注册、任务规划、状态机、多 Agent 协作。数据层负责记忆、检索、评测数据集、反馈回流。为什么这么分因为这三层的变更频率完全不同。推理层可能一周换一次模型版本编排层一个月调一次流程数据层则是持续积累。如果混在一起改一处动全身。我见过最糟糕的设计是把 Prompt 硬编码在业务 Service 里结果换模型时要改几十个文件回归测试跑三天。提示分层不是为了好看是为了让变更半径可控。判断分层是否合理看一个需求改动会波及几层——理想情况是只动一层。2.3 关键选型为什么是 Agent 而不是 Chain早期大家用 Chain固定流程编排现在越来越多转向 Agent动态决策。我的判断标准是任务路径是否可枚举。如果所有可能的执行路径你都能画出来Chain 更稳、更便宜、更好调试。如果路径依赖运行时信息比如用户问题决定要查几个库、要不要追问Agent 更合适。举个具体例子。发票报销审核流程是固定的验真→查重→核对金额→审批。这种用 Chain每步一个函数出错好定位。但帮我分析这份财报里有哪些风险点这种任务路径完全取决于财报内容可能要看现金流、可能要看关联交易、可能要对比同行这种必须用 Agent让它自己决定调哪些工具。实际项目里我经常混用外层用 Agent 做任务规划内层每个子任务用 Chain 保证稳定。这样既有灵活性又不会让整个系统变成不可预测的黑盒。2.4 并发与成本的前置考量AI 系统的并发模型和传统 Web 完全不同。传统接口 QPS 上去了加机器就行AI 系统的瓶颈通常在模型侧——要么是 API 限流要么是自建推理的显存。我踩过的坑是上线前压测只测了 50 并发结果真实流量到 200 时模型 API 直接 429整个系统雪崩。所以架构设计阶段就要定三件事。第一请求队列与背压超过承载能力时是排队还是拒绝要有明确策略。第二语义缓存相同或相似的问题直接返回缓存结果能省掉大量重复推理。第三降级链路模型不可用时是返回兜底话术还是走规则引擎。这三件事我在第 4 节会展开讲具体实现。3. 核心模块拆解与实操要点3.1 推理层模型路由与 Prompt 管理推理层最容易做烂的地方是 Prompt 管理。我见过把 Prompt 写成 Python 字符串拼接的也见过存在数据库里但没版本控制的。正确做法是把 Prompt 当代码管理模板化、版本化、可评测。模板化指的是用占位符而不是字符串拼接比如{user_query}这种好处是能静态检查变量是否齐全。版本化指的是每次改动都有记录能回滚能 A/B 对比。可评测指的是每个 Prompt 版本都要跑一遍评测集看指标变化。模型路由这块我的经验是至少支持三种策略按任务类型路由简单分类用小模型复杂推理用大模型、按成本路由预算内优先便宜模型、按可用性路由主模型挂了自动切备用。实现上可以用一个配置表任务类型首选模型备用模型超时(ms)重试次数意图分类小模型A小模型B8002内容生成大模型A大模型B80001代码补全代码模型大模型A30002向量检索嵌入模型本地嵌入5003这张表要能热更新不能改一次重启一次。我用过最简单的方案是存 Redis配置变更发个消息通知各实例刷新。3.2 编排层Agent 的状态机设计Agent 最容易失控的地方是无限循环——它反复调用同一个工具或者陷入自我怀疑。解决办法是给 Agent 加一个显式状态机而不是让它自由发挥。我的做法是把 Agent 的执行拆成几个明确状态理解意图 → 规划步骤 → 执行工具 → 评估结果 → 决定继续或结束。每个状态有最大执行次数比如规划最多 3 轮工具调用最多 10 次。超过就强制结束并返回当前最好结果。状态机的另一个好处是可观测。每个状态转换都打点出问题时能一眼看出卡在哪。我线上排查过一个 caseAgent 在评估结果状态反复横跳原因是评估 Prompt 写得太模糊模型每次都觉得还不够好。后来把评估标准改成明确的 checklist问题就消失了。工具注册这块我建议用装饰器模式每个工具声明自己的名称、描述、参数 schema、超时时间。描述特别重要因为 Agent 是靠描述来决定调不调这个工具的。描述写得好Agent 的决策质量能提升一大截。tool( namequery_order, description根据订单号查询订单详情包括状态、金额、物流信息。当用户询问订单相关问题时使用。, timeout3000 ) def query_order(order_id: str) - dict: ...3.3 数据层记忆、检索与评测集数据层是 AI Native 系统里最容易被低估的部分。很多人以为接个向量库就完事了实际上记忆要分短期和长期检索要分精确和语义评测集要持续维护。短期记忆是当前会话的上下文通常放 Redis带 TTL。长期记忆是跨会话的用户偏好、历史事实放数据库或向量库。这里有个坑不要把整个对话历史都塞进上下文token 成本高不说还会稀释关键信息。我的做法是做摘要压缩超过 N 轮后把早期对话总结成一段话。检索这块纯向量检索在精确匹配场景下会翻车。比如用户问订单 12345 的状态向量检索可能返回一堆相似订单号。正确做法是混合检索先做关键词/结构化过滤再做语义排序。我一般用BM25 召回 向量召回 重排三段式实测比纯向量召回准确率高 20% 以上。评测集是数据层的灵魂。没有评测集你改 Prompt 就是盲改。我的建议是项目第一天就建评测集哪怕只有 50 条。评测集要覆盖正常 case、边界 case、对抗 case。每次改动跑一遍看准确率、延迟、成本三个指标。3.4 横切关注点可观测性与安全护栏可观测性对 AI 系统比对传统系统更重要因为它的失败模式更隐蔽。传统系统报错有堆栈AI 系统可能成功返回了一个错误答案。所以要记录输入、输出、调用的模型、token 数、延迟、工具调用链、中间状态。我用过的方案是 OpenTelemetry 自定义 span每个 Agent 步骤一个 span能串成完整链路。关键是要能按会话 ID 检索出问题时能复现整个决策过程。安全护栏分输入和输出两侧。输入侧做 Prompt 注入检测、敏感信息过滤。输出侧做格式校验、内容审核、事实性检查。这里要强调护栏不能只靠 Prompt 让模型自觉遵守必须有代码层面的硬校验。比如要求输出 JSON就要用 schema 校验不合法就重试或降级。4. 从零搭建的实操过程4.1 环境准备与技术栈选择假设我们从零起一个 AI Native 的客服系统。技术栈我推荐Python 做推理和编排生态最全FastAPI 做接口层Redis 做缓存和短期记忆PostgreSQL pgvector 做长期记忆和检索Celery 或类似方案做异步任务。为什么用 pgvector 而不是专用向量库因为中小规模百万级以下场景pgvector 够用而且省了一套运维。等数据量上去了再迁专用库也不迟。我见过一上来就上分布式向量库的结果运维成本比业务开发还高。模型侧我建议至少接两家 API避免单点。自建推理的话先评估显存和并发需求别盲目上。一个 7B 模型在单卡上跑并发也就几十撑不住生产流量。4.2 第一步搭推理层的最小闭环先别急着做 Agent先把输入→模型→输出跑通。这一步的目标是验证模型能力边界同时把 Prompt 管理、模型路由、日志打点这些基础设施搭好。具体步骤定义 Prompt 模板文件写一个 ModelClient 封装调用加缓存层加日志。缓存这块要注意 key 的设计我一般用hash(model prompt params)相同请求直接返回。实测在客服场景下缓存命中率能到 30% 左右省不少钱。参数选择上温度temperature是关键。分类任务用 0生成任务用 0.7 左右需要创意的用 1.0。max_tokens 要设合理上限别让它无限生成。超时时间按任务定分类 1 秒生成 10 秒。4.3 第二步接入编排层与工具推理层稳了之后开始做 Agent。先定义工具集从最核心的几个开始比如查订单、查物流、退款申请。每个工具写好描述和参数 schema。然后写 Agent 主循环。我的实现是一个 while 循环每轮把当前状态和工具列表给模型模型返回下一步动作调工具还是给答案执行动作更新状态检查是否结束。循环上限设 10 轮防止死循环。这里有个实操细节工具返回结果要截断。比如查订单返回一个巨大的 JSON直接塞回上下文会爆 token。我的做法是只保留关键字段或者做摘要。这个截断逻辑要写在工具封装里不要让 Agent 自己处理。4.4 第三步数据层与评测集建设记忆和检索这块先做短期记忆会话上下文再做长期记忆用户画像。短期记忆用 Redis list 存每轮 append超过长度做摘要。长期记忆用 pgvector 存用户历史交互的 embedding检索时按相似度召回。评测集建设我建议用真实日志 人工标注的方式。上线后把真实请求采样人工标注期望输出逐步积累。初期可以自己造 50-100 条覆盖主要场景。评测脚本要能一键跑输出准确率、平均延迟、平均 token 消耗。4.5 第四步上线与灰度上线别一把梭。先小流量灰度比如 5%观察一周。重点看三个指标任务完成率、平均轮次、用户满意度如果有反馈入口。发现问题及时回滚 Prompt 或模型版本。灰度期间要特别关注沉默失败——用户没报错但问题没解决。这种要靠人工抽检日志发现。我一般每天抽 50 条对话人工看连续看一周能发现很多自动化指标看不出的问题。5. 常见问题与排查技巧实录5.1 Agent 陷入循环怎么办这是最高频的问题。表现是 Agent 反复调同一个工具或者在不同工具间来回跳。排查思路先看日志里每轮的决策找出循环的起点。常见原因有三个工具描述有歧义Agent 不确定该用哪个、工具返回结果不明确Agent 觉得没拿到想要的信息、评估 Prompt 太宽松Agent 觉得还没完成。解决办法工具描述加何时使用/何时不使用的说明工具返回加明确的成功/失败标识评估 Prompt 改成明确的完成条件 checklist。另外加硬性轮次上限兜底。5.2 模型输出格式不稳定要求 JSON 但偶尔返回带 markdown 代码块的或者字段名对不上。这是概率性问题不能靠 Prompt 根治。我的做法是用支持结构化输出的模型能力如果有加 schema 校验校验失败自动重试最多 2 次还失败就走降级逻辑。重试时把错误信息也带上让模型知道哪里错了。5.3 并发上不去、延迟高先定位瓶颈在哪一层。如果是模型 API 限流加队列和背压如果是自建推理显存不够减 batch size 或换小模型如果是检索慢加索引或缓存。我遇到过一次延迟高排查半天发现是日志同步写磁盘拖慢了主流程改成异步写就好了。5.4 常见问题速查表问题现象可能原因排查方向解决手段Agent 循环工具描述歧义/评估太宽看决策日志改描述加轮次上限格式不稳定模型概率性输出看失败样本schema校验重试降级延迟高瓶颈定位不清分层打点队列/缓存/异步化成本超预算无缓存/模型选型不当看token统计语义缓存模型路由答案不准检索质量差看召回结果混合检索重排上下文爆token历史全塞看上下文长度摘要压缩截断5.5 几个我踩过的坑第一个坑过早优化 Prompt。项目初期花大量时间调 Prompt结果模型一升级全白费。正确做法是先把架构搭好Prompt 用最朴素的版本等架构稳定了再优化。第二个坑忽略 token 成本。上线第一个月账单超预算三倍原因是没做缓存而且把整个知识库都塞进上下文。后来改成按需检索成本降了 70%。第三个坑评测集和线上分布不一致。评测集是自己造的都是标准问题线上全是长尾。后来改成从线上采样评测才有意义。第四个坑没有降级链路。模型 API 挂了一次整个系统不可用。后来加了规则引擎兜底至少能回答常见问题。6. 一些个人体会做 AI Native 架构这两年我最大的感受是它的难点不在 AI在架构。模型能力每年都在涨但架构设计的基本原则——分层、解耦、可观测、可降级——是不变的。把传统分布式系统的经验迁移过来再针对模型的不确定性做特殊处理基本就能搭出一个能用的系统。另外一点是别追求一步到位。我见过太多团队想一开始就设计一个完美的 Agent 框架结果三个月没上线。正确的节奏是先跑通最小闭环再逐步加能力每一步都有评测和灰度。架构是演化出来的不是设计出来的。最后分享一个我常用的判断标准如果你换一个模型需要改动的代码超过 10 行说明架构有问题。好的 AI Native 架构换模型应该只是改配置。这个标准帮我发现过好几次设计缺陷你也可以拿来检验自己的系统。