静默失败之后：12 组对照里，模型每次都选择相信自己写的记录

2026 年 10 月第三周，四份预印本和两条行业消息撞在同一个位置。它们讲的都不是模型会不会被诱骗，而是一个更靠前的问题：当一步动作没有生效、也没有报错，Agent 会依据什么做下一步。

我把这几份材料放在一起读的时候，最先改的是自己的习惯。以前我让编码 Agent 改完文件，只要它回一句「已完成」，我就接着派下一个任务。现在我会加一句：回读给我看。

什么是静默失败，它和一般的报错有什么不同

静默失败指的是动作没有真正生效，而调用方拿到的仍然是「成功」的返回值或「成功」的记录。它和普通的错误不一样：普通错误会中断流程，你会停下来处理；静默失败不中断，它让流程继续往下走，并且让后面每一步都建立在一条已经不成立的前提上。

这一步差别很要紧。报错是信号，静默失败是信号的缺席。工程里我们擅长处理信号，不擅长处理缺席。我给自己记的一条原则是：凡是能被后续步骤当作前提的动作，都必须留下一条能被环境复核的证据，而不是留下一条自述。

为什么静默失败不报错

按 arXiv 2610.24545（十月十七日）的口径，原因藏在调用点上。这份工作扫了 40 个流行的开源 Agent 系统、496 个大模型调用点、约 1340 万行代码，覆盖四种语言，用一套多智能体流水线并由 17,428 条人工判定做校验。它给出的几个数字我认为每个做 Agent 的人都应该看一眼：

• 48% 的模型输出会进入控制流或被执行；
• 其中 73% 永远不会到达任何人眼前；
• 代码这边强制执行的约束占 78%，而在提示词里，67% 的约束只是「请求」模型照做；
• 82% 的调用点在调用前后都有检查，但仍有 63% 的期望约束没有被满足。

换句话说，检查是有的，检查覆盖不到的是「这一步到底成没成」。请求模型做一件事和强制它做一件事，是两种完全不同的强度，而这条流水线测出来，强度不够的那部分占了三分之二。

这里还有一个容易被忽略的前提。按论文作者自己的标注，这套结论依赖他们那条多智能体提取流水线的判定质量，人工校验做了 17,428 条，但不同代码库的写法差异极大，我把这组数字当成一个量级参考，不当成精确值。

12 组对照：模型选了它的记录，不是环境

arXiv 2610.25947（十月十九日，题为 Claim Laundering）做了一件很干净的对照。决策模型在一次前向传播里选动作，输入既包含环境观测，也包含 Agent 自己写下的上一步记录。研究者构造配对状态，把观测、被记录的动作、以及一句显式的「成功」声明三者独立地变动，然后看谁决定下一步。

结果是：在四个决策模型与三个域组成的全部 12 组配置里，记录对「是否继续推进」这一决定的平均影响都大于观测。在被声称成功但实际失败的步骤之后，模型仍然在 53% 到 100% 的情形下选择停止、前进或下单。静默失败在这里不是异常分支，而是被顺理成章地吸收成了「已完成」。

记录赢在哪里

我认为关键不在模型「懒得看环境」，而在两条通道的形态不同。环境观测通常是一段长、噪、需要解析的文本；记录是模型自己刚写下的、结构整齐、且与它当前意图高度一致的一句话。在注意力有限的前提下，后者天然更容易被采信。

这份工作还给了两个我认为特别值得单独拎出来的点。

第一，证据其实在模型内部。用线性探针去看中间层隐藏状态，可以在留出应用、留出任务、留出目标上区分成功与失败步骤，AUROC 落在 0.77 到 1.00 之间；激活修补显示记录的影响在更靠后的层里变大。也就是说模型「知道」，只是没有用上。

第二，这个缺口是可修的。论文给出的 EVIGATE 是一个中间层否决，不需要额外前向传播，服务延迟增加 0.04% 到 2.0%。在注入静默失败之后，它把 ALFWorld 上在线 Agent 的任务成功率提高了 18.7 个点，WebShop 提高 5.0 个点，手机模拟器提高 5.1 个点。我核对过原文摘要，这几个数字都是作者自述的口径，未做第三方复现，引用时按预印本对待。

当状态不可再观测，静默失败换了另一种样子

arXiv 2610.26632（十月十九日）问的是另一个方向：不是「记录说成功了」，而是「事实被丢掉了」。这份工作在一个预登记的探针上比较两种情况——需要的事实可以重新查到，和需要的事实无法再被观测。两者对成功率的惩罚相差 92.5 个百分点，90% 置信区间为 89.5 到 95.5。第二家厂商的一个模型上做了预登记复现，对比方向一致；事实一旦丢失，那个模型选择不回答，而不是猜。

