企业级Agent模型路由：不止fallback，更是服务契约治理

1. 为什么“配个备用模型”根本挡不住企业级 Agent 的真实崩塌

“给 Agent 配个备用模型”——这句话我去年在三个不同行业的客户现场都听过。一次是某金融后台的智能工单分派系统，一次是某制造企业的设备故障语音诊断助手，还有一次是某教育平台的个性化学习路径生成模块。他们清一色把“模型路由”理解成 YAML 文件里加一行 fallback_model: qwen2-7b，然后在测试环境跑通了 5 条样例就宣布上线。结果呢？工单系统在大促日峰值时因主模型响应超时触发 fallback，但备用模型因未预热、无缓存、token 限流策略不一致，平均延迟飙到 8.2 秒，客服坐席界面直接卡死；设备诊断助手在产线凌晨批量上传音频时，fallback 切换后因备用模型不支持长上下文，把 3 分钟的振动频谱分析压缩成两句话，漏判了轴承早期微裂纹；教育平台更典型——主模型返回 JSON 格式学习建议，备用模型却输出 Markdown 混排文本，前端解析器直接抛出 uncaught SyntaxError，整个学习面板白屏。

这根本不是“有没有备用模型”的问题，而是把模型路由当成静态配置开关，完全忽略了企业级 Agent 运行在真实业务链路中的四个刚性约束：语义一致性约束（不同模型对同一指令的理解偏移）、协议契约约束（输入/输出格式、字段名、嵌套结构的强约定）、资源水位约束（GPU 显存、KV Cache 占用、并发请求数的非线性增长）、状态连续性约束（多轮对话中历史 context 的截断策略、tool call 记录的还原能力）。你配的不是“备用模型”，而是一个未经契约验证、未做水位压测、未对齐状态管理的“潜在故障点”。我在某实验室做过一组对照实验：同样用 Llama3-8B 作主模型、Qwen2-7B 作 fallback，在 1000 QPS 下模拟网络抖动触发切换，未做任何适配的裸切方案失败率 63%；而完成语义对齐（prompt engineering + output schema validation）、协议加固（统一 JSON Schema + strict parsing wrapper）、水位隔离（独立 GPU 实例 + request queue length throttling）后，失败率压到 1.7%。差的不是模型能力，是整套路由机制的设计深度。

提示：企业级 Agent 的容灾不是“模型级冗余”，而是“服务契约级冗余”。当你只改 config 文件里的 model_name，你加固的是配置项，不是服务。

关键词里没写，但所有踩过坑的团队最后都补上了这三类词：语义对齐、协议契约、状态连续性。它们才是标题里“远不止”三个字真正指向的暗礁区。接下来我会拆解一个真实落地的七层路由架构——它不靠魔法，只靠可验证、可压测、可回滚的工程细节。

2. 七层路由架构：从请求入口到模型执行的全链路控制平面

企业级 Agent 的路由不能只发生在“调用前选模型”这一个点。真正的控制力必须渗透到请求生命周期的每个关键断点。我们最终落地的架构不是“一个路由中间件”，而是由七个协同工作的控制层组成的有机体。每一层解决一类特定风险，且层与层之间有明确的职责边界和数据契约。下面按请求流经顺序展开，重点讲清楚每层“为什么必须存在”以及“不建这一层会出什么具体故障”。

2.1 第一层：入口流量染色与业务标签注入

所有请求进入 Agent 网关的第一件事，不是解析 prompt，而是打上业务身份标签。这个动作常被跳过，但后果严重。比如某教育平台的“错题讲解”和“知识点拓展”两个功能，表面看都是问答，但前者要求模型严格引用教材原文页码（需启用 RAG 的 citation 模式），后者允许自由发挥（可关闭 RAG 降延迟）。如果路由层只看 raw prompt 文本相似度，就会把高优先级的错题请求错误导向低延迟但无 citation 能力的轻量模型。

我们的实现是在 API 网关层（如 Kong 或自研网关）强制要求客户端传入 x-business-scenario 头，值为预定义枚举：homework_explanation / knowledge_expansion / exam_simulation。网关校验该 header 存在且合法后，才将请求转发至下游，并将此标签注入请求上下文（context.Context）。后续所有路由决策都基于此标签，而非 NLP 模型对 prompt 的模糊分类。

注意：业务标签必须由客户端显式声明，禁止服务端自动推断。推断意味着耦合，而企业系统最怕的就是隐式耦合——当某天“错题讲解”新增了语音输入功能，自动推断逻辑若未同步更新，路由就会静默失效。

