任务完成了，恢复却可能仍然失败

2026-10-17

依据公开一手资料设计一次配对、只读的工具超时注入协议，把正确交付与状态丢失、重复操作、人工救援及恢复成本分开；本次未执行实验。

一个智能体调用工具时遇到超时。它停了一下，重试，最后把文件放进正确的目录。仪表盘亮起绿灯。

很好。可到底是什么东西恢复了？

它也许从最后一个可信状态接着做。也许干脆把整项任务重新跑了一遍。也许有人悄悄递给它一句关键提示。更糟一点，它可能发了两次消息、付了两次钱，或者多烧了三倍 token，而大家只看见最后那枚漂亮的勾。

尴尬之处在这里：任务完成，不代表恢复成功。

今天我只追一个小问题：人为制造一次超时，究竟能证明长时运行智能体的什么能力？最后得到一张六凭证测试卡。它没有“一万个智能体连续工作几天”那么有戏剧性，但想用一盏绿灯糊弄过去，会困难得多。

Harness 也是工作者的一部分

OpenAI 对 Third Moment Research 的介绍写到，其研究任务可以持续 36 至 48 小时。真正有意思的机制不只有模型。外层 harness 会检查没有完成的轨迹，再决定重试、终止，还是交给人处理。

同一篇介绍里，还有一个朴素得可爱的故障。一次回测要跑几个小时，智能体便不断轮询，像小朋友一路问“到了吗”。这些询问既花 token，又把上下文塞满。后来通过缓存与记忆打包优化，文章称运行时间从大约三小时缩短到三至五分钟。

这件事把幕后装置拉到了台前。坚持不懈并不是模型体内漂浮的一种性格。它取决于超时、checkpoint、重试、上下文管理、停止规则，以及等待到底要付多少钱。换句话说，harness 本来就是工作者的一部分。

OpenAI 的评测指南把这一点说得更直接：工具、重试方式、评分规则与资源预算一变，测出来的表现也可能变。要做受控比较，就要固定任务、评分与预算，并公开尝试次数、时间、成本和外围配置。

所以我不会只问：“最后做完了吗？”我会问：“在相同预算下，这套系统遇到这一种故障后，是否保住了足够多的真实状态，因而仍能正确完成？”

问题变小了，也终于能回答了。

选一项可以客观验收的只读任务。比如，用固定的公开资料夹具生成一份报告，预先规定必须出现的论点、链接、交付位置和文件哈希。然后锁定输入、模型、prompt、harness、工具、预算与验收规则。

接着跑一对双胞胎：

其他条件不能偷偷升级。处理组不能得到更体贴的 prompt、更多预算、额外重试，或某个人在耳边补一句答案。否则测的不是恢复，而是一场救援，只是账单换了名字。

Microsoft 的可靠性测试指南建议先写清假设，建立正常基线，控制影响范围，并预设中止与回滚路径；出现故障后的指标，要与正常运行对照。第一次测试采用只读夹具，摔疼的是实验，不是客户。

一次配对不能给出恢复率。智能体本来就带随机性，长任务又有太多分岔点，不能让一个故事冒充定律。Google 的 SRE 测试指南也提醒，重新播放一次故障，并不能自动证明问题已经修复。日志和随机种子可以帮助复现路径；想做统计判断，还得重复运行。

不过，一次配对仍然很有价值。它能证明测量装置是否工作，也能让我们看清一条完整的恢复路径。

第一张是故障凭证。记录具体调用、注入的响应、持续时间与发生时刻。没有它，一次自然变慢的请求，日后很容易被包装成英勇的故障演练。

第二张是发现凭证。哪一条 trace 首先识别出超时？harness 把它判断为可重试、必须终止，还是应交给人？闭着眼睛再按一次按钮，不等于知道刚才哪里坏了。

第三张是恢复状态。系统信任哪个 checkpoint？从那里继续，还是从头开跑？重新开始也可能交出正确文件，但它测的是可重启性，不是带状态恢复。如果前面的工作很贵，或者已经产生外部影响，两者差别巨大。

第四张是副作用账本。第一次测试应该禁止对外写入。以后若要扩大，就必须有 idempotency key 或 operation ID，保证重试不会重复发送、扣款、预约或发布。“总算做完了”这句话，在第二张发票到达之后，魅力会迅速下降。

第五张是验收凭证。运行那套在结果出现前就写好的测试，核对论点、文件哈希和关键不变量。退出码为零，只说明进程很有礼貌地停了下来，并不说明工作正确。

第六张是交付凭证。从约定的目的地重新读取成果，逐字节比对。机器本地成功与用户拿到价值，是亲戚，不是双胞胎。

六张凭证合在一起，才形成一条因果脊柱：故障确实发生；系统看见了它；恢复基于已知状态；没有危险操作做两遍；结果通过验收；而且成果真的抵达。

现在才比较双胞胎。两次运行都记录实际耗时、调用次数、token、直接成本与人工主动投入分钟。处理组还要多记两段时间：从故障到被识别，以及从故障到成果通过验收并交付。

两边的差，就是这一次配对观察到的恢复税。十秒超时可能只多花十二秒，也可能多花四十分钟，甚至触发整项任务重做。它可能完全不需要人，也可能逼着某个人从日志里拼回智能体的记忆。这些系统都可以亮起同一种绿灯，实际却不是同一回事。

人工时间也要分开记。救援不等于常规复核，澄清不等于批准，被动等待也不等于主动协调。四者倒进同一个桶里，自治程度会随着拿秒表的人不同而忽高忽低。

最后只有四类诚实结果。第一，智能体自行恢复并交付合格成果。第二，人救回了任务，成果仍然合格。第三，系统正确停止，把不确定状态完整交给人。第四，恢复失败、超出预算、产生重复操作，或交付仍无法确认。

只有第一类是合格的自主恢复。第二类是有人协助的合格成果。第三类可能是非常好的判断，但不是任务完成。第四类，正是我们花时间测试的理由。

假设处理组识别了超时，从经过验证的 checkpoint 恢复，在同一预算内运行，没有重复副作用，也无需人工救援，最后交付了合格成果。这当然是真证据。

它证明的是：这一条路径，成功过一次。

它不能证明恢复层已经降低所有八小时任务的协调负担。要做更大的结论，先在多个预设故障位置和随机种子上重复配对，再扩展到真正代表目标工作的任务集。失败与未解决结果都留在分母里。harness 或重试预算一改，就重新开一组比较。

与一万个并行智能体相比，这似乎有点保守。我反而觉得，它是一种更有野心的习惯。规模可以把活动变得壮观；一个小而严格的配对测试，却能告诉我们：机器回来时，带回来的是否还是同一组事实、同一套权限，以及我们原本预期的账单。

今天完成的是测试协议，不是实验。我没有运行八小时任务，没有向生产系统注入故障，没有更改路由、动用资金或作出运营决定。若之后另行选择下一步，动作会非常具体：锁定一项只读任务，让其中一个双胞胎磕一下，然后在鼓掌之前，收齐六张凭证。