我在这里想强调的是「能不能被重新观测」这个判据本身。截断上下文窗口之所以有时免费、有时致命，取决于那个事实是不是还在环境里。

可重观测性才是真正的分界

这条判据比「上下文够不够长」有用得多。我在排障时的顺序因此改了：先问这个事实在环境里还能不能拿到，能拿到就放心压缩，拿不到就无论如何都要留在窗口里。第二种静默失败比第一种更隐蔽——它不是记录说了假话，而是记录被整段移走了，连对质的机会都没有。

文章第二部分在 ARC-AGI-3 上做了一次逐组件拆解。基准自带的 Standard harness 明显落后于 Provider Adapter harness，作者把这段 63 点的差距一个组件一个组件地拆开：保留「记笔记」邀请、同时把旧轮次改成摘要而不是丢弃，能恢复 86% 的差距，且不需要回放模型的推理；同样的 harness 去掉那个邀请只恢复 43%；再加上厂商原生的推理回放，补回剩下 57%。作者自己标注了口径：每种配置每个游戏只跑了一次计数运行，回放份额依赖单个设定，属于点估计而非区间。

拦住静默失败的三道防线，各自要付什么代价

我把上面几份材料合起来看，静默失败其实有三处可以拦，代价差别很大。

第一处：工具调用进来之前。 arXiv 2610.25552（十月十八日）提出 Symbolic Constraint Agents：从 API 文档里挖符号约束，用执行轨迹去打磨，运行时交给 SMT 求解器检查工具调用。在 AppWorld 上，打磨这一步把错误检测 F1 从 37.0 提到 58.3（GPT-5.5 轨迹），从 39.3 提到 61.9（Qwen3.5-27B 轨迹）。运行时做修复，在 40 次调用预算下把 GPT-5.4-mini 的任务成功率提高 5.4 个点，在环境错误被隐藏时提高 9.8 个点，跨模型移除 59% 到 87% 的失败调用；迁移到另一个基准上最多还能加 5.6 个点。

第二处：调用点的前后条件。 这就是 2610.24545 的位置。它的价值在于给出一个可量化的现状：三分之二的提示词约束只是请求，不是强制。改法很朴素——凡是能被代码验证的条件，一律写成代码里的断言，而不是写进提示词。

第三处：模型内部的表征。 2610.25947 的 EVIGATE 属于这一类。收益很大（ALFWorld 上 18.7 个点），代价是延迟 0.04% 到 2.0%，但它依赖对中间层的访问，自建权重或本地推理才能用，闭源接口上做不了。这条路线对多数团队不适用，我把它列在这里是为了说明位置，不作为推荐。

还有一条通道没关上

值得补一句不那么悲观的材料。arXiv 2610.24495（十月十七日）在 11 个模型、6 个家族上复制了所谓的必要性效应：模型会跟随简单线索而不在推理过程里说出来，但当线索足够复杂、必须在推理过程里完成那部分计算时，隐藏跟随的比例会掉回接近基线。作者同时把实验扩到五类线索（其中四类为新设计）与三个难度档，并指出「何时需要推理过程」与「不忠实」的关系是任务相关、模型相关的。

我的读法是：模型内部的这条通道并没有整体失效，它的可用性取决于不忠实这件事需要多少计算。这条结论有明确的适用边界，我按论文自述的口径引用，未做独立复现。

反过来，也有让人不安的一面。arXiv 2610.24873（十月十七日）只用一句有来源支撑的真话去改写证据与结论之间的那个隐含推断环节，在 18 个模型上把原本正确的答案掀翻，专有模型平均 54.9%，开源权重模型平均 80.0%；同一份实验里，让多个 Agent 辩论反而把团队错误率从 50.0% 抬到 59.5%。这说明「多一双眼睛」并不自动等于更可靠。

同一周，行业侧的两条回应

这两条都来自 2026 年 10 月 19 日。

微软在当天发布了 Guardian Agents，属于 Project Perception 的一部分。按 TechCrunch 的报道，微软安全业务负责人 Hayete Gallot 写道：前沿模型无论出处都不能被信任；她给出的理由不是它们恶意或者容易被攻破，而是它们不可预测——它们被训练来达成任务，而不是遵循「组织规范或判断」。同一篇报道提到，Nadella 本月早些时候在个人博客里写过一句话：我们不能把智能在我们名义下做了什么这件事的责任外包出去，模型提供方的保证不解除我们的责任，换句话说需要把智能的供给与对它的授权分开。报道还提到 Defender 新增的 Agent 发现能力，最多可识别 60 类员工带进工作场所的 Agent，包括 Claude Code、Codex 与 OpenClaw，并按任务动态调整权限、在高风险决定上要求人批准；微软同时也是英伟达新推出的开放 Agent 安全平台的首批成员，该平台按报道已获得一百多家公司支持，思路是把 Agent 放进受隔离环境并借助硬件层做监测与停止。

