把提示、模型与工作流逻辑作为一个 AI 发布版本

AI 生产发布的单位不是模型端点或提示文本，而是当时实际控制服务行为的整套配置。若只回滚模型，新提示、工具模式、权限或工作流仍可能留在线上。团队必须为完整行为栈赋予共同身份，才能确认测试对象、异常请求所用配置，以及应恢复的兼容已知良好版本。

哪些内容才算同一个 AI 发布？

一个 AI 发布应涵盖所有能实质改变服务行为、权限、风险、成本、延迟或可观测性的运行依赖。NIST 建议盘点相互关联的系统组件，包括第三方软件和数据；Google Cloud 也把配置、验证、元数据、服务基础设施与监测列为生产系统的一部分。具体边界须按系统影响确定。

• 提示内容及其不可变版本或内容摘要
• 已解析的模型快照、温度、输出上限和其他实际推理参数
• 工具模式、工具版本、调用权限及所需人工批准
• 政策、护栏、拒绝与升级规则
• 检索来源、上下文组装方式和资料快照
• 工作流代码、路由、重试、交接与例外逻辑
• 输入输出模式、运行依赖及行为相关环境绑定

评估数据集、评分器、量表和门槛虽通常不在服务路径内执行，却会影响批准决定，因此也须版本化并关联发布记录。组件可保留各自历史，但完整运行候选必须有共同发布标识。凡提示、模型、参数、政策、工具契约、工作流、模式、依赖或环境绑定改变服务行为，便应形成新候选。

如何把整套行为配置绑定进发布清单？

冻结不可变候选清单，并让字段指向当时解析出的对象，而非浮动别名。清单至少记录发布标识、时间、负责人、目标服务、状态、停止条件、回滚负责人及前一已知良好发布。MLflow 的提示版本可保持不可变，但别名和部分附带模型设置仍可能改变，所以“production”或“latest”不能充当可重建身份。

• 组件：版本号、提交标识、制品摘要、内容哈希或其他稳定引用，以及实际生效设置
• 环境：目标服务、功能旗标标识、路由约束、获准连接和适用的检索或资料引用
• 兼容性：模式变化、迁移要求、供应商可用性、工具契约和状态读取条件
• 治理：发布负责人、批准者、停止条件、回滚目标和外部动作处置手册
• 证据：构建记录、契约测试、评估版本与结果、限制、批准及分阶段观察

例如 support-assistant-r18 可绑定提示 p-42、模型快照 m-2026-07 及参数、CRM 工具模式 t-9、权限政策 policy-12、工作流提交 wf-a71、输出模式 reply-6 和运行依赖锁，再关联评估套件 eval-23 与评分器版本。OpenAI 建议固定模型版本并进行应用评估；MLflow 则支持明确关联模型与特定提示版本。

清单冻结后，任何影响行为的组件、设置、权限、上下文或环境绑定变化都须取得新发布标识；计划内流量和部署时间则写入关联的晋级记录。r17 只有确认兼容新增的可选到期日与升级字段后，才能成为回滚目标。清单记录获准连接的身份而非密钥，并让代码、参数、模式、制品及评估结果可在同一证据链中查询。

凡是能改变服务行为，或改变批准该行为所依据证据的内容，都应在发布记录里拥有已解析的身份。

哪些证据足以决定候选能否晋级？

完整候选通过适用关卡，并记录由谁决定晋级、暂缓或拒绝后，才应进入下一阶段。发布说明须涵盖行为目标、变更依赖、受影响场景与接口、权限或可观测性变化、限制、剩余风险、上线负责人及兼容回滚目标。NIST 强调记录评估方法并明确判断是否继续部署，因此关卡必须形成有责任归属的决定。

• 写清变更希望改善的工作结果，以及明确不打算改变的行为
• 列出受影响的语言、缺失上下文、长对话、工具调用和例外路径
• 比较当前发布与候选的任务质量、升级、拒绝、工具、可靠性、延迟和成本表现
• 列明未解决限制、残余风险、观察方法、停止条件及外部动作处置路径

OpenAI 建议评估采用真实工作流案例、代价高昂的边缘案例、领域人员复核及评分器审计。Google Cloud 建议将候选与当前或基线版本比较，并检查重要分段和服务接口。单一平均分不得掩盖重大契约、权限、安全或分段退步；评估数据、评分器、量表与门槛也须版本化。

