本周另一个需要推进的判断，是自动化应该在哪一步算“完成”。PHP 复盘里，风险迹象早已出现，团队却迟迟无法在有代价的修复方案中作决定；Sierra 的语音实验里，代理已经请求核验，错误字段却常常没有改对。两种工作的参与者和时间尺度不同，但都提醒读者：发出一份报告、做出一次检查，与最终状态发生正确变化，需要分别举证。
10 月 22 日的观察已把修复选择与下游恢复纳入交付，23 日又区分监控输入是否送达、纠错是否完成。周报把这些环节放到一起，重点不在多添几张检查表，而在识别下一步到底缺什么。PHP 缺过明确利用路径，也缺过能处理兼容性取舍的人和决策机制；给同一问题再增加十份报告，未必帮助团队选定方案。反过来，更具体的攻击证据确实改变了优先级，不能把新增发现一概视为负担。
Trail of Bits 把可交接的证据做得更具体：同一复现先在原版失败，在补丁版成功，再在撤销补丁后失败，以减少环境偶然变化带来的错误归因；另一个流程检查原本受支持的行为是否被破坏。作者回看一百三十余个已合入改动，确认二十一项回归。新回归检查器在这组材料上减少了误报，也让部分已知问题因为举证不足停在边界状态。工具因此更容易交给维护者判断，但这组内部评估仍不能证明所有项目都会以更少工作交付。
语音实验把“动作出现”与“结果改好”之间的距离放得更大。代理可能请来电者拼写、重复一遍，却继续提交错的字符串。规定核验流程能提高通过率，同时延长通话；更有用的追问是，时间花在确认了正确内容，还是反复确认仍未改正的内容。最终工具中的字段提供了独立于礼貌话术的检查点。实际业务若再涉及多字段、非配合用户，仍需要重新评价。
监控系统则说明，连检查所依据的材料也要单独核对。Redwood 与 METR 的报告评估的是 7 月 21 日及以前的内部系统，发现某些符合监控条件的轨迹没有完整进入检查链。OpenAI 后来表示已修复影响生产防护的漏洞，外部团队明确没有复核这个声明。因此本文借用的是对账方法，不能把历史缺口写成当前覆盖率。预期应该出现的任务和实际收到的轨迹，应有各自的记录来源。
把这些经验迁移到日常 Agent 工作，一个具体起点是挑一批同类任务，预先写下它们需要交付的状态，再沿同一身份记录证据送达、方案决定、执行和验收。没有轨迹、输入不全、判断错误、执行未生效，应分别定位。需要人作取舍时，把可重跑证据和未解决条件交给人；需要工具写入时，核对写入后的状态。这样增加的记录才有机会减少下一位参与者重新调查的时间。
这里提出的是尚未执行的比较方法，不是又一套已经证明有效的流程。PHP 下游站点仍要升级与恢复服务，语音用户仍要付出确认时间；这些负担不能只在工具提供者的账上消失。下一次回访要看同批任务从发现到验收的总等待、返工和人的处理时间。如果新增检查只增加了无法行动的提示，就需要重划责任；如果帮助团队更快选定方案并得到正确结果，才值得扩大使用。
本周另一个需要推进的判断，是自动化应该在哪一步算“完成”。PHP 复盘里，风险迹象早已出现，团队却迟迟无法在有代价的修复方案中作决定；Sierra 的语音实验里，代理已经请求核验，错误字段却常常没有改对。两种工作的参与者和时间尺度不同，但都提醒读者：发出一份报告、做出一次检查，与最终状态发生正确变化，需要分别举证。