可靠性、限流

• 限流维度
• 统一限流模型
• 配额管理

四类限制：1) 请求数（RPM/TPM 请求级）：单位时间请求次数；2) Token（输入/输出 TPM）：单位时间 token 消耗；3) 并发数：同时进行的请求数；4) Provider 配额：Provider 侧的限制（RPM、TPM、并发）。统一限流模型：按"租户 + 模型 + Provider"多维建立配额，用统一限流器（令牌桶/滑动窗口）管理四类维度，优先级：Provider 配额最硬（不可超），其次 Token（成本/配额），再请求数与并发。设计：限流键 = 租户/模型/Provider；用多层限流（租户级 → 模型级 → Provider 级）；输出 Token 需预留（未知输出长度按上限估算）。统一模型把四类限制放同一体系，用"配额分配 + 优先级 + 超限策略（拒绝/排队/降级）"。

四类限制相互关联（请求数、token、并发、Provider 配额），需统一管理。分层限流 + 多维配额 + 优先级，避免单一维度限流漏掉其他瓶颈。

• 多层限流
• 租户公平性
• 防止饿死

分层限流：1) 客户端层：客户端更节流，减少无效请求；2) 服务端层：全局限流，防整体过载；3) 租户队列层：按租户分队列/配额，隔离各租户；4) Provider 限额层：遵守 Provider 配额。防止大租户饿死小租户：1) 租户级配额：每个租户有独立配额（如最小保证），大小租户隔离；2) 公平调度：用加权公平队列（WFQ）或保证部分配额，按租户权重分配，但每个租户有最低保证；3) 防爆：大租户突发时限制其占用，给小租户保留额度；4) 优先级：付费/企业租户可优先但小租户不饿死。用"租户隔离 + 最小保证 + 公平调度"保证公平。

分层限流（客户端→服务端→租户→Provider）明确各层职责。防饿死靠"租户配额隔离 + 最小保证 + 公平调度"，避免大租户独占。

• Retry-After 尊重
• 指数退避与抖动
• 防重试风暴

避免重试风暴：1) 尊重 Retry-After：429/503 响应中的 Retry-After 头明确给出等待时间，客户端应等待该时间再重试，而非立即重试；2) 有上限的指数退避：退避按指数增长（如 1s,2s,4s...）但设上限（如 30s），防止无限增长；3) 抖动（jitter）：在退避时间加随机抖动，避免大量客户端同时重试造成"惊群"（重试风暴）；4) 重试次数上限：限制最大重试次数，超限则降级/放弃；5) 全局协调：网关统一处理重试，避免每个调用方各自重试。核心是"尊重信号 + 有上限退避 + 抖动 + 次数上限"，防止重试本身压垮系统。

重试风暴来自"所有客户端同时重试"。Retry-After 尊重、抖动、退避上限、次数上限 + 网关统一协调，防止重试放大故障。

• 副作用重试风险
• 幂等键设计
• 安全重试

有副作用调用（写库、发消息、下单）不能自动重试，因为重试可能"重复执行副作用"（重复扣款、重复发消息、重复写库），造成不可逆后果。要用幂等键实现安全重试：1) 幂等键设计：每次业务操作生成唯一幂等键（如 UUID，或由业务字段派生：订单号+动作），随请求传给服务端；2) 服务端存储幂等键与结果：对相同幂等键的重复请求返回首次结果，不重复执行；3) 键的粒度：按"业务动作"而非"请求"设计，保证同一业务操作重试命中同一键；4) 键的唯一性：全局唯一，避免不同操作冲突；5) 有效期：幂等键记录有 TTL，过期后允许新操作。有幂等键后，重试安全（重复请求返回同一结果）。无副作用（纯读）可自动重试。

副作用重试的根险是"重复执行"。幂等键让服务端识别重复请求并返回缓存结果，从而安全重试。纯读操作无此风险可自动重试。

• 超时预算
• 阶段分配
• 取消传播

端到端超时预算分配：设总超时（如 30s），按阶段分配子预算（排队 5s、检索 3s、模型 15s、工具 5s、生成 2s），各阶段用独立超时，防止某阶段占满总预算。分配原则：按阶段耗时特点（模型最耗时给最大预算）与重要性。取消传播：由"协调者/入口服务"负责在总超时或任一步超时时，向下游（Agent、工具、Provider）传播取消信号，释放资源。责任：调用发起方负责超时监控与取消传播，各阶段收到取消后停止并释放。用"总预算 + 分阶段子预算 + 协调者统一取消传播"保证端到端可控制。

超时预算要"总 + 分"，避免单阶段拖垮整体。取消传播由协调者统一负责，任一步超时即取消下游，避免资源悬空。

• 弹性模式组合
• 副作用重试
• 可靠性设计

组合：1) 断路器：检测 Provider/服务故障，快速失败并隔离，防级联；2) Bulkhead（舱壁）：按服务/租户/工具分隔离池，防某方耗尽整体资源；3) Fallback：故障时降级（备用模型、固定模板、缓存）；4) 幂等：重试安全（副作用去重）；5) 补偿：副作用已执行时反向补偿。组合逻辑：断路器识别故障 → Bulkhead 隔离资源 → Fallback 降级 → 对可重试调用用幂等安全重试 → 对已执行副作用用补偿。不能自动重试的副作用调用：写库、发消息、下单、扣款、发送邮件等有不可逆/重复后果的操作——这些必须用幂等键 + 人工确认，不能盲目自动重试。

弹性模式组合成"故障检测→隔离→降级→安全重试→补偿"的完整策略。关键是识别副作用调用，不能自动重试，用幂等与补偿。

• 三类故障识别
• 应急处置差异
• 故障分类

三类故障识别与处置不同：1) Provider outage（故障）：识别为 5xx/超时/连接失败，应急处置：切换备用 Provider、触发断路器、降级；2) rate limit（限流）：识别为 429 + Retry-After，应急处置：尊重 Retry-After、退避重试、降低并发、排队，不该切换 Provider（限流是暂时的配额问题而非故障）；3) quota exhausted（配额耗尽）：识别为 429/403 配额错误，应急处置：停止重试（配额耗尽重试无益）、升级配额、降级到其他 Provider/模型、通知计费。关键区别：outage 可切换 Provider 重试，rate limit 应退避等待，quota exhausted 应停止重试并升级配额。错误分类决定处置策略。

三类故障处置不同：outage 切换 Provider、rate limit 退避等待、quota exhausted 停止重试升级配额。错误分类是正确处置的前提。

• 断路器隔离
• 舱壁隔离
• 防级联失败