2.2 第二层：语义敏感度分级与模型能力画像

拿到业务标签后，第二层要回答：“当前请求对语义精度有多敏感？” 这决定了能否容忍模型间的能力落差。我们定义了三级敏感度：

• L1（强契约）：输出必须严格符合 JSON Schema（如工单分派需返回 {“category”: string, “urgency”: “high|medium|low”, “assignee”: string}），字段缺失或类型错误即失败；
• L2（弱契约）：允许格式宽松但语义不可偏移（如设备诊断需准确识别“轴承”“齿轮”“电机”等实体，但返回形式可为列表或段落）；
• L3（无契约）：纯创意生成（如营销文案润色），仅需内容相关性。

对应地，我们为每个接入模型构建了能力画像表，不是简单标“能力强/弱”，而是量化其在各敏感度下的实测表现：

路由决策时，若请求标记为 L1，则只允许调度 Llama3-70B；若为 L2，Qwen2-7B 可作为 fallback；L3 场景三者皆可。这个表每天凌晨用固定测试集自动刷新，确保画像始终反映真实水位。

2.3 第三层：实时水位熔断与动态权重分配

即使模型能力匹配，资源不足也会让路由失效。第三层是实时水位熔断器，它不依赖静态阈值，而是基于两个动态指标：

• GPU 显存占用率 > 85%：触发降级，拒绝新请求并返回 429；
• P95 延迟 > 当前模型基线延迟 × 1.8：触发权重衰减，将该模型在负载均衡池中的权重从 100 降至 30，持续 60 秒观察。

关键设计在于“基线延迟”的计算方式：不是取全局平均，而是按业务标签+敏感度组合维护独立滑动窗口（15 分钟，步长 1 分钟）。例如，“homework_explanation + L1”的基线延迟是过去 15 分钟内该组合下所有成功请求的 P95 值。这样，当错题讲解流量突增导致 Llama3-70B 延迟升高时，熔断器只影响该业务线，不会误伤知识拓展等其他场景。

我们曾在线上验证：当某次模型服务因底层 GPU 驱动异常导致延迟毛刺时，该层在 2.3 秒内将 Llama3-70B 权重降至 0，流量自动切至 Qwen2-7B，用户侧无感知；待驱动修复后，权重在 60 秒内平滑恢复。整个过程无需人工介入。

2.4 第四层：协议契约验证与 Schema 强制归一化

这是最容易被忽视、却最致命的一层。很多团队以为“fallback 模型输出格式不同，前端适配下就行”，但实际中，前端适配成本远超预期。某教育平台曾为兼容两种模型输出，前端写了 370 行条件判断代码，后来新增一个模型又得重构——技术债滚雪球。

我们的解法是：所有模型输出必须经过第四层的 Schema 验证与归一化。无论模型原生输出是 JSON、Markdown 还是纯文本，路由层强制要求：

1. 模型必须返回标准 JSON（通过 system prompt 约束 + output parser wrapper 保障）；
2. JSON 必须符合预定义的业务 Schema（如 homework_explanation 的 Schema 定义了 required 字段、type 类型、enum 枚举值）；
3. 若模型输出不合规，路由层启动三步归一化：
   • Step1：用轻量模型（Phi-3-mini）做格式修复（prompt：“将以下文本转为符合 Schema 的 JSON，缺失字段填 null，错误类型转为 string”）；
   • Step2：若 Step1 失败，触发降级策略（如 L1 请求直接返回 500，L2 请求返回带 warning 字段的降级 JSON）；
   • Step3：记录归一化失败事件，用于模型画像更新。

这套机制让前端永远只对接一个 Schema，新增模型只需通过 Schema 验证即可接入，彻底解耦。

2.5 第五层：状态连续性锚点与上下文智能截断

多轮对话中，fallback 切换最怕“断档”。用户问：“上一条说的轴承温度阈值是多少？”，主模型刚返回“85℃”，切换到备用模型后，它可能因上下文长度限制，把前序对话全截掉，只能回答“我不知道”。

第五层专治此病。我们设计了状态锚点机制：在每轮对话的 system prompt 中，强制插入一个结构化锚点：

[STATE_ANCHOR] { "last_entity": "bearing", "last_value": "85℃", "last_intent": "temperature_threshold_query" } [/STATE_ANCHOR]

