当一个团队第一次把 AI 编码助手接入开发流程时，大家讨论最多的是“哪家模型写代码更强”。但往往运行两三个月后，讨论的话题就会彻底改变，变成“这个需求是让模型直接生成，还是走规则引擎？”“模型一旦抖动，线上哪些业务可以降级？”这种从“模型选型”到“架构取舍”的转变，才是 AI 原生开发真正开始的地方。
这篇文章想聊两件事：一是 AI 原生开发到底在重排团队的哪些东西，二是 LLM 网关作为模型依赖的入口，怎么把故障取舍落到可执行的工程策略上。如果你正处于团队引入 AI 但还没有统一入口的阶段，或者已经在维护多个大模型调用但疲于应付稳定性问题，这篇文章会给你一个相对完整的框架。
1. AI 原生开发在重排什么：三个层面的真实变化
很多人把 AI 原生开发理解为“用 AI 写代码”，这个理解太浅了。它更准确的定义是：把大模型当成系统里的一个原生依赖，围绕它的特性重新设计团队分工、研发流程和系统架构。
1.1 角色层：核心工作从“写代码”变成“定义质量”
传统开发流程中，研发团队的核心产物是代码，测试团队的核心产物是用例，交付团队关心的是上线结果。引入大模型之后，最难的不是让模型生成一段代码，而是怎么定义“生成结果是对的”。
于是团队里开始出现以前没有的角色：
- 提示词工程师：负责把业务需求转化成模型能理解的输入，并且持续优化输入结构。
- 评测工程师：负责建设评测集、设定评分标准，判断模型输出是否满足业务要求。
- 模型运营人员：负责跟踪模型升级、成本消耗、调用量变化，类似传统运维对服务器的关注。
- AI 基础设施工程师：负责维护 LLM 网关、模型路由、熔断降级、日志链路。
这不是把原来的开发岗位改个名字，而是新增了一类“围绕模型输出的质量与运营”的岗位。真正的 AI 原生团队，不会把所有工程师都变成提示词工程师，但一定会有人专门扛起“输出质量”这个指标。
1.2 流程层：开发流程从“代码驱动”变成“评测驱动”
传统敏捷开发里，需求被拆成用户故事，开发完成后提测，测试人员根据验收标准验证功能。AI 原生开发多了一个非常关键的环节：评测回归。
原因很简单。传统代码的行为是确定的，同一个输入永远得到同一个输出。大模型不是，它的输出有随机性，模型的版本升级也可能带来行为漂移。如果不建评测集，你今天精调好的提示词，可能因为模型一个微小的版本变化就整体失效。所以评测集在 AI 原生开发里的地位，已经等同于传统开发里的自动化测试套件。
这里有一个团队最容易踩的坑：把提示词当代码管理，却没有把评测结果当测试报告管理。提示词确实应该进 Git，但更重要的是，每次修改提示词或切换模型后，必须拿同一套评测集跑一遍，对比分数，再决定合并还是回滚。评测驱动的流程一旦建立起来，AI 改造才算是融入了研发闭环。
1.3 架构层：模型从“API 调用”变成“外部核心依赖”
更隐蔽的变化发生在架构层面。早期接入 AI 只是“请求第三方 API”，一个服务里写死一个 URL，配上 API Key 就算完。但当一个系统里几十个服务都在调用大模型时，模型就不再是一个普通外部接口，而是一个核心依赖。
既然是核心依赖，它就需要像数据库、缓存、消息队列一样被治理：
- 需要统一入口，而不是每个服务各自直连。
- 需要超时和重试，因为模型 API 的延迟和可用性不受你控制。
- 需要熔断和降级，因为模型服务在极端情况下一定会出问题。
- 需要成本控制，因为 token 消耗是持续性的真金白银。
这就是 LLM 网关登场的背景。它解决的并不是“调用模型好不好用”的问题，而是“当模型成为核心依赖之后，如何治理这个依赖”的问题。
2. LLM 网关是什么：和传统 API 网关的区别
2.1 没有网关时是什么状态
先看一个没有 LLM 网关的典型状态。一个中型团队，前端页面要 AI 总结，客服系统要 AI 回复，内容团队要 AI 写摘要，运营要 AI 做标签。每个项目各自接入模型供应商，各自维护 API Key，各自处理超时和重试。结果往往是：
- 密钥散落在不同项目的环境变量里，权限失控。
- 每个项目对同一个模型写了三套完全不同的超时和重试逻辑。
- 一个模型服务抖动，所有直连它的服务一起跟着抖。
- 月底成本核算时，根本说不清哪个场景消耗了多少 token。
- 出了问题想排查链路，每个项目都有日志，但拼不起一条完整链路。
这些痛点叠加起来，就是 LLM 网关要解决的原始需求。
2.2 LLM 网关的定义
LLM 网关是介于应用服务和大模型 API 之间的中间层。它负责统一接收应用的模型调用请求，做认证鉴权、模型路由、速率限制、超时重试、熔断降级、成本统计和链路追踪，再转发给真实的大模型供应商。
一句话概括：应用不再关心“这次请求会打到哪个模型、怎么控制失败、怎么统计成本”，这些全部交给网关。
2.3 与传统 API 网关的差异
很多团队会问：我们已经有 Kong、APISIX、Spring Cloud Gateway，为什么还需要 LLM 网关？这里的核心差异是治理维度不同。
| 维度 | 传统 API 网关 | LLM 网关 |
|---|---|---|
| 核心对象 | HTTP 接口、微服务 | 大模型调用、提示词、token |
| 路由依据 | URL、请求头、服务名 | 任务类型、成本预算、场景要求 |
| 故障处理 | 超时、限流、熔断 | 超时、重试、降级到备用模型或本地预案 |
| 成本感知 | 无 | 按 token 计费、配额控制、结果缓存 |
| 输出管理 | 只转发响应 | 可能需要校验输出格式、处理敏感信息 |
| 典型指标 | QPS、成功率、延迟 | token 消耗、生成质量、降级命中率 |
传统网关负责的是“流量怎么走”，LLM 网关负责的是“模型怎么选、失败怎么办、成本怎么控”。如果团队已经用了微服务网关，不等于不需要 LLM 网关，两者会同时存在：应用先经过微服务网关，再到 LLM 网关，最后才到模型供应商。
3. LLM 网关的核心能力拆解
3.1 模型路由：按场景把请求分发给最合适的模型
模型路由是 LLM 网关最基础也最有价值的能力。它的目标不是把请求随便丢给一个模型，而是结合任务类型、成本和延迟要求做决策。
举一个常见场景：一个应用里同时有摘要生成、意图识别、代码解释、情感分析四个功能。摘要和解释需要理解能力强的大模型，意图识别和情感分析这类简单分类任务，小模型完全能胜任。如果所有请求都走同一个大模型，不仅成本高，延迟也上不去。通过网关配置，就可以让简单任务路由到小模型，复杂任务路由到大模型。
以下是一个配置风格的示例，重点演示路由思路，字段名以实际网关产品为准：
# llm-gateway-route.yaml routes: - name: content-summary match: scene: summary priority: high target: provider: openai-compatible model: gpt-4.1-mini fallback_model: gpt-4o-mini timeout: 30s max_tokens: 2048 - name: intent-classification match: scene: intent priority: low target: provider: openai-compatible model: gpt-4o-mini fallback_model: claude-3-haiku timeout: 10s max_tokens: 512路由策略一般包含三个要素：匹配条件、目标模型、兜底模型。匹配条件可以是业务场景、用户等级、输入长度等；目标模型是正常情况下使用的模型；兜底模型是主模型失败或超时后切换的备选。
这里容易踩坑的地方是：路由条件不要只写场景名，还要考虑该场景对延迟和成本的真实要求。网关配置不是写好就永远不动，而是需要根据线上调用量和成本报表持续调整。
3.2 超时、重试与幂等：模型 API 不像数据库那么好伺候
模型 API 的失败模式和数据库有本质区别。数据库连接失败可以快速重试，因为事务有明确的幂等控制；而大模型生成是“重试一次就可能生成完全不同的结果”，而且每次都消耗 token。
所以在配置重试时，要区分可重试和不可重试的错误：
- 可重试：HTTP 429（限流）、503、504、网络超时。
- 不可重试：400（请求参数错误）、401（鉴权失败）、403（无权限）。
429 是特别典型的场景。模型供应商为了控制负载，会对调用频率做限流。一旦出现 429，正确的做法不是立刻重试，而是采用指数退避策略，每次等待时间翻倍，比如 1s、2s、4s，同时加上随机抖动，避免所有请求同时重试形成惊群效应。
网关层还要做幂等控制。应用在发起模型调用时，应该生成一个唯一的 request_id，网关根据 request_id 判断当前请求是否已经重试过，避免同一业务被重复提交产生多次扣费。
3.3 熔断与降级：故障取舍的真正落点
熔断是链路上防止故障扩散的成熟手段。在 LLM 网关里，熔断器会对每个模型实例记录连续失败次数，当失败率达到阈值时，熔断器打开，后续请求不再打到真实模型，而是直接走降级逻辑。等冷却时间结束后，进入半开状态，放小部分流量探测，确认模型恢复后再关闭熔断器。
降级是故障取舍的核心动作。模型不可用时的降级方案通常有以下几类：
- 切换备用模型：主模型挂了，切到另一个供应商的模型。
- 返回本地缓存：相似请求之前有过成功结果，直接复用。
- 使用静态模板：针对特定场景，返回预设文案或规则处理结果。
- 简化生成：放弃复杂输出，返回一个更短、更保守的回答。
- 直接报错：明确告诉用户当前功能不可用。
这几种方案的业务代价完全不同。切换备用模型最接近原体验，但成本高；返回缓存快但没有新内容；静态模板稳定但不够智能；直接报错最透明但可能流失用户。没有绝对正确的方案，只有根据业务等级选择的方案。
4. 故障取舍：LLM 网关面对的真实选择题
“故障取舍”不是理论话题，而是每天可能发生的工程决策。我们把几个关键选择展开来看。
4.1 取舍一：宁可报错，还是宁可降智？
这是最核心的选择。当模型不可用或输出质量不稳定时，你是给用户一个明确的错误提示，还是退而求其次，给一个质量略低但可用的结果？
一个客服售后场景就是很好的例子。如果 AI 客服依赖的模型服务故障，直接提示“系统繁忙”当然最诚实，但用户会非常不满。更优的做法可能是：降级到 FAQ 检索或人工客服入口，用户至少能获得咨询路径。这里的“降级”不等于“坏结果”，而是用一个更可控的结果替代不可控的结果。
反过来，在医疗建议、法律意见这类高风险场景中，宁可拒绝回答也绝不能给出质量不达标的生成结果。因为低质量答案的代价远超“服务暂时不可用”。团队在进行故障取舍前，必须先把业务划分等级，再对号入座选择降级策略。
4.2 取舍二：重试到底几次？熔断到底多敏感？
重试和熔断天然存在张力。重试太多可能放大故障，把已经拥堵的模型打得更慢；熔断太敏感则可能在模型短暂抖动时就把业务切到降级，造成不必要的体验下降。
推荐的做法是给不同场景配置不同的参数。核心支付链路要少重试、快熔断；智能摘要类非核心功能可以容忍更长重试。具体数值没有统一标准，但团队应当明确一个目标：网关的默认配置只是起点，线上运行后要根据错误率、延迟、降级命中率持续调优。
4.3 取舍三：成本和体验，谁优先？
模型调用是按 token 计费的。同一个问题，用大模型解决要花 1 元，用小模型只要 0.1 元，但生成质量可能差一点。当业务规模上来后，这个成本差距会非常显著。
LLM 网关的价值在于让这个取舍变得可见、可配置。通过网关，你可以监控每个场景的 token 消耗，甚至给不同项目设置配额。这样团队负责人不需要每天看账单，只要看网关报表就能知道哪个业务在烧钱，然后主动决定是否下调模型档位或开启结果缓存。成本控制不是上线后才做的事，而是网关配置阶段就应该考虑的事。
4.4 故障取舍的本质
说到底，故障取舍要回答的问题是：系统在降级状态下，保留什么、舍弃什么。保留的是用户的访问能力、关键路径、基础体验；舍弃的是复杂性、完全智能化、极端准确性。这个判断不是技术团队单独能定的，必须结合业务目标，才能在故障发生时做出恰当的取舍。
5. 从工具引入到 AI 原生开发：团队落地的四步路径
5.1 第一步：单点试点，不铺开
团队从零转向 AI 原生时，最容易犯的错误是全面开花。建议先选一两个高频、低风险的场景试点，比如“客服自动摘要”“代码提交信息生成”。把这些场景跑通，本质上是验证团队对模型输出质量的定义能力。
试点阶段不急着引入网关，但要记录调用方式、失败率、成本和数据回流环节，为后面统一管理做准备。
5.2 第二步：统一入口，收敛模型调用
当试点场景被验证有效，其他业务开始跟进时，就应该引入 LLM 网关。这一步的核心目标是收敛：所有模型调用走同一个入口，统一认证、统一日志、统一成本统计、统一失配策略。
统一入口带来的价值很快会显现：新场景接入从“找 API、配 Key、写重试逻辑”变成“在网关加一条路由”，周期明显缩短；故障时也能在网关层快速确认是模型问题还是业务问题。
5.3 第三步：建立评测集，让质量回归成为习惯
统一网关之后，下一步是建设评测集。一个最小可用的评测集包含三类数据：
- 正常输入：覆盖高频业务场景的标准问题。
- 边界输入：容易混淆、容易出错的输入。
- 恶意或异常输入：测试提示词注入、超长输入、空输入。
每次修改提示词、切换模型、升级模型版本，都要用同一套评测集跑回归。评测结果直接决定这个变更能不能上线。
5.4 第四步：架构角色化，固化职责边界
当团队规模变大，基础设施团队负责维护 LLM 网关、模型账号、配额和稳定性指标；业务团队负责各自的提示词、评测集和场景回落策略。两者的边界要清晰：业务团队不应直接改网关底层配置，基础设施团队也不应替业务团队决定“这个场景能不能接受降智”。职责边界清晰后，AI 原生开发的团队结构才算稳定下来。
6. 可落地的配置示例与代码片段
6.1 降级策略配置示例
以下是一个按业务等级配置降级策略的示例，假设网关框架支持类似 DSL 的配置：
# fallback-policy.yaml fallback_policy: - scene: customer_service level: P0 fallback_order: - switch_model - cache_result - static_template static_template: "当前智能服务繁忙，请拨打人工客服电话 400-XXX-XXXX。" circuit_breaker: failure_threshold: 5 open_timeout: 30s - scene: content_summary level: P1 fallback_order: - switch_model - simplify_generation simplify_generation: max_tokens: 128 prompt_template: "请用一句话总结原文：{{input}}"这段配置表达了两层含义：P0 客服场景宁可降级到人工入口，也不能让用户得不到任何响应；P1 摘要场景可以接受简化生成，但保留核心功能。策略中的 fallback_order 从左到右依次尝试，实际字段名以网关实现为准。
6.2 调用侧处理降级结果的 Java 示例
应用侧调用 LLM 网关时，并不需要知道网关内部选择了什么降级方案，只需要判断返回结果是否还在可接受范围内。以下是一个最小示例：
// 文件路径：src/main/java/com/example/gateway/client/LlmGatewayClient.java public class LlmGatewayClient { private final RestTemplate restTemplate; private final String gatewayUrl; public LlmGatewayClient(RestTemplate restTemplate, String gatewayUrl) { this.restTemplate = restTemplate; this.gatewayUrl = gatewayUrl; } public LlmResponse call(String scene, String prompt) { LlmRequest request = new LlmRequest(); request.setScene(scene); request.setPrompt(prompt); request.setRequestId(UUID.randomUUID().toString()); request.setTraceEnabled(true); try { ResponseEntity<LlmResponse> resp = restTemplate.postForEntity( gatewayUrl + "/v1/chat", request, LlmResponse.class ); LlmResponse body = resp.getBody(); if (body == null || body.isFallback()) { // 网关层返回了降级结果，这里由业务决定是否接受 log.warn("llm gateway returned fallback response, scene={}", scene); } return body; } catch (HttpServerErrorException e) { // 网关本身不可用或模型全部失败，走业务兜底逻辑 return LlmResponse.businessFallback("AI 服务暂时不可用，请稍后重试。"); } catch (ResourceAccessException e) { // 网络超时，不盲目重试，交给上层决定 log.error("llm gateway request timeout, scene={}", scene, e); return LlmResponse.businessFallback("AI 服务超时，请稍后重试。"); } } }这段代码的关键点在于：应用侧永远不直接选择模型，只指定场景；网关层是否降级、切换到哪个模型，由网关决定。这样业务代码保持简单，故障决策集中在基础设施层。上层的 LlmResponse 需要包含 isFallback 字段，用来告知调用方当前结果并非模型原始输出，业务方可以据此决定是否展示。
6.3 评测回归脚本示例
评测回归是 AI 原生开发里最需要固化下来的工程环节。下面是一个简化版的 Python 评测脚本，读评测集、调用网关、计算得分：
# 文件路径：eval/regression_eval.py import json import time import requests EVAL_SET_PATH = "./eval_set.json" GATEWAY_URL = "http://localhost:8080/v1/chat" def load_eval_set(path): with open(path, "r", encoding="utf-8") as f: return json.load(f) def call_model(scene, prompt): payload = {"scene": scene, "prompt": prompt, "request_id": f"eval-{time.time()}"} resp = requests.post(GATEWAY_URL, json=payload, timeout=30) resp.raise_for_status() return resp.json() def evaluate(case): result = call_model(case["scene"], case["prompt"]) generated = result.get("output", "") # 这里的评分函数可以替换为人工评分、LLM 评分或规则匹配 if case["type"] == "contains": return float(any(kw in generated for kw in case["keywords"])) if case["type"] == "exact": return float(generated.strip() == case["expected"].strip()) return 0.0 def main(): cases = load_eval_set(EVAL_SET_PATH) scores = [evaluate(case) for case in cases] total = sum(scores) / len(scores) print(f"eval score: {total*100:.2f}%") for i, case in enumerate(cases): print(f"{i+1}. [{case['scene']}] {case['name']}: {scores[i]}") if __name__ == "__main__": main()对应的评测集文件可以长这样：
[ { "name": "客服摘要包含订单号", "scene": "customer_summary", "type": "contains", "prompt": "请总结这段客服对话，并提取订单号：...", "keywords": ["20240101"] }, { "name": "意图识别准确", "scene": "intent_classification", "type": "exact", "prompt": "我想退掉这个订单", "expected": "退款意图" } ]评测脚本的运行方式是：
python eval/regression_eval.py如果输出分数低于上一次基线，说明当前提示词或模型变更属于回归，应阻止合并。这个最小评测框架可以很快扩展到多维度评分和自动回归任务中。
7. 常见问题与排查思路
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 模型调用偶尔超时 | 未配置超时与重试，或超时时间过短 | 查看网关日志和调用链路耗时 | 设置合理超时，对限流和5xx采用指数退避重试 |
| 一个模型故障拖垮所有业务 | 业务直连模型，没有统一网关 | 查看模型供应商状态和各服务调用关系 | 引入 LLM 网关，统一熔断和降级 |
| 模型不可用时用户收到负面体验 | 没有降级策略或降级策略只返回报错 | 看错误率和降级命中率指标 | 按业务等级配置多级降级方案 |
| 成本每个月都在涨 | 没有成本配额，所有请求都走大模型 | 按场景统计 token 消耗报表 | 开启模型分级路由和结果缓存，设置配额 |
| 模型升级后效果明显变差 | 没有评测集和回归流程 | 对比升级前后评测分数 | 建立场景评测集，升级前跑回归 |
| 网关配置变更导致线上故障 | 缺少配置管理和灰度发布 | 检查配置变更记录 | 网关配置纳入 Git 管理，走灰度发布 |
8. 最佳实践与工程建议
8.1 先定义“可接受失败率”，再选技术方案
引入网关之前，先和业务方对齐一个指标：哪些场景可以接受降级，哪些场景宁可报错也不能降智。这个共识会直接影响网关的熔断阈值和降级策略设计，比任何技术选型都重要。
8.2 网关配置要有版本管理
LLM 网关的路由规则、降级策略、触发阈值，都应该像应用代码一样纳入版本管理。每次修改需要走评审，记录变更原因。否则模型行为变化时，很难判断是模型升级导致的，还是网关配置导致的。
8.3 令牌和密钥管理要独立
不要把所有模型的 API Key 放在业务项目的环境变量里。密钥应统一由网关管理，业务侧通过网关的鉴权机制访问。涉及密钥的配置要使用独立的密钥管理系统，避免密钥出现在日志和代码仓库中。同时建议用最小权限原则，不同业务线只暴露自己需要的模型能力。
8.4 模型切换一定要灰度
无论是切换模型供应商还是升级模型版本，都不要一次性切全量流量。建议先切 5% 到 10% 的流量，观察评测分数、用户反馈、错误率和成本变化，确认稳定后再逐步放量。这里评测集和网关配置灰度发布缺一不可。
8.5 监控指标要覆盖到模型层
传统监控主要看 QPS、成功率、延迟。AI 场景下至少还要增加：
- token 消耗总量和分场景消耗。
- 模型路由命中分布，即每个模型承接了多少请求。
- 降级命中率，即多少请求走了降级策略。
- 平均生成耗时，即首 token 延迟和总生成时长。
这些指标直接反映模型这个外部依赖的健康状况，也是故障取舍是否奏效的证据。
9. 总结与后续学习方向
AI 原生开发对团队的重排，不是说要把团队切成“用 AI 的”和“不用 AI 的”，而是要把围绕模型的质量定义、评测回归、网关治理这些新任务固化到组织结构里。LLM 网关在其中承担的是“基础设施承重墙”的角色，它把模型不可靠、成本不可控、调用分散这些老问题集中到一层解决，让业务团队只需要关心场景本身。
如果你想在一周内落地一个最小闭环，可以按这个顺序做：先选一个核心场景，定义它的降级策略；再搭一个最简单的统一入口，把直连模型的调用收敛起来；最后写几条评测用例，跑一次回归脚本。不要把战线拉得太长，先让团队看到“模型故障时系统依然可控”这个效果，比任何架构设计都更有说服力。
值得继续深入的方向包括：模型评测框架的设计与自动化、多供应商模型路由策略、token 成本建模与配额治理，以及网关层如何处理流式输出下的熔断与降级。这些都是 AI 原生开发走向成熟阶段绕不开的工程细节，也是 LLM 网关真正发挥价值的地方。