多 Provider 隔离：1) 断路器：每个 Provider 独立断路器，某 Provider 故障时快速打开（熔断），不再路由到它，避免持续失败与资源浪费；2) 舱壁（Bulkhead）：每个 Provider 有独立线程池/连接池/配额隔离，某 Provider 慢/满时只耗尽自己的舱，不拖垮其他 Provider 与整体；3) 路由策略：故障 Provider 熔断后，请求路由到健康 Provider（fallback）；4) 半开探测：熔断后定时半开测试，恢复后关闭。避免级联失败：隔离 + 熔断 + 降级，让单个 Provider 故障不影响整体。关键：每个 Provider 独立熔断与独立资源池，故障不扩散。

多 Provider 防级联靠"每个 Provider 独立断路器 + 独立舱壁资源池"。故障 Provider 被熔断隔离，请求 fallback 到健康 Provider，整体不受影响。

• 降级能力校验
• 能力矩阵
• 防静默缺失

降级到备用模型前要校验能力，防止"静默缺失"（备用模型看似可用但缺某能力）：1) 能力矩阵：维护能力注册表（模型支持工具调用、Schema、多模态、安全过滤器、输出格式），降级前查表确认备用模型具备所需能力；2) 运行时校验：降级时用能力探测（发测试请求验证工具/多模态/格式是否正常）；3) 输入校验：若请求涉及多模态/工具，备用模型不支持则不能降级（或降级时明确降级该能力）；4) 安全兜底：备用模型安全策略可能不同，降级后仍走安全过滤器；5) 监控告警：降级后监控能力相关指标，发现静默缺失及时告警。降级不是"换模型就完"，要校验能力完整。

降级风险是"备用模型能力不全但静默降级"。用能力矩阵 + 运行时探测 + 输入校验 + 安全兜底，确保降级不丢关键能力。

• 重试的副作用
• 系统恶化机理
• 盲目重试危害

"重试更多次"不等于"成功率更高"，因为：1) 若故障是系统性的（Provider 超载、限流、服务故障），重试只会增加负载，成功率不升反降；2) 重试消耗资源（并发、Token、网络），加重过载，形成"重试越来越多 → 系统越慢 → 更多失败"的恶性循环；3) 对副作用调用重试有重复副作用风险；4) 重试可能掩盖真实故障，延误根因定位。盲目重试恶化：放大过载、挤占正常请求、导致雪崩。正确做法：有上限、有退避、尊重 Retry-After、区分"可重试"与"不可重试"、过载时降级而非重试。

重试在"瞬时故障"有效，在"系统性过载"是毒药。盲目重试放大负载导致雪崩。区分故障类型、有上限退避、过载降级才是正确策略。

• 网关统一重试
• Retry-After 处理
• 透明化

由网关统一处理而不是每个调用方：1) 网关拦截 429 响应，读取 Retry-After，统一等待后重试，调用方无需感知；2) 网关做全局限流/退避协调，避免多个调用方各自重试造成重试风暴；3) 网关可做"排队"：把超限请求排队，按 Retry-After 释放，而不是立即拒绝；4) 网关对同一上游的请求做"汇聚重试"（多重调用方共享一次重试）；5) 调用方只需把"重试策略"交给网关，网关透明处理。用网关统一处理 Retry-After 与重试，让调用方简单、系统协调、避免风暴与重复。

网关统一处理 429/Retry-After 让"重试逻辑集中"，调用方简洁、全局协调、避免各自重试造成风暴。是网关的职责之一。

• Token 限流预估
• 输出长度不确定性
• 余量预留

TPM 限流难点：输出 Token 未知（请求前不确定 max_tokens 实际用多少）。预估与预留：1) 按最大输出估算：把每个请求按 max_tokens 上限计 TPM 消耗（保守），防止超限；2) 统计分布：用历史输出长度分布（P50/P95）预估，按 P95 预留余量；3) 预留余量：TPM 配额保留一定缓冲（如 20%），避免突发输出超限触发 429；4) 动态：监控实际输出长度，动态调整预留；5) 分级：长输出/大 max_tokens 请求单独配额。核心：因为输出未知，按"上限或统计高分位"预留，避免实际消耗超 TPM 导致限流失败。

输出 Token 未知导致 TPM 难精确。用"max_tokens 上限或历史高分位"预估 + 预留缓冲，防止突发超限，是安全的 TPM 限流设计。

• 半开状态
• AI 输出不确定性
• 熔断判定

熔断器半开（half-open）常规做法：放少量请求试探，成功则关闭熔断，失败则保持打开。AI 场景更难判定，因为：1) 输出随机性：LLM 输出可能因温度/采样而随机变化，即使成功也可能偶发质量差，无法用"一次成功/失败"可靠判定；2) 质量定义模糊：AI 场景"成功"不只是"无错误返回"，还包括"质量达标、安全、无幻觉"，判定复杂；3) 失败模式多样：限流、超时、生成错误、质量差都可能触发，需区分。应对：半开判定用"多请求统计"（成功比例、质量指标）而非单次；结合"错误类型 + 质量门槛"综合判定；半开探测用低风险流量。不能像传统服务那样"一次试探定成败"。

传统服务半开看"是否成功返回"，AI 输出随机且质量需评估，单次试探不可靠。半开判定需统计 + 质量维度 + 错误类型，而非单次成败。

• 降级告知
• UI 透明
• 用户体验

降级时 UI 应透明告知：1) 返回固定模板：UI 明确提示"当前为模板回复，可能不完全满足需求"，并提供联系人工/重新提问入口；2) 人工接管：UI 清晰引导"已为您转接人工"，显示转接状态；3) 备用模型：UI 提示"当前使用备用模型，回复质量可能受限"，并注明降级原因。告知原则：降级状态要可见（降级标识、原因）、可理解（非技术语言）、可操作（提供解决路径：重试、人工、降级提示）。避免"静默降级"（用户误以为正常结果）。降级是"业务连续性"的权衡，但要对用户透明。

降级要"透明可见"，避免静默降级误导用户。UI 明确降级类型、原因与解决路径，管理用户预期，保障体验。

• 重试计费透明
• 计费归属
• 租户透明

重试造成额外 Provider 计费，需向租户透明：1) 计费明细：账单区分"成功请求"与"重试请求"，重试的 Token 消耗单独列出，注明是重试导致；2) 计费策略：明确重试费用归属（是否计入租户、是否减免、是否限次），在计费规则中透明说明；3) 重试配额：限制可重试次数/量，超限的额外费用明确告知或需租户确认；4) 透明报告：转账单/报表展示重试次数、重试 token、重试费用占比，让租户了解；5) 避免大量重试：通过限流/降级减少无效重试，控制额外成本。原则：重试的额外成本要"可见、可查、归属明确"，不偷偷计入租户账单。

