把提示词、模型、工具和索引组成发布版本，在无副作用回放中筛查回归问题。
本文于 2026-09-12 补充整理，按 2026-08 专题归档。示例为方案设计，参数用于说明方法，不代表已上线项目或实测成果。
发布单位不只是应用镜像
同一份 Java 代码，换了提示词、模型或知识索引，行为都可能改变。只记录 Git commit，无法解释为什么昨天能正确引用规范，今天却频繁拒答。
建议维护一份不可变发布清单：
releaseId: agent-demo-r1
applicationRevision: example-commit
promptBundle: ticket-assistant-v3
toolContract: tools-v2
modelRoute: route-v4
knowledgeRelease: kb-v7
evaluationDataset: eval-v2
policyVersion: policy-v5
这是合成示例，字段值不对应已存在项目。任务创建时绑定清单，恢复时按兼容规则加载。不能让长任务前半段使用旧工具契约、后半段无声切换新语义。
离线评测是第一道门
先跑输出结构、权限、幂等和状态转换等确定性检查，再跑回答质量评测。安全边界失败应阻止发布，不能靠平均回答分数补偿。
对模型评判器，需要固定标准并保留人工校准样本。Anthropic 的评测文章讨论了不同评判方式的适用范围。对于这个助手，工单实际创建数量和越权次数仍应由程序断言。
比较时展示同一案例在新旧版本的变化，而不仅是总体分数。新版本可能改善普通问答，却破坏少量审批任务。
影子流量必须避免真实副作用
影子运行可以复制经过授权和脱敏的输入，但写工具应指向模拟环境或记录动作提案，不能重复创建真实工单。读取外部接口也可能产生配额和审计影响，所以需要单独预算。
影子系统不一定具备真实请求发生时的全部历史状态。应保存必要的知识快照和工具观察，或者明确哪些步骤使用了当前数据，避免把环境变化误判成模型回归。
影子输出通常不返回给用户，目的在于比较行为。它无法完全替代真实交互中的用户澄清和满意度验证。
灰度按任务保持一致
按租户或 taskId 稳定分桶，让同一任务始终使用同一发布版本。对话中途每次随机选版本，会让问题难以复现，也可能使审批和工具契约不一致。
逐步提高流量时，观察业务成功率、拒绝和澄清比例、成本、长尾耗时，以及高风险动作失败。阈值应来自业务要求和基线，不能直接复制一个通用百分比。
如果流量分布发生变化，需要按任务类型分层比较。灰度组恰好多了简单问题，会让新版本看起来更优秀。
回滚要考虑已经开始的任务
新任务可以切回旧版本；正在运行的任务需要按状态分类。纯问答可结束后重试，等待审批的提案可重新验证，正在执行写操作的任务必须先核实结果。
知识索引回滚不能恢复已被撤销的权限或已删除文档。权限和删除规则属于当前强约束，即使内容回到旧版本，也必须继续生效。
数据库迁移最好先采用向后兼容的扩展，再切换代码，最后清理旧字段。否则模型路由回滚成功，旧代码却读不懂新状态。
验收一次有意失败的发布
让候选版本故意遗漏引用或多发一次工具调用。离线评测应发现问题；如果在影子阶段才发现，也应能定位到具体版本和样本；灰度期间触发回滚后，旧任务不应重复写入。
完成这些验证后，发布记录才真正连接了“改了什么”“为什么允许上线”和“出问题怎么退回”。
