AI Native 架构实战：从模型收口到上下文工程的落地指南

AI Native 这个词这两年出现的频率越来越高，但真正动手从零搭一套以 AI 为核心的系统时，大多数人还是会不自觉地退回老路：先定数据库表结构，再写后端接口，最后把大模型当成一个“智能插件”塞进某个业务节点。这种做法本质上还是传统架构加了个 AI 外壳，跑起来能演示，但一旦业务逻辑变复杂、模型需要频繁替换、上下文越来越长，系统就会变得极其脆弱。我过去一年参与了三个从零起步的 AI 原生项目，踩过的坑从“提示词硬编码在业务代码里”到“换一个模型整个链路崩掉”都有，这篇文章就把这些经验整理成一套可落地的架构思路，适合正在规划 AI 产品、准备重构现有系统、或者单纯想搞清楚 AI Native 到底和传统架构差在哪里的开发者参考。

1. 先搞清楚 AI Native 和“传统系统加个模型”的本质区别

1.1 传统架构的思维惯性在哪里失效

传统业务系统的核心假设是：逻辑是确定的、可枚举的、可穷举测试的。你写一个订单状态机，状态流转路径就那么多条，测试用例覆盖完就敢上线。但 AI 原生系统面对的是概率性输出，同一个输入可能得到不同结果，模型版本一换行为就变，上下文长度、温度参数、甚至调用时间都可能影响最终表现。这意味着传统那套“接口契约 + 单元测试 + 回归验证”的保障体系，在 AI 系统里只能覆盖一部分，剩下的必须靠新的架构手段来兜底。

我见过最典型的反面案例是一个客服工单分类系统。团队把大模型调用写在一个 Service 方法里，提示词直接拼字符串，模型返回结果直接入库。上线第一周没问题，第二周运营改了一版提示词，分类准确率从 92% 掉到 67%，排查了两天才发现是新提示词里少了一个关键约束条件。问题不在于提示词写错了，而在于整个架构没有把“提示词”当成一等公民来管理，它散落在代码里，没有版本、没有测试、没有回滚机制。

1.2 AI Native 架构的三个核心转变

从我的实践来看，AI Native 架构和传统架构的差异可以归纳为三个根本性转变。

第一个转变是从“逻辑驱动”到“上下文驱动”。传统系统靠代码逻辑决定行为，AI 系统靠上下文（Context）决定行为。上下文包括系统提示词、历史对话、检索到的知识、工具调用结果等等。架构设计的核心任务之一，就是如何高效地组装、管理、压缩和传递上下文。这就像做菜，传统架构是你写好菜谱每一步放什么，AI 架构是你把食材和调料摆好，让厨师（模型）自己决定怎么炒，但食材的新鲜度、调料的配比、灶台的火候都得你来控制。

第二个转变是从“接口契约”到“能力契约”。传统微服务之间靠 API 契约通信，字段类型、必填项、返回结构都是确定的。AI 系统里，模型和外部工具之间的交互是动态的，模型可能决定调用哪个工具、传什么参数、什么时候停止。架构需要定义的是“能力边界”而不是“接口格式”——模型能做什么、不能做什么、做错了怎么兜底。

第三个转变是从“部署即完成”到“持续演进”。传统系统上线后相对稳定，AI 系统上线只是开始。模型会更新、提示词会迭代、用户输入分布会漂移、检索库会膨胀。架构必须内建可观测性、可评估性和可回滚性，否则你根本不知道系统是在变好还是变坏。

1.3 一个判断标准：你的系统离 AI Native 有多远

我通常用下面这张表来快速判断一个系统的 AI 原生程度。你可以对照自己的项目看看处在哪个阶段。

如果你的系统大部分落在第一列，那基本还是传统架构加了个模型调用；如果开始往第二列迁移，说明有了 AI 原生的意识；只有大部分落在第三列，才算真正以 AI 为核心在构建系统。

2. 上下文工程：AI Native 架构真正的核心战场

2.1 为什么说上下文比模型更重要

很多人选型时花大量时间对比模型跑分，但实际项目里，上下文的质量对最终效果的影响往往比模型本身更大。我做过一个对比实验：同一个任务，用中等能力的模型配精心设计的上下文，效果明显优于用最强模型配粗糙的上下文。原因很简单，模型再强，你给它的信息不完整、有噪声、格式混乱，它也巧妇难为无米之炊。