重试产生额外 Provider 费用，若悄悄计入租户账单会引发信任问题。账单明细化、策略透明、重试受限，让成本可见可查。

• 长 Retry-After 处理
• 降级策略
• 资源释放

长 Retry-After（如 30s）期间，客户端不应"阻塞等待"占用连接/线程资源，应降级：1) 立即返回降级响应（模板、备用模型、缓存结果），让用户及时得到响应；2) 异步排队：把请求放入队列，按 Retry-After 到期后后台重试，不阻塞同步连接；3) 释放连接：不让连接/线程挂起等待，降低资源占用；4) 告知用户：降级时提示"稍后可重试/已排队"；5) 合理策略：长 Retry-After 意味着 Provider 过载，重试价值低，降级/排队比等待更合理。核心：长等待期用"降级响应 + 异步处理 + 释放资源"，避免资源被占死不释放。

长 Retry-After 不应同步阻塞占资源。降级响应 + 异步排队 + 释放资源，既给用户及时反馈又不占用连接，是正确处理。

• 限流粒度分层
• 配额隔离
• 防单点耗尽

限流粒度分层：1) 用户级：每用户配额，防单用户滥用；2) 会话级：每会话配额，防长会话耗尽；3) 工具级：每工具配额，防某工具被高频调用耗尽共享；4) 模型调用级：每模型调用配额，防某模型被冲刷。防止单个工具/用户耗尽共享配额：给每个维度独立配额（工具配额、用户配额），用"共享配额 + 单维度上限"双重控制——共享配额限制总消耗，单维度上限防止单工具/单用户独占。限流键按"用户/会话/工具/模型"组合，优先级：高价工具/模型更严格。多级限流保证"整体不超，单个不失衡"。

多模态/工具链路要多粒度限流。每维度独立配额 + 共享配额上限，防止单工具或单用户耗尽共享资源，是"防单点耗尽"的关键。

• 网关统一能力
• 厂商特有能力保留
• 网关架构

模型网关统一：1) 认证：统一 API key/租户认证，下游 Provider 密钥集中在网关；2) 路由：统一路由（按模型/租户/策略选 Provider）；3) 限流：统一限流（请求/Token/并发/配额）；4) 重试：统一重试（退避、Retry-After、故障切换）；5) 成本：统一计费与用量统计；6) 观测：统一 trace/指标/日志。同时保留厂商特有能力：1) 用"能力抽象 + 透传"：网关统一抽象通用能力，厂商特有能力（特别的流事件、多模态、特定参数）通过透传/扩展字段保留，不强行抹平；2) 能力矩阵：记录各厂商特有能力，路由时按需启用；3) 兼容层：OpenAI 兼容 API 为通用入口，厂商特有 API 走扩展端点。网关做"统一横切 + 保留纵向特性"。

网关统一"横切能力"（认证/路由/限流/重试/成本/观测），但对厂商特有能力的"透传"保留，避免抹平差异。统一 + 扩展并存。

• 复杂度路由特征
• 可解释特征
• 反馈纠偏

任务复杂度路由：用可解释特征判断任务复杂度，路由到合适模型档位：1) 特征：请求长度、任务类型（检索/推理/创作）、工具数、是否需要多步推理、领域、历史反馈；2) 规则/分类器：用这些特征打分，简单任务路由 mini（快省）、普通任务路由标准、复杂任务（强推理）路由 reasoning 模型；3) 可解释：特征要可解释（为何路由到该档位可审计），用规则或可解释模型；4) 反馈纠偏：路由结果与实际反馈（用户满意度、任务成功率、质量评估）对比，发现"路由到 mini 但质量差"或"路由到 reasoning 但没必要"时，调整路由特征/阈值（纠偏）。用"可解释特征 + 反馈闭环"持续优化路由，兼顾质量与成本。

复杂度路由用可解释特征选档位，平衡质量与成本。反馈纠偏让路由随真实效果调整，避免"贪便宜选错档"或"浪费贵模型"。

• 网关架构差异
• 选型依据
• 自研场景

各网关架构差异：1) LiteLLM Proxy：开源、自托管、统一 OpenAI 兼容接口，支持多 Provider、路由、限流、观测，可自管理；2) Portkey：商业化 LLM 网关，路由、缓存、观测、成本管理，托管/自托管；3) OpenRouter：聚合多模型的市场，统一接口 + 自动路由，托管为主；4) Cloudflare AI Gateway：云原生边缘网关，缓存、限流、观测、可观测性，托管。选型依据：数据主权（自托管 vs 托管）、成本（托管按量 vs 自建）、运维能力、功能需求（路由/缓存/观测）、多区域合规。自研场景：强定制（特有路由策略、特有缓存、合规驻留、深度集成自有系统）、数据主权要求高、需深度控制、成本敏感（大规模自建更划算）。选型：合规与定制强 → 自研/开源自托管；快速上线 → 托管网关。

网关选型看"数据主权、成本、运维、功能、合规"。自研适合强定制、强合规、大规模成本敏感；托管适合快速上线。

• 路由特征
• 特征采集与验证
• 档位选择

任务复杂度路由基于可解释特征选档位：1) 特征：请求长度（Token 数）、工具数（调用工具数量）、领域（是否复杂领域）、推理需求（多步/数学/代码）、查询复杂度、历史反馈；2) 档位选择：规则/评分把特征映射到档位（mini/标准/reasoning），简单任务 mini、复杂任务 reasoning；3) 特征采集：在请求入口从请求/上下文/Agent 轨迹提取特征（结构化、可解释），记录到路由 decisions；4) 特征验证：用评估对比"路由决策 vs 实际质量/成本"，验证特征是否有效（某特征是否真能区分简单/复杂）、是否可解释、是否稳定；5) 迭代：用真实反馈调整特征与阈值。特征要"可解释、可采集、可验证"，保证路由决策可审计、可优化。

路由特征要可解释、可采集、可验证。规则/评分选档位，用"决策 vs 质量成本"验证特征有效性，并持续迭代优化。

• 能力矩阵
• 模型别名
• 版本固定

