AI Agent 如何从测试走向生产：影子运行与小流量上线

Google Cloud 的质量指南建议对新模型做小流量测试并验证回滚；该文原本面向预测式机器学习。这里将分阶段试验原则用于企业 Agent，是本站分析。对于会改变业务状态的 Agent，还要补上执行授权和副作用检查。

把写接口从影子环境中移除，或由执行层明确拒绝写入。仅在提示词中说“不要执行”不够。若发送邮件、创建工单或扣减库存仍然可调用，误调用就会影响真实业务。

可以只读获取授权任务数据，生成建议并写入独立评测记录。记录输入版本、权限范围、建议和人工实际处理结果，方便按同一条件比较。影子记录本身也可能包含敏感资料，要限制访问和保留时间。

选样本时覆盖不同渠道、资料完整度和业务时段。只选配合程度高、资料最齐全的用户，会得到偏乐观的结果。无法覆盖的类型应在结果说明中列出来。

人工结果也可能出错，不能直接把所有差异都判为 AI 失败。让负责人按证据复核，必要时修正规则或标注。Anthropic 的评测文章也强调轨迹与最终结果要分别检查。

开放范围至少说明谁能用、能处理什么对象、允许哪些动作以及遇到例外找谁。可以先开放生成草稿，再开放受限写操作；不要让一次开关切换同时释放所有工具权限。

放行条件由项目约定：关键错误不能出现、业务质量达到目标、时延满足使用需求、负责人能够接手异常等。具体比例和观察时间没有通用标准。记录样本量与任务分布，避免把少量成功推成稳定结论。

停止条件需要可自动触发或由值班人员立即执行。例如发现越权访问、关键规则错误、重复写入或异常费用增长，先暂停相应动作并保留诊断记录。紧急停用不应依赖重新部署整个系统。

保存模型与提示词配置、工具版本、索引版本和允许动作清单。回滚时要处理排队任务和正在执行的任务，明确哪些继续、哪些暂停、哪些需人工核对。只切回旧模型，未必能阻止新配置创建的任务继续执行。

外部副作用单独处理。已经发送的消息无法通过恢复配置自动收回，已经创建的退款要按业务状态查询与处置。演练时选不会影响真实客户的数据，验证开关、权限和任务状态是否一致。

上线负责人、业务负责人和系统维护者各自确认自己的部分。不要只保存一个“发布成功”标记；保留放行依据、当前限制和恢复步骤，下一位值班人员才能理解。

第一阶段拿既有脱敏申请回放，检查队列、缺失字段与禁止动作。第二阶段读取当前申请生成候选分流，在独立记录中与人工结果比较，不创建真实工单。第三阶段只对已选业务组开放创建待处理工单，退款和对外发送继续由原流程完成。

每次扩大范围前检查新的证据：影子运行是否暴露资料版本问题，小范围使用是否出现重复工单，维护者能否定位失败。发现用户经常改写建议，应记录改写原因；这可能是规则未覆盖，而不是用户“不信任 AI”。

这里的阶段并非固定三周计划。某阶段达不到放行条件就停留或缩小范围；已经验证的部分可以继续使用。项目进度由证据决定，时间表则用来安排检查和责任人。

准备一组近期脱敏任务，记录真实流程的当前基线，列出影子环境仍可访问的工具，并在上线前做一次暂停与恢复演练。先解决能执行写入的影子环境，再扩大样本。

这套流程适合持续处理真实业务的 Agent。低影响内部创作工具可以采用更轻的发布过程；资金、权限或客户承诺类动作需要更细的约束。小流量上线能够发现问题，但不保证未观察到的风险不存在。