上下文工程要解决的问题包括：哪些信息该放进上下文、以什么格式放、放多少、什么时候该压缩、什么时候该丢弃。这听起来像是个工程问题，但实际做起来更像是在设计一套信息流系统。我习惯把上下文分成四层来管理。

第一层是系统指令层，定义模型的角色、行为边界、输出格式要求。这一层相对稳定，但需要版本管理。第二层是任务上下文层，包括当前用户输入、会话历史、相关业务数据。这一层变化最频繁，也是 Token 消耗的大头。第三层是知识检索层，从向量库或搜索引擎召回的文档片段。这一层的关键是召回质量和去重。第四层是工具结果层，模型调用外部工具后返回的数据。这一层需要做截断和摘要，否则很容易撑爆上下文窗口。

2.2 上下文窗口管理的实操策略

上下文窗口是有限资源，怎么在有限窗口里塞进最有价值的信息，是每个 AI 原生系统都要面对的问题。我总结了几条实操策略，按优先级从高到低排列。

策略一：系统指令精简到极致。很多人的系统提示词写得像产品需求文档，动辄两三千字。实测下来，系统指令超过 800 字后，边际收益急剧下降，反而挤占了任务上下文的空间。我的做法是把系统指令控制在 500 字以内，只保留角色定义、核心约束、输出格式三部分，其他细节通过 Few-shot 示例来传达。

策略二：会话历史做滑动窗口加摘要。多轮对话场景下，历史消息不能无限堆积。常见做法是保留最近 N 轮完整对话，更早的对话用模型生成摘要。这里有个坑：摘要本身也要消耗 Token，而且摘要质量不稳定。我的经验是，摘要触发阈值不要设得太低，一般当历史 Token 超过窗口的 40% 时再触发，摘要长度控制在原文的 15% 左右。

策略三：检索结果做重排序和截断。向量检索返回的 Top-K 结果里，真正相关的可能只有前两三条。直接全部塞进上下文，不仅浪费 Token，还会引入噪声干扰模型判断。我通常会在检索后加一个轻量级重排序步骤，可以用交叉编码器，也可以简单用关键词匹配打分，然后只保留得分最高的 3 到 5 条，每条再做长度截断。

策略四：工具结果做结构化摘要。模型调用工具后返回的数据往往是原始 JSON 或长文本，直接放回上下文很占空间。更好的做法是在工具层就做好摘要，只返回模型决策所需的关键字段。比如查询订单接口，不需要返回完整订单对象，只返回订单号、状态、金额、时间四个字段就够了。

2.3 上下文组装的代码结构长什么样

下面这段伪代码展示了我常用的上下文组装逻辑，核心思路是把各层上下文分开管理，最后按优先级和 Token 预算组装。

class ContextBuilder: def __init__(self, token_budget=8000): self.token_budget = token_budget self.layers = [] def add_system_instruction(self, instruction: str, priority: int = 100): self.layers.append({ "type": "system", "content": instruction, "priority": priority, "compressible": False }) def add_conversation_history(self, messages: list, max_turns: int = 10): recent = messages[-max_turns:] older = messages[:-max_turns] if older: summary = self.summarize(older) self.layers.append({ "type": "history_summary", "content": summary, "priority": 60, "compressible": True }) self.layers.append({ "type": "history_recent", "content": recent, "priority": 80, "compressible": False }) def add_retrieval_results(self, docs: list, top_k: int = 5): reranked = self.rerank(docs)[:top_k] self.layers.append({ "type": "retrieval", "content": reranked, "priority": 70, "compressible": True }) def build(self) -> list: # 按优先级排序，在 Token 预算内组装 sorted_layers = sorted(self.layers, key=lambda x: -x["priority"]) result = [] used_tokens = 0 for layer in sorted_layers: layer_tokens = self.count_tokens(layer["content"]) if used_tokens + layer_tokens <= self.token_budget: result.append(layer) used_tokens += layer_tokens elif layer["compressible"]: compressed = self.compress(layer["content"], self.token_budget - used_tokens) result.append({**layer, "content": compressed}) used_tokens += self.count_tokens(compressed) return result

这段代码的关键设计点是：每个上下文层都有优先级和可压缩标记，组装时按优先级从高到低填充，遇到预算不足时优先压缩可压缩层。这样能保证系统指令和最近对话永远不被裁掉，而检索结果和历史摘要可以灵活伸缩。

3. 模型网关：别让业务代码直接碰模型 SDK

3.1 直接调用 SDK 的五个致命问题

项目初期为了快速验证，直接在业务代码里调模型 SDK 是最省事的做法。但只要项目活过三个月，下面这些问题一定会出现。