每项关卡都须明确产出晋级、暂缓或拒绝，而不只是“已测试”。较高风险发布可分开变更作者与批准者；GitHub 的部署保护可执行审核和外部检查。即使小团队由同一人兼任，也应保存证据、决定、理由及例外。门槛须按服务目标与风险设定，不能照抄其他服务的数字。

同一个候选应如何分阶段进入生产环境？

同一个已解析候选应依次经过影子测试、内部使用、固定生产群组、扩大曝光及全量流量，并在各阶段与当前发布比较约定信号。NIST 支持部署前测试与运行中监测，OpenAI 也指出外部发布仍需线上实验。两类证据互补，但离线评估、影子流量和小范围金丝雀都不能证明覆盖所有生产情况或罕见失败。

1. 先以代表性近期请求做影子或非执行式重放；禁用或沙箱化写入工具及其他有后果的动作。
2. 让内部运营团队使用候选，并继续要求人工批准一切外部动作。
3. 把一个固定而可追踪的生产群组分配给候选，避免同一使用者在版本间来回切换。
4. 达到预先约定的观察条件后逐步扩大流量，持续比较任务、安全、工具、可靠性、延迟与成本信号。
5. 全量上线后继续附带发布标识监测，并在规定保留期内维持已验证的回滚目标。

各阶段须推广同一个候选；任何提示、模型设置、工具、权限、政策、检索、工作流、模式、依赖或行为相关绑定变化，都要建立新候选。按获批计划调整曝光可记为同一候选的部署事件，并记录群组、流量、时间、观察期和结果。Google Cloud 未规定通用比例或时长，这些值须按风险、流量、发现延迟和团队承接能力决定。

何时应停止发布，回滚又必须恢复什么？

若出现预先声明的安全或政策违例、未授权工具行为、重大契约失效或严重可靠性故障，发布应立即停止；其他退步则按服务门槛决定暂缓或回滚。NIST 把部署视为明确的继续或暂停决定，因此模糊发现可进入调查期，但须记录处置、负责人和复核条件。门槛与观察期必须按服务风险制定。

• 硬停止：安全、政策、权限、关键契约或严重可靠性问题
• 暂缓调查：证据不足、影响范围不清或信号互相矛盾
• 回滚：把后续流量恢复到完整且兼容的已知良好发布
• 恢复验证：确认核心请求、工具权限、模式和监测均正常

回滚目标须是完整配置包，而非只换回模型。恢复前应检查状态模式、资料迁移、供应商可用性、工具契约、路由和新增字段。Google Cloud 建议预先测试前一服务版本能否迅速、安全恢复，并随部署元数据记录该版本。演练还应记录切换方式、恢复检查、负责人和预期信号。

配置回滚只改变后续流量，不会删除消息、撤销写入、取消审批或逆转已完成的外部动作。团队应凭发布标记的追踪找出受影响请求、路径及动作标识，再按获授权手册进行隔离、核对、纠正、通知或补偿。OpenAI Agents SDK 可记录工具调用，但追踪本身不赋予纠正权限；撤回 r18 也不会删除既有 CRM 任务。

保留哪些记录，日后才能重建 AI 发布？

可重建发布的最小记录须说明有效配置、评估依据、批准决定、实际曝光及最终处置。Google Cloud 建议保存组件与流水线版本、执行信息、参数、制品、评估结果及前一版本引用。生成式 AI 工作流还应保留候选清单、环境绑定、兼容性结果、部署与回滚事件，以及决定负责人和时间。

• 不可变候选清单及所有已解析组件和参数
• 评估数据、评分器、量表、门槛、结果与人工复核
• 兼容性检查、批准、例外、停止条件和回滚目标
• 部署事件、群组规则、流量分配、观察期和最终处置
• 发布标记的追踪、请求标识、工具动作标识和修复记录

发布标识须加入追踪，才能把生成、工具调用、交接、护栏、时间和结果归因到服务该请求的候选。OpenAI Agents SDK 可记录这些事件并排除敏感输入输出；OpenAI 也建议保存供应商请求标识以便排障。无需为追求完整而保留每段客户载荷，敏感内容的收集、期限与访问须遵循组织政策。

完整记录可重建有效配置与批准依据，却不能保证随机或托管 AI 服务逐字重现旧输出。目标应是“配置可重建”和“决策可重建”，即确认生效设置、评估依据、放量过程及停止或回滚理由。先采用覆盖这些问题的最小发布包；涉及敏感资料、重大权限、受规管流程或外部动作修复时，应由组织内合资格人员判断。