AI网关已完成POC，项目组准备上线；平台团队确认路由规则存在，安全团队却没有验证审计字段，应用团队也不知道限流和降级时会收到什么。AI网关上线验收必须让路由、限流、审计和降级在同一请求链路中联动，并准备配置回滚。

上线门禁：验收生产候选版本的实际行为、责任和恢复路径，不重新做一遍功能演示。

先冻结配置、应用和变更窗口

冻结项包括网关版本、模型目录、路由与限流策略、应用身份、凭证、上游模型、监控、日志字段和回滚对象。验收期间若修改策略，应生成新版本并重新执行受影响场景。

上线窗口要明确变更负责人、观察人、业务确认人和撤回授权人。没有责任人时，即使工具支持回滚，也可能错过停止影响的时机。

路由验收关注命中原因和错误反馈

使用不同应用、任务和模型状态验证路由，确认优先级、默认规则和不可用后端处理。日志应记录策略版本、命中原因和最终模型，调用方收到的错误不能掩盖真实失败。

策略冲突时要有明确优先级，模型下线或别名变化时要能识别受影响应用。静态配置正确之外，还要测试后端状态变化和策略回滚。

限流要同时保护后端与调用方体验

验收按应用、租户或模型制造超限，观察请求是拒绝、排队还是降级，响应是否包含可处理信息，后端是否避免持续过载。固定通用阈值没有意义，应由目标容量与业务优先级决定。

限流顺利获得不等于拒绝越多越好，而是压力能够在预期边界内被收敛。 高优先级与普通任务若共用策略，应验证公平性和异常租户隔离。

审计与降级需要关联同一次异常

选取上游超时或不可用，检查健康判定、熔断、备用路径或明确失败，并在审计中关联应用、模型、策略、结果和恢复。备用模型若功能或数据边界不同，要告知调用方并限制适用场景。

控制台式图把四类证据放在一起，提醒评审者不能用四张独立菜单截图代替一次联动演练。

回滚演练完成后才进入放行签字

回滚至少覆盖策略、模型目录、凭证或密钥引用、部署版本与流量入口。演练要确认旧配置可识别、权限仍有效、上游模型可用，恢复后用代表性请求复验。

上线前可先按 AI网关入口治理 固定对象与责任；异常证据的关联方式可参考 AI模型可观测性 。

结论分为顺利获得、条件放行、补测和阻断。条件放行限制应用、流量和时间，并设撤回触发器。没有降级影响说明和回滚实证时，不应无条件放行。

上线签字前要完成网关运行交接

验收顺利获得并不表示实施团队可以立即退出。运行交接至少包含配置与模型目录版本、应用身份清单、限流和降级策略、日志与告警入口、变更权限、回滚包、供应商升级路径和已知风险。SRE应能够在不依赖原配置人员的情况下定位一次异常。

交接演练可以从值班视角开始：给出一条超限请求或上游失败，让接班人根据告警找到应用、策略和实际模型，判断是保持降级、回滚配置还是停止流量。若需要临时管理员权限或口头询问才能完成，交付材料仍不足。

条件放行的应用、流量与时间范围要进入值班看板，并配置撤回触发器。补测完成后由原签字角色复核，不让条件放行自然变成长期状态。审计和日志的访问权限也要在交接时校验，避免故障发生后才申请。

模型、策略或客户端首次变更时，使用同一组路由、限流、审计和降级请求做小规模回归。这样上线验收就能转化为日常变更门禁，而不是只在项目结项时执行一次。

验收会上还应让一名未参与配置的人依据证据复述结论；如果他无法判断场景、版本、失败影响和恢复责任，说明材料仍不足以支持独立复核。该复述结果应写入补测项，而不是依靠口头经验放行。

最终交付要核对合同范围、运行权限和停用条件

上线验收不仅判断技术行为，也要核对采购范围。路由、限流、审计和降级哪些属于标准能力，哪些依赖企业系统或定制，谁负责后续升级回归，应与合同和实施清单一致。现场临时修改若未进入配置基线与交付文档，不能作为长期能力签字。