第一，模型切换成本极高。业务代码里到处是某个厂商 SDK 的调用方式，想换个模型或者加个备用模型，得改几十个文件。第二，无法统一做限流和降级。每个调用点各自为政，某个模型服务抖动时，整个系统跟着雪崩。第三，Token 计量和成本核算做不了。你不知道哪个业务模块消耗了多少 Token，优化无从下手。第四，提示词版本管理缺失。提示词散落在代码里，改一版就得发一次版，回滚更是噩梦。第五，可观测性差。调用失败时，你只能看到业务层的报错，看不到模型返回的原始内容、耗时分布、Token 使用情况。

3.2 模型网关该具备的六项能力

一个合格的模型网关，我认为至少要具备下面六项能力。这不是过度设计，而是每个都在实际项目中救过命。

能力一：统一调用接口。不管底层是哪个厂商的模型，上层业务只面对一套统一的请求和响应格式。这样切换模型只需要改网关配置，业务代码零改动。

能力二：模型路由。根据任务类型、成本预算、延迟要求，把请求路由到不同的模型。比如简单分类任务走小模型，复杂推理走大模型，敏感内容走专用审核模型。

能力三：限流与降级。对每个模型设置 QPS 上限和并发上限，超限时要么排队要么降级到备用模型。降级策略要可配置，比如主模型超时 3 秒就切备用模型，备用也失败就返回兜底话术。

能力四：提示词管理。提示词从代码里抽出来，存到配置中心或数据库，支持版本、灰度、回滚。每次调用记录用了哪个版本的提示词，方便问题追溯。

能力五：Token 计量与成本追踪。每次调用记录输入 Token、输出 Token、模型名称、业务标签，汇总后可以按业务线、按用户、按时间段出成本报表。

能力六：全链路可观测。记录请求 ID、模型名称、提示词版本、耗时、Token 数、返回状态、错误信息。这些数据既要能实时看板展示，也要能落库供后续分析。

3.3 网关的降级策略怎么设计才靠谱

降级策略设计不好，要么该降的时候不降，要么不该降的时候乱降。我踩过的坑是：一开始只设了“主模型失败切备用”，结果主模型没失败但响应特别慢，用户等得骂人，系统还在傻等。后来改成基于超时的降级，但又遇到备用模型也慢的情况，请求堆积越来越多。

最终我采用的是一套组合策略，用下面这张表来说明。

这套策略的核心思想是：降级不是二元的，而是分层的。从主模型到备用模型到兜底响应，每一层都有明确的触发和恢复条件。而且恢复条件要比触发条件更严格，避免在临界点反复横跳。

3.4 提示词版本管理的落地方式

提示词版本管理听起来简单，做起来有不少细节。我的做法是把提示词存成结构化数据，每条提示词有唯一 ID、版本号、内容、适用模型、创建时间、状态（草稿/灰度/正式/下线）。调用时通过提示词 ID 加版本号来获取，如果不指定版本号则取当前正式版本。

灰度发布时，可以配置流量比例，比如新版本提示词先接 10% 流量，观察核心指标（准确率、用户满意度、Token 消耗）没有明显下降再逐步放大。回滚就是切回上一个正式版本，秒级生效。

这里有个容易忽略的点：提示词变更后，之前缓存的模型响应可能不再适用。如果系统里有基于提示词哈希的缓存，提示词版本变更时必须让缓存失效，否则会出现新旧提示词混用导致的诡异问题。

4. 输出可靠性：让概率性输出变得可工程化

4.1 结构化输出是可靠性的第一道防线

模型输出不可控是 AI 系统最大的工程挑战之一。你让它返回 JSON，它可能给你返回一段带解释的 JSON，也可能字段名拼错，还可能多返回几个你没定义的字段。如果业务代码直接解析，分分钟抛异常。

结构化输出的核心思路是：不让模型自由发挥，而是约束它按固定格式输出。目前主流做法有三种。第一种是提示词约束，在系统指令里明确要求输出 JSON 并给出 Schema，简单但不够可靠。第二种是模型厂商提供的结构化输出能力，比如某些模型支持 JSON Mode 或 Function Calling，可靠性高但绑定厂商。第三种是输出后处理，用解析器容错解析，失败则重试或走兜底。

我的实践是三者结合：优先用厂商的结构化输出能力，同时提示词里也写清楚格式要求，最后加一层容错解析。容错解析器要能处理常见问题，比如 JSON 外面包了 Markdown 代码块、字段名大小写不一致、数值类型被写成字符串等。

