很多 AI Agent 在演示环境里都能顺利理解意图、调用工具、生成结果。真正上线时，第一批问题却往往不是“模型完全不会做”，而是系统在边界场景里继续执行，却没有足够证据解释它为什么这样做。
常见信号包括：
- 普通样本表现不错，权限、冲突证据和异常输入却没有覆盖；
- 工具调用成功了，但调用理由、输入引用、输出引用和影响范围没有留下；
- 人工原本会暂停的地方，Agent 仍然继续执行；
- 成本、延迟、重试、降级和人工接管没有统一口径；
- 出问题后，团队分不清是提示词、工具权限、业务规则还是评测集的问题。
这时不适合从 demo 直接跳到全自动执行。更稳的做法，是先做一段影子运行：Agent 接入真实或近真实业务输入，输出判断、调用计划或建议动作，但暂时不直接改变生产状态。真实动作仍由人工或原系统执行，团队用同一批输入比较两边差异。
第 0 天：先选一条能验证的业务流
影子运行不是把所有流程一起丢给 Agent。第一轮应该选择一个边界明确、结果可核对、风险可控制的流程。
| 流程 | 第一轮适合度 | 原因 |
|---|---|---|
| 客服工单分流 | 高 | 可以对比人工分类、优先级和处理建议 |
| 销售线索初筛 | 高 | 可以对比标签、分级和下一步建议 |
| 设备告警解释 | 中 | 需要历史数据和人工确认共同判断 |
| 自动退款审批 | 低 | 涉及资金动作，不适合直接放权 |
| 生产配置变更 | 低 | 影响范围大，应先保留只读建议和审批 |
第一轮只回答三个问题：系统在哪些输入上稳定，哪些场景必须转人工，以及现有日志和回滚证据是否足够支撑下一步放权。
第 1-2 天：先确认数据和日志能不能用
前两天不要急着调提示词。先确认输入是否接近真实分布，以及每次运行是否留下同一套字段。
一条够用的影子运行记录至少应包含：
{
"runId": "shadow_20260712_001",
"businessFlow": "support_ticket_triage",
"riskLevel": "medium",
"agentDecision": {
"intent": "billing_issue",
"suggestedAction": "route_to_finance_support",
"requiresHumanApproval": true
},
"toolCalls": [
{
"tool": "ticket_history_search",
"status": "success",
"latencyMs": 820,
"inputRef": "audit://input/781",
"outputRef": "audit://output/781"
}
],
"humanDecision": {
"action": "route_to_finance_support",
"changedAgentOutput": false
},
"outcome": "accepted_with_review"
}
日志里不要复制客户隐私、生产密钥或完整业务原文。生产记录更适合保留脱敏摘要、哈希、引用标识和审计链接，既能复盘，也不制造新的数据泄露面。
第 3-4 天：把差异按失败模式归类
中段的重点不是展示成功案例，而是把 Agent 与人工决策放进同一张对照表。
| 维度 | Agent | 人工 | 结论 |
|---|---|---|---|
| 意图识别 | 账单问题 | 账单问题 | 一致 |
| 优先级 | P2 | P1 | 低估风险 |
| 建议动作 | 转财务支持 | 先安抚再转财务 | 部分可用 |
| 工具证据 | 2 条历史工单 | 另有合同条款 | 证据不足 |
| 是否自动执行 | 是 | 否 | 必须人工复核 |
再把差异归到工程上可处理的类别：需求理解错误、证据不足、权限过宽、规则冲突、成本失控、下游超时、日志缺失。这样才能判断哪些问题可以靠护栏修复，哪些说明当前流程暂时不适合自动化。
第 5-6 天：只放开低风险半自动动作
如果前几天的数据稳定，可以按风险逐级测试半自动动作：
- 只读检索和摘要；
- 建议标签、分类和下一步动作；
- 生成草稿，但必须人工确认；
- 自动执行低风险内部动作，例如打标签或任务分派；
- 对外发送、退款、删数据和改生产配置继续保留审批。
真正成熟的 Agent 系统不是“所有动作都自动”，而是每类动作都有独立的权限、审批、暂停和回滚条件。
第 7 天：用 go / no-go 评审结束影子期
最后一天不要只写“试运行效果不错”。至少应交付这些结论：
- 样本量和主要输入类型覆盖；
- Agent 与人工一致、部分一致和不一致的比例；
- 未被护栏拦截的高风险错误；
- 工具成功率、失败率、超时率和重试情况；
- 单任务成本以及 P50、P95 时延；
- 日志能否复盘输入、工具、证据和人工决策；
- 哪些动作可以自动、只能建议或仍然禁止；
- 开关、降级路径、回滚责任人是否明确。
如果团队还无法回答这些问题，就不应把影子运行包装成上线成功。继续补样本、日志、权限和回滚，通常比带着不确定性强行发布更便宜。
影子运行真正解决的是什么
影子运行不是为了拖慢上线，而是把“感觉可以”变成一组可审查的证据。它让团队在真实业务边界里看到系统会在哪里犯错、错误会造成什么影响、现有护栏能否拦住，以及人工应该在哪一步接管。
要开始执行，可以直接使用站内的 dry-run 与影子期 10 项清单；需要看整套系统的数据、权限、审计、模型路由和可观测性缺口，则继续做 AI 系统上线前检查。