检查开始了，还要知道它看到了什么、改好了什么

2026-10-23 · 当时的记录

“再检查一次”是面对不可靠 Agent 时很自然的反应。但今天的材料说明，检查本身也有一段需要验收的工作。语音代理可能请求拼写，却仍写入错误字符；内部监控可能在规则上覆盖大多数工作，却漏掉压缩上下文后的部分轨迹。前者缺的是修复完成，后者缺的是证据送达。两者无法用同一种模型分数解释。[1][2]

10 月 20 日，我们从任务漏跑的经验提出：预期工作清单不能只由已经发生的轨迹倒推。今天的红队报告把这一判断推进到监控系统内部——即使使用已经被归入“应检查”类别，事件处理链仍可能丢失记录。METR 自身的部署笔记也列出误解政策而未启用监控、子代理动作不可见的情况。新增证据支持独立对账，但仍没有给出当前所有系统共同、完整的覆盖率。[2][3]

语音任务从另一端说明，证据到了也未必完成纠错。代理对困难名字增加核验，意味着它部分察觉了风险；已核验错误仍常留下来，说明风险识别不能替代正确的修复动作。规定拼写、复述、纠正和确认的流程带来增益，同时增加通话时间。由此更值得比较的是每多花一段时间，哪些最终错误减少了，而不是是否出现“我再确认一下”这句话。[1]

架构可以沿着这个问题重新划分。把共享上下文的子代理合并，有机会少丢一次信息；但旧专家若承担了隐含的验收责任，合并后也可能漏报到货日期。把权限放到 OpenShell 这样的环境里，有机会让访问约束独立于模型自述；但策略证明仍需要完整输入和匹配的运行时。真正可迁移的做法，是写清每个接口承诺什么，再给这个承诺一个能被下一步核对的结果。[4][5]

实践上，可以为一小批任务预先登记必须完成的步骤，逐项连接实际记录、检查所见输入、最终结果和异常处理。没有记录、输入不全、判断错误、修复失败，应分开统计。这样既能发现该补哪段程序，也能找到模型判断真正增加价值的地方。这里提出的是待验证的比较方法，本刊没有运行这组实验；已有材料支持分层诊断，还不足以保证它降低总成本。

下一次回访应继续找未告警样本的抽查和人工处理耗时。如果新增检查只是产生更多难以处理的提示，可靠性仍没有完成最后一步；如果最终错误减少且恢复更快，才有理由扩大使用。这个标准也保留了对新能力的期待：更好的判断模型、可重放的证据和明确的工具约束，可以各自改善不同环节，而不必互相替代。

回到当期正文 ↗

2026-10-20 · 当时的记录

当 Agent 承担持续运行的工作，可靠性就不能只问“这次回答对不对”。任务有没有启动，运行中拿到的输入是否可信，结果有没有满足要求，最后有没有人处理异常，分别需要证据。今天的材料把这四层进一步拆开：Meta 让固定编排守住前置步骤，Laminar 沿轨迹找语义错误，Congdon 把监控计划与持续执行分开。它们各有明确作用，不能因为都增加了检查，就当作同一种保证。[1][2][3]

这延续了近几期的一条追问，但改变了观察的位置。10 月 17 日，我们从代码审查想到：只在历史事故上找错，会漏掉审查器对原本正确改动造成的伤害，因此也要看干净样本与执行后果；10 月 18 日讨论成本时，要求先固定任务和验收，再比较费用；10 月 19 日又区分了消息送达、读取与完成交接。那些判断主要围绕已经进入流程的工作。今天 Laminar 评论区的一次漏跑经历，把问题推到了入口之前：有些本来应做的任务，连供检查的记录都没有。[4][6][7]

评论者说，宿主机器休眠与计时器交互，使早晨的任务没有启动，也没有重试。这是他的个人经历，不是 flow-1 性能实验，却足以揭示检查范围的逻辑缺口：检查器若只收到实际产生的轨迹，漏跑就不会进入分母。用一个编辑自拟的例子说明，约定做十件事、只启动八件，即使八条轨迹都判为正确，也只回答了已运行部分的质量。预期任务清单应来自约定，实际开始、结束和例外记录来自执行，两边对照后才知道哪些工作没有发生。[4]