这个锚点由路由层在每次请求前动态注入，内容来自上一轮响应的结构化解析（利用第四层的 Schema 归一化结果）。当 fallback 触发时，锚点仍保留在上下文中，且因其体积小（< 200 token），几乎不增加截断风险。备用模型看到锚点，就能精准延续语义，而不是从零开始。

实测显示，加入锚点后，跨模型切换的多轮连贯性从 41% 提升至 89%。更重要的是，锚点内容可审计——运维人员能直接查日志看到“本次切换时模型记住的关键状态是什么”，排查问题效率倍增。

2.6 第六层：工具调用（Tool Calling）的跨模型事务一致性

企业 Agent 很多依赖外部工具（查数据库、调 API、执行代码）。主模型调用 tool A 成功，fallback 模型却因不支持该 tool 或参数格式不同而失败，导致业务逻辑中断。

第六层实现了Tool Calling 的事务封装。所有 tool 调用不直接暴露给模型，而是由路由层提供统一的 tool registry：

• 每个 tool 在 registry 中注册：name、description、input_schema、output_schema、execution_handler（Python 函数）；
• 模型只输出 tool name 和 input 参数（JSON 格式）；
• 路由层校验 input 是否符合 schema，调用 execution_handler 执行，再将 output 按 output_schema 归一化后返回给模型。

这样，无论主模型还是 fallback 模型，面对的都是同一套 tool 接口。即使 fallback 模型本身不支持 function calling，路由层也能用规则引擎模拟其行为（如对“查库存”tool，fallback 模型只需输出 {"sku": "A123"}，路由层自动调用库存 API 并注入结果）。

2.7 第七层：全链路可观测性与熔断决策回溯

最后一层不是控制层，而是决策审计层。它不干预路由，但记录一切：

• 每次请求的完整决策链：业务标签 → 敏感度判定 → 水位检查 → 模型选择 → Schema 验证结果 → 锚点内容 → tool 调用日志；
• 每次 fallback 触发的根因：是水位超限？Schema 不合规？还是延迟毛刺？
• 每个模型的实时健康分（基于 L1 合规率、延迟、错误率加权计算）。

这些数据接入 Grafana，运维可随时查看：“过去 1 小时，Qwen2-7B 在 L2 场景的 Schema 归一化失败率为何突然升至 12%？” —— 点开详情发现是某次 prompt 更新引入了新字段，立即回滚。没有这一层，你永远在猜“为什么 fallback 了”，而不是“哪里需要优化”。

这七层不是理论模型，而是我们线上运行 11 个月的生产架构。它把“模型路由”从一个配置项，升级为一个可监控、可验证、可演进的服务治理平面。

3. 语义对齐实战：让不同模型说出“同一句话”

技术人容易陷入一个误区：认为“模型能力越强，路由越简单”。但现实恰恰相反——能力越强的模型，其输出越“自由”，语义偏移风险反而越高。Llama3-70B 生成的 JSON 可能字段丰富但包含冗余信息，Qwen2-7B 输出则可能过度精简丢失关键字段。真正的难点不在“选谁”，而在“怎么让它们说一样的话”。

我们花了三个月打磨语义对齐方案，核心是三层约束体系：Prompt 层强制、Parser 层校验、Post-process 层兜底。下面以“工单分派”场景为例，展示如何让两个模型输出完全一致的 JSON。

3.1 Prompt 层：用结构化指令替代自然语言描述

很多人写 system prompt 是：“你是一个工单分派助手，请根据用户描述判断工单类别和紧急程度。” 这种描述对 Llama3-70B 可能生成 5 个字段，对 Qwen2-7B 只生成 2 个。我们必须用机器可读的指令替代人类语言。

最终采用的 system prompt 模板：

You are a ticket routing agent. Output ONLY valid JSON matching this exact schema: { "category": "string, one of: ['network', 'server', 'database', 'application', 'security']", "urgency": "string, one of: ['critical', 'high', 'medium', 'low']", "assignee": "string, format: 'team-{name}' or 'user-{id}', if unknown return 'unassigned'", "confidence_score": "number between 0.0 and 1.0, estimate your certainty" } Do NOT output any text before or after the JSON. Do NOT include comments or explanations.

注意三个关键点：

• Schema 直接内联：避免引用外部文档，模型无需额外查找；
• 枚举值明确列出：防止模型发明不存在的 category（如 “cloud”）；
• 格式强约束：“ONLY valid JSON”、“NO text before/after”、“NO comments”。

我们在测试中发现，Qwen2-7B 对这种强约束 prompt 的遵循率比宽松 prompt 高 34%，而 Llama3-70B 因其更强的指令遵循能力，提升不明显，但输出稳定性（字段缺失率）下降了 22%。