网关做能力矩阵、别名与版本固定：1) 能力矩阵：记录每个模型/版本的能力（工具、多模态、上下文、安全、价格），路由与选型时查表；2) 模型别名：用稳定别名（如 "chat-standard"）映射到具体模型版本，业务代码引用别名，不直接写死模型名；3) 版本固定：别名指向"固定版本快照"（如 gpt-5-2026-08），升级时显式改别名指向新版本，避免 Provider 同名模型自动升级；4) 升级控制：版本升级走"别名切换 + 评估 + 灰度"，不静默变化；5) 审计：记录别名→版本映射，可追溯。这样避免"同名模型升级"导致应用行为不可控变化，升级可评估、可回滚。

模型别名 + 版本固定 + 能力矩阵，让"模型变更"受控。业务用别名，升级通过显式切换别名 + 评估 + 灰度，避免静默升级的不可控。

• usage 字段统一
• 跨 Provider 计费
• 规范化

多 Provider 的 usage 字段命名与口径不同，需统一：1) 建立统一 usage 模型：定义标准字段（input_tokens、output_tokens、cache_read_tokens、cache_write_tokens、total_tokens），作为内部统一口径；2) 适配层：把各 Provider 的原始 usage 映射到统一字段（Provider 的 prompt_tokens→input_tokens、completion_tokens→output_tokens、cached_tokens→cache_read）；3) 评分/计费：统一字段后按统一价格计算成本，跨 Provider 可比；4) 保留原始：映射时保留原始 usage 供审计；5) 对账：统一字段用于与 Provider 账单对账。统一 usage 让成本统计、跨 Provider 对比、成本控制可落地。

各 Provider 的 usage 字段口径不一，需统一映射模型。适配层统一字段，计费、对账、成本对比才可比。

• 网关职责边界
• 单一职责 vs 大而全
• 架构权衡

网关应"以路由/横切为主，谨慎扩展"：1) 核心职责：认证、路由、限流、重试、计费、观测——这些是网关该做的横切能力；2) 超出路由的功能（缓存、压缩、向量化）需权衡：缓存能显著降本提效，可作为网关可选能力（但要有缓存正确性、隔离、失效设计）；压缩/向量化是重计算功能，放网关可能使其变重、耦合、难扩展。原则：网关保持"轻量、专注横切"，缓存可在网关做（收益大、通用），压缩/向量化等重业务功能放业务层/专用服务，避免网关"大而全"变难维护。按"是否通用、是否影响路由、是否高成本"决定是否放网关。

网关核心是"横切能力"，缓存因收益大可纳入，但压缩/向量化等重功能应放业务层，避免网关臃肿。按"通用性 + 职责聚焦"决定边界。

• 自建网关职责拆分
• 服务网格边界
• 架构分层

自建网关职责拆分：1) 协议层：暴露 OpenAI 兼容接口，处理请求/响应转换；2) 路由层：模型/Provider 路由、能力矩阵、别名；3) 横切层：认证、限流、重试、计费、观测；4) 服务网格层（Envoy/Istio）：处理网络通信、流量控制、可观测（sidecar 注入）。边界：业务服务通过网关调用模型（不直连 Provider），网关是"唯一入口"；业务服务负责业务逻辑（Prompt 组装、工具、Agent），不直接处理 Provider 细节；网关负责"模型访问的横切"，不掺入业务逻辑。Provider 直连边界：业务服务不直连 Provider，统一走网关，保证认证/限流/计费/观测集中。服务网格管"网络流量"，网关管"模型横切"，两者分层。

自建网关是"模型访问唯一入口"，业务服务管业务逻辑，服务网格管网络，Provider 不直连。职责分层清晰，避免耦合。

• 选型文档防过期
• 能力数据核查
• 定期重验

网关产品迭代快，模型数量、延迟、能力、价格都会变，写死"支持 100 个模型""延迟 100ms"会误导决策：1) 原因：这些数据会随时间过时，基于过时数据决策会选错；2) 处理：能力/性能数据（支持模型数、延迟、吞吐、价格）标注"核查日期"，注明数据来源与版本；3) 定期重验：按周期（季度/半年）或关键变更时重新验证，更新文档；4) 用"范围/趋势"而非"固定值"描述（如"延迟在 X-Y 区间，需实测"），强调实测验证。选型文档要"可核查、可更新、防过期"，避免"拍脑袋写死"。

网关能力数据会漂移，写死会误导。标注核查日期 + 定期重验 + 用范围/实测描述，防止选型基于过时数据。

• 缓存/重试一致性
• 流式与工具调用
• usage 对账

网关缓存/重试要与流式、工具、usage 对账保持一致：1) 缓存：缓存响应的 usage 也要记录（缓存命中不产生 Provider 计费，但也要计入使用量），缓存与流式、工具结果要正确对应（缓存完整的流式事件序列与工具结果，重放一致）；2) 重试：重试会增加 Provider 调用，usage 需累计去重（重试的 token、费用要正确计入，避免漏计或重复计）；3) 流式：缓存/重试要保留流式事件的完整性（事件序列、顺序），重放时一致；4) 工具调用：有副作用工具调用不能缓存/重试（或有幂等处理），缓存工具结果需考虑副作用；5) 对账：网关的已计 usage 与 Provider 账单对账，缓存命中、重试消耗要能解释。核心：缓存/重试不能破坏"流式完整性、工具安全、usage 准确性"。

缓存/重试会改变 usage 与流式/工具行为。缓存要保留完整事件与工具安全、重试要 usage 去重累计、流式要保序，且与 Provider 账单对账。

• OpenAI 兼容的局限
• 流事件差异
• 能力保留

只做"OpenAI 兼容"会丢失厂商特有能力：1) 各 Provider 的流式事件结构不同（OpenAI 的 delta、Anthropic 的 content_block、Gemini 的不同事件），强行统一为 OpenAI 格式会丢失特有信息（如多模态内容、工具调用细节、用量接口差异）；2) OpenAI 兼容层是"通用子集"，厂商特有能力（特别的流事件、多模态、特殊参数）无法表达；3) 兼容层会抹平能力差异，导致无法使用厂商最佳特性。因此：网关提供 OpenAI 兼容的"通用入口"作为默认，但保留/透传各家的特有流事件结构（通过扩展字段、原始事件透传、专用端点），让需要厂商特性时可用。通用兼容 + 特有透传。

OpenAI 兼容是"通用子集"，丢失厂商特有流事件与能力。网关应"通用兼容 + 特有透传"，保留各家差异而非抹平。

• 缓存正确性
• 租户/版本隔离
• 缓存键设计

