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

AI生产发布的对象不是某个模型端点，也不是一段提示词，而是所有能够改变实际服务行为的配置组合。只回滚模型，却把新提示词、工具模式、权限规则、检索设置或重试路径留在线上，并不等于恢复旧版本。没有统一发布身份，团队就很难回答三个基本问题：故障请求究竟由什么配置处理、评测时使用的是否正是上线候选、需要把流量恢复到哪套兼容配置。

哪些内容应共同算作一次AI发布？

一次AI发布应覆盖所有可能实质改变服务行为、权限、风险、成本、时延或可观测性的运行依赖。NIST把AI生命周期活动视为相互依赖的整体，要求对包括第三方软件和数据在内的系统组件建立清单，并记录部署前及运行期测试。Google Cloud也将生产机器学习系统描述为除模型代码外还包含配置、自动化、验证、测试、元数据管理、服务基础设施和监控。具体边界因系统而异，但不能默认以模型为界。

• 提示词及其模板、变量规则和响应格式。
• 已解析的模型快照、温度、输出长度、采样参数和其他有效推理设置。
• 工具模式、可调用范围、权限、审批要求、策略与护栏。
• 检索源、上下文组装、路由、特征开关和其他会改变请求处理的环境绑定。
• 工作流代码、输入输出模式、运行依赖、重试、交接和异常路径。
• 评测数据集、评分器、量规和阈值；它们通常不参与线上服务，却会影响是否批准发布。

组件各自的版本历史仍然有价值，但完整候选还需要一个共同身份。只要提示词、模型设置、工具合同、权限、策略、检索、工作流、模式、依赖或行为相关绑定发生变化，就建立新候选版本。第一方和第三方依赖是否纳入，也应依据其能否实质影响服务或发布决定，而不是依据采购关系或代码归属。

怎样把行为栈绑定为一份发布清单？

做法是冻结一份不可变候选清单，并让每项组件都指向可稳定解析的版本、提交、产物摘要、内容哈希或签名引用。发布清单应以一个身份绑定提示词、模型配置、工具、权限、策略、检索或上下文、工作流、模式、运行依赖和环境绑定。清单还要记录创建时间、负责人、目标服务、状态、停止条件、回滚负责人和上一已知良好版本；任何行为相关组件变化都产生新的发布ID。

不要把“production”或“latest”之类浮动别名当作版本本身。MLflow的提示词模板版本不可变，但别名可变，且部分附带模型配置在提示词版本建立后仍可能被修改；它也能够记录模型与具体提示词版本地址之间的关联，使提示词—模型血缘可以被明确查询。OpenAI指出模型快照之间的提示行为可能变化，并建议固定模型版本及运行应用级评测。因此，清单应保存别名在候选冻结时解析出的目标及全部有效设置。

以内部客服助手为例，候选版本support-assistant-r18绑定提示词p-42、模型快照m-2026-07及参数、CRM工具模式t-9、权限策略policy-12、工作流提交wf-a71、输出模式reply-6和运行依赖锁。关联发布包再指向评测套件eval-23及评分器版本。其回滚目标support-assistant-r17只有在新增截止日期与升级原因字段被确认兼容后，才能被标为可恢复目标。

• 在清单中保存获批连接、数据或检索引用、特征开关身份及路由约束，但不保存密钥本身。
• 把兼容性约束、迁移条件和上一已知良好版本写入候选记录。
• 把流量分配、部署时间和每阶段结论写入关联的晋级事件，不要反向修改冻结清单。
• 预先批准的单纯放量可以沿用同一候选；会改变单次请求行为、权限或上下文的路由与绑定变化必须新建候选。

凡是能改变服务行为，或改变授权该行为所依据的证据，都必须在发布记录中拥有已解析的身份。

哪些证据才足以决定候选版本是否晋级？

决定候选版本是否晋级的，应是一组面向具体工作流、针对完整候选执行且责任明确的证据门禁。面向决策的发布说明应写明行为意图、变更依赖、受影响场景与接口、权限或可观测性变化、证据、限制、剩余风险、负责人和兼容回滚目标。NIST要求测试、评测、验证与确认方法可记录、可重复，并要求明确判断开发或部署是否应继续。

门禁应针对真正准备晋级的完整候选版本，检查适用的合同、任务质量、安全与权限、工具行为、可靠性、时延、成本、重要分群和高代价边缘场景。OpenAI的评测指导认为通用模型评测无法覆盖具体业务工作流的全部细节，并建议使用真实场景、代价较高的边缘案例、领域人员参与和自动评分器审计。一个总分不能掩盖合同破坏、越权行为、安全问题或关键分群退化。

评测数据集、评分器、量规和阈值需要版本化，因为门禁变化会改变同一运行候选结果的解释。Google Cloud建议把候选版本与当前或基线版本比较，检查重要数据分群和服务接口，并把评测结果写入流水线元数据。每道门禁最终都要留下晋级、暂停或拒绝的结论和负责人；对风险较高的发布，可把变更作者与批准人分开。