3.2 Parser 层：基于 JSON Schema 的硬校验与自动修复

Prompt 再强，模型也会出错。Parser 层是第二道防线。我们不使用通用 JSON 解析器，而是为每个业务场景定制 Schema Validator：

# homework_explanation_validator.py from jsonschema import validate, ValidationError import json SCHEMA = { "type": "object", "required": ["explanation", "source_reference"], "properties": { "explanation": {"type": "string"}, "source_reference": { "type": "array", "items": { "type": "object", "required": ["page", "chapter"], "properties": { "page": {"type": "integer", "minimum": 1}, "chapter": {"type": "string"} } } } } } def parse_and_validate(raw_output: str) -> dict: try: data = json.loads(raw_output) validate(instance=data, schema=SCHEMA) return data except json.JSONDecodeError as e: # Step1: 尝试用正则提取 JSON 片段 import re json_match = re.search(r'\{.*\}', raw_output, re.DOTALL) if json_match: try: data = json.loads(json_match.group()) validate(instance=data, schema=SCHEMA) return data except: pass # Step2: 调用 Phi-3-mini 做格式修复 repair_prompt = f"Fix this to match schema {SCHEMA}: {raw_output}" repaired = lightweight_model_call(repair_prompt) return json.loads(repaired) except ValidationError as e: # Step3: 返回带 error 字段的降级结构 return { "explanation": "无法生成有效解释", "source_reference": [], "error": str(e) }

这个 validator 不是“解析失败就报错”，而是有三级修复策略。线上数据显示，约 18% 的原始输出需经修复才能达标，其中 63% 由正则提取解决，32% 由 Phi-3-mini 修复，仅 5% 进入降级。

3.3 Post-process 层：基于业务规则的语义归一化

即使 JSON 结构正确，语义仍可能漂移。例如，用户问：“服务器 CPU 占用 95% 怎么办？”，Llama3-70B 可能返回"category": "server"，而 Qwen2-7B 返回"category": "performance"。两者都算“正确”，但破坏了下游系统的分类一致性。

Post-process 层用轻量规则引擎做最终归一化：

# category_normalizer.py CATEGORY_MAPPING = { "performance": "server", "cpu": "server", "memory": "server", "disk": "server", "network_latency": "network", "packet_loss": "network", # ... 50+ 条映射 } def normalize_category(data: dict) -> dict: if "category" in data and data["category"] in CATEGORY_MAPPING: data["category"] = CATEGORY_MAPPING[data["category"]] return data

这个映射表由业务方维护，每次新增故障类型只需加一行，无需改动模型或 prompt。它把“语义理解”的责任，从不可控的大模型，转移到可控的、可审计的业务规则上。

语义对齐不是追求模型输出一模一样，而是确保业务系统接收到的信号，无论上游模型是谁，都指向同一个业务含义。这需要 Prompt 的刚性、Parser 的韧性、Post-process 的柔性，三者缺一不可。

4. 容灾不是“切过去”，而是“切得稳、切得准、切得可逆”

很多团队把容灾等同于“主挂了，切到备”。但企业级场景中，最危险的时刻不是主模型宕机，而是主模型“半死不活”——延迟飙升、错误率爬升、输出质量波动。这时盲目切换，可能把系统拖入更糟的境地。真正的容灾，是一套有节奏、有依据、有退路的渐进式决策机制。

我们设计的容灾流程分为四个阶段：探测 → 评估 → 切换 → 验证，每个阶段都有明确的触发条件和退出机制，绝不是“一刀切”。

4.1 探测阶段：多维指标联合告警，拒绝单一阈值

传统做法是设一个“延迟 > 2s 就切”。但延迟受网络、输入长度、模型版本等多重影响，单一阈值误报率极高。我们采用多维滑动窗口联合探测：

• 延迟维度：过去 2 分钟内，P95 延迟 > 基线 × 1.8 且持续 5 个采样点（每 15 秒采样）；
• 错误维度：过去 2 分钟内，HTTP 5xx 错误率 > 5% 且绝对错误数 ≥ 10；
• 质量维度：过去 2 分钟内，Schema 验证失败率 > 15%（由第四层提供）；
• 资源维度：GPU 显存占用率 > 90% 持续 30 秒。

只有当至少两个维度同时满足条件，才进入评估阶段。这大幅降低了误触发率。上线后，探测误报从每周 12 次降至每月 1 次。