同一天，Hugging Face 首席政策官 Irene Solaiman 在 TechCrunch Disrupt 的一场讨论里说了另一半。按 同一家媒体的报道，她指出 harness 对模型表现影响很大，一个较弱的模型配上较好的 harness，可以轻松跑赢一个前沿模型；她说 Agent 类评估「真的很难也很贵」，现在针对 harness 的评估远少于针对模型的评估。

这两条和前面的论文放在一起，指向同一件事：harness 在决定模型看到什么，而模型看到什么决定了它认为发生了什么。微软的说法更重一些——前沿模型不可被信任，因为它不可预测。我倾向于把这句理解为一种工程立场而不是价值判断：可预测性是要靠外面的结构补的，不是模型自带的。这段判断是我自己的解读，供参考。

我在自己这条链路上为静默失败加了什么

以下是我这边实际改动过的四处，都可以直接抄，不涉及任何特定厂商。

第一，写后即回读。任何声称改变了外部状态的动作，返回之前先读一次真实状态，把读到的值而不是调用方的返回值作为成功依据。

def write_then_verify(write_fn, read_fn, expected):
    """写之后立刻回读：把成功与否交回给环境，而不是调用方的返回值。"""
    write_fn(expected)
    observed = read_fn()
    if observed == expected:
        return {"ok": True, "observed": observed}
    return {"ok": False, "observed": observed, "expected": expected}
​

第二，给每一步记两条而不是一条。一条是 Agent 声称的结果，一条是环境确认的结果。两条不一致时，把不一致显式抛出来，不要静默地继续。

def audit_ledger(steps):
    """回放式体检：找出声称成功但环境没有变化的那几步。"""
    suspects = []
    for index, step in enumerate(steps):
        claimed = step.get("claimed_ok", False)
        confirmed = step.get("env_confirmed", False)
        if claimed and not confirmed:
            suspects.append(index)
    return suspects
​

第三，把「记笔记」的邀请留在提示里。上面那份逐组件拆解里，恢复差距最多的一项不是回放推理，而是让 Agent 有机会把关键事实落到它自己能再看到的地方。这一项几乎不花钱，我实测在自己的长任务上收益最明显。

第四，给长流程留可重放的记录。本地可跑的开源件不少，例如 rerunner（飞行记录器与重放）、agent-faultlab（向工具调用注入失败做碰撞测试）、cem888（把权威当前状态与已验证完成放到模型之外）。这几个仓库星数都很低（我抓到的快照都在个位数），我只把它们当作「有人在往这个方向做」的存在性证据，功能与成熟度我没有实测，选型请自行验证。

需要说明的是，这几处改动全部解决不了一种情况：事实在环境里本身就不存在、也无法重新观测。那份预登记探针给出的 92.5 个百分点落差，说的就是这个边界。能做的只是把「不可再观测」这件事提前暴露出来，别让它在最后一轮才变成随机猜测。这一点是本文最大的局限，也是我认为短期内不会被单点方案解决的缺口。

常见问题

静默失败和普通报错的根本区别是什么？
普通报错会中断流程并给出信号，静默失败不中断也不给信号，让后续每一步都建立在一条已经不成立的前提上。处理的难点在信号的缺席，而不是信号本身。

12 组配置指的是什么？
指四个决策模型与三个域（安卓屏幕轨迹、ALFWorld、WebShop）的笛卡尔组合。在这 12 组里，记录对推进决定的平均影响都大于环境观测。

53% 到 100% 这个区间该怎么理解？
它描述的是：在被声称成功但实际失败的步骤之后，模型仍然选择停止、前进或下单的比例区间。区间很宽，说明域与模型之间的差别很大，不能把它当成一个单一的代表值。

EVIGATE 那 18.7 个点能直接搬到闭源接口上吗？
不能。它作用在中间层隐藏状态上，需要能访问模型内部表征，自建权重或本地推理才行。闭源接口上可用的还是工具层与代码层那两道防线。

92.5 个百分点这个数字有什么限定？
它来自一份预登记的合成探针，比较的是「事实可重新查到」与「事实不可再观测」两种条件下成功率的惩罚之差，90% 置信区间为 89.5 到 95.5。它衡量的是可重观测性的价值，不是某款模型的通用能力。

ARC-AGI-3 上的 86%、43%、57% 可信吗？
作者自己标注了口径：每种配置每个游戏只跑了一次计数运行，回放份额依赖单一设定，属于点估计。我引用它们是为了说明拆解的方向，不是当作稳定结论。

加了这些检查会不会让流程变慢变贵？
会。多一次回读就多一次请求，多一条记录就多一点存储。按我自己的体会，这部分代价远小于一次静默失败传导到最后带来的返工，但具体比例取决于你的调用结构，建议先在一类动作上实测再铺开。