★ FEATURED ARTICLE 1. 为什么现在要聊 AI Native 架构过去两年我参与过三个从零起步的 AI 项目也接手过两个“传统系统加挂 AI 模块”的改造项目。这两类项目的体感差异非常大前者迭代速度快、代码量少、上线周期短后者则经常陷入“模型效果不错但系统跑不起来”的泥潭。这个差异的根源就在于系统到底是AI Native还是AI Enabled。AI Native 架构的核心含义是把 AI 能力当作系统的第一等公民而不是事后挂上去的插件。传统架构里业务逻辑是主干AI 是一个被调用的工具函数AI Native 架构里模型推理、上下文管理、工具调用、记忆存储这些能力本身就是主干的一部分业务逻辑反而更像是编排层。这个思路的转变直接决定了你后面所有的技术选型、目录结构、部署方式和迭代节奏。这篇文章适合三类人看第一类是从零开始做 AI 产品的开发者想知道怎么搭架子才不至于三个月后推倒重来第二类是做过后端或全栈、想转 AI 应用方向的工程师需要一套可落地的架构参照第三类是技术负责人需要判断团队现有的架构能不能撑住 AI 功能的持续迭代。我会把整体设计思路、核心模块拆解、实操步骤、参数选择依据和踩过的坑都讲清楚尽量做到你读完能直接照着搭。需要先说明一点AI Native 不等于“全部用大模型”。很多团队一上来就把所有逻辑塞给模型结果成本失控、延迟爆炸、输出不稳定。真正合理的做法是能确定性解决的绝不交给模型模型只负责它真正擅长的部分——语义理解、生成、模糊匹配、决策编排。这条原则会贯穿全文。2. AI Native 架构的整体设计与思路拆解2.1 从“业务驱动”到“能力驱动”的思维切换传统后端架构的思考起点是“业务有哪些实体、哪些流程”然后设计表结构、接口、服务边界。AI Native 架构的思考起点不一样它先问的是“这个系统需要哪些 AI 能力”比如意图识别、内容生成、工具调用、长期记忆、多轮规划然后再围绕这些能力去组织数据流和存储。我举个具体例子。做一个智能客服系统传统思路是先设计工单表、用户表、会话表然后在回复环节调用一次模型接口。AI Native 思路则是会话本身就是核心数据结构每一轮对话都要考虑上下文窗口怎么管理、历史记忆怎么检索、工具查订单、退款怎么被模型自主调用、模型输出怎么校验。你会发现数据模型的重心从“业务实体”偏向了“上下文与状态”。这个切换带来的直接好处是扩展性。当你要加一个新能力比如“根据用户情绪调整回复语气”在 AI Native 架构里只是往上下文组装层加一个模块在传统架构里你可能要改好几个服务的接口。2.2 分层设计把不确定性关进笼子AI 系统最大的工程挑战是不确定性。同样的输入模型可能给出不同输出网络抖动会导致推理超时上下文超长会导致效果骤降。所以 AI Native 架构的分层目标很明确把不确定性集中到少数几层其他层保持确定性。我通常分成五层接入层负责鉴权、限流、请求路由完全确定性。编排层决定这次请求要走哪条链路是直接回答、调用工具还是走多步规划。这一层有少量不确定性但可以用规则兜底。能力层模型推理、向量检索、工具执行。不确定性主要集中在这里。记忆与状态层短期上下文、长期记忆、会话状态。要求强一致性和可追溯。可观测层日志、追踪、评测。这一层是 AI 系统能不能持续迭代的生命线很多团队前期忽略后期吃大亏。这样分层的意义在于当模型出问题时你能快速定位是编排逻辑错了、检索召回差了还是模型本身不行。如果所有逻辑糊在一起排查就是灾难。2.3 为什么选择“编排优先”而不是“模型优先”市面上有两种主流做法。一种是模型优先把尽可能多的逻辑写进 prompt让模型自己决定一切。另一种是编排优先用代码控制流程模型只在关键节点介入。我实测下来编排优先在工程上稳得多。原因有三点。第一可测试性。编排逻辑是代码可以写单元测试纯 prompt 逻辑很难做回归测试。第二成本可控。编排层可以在调用模型前做缓存、做短路避免不必要的推理。第三可解释性。出问题时你能看到每一步的输入输出而不是面对一个黑盒。模型优先也不是没用它适合探索期快速验证想法。但一旦要上生产我建议逐步把关键路径迁移到编排优先的结构上。2.4 关键选型背后的考量选型这块我列个表把常见决策点和我的建议说清楚。决策点常见选项我的建议理由模型调用方式直连 API / 自建推理服务前期直连量大后自建前期省运维量大后成本和延迟都可控上下文存储内存 / Redis / 数据库Redis 做热数据数据库做持久化兼顾速度和可追溯向量检索专用向量库 / 关系库扩展数据量小于百万用关系库扩展即可减少组件降低运维复杂度编排方式硬编码 / 配置化 / 图编排中等复杂度用配置化复杂用图编排平衡灵活性和可维护性工具调用模型自主 / 规则触发关键操作规则触发查询类可自主涉及写操作必须可控这张表不是标准答案但能帮你避开最常见的过度设计。我见过太多团队一上来就上向量数据库集群、上复杂的图编排框架结果业务还没跑通运维已经压垮了。3. 核心模块拆解与实操要点3.1 上下文管理AI Native 的“内存管理”上下文管理是 AI Native 架构里最容易被低估的模块。很多人以为就是把历史消息拼起来发给模型实际上这里面有很多讲究。首先要区分短期上下文和长期记忆。短期上下文是当前会话的最近若干轮对话直接进 prompt。长期记忆是跨会话的用户偏好、历史事实需要通过检索按需注入。我一般给短期上下文设一个 token 预算比如总窗口的 60%剩下的留给长期记忆和工具返回结果。其次是上下文压缩。当对话轮数多了不能简单截断否则会丢失关键信息。我的做法是保留最近 N 轮原文更早的对话用模型做一次摘要摘要结果作为一条系统消息注入。摘要的 prompt 要明确要求保留“用户明确表达的偏好、已确认的事实、未完成的待办”。注意摘要本身也是一次模型调用要计入成本。我一般设置一个阈值比如超过 20 轮才触发摘要避免频繁调用。还有一个细节是上下文的顺序。实测下来把最重要的信息放在 prompt 的开头和结尾模型召回效果更好。中间部分容易被“淹没”。所以工具返回结果、检索到的记忆我会根据重要性做位置编排。3.2 工具调用让模型“动手”的边界控制工具调用是 AI Native 系统区别于聊天机器人的关键。但工具调用也是最容易出事故的地方。我的原则是读操作可以放开写操作必须收紧。具体怎么做把工具分成三类查询类查天气、查订单、查文档。这类可以让模型自主决定调用风险低。计算类调计算器、调代码执行。这类要限制资源比如超时时间、内存上限。写入类下单、发消息、改数据。这类必须经过规则校验或人工确认不能让模型直接执行。工具的描述description也很关键。模型是根据描述来决定调不调、怎么调的。描述要写清楚这个工具做什么、参数含义、什么情况下用、什么情况下不用。我踩过的坑是描述写得太简略模型经常在不该调用的时候调用或者参数传错。# 工具定义示例伪代码展示结构 tool_register( namequery_order, description根据订单号查询订单状态。仅当用户明确提供了订单号时调用。 如果用户没有提供订单号先询问不要猜测。, parameters{ order_id: {type: string, required: True, description: 用户提供的订单号通常是数字串} }, handlerquery_order_impl, categoryread # 标记为读操作允许自主调用 )工具返回结果也要处理。模型对结构化数据的理解不如对自然语言的理解所以我会把工具返回的 JSON 转成一段简短的文字描述再喂给模型效果明显更好。3.3 记忆系统从“无状态”到“有状态”传统 Web 服务是无状态的AI Native 系统必须有状态否则每次对话都从零开始体验很差。记忆系统我一般分三层会话级记忆当前会话的上下文存在 Redis设置过期时间。用户级记忆跨会话的偏好和事实存在数据库通过向量检索召回。全局知识产品文档、FAQ存在向量库所有用户共享。用户级记忆的写入要谨慎。不是所有对话内容都值得记。我的做法是在每轮对话结束后用一个轻量模型判断“这轮对话是否包含值得长期记住的信息”如果有抽取成结构化的事实存起来。比如“用户说他住在杭州”就存成{user_id, key: city, value: 杭州}。提示记忆的召回要设相关性阈值。我见过系统把不相关的记忆也注入上下文反而干扰了模型判断。宁可少召回不要乱召回。3.4 可观测与评测让迭代有据可依这一块是很多团队的短板。AI 系统的输出没有绝对的对错所以评测不能靠传统断言。我的做法是建立三层观测第一层是请求级日志每次请求的输入、输出、耗时、token 消耗、调用了哪些工具全部落库。这是排查问题的基础。第二层是质量评测定期抽样一批请求用模型或人工打分看回复质量、工具调用准确率、幻觉率。我一般每周跑一次跟踪趋势。第三层是线上反馈用户点赞点踩、追问率、会话中断率。这些是真实信号比离线评测更有价值。有了这三层你才能回答“这次 prompt 改动到底有没有变好”这个问题。没有评测的 AI 迭代就是盲人摸象。4. 从零搭建的完整实操流程4.1 项目骨架与目录结构我建议的目录结构是这样的核心思想是按“能力”而不是按“技术层”组织project/ app/ api/ # 接入层路由和鉴权 orchestrator/ # 编排层决定请求走哪条链路 capabilities/ # 能力层 llm/ # 模型调用封装 retrieval/ # 检索 tools/ # 工具实现 memory/ # 记忆与状态 observability/ # 日志、追踪、评测 configs/ # 配置包括 prompt 模板 tests/ # 测试包括编排逻辑的单元测试为什么按能力分而不是按 controller/service/dao 分因为 AI 系统的变更往往集中在某个能力上比如优化检索、调整 prompt。按能力分改动范围清晰也方便不同人负责不同能力。4.2 模型调用封装的关键参数模型调用不要散落在各处一定要封装成一个统一入口。封装时要处理这几件事超时与重试设置合理超时比如 30 秒。重试要区分错误类型网络错误可重试参数错误不要重试。降级主模型不可用时切到备用模型或返回兜底话术。成本统计每次调用记录 token 数方便算账。参数默认值temperature、max_tokens 这些给合理默认业务层可以覆盖。# 模型调用封装示意 def call_llm(messages, modeldefault, temperature0.7, max_tokens1024, timeout30): # 1. 检查缓存 # 2. 组装请求 # 3. 调用带超时和重试 # 4. 记录 token 消耗和耗时 # 5. 返回结果 ...temperature 的选择有讲究。需要稳定输出的场景比如工具参数抽取用 0 到 0.3需要创意生成的场景用 0.7 到 1.0。我见过有人所有场景都用默认值结果要么太死板要么太飘。4.3 编排逻辑的实现方式编排逻辑我推荐从简单的 if-else 开始不要一上来就上图编排框架。大部分场景用状态机或者简单的条件分支就够了。一个典型的编排流程是这样的接收用户输入做预处理敏感词过滤、意图初判。判断是否需要检索记忆或知识库。组装上下文调用模型。判断模型输出是否包含工具调用意图。如果有执行工具把结果回填再次调用模型。校验最终输出返回。这个流程用代码写出来大概几十行清晰可控。等流程复杂到分支爆炸再考虑引入编排框架。注意编排逻辑一定要写单元测试。把模型调用 mock 掉测试各种分支是否走对。这是保证系统稳定的关键。4.4 部署与扩容的实操建议AI Native 系统的部署和传统服务有区别主要在于对 GPU 和外部 API 的依赖。前期我建议无状态服务 外部 API的组合。应用服务本身无状态可以随意扩容模型能力走外部 API省去 GPU 运维。等量大了再把高频调用的模型迁到自建推理服务。扩容时要关注两个指标并发请求数和token 吞吐。前者决定应用服务实例数后者决定模型服务容量。我一般给模型调用设一个并发上限超过就排队或降级避免雪崩。缓存也很重要。相同或相似的请求可以缓存结果。我实测下来客服类场景缓存命中率能到 20% 到 30%直接省下这部分成本。5. 常见问题与排查技巧实录5.1 模型输出不稳定的排查思路这是最高频的问题。排查顺序我一般是先看 temperature 是不是设高了。再看上下文是不是太长导致关键信息被淹没。然后看 prompt 是不是有歧义指令是否明确。最后才怀疑模型本身。大部分“模型不行”的问题其实是 prompt 或上下文的问题。我建议每次改动只改一个变量然后跑评测对比否则你根本不知道是哪个改动起了作用。5.2 工具调用出错的典型场景工具调用出错主要有三种该调没调、不该调乱调、参数传错。该调没调通常是工具描述不够清晰或者上下文里没有足够信息让模型判断。解决办法是把“什么情况下调用”写进描述。不该调乱调通常是工具描述太宽泛或者模型过度积极。解决办法是加约束比如“仅当用户明确要求时调用”。参数传错通常是参数描述不清晰或者模型对格式理解有偏差。解决办法是给参数加示例并在工具实现里做校验传错就返回明确错误让模型重试。5.3 上下文超长的处理策略上下文超长会导致效果下降和成本上升。我的处理策略按优先级先做历史摘要压缩早期对话。再做检索只注入相关的长期记忆。然后做工具结果精简只保留关键字段。最后才考虑截断且从最不重要的部分截。截断是下策因为可能丢掉关键信息。我一般把截断作为最后兜底。5.4 常见问题速查表现象可能原因排查方向解决建议回复答非所问上下文污染 / prompt 歧义检查注入的记忆和工具结果精简上下文明确指令工具调用失败参数格式错 / 工具不可用看工具返回的错误信息加参数校验加重试响应慢模型调用慢 / 串行调用多看各环节耗时并行化加缓存成本高上下文太长 / 无缓存统计 token 消耗压缩上下文加缓存输出格式乱prompt 没约束格式检查输出解析逻辑明确格式要求加解析兜底5.5 我踩过的几个坑第一个坑是过早引入复杂框架。一开始就上图编排、上向量库集群结果调试困难进度反而慢。后来退回到简单实现先把业务跑通再逐步替换效率高很多。第二个坑是忽略评测。早期靠感觉调 prompt改来改去不知道有没有变好。后来建了评测集每次改动跑一遍迭代方向才清晰。第三个坑是记忆写入太随意。什么都往长期记忆里塞导致召回时噪音大。后来加了写入判断和相关性阈值效果明显改善。第四个坑是没有降级方案。模型服务抖动时整个系统不可用。后来加了备用模型和兜底话术可用性上了一个台阶。6. 关于迭代节奏的一点个人体会搭 AI Native 系统我的体会是先跑通再优化先确定性再智能化。不要一上来就追求完美的架构因为 AI 领域变化太快今天的“最佳实践”可能下个月就过时了。把核心链路搭稳把可观测和评测建起来剩下的就是持续迭代。另外团队协作上prompt 和编排逻辑应该像代码一样管理进版本控制、有 review、有测试。我见过把 prompt 散落在各处、改了就上线的团队出问题根本追溯不了。这一点值得每个做 AI 应用的团队重视。最后分享一个实用技巧给每个能力模块设一个“开关”。线上出问题时能快速关掉某个能力比如关掉工具调用只保留纯对话把影响面控制住。这个开关在关键时刻能救命。
阅读完成 · 觉得有帮助？
