很多 AI Agent 项目在 demo 阶段看起来很顺能理解任务能调用工具也能生成一段像样的执行结果。真正进生产时问题往往不是“模型不会回答”而是它开始改真实数据、发真实消息、触发真实流程之后团队才发现权限边界、证据链和回滚方案都还没准备好。我更建议在正式放权之前加一个 dry-run也可以叫影子执行模式。它不是让 Agent 假装工作而是让 Agent 在真实上下文里跑完整决策链但先不改变真实状态。dry-run 要解决什么问题生产 Agent 的风险通常出现在这几类地方证据不足时仍然继续执行工具返回异常时没有停住把只读任务升级成了写操作对外发送消息前没有人工确认出错后不知道修改了哪些对象日志只能看到最终结果看不到决策过程。如果直接全自动上线这些问题会在真实客户、真实订单、真实工单里暴露。dry-run 的价值是把风险提前放到一个可观察、可比较、可复盘的阶段。简单说Agent 可以想可以建议可以生成执行计划但先不要真正动手。推荐的执行链路一个比较稳妥的链路是是否真实任务进入Agent 读取上下文生成计划和候选动作权限与证据校验dry-run?记录建议动作人类执行或驳回对比差异执行适配器真实系统状态变更复盘指标与放权规则这里最关键的不是流程图本身而是把“建议动作”和“真实执行”分开。Agent 的输出先进入一个待审层由系统记录它想调用什么工具、依据是什么、会影响哪些对象、人类最终是否采纳。动作要分层不要一刀切不是所有动作都需要同样严格。一个实用分层可以这样设计typeActionLevel|read_only|draft_only|internal_write|external_side_effect;constpolicy{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 和人类操作之间的差异再讨论自动执行风险会低很多。
很多 AI Agent 项目在 demo 阶段看起来很顺能理解任务能调用工具也能生成一段像样的执行结果。真正进生产时问题往往不是“模型不会回答”而是它开始改真实数据、发真实消息、触发真实流程之后团队才发现权限边界、证据链和回滚方案都还没准备好。我更建议在正式放权之前加一个 dry-run也可以叫影子执行模式。它不是让 Agent 假装工作而是让 Agent 在真实上下文里跑完整决策链但先不改变真实状态。dry-run 要解决什么问题生产 Agent 的风险通常出现在这几类地方证据不足时仍然继续执行工具返回异常时没有停住把只读任务升级成了写操作对外发送消息前没有人工确认出错后不知道修改了哪些对象日志只能看到最终结果看不到决策过程。如果直接全自动上线这些问题会在真实客户、真实订单、真实工单里暴露。dry-run 的价值是把风险提前放到一个可观察、可比较、可复盘的阶段。简单说Agent 可以想可以建议可以生成执行计划但先不要真正动手。推荐的执行链路一个比较稳妥的链路是是否真实任务进入Agent 读取上下文生成计划和候选动作权限与证据校验dry-run?记录建议动作人类执行或驳回对比差异执行适配器真实系统状态变更复盘指标与放权规则这里最关键的不是流程图本身而是把“建议动作”和“真实执行”分开。Agent 的输出先进入一个待审层由系统记录它想调用什么工具、依据是什么、会影响哪些对象、人类最终是否采纳。动作要分层不要一刀切不是所有动作都需要同样严格。一个实用分层可以这样设计typeActionLevel|read_only|draft_only|internal_write|external_side_effect;constpolicy{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 和人类操作之间的差异再讨论自动执行风险会低很多。
