Agent 上线前的 dry-run 与影子观察期对照清单

10 项可逐条核验的检查:写操作统一打桩、影子期样本覆盖、建议-执行偏差记录、分级放权与回退触发条件。用于判断 Agent 是否可以从「建议者」升级为「执行者」。
← 对照清单

demo 证明的是模型能不能完成任务;上线前真正要回答的是另一个问题:它给出的动作,在真实业务流里是否稳定、可解释、可接管。dry-run(影子执行)指让 Agent 在真实上下文里跑完整决策链,但先不改变真实状态;影子观察期(下文简称影子期)则是在这种模式下积累足够的真实样本,再决定放权范围。

下面的清单按「有 / 部分 / 没有」逐条自查。每项都给出缺失时的生产后果、可执行的验证方法和补齐的第一步。严重度是通常情形下的判断,实际定级要结合系统与业务场景。

1.dry-run 模式下,所有写操作在执行适配器层被统一打桩或标记,不落真实库

缺失时通常为 P0 · rubric 5.5
缺失时的生产后果
影子期的前提是零副作用。如果 dry-run 靠逐个工具各自处理,漏掉一个,观察期本身就在生产里写数据——而这段时间恰恰既没有人工盯守,也没有回滚预案。
怎么验证
打开 dry-run 开关,跑一条会触发建单或改状态的任务;确认目标系统没有新增记录,同时建议动作(工具名、参数、目标对象)被完整记下。
补齐第一步
在执行适配器层加统一的 dry-run 开关,而不是在每个工具里各写一份判断。

2.影子期跑的是真实任务流,而不是构造出来的测试样本

缺失时通常为 P1
缺失时的生产后果
构造样本里跑不出字段缺失、客户表述模糊、历史记录冲突、工具偶发超时这些真实噪音。只在理想输入上通过的影子期,对生产行为没有代表性。
怎么验证
抽查影子期记录的任务来源,确认输入来自生产队列或真实业务事件,而不是测试脚本;同时确认副作用出口处于建议模式。
补齐第一步
把影子系统接到真实输入流,只把下游执行切到建议模式。

3.影子期的时长与样本量有明确标准,覆盖关键任务类型,而不是只跑满固定天数

缺失时通常为 P1
缺失时的生产后果
只按天数结束观察期,低频但高风险的场景可能一次都没出现就被放权。常见生产事故往往出在覆盖不到的那部分任务类型上。
怎么验证
列出关键任务类型清单,逐一核对影子期记录:每类都有样本,高风险类都有人工复核记录。时长通常以 1-2 周为起点,视任务量与风险而定。
补齐第一步
先写下任务类型清单和每类的最小样本数,作为影子期出口条件的一部分。

4.每条建议都记录证据、目标对象和人工最终决策,形成建议-执行偏差记录

缺失时通常为 P1
缺失时的生产后果
只留下「Agent 建议了什么」而没有「人为什么没照做」,影子期结束时既解释不了偏差,也没有依据决定哪些动作可以放权。
怎么验证
随机抽 10 条影子期记录,确认每条都能看到证据列表、建议动作及参数、人工采纳/修改/驳回的结论和原因。
补齐第一步
给影子记录加三个必填字段:证据、建议动作、人工决策及原因。

5.偏差有分类(证据不足、动作过早、工具选错、该升级未升级等),不是只看一个采纳率

缺失时通常为 P2
缺失时的生产后果
采纳率把修复方式完全不同的问题混在一起:证据不足要补数据源,动作过早要加状态门槛,工具选错要改工具说明。混着看,结论往往只剩「再调调提示词」。
怎么验证
查看影子期复盘记录,确认被修改或驳回的样本带偏差类别标签,且每个类别有对应的处理方案。
补齐第一步
先定 5-6 个偏差类别的枚举,人工复核时必须选一个。

6.放权按动作风险分级推进:只读 → 草稿 → 内部写操作 → 对外消息,每级有独立的放开条件

缺失时通常为 P0 · rubric 5.3
缺失时的生产后果
一刀切的结果通常是两个极端:要么所有能力都锁死,Agent 形同摆设;要么对外消息和只读查询一起放开,而事故大多出在前者这类高风险动作上。
怎么验证
检查权限策略配置:每个工具标注了动作级别,对外副作用类动作仍处于建议或审批状态,各级放开条件写在文档里。
补齐第一步
把现有工具清单按四级动作分级逐一打标。

7.影子期的出口标准写成书面规则并需要签署,而不是口头判断

缺失时通常为 P1
缺失时的生产后果
没有书面出口标准,放权决定会随交付压力漂移;出了问题也无法回答「当时为什么认为可以放」。
怎么验证
能拿出一份放权条件文档,条目逐一对应影子期数据:采纳率、偏差分类结果、任务类型覆盖度、高风险样本复核记录。
补齐第一步
把出口条件写进上线评审模板,放权由负责人签署确认。

8.定义了回退到影子模式的触发条件,异常时可以把动作降级回建议

缺失时通常为 P1
缺失时的生产后果
放权不是单行道。没有预先定义的回退触发条件,出现异常时团队会在「继续观察」和「紧急下线」之间摇摆,错过止损窗口。
怎么验证
做一次演练:构造一类高风险偏差(如高风险动作驳回率越过阈值),确认对应动作能被降回建议模式,且流程里明确由谁触发。
补齐第一步
先给一两个指标设回退阈值,例如高风险动作的人工驳回率。

9.影子期的驳回和修改样本沉淀成固定评测集,后续每次变更都会回归

缺失时通常为 P1 · rubric 3.1
缺失时的生产后果
影子期最有价值的产出是真实失败样本。不沉淀成评测集,下次换模型、改提示词时,同样的问题要在生产里再暴露一遍。
怎么验证
检查评测集:包含影子期被驳回/修改的样本及期望行为(含曾出过问题的案例);提示词、工具或模型版本变更时会重跑并有记录。
补齐第一步
把影子期人工驳回的样本导出为带期望行为的评测用例。

10.影子期记录与生产 trace 同结构(run_id、工具、参数、结果),切换到真实执行时不换观测体系

缺失时通常为 P2 · rubric 4.1
缺失时的生产后果
影子期用一套临时日志、放权后另起一套,切换点恰好是风险最高的时刻,前后数据却失去可比性,偏差趋势直接断档。
怎么验证
对比影子期记录与生产 trace 的字段:run_id、工具名、参数、结果、人工决策等结构一致,仅多一个 dry-run 标记。
补齐第一步
让影子记录直接写入与生产相同的 trace 管道,只增加一个 dry-run 标记字段。

先看全部支柱

这份清单只覆盖一个专题。站上的免费上线前检查按场景分流后覆盖全部支柱——数据可信与接地、工具调用、评测回归、可观测审计、安全动作与幂等、成本路由——先定位薄弱支柱,再回来逐项对照。

运行免费上线前自检

自查与付费审查的边界

清单和自检都是自报对照:结论基于你自己的判断,不做证据核验。生产就绪审查与路线图会进入系统本身——逐项核验证据、按支柱加权评分、给出 P0/P1/P2 判级和修复路线图。适合准备放权写操作、或需要一个可辩护结论的团队。

邮件 hello@ideapop.cn,附上自查结果和最不放心的一两项即可。