AI 网关如何按成本/质量做模型级路由与降级？
AI 网关按成本/质量做模型级路由，即根据请求特征与当前各模型状态，选择最合适的模型。路由维度：质量敏感（复杂问题、高价值用户）路由到强模型，成本敏感（简单问题、低价值）路由到弱模型；实时监控各模型的质量/延迟/成本，某模型质量下降或成本突增时自动降低其权重或剔除。降级策略：按模型能力分层（强模型→中模型→弱模型），主模型故障或超时降级到次模型，或降级到缓存/规则兜底。网关维护"模型池+路由策略+健康状态"，动态调整路由。核心是"成本-质量-可用性"的实时权衡。
模型级路由的本质是"把请求动态匹配到成本与质量最优的模型"。结合健康状态与降级层级，网关才能既控成本又保可用。
高峰期请求排队与限流如何兼顾公平与优先级？
高峰期限流与排队要兼顾公平与优先级。公平性：不能让少数用户独占资源，用公平队列（fair queueing）或按租户/用户分桶限流，保证每个用户获得合理份额；优先级：付费/高价值/实时性高的请求优先（优先级队列），低优先级请求排队或降级。实现：令牌桶/漏桶限流按用户与全局双层；排队用带优先级的队列（高优先级先出队，低优先级等待）；超时/降级策略（低优先级排队超时降级到弱模型或缓存）。关键是把"公平分配"与"优先级保障"结合，避免高优先级饿死低优先级或低优先级拖垮高优先级。
公平与优先级平衡的核心是"分桶配额 + 优先级队列"。按用户分桶保证公平，按优先级排队保证保障，两者配合度过高峰。
模型级联（小型优先，失败升级大模型）的触发条件是什么？
模型级联是"先让小模型/低成本模型处理，失败或质量不足时升级到大模型"。触发条件：小模型输出置信度低（自评估分数低于阈值）、任务复杂度超出小模型能力（如长文档、复杂推理）、工具调用失败、校验器判定小模型结果不合格（如格式错、引用缺失、事实不符）、或用户显式要求高质量。升级触发要可控，避免频繁升级导致成本失控；可用"小模型+校验器"判断是否升级，而非无条件升级。级联还要防止小模型反复失败反复升级的抖动（设升级次数上限）。
模型级联的本质是"用便宜模型兜底，用校验触发升级"。触发条件要能准确识别"小模型不可靠"，否则级联就失去了成本优势。
Token 预算耗尽时的用户级限速与排队体验如何设计？
用户级 token 预算耗尽时，需限速并保障体验。设计：为每个用户设定 token 预算/配额，耗尽时触发限速（拒绝新请求、降级、排队）；排队体验设计——如果预算可恢复（如按时间窗口重置），让用户排队等待，并给出预期等待时间与额度提示；若预算不可恢复，需付费或升级；对实时性高的请求在预算耗尽时优先降级（弱模型、缓存）而非直接拒绝。体验上要透明：明确告知用户"额度用尽、何时恢复、如何提升"，避免静默失败。关键是把"限速"与"体验"结合，不让用户困惑。
Token 预算限速的关键是"透明与可预期"。明确的额度提示、恢复时间与降级路径，能降低预算耗尽带来的挫败感。
基于语义的路由（简单问题走小模型）如何工程实现？
基于语义的路由是把"简单问题路由到小模型、复杂问题路由到大模型"。工程实现：用一个轻量路由分类器/模型判断问题复杂度（simple/complex），或用小模型本身先评估；把问题特征（长度、是否含数字/推理、领域、历史）作为信号；路由决策后把请求分发到对应模型。实现要点：路由分类器要准（误分简单问题到大模型浪费成本，误分复杂问题到小模型质量问题）；路由规则可配置（阈值、白名单）；对分类不确定的问题做保守处理（走大模型）。可结合"小模型试跑+校验器"判断是否需升级。
语义路由的本质是"把问题复杂度作为路由信号"。分类器准确性与保守策略决定成本与质量平衡，是控成本的关键技术。
AI 流量治理的可观测性指标设计与看板如何做？
AI 流量治理可观测性要覆盖整个生命周期：指标分层——请求量/流量分布（按模型、按路由）、限流与排队（被限流数、排队数、等待时长、拒绝数）、降级（降级率、降级原因）、模型健康（各模型质量/延迟/成本/错误率）、成本（token 用量、单请求成本）。看板设计：按"流量-限流-降级-模型健康-成本"分层展示，支持按模型/租户/区域/版本下钻；关键指标设告警（限流率过高、降级率突增、成本突增）。还要观测"治理动作本身"（路由决策分布）以验证治理策略有效。目的是一眼看清"流量从哪来、被怎么治理、治理效果如何"。
可观测性的本质是"让治理动作可量化、可验证"。分层指标+多点下钻+告警，才能及时发现问题并验证治理策略。
多 Provider（多模型供应商）故障时的流量切换与优雅降级策略如何设计？
多 Provider 故障时需流量切换与优雅降级。设计：多 Provider 冗余（主备/多活），故障检测（健康检查、错误率、超时）发现 Provider 故障后自动切换流量到备 Provider；切换用"故障转移"机制（重试到其他 Provider）；优雅降级——Provider 全部故障时降级到缓存答案、弱模型、离线兜底或拒绝并给出友好提示，避免雪崩。关键：切换要快（目标短时间）、可回切（故障恢复后切回）、切换期间请求不丢失（队列/重试）；对 Provider 级错误要区分"可重试"与"不可重试"。多 Provider 还要求 prompt/输出格式兼容，便于无缝切换。
多 Provider 治理的核心是"冗余 + 故障切换 + 优雅降级"。容错分层（单 Provider 故障→切换，全部故障→降级），保证 AI 服务在供应商故障时仍可用。
区域流量就近接入与跨境合规的路由约束如何设计？
区域流量路由要同时满足就近接入与跨境合规。就近接入：请求路由到最近的区域节点，减少延迟。跨境合规约束：特定区域（如数据驻留要求）的数据不能出境，路由必须把请求锚定到该区域内的节点与存储，禁止跨区域调度；跨境流动需合规评估。设计上路由决策带"区域+合规"双约束：先按合规确定请求可去的区域集合，再在合规集合内就近选择；对强约束区域（数据不出境）强制区域路由，禁止 fallback 到其他区域。路由要记录区域归属供审计。核心是"合规优先，就近其次"。
区域路由的本质是"合规是硬约束，就近是优化目标"。在合规可用的区域集合内就近选点，避免为延迟牺牲数据合规。
灰度流量与生产流量在网关层的隔离手段是什么？
网关层隔离灰度与生产流量，防止串扰。手段：请求带灰度标识（标签/bucket），网关按标识路由到对应版本的处理链路；灰度与生产用独立的缓存命名空间、独立的限流配额、独立的路由规则，避免灰度流量影响生产或生产缓存污染灰度；灰度流量与生产流量在指标上分桶统计（不混在一起）。隔离维度包括：版本隔离（不同版本不同处理）、缓存隔离（不同缓存键）、配额隔离（灰度单独配额，不挤占生产）、观测隔离（灰度指标单独看板）。核心是"灰度全程带标识，各环节按标识隔离"。
网关隔离的本质是"用灰度标识贯穿全链路，按标识隔离版本/缓存/配额/观测"。隔离保证灰度不污染生产、生产不干扰灰度。
流量治理规则（限流、路由、降级）的热更新与版本管理如何做？
流量治理规则（限流阈值、路由、降级策略）需热更新与版本管理。热更新：规则存配置中心，变更实时下发且无需重启网关，快速生效；版本管理：规则版本化，每次变更记录版本、变更内容、责任人，支持回滚到上一版本；变更安全：先做规则校验（语法、范围、阈值合理性），可灰度下发规则（先小流量验证再全量），异常时一键回滚。关键是把治理规则当作"代码资产"管理，热更新 + 版本化 + 回滚，避免规则变更造成治理失效或误伤。
治理规则热更新与版本管理的本质是"把规则当作可安全变更的配置"。实时下发+版本回滚+灰度验证，让规则调整既快又安全。
AI 依赖（模型/检索/工具）故障注入演练如何设计？
AI 依赖故障注入演练通过人为制造故障验证系统韧性。注入对象：模型（超时、报错、返回垃圾）、检索（索引不可用、召回失败）、工具（超时、异常、格式错误）。注入方式：在测试环境/影子环境注入，模拟延迟、错误、限流、降级；可用故障注入工具（chaos mesh）或代码桩。演练验证目标：系统能否检测故障（告警）、能否降级（降级到缓存/弱模型/兜底）、能否优雅处理（不崩溃、不返回错误结果）、故障恢复后能否回切。演练后校准熔断阈值与恢复策略。核心是"把故障注入当作可重复的演练流程"。
故障注入演练的本质是"主动制造故障来验证韧性"。覆盖模型/检索/工具三类依赖，验证检测、降级、恢复全链路，并校准治理参数。
工具调用超时/异常时，Agent 的降级路径如何设计？
工具调用超时/异常时，Agent 需有降级路径。设计：给工具调用设超时与重试（可重试的异常重试，不可重试的跳过）；降级路径分层——A. 重试工具（改参数/换工具）；B. 跳过该工具，用已有信息回答；C. 改用备选工具或方式（如从 API 改为检索文档）；D. 明确告知用户"工具不可用"，给出不依赖该工具的答案或拒绝。Agent 要能"感知工具失败"并决定走哪条降级路径，而不是卡死或产生错误结果。同时记录工具故障供监控。核心是"工具失败不阻塞，Agent 有明确的降级决策"。
工具降级的本质是"把工具故障变成 Agent 可决策的分支"。超时/重试/跳过/备选/告知，让 Agent 在工具不可用时仍能优雅完成任务。
模型输出格式异常（JSON 错误、字段缺失）时，如何用 schema 校验并兜底？
模型输出格式异常（JSON 解析失败、字段缺失、类型错误）需 schema 校验与兜底。做法：定义输出 schema（JSON Schema），模型输出后做结构校验；校验失败时兜底——重试（让模型修正输出）、宽松解析（容错提取字段）、基于规则修复（补默认值、类型转换）、或降级到预定义兜底响应。关键：schema 校验要快（不拖慢响应）；对常见错误（多余字段、字段缺失）做兼容处理；对频繁格式异常要回溯（改 prompt 的格式约束、加 few-shot）。兜底原则是"宁可返回格式正确的兜底，也不返回格式错误的原始输出"。
schema 校验的本质是"在模型输出与下游消费之间加协议层"。校验+修复+兜底，保证下游永远拿到结构正确的数据，防格式异常穿透。
关键业务链路的 AI 降级开关如何设计，避免雪崩（cascade failure）？
关键业务链路依赖 AI 时，需降级开关避免 AI 故障拖垮整个业务。设计：在 AI 调用前设"熔断/降级开关"，AI 故障或超负荷时快速切断 AI 调用，走降级路径（缓存答案、规则引擎、人工兜底、返回默认），保护业务主链路不被 AI 拖垮；开关要自动+手动（自动检测异常触发，手动一键），并支持快速恢复；降级开关要"隔离"——AI 故障不影响非 AI 部分；用熔断器（circuit breaker）监控 AI 调用的错误率/超时，超阈值开闸降级。核心是"AI 是可选依赖，关键链路有兜底，AI 故障不联动崩溃"。
避免雪崩的本质是"把 AI 变成可隔离、可降级的依赖"。熔断+降级开关+业务兜底，保证 AI 故障时关键业务仍可用。
多 Agent 系统的级联失败混沌演练应如何设计？演练结果如何校准熔断阈值与恢复策略？
多 Agent 系统（Agent 间存在依赖）的级联失败（一个 Agent 故障传导到其他 Agent）需混沌演练验证。设计：注入某 Agent 故障（超时、错误、限流），观察级联效应——是否其他 Agent 被拖垮、是否雪崩、是否产生错误传播；演练覆盖 Agent 间调用、共享依赖、级联重试。演练后校准：根据级联影响调整熔断阈值（避免误熔断又避免级联）、超时与重试策略（限制重试防止放大）、降级路径（Agent 故障时如何隔离）；校准恢复策略（故障恢复后的回切与恢复节奏）。核心是"演练发现级联路径，用结果校准治理参数"。
多 Agent 级联演练的本质是"模拟故障在依赖链上的传播"。通过演练识别级联路径，校准熔断/重试/降级参数，防止单点故障放大。
从故障演练反推的架构改进闭环如何做？
故障演练的意义在于"发现问题→改进架构→再演练验证"的闭环。流程：演练暴露架构弱点（如单点依赖、缓存污染、降级不生效、重试风暴）；针对问题做架构改进（去单点、加兜底、隔离依赖、优化重试）；把改进纳入架构标准；再通过演练验证改进是否生效。闭环沉淀：把演练发现的问题与改进记录成文档/评测，形成"演练-改进-再演练"的持续循环。关键是不能"演练完就结束"，必须把发现转化为实际架构改进并回归验证。
架构改进闭环的本质是"演练不是为了表演，而是为了发现并修复缺陷"。问题→改进→再验证的循环，让韧性持续提升。
流量治理的配额与预算：按租户/功能的 token 预算、动态配额与超支拦截的工程实现如何做？
token 预算与配额治理按租户/功能维度控制成本。工程实现：为每个租户/功能设 token 预算（月/日/请求级），实时累计 token 用量（请求层记录输入/输出 token）；动态配额——按实时用量与剩余预算动态调整（高优先级租户配额优先、用量紧张时收紧）；超支拦截——用量接近或超过预算时拦截（拦截新请求、降级到弱模型、限流、告警），防止预算失控。实现上用量统计要实时准确（每请求记账），配额检查在请求入口做，超支时走降级而非直接拒绝。核心是"预算计量 + 动态配额 + 超支拦截"三层。
配额治理的本质是"把成本控制在预算内"。按租户/功能计量、动态调配额、超支拦截，能防止个别租户/功能拖垮整体成本。
Provider 限流（429）的退避与重试最佳实践是什么？
Provider 返回 429（限流）时的退避与重试最佳实践：尊重 Retry-After 头（按服务端建议的等待时间重试）；指数退避（exponential backoff）+ 抖动（jitter），避免大量请求同时重试造成重试风暴；限制总重试次数（避免无限重试消耗且放大限流）；对 429 区分"可重试"（等待后可重试）与"不可重试"（如配额永久耗尽，应走降级而非重试）；重试只对幂等请求安全。同时自身要做限流（客户端限流避免触发 Provider 限流）。核心是"退避+抖动+有限重试+尊重服务端提示"。
429 处理的本质是"尊重限流系统的信号，避免重试放大"。指数退避+抖动+重试上限+Retry-After，是防止重试风暴的标准实践。
AI 应用混沌工程与传统微服务的异同是什么？
传统微服务混沌工程：注入网络故障、实例故障、依赖故障，验证系统弹性的标准做法。AI 应用混沌工程与之相同的是目标（验证韧性、发现弱点）与手段（故障注入、演练）。差异在于：AI 应用多了"模型/检索/工具"这类软依赖，故障形态多样（模型退化、幻觉、质量下降、格式异常、成本突增），这些"软故障"难以像网络故障那样精确注入；AI 的故障注入还包括 Prompt 漂移、数据变化、语义维度退化；验证也复杂（质量指标主观）。因此 AI 混沌工程除了注入硬故障，还要注入"软故障"（降级模型、污染数据、异常输出）并观察质量与成本影响。
AI 混沌工程是传统混沌工程在"AI 软依赖"上的扩展。共性在方法，差异在故障类型从硬故障扩展到质量/语义/成本类软故障。
故障复盘中的 AI 特有根因（Prompt 漂移、数据变化）如何识别？
传统故障根因多为代码/基础设施，AI 故障还有特有根因。Prompt 漂移（Prompt 功能正常但输入分布或意图变化导致输出质量下降，或 Prompt 被无意改动）；数据变化（知识库更新、文档增删、embedding 变化导致检索质量变化）；模型更新（供应商侧模型行为变化，即使代码没变）；上下文漂移（长期对话中上下文污染）。识别方法：对比"同一输入在不同时间的输出"；检查 Prompt 版本是否被改动；检查知识库/索引是否有变更；监控模型端行为变化（供应商发布说明）；用评测集回归验证。定位时把"代码变更→Prompt 变更→数据变更→模型变更"四类因素逐一排查。
AI 特有根因的本质是"行为变化未必来自代码"。Prompt/数据/模型三者的非代码变更都可能引发故障，复盘时要纳入排查范围。
韧性目标（SLO）在 AI 应用中的可量化定义是什么？
AI 应用的 SLO 要可量化。传统 SLO 是可用性（如 99.9%）、延迟（P95）、错误率；AI 应用还需补充质量类 SLO：正确率/准确率（评测集达标率）、引用支持率、可用性（请求成功率）、有效响应率（非空/非降级响应占比）、成本（单请求成本）。定义要具体：如"响应可用性 ≥ 99.5%""TTFT P95 ≤ 3s""引用支持率 ≥ 90%""降级率 ≤ 5%"。SLO 要可测量（有埋点）、可告警（超阈值告警）、可复盘（达成/未达成记录）。关键是把"质量"也量化成 SLO，而非只盯可用性。
AI SLO 的本质是"把可用性+质量+成本都量化成可承诺的目标"。可测、可告警、可复盘，才能驱动韧性治理。
模型灰度的评估闭环：影子流量、指标对比（质量/延迟/成本）与放量决策的流程如何设计？
模型灰度评估闭环：第一步影子流量——把生产流量复制给新模型离线对比，无风险采集真实表现；第二步指标对比——用统一评测集+影子结果对比新旧模型的质量（准确率、引用支持率）、延迟（TTFT、P95）、成本（单请求 token 成本），量化差异；第三步放量决策——按指标达标情况决定放量节奏（不达标则终止或调整，达标则按阶梯放量：5%→10%→…→全量），每阶段重新评估；全量后持续监控并纳入防回归。闭环是"影子→对比→决策→放量→监控→再评估"，关键是指标对比口径统一、决策有明确阈值。
灰度评估闭环的本质是"把灰度做成可验证、可决策的循环"。影子验证降低风险，统一指标对比提供依据，放量决策有阈值可循。