Meta 的七步协议提供了一个具体落点：先查目标是否存在、收齐字段、发现配置、检查警告与审核人，再把领域工作交给专门 Agent。它把若干容易漏掉的前置动作变成固定步骤，却没有证明所有定时任务都一定启动。Laminar 的合同例子则站在后面：任务已运行，问题清单说完成了，附表却仍是旧窗口。两者互补之处，是一个约束执行顺序，一个核对交付含义；若把前者的成功状态直接当作后者的验收结论，漏洞仍会留下。[1][2]

有了轨迹还要问输入是什么。另一位评论者提出，工具成功返回的可能是过期缓存或带提示注入的文本，模型在错误材料上也能作出连贯推理。沿轨迹重读能够发现内部矛盾，却不一定能凭同一份输入确认外部事实。因此我倾向于把任务登记、时间与版本记录、重试上限交给固定程序，把不规则证据的解释和调查方向交给模型；分界依据是这项证据怎样核对，而不是笼统地把简单工作给代码、复杂工作给模型。[5]

最后一层是异常交给谁。Congdon 的原型让固定执行器运行监控规格，触发后再调查并升级给人，保留了从发现到处置的路径。此前代码审查中出现过五十多轮自动审查与修复，说明检查本身也会制造新工作；团队因此同时关注真实缺陷、干净改动上的有害建议和审查轮次。两类系统的故障不同，但可以据此提出相同的验收问题：新增告警有没有帮助某个人作出有效决定，还是只让所有人更忙？这是一种编辑对照，不是跨系统的实测结论。[3][6]

沿着这个区分，下一次比较可以预先登记同一批任务，分别统计未启动、运行中断、交付语义错误，以及发现之后的人工处理时间；同时抽查未告警的任务，防止把沉默全算成功。这是建议的评估办法，并非三位作者已经共同完成的实验。若监控只提高了现有轨迹的检查率，却没减少漏跑或没人处理的失败，它改善的是局部。真正值得继续追踪的，是在同一任务与验收标准下，多完成了多少工作、留下多少返工，以及为这些结果付出了多少人的时间。

回到当期正文 ↗

2026-10-20 · 当时的记录

当 Agent 开始承担持续运行的工作，可靠性就不能只问“这次回答对不对”。一次任务有没有启动，运行中拿到的事实是否可靠，结果有没有满足要求，最后有没有人处理告警，分别需要证据。Meta 的固定编排、Laminar 的轨迹调查与 Congdon 的监控原型，从不同位置触及这些问题；它们还没有构成经过共同测试的一套方案，但已经足以帮助我们拆开验收对象。[1]、[2]、[3]。

最容易忽视的是没有留下痕迹的失败。Laminar 帖下一位读者说，自己的任务因休眠与计时器交互而漏跑；没有轨迹可读，语义检查就无从开始。这不是对 flow-1 检测精度的反证，而是提醒我们：检查器的分母若由被检查对象自己提供，遗漏可能永远不进入视野。需要另一个来自任务约定的清单，记录应当何时开始、结束或报告例外。[4]。

有了轨迹也不等于有了事实。工具返回成功，只能确认接口完成了某种操作；内容过期或被污染时，后续推理仍可能自洽。由此我倾向于把固定程序用于登记、对账、重试上限和状态转移，把模型用于解释不规则证据与提出调查方向。这里的分界应按证据是否可直接核对来划，不能简单按“容易的交给代码、困难的交给模型”来划。[5]。

这一判断仍需用实际工作检验。可以预先登记同一批任务，分别记录漏跑、运行失败、语义错误及人工处理耗时；增加监控后，先看未被发现的错误是否减少，再看告警是否挤占了人的时间。若最终只是把错误转成更多难处理的告警，系统并未因此完成更多工作。后续我会寻找带有完整任务分母、未告警抽查和人工处置记录的对照，而不把监控调用量当作可靠性进步。

回到当期正文 ↗