这两年我一直在做以 LLM 为核心的业务系统最大的感触是国内聊架构的人很多但真正落地 AI Native 的少。多数团队做的是系统里塞个 AI 接口而不是从零开始以 AI 为核心构建系统。这个差别往小了说是技术选型不同往大了说是整个研发范式都要变。我先后主导过几个 AI Native 方向的项目从最初在传统系统上打补丁、接大模型 API到后来把一个新系统从需求阶段就按 AI 优先的方式设计中间踩过大量坑。这篇文章不聊概念只聊实操。我会把自己从需求拆解、架构分层、工具设计、评估体系搭建到成本控制的全过程记录下来每步都讲清楚当时为什么这么选、换了别的方案会出什么问题。准备做类似系统的朋友可以直接照着这个思路去搭第一版。1. AI Native 架构到底是什么先把概念对齐1.1 AI Native 不是AI 增强别再把旧系统缝缝补补AI Native 这个词不少人以为是在传统架构里接入 ChatGPT 或者开源模型 API 就算完成了。这其实是把AI 增强AI-Enhanced和AI 原生AI-Native搞混了。AI 增强的典型场景是这样的现有 CRM 系统里有个知识库模块你接了一个大模型 API让用户能用自然语言检索文档。用户的交互路径仍然是打开系统 - 点击菜单 - 输入问题 - 看结果AI 只是一个新的搜索框、一个摘要插件底层业务逻辑、数据模型、权限体系完全是过去那套。而 AI Native 的逻辑完全不同。系统从需求分析开始就把大模型的推理、规划、生成能力当作核心引擎传统模块数据库、消息队列、权限管理都是为 AI 服务的周边设施。用户的交互方式不再是点按钮、填表单而是用自然语言描述目标系统理解后自行规划任务、调用工具、执行操作、反馈结果。举个具体的例子。同样是做一个售后工单系统AI 增强方案工单的创建、流转、关闭还是原来的状态机AI 只负责自动总结用户描述、给工单打标签。AI Native 方案用户直接说我的设备在保修期内最近三天频繁重启帮我申请换货系统通过意图识别拆解出多个子任务调取订单数据核对保修信息检查设备日志确认故障模式生成换货工单并通知仓库最后向用户说明处理进展。整个流程里业务动作全部由 AI 编排驱动状态机变成了模型决策的一部分。这才是 AI Native 的核心系统不是靠固定代码路径响应业务而是靠模型理解意图、拆解任务、调用工具来驱动业务流转。这对架构设计的影响是颠覆性的最直观的冲击就是你得重新思考接口模块权限这些基础概念。1.2 AI Native 系统的三个核心特征根据我落地的经验判断一个系统是不是真正的 AI Native主要看三条。第一数据流是围绕模型设计的而不是围绕页面设计的。传统系统建表考虑的是表单字段和列表展示AI Native 系统建库考虑的是这一块数据是否方便以结构化的形式注入上下文。比如用户信息表不只存姓名电话还要存偏好摘要、历史交互语义向量、敏感信息等级。后者决定了模型能否在权限允许的范围内、以最有利于理解 user intent 的方式消费数据。第二业务逻辑从硬编码变成模型编排。传统代码里用户想退货是一个具体的createReturnOrder()方法调用AI Native 系统里这是模型在推理后对若干个候选函数查订单、验日期、生成退货单进行组合调用的结果。开发者从写死每一条流程变成设计模型可用的工具集、定义工具间的约束、兜住模型调不到的边界情况。第三评估和迭代方式变了。你不再只盯接口延迟、错误率、覆盖率还要盯模型对同一问题的回答一致性、工具选择的正确率、任务拆解的合理性。评估不再是上线前的环节而是贯穿整个系统生命周期的常驻模块。这三条说起来简单真正落地的时候会牵动每一个技术决策。比如微服务和单体该怎么选、数据库要不要引入向量检索、函数怎么写才能让模型更容易调用所有这些都要回到这三个特征上去对齐。1.3 哪些系统适合从零开始做 AI Native不是所有系统都应该 AI Native我从项目里总结出一个判断标准如果系统的核心价值来自把不确定信息转化为确定决策那么这个系统天然适合从零开始以 AI 为核心构建如果核心价值来自稳定高效地处理高频确定事务那 AI Native 可能反而添乱。适合的场景比如企业内部知识管理问答系统、智能客服与工单处理系统、代码助手类工具、数据分析辅助平台、个性化推荐编排。这些场景的共同特点是用户输入高度开放、决策路径不固定、答案质量有较大弹性空间这些恰好是模型能力的用武之地。不适合的场景比如银行核心账务系统、高并发的库存扣减、强事务型 ERP 模块。这类系统的结果是必须精确可预期的模型输出天生有不确定性强行 AI Native 只会给工程质量带来巨大负担。我见过一个团队把一个简单的 CRUD 后台管理改成 AI Native用户说一句帮我把昨天创建、状态为待审核的订单查出来就触发多模型推理结果是 80% 的查询用一句话描述的效率反而不如直接点筛选器。这种纯展示型查询传统实现简单可靠没必要让 AI 介入。选型前务必先把场景的业务本质想清楚。2. 从零开始的设计思路先立五层骨架再填血肉2.1 模型层怎么选调 API 还是自部署没有标准答案模型层是 AI Native 系统的发动机。你需要先回答一个问题用纯 API 调用还是私有化部署开源模型我自己的经验是分阶段选择。系统起步阶段业务逻辑还没跑通上下文设计也没定型强烈建议先用成熟的商业 API国内的就是通义千问、智谱、DeepSeek出海的话可以看 Claude、GPT 系列。这个阶段的诉求是快速验证推理质量、把产品逻辑跑通而非省成本。API 按量计费前期量不大费用可控而且你不用处理推理卡、显存、扩容这些运维问题。到了系统稳定跑起来以后再做开源模型私有化评估。选型主要是看 Qwen通义千问、DeepSeek 这些开源系列。这里要注意开源模型的部署不只是拉个镜像起服务那么简单还要做 Prompt 策略对齐、输出格式微调如果需要的话、推理性能压测。模型层的架构关键不在模型本身而在抽象。我给团队定的规矩是所有业务代码不直接依赖某一家模型 SDK而是走一层统一的LLM Gateway。这个 Gateway 负责管理模型版本、切换供应商、统一超时和重试策略、统计 Token 消耗。原因很简单大模型迭代太快你今天用 GPT-4o 调通的逻辑明天可能发现新的模型效果更好没有 Gateway 层换模型就要改业务代码这种耦合会让后面的迭代痛不欲生。# Gateway 层接口设计的核心就几个方法 class LLMGateway: def complete(self, messages: list[dict], tools: list[dict] | None None) - LLMResponse: 统一文本补全和工具调用入口 def stream_complete(self, messages: list[dict], tools: list[dict] | None None): 流式输出适合交互型场景 def embed(self, texts: list[str]) - list[list[float]]: 文本向量化RAG 场景要用这是我在项目里用得很顺手的一组抽象后续不管底层对接哪个模型服务商业务代码几乎不用动。换模型是必然发生的。一个 AI Native 系统的生命周期内模型底座一定会换两到三次。你要么提前做好这层抽象要么就等着每次换模型时修改几十个调用点、祈祷回归测试能覆盖住所有异常角落。抽象层多花的这点功夫后面会成倍赚回来。2.2 数据层设计AI 系统的数据库不再是存业务记录那么简单数据层是 AI Native 架构里最容易被低估的部分。初版我犯过一个错误完全沿用传统业务系统的数据表结构结果发现模型根本吃不到对胃口的数据。AI Native 系统里的数据要满足三类需求第一结构化的业务数据仍然要有但表结构设计要增加语义维度。比如工单表除了传统字段你需要冗余出工单摘要紧急程度权重关联知识包ID这些字段是给模型生成上下文用的让模型不必每次去实时分析全部对话记录。第二向量数据。只要系统需要做知识库问答、语义检索就得引入向量数据库我用过 Milvus、Qdrant国内团队也有很多用 Elasticsearch 的向量插件。这里最大的坑不是选哪家向量库而是切分策略。文本怎么切块、每块多大、重叠多少直接影响检索质量。我实践下来比较稳的参数是 500 到 800 字符一个 chunk重叠 50 字符左右具体要根据文档类型调。代码类文档可以更小法律合同类的可能需要更大切块配合标题层级。第三对话记忆数据。AI Native 系统的多轮交互能力依赖记忆。记忆分短期和长期短期记忆就是当前 session 的上下文长期记忆要单独设计存储结构保存用户的偏好、关键决策、历史问题摘要以便在未来的对话中恢复。这一块在传统架构里没有对应物是我觉得 AI Native 架构最有意思的地方。数据层的所有设计最终都要回答一个问题当模型需要决策时它是否能以最短的 token 消耗拿到最相关的信息数据结构不好模型就把大量上下文浪费在无关内容上数据结构好模型的任务准确率和响应速度都会有明显提升。2.3 编排层LLM 怎么和业务逻辑、API 组合成完整能力编排层是 AI Native 系统的大脑中枢负责决定模型什么时候调什么工具、调用的结果怎么处理、多步任务怎么衔接。目前在实践中沉淀出两种主流编排范式我认为可以理解为线性管道和Agent 循环。线性管道适合流程相对固定的场景比如客服工单自动分类接收入口 - 调用一个语义分类模型 - 根据分类结果走不同的后续处理函数。每步的输入输出是确定的模型只是流程中的一个增强组件这其实是AI 增强但它也是 AI Native 系统里不可少的基础环节。Agent 循环则复杂得多。系统将一个大目标交给 AgentAgent 自行规划步骤、逐个调用工具、根据工具结果调整计划、最终汇总输出。当前业内主流的 Agent 架构就是 LLM API 工具注册表 记忆模块的组合。工具注册表是重中之重系统暴露给 Agent 的所有函数、参数 schema、说明文字都要在一个统一的地方登记。模型通过阅读这些说明来决定调谁、传什么参所以工具描述的清晰度直接决定 Agent 的表现。编排层设计里我吃过最大的亏是任务状态管理。Agent 循环往往要执行很久如果中间某一步失败、或者模型决策路径绕远了整个状态很容易丢。解决方法是把任务状态独立于模型调用持久化到一个任务队列里每步执行完都记录状态快照。这听起来很基础但很多团队初版就把状态放在内存变量里进程一重启所有进行中的 Agent 任务全部丢失。编排层的另一个关键决策是要不要引入微服务。我的经验是AI Native 系统初期不要过度拆微服务模块化单体Modular Monolith是最舒服的形态。因为 AI Agent 的调用链条长、依赖关系复杂拆成微服务后链路追踪和故障排查的复杂度会指数级上升。先把所有能力放在一个代码库内用清晰的模块边界约束等业务量真的大到需要独立扩容某个能力时再把这个模块拆出去。2.4 记忆层与工具层Agent 能力上限的分水岭工具层和记忆层做得好不好才是不同团队 AI Native 系统体验拉开差距的地方。记忆层的目标是让系统在每轮对话中知道自己在跟谁说话、之前聊过什么、什么信息重要。我的做法是把记忆分成三层工作记忆当前对话上下文、情景记忆最近若干次对话摘要、长期记忆用户画像、业务偏好。工作记忆直接放模型上下文窗口里这个不用多说情景记忆可以按会话维度单独存储用向量化方式在下一次对话启动时检索相关摘要用 RAG 加载历史记忆长期记忆则要设计成比较稳定的结构化数据避免模型过度揣测。工具层就是暴露给模型的操作能力集合。我在一个售后系统里给 Agent 配过 30 多个工具查订单、查物流、查保修、创建工单、发通知等最初写工具说明时特别随意模型经常调错参数。后来我把工具说明按场景 参数约束 返回示例三个部分重写调用准确率直接从 70% 提升到 90% 以上。这充分说明工具层的核心不在代码而在写清楚机器可读的说明书。工具层设计还需要考虑权限和安全。Agent 能调用哪些工具必须和用户权限挂钩。模型本身没有权限意识它只会按工具描述去调用。这就要求在工具执行层强制做权限校验。这是 AI Native 系统里最不能省略的一环否则一个普通用户通过 Agent 调用了管理员的删除接口后果可能很严重。3. 核心环节的实现路径与实操记录3.1 打通 LLM 与业务系统从函数注册到工具调用工具调用Function Calling / Tool Use是当前让 LLM 操作业务系统的标准方式。我在对接 OpenAI 兼容接口和国产模型时流程基本一致核心步骤分四步。第一步定义函数 schema即业务函数的结构化描述。这是给模型看的不是给代码看的。每个函数需要写清楚名称、描述、参数列表、每个参数的类型与含义、哪些参数必填、哪些选填。以查询订单为例{ type: function, function: { name: query_order, description: 根据订单号或用户ID查询订单基本信息适用于售前咨询和售后处理场景, parameters: { type: object, properties: { order_id: {type: string, description: 完整订单号长度通常为18位}, user_id: {type: string, description: 用户唯一标识} }, required: [order_id] } } }第二步把 schema 随同用户消息一起传给模型。模型会判断这个用户的诉求需要调用 query_order参数可以从上下文里提取然后在回复里返回一个结构化的函数调用请求而不是直接输出文本。这一步的重点是模型必须能提取到准确的参数所以你在给模型的系统提示词里要强调参数缺失时主动询问用户不要瞎猜。第三步业务侧解析模型返回的调用请求执行真实的函数把执行结果传回给模型。第四步模型根据工具执行结果生成面向用户的最终回复。这一步是给用户看的语言要自然信息要准确。我实测下来最容易出问题的环节是第三步和第四步之间的衔接。工具返回的结果往往是一大段数据库记录或接口 JSON如果把这些原样塞回给模型既浪费 token 又容易让模型抓不住重点。我现在的标准做法是在工具执行函数内部就把返回内容做一次裁剪和摘要只把关键字段返回给模型。这一步相当于帮模型划重点能显著减少错误输出。3.2 多 AI 协作的三种模式什么时候需要多个 Agent 一起上多 AI 协作Multi-Agent Collaboration是最近特别火的方向但很多团队没有想清楚就上结果系统复杂度爆炸却没有带来实际收益。根据我的经验多 Agent 协作主要有三种模式按场景去选就行。第一种是流水线模式Pipeline。一个任务按顺序经过多个专用 Agent比如先由理解 Agent解析用户意图再由检索 Agent查资料最后由生成 Agent写答案。这种模式适合工序清晰的任务优点是每个 Agent 只干一件事Prompt 可以写得非常聚焦缺点是链路中任何一环出错都会前功尽弃。第二种是编排者-工作者模式Orchestrator-Workers。由一个主控 Agent 负责任务拆解和结果整合多个工作 Agent 并行执行子任务。这是我最常用的模式。比如做一个市场分析报告主控 Agent 把任务拆成竞品信息搜集用户评论情感分析数据图表生成几个子任务分发给不同 Worker各 Worker 完成后再由主控汇总。需要注意的是子任务之间的依赖关系得让主控明确列出避免出现A 的结果是 B 的输入这种隐性依赖被忽略。第三种是辩论/评审模式Multi-Agent Debate。多个 Agent 以不同视角分析同一个问题互相质疑补充最后投票或仲裁。这种模式能提升决策稳定性但 token 成本很高一般只用于高风险判断比如医疗建议、投资分析之类的场景。我个人的建议是大多数业务系统用到编排者-工作者模式就够了不要贪多。Agent 数量一多在上下文隔离、结果协议对齐上会耗费大量开发精力回报可能反而不如单 Agent 精心调优。3.3 输出可靠性兜底结构化输出校验与自动重试设计大模型的输出天生不稳定这在 AI Native 系统里是必然要面对的问题。我的兜底策略分三层。第一层是 Prompt 层面的强力约束。系统提示词里明确告诉模型你必须严格按 JSON 格式输出不要包含任何解释性文字。但光这么说不够还要在工具调用的 schema 里把输出结构定义得非常死板让模型几乎没有自由发挥空间。如果可以优先让模型通过 function calling 返回结构化对象而不是直接输出纯文本让下游去解析这样可靠性会高非常多。第二层是代码层面的格式校验。模型返回的 JSON 不一定合法字段缺失、取值为 null 的情况很常见。我在解析层加了一个校验函数用 Pydantic 或 TypeScript 的类型系统做严格校验不合法就让模型重新生成并附带错误信息。这个校验失败 - 返回给模型修正的循环可以迭代两到三次。实测下来加了校验和修正后输出解析成功率能从 80% 拉到 98% 以上。# 结构化输出校验的简化示意 def parse_agent_result(raw: str, schema: dict) - dict: data json.loads(raw) errors validate_schema(data, schema) for i in range(2): # 最多重试两次 if not errors: return data data ask_model_to_fix(raw, errors) # 把错误信息反馈给模型 errors validate_schema(data, schema) raise OutputValidationError(errors)第三层是全链路兜底。如果模型修正两轮仍然失败不要无限重试而是降级处理给用户返回一个友好提示并转人工同时记录完整调用链方便后续分析模型为什么反复出错。这里要说明的是无限重试不仅成本高还会把一次简单交互搞成死循环。3.4 评估闭环怎么衡量一个 AI Native 系统好不好用很多人做 AI Native 功能上线后发现效果还行但说不清哪里行原因就是没有建立评估闭环。我把这套评估体系分为三个层次。第一层单元评测。针对每个模型调用点准备一批带标准答案的测试样例自动跑模型输出和预期结果对比。比如意图识别模块准备几百句用户消息标注好期望调用哪个工具工具参数提取模块标注好期望的参数值。这层重点是快速、便宜每次改 Prompt 后都能自动回归。第二层端到端评测。把完整用户任务丢给整个系统看最后能否成功解决。例如用户要退货系统能否正确走到创建退货单这一步。这层关注流程正确率。为了自动化我会给系统设置一个特殊的测试用户用预录的对话脚本回放。第三层用户反馈闭环。生产环境里让用户对回答质量打分把低分样本捞出来分析是上下文不够、工具缺失还是模型推理错误再反向优化。这是最现实的质量信号比任何离线指标都重要。评估体系是 AI Native 系统的方向盘没有它就没有迭代方向。我建议做任何 AI Native 系统都要尽早搭建哪怕是刚开始只有几个测试样例也比完全没有强。4. 实操排坑最常见的问题与我的排查心得4.1 上下文窗口爆炸系统响应越来越慢多轮对话一长历史消息全塞进上下文token 消耗变大、模型响应变慢甚至直接超出上下文窗口报错。这个问题几乎每个做 AI 系统的团队都会遇到。我的解法是分级压缩策略。对话超过一定轮数后不再把原始消息全量送回模型而是先请模型对前面的对话生成摘要用摘要替换旧消息。这个摘要动作本身会消耗一些 token但能显著控制后续调用的规模总体是划算的。对于更早的对话再把摘要向量化存入记忆库需要时按相关性检索而不是每次都全量载入。另外一个容易忽略的工程手段是提前做意图判定。很多轮对话里用户可能只是在闲聊或者问与系统功能无关的问题系统完全不需要把整个业务上下文加载进模型。可以做一个轻量的意图门槛过滤掉无关请求。4.2 模型输出不稳定同样的输入不同结果怎么办模型本身的随机性加上 Prompt 微调不到位会导致用户感受飘忽。我的处理方式有两条一条靠配置一条靠架构。配置层面在调试的时候把 temperature 调低0 到 0.3减少输出的随机性。不要追求完全杜绝随机AI Native 系统本身就包含可能性微小的表达差异不影响功能属于正常现象。架构层面把需要高度稳定的判断逻辑尽量拆成小模型 结构化工具调用来做避免让模型自由创作。不需要创作力的场景全部给模型一个固定模板让它在模板内填空。举个例子工单自动分类不要求模型输出原因分析只要求它从给定分类字典里选一个枚举值输出可靠性会指数级上升。4.3 Token 消耗像流水成本完全失控AI Native 系统的成本大头是模型调用。我见过一个知识库问答系统用户问一句话系统背后做了检索加五轮工具调用加超长上下文注入单次成本去到几块钱人民币。成本控制要从源头设计入手而不是事后限制。第一工具返回结果必须裁剪这一点前面说过了是所有成本优化里收益最大的。第二多 Agent 协作时控制上下文传递不要让每个 Agent 都带着全部对话历史。第三对高频简单问题设置缓存语义相同的问题直接返回历史答案这一步能省下非常可观的费用。我还会在 Gateway 层记录每个请求的 token 拆解输入、输出、缓存命中、各工具调用占比每周做一次成本报表。看到异常增长时基本能定位到是哪条 Prompt 膨胀了、哪个工具返回了过大的内容然后针对性瘦身。4.4 可观测性缺失AI 系统出问题根本没法查传统系统出问题查日志、看堆栈、盯监控就行。AI Native 系统的问题隐蔽得多它不是报错而是行为不正确。比如 Agent 调错了一个参数、某一步工具调用返回了空结果、模型在中间环节产生了幻觉这些问题无法靠看一条 error 日志定位。我的做法是给调用链全程加追踪。每次模型请求、工具调用、记忆检索、重试动作都记录到可观测性系统里业界称 LLMOps除了传统的日志指标还要记录Prompts 和 Completions 的实际内容、Token 消耗、模型名称和版本、工具调用名称及参数、校验与重试的完整过程。有了这些追踪排查问题时的思路就跟调试传统系统一样清晰打开一次对话的完整 trace看到底是哪个环节出了岔子模型接到的输入是什么输出是什么哪个工具抛异常了。没有这套系统AI Native 项目就只能靠猜研发效率会低到让人怀疑人生。4.5 微服务和 AI Native 是否冲突关于分布式架构的思考很多团队受过去几年微服务潮影响拿到 AI Native 项目第一反应是拆微服务。我的看法是微服务和 AI Native 不冲突但 AI Native 项目落地初期几乎不需要微服务。原因在于 Agent 的多步推理会频繁调用多个能力如果这些能力分散在不同服务里每一次工具调用都是一次远程通信出故障的概率和延迟都会显著上升。而 Agent 本身对延迟极其敏感用户等待时本来就没有耐心再多几跳远程调用体验基本没法看。我推荐模块化单体方案代码分模块业务边界清晰但部署在一个进程里。这样既保留按业务能力划分模块的思考收益又避免了分布式事务、链路追踪、跨服务调试的额外负担。等到某个模块的负载确实独立于主进程再通过 RPC 或消息队列单独拆分出来不迟。我目前团队的核心 AI 系统跑了一年多依然是模块化单体的形态稳定性和迭代效率都很好。写在最后的个人经验从零开始以 AI 为核心构建系统本质上是一次研发思维的重置。过去做架构我们追求确定性的流程编排、严格的类型系统、可控的状态流转现在做 AI Native这些能力仍然需要但主角变成了一台有概率行为的推理引擎。你要学会和不确定性共处用工程手段兜住模型的随机性然后把精力花在工具质量、上下文设计、评估反馈这些真正影响用户体验的事情上。踩过这几年坑之后我最大的体会是AI Native 架构最难的不是模型能力而是产品团队是否真的愿意把用户的自然语言请求当作第一公民从数据、工具到评估每一层都为模型服务。技术框架都在快速演进但架构原则始终稳得住——上下文始终是对齐的目标工具始终是对齐的手段可靠性和可控性始终是对齐的底线。如果你正在准备启动一个 AI Native 项目我建议先别急着写代码。花两个星期把产品场景的边界、数据现状、评估基准、成本上限想清楚再多跑几个模型对比效果。地基打得牢后面所有层级的工程量都省得回来。