4.2 评估阶段：基于业务影响的切换优先级排序

探测到异常后，不立即切换，而是评估“切了之后，业务受损是否小于不切”。我们为每个业务场景定义了影响系数矩阵：

评估阶段会查询当前 fallback 模型的实时能力画像（第二层数据），计算其在目标场景下的预测表现。例如，若工单分派场景探测到异常，而 Qwen2-7B 的 L1 合规率当前为 86.7%（低于 95% 门槛），则评估结论为“不满足切换条件”，转而启动主模型的快速重启流程，而非强行切换。

4.3 切换阶段：灰度发布式流量迁移

确认可切换后，绝不“全量切”，而是灰度迁移：

• Step1：先将 1% 流量切至 fallback，持续 30 秒；
• Step2：监控这 1% 流量的 P95 延迟、错误率、Schema 合规率；
• Step3：若全部达标，升至 5%；否则立即回退；
• Step4：重复此过程，每次翻倍，直至 100%。

整个过程全自动，无需人工干预。灰度机制让我们在某次上线新 fallback 模型时，提前 47 秒捕获到其在长文本场景下的内存泄漏（P95 延迟在 5% 流量时突然跳变），及时终止迁移，避免了全量事故。

4.4 验证阶段：双写日志与业务效果回溯

切换完成后，最关键的一步是验证业务效果是否真如预期。我们采用双写日志 + 业务指标比对：

• 所有切换后的请求，路由层同时记录两条日志：
  • Model Log：原始模型输出、耗时、状态；
  • Business Log：经第四层归一化后的输出、下游系统处理结果（如工单是否被正确分派）、用户反馈（如有）；
• 每小时跑一次比对脚本，计算：
  • 切换后工单分派准确率 vs 切换前 24 小时均值；
  • 切换后设备诊断召回率 vs 切换前 24 小时均值；
  • 切换后用户点击“有用”按钮的比例变化。

若任一业务指标下降超过 5%，自动触发告警，并建议回退。这个机制让我们在一次因 fallback 模型 RAG 索引未同步导致的知识检索准确率下降事件中，2 小时内定位根因并修复，而非让用户持续体验劣质服务。

容灾的终极目标不是“系统不死”，而是“业务不损”。每一个切换决策，都必须回答：“这次切换，是让业务更好，还是更糟？”

5. 经验复盘：那些文档里不会写的血泪教训

以上所有架构和流程，都不是一纸蓝图，而是踩着无数坑、熬过无数夜、被线上事故反复锤炼出来的。这里分享几个最痛的教训，它们没有出现在任何官方文档里，却是决定项目成败的关键。

5.1 教训一：不要相信模型的“自我报告”能力

初期我们让模型在输出 JSON 时，自己计算并填入confidence_score字段。Llama3-70B 报 0.98，Qwen2-7B 报 0.95，看起来都很自信。但实测发现，当模型遇到模糊表述（如用户说“服务器好像不太快”），Llama3-70B 的 confidence_score 仍高达 0.92，而实际分类错误率 68%；Qwen2-7B 报 0.75，错误率 41%。模型的“自信”和“准确”几乎无关。

解决方案：confidence_score改为路由层计算。我们用一个轻量分类器（XGBoost），输入特征包括：prompt 长度、关键词密度、实体识别置信度、与历史相似请求的匹配度，输出真实可信度分数。这个分数与实际错误率相关性达 0.83，远超模型自报。

5.2 教训二：Fallback 模型的“冷启动”比主模型更致命

主模型常年在线，GPU 显存、KV Cache 都是热的。但 fallback 模型可能几小时甚至几天才调用一次，首次调用时要加载模型权重、初始化 CUDA 上下文、预热推理引擎，耗时可达 3-5 秒。用户看到的就是“卡顿”，然后疯狂刷新，进一步加剧主模型压力，形成恶性循环。

解决方案：对所有 fallback 模型实施主动预热。我们用一个轻量心跳服务，每 30 秒向每个 fallback 模型发送一个空请求（{"prompt": "ping"}），保持其 GPU 显存常驻、CUDA 上下文活跃。预热请求不计入业务指标，但确保真实请求来临时，延迟与主模型无异。上线后，fallback 首请求延迟从 3200ms 降至 210ms。

5.3 教训三：日志里藏着最真实的路由瓶颈

