很多 AI Agent 项目在 demo 阶段看起来很顺：能理解任务，能调用工具，也能生成一段像样的执行结果。真正进生产时，问题往往不是“模型不会回答”，而是它开始改真实数据、发真实消息、触发真实流程之后，团队才发现权限边界、证据链和回滚方案都还没准备好。

我更建议在正式放权之前，加一个 dry-run，也可以叫影子执行模式。它不是让 Agent 假装工作，而是让 Agent 在真实上下文里跑完整决策链，但先不改变真实状态。

dry-run 要解决什么问题

生产 Agent 的风险通常出现在这几类地方：

• 证据不足时仍然继续执行；
• 工具返回异常时没有停住；
• 把只读任务升级成了写操作；
• 对外发送消息前没有人工确认；
• 出错后不知道修改了哪些对象；
• 日志只能看到最终结果，看不到决策过程。

如果直接全自动上线，这些问题会在真实客户、真实订单、真实工单里暴露。dry-run 的价值，是把风险提前放到一个可观察、可比较、可复盘的阶段。

简单说：Agent 可以想，可以建议，可以生成执行计划，但先不要真正动手。

推荐的执行链路

一个比较稳妥的链路是：

这里最关键的不是流程图本身，而是把“建议动作”和“真实执行”分开。Agent 的输出先进入一个待审层，由系统记录它想调用什么工具、依据是什么、会影响哪些对象、人类最终是否采纳。

动作要分层，不要一刀切

不是所有动作都需要同样严格。一个实用分层可以这样设计：

type ActionLevel =
  | "read_only"
  | "draft_only"
  | "internal_write"
  | "external_side_effect";

const policy = {
  read_only: {
    dryRunRequired: false,
    approvalRequired: false
  },
  draft_only: {
    dryRunRequired: false,
    approvalRequired: true
  },
  internal_write: {
    dryRunRequired: true,
    approvalRequired: true
  },
  external_side_effect: {
    dryRunRequired: true,
    approvalRequired: true,
    extraEvidenceRequired: true
  }
};

比如查询 CRM、读取工单、检索知识库，可以先按只读能力开放。生成邮件草稿、生成报价说明，可以进入草稿待审。修改订单状态、关闭工单、发送客户通知、触发退款，这类动作必须先经过 dry-run 和人工确认。

这样做的好处是，团队不会因为担心高风险动作，就把所有能力都锁死。低风险能力可以逐步释放，高风险动作继续保守。

dry-run 不是只打日志

很多团队会说“我们已经有日志了”。但普通日志通常只记录调用了哪个接口、成功还是失败。对 Agent 来说，这不够。

dry-run 期间至少要记录这些字段：

{
  "task_id": "ticket_48291",
  "agent_goal": "判断是否可以自动关闭售后工单",
  "evidence": [
    "客户最近一次回复表示问题已解决",
    "设备上报状态连续 24 小时正常",
    "知识库规则要求等待 48 小时"
  ],
  "proposed_action": {
    "tool": "ticket.update_status",
    "arguments": {
      "status": "pending_close",
      "reason": "等待 48 小时确认"
    }
  },
  "risk_level": "internal_write",
  "human_decision": "modified",
  "human_action": "只添加备注，不修改状态",
  "difference_reason": "等待窗口未满足"
}

这些字段能帮团队回答几个更重要的问题：

• Agent 的判断依据是否完整；
• 它有没有过早调用写操作；
• 人类修改它建议的原因是什么；
• 哪些规则应该进入提示词，哪些应该进入代码策略；
• 哪些工具可以放权，哪些必须继续审批。

如果 dry-run 只留下“Agent 建议了什么”，但没有记录“人为什么没有照做”，后续优化会很难。

影子期看哪些指标

我通常会看五类指标。

第一是采纳率。Agent 给出的建议，有多少被人类原样采纳，有多少被修改，有多少被直接驳回。采纳率低不一定说明模型差，也可能是工具说明不清、业务规则缺失、权限范围太宽。

第二是证据缺口。每次人类驳回时，最好标记原因：缺少客户确认、缺少设备状态、缺少合同条款、缺少库存信息。这个指标能反推系统还需要接入哪些数据源。

第三是越权倾向。Agent 是否经常把只读任务推向写操作，或者在没有足够证据时建议对外发送消息。这类问题不能只靠 prompt 修，通常要落到策略层和工具适配层。

第四是延迟成本。人工审批会增加时间，dry-run 期要看哪些任务因为审批变慢，哪些审批其实没有价值。后续放权不是凭感觉，而是看风险和收益是否匹配。

第五是回滚可行性。如果某个建议动作真的执行错了，系统能否定位影响对象、撤回消息、恢复状态、通知相关人。无法回滚的动作，要比可回滚动作更晚放权。

什么时候可以从 dry-run 切到半自动

我不会用“跑满多少天”作为唯一标准。更靠谱的是同时满足几个条件：

• 连续一段时间内，高风险建议没有明显越权；
• 人类驳回原因可以被稳定解释；
• 关键证据来源已经接入系统；
• 工具调用有幂等、审计和失败处理；
• 对外动作有人工确认或延迟撤回机制；
• 出错后能明确知道影响范围。

达到这些条件之后，也不意味着全自动。更常见的路径是分场景放权：

• 只读查询自动化；
• 草稿生成自动化；
• 低风险内部状态更新自动化；
• 高风险写操作继续人工确认；
• 对外消息先延迟发送，保留撤回窗口。

这比“要么全自动，要么全人工”稳很多。

一个容易忽略的点：dry-run 也要接近真实生产

dry-run 如果只在假数据里跑，价值会打折。真正要验证的是 Agent 在真实业务噪音里的表现：字段不完整、客户表述模糊、历史记录冲突、工具偶发超时、规则互相打架。

所以影子执行最好使用真实任务流，但把执行适配器切到建议模式。也就是说，上游输入尽量真实，下游副作用先关掉。

这样才能看到 Agent 在生产系统里最容易出错的地方，而不是只证明它在理想样本里能跑。

小结

生产级 Agent 的上线，不应该只有“能不能调用工具”这个问题，还要回答：

• 它为什么建议这个动作；
• 它准备影响哪些对象；
• 人类是否认可这个建议；
• 偏差能不能解释；
• 出错后能不能恢复；
• 哪些动作可以逐步放权。

dry-run / 影子执行模式的价值，就是把这些问题提前暴露出来。等团队能稳定解释 Agent 和人类操作之间的差异，再讨论自动执行，风险会低很多。

对 AgentKick 这类生产 AI Agent 系统交付来说，我更愿意把 dry-run 当成上线前的必经环节，而不是锦上添花的测试步骤。真正能进生产的 Agent，不是 demo 里最会说话的那个，而是能被观察、能被接管、能被复盘、能逐步放权的那个。