网关缓存避免过期/跨用户回答：1) 租户隔离：缓存键包含租户 ID，不同租户的缓存不共享，防止跨租户返回（数据泄露/越权）；2) 版本边界：缓存键包含模型版本、Prompt 版本、参数，模型/Prompt 升级后不命中旧缓存，避免返回旧版本回答；3) 新鲜度：缓存设 TTL 与失效策略，动态/时效性内容（新闻、实时数据）短 TTL 或不缓存，避免过期；4) 上下文敏感：缓存键含完整影响输入的上下文（query、工具、参数），避免"相似但不同"的请求误命中；5) 敏感数据：含 PII/敏感请求不缓存。设置"租户 + 版本 + 上下文 + TTL"边界，保证缓存正确、安全、不过期。

缓存正确性依赖"缓存键隔离"：租户隔离防跨用户、版本隔离防旧版本、上下文含全防误命中、TTL 防过期。缓存键设计是核心。

• 地域路由
• 数据驻留
• 合规

多区域地域路由，保证数据不出域：1) 地域识别：根据用户/请求的属地（租户配置、IP、请求头）识别所属区域；2) 地域路由：把请求路由到该区域的 Provider 端点/网关（EU 请求路由到 EU 端点，US 路由到 US 端点），保证数据在区域内处理；3) 数据驻留：配置 Provider 的区域端点（如 Azure OpenAI 的 EU deployment），数据不出域；4) 就近路由：同区域请求路由到就近节点，降低延迟；5) 合规：区域隔离与数据驻留配置满足 GDPR 等合规要求；6) 边界：跨区域请求明确禁止或需审批。用"地域标签 + 区域路由 + 区域端点 + 就近"实现数据不出域与合规。

地域路由用"地域标签识别 + 区域端点路由 + 数据驻留配置"，保证数据在区域内处理、满足合规与就近延迟。

• 流式监控
• 事件结构保留
• 透明代理

网关流式监控要"透明"（不破坏事件结构）：1) 透传转发：网关对流式事件做"透传"（原样转发），不解析改造事件结构，只做旁路观察；2) 旁路监控：用"影子/旁路"方式记录事件流（事件类型、token 数、时间、TTFT/TPOT），不改动转发给客户端的事件；3) 事件计数与统计：对事件做计数/时间统计（首 token、间隔、总事件数），用于监控，不改变内容；4) 保留特有结构：事件透传时保留厂商特有字段，不强制统一；5) 遇监控需求需转换时，用扩展字段保留原始。核心：监控"旁路观察"，转发"原样透传"，不破坏 Provider 特有事件结构。

流式监控要"旁路 + 透传"：转发原样保留事件结构，监控侧旁路记录统计，两者不互相干扰。

• Provider 切换
• 抽象层
• 平滑过渡

Provider 切换通过抽象层平滑：1) 认证抽象：网关统一认证（API key），切换时只改网关的 Provider 凭据配置，业务无感；2) 端点抽象：网关统一端点，切换 Provider 改网关路由配置，业务代码不感知后端变化；3) 模型别名：业务用别名（如 "chat-standard"），切换时改别名→新 Provider 模型的映射，业务不用改；4) 数据驻留：切换需考虑数据驻留差异（Azure 数据驻留 vs OpenAI），路由配置按区域/合规调整；5) 能力校验：切换前校验新 Provider 能力（工具/多模态/流式）与旧兼容；6) 灰度切换：先小流量验证再全量，可回滚。用"网关抽象层 + 别名 + 灰度"让 Provider 切换对业务透明、平滑、可回滚。

Provider 切换靠抽象层隔离：认证、端点、别名、数据驻留都在网关配置层处理，业务无感，配合能力校验与灰度实现平滑过渡。

• 前缀缓存
• Prompt 布局
• 缓存复用提升

前缀缓存（Provider 对相同前缀 token 复用 KV cache）复用率取决于"前缀稳定性"：1) 稳定在前：系统指令、工具 Schema、固定示例、长文档前缀放在最前面，这些不变的内容成为稳定前缀，可被缓存复用；2) 动态在后：用户输入、时间、动态数据放最后，避免变化部分破坏前缀；3) 避免前缀抖动：不要在开头插入动态内容（如把时间戳放开头），否则前缀每次都变、缓存失效；4) 固定顺序：把稳定内容顺序固定，减少重排；5) 长文档前缀：把常变的长文档（知识库片段）放稳定位置，提高复用。布局原则："稳定前、动态后"，最大化可缓存前缀。

前缀缓存命中的前提是"前缀稳定"。把系统指令/工具 Schema/长文档放前、动态内容放后，最大化稳定前缀，提高缓存复用、降本增效。

• 多轮前缀缓存
• 动态数据后置
• 缓存复用

多轮会话逐轮新增尾部消息，前缀缓存复用的关键是"保持前面消息不变"：1) 历史消息作为稳定前缀，新消息追加在尾部，前端历史不变则前缀可复用缓存；2) 动态数据后置：时间、用户数据、动态状态放末尾，因为它们在每轮变化，放前面会破坏前缀、导致缓存失效；3) 系统指令/历史固定放最前，每轮只在尾部追加新内容；4) 避免在历史中间插入/修改（会破坏前缀）；5) 若历史需裁剪，从尾部裁（保留前缀）。动态时间/用户数据后置原因：它们逐轮变化，放前缀会破坏稳定前缀，放到尾部让稳定前缀尽量长、缓存复用最大。

多轮前缀缓存靠"前缀全稳定"。动态内容（时间/用户数据）每轮变化，必须后置，保持稳定前缀在前，最大化缓存复用。

• 语义缓存
• 相似阈值
• 租户隔离与过期

语义缓存（用嵌入相似度匹配相似问题复用答案）要防误判与越权：1) 相似阈值：设合理的相似度阈值，阈值过高命中少（缓存收益低）、过低误命中（相似但不同的问题返回错误答案），需按场景调优并验证；2) 租户隔离：缓存键含租户，不同租户的缓存不共享，防止跨租户返回越权/他人答案；3) 过期规则：设 TTL 与失效策略，时效性内容短 TTL，动态知识不缓存，防止返回过期答案；4) 上下文敏感：足够相似才命中，且答案对应的问题语义要一致；5) 敏感内容：PII/敏感请求不缓存。语义缓存要平衡"命中率"与"正确性"，隔离 + 过期 + 阈值控风险。

语义缓存风险是"相似误命中"与"越权/过期"。相似阈值调优、租户隔离、过期规则、敏感不缓存，保证正确与安全。

• 缓存交互问题
• 流式/工具/引用/usage
• 缓存一致性