我们曾长期困惑：为什么在 70% GPU 利用率时，延迟就开始爬升？监控图表显示一切正常。直到有一天，我导出了一分钟内的所有请求日志，按时间戳排序，手动数了数——发现每秒有 120 个请求涌入，但路由层的并发处理队列最大只设了 100。超出的 20 个请求在队列里排队，平均等待 1.8 秒，这 1.8 秒就是“神秘延迟”的来源。

解决方案：路由层的所有内部队列（请求队列、模型调用队列、归一化任务队列）都必须有独立监控和动态伸缩。我们用 Prometheus 暴露routing_queue_length和routing_queue_wait_time_seconds指标，当队列等待时间 P95 > 100ms，自动扩容队列长度。这个改动让 P95 延迟曲线变得平滑，再无毛刺。

5.4 教训四：业务方永远比技术方更懂“什么是失败”

有一次，教育平台反馈“fallback 后学习建议质量下降”。我们查日志，Schema 合规率 99.8%，延迟只高 12%，觉得没问题。直到和教研老师一起看样例，才发现：主模型会把“二次函数顶点公式”拆成三步推导（适合初学者），fallback 模型直接给结论（适合优等生）。对“错题讲解”场景，这不是技术失败，而是教学法失败。

解决方案：在能力画像中，加入业务效果维度。我们邀请教研老师标注 500 个 fallback 输出，按“步骤清晰度”“类比恰当性”“易错点提示”打分，生成业务质量分。这个分数和 L1 合规率同等重要，共同决定 fallback 是否可用。技术指标保证“能跑”，业务指标保证“该跑”。

这些教训没有高深算法，全是琐碎细节。但正是这些细节，决定了你的 Agent 是“可用”，还是“好用”，抑或是“被用户骂着用”。

6. 落地 checklist：一份可直接抄作业的实施清单

理论讲完，最后给你一份可直接落地、逐项核对的 checklist。它不讲原理，只列动作，每项都对应前文某个环节，确保你上线时不漏关键点。

6.1 必做项（上线前必须完成）

• [ ]业务标签体系建立：定义至少 5 个核心业务场景枚举值（如 homework_explanation, device_diagnosis），并强制网关校验 header；
• [ ]模型能力画像表初始化：为每个接入模型跑 1000 次标准测试集，记录 L1 合规率、L2 实体召回率、P99 延迟，存入数据库；
• [ ]七层路由代码集成：确认入口染色、语义分级、水位熔断、Schema 验证、状态锚点、Tool 封装、可观测性日志全部接入主服务；
• [ ]Fallback 模型预热服务部署：确保每个 fallback 模型每 30 秒接收一次 ping 请求；
• [ ]双写日志与业务指标比对脚本上线：能每小时自动计算切换前后业务指标变化；
• [ ]灰度切换自动化流程验证：在预发环境完整走通 1%→5%→10%→100% 切换流程，记录各阶段耗时。

6.2 强烈建议项（上线后 2 周内完成）

• [ ]业务效果标注启动：邀请 3 位业务方专家，对 500 个 fallback 输出进行教学/诊断/分派效果打分，生成业务质量分；
• [ ]Confidence Score 替换：停用模型自报 confidence，上线路由层 XGBoost 分类器；
• [ ]状态锚点模板库建设：为每个业务场景定义标准锚点结构（如设备诊断锚点含 last_sensor_id, last_anomaly_type），并写入文档；
• [ ]熔断决策回溯看板搭建：在 Grafana 创建仪表盘，能按小时查看“触发熔断次数”、“根因分布（延迟/错误/质量）”、“切换成功率”。

6.3 长期运营项（持续迭代）

• [ ]能力画像每日自动刷新：凌晨 2 点用最新测试集重跑，更新数据库；
• [ ]Fallback 模型轮换机制：每季度评估各 fallback 模型表现，淘汰末位，引入新模型；
• [ ]业务标签扩展机制：当新增业务场景时，能 1 小时内完成标签定义、网关配置、路由规则添加；
• [ ]灾难演练常态化：每月一次，随机 kill 主模型进程，验证全流程切换时效与业务影响。

这份清单不是理想化的“应该做”，而是我们团队在 11 个月中，用线上事故换来的“必须做”。勾选一项，就少一个线上火警。

我在某实验室带新人时总说：企业级 Agent 的路由与容灾，本质上是一场与不确定性的谈判。你无法消除不确定性（模型会飘、GPU 会抖、网络会抖），但你可以用确定性的工程手段，把它框在可控范围内。那些看似繁琐的七层架构、语义对齐、灰度切换，不是为了炫技，而是为了让每一次“模型切换”，都成为一次无声的、可靠的、业务无感的服务交接。