别只测“回答对不对”：我把限流、注入、崩溃和重复执行写进 AI Platform 发布闸门
先说结论
一组题回答得很好，不等于 AI Platform 可以上线。模型评测关注概率性的答案质量；生产发布还必须证明身份不会丢、401 不会被错误降级、429 重试有上限、高风险工具会等待审批、重复投递只产生一次副作用、过期记忆进不了 Prompt、策略拒绝不会被算成系统故障，以及每个决定都能用 Trace、审计和成本记录解释。为了把「感觉差不多」变成发布条件，我写了一个零网络、零凭据、只用 Python 标准库的 30 道闸实验，覆盖身份、网关、策略、执行、记忆和证据六个故障边界。30/30 才显示
RELEASE=PASS；任何一项失败都必须阻断发布，而不是删掉测试让看板重新变绿。
图 1：原创图。模型、Prompt、工具、策略和任务状态组成一个候选版本；只有身份、路由、权限、执行、记忆与证据共同通过，才允许扩大流量。
一、问题背景：Demo 验收和生产验收不是同一张试卷
很多 AI 项目的验收方式是准备几十个问题，运行新模型或新 Prompt，再让人看回答是否「更好」。这种方法有价值，但只覆盖了系统的一小部分。
如果模型回答非常准确，却把另一个租户的记忆塞进上下文，不能上线；如果答案漂亮，却在队列重投后执行了两次付款，不能上线；如果正常路径全绿，但遇到 401 后连续切换三个模型、花三倍钱仍然失败，也不能上线。
这像学校食堂推出一道新菜。试吃员觉得味道不错，只能证明「好吃」；它不能证明进货可追溯、冰箱温度正常、过敏原写清楚、刷卡只扣一次、停电后不会把隔夜菜当成新菜。答案质量是菜的味道，平台控制是整间厨房的食品安全。两者缺一不可。
二、问题表现：上线前全绿，上线后却出现七种意外
- 离线题集得分上升，真实任务完成率没有变化；
- 模型更新后多调用一次工具，成本和副作用一起翻倍；
- Provider 限流时无界重试，延迟和账单同时爆炸；
- Prompt Injection 被模型「识别」了十次，第十一次仍绕过策略；
- Worker 崩溃后队列重投，服务重启两次；
- 正确拒绝危险请求，却被成功率看板计为失败；
- 出事后只剩一段最终回答，无法证明身份、路由、批准和真实副作用。
根因并不是「题集不够大」，而是把不同性质的问题压缩成了一个分数。
三、问题根因：确定性控制、概率质量和业务结果被混在一起
生产验收至少有三层：
图 2：原创图。事务和权限必须每次都正确；模型质量要比较分布与波动；最终还要确认用户的工作是否真的完成。不能用一个平均分互相抵消。
- 确定性控制层：身份、租户、参数 Schema、状态转换、幂等、审计必须每次通过。一百次里错一次也不能用平均值掩盖。
- 概率质量层：任务成功、事实依据、安全性、语言质量、延迟和成本会波动，需要固定数据集、多次采样和统计比较。
- 人工与业务结果层：用户是否解决问题、审批是否清楚、失败能否接管、回滚是否可用，必须结合真实工作流判断。
模型评测不能替代平台测试，平台测试也不能证明答案一定有帮助。好的发布闸门会保留这三类证据，而不是把它们揉成一个「82 分」。
四、三十道闸：按故障边界分组，而不是按团队分工
本文实验把验收拆成六组，每组五项。
图 3：原创图。分组依据是失败边界：谁在做、在哪里做、能不能做、是否只做一次、上下文是否仍真实、事后能否证明。
身份闸：每次交接都不能掉身份证
身份组验证：请求封套是否包含租户、用户、角色和 request ID；缺少租户是否立即拒绝；跨租户记录是否隐藏；过期委托是否失效；同一 request ID 是否贯穿入口、网关、Worker 和审计。
图 4：真实实验输出截图。把用户名写进 Prompt 不叫身份传播；策略需要不可由模型改写的结构化声明。
五、网关闸：429 可以降级，401 必须停
网关组不是只看「备用模型能否回答」，而是验证失败是否被正确分类：
- 合成 429 属于短暂容量问题，可以在预算内降级；
- 401 是凭据或认证问题，换模型会掩盖根因，必须停止；
- 重试预算最多一次，不能形成瀑布式账单；
- 预估成本超过剩余预算时应在调用前阻断；
- 数据区域不符合要求的候选模型必须先被排除。
图 5：真实实验输出截图。降级不是「失败就换一个」，而是受错误类型、能力、数据分类、预算和最大尝试次数共同约束的决策。
六、策略闸：模型只能提议，不能给自己盖章
策略组检查只读工具可以正常通过，高风险操作进入等待批准；提示词注入在模型和工具执行前停止；工具参数中多出的 shell 字段被 Schema 拒绝；批准记录必须绑定规范化参数，目标改变后旧批准自动失效。
图 6：真实实验输出截图。模型说「用户同意了」不是批准证据；批准应绑定工具、目标、参数版本、申请人、批准人、有效期和一次性 nonce。
Prompt Injection 测试尤其不能只准备十句攻击文本，看模型是否回答「我不能照做」。真正的验收是：攻击内容有没有改变工具选择、参数、权限、Secret 访问、日志字段和最终副作用。平台策略应独立于模型输出工作。
七、执行闸：队列可以重复送信，副作用不能重复发生
执行组验证合法状态转换、租约过期后的重投、幂等唯一约束、fencing token 拒绝旧 Worker，以及取消后不再启动新副作用。
图 7：真实实验输出截图。实验用 SQLite 唯一键接收两次相同投递，最终副作用计数仍为 1。它验证控制逻辑，不假装端到端 Exactly-once 很容易。
这里要区分「消息被送了几次」和「业务动作发生几次」。像快递员因为网络问题扫描同一个包裹两次，仓库可以接受两条扫描记录，但不能发出两个包裹。生产指标应分别记录 redelivery count 与 duplicate side-effect count，后者必须为零。
八、记忆闸：旧事实比没有事实更危险
记忆组验证过期记录、其他租户记录、不可信检索文本、被旧版本取代的记录和已删除记录都无法进入上下文。
图 8：真实实验输出截图。向量相似度不在这五项中，因为它只负责候选排序；是否允许使用由确定性生命周期策略决定。
如果想深入理解为什么一条「记得很牢」的旧目标会害人，可以继续阅读本系列的 结构化记忆生命周期实战。
九、证据闸：最终答案不能替代事故记录
证据组要求模型和工具 span 共享同一 trace，审计记录包含谁、对什么工具、作出什么决定以及原因；预估成本和实际成本能够对账；正确策略拒绝不会被算成平台故障；合成恢复时间满足定义好的 SLO。
图 9：原创图。每个服务都有日志并不等于可观测；如果 request、trace、task 和 audit 无法关联，事故仍然拼不起来。
图 10：真实实验输出截图。「被策略拒绝」被分类为 correct-control，而不是 outage；否则团队会为了提高成功率而放松安全策略。
十、成功率为什么最容易骗人
假设一天有十个请求：七个完成、一个危险请求被正确拒绝、一个等待人工批准、一个 Provider 真故障。粗暴的成功率是 70%，但这个数字把三种完全不同的状态混在了一起。
图 11：原创图。正确拒绝说明刹车有效，等待审批说明任务被安全保存，真正的失败才是预期业务结果意外丢失。
更好的看板至少分开：业务完成率、策略正确拒绝率、审批等待时间、技术故障率、恢复时间、重复副作用、每个完成任务的成本。这样才能防止「为了让一个百分比变绿」而误伤安全边界。
十一、发布流程：每一层通过后才扩大爆炸半径
生产发布不应从本地改 Prompt 直接跳到 100% 流量。建议按下面顺序推进：
- 静态检查 Schema、Secret、依赖和配置；
- 固定黄金任务集，多次运行概率评测；
- 执行限流、超时、注入、队列重投、Worker 崩溃和记忆过期实验；
- Shadow 只观察不产生副作用；
- Canary 从极小流量开始，设置自动回滚阈值；
- 全量后持续观察业务、成本、安全和恢复 SLO。
图 12：原创图。任一闸失败都应停止、解释、修复并重跑；不能删除失败测试来换取绿色发布。
闸门还要版本化。模型、Prompt、工具 Schema、策略、检索语料、路由和评测集只要任一改变，都要能回答「这次证据对应哪组版本」。否则今天的 PASS 无法证明明天的组合仍安全。
十二、可复现实验：30/30 才允许 RELEASE=PASS
本文的 release gate 实验 使用固定时钟、合成身份和本地 SQLite，不访问任何模型、工具或网络。它实际执行三十个布尔验收，而不是把 PASS 文本写死。
图 13：真实实验输出截图。30/30 表示教学实验里的控制点全部通过；生产发布仍需要真实模型质量、业务结果、容量、安全和回滚证据。
Windows 11 一键执行
下载 实验脚本 与 Windows 启动器 到同一目录：
powershell -ExecutionPolicy Bypass -File .\run_windows.ps1
Ubuntu 26.04 一键执行
下载 Ubuntu 启动器 后运行：
chmod +x ./run_ubuntu.sh
./run_ubuntu.sh
macOS 26 一键执行
下载 macOS 启动器 后运行：
chmod +x ./run_macos.sh
./run_macos.sh
人工验收时，执行 python3 release_gate_lab.py --clean，依次阅读六份分类证据和最终 JSON，不要只看终端最后一行。Agent 自动验收时，把 Agent 任务契约 交给 Agent；它被禁止联网、安装依赖和弱化闸门，必须检查 total=30、passed_count=30、release=PASS，任何失败立即停止并报告具体类别。
十三、如何把这套闸门接入真实 CI/CD
实验是单机教学版本，生产集成建议遵循四条原则：
- 确定性闸门硬阻断：跨租户、重复副作用、未批准高风险动作、审计缺失等不得用人工「忽略失败」放行；
- 概率指标比较置信区间：同一版本多次采样，比较任务成功、质量、延迟和成本分布，不用单次幸运结果；
- 高风险场景独立阈值：普通问答的平均分不能抵消付款、删除、生产控制等关键任务的失败；
- 证据绑定版本：记录模型、Prompt、策略、工具 Schema、数据集、代码提交和环境摘要。
CI 可以快速跑标准库闸门，定时任务运行更贵的模型评测；发布系统消费两类结果，在 Shadow/Canary 阶段加入真实流量指标。若生产 SLO 越界，应自动暂停放量或回滚，而不是等用户在工单里完成故障注入。
十四、Q&A
Q1：三十项是不是一个行业标准？
不是。它们是一份可执行的最小教学基线，用来展示六类边界。真实系统还应根据医疗、金融、IoT、代码执行等风险增加专属场景。
Q2：模型升级后，只重跑答案评测可以吗？
不够。模型可能改变工具选择、参数格式、Token、延迟和拒绝行为，因此策略、路由、工具与成本闸也要重跑。
Q3：为什么策略拒绝不能算失败？
因为它完成了安全目标。应单独统计「正确拒绝」和「错误拒绝」；把所有拒绝都算失败会诱导团队降低安全性。
Q4：Shadow 流量能验证工具调用吗？
可以验证计划和策略，但应阻断真实副作用，或将工具替换为沙盒/只读适配器。不要为了测试直接复制生产写操作。
Q5：离线黄金集会不会过拟合？
会，所以要保留隐藏集、定期加入生产失败案例、做对抗和变形测试，并结合 Canary 的真实业务结果。黄金集是体检表，不是免疫证书。
Q6：是不是 30/30 就一定能上线？
不是。它只说明这三十个确定性断言通过。上线还要满足模型质量、容量、隐私、法规、依赖健康、回滚和业务负责人确认。闸门的价值是明确「什么没证明就不能说已经证明」。
十五、写在最后
AI Platform 最危险的发布方式，是拿几段漂亮回答当作整个系统的健康证明。模型会波动，Provider 会限流，攻击内容会出现，Worker 会崩溃，队列会重投，记忆会过期；发布工程的职责不是祈祷这些事情别发生，而是在上线前主动让它们发生一次。
这篇文章是 AI Platform 旗舰架构 的发布验收篇。你也可以从 架构实践阅读地图 回看工具调用、网关、可观测性与安全文章，或继续阅读本系列的 Worker 幂等、Turn Manager、AI Gateway 和结构化记忆深挖。
参考资料：