运行权限需要遵循最小化和可追溯。谁能改模型目录、提高配额、关闭审计、启用备用模型或执行回滚，均应顺利获得角色和审批控制。验收时使用非管理员运行角色完成一次告警定位与处置，可以发现所有操作是否仍依赖供应商或超级管理员。

合同服务边界还应包含模型后端异常、身份依赖故障、日志管道中断和策略错误的升级路径。供应方给予什么诊断材料、企业业务团队何时确认降级影响、问题关闭前要复验哪些请求，都应明确。不能控制的外部因素可作为边界，但必须有探测、通知和替代动作。

停用网关或回退到旧入口时，应导出策略与必要审计、撤销凭证、收敛在途请求并确认应用不再调用新路径。条件放行到期、关键补测失败或版本回滚都可能触发停用。退出动作经过演练，生产门禁才真正覆盖完整生命周期。

灰度期间继续复核业务侧结果

技术指标稳定不代表调用方已经正确处理限流、降级和错误。灰度应用需要确认用户提示、重试、工具动作和成本归属，SRE则观察策略命中、后端保护与回滚触发器。两侧证据一致后，才能从条件放行扩大到更多应用。

首次升级也属于验收延伸。升级前导出配置并列出影响应用，升级后复跑四组请求和一次回滚。供应商若改变默认策略或日志字段，应给予差异说明；企业根据业务影响决定继续灰度、补测或撤回。

验收档案应保存候选版本、配置摘要、测试身份、请求样本、异常结果、回滚记录和签字限制，并与后续变更单关联。故障发生时可以据此判断当前行为是否偏离放行基线；缺失或过期的材料要触发补测，而不是依靠记忆继续扩大流量。

下一步建议

冻结生产候选版本后，准备正常路由、超限、未授权和上游故障四组请求。让同一应用身份贯穿策略、日志和监控，随后执行一次配置回滚。将业务影响、人工动作、未验证项和撤回条件写进上线签字表，再安排受控灰度。

常见问题

限流触发后应该排队还是拒绝？

取决于业务时效、请求成本、队列容量和上游恢复速度。交互请求如果排队超过用户超时，明确拒绝并给予重试信息可能更好；批量任务可以在有边界的队列中等待；关键业务可使用独立配额。没有上限的排队会把压力和故障延后放大。

验收应分别测试目标策略下的响应、队列、后端负载和恢复，并让调用方知道如何处理。策略不应只在网关内部看起来合理，还要符合业务语义。

限流证据要同时展示调用方响应、队列状态、后端负载和恢复过程。交互请求、批量任务与关键业务可以采用不同策略；无上限排队或无提示拒绝都不适合作为默认生产结果。

降级到备用模型需要告知调用方吗？

若备用模型可能改变功能、质量、数据位置、内容策略或成本，应显式告知或顺利获得接口标识，使调用方决定是否接受。对完全同版本、同契约的冗余实例，告知方式可按项目设计，但审计仍应记录实际后端。

高风险流程不宜静默切换。可以设置兼容等级：完全兼容自动切换，有限兼容降级并告知，不兼容明确失败或人工接管。POC和上线验收都要验证该行为。

备用模型改变功能、质量、数据位置、内容策略或成本时，调用方应取得可识别标记并决定是否接受。完全同版本冗余仍需审计实际后端；高风险流程默认不做静默切换。

上线验收如何验证策略回滚？

先保存并标识当前与上一版策略，记录模型目录和应用映射；在隔离或受控窗口发布一个可观察的小变更，再执行撤回。检查配置是否恢复、缓存是否刷新、实例是否一致、流量是否使用旧规则，以及审计能否关联变更。

回滚后还要用正常、超限和故障请求复验，不能只看版本号。若回滚依赖手工改多处配置，应记录步骤和权限，并评估是否足以支持生产窗口。

策略回滚应保存当前与上一版、模型目录和应用映射，在受控窗口发布可观察变更后撤回。回滚后复跑正常、超限和故障请求；缓存未刷新或实例版本不一致时，不能只凭配置版本号判定成功。