# 生产 Agent 上线后先跑 7 天影子观察期很多 Agent 项目从 demo 走到生产时会跳过一个很关键的阶段影子观察期。demo 阶段证明的是“模型能不能完成任务”。生产阶段真正要证明的是它给出的动作建议在真实业务流里是否稳定、可解释、可接管。我的做法通常不是马上让 Agent 自动改工单、发消息、改配置或触发设备指令而是先让它在真实流量旁边跑一段时间。它可以读真实上下文也可以给出下一步建议但最终动作仍由人或既有系统执行。这 7 天不是形式主义。它能帮团队看清三件事- Agent 建议和人工决策差在哪- 哪些工具调用经常缺证据- 哪些动作看起来简单但其实需要审批、回滚或补偿。## 影子观察期看什么我一般会把每次任务记录成一个轻量事件而不是只存一段聊天记录。json{caseId: ticket-20260630-1421,agentSuggestion: 将工单标记为配置问题并通知客户等待修复,evidence: [最近一次配置变更发生在 10:13,相同错误码在 3 个租户出现,上游服务健康检查正常],humanDecision: 先转二线确认不直接通知客户,finalOutcome: 配置回滚后恢复,delta: agent_action_too_early}这个结构比“Agent 调用了什么工具”更有用。它能回答一个更现实的问题如果当时放权给 Agent它会不会把事情做早、做错或者做过头。## 先不要追求全自动影子观察期里我会故意把动作分成三层。第一层是只读建议例如查日志、查工单、生成排查摘要。这类动作风险低可以让 Agent 多跑。第二层是内部草稿例如起草客户回复、生成配置变更说明、准备审批单。这类动作可以自动生成但发布或提交前仍要人工确认。第三层是外部副作用例如改订单状态、发客户消息、执行配置变更、触发设备指令。这类动作在影子观察期通常只允许“建议”不允许直接执行。这样做看起来慢但它能避免一个常见误判模型在 80% 场景里表现不错于是团队直接把剩下 20% 也交给它。生产事故往往就在这 20% 里。## 偏差要分类不要只算准确率影子观察期结束后不要只问“准确率是多少”。这个指标太粗。更有用的是偏差分类- 证据不足Agent 结论对但缺关键证据- 动作过早它建议执行但还没到执行条件- 动作过晚它保守等待错过处理窗口- 工具选错该查状态时调用了写工具- 升级失败应该转人工或升级审批但没有触发- 表达不合适技术判断对但对客户或业务方的措辞不合适。这些偏差对应的修复方式不同。证据不足要补工具返回值和提示词约束动作过早要加状态机和审批门槛表达不合适可能要拆出“内部判断”和“外部话术”两个输出。## 可以用一个很简单的判定表text动作类型 影子期权限 放权条件只读查询 可自动执行 命中率稳定日志可解释内部草稿 可自动生成 人工改动率低于预期阈值状态更新 只给建议 幂等、回滚、审批都齐客户消息 只给草稿 话术稳定敏感场景可升级设备/资金动作 不自动执行 需要单独风险评审这张表不复杂但能防止团队把“看起来能跑”的 Agent 误认为“可以放权”的 Agent。## 什么时候结束影子期我不会用固定天数作为唯一标准。7 天只是一个起点更重要的是覆盖到足够多的真实样本。至少要满足几个条件1. 关键任务类型都出现过2. 高风险动作都至少有人工复核记录3. 失败样本已经分类4. 每类偏差都有明确处理方案5. 审计日志能解释“为什么建议这么做”6. 放权范围被写成规则而不是口头约定。如果这些条件没满足就继续影子跑。不要急着把 Agent 从“建议者”升级成“执行者”。## 一个容易忽略的点影子观察期还会暴露组织流程问题。有些时候不是 Agent 不聪明而是人类流程本身没有清楚定义什么情况能自动关闭工单什么情况必须通知客户什么情况需要二线确认什么情况要等审批。如果这些规则在人类团队里都说不清Agent 只会把模糊流程放大。生产 Agent 的上线不只是模型上线也是流程上线。先用 7 天影子观察期把真实偏差看清楚再决定哪些动作可以交给它通常比直接追求全自动更稳。