“再检查一次”是面对不可靠 Agent 时很自然的反应。但今天的材料说明，检查本身也有一段需要验收的工作。语音代理可能请求拼写，却仍写入错误字符；内部监控可能在规则上覆盖大多数工作，却漏掉压缩上下文后的部分轨迹。前者缺的是修复完成，后者缺的是证据送达。两者无法用同一种模型分数解释。[1][2]
10 月 20 日，我们从任务漏跑的经验提出：预期工作清单不能只由已经发生的轨迹倒推。今天的红队报告把这一判断推进到监控系统内部——即使使用已经被归入“应检查”类别，事件处理链仍可能丢失记录。METR 自身的部署笔记也列出误解政策而未启用监控、子代理动作不可见的情况。新增证据支持独立对账，但仍没有给出当前所有系统共同、完整的覆盖率。[2][3]
语音任务从另一端说明，证据到了也未必完成纠错。代理对困难名字增加核验，意味着它部分察觉了风险；已核验错误仍常留下来，说明风险识别不能替代正确的修复动作。规定拼写、复述、纠正和确认的流程带来增益，同时增加通话时间。由此更值得比较的是每多花一段时间，哪些最终错误减少了，而不是是否出现“我再确认一下”这句话。[1]
架构可以沿着这个问题重新划分。把共享上下文的子代理合并，有机会少丢一次信息；但旧专家若承担了隐含的验收责任，合并后也可能漏报到货日期。把权限放到 OpenShell 这样的环境里，有机会让访问约束独立于模型自述；但策略证明仍需要完整输入和匹配的运行时。真正可迁移的做法，是写清每个接口承诺什么，再给这个承诺一个能被下一步核对的结果。[4][5]
实践上，可以为一小批任务预先登记必须完成的步骤，逐项连接实际记录、检查所见输入、最终结果和异常处理。没有记录、输入不全、判断错误、修复失败，应分开统计。这样既能发现该补哪段程序，也能找到模型判断真正增加价值的地方。这里提出的是待验证的比较方法，本刊没有运行这组实验；已有材料支持分层诊断，还不足以保证它降低总成本。
下一次回访应继续找未告警样本的抽查和人工处理耗时。如果新增检查只是产生更多难以处理的提示，可靠性仍没有完成最后一步；如果最终错误减少且恢复更快，才有理由扩大使用。这个标准也保留了对新能力的期待：更好的判断模型、可重放的证据和明确的工具约束，可以各自改善不同环节，而不必互相替代。