缓存交互问题：1) 流式输出：缓存命中需重放完整流式事件序列（保序、保完整），否则客户端解析错误；2) 工具副作用：缓存命中的工具调用若再次执行会重复副作用，有副作用工具不可缓存或需幂等；3) 引用新鲜度：缓存命中可能返回旧引用（知识已更新），需考虑引用新鲜度与失效；4) usage 对账：缓存命中不产生 Provider 计费，但使用量要正确记录（缓存命中 vs 未命中），与 Provider 账单对账；5) 版本/上下文：缓存与模型/Prompt 版本、上下文绑定，避免错配。交互处理：缓存要"保流式完整、工具幂等、引用新鲜、usage 准确、版本匹配"。

缓存不是"简单存答案"，要与流式、工具、引用、usage 协调。保流式完整、工具幂等、引用新鲜、usage 对账、版本匹配，避免缓存引入问题。

• 租户隔离缓存
• 缓存键设计
• 防跨租户

租户隔离缓存设计：1) 缓存键包含租户 ID：缓存键 = 租户 ID + 模型 + Prompt 哈希 + 参数 + 上下文，不同租户键不同，天然隔离；2) 命名空间/分区：按租户分缓存命名空间/分区，物理/逻辑隔离；3) 权限：缓存访问按租户校验，防止跨租户读取；4) 敏感数据：租户数据不跨租户存储，防止泄露；5) 验证：测试跨租户请求不命中（A 租户的请求不返回 B 租户缓存）。核心是"缓存键含租户 + 命名空间隔离 + 访问校验"，确保租户 A 的请求绝不命中租户 B 的缓存。

防跨租户缓存靠"缓存键含租户 ID + 命名空间隔离 + 访问校验"。租户隔离是缓存安全红线的关键。

• 缓存评估指标
• 多维评估
• 缓存价值

缓存评估要多维而非只看请求数：1) 命中率：缓存命中比例，体现复用程度；2) 节省 Token：缓存节省的输入/输出 Token 与成本（核心价值，缓存命中省 Provider 费用）；3) 额外延迟：缓存查找/命中带来的额外开销（命中应比未命中快或接近，不能因缓存变慢）；4) 错误命中率：缓存命中返回错误答案的比例（关键风险，错误命中高则缓存不可用）；5) 综合：缓存价值 = 节省 Token/成本 - 缓存开销 - 错误命中风险。只看请求数会误导：命中率高但省 Token 少、或错误命中高，缓存价值低。用"命中率 + 省 Token + 延迟 + 错误命中率"综合评估。

缓存价值是"省成本"，命中率是过程指标。省 Token、延迟、错误命中率是结果与风险。四维综合评估才能判断缓存是否值得。

• 缓存规则/价格变化
• 文档防过期
• 核查日期

Provider 缓存规则（缓存机制、命中条件、cache_read 计费）与价格会随版本变化，工程文档必须标注核查日期：1) 原因：缓存规则/价格变化会改变缓存收益计算与实现策略，若文档基于过时信息，会做出错误决策（如缓存实现与当前 Provider 规则不符、成本估算错误）；2) 处理：文档中的缓存规则、价格、阈值标注"核查日期"与数据来源；3) 定期重验：按周期或 Provider 变更时重新核对，更新文档；4) 用版本快照：记录当时 Provider 版本与规则。防过期：文档可核查、可更新，避免"照着旧规则实现导致缓存失效或成本失控"。

Provider 缓存规则/价格会漂移，文档必须"标注核查日期 + 定期重验 + 版本快照"，防止基于过时规则实现缓存或估算成本。

• 缓存键维度
• 正确性
• 隔离

缓存键应包含影响"输出"的所有维度：1) 模型：模型版本/别名（不同模型输出不同，不能共用缓存）；2) Prompt 哈希：完整 Prompt 的哈希（内容变化缓存失效）；3) 参数：温度、max_tokens、top_p 等推理参数（不同参数输出不同）；4) 租户：租户 ID（隔离，防跨租户）；5) 上下文：工具的、检索上下文（若影响输出）；6) 版本：Prompt/应用版本。组合：cache_key = hash(租户 + 模型 + 参数 + Prompt + 上下文 + 版本)。缓存键要"足够细"保证正确（不误命中不同输出），又要"不冗余"保证命中率。核心是"所有影响输出且可哈希的维度都进键"。

缓存键要包含"影响输出的全部维度"（模型、参数、Prompt、租户、上下文、版本），保证命中正确且隔离。键设计决定缓存正确性与命中率。

• 命中率监控
• 真实 vs 虚假提升
• 质量分析

命中率提升不一定是"好事"：可能是"低质量查询重复提交"（相同垃圾查询反复命中，命中率虚高但无价值）。区分：1) 分析命中样本的多样性：监控命中请求的"唯一性/多样性"（不同 query 数、重复度），若近乎全是重复的低质量查询，则是虚假提升；2) 分析命中请求的质量：命中样本的质量分布（是否有价值、是否用户高频有用查询）——高质量查询命中是真实收益，低质量重复命中是虚假；3) 量化"节省"：真实价值看"节省 Token/成本"而非命中率，低质量查询命中省不了多少有效成本；4) 结合质量指标：命中后用户满意度/任务成功率是否提升。核心：命中率是过程指标，区分"有效命中"与"低质量重复命中"才见真实价值。

命中率提升可能来自低质量查询重复提交。看"命中多样性、查询质量、节省 Token"而非单纯命中率，才能区分真实与虚假提升。

• 缓存击穿
• 防雪崩手段
• 热点缓存

缓存击穿（热点 key 失效瞬间大量请求同时打到下游）防雪崩：1) singleflight（单飞）：同一 key 的并发请求合并为一次下游调用，其余请求等待结果，避免打爆下游；2) 分布式锁：热点 key 失效时，让一个请求拿锁去重建缓存，其他请求等待/读旧缓存，避免并发重建；3) 本地缓存：加一层本地缓存（进程内），热点 key 本地缓存减少对分布式缓存/下游的冲击；4) 永不过期/逻辑过期：逻辑过期让 key 物理不过期，后台异步刷新，避免瞬间失效；5) 预防：热点 key 用布隆/检测提前预警。核心：用"单飞 + 分布式锁 + 本地缓存"控制热点 key 失效时的并发重建，防止瞬间击穿雪崩。

缓存击穿是"热点 key 失效瞬间并发击穿下游"。singleflight 合并请求、分布式锁控重建、本地缓存减压，三层防雪崩。

• 自动缓存 vs 显式缓存
• 混合使用
• 断流/长 Prompt