同一个候选版本应如何逐步进入生产环境？

同一个已解析候选应沿着影子验证、内部使用、固定灰度人群、扩大流量和全量发布逐级前进，而不是在每一阶段悄悄更换组件。NIST建议在部署前测试、运行中监测，并在接近实际部署的条件下展示系统行为；OpenAI的评测指导也指出评测需要随模型、数据、目标和失败模式变化而维护，对外发布仍需开展线上实验。离线通过并不代表生产条件已被完全覆盖。

1. 在可行时先对代表性请求做影子或非执行式重放，关闭或沙箱化写入工具和其他有后果的动作，比较候选与当前版本的完整路径。
2. 向内部运营团队开放候选，保留所有外部操作的既有审批要求，验证实际交接和异常处理。
3. 把固定且可追踪的生产人群分配给候选，比较约定的任务、安全、工具、可靠性、时延和成本信号。
4. 达到预先约定的观察和样本要求后再扩大流量，同时保持人群分配稳定并持续记录版本标识。
5. 进入全量后继续监测，并在规定保留期内保持兼容的旧版本和恢复能力。

Google Cloud的部署指导包含预发布检查、冒烟测试、小流量金丝雀发布和线上比较，但没有给出通用流量比例或观察周期。这些值应由服务风险、请求量、问题发现延迟和运营承载能力决定。各阶段应晋级同一个已解析候选版本；若中途改变行为相关配置，就应创建新的发布身份并重新形成相应证据。单纯按预案增加曝光则只需新增部署事件。

影子流量与真实交互并不等价，有限灰度人群也可能遗漏罕见场景或其他生产条件。因此，发布记录要同时保留人群规则、流量分配、观察时段、比较结果与阶段结论，不能把灰度通过写成“已证明安全”。它提供的是受边界限制的运行证据，价值在于尽早发现问题并控制暴露面。

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

安全或策略违规、未授权工具行为、合同破坏和严重可靠性故障应在放量前被定义为硬停止条件，其他回归则采用服务专属界限。含义不明、样本不足或信号冲突的发现可以先暂停调查，不必一律自动回滚，但必须记录结论和负责人。NIST把部署视为需要作出继续或暂停判断的风险决定，并要求在相互依赖的生命周期活动中持续监测和管理风险。

触发回滚时，应把流量恢复到完整、兼容且已知良好的发布版本，而不是只换回旧模型。恢复前检查输入输出模式、状态变更、数据迁移、提供商可用性、工具合同、路由和环境绑定。Google Cloud建议验证先前服务版本能够被快速、安全地恢复，并在部署元数据中保留前一版本指针。恢复动作应提前演练，演练结果也要进入发布证据。

配置回滚只能改变后续流量去向，不能自动撤销已经完成的消息、数据写入、审批或外部系统操作。对客服助手而言，换回support-assistant-r17不会删除r18已经创建的CRM任务。OpenAI Agents SDK追踪能够记录工具调用及相关工作流跨度，为定位某个发布版本处理过的请求提供运行证据，但仍需把发布ID写入追踪元数据。

• 先隔离候选版本和仍可触发后果的动作路径。
• 依据带发布标识的追踪定位受影响请求、工作流路径及外部操作ID。
• 由获授权的负责人按独立处置手册执行遏制、核对、纠正、通知、恢复或补偿操作。
• 分别记录流量恢复时间与外部操作处置结果，避免把两类完成状态混为一谈。

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

要在日后重建一次AI发布，最低限度应保留不可变候选清单、已解析组件与参数、环境绑定、兼容性结论、评测资产版本和结果、审批、部署事件、流量分配、运行发现、回滚事件及最终结论。Google Cloud建议记录流水线和组件版本、执行时间、执行者、参数、产物、评测结果以及前一模型指针。记录之间应以发布ID相连，而不是依赖文件名或口头约定。

把发布ID写入追踪元数据，才能把生成、工具调用、交接、护栏、耗时和结果归因到实际处理请求的候选版本。OpenAI Agents SDK追踪可以记录工作流层级、生成、工具调用、交接、护栏、任务、轮次、时间戳和元数据，同时允许排除敏感的模型或工具输入输出。还可在提供商支持时记录其请求ID与应用追踪ID，以便跨系统排障。

完整审计链不等于保存每一条提示、工具输入、模型输出或客户载荷。敏感内容是否采集、抽样和保留，应遵循组织的信息处理与留存规则；发布记录可以优先保存标识、摘要、结论及受治理的必要样本。固定标识和归档设置支持配置与决策复现，但随机生成或托管AI服务仍可能无法逐字节重放相同输出。

可先采用最小发布包：一个不可变运行候选、一组版本化保证证据、一串阶段晋级决定，以及一个经过兼容性验证的回滚目标。若变更涉及敏感数据、重要权限、受监管工作流、留存义务或外部操作处置，应让组织内具备相应职责的安全、隐私、法律、档案、风险或领域人员参与判断；本文方法本身不替这些角色作出专业结论。