AI Native 这个词这两年几乎成了技术圈的硬通货但真正动手从零搭一套以 AI 为核心的系统时大多数人第一反应还是先写业务逻辑再挂个大模型接口上去。这种思路做出来的东西本质上还是传统架构加了个 AI 插件跟 AI Native 差着十万八千里。我自己从去年开始陆续参与过几个 Agent 项目和 LLM 应用的重构踩过的坑足够写一本小册子。这篇就把从零开始以 AI 为核心构建系统这件事拆开讲透包括为什么传统分层架构在 AI 场景下会失灵、Agent 和 LLM 该怎么摆位置、embedding 和向量检索在架构里扮演什么角色、以及并发和成本这两个绕不开的现实问题怎么处理。适合正在做 AI 应用架构选型的中高级工程师也适合想理解 AI Native 到底新在哪里的技术负责人。1. 为什么传统分层架构套在 AI 系统上会失灵1.1 确定性调用链与概率性输出的根本冲突传统后端架构的核心假设是给定输入输出是确定的。Controller 收到请求调 ServiceService 查数据库返回结果整条链路可预测、可测试、可回放。但 LLM 的引入直接打破了这个假设——同样的 prompt模型可能给你三种不同的回答token 采样温度稍微调一下输出结构就变了。我见过太多团队在这一点上翻车。他们按照经典三层架构设计在 Service 层里塞一个callLLM()方法然后指望像调普通 RPC 一样处理返回值。结果上线后发现模型偶尔返回 JSON 格式错误、偶尔幻觉出一个不存在的字段、偶尔因为上下文超长直接截断。这些在传统架构里属于异常但在 AI 系统里属于常态。正确的做法是把 LLM 调用当成一个概率性组件来对待而不是确定性服务。这意味着架构上必须有一层专门处理不确定性的模块——输出校验、重试、降级、结构化解析这些不能散落在业务代码里必须独立成层。1.2 状态管理从无状态服务变成有状态会话微服务架构推崇无状态服务实例可以随意扩缩容。但 AI 系统天然是有状态的对话历史、工具调用轨迹、中间推理步骤这些都是上下文的一部分。你不能像查数据库那样每次都从零开始因为 LLM 的记忆完全依赖你喂给它的 context window。这就带来一个架构难题会话状态放哪里放内存里实例重启就丢放 Redis 里序列化和反序列化开销不小放数据库里每次请求都要读一大坨历史。我实测下来比较稳的方案是分层存储——最近几轮对话放内存或本地缓存完整历史异步落库需要时再按需加载。这个后面会详细讲。1.3 成本模型从按 QPS 计费变成按 token 计费传统架构扩容看的是 QPS 和 CPU 利用率AI 系统扩容看的是 token 消耗。一次请求可能消耗几百 token也可能消耗几万 token取决于上下文长度和输出长度。这意味着你的容量规划逻辑完全变了——不是能扛多少请求而是能扛多少 token/秒以及每次请求平均烧多少钱。我做过一个粗略测算一个中等复杂度的 Agent 任务平均消耗 8000 输入 token 2000 输出 token按主流模型定价单次成本在几分钱到几毛钱之间。如果日活一万、人均十次调用一天就是几百到几千块。这个数字在传统架构里是不可想象的——你不可能因为一次 API 调用就烧掉几毛钱。提示在架构设计初期就要把 token 成本纳入核心指标而不是等上线后才发现账单爆炸。建议在网关层就做 token 计数和预算控制。2. AI Native 架构的核心分层该怎么切2.1 从请求-响应到意图-规划-执行的范式转换传统架构的入口是 HTTP 请求AI Native 架构的入口应该是意图。用户说帮我订明天去上海的机票这不是一个 API 调用而是一个需要拆解的任务查航班、比价格、选时间、下单、通知。这中间涉及多个工具调用和多次 LLM 推理。所以架构的第一层不是 Controller而是意图理解与任务规划层。这一层的职责是把自然语言输入转成结构化的任务图Task Graph每个节点是一个可执行的子任务节点之间的依赖关系决定了执行顺序。我习惯用 DAG 来描述这个结构因为大部分任务确实是有向无环的——先查再选再下单不会反过来。这一层的核心组件包括意图分类器可以用小模型或规则、任务拆解器通常用 LLM、依赖解析器决定哪些任务可以并行。实测下来任务拆解的质量直接决定了整个系统的上限拆得太粗会导致单步任务过于复杂拆得太细会导致调用次数爆炸、成本失控。2.2 Agent 执行层工具调用与状态机的结合Agent 是 AI Native 架构里最核心的执行单元。我的理解是Agent LLM 工具集 状态机 记忆。LLM 负责决策工具集负责与外部世界交互状态机负责控制流程记忆负责维持上下文。这里有个常见的误区很多人把 Agent 写成一个 while 循环让 LLM 自己决定下一步做什么直到它说完成了。这种写法在 demo 里很酷在生产环境里是灾难——LLM 可能陷入死循环、可能调用不存在的工具、可能在错误的时机停止。我的做法是用状态机约束 Agent 的行为边界。状态机定义合法的状态转移LLM 只能在当前状态下选择合法的动作。比如在查询航班状态下LLM 只能调用航班查询工具不能直接跳到下单。这样既保留了 LLM 的灵活性又保证了流程的可控性。class AgentStateMachine: states [idle, planning, executing, waiting_tool, completed, failed] def transition(self, current_state, llm_decision): allowed self.allowed_transitions[current_state] if llm_decision.action not in allowed: return self.fallback(current_state) return llm_decision.next_state工具调用的设计也有讲究。每个工具必须有清晰的 schema 描述名称、参数、返回值LLM 才能正确调用。我踩过的坑是工具描述写得太模糊LLM 经常传错参数工具返回值太复杂LLM 解析不了。后来统一规范工具描述用自然语言 JSON Schema 双重描述返回值必须是扁平的结构化数据。2.3 记忆层短期上下文与长期知识的分工记忆层是 AI Native 架构里最容易被低估的部分。很多人以为记忆就是把历史对话拼到 prompt 里这是最粗糙的做法token 消耗大且效果差。我的分层方案是短期记忆最近 N 轮对话直接放 context window保证对话连贯性工作记忆当前任务的中间结果比如已经查到的航班列表、用户偏好用结构化格式存储长期记忆跨会话的知识比如用户的历史偏好、常见问题用向量库存储按需检索短期记忆和工作记忆是每次请求都要带的长期记忆是按需召回的。这个分工的关键在于不是所有历史都值得放进 prompt。我实测过一个对话系统把全部历史塞进去token 消耗是分层方案的 5 倍但回答质量反而更差——因为无关信息干扰了模型判断。2.4 模型层多模型路由与降级策略不要把所有鸡蛋放在一个模型篮子里。AI Native 架构的模型层应该支持多模型路由简单任务用小模型快、便宜复杂任务用大模型慢、贵特定任务用专用模型比如 embedding 用专门的 embedding 模型。路由策略可以基于任务类型、输入长度、历史成功率等维度。我常用的规则是任务类型推荐模型理由意图分类小模型/规则简单分类不需要大模型任务拆解中等模型需要一定推理能力复杂推理大模型需要强推理能力文本嵌入专用 embedding 模型通用模型效果差且贵格式化输出小模型简单转换任务降级策略同样重要。主模型超时或失败时自动切到备用模型备用也失败时返回兜底回答而不是报错。这个在传统架构里叫熔断降级在 AI 系统里同样适用只是降级的对象从服务变成了模型。3. Embedding 与向量检索在架构中的真实位置3.1 Embedding 不是可选项是 AI Native 的基础设施很多人把 embedding 当成 RAG 的附属品需要做知识库检索时才想起来。但在 AI Native 架构里embedding 应该是基础设施级别的存在和数据库、缓存同级。为什么因为 embedding 解决的是语义相似度问题而这个问题在 AI 系统里无处不在长期记忆检索、工具选择、意图匹配、去重、聚类全都依赖 embedding。你不可能每个场景都单独搭一套向量检索必须有一个统一的 embedding 服务。这个服务的核心职责是文本转向量、向量存储、相似度检索。我建议把它做成独立的微服务对外暴露简单的 APIembed(text) - vector和search(vector, top_k) - results。这样上层应用不用关心底层用的是哪个 embedding 模型、哪个向量库。3.2 向量库选型的几个现实考量向量库的选择没有银弹取决于你的数据规模和查询模式。我整理了一个对比向量库适用场景优点缺点FAISS单机、中小规模快、轻量、无需部署不支持分布式、无持久化Milvus大规模、分布式功能全、支持多种索引部署复杂、资源占用高Qdrant中等规模、易用部署简单、API 友好生态相对小pgvector已有 PostgreSQL无需额外组件、事务支持大规模性能一般Chroma原型、小规模极简、上手快生产环境能力弱我的经验是先用最简单的方案跑通再根据瓶颈升级。很多团队一上来就上 Milvus 集群结果数据量才几万条纯属浪费。几万条数据用 FAISS 或 pgvector 完全够用等到了百万级再考虑分布式方案。3.3 检索质量的决定因素不只是模型embedding 模型的选择当然重要但检索质量的决定因素远不止模型本身。我踩过的坑包括分块策略把文档切成多大的块切太大检索精度低切太小上下文不完整。我的经验是 256-512 token 一块重叠 50 token。元数据过滤纯向量检索容易召回无关内容加上元数据过滤时间、来源、类型能大幅提升精度。重排序向量检索召回 top-50再用重排序模型精选 top-5效果比直接取 top-5 好很多。混合检索向量检索 关键词检索结合能覆盖纯语义检索的盲区。注意embedding 模型一旦选定换模型的成本极高——所有存量向量都要重新计算。所以选型时要考虑长期稳定性不要频繁更换。4. 并发、成本与可观测性AI 系统的三个现实约束4.1 Agent 怎么扛并发异步与流式的组合拳AI Agent 的并发处理和传统服务完全不同。传统服务一次请求几十毫秒Agent 一次任务可能几秒到几十秒。如果同步处理线程池瞬间打满。我的方案是全链路异步 流式输出。用户发起请求后立即返回一个 task_id后台异步执行 Agent 任务执行过程中的中间结果通过 SSE 或 WebSocket 流式推送给前端。这样用户能实时看到进度服务端也不会被长连接占满。异步执行的核心是任务队列。我通常用 Redis 或消息队列做任务分发Worker 池消费任务。每个 Worker 处理一个 Agent 任务任务内部的多步推理可以并行的地方就并行比如同时查多个数据源。这里有个细节Agent 任务的超时控制。不能让它无限跑下去必须设置最大步数和最大耗时。超过阈值就强制终止返回部分结果。我一般设最大 20 步、最长 60 秒超过就降级。4.2 Token 成本控制从架构层面省钱成本控制不能靠省着用要靠架构设计。我的几个做法Prompt 压缩定期分析 prompt删掉冗余的指令和示例。我见过一个 prompt 里塞了 2000 token 的 few-shot 示例实际只用得上 3 个压缩后省了 70%。缓存相同或相似的请求结果缓存起来。embedding 结果、常见问题的回答都可以缓存。分级模型前面说的多模型路由简单任务用小模型能省一大半成本。上下文裁剪不是所有历史都要带按相关性裁剪。批量处理能批量的 embedding 请求合并成一次调用。我实测过一个优化案例通过 prompt 压缩 分级模型 缓存整体成本降了 60%效果几乎没有损失。4.3 可观测性AI 系统的黑盒怎么打开AI 系统最大的问题是黑盒——你不知道模型为什么这么回答不知道哪一步出了问题。可观测性必须从第一天就设计进去。我关注的几个维度Trace每个请求的完整链路包括每次 LLM 调用的输入输出、每次工具调用的参数和结果、每步的耗时。Token 统计每次调用的输入输出 token 数按用户、按任务类型聚合。质量指标回答准确率、工具调用成功率、任务完成率。成本指标按维度聚合的 token 成本。工具上LangSmith、Langfuse 这类 LLM 可观测性平台能省很多事。如果自建至少要保证每次 LLM 调用都有完整的日志记录包括 prompt、response、耗时、token 数。5. 从零搭建的实操路径与踩坑记录5.1 最小可行架构先跑通再优化不要一上来就设计完美架构。我的建议是先搭一个最小可行版本一个简单的 API 入口接收用户输入一个 LLM 调用封装处理重试和降级一个工具注册机制支持动态添加工具一个简单的状态机控制 Agent 流程基础的日志和 token 统计这个版本可能只有几百行代码但能跑通完整的输入-规划-执行-输出链路。跑通之后再逐步加记忆层、向量检索、多模型路由、可观测性。我见过太多团队在架构设计阶段花了几个月结果一行代码没写。AI 这个领域变化太快过度设计等于浪费时间。5.2 那些文档里不会写的坑坑一LLM 返回的 JSON 不合法。即使你明确要求返回 JSON模型也可能返回带 markdown 代码块的、带注释的、字段名拼错的。解决方案是用结构化输出function calling 或 JSON mode加上严格的解析和重试。坑二工具调用的参数类型不匹配。LLM 可能把数字传成字符串把数组传成对象。解决方案是在工具层做参数校验和类型转换不要信任 LLM 的输出。坑三上下文超长导致截断。不同模型的 context window 不同超长时行为也不一样——有的报错有的静默截断。解决方案是在调用前计算 token 数超长时主动裁剪或摘要。坑四Agent 陷入循环。LLM 可能反复调用同一个工具或者在不同状态间来回跳。解决方案是设置最大步数、检测重复调用、状态机约束。坑五embedding 模型版本不一致。查询时用的模型和入库时用的模型不一致检索结果完全错乱。解决方案是把模型版本作为元数据存储检索时校验。5.3 团队协作与迭代节奏AI Native 项目的迭代节奏和传统项目不同。传统项目可以按季度规划AI 项目可能每周都要调整 prompt、换模型、加工具。所以协作方式也要变Prompt 版本管理prompt 要像代码一样管理有版本、有 review、有回滚。评测集建立一套评测集每次改动都跑一遍防止效果回退。灰度发布新 prompt 或新模型先小流量灰度观察指标再全量。快速回滚任何改动都要能快速回滚包括 prompt、模型、工具配置。我个人的体会是AI Native 架构的核心不是某个具体技术而是接受不确定性并将其工程化。传统架构追求确定性AI 架构追求的是在不确定中保持可控。这个思维转变比任何具体技术都重要。最后分享一个实用技巧在架构里预留一个实验开关能快速切换模型、prompt、工具配置而不需要改代码重新部署。这个开关在调试和优化阶段能省下大量时间。