4.2 重试机制的设计要点

模型输出不符合预期时，重试是最直接的补救手段。但重试不能无脑重试，否则可能陷入死循环或者放大成本。我设计重试机制时遵循几个原则。

原则一：区分可重试错误和不可重试错误。网络超时、限流、模型临时不可用属于可重试；输入内容违规、Token 超限、Schema 定义错误属于不可重试，重试多少次都一样。

原则二：重试要带修正信息。如果第一次输出格式不对，重试时把错误信息反馈给模型，比如“你上次返回的不是合法 JSON，请只返回 JSON 不要有其他内容”。这样重试成功率会高很多。

原则三：重试次数和退避策略要合理。我一般设最多 2 次重试，第一次立即重试，第二次延迟 1 秒。超过 2 次还不成功，说明问题不在偶发因素，继续重试只是浪费 Token。

原则四：重试要记录。每次重试的原因、结果都要记录，定期分析重试率高的场景，从提示词或 Schema 设计上根治问题。

4.3 兜底策略：当模型彻底不靠谱时怎么办

再好的架构也不能保证模型 100% 可靠，所以兜底策略是必须的。兜底不是简单返回“系统繁忙”，而是要根据业务场景设计有意义的降级响应。

对于分类任务，兜底可以返回“其他”类别，并标记为待人工处理。对于生成任务，兜底可以返回预置的模板话术。对于问答任务，兜底可以返回“这个问题我暂时无法回答，已为您转接人工”。关键是要让用户感知到系统在正常工作，而不是崩了。

兜底策略还要考虑数据一致性。如果模型调用是某个业务流程的一环，兜底后业务流程怎么继续、数据怎么标记、后续怎么补偿，这些都要提前设计好。我见过一个系统，模型调用失败后直接返回空，导致下游流程拿到空数据继续跑，产生了一堆脏数据，清理起来非常痛苦。

5. 评估体系：没有评估就没有迭代

5.1 为什么 AI 系统的评估比传统系统难十倍

传统系统的测试是确定性的：输入 A 必然得到输出 B，断言相等即可。AI 系统的输出是概率性的，同一个输入可能得到语义相同但表述不同的多个输出，你没法用等号来判断对错。更麻烦的是，很多 AI 任务没有标准答案，比如“写一段产品介绍”，什么叫好什么叫不好，本身就带有主观性。

这就导致很多团队在 AI 项目上陷入一个困境：上线靠 demo，迭代靠感觉。产品经理说“我觉得这次改得不错”，工程师说“我测了几个 case 没问题”，然后上线，然后被用户骂。根本原因是没有建立一套可量化、可复现、可持续的评估体系。

5.2 构建评估集的实操方法

评估体系的基础是评估集。评估集不是随便找几个例子，而是要覆盖真实场景的分布。我构建评估集通常分四步走。

第一步，从真实日志中采样。系统上线后，把用户真实输入按类型分层采样，确保各类场景都有覆盖。冷启动阶段没有日志，就靠产品经理和领域专家手工构造。

第二步，给每个样本标注期望输出。对于有标准答案的任务，直接标注答案；对于开放式任务，标注评分标准或参考答案。标注工作最好由领域专家做，工程师代劳容易偏离业务实际。

第三步，划分回归集和探索集。回归集是每次发版必须跑的，用来确保没有退步；探索集是定期跑的，用来发现新的问题场景。回归集要稳定，探索集可以动态更新。

第四步，持续扩充和修正。线上发现 bad case，评估后加入评估集。评估集不是一成不变的，它应该随着系统演进不断生长。

5.3 自动化评估与人工评估的配合

全自动评估省事但不够准，全人工评估准但太贵。我的做法是分层配合。

自动化评估负责跑量，用规则匹配、关键词命中、语义相似度等指标快速筛选。比如分类任务直接比对标签，抽取任务比对字段是否齐全，生成任务用 BERTScore 或相似度模型打分。自动化评估的阈值可以设得宽松一些，它的作用是快速发现明显问题，而不是精确打分。

人工评估负责校准，定期从自动化评估结果中抽样，由人工复核。人工评估的结果用来校准自动化评估的阈值，也用来发现自动化指标覆盖不到的问题。我一般每周抽 50 到 100 条做人工评估，这个量级既能发现问题，成本也可控。