混合使用：1) Provider 自动缓存（prompt caching）：Provider 侧对相同前缀自动复用 KV cache，省 token 但"不可控"（由 Provider 决定命中、有 TTL、跨用户可能命中）；2) 显式缓存（应用层）：应用自己缓存完整响应，可控（命中、失效、隔离清晰）。混合策略：3) 长 Prompt：长 Prompt 用 Provider 自动缓存（前缀复用省 token），但显式缓存负责"完整响应复用"（相同完整请求直接返回，不重复调 Provider）；4) 断流恢复：断流时 Provider 自动缓存可能失效（TTL、会话断开），显式缓存可恢复完整响应（重放缓存），实现快速恢复；5) 分层：两者结合——显式缓存做"完整命中"、Provider 自动缓存做"前缀省 token"，互相补充。用"显式缓存管完整响应 + Provider 自动缓存管前缀"混合。

Provider 自动缓存省前缀 token 但不可控，显式缓存可控可恢复。混合：长 Prompt 用 Provider 前缀缓存，断流恢复用显式缓存重放，分层互补。

• 缓存敏感数据
• 脱敏与访问控制
• 缓存安全

缓存不应存敏感数据，写入前做防护：1) 识别敏感：写入前检测请求/响应是否含 PII、密钥、敏感正文，含敏感内容的请求不缓存或脱敏后缓存；2) 脱敏：对要缓存的响应做字段级脱敏（替换 PII/密钥，保留非敏感部分）；3) 访问控制：缓存访问按租户/角色，RBAC 控制谁可读缓存，防越权读取；4) 加密：缓存内容加密存储（补充防线）；5) 生命周期：敏感缓存设短 TTL，及时删除；6) 审计：记录缓存读写，异常访问可追溯。原则：缓存"源头不存敏感数据"，脱敏 + 访问控制 + 加密 + 短 TTL 多层防护。

缓存泄露敏感数据是红线。写入前识别脱敏、访问控制、加密、短 TTL、审计，从源头避免敏感数据进缓存。

• Provider 缓存不可靠
• 双轨能力
• 正确性保证

不能把 Provider 缓存当"永远命中"，因为：1) Provider 缓存命中不由应用控制（Provider 决定、有 TTL、可能失效、缓存内容可能被更新）；2) 缓存可能返回过期/不正确内容（知识更新、动态数据）；3) 依赖 Provider 缓存会失去"正确性兜底"。应保持应用层"重算与缓存双轨"：1) 缓存作为"加速"：命中时返回缓存（快），但应用始终有能力"重算"（重新调用 Provider 生成）；2) 失效/怀疑时重算：缓存过期、引用新鲜度存疑、用户要求实时时，走重算路径；3) 双轨校验：可对缓存命中做抽样校验（与重算对比），确保缓存正确；4) 兜底：缓存不可用时优雅回退到重算。缓存是"优化不是依赖"，重算能力始终保留。

Provider 缓存不可控、可能过期，不能当"永远命中"。保持"缓存加速 + 重算兜底"双轨，缓存失效/存疑时重算，保证正确性。

• 限流算法差异
• 突发容忍
• 分布式实现

限流算法选型：1) 令牌桶：允许一定突发（桶容量 + 速率），适合"允许突发但限制平均速率"（AI 场景常见，兼容突发请求）；2) 漏桶：固定速率输出，平滑、无突发，适合"严格平滑"（但 AI 请求突发会被拒）；3) 滑动窗口：按时间窗口限流，比固定窗口更平滑（避免边界突发），实现简单；4) 固定窗口：简单但边界可突发（窗口边界请求翻倍）。分布式实现：Redis 分布限流（令牌桶/滑动窗口用 Redis 原子操作/Lua）保证多实例一致，但增加 Redis 调用延迟；本地限流快但多实例不一致。AI 网关取舍：允许突发用令牌桶，严格平滑用漏桶，跨实例用 Redis 分布式（一致性优先，牺牲些延迟），单实例可本地限流。突发容忍差异：令牌桶 > 滑动窗口 > 漏桶。

算法选型看"突发容忍 vs 平滑性 vs 分布式一致性"。AI 网关常用令牌桶容忍突发 + Redis 分布式保一致性，用滑动窗口平滑边界。

• 背压与积压
• 队列治理
• 防雪崩

队列积压治理防雪崩：1) 排队长度上限：队列设最大长度，超限拒绝（fail fast），避免无限积压拖垮系统；2) 拒绝策略：队列满时拒绝新请求（返回 503/降级），明确告知，而非无限排队；3) 降级提示：被拒/排队时向用户降级提示（稍后重试、降级响应），管理预期；4) 消费者伸缩：监控队列积压，自动伸缩消费者（K8s HPA/扩缩容），积压高则扩消费者；5) 背压：生产者感知下游压力，主动限速/降级，而非无限投递；6) 监控告警：积压超阈值告警，及时干预。核心：用"队列上限 + 拒绝 + 降级 + 伸缩 + 背压"形成闭环，防止积压转发为雪崩。

队列积压失控会雪崩。排队上限、拒绝策略、降级提示、消费者伸缩、背压反馈，形成防雪崩的治理闭环。

• 缓存主动失效
• 失效触发条件
• 缓存一致性

缓存应主动失效的场景：1) Prompt 改版：Prompt 变更后旧缓存失效（旧 Prompt 的答案不适用于新 Prompt），缓存键含 Prompt 版本，改版即刷新；2) 模型切换：模型/版本切换后旧缓存失效（不同模型输出不同），缓存键含模型版本；3) 法规变化：合规/政策变化导致旧回答不合法（如法规更新后旧答案违规定应失效），需立即失效相关缓存；4) 知识更新：知识库/文档更新，相关缓存失效（引用新鲜度）；5) 用户侧：用户信息/敏感数据变化，相关缓存失效。主动失效机制：版本号/缓存键版本化、按类别失效（broadcast）、失效队列。核心：凡"影响输出的因素"变化（Prompt/模型/法规/知识）就主动失效，保证缓存不返回过期或错误内容。

缓存主动失效触发条件是"影响输出的因素变化"。Prompt 改版、模型切换、法规变化、知识更新都需失效缓存，保证正确性与合规。

• 多模态缓存
• 图像/音频缓存键
• 相似匹配