两者配合的关键是建立反馈闭环：人工评估发现的问题，要能追溯到具体的提示词版本、模型版本、上下文组装逻辑，然后针对性优化，优化后再跑自动化评估验证。

5.4 评估指标该怎么选

不同任务类型的评估指标差异很大，下面这张表是我常用的一些指标组合。

选指标时有个原则：指标要能指导优化方向。如果一个指标涨了但你不知道该改什么，那这个指标意义不大。比如“用户满意度”是个好指标，但它太宏观，涨了跌了都不知道原因。更好的做法是把它拆解成可操作的子指标，比如“答案相关性”“格式规范性”“响应及时性”，每个子指标都能对应到具体的架构环节。

6. 可观测性：AI 系统上线后你该盯什么

6.1 传统监控指标在 AI 系统里的盲区

传统系统监控 CPU、内存、QPS、错误率就够了，但 AI 系统这些指标全绿也可能在“慢性死亡”。我遇到过模型响应时间正常、错误率为零，但输出质量悄悄下降的情况，原因是上游检索库更新了一批低质量文档，模型被带偏了。这种问题传统监控完全发现不了。

AI 系统的可观测性要额外关注几个维度：Token 消耗趋势、提示词版本分布、模型输出长度分布、重试率、降级触发次数、评估指标变化。这些指标单独看可能都正常，但组合起来能发现很多隐藏问题。

6.2 全链路追踪该记录哪些字段

每次模型调用都应该生成一条追踪记录，包含下面这些字段。字段看着多，但真出问题时，少任何一个都可能让你多排查半天。

{ "trace_id": "唯一请求标识", "timestamp": "调用时间", "business_tag": "业务标签，如 order_classify", "model_name": "实际调用的模型", "prompt_id": "提示词ID", "prompt_version": "提示词版本", "input_tokens": "输入Token数", "output_tokens": "输出Token数", "latency_ms": "总耗时", "first_token_ms": "首Token耗时", "status": "成功/失败/降级", "retry_count": "重试次数", "error_type": "错误类型", "context_layers": "上下文各层Token占比", "output_hash": "输出哈希，用于去重和缓存" }

这些字段落库后，可以做很多分析。比如按 business_tag 看 Token 消耗排名，找出成本大户；按 prompt_version 看不同版本的评估指标差异；按 context_layers 看上下文组装是否合理，有没有某一层占比过高。

6.3 告警规则怎么设才不扰民

可观测性做不好会变成告警风暴，做太好又可能漏报。我的经验是告警规则要分层，不同层级的告警走不同通道。

P0 级告警：模型服务完全不可用、错误率超过 10%、降级触发超过阈值。这类告警直接打电话，必须立即处理。

P1 级告警：P99 延迟超过阈值、Token 消耗突增 50%、重试率超过 5%。这类告警发到工作群，当天处理。

P2 级告警：评估指标下降超过 5%、提示词版本分布异常、输出长度分布偏移。这类告警发邮件或日报，按周处理。

关键是要给告警设置合理的静默期和聚合规则。比如同一个模型 5 分钟内触发 10 次相同告警，只发一次。否则运维同学会被淹没，最后对所有告警都麻木了。

7. 从零搭建 AI Native 系统的落地顺序

7.1 第一阶段：把模型调用收口

不管系统多复杂，第一步永远是建模型网关，把所有模型调用收口到一处。这个阶段不用追求功能完备，先实现统一接口、基础路由、Token 计量三件事。业务代码里所有直接调 SDK 的地方全部改成调网关。这一步做完，后面所有优化才有抓手。

我见过团队跳过这一步直接做上层功能，结果做到一半发现模型调用散落各处，想加个限流都加不了，只能推倒重来。收口这件事，越早做成本越低。

7.2 第二阶段：上下文工程和提示词管理

网关建好后，开始治理上下文和提示词。把硬编码的提示词抽出来，建立版本管理。把上下文组装逻辑从业务代码里剥离，做成独立的 ContextBuilder。这个阶段会动到不少业务代码，但动完之后，提示词迭代和上下文调优的效率会提升一个数量级。

这个阶段有个实用技巧：先做提示词版本管理，再做上下文分层。因为提示词版本管理改动小、见效快，能快速让团队感受到收益，为后续更大的重构积累信任。

7.3 第三阶段：输出可靠性和评估体系

前两个阶段解决的是“能跑”的问题，这个阶段解决“跑得稳”的问题。加上结构化输出、重试、兜底，建立评估集和自动化评估流程。这个阶段的关键是不要追求一步到位，评估集从 20 条开始也行，先跑起来，再慢慢扩充。