多模态请求缓存：1) 哈希：图像/音频内容做内容哈希（感知哈希/加密哈希），作为缓存键的一部分，用于"完全相同"内容匹配；2) 视觉特征：对图像用视觉特征向量（embedding），可做"相似度匹配"（相似图像命中缓存，而不只是精确哈希），用于近似场景；3) 组合：缓存键 = 文本 + 图像哈希/特征 + 音频哈希 + 模型 + 参数，精确内容用哈希、相似内容用特征；4) 语义缓存：多模态语义缓存（图像语义相似）可复用，但需谨慎（相似图像可能语义不同）；5) 成本：多模态内容哈希/特征计算有开销，需权衡缓存收益。多模态缓存用"哈希精确匹配 + 视觉特征相似匹配"结合。

多模态缓存：完全相同用内容哈希，相似用视觉特征向量，组合进缓存键。精确 + 相似两种匹配，兼顾命中与正确。

• 缓存新鲜度
• 召回质量
• 联合评估

缓存新鲜度与召回质量联合评估：1) 新鲜度：缓存返回的内容是否仍正确/时效（命中但过期的内容质量差）；2) 召回质量：命中率与命中内容是否有效（命中但内容差、或低质量重复命中）；3) 联合：新鲜度差（命中返回过期内容）会损害召回质量（用户得到错误答案），只优化新鲜度会牺牲命中率、只优化召回率会牺牲新鲜度。单一指标不够：1) 只看命中率会忽略过期内容（虚高）；2) 只看新鲜度会忽略缓存收益（过低）；3) 需"命中率 × 新鲜度 × 内容质量"综合，如"有效命中率"（命中且内容新鲜且正确）。用"新鲜度 + 召回质量 + 内容正确性"联合评估缓存价值。

缓存"新鲜"与"命中"互相制约：太新鲜牺牲命中、太重命中牺牲新鲜。联合评估命中率、新鲜度、内容正确性，单一指标会误导。

• 统一认证
• 统一路由
• 网关能力

AI 网关统一认证与路由：1) 统一认证：客户端只需一个网关 API key，网关内部管理各 Provider 的密钥（密钥不暴露给客户端），网关做认证/鉴权（租户、权限、配额）；2) 统一路由：客户端用统一接口（通常 OpenAI 兼容）请求模型，网关按路由策略（模型名/别名、租户、能力、成本、可用性）选择实际 Provider，自动路由；3) 路由策略：按别名映射、成本优化、故障切换、租户隔离、地域路由；4) 能力：认证（统一 key、租户鉴权）+ 路由（模型选择、Provider 选择）由网关集中处理，客户端只需"一个 key + 一个接口"。这样客户端统一接入，Provider 细节与密钥由网关管理。

网关统一认证（一个 key，密钥集中管理）+ 统一路由（一个接口，按策略选 Provider），客户端简化、Provider 细节隔离。

• 多模型路由特征
• 可解释选择
• 档位策略

多模型路由用可解释特征选择档位：1) 特征提取：请求长度、任务类型、复杂度（推理/检索/创作）、工具需求、领域、历史质量；2) 特征→档位映射：规则/评分/可解释分类器把特征映射到模型档位（如简单→mini/快省、复杂→strong/reasoning）；3) 可解释：路由决策可解释（为什么选这个档位，基于哪个特征），可审计、可调试；4) 成本-质量平衡：简单任务用便宜模型省成本，复杂任务用强模型保证质量；5) 反馈优化：用路由结果与实际质量/成本对比，调整特征与阈值（纠偏）。可解释特征让路由"透明、可审计、可优化"，而非黑盒。

多模型路由用可解释特征（长度/复杂度/工具）选档位，平衡成本与质量。可解释性让路由可审计，反馈纠偏让它持续优化。

• 自建网关数据主权
• 合规驻留量化
• 商业网关优势

自建网关数据主权/合规优势量化：1) 数据主权：自建可保证数据不出域、不被第三方处理，量化"数据泄露风险降低 + 合规成本降低"（无第三方审计/合规/数据共享风险）；2) 合规驻留：自建可精确控制区域部署与数据驻留，量化"满足法规（GDPR 等）的合规成本与风险溢价"；3) 退出成本：自建无平台锁定，量化"迁移成本 + 平台费用"。商业网关多区域合规更划算的场景：1) 多区域需求广（需迅速部署多个区域的数据驻留）；2) 自建多区域合规成本高（每个区域都要自建合规、证书、审计）；3) 合规资质/证书由商业网关提供更省（专业合规团队）；4) 运维成本低。量化：自建节省"数据风险 + 锁定成本"，商业网关照省"多区域建设 + 合规认证 + 运维"。按"规模、区域数、合规要求"权衡。

自建强在数据主权与无锁定，商业网关强在多区域合规与运维。量化"数据风险、合规成本、多区域建设、运维"后，按规模与合规需求权衡。

• 自建 vs 商业决策
• 多维度权衡
• 退出成本

决策维度：1) 数据主权：自建数据完全自控，商业数据在第三方（需评估信任与合规）；2) 多区域：商业网关多区域部署成熟（开箱即用），自建多区域工作量大、成本高；3) 合规：商业网关提供合规认证（省力），自建需自建合规体系（强控制但成本高）；4) 运维：商业免运维（托管、SLA），自建需自建运维（升级、监控、扩展）；5) 退出成本：商业有平台锁定风险（迁移成本高），自建无锁定（但自建投入沉没）。决策：强合规/数据主权/长期大规模 → 自建；快速上线/运维弱/多区域广 → 商业；可混合（敏感数据自建、通用商业）。综合评估五维，按"数据主权 vs 运维成本"的核心权衡。

自建 vs 商业是"数据主权/控制 vs 运维/多区域/合规便利"的权衡。五维综合评估，无绝对最优，按需求与规模决策。

• 流式中断恢复
• 重连与续传
• 幂等与超时

流式中断恢复设计：1) 断流重连：客户端检测连接断开，自动重连（指数退避），重连后恢复流式会话；2) 增量续传：用"事件序号/游标"记录已消费的流事件，重连后从断点继续（续传未消费部分），避免重复/丢失；3) 超时重发：设空闲超时与总超时，长时间无事件判定断流，重发最后未确认的事件/重新请求；4) 幂等：重连/重发用会话 ID/事件 ID 去重，避免重复处理；5) 缓存：服务端缓存已生成的部分流（断点续传），客户端重连后从缓存续传；6) 状态：若续传不可行（无状态 Provider），则重新请求并引导用户（可接受重新生成）。设计目标：断流后"自动重连 + 从断点续传 + 不重复不丢失 + 超时兜底"。

流式中断恢复要"重连 + 增量续传 + 超时重发 + 幂等去重"。事件序号游标续传、缓存部分生成、超时兜底，保证不重复不丢失。