评估体系建立后，你会发现之前很多“感觉”上的问题变得可量化了。比如“最近回答质量好像下降了”，以前只能靠感觉，现在可以看评估指标曲线，是哪个维度降了、从哪个版本开始降的，一目了然。

7.4 第四阶段：可观测性和持续优化

最后一个阶段是把可观测性补齐，建立告警和日报机制。这个阶段不是终点，而是持续优化的起点。有了完整的可观测数据，你可以做很多之前做不了的事：按业务线优化成本、按场景优化提示词、按模型表现调整路由策略。

整个落地顺序的核心逻辑是：先收口再治理，先能跑再跑稳，先有数据再优化。反过来做，比如先建可观测性再收口模型调用，你会发现数据采集点散落各处，根本没法统一。

8. 几个容易踩的坑和我的应对建议

8.1 过度依赖单一模型厂商

项目初期为了快速上线，只接一家模型厂商是合理的。但到了生产阶段，一定要有备用方案。我经历过一次主模型服务区域故障，整个系统瘫痪了四个小时，就是因为没有备用模型。后来加了备用模型和自动降级，虽然备用模型效果略差，但至少系统可用。

备用模型的选择要注意两点：一是接口协议要能通过网关适配，二是效果不能差太多，否则降级后用户体验断崖式下跌。我一般会选一个同级别但不同厂商的模型做备用，定期做效果对比，确保降级后核心指标下降不超过 10%。

8.2 忽视 Token 成本导致月底账单爆炸

Token 成本在项目初期不明显，因为量小。但用户量一上来，成本增长是指数级的。我见过一个项目，上线三个月后月 Token 成本从几百块涨到几万块，就是因为没有做成本监控和优化。

控制成本的手段有几个：一是上下文压缩，前面讲过的分层和摘要策略能省不少；二是模型路由，简单任务走小模型；三是缓存，相同或相似请求复用结果；四是输出长度限制，在提示词里明确要求简洁输出。这几个手段组合起来，成本能降 50% 以上。

8.3 评估集和线上场景脱节

评估集如果只由工程师构造，很容易偏向技术场景而忽略业务场景。我建议评估集的构建一定要有产品经理和领域专家参与，他们更清楚真实用户会怎么用、哪些边界情况容易出问题。

另外，评估集要定期用线上真实数据更新。我一般每个月从线上日志里采样一批新数据，人工标注后加入评估集。这样评估集才能跟上用户行为的变化，不会越来越偏离实际。

8.4 提示词改了但没通知下游

提示词变更的影响范围往往被低估。改一个分类提示词，可能影响下游的工单路由、报表统计、用户通知。如果变更前没有评估影响范围，很容易引发连锁问题。

我的做法是提示词变更走变更流程：先评估影响范围，再在测试环境验证，然后灰度发布，最后全量。变更记录要同步给相关方，特别是下游依赖方。这个流程听起来重，但比起出事后排查，成本低得多。

8.5 把 AI 系统当传统系统做容量规划

传统系统容量规划看 QPS 和响应时间，AI 系统还要看 Token 吞吐量和上下文长度分布。同样 QPS 下，上下文长度翻倍，Token 吞吐量就翻倍，成本和延迟都会受影响。

做容量规划时，我一般按 Token 吞吐量来估算资源需求，而不是 QPS。同时要预留缓冲，因为用户输入长度分布可能突变，比如某个营销活动导致大量长文本输入。缓冲系数我一般设 1.5 到 2 倍，具体看业务波动性。

9. 写在最后的一些个人体会

AI Native 架构这件事，技术选型只占三成，剩下七成是工程习惯和团队协作方式的转变。我见过技术栈很先进但效果一般的项目，也见过技术栈朴素但效果很好的项目，差别往往在于团队有没有把提示词当代码管、有没有把评估当测试做、有没有把上下文当接口设计。

如果让我给正在起步的团队一个建议，我会说：先把模型调用收口，再把提示词管起来，然后建一个哪怕只有 20 条样本的评估集。这三件事做完，你就已经超过大多数团队了。剩下的路由、降级、可观测性，都是在这三件事的基础上自然生长出来的。

另外，别追求一步到位。AI 原生架构是个演进过程，不是一次重构就能完成的。我自己的项目也是跑了半年多才把各个模块补齐，中间还推翻重来过两次。重要的是保持迭代，每次解决一个具体问题，积累下来就是一套适合自己的架构方案。