夜雨聆风2026 年 7 月 7 日到 10 日，短短四天，出现了至少八篇论文，主题惊人地一致——它们不谈怎么让 AI Agent 更强，而是掉过头去研究一个几乎没人愿意写的问题：Agent 是怎么失败的？失败发生在哪一步？能不能提前发现、当场拦住？
过去两年，Agent 领域的论文几乎都长一个样：提出一个新框架，在某个榜单上把成功率从 62% 刷到 71%，然后宣布"效果显著"。但这一周的风向变了。有人专门去拆那些"看起来成功、其实早就错了"的任务；有人发现自进化 Agent 的一个致命 bug，让它明明在退化却毫无察觉；还有人证明：一个注定要失败的任务，其实在 Agent 动手的第一步就能被预测出来。
这不是巧合。当一个领域开始密集研究自己的失败模式，通常意味着它正在从"炫技"走向"能用"。就像自动驾驶早期都在比谁跑得快，后来才发现真正的护城河是"怎么保证不出事"。
这篇文章就把这波论文彻底讲清楚：Agent 失败到底分几类、研究者用什么办法抓出"真凶"、以及一个正在成型的共识性解法——为什么大家不约而同地想给 Agent 装上"确定性的刹车"。
一、先说清楚：为什么"榜单成功率"是个骗人的指标
要理解这波研究，得先明白它们共同的靶子：resolve rate（任务解决率）这个指标，掩盖了太多东西。
来自新加坡的一篇综述 "Beyond the Leaderboard"（arXiv 2607.05775）把 2023 到 2026 年间 27 篇 Agent 评测论文、覆盖 19 个基准，全部梳理了一遍，得出一个让人不太舒服的结论：
Agent 的失败会随着任务变长而"非线性地叠加"。
这句话什么意思？举个例子。假设一个 Agent 完成单个子任务的成功率是 95%，听起来很高。但一个真实的工作流可能包含 20 个子任务串联，如果每一步都独立，全程不出错的概率是 0.95 连乘 20 次，大约只剩 36%。而这 36% 还只是最乐观的估计——现实里错误根本不是独立的，前一步的小偏差会污染后面所有步骤的上下文，让错误像滚雪球一样越滚越大，真实成功率只会比 36% 更低。
这篇综述把 Agent 的失败归纳成六大类，每一类都很好理解：
第一类，工具调用与参数级错误——调对了工具但参数填错了，比如日期格式反了、把用户 ID 填到了金额字段里。第二类，规划与约束满足失败——Agent 制定的计划本身就违反了某个硬性约束，比如"先发货再付款"这种顺序错误。第三类，上下文累积导致的长程退化——对话或操作越来越长，早期的关键信息被淹没，Agent 到后面就"失忆"了，忘了自己最初要干嘛。第四类，多 Agent 协调失败——几个 Agent 分工时互相误解、重复劳动或者踢皮球。第五类，对抗或欠规范条件下的安全失败——遇到刻意构造的恶意输入，或者遇到规则没写清楚的模糊地带，Agent 就崩了。第六类，测量效度问题——也就是评测本身不靠谱，测出来的分数没法反映真实能力。
这六类里，前四类是"能力问题"，后两类是"可信度问题"。而这一周的多篇论文，恰恰是冲着后面这些更隐蔽、更难测的问题去的。
它最扎心的一句话是："子任务做得好，不代表端到端能成功；给 Agent 加更多脚手架，也不能稳定地提升可靠性。"
换句话说，过去大家习惯的做法——"哪里不行就加个模块补一下"——被证明是不成立的。你补了 A 环节，B 环节可能因为上下文变化又崩了。这就是为什么单看一个总成功率数字，你根本不知道 Agent 是"真的会做"还是"蒙对了"。
再举个更贴近实际的例子。假设你让一个 Agent 帮你"整理一批数据表、算出季度汇总、再生成一份报告"。它第一步读表时把某一列的单位理解错了（比如把"千元"当成了"元"），但这一步不会报错——数据读进来了，格式也对。接下来所有的计算都基于这个错误前提，最后生成的报告数字全错，可流程从头到尾没有任何一步"失败"。你拿到报告，除非亲自核对，否则根本发现不了。这就是"非线性叠加"最典型的样子：一个不起眼的早期偏差，被后续每一步忠实地放大，最终酿成一个完全错误、却看起来一切正常的结果。
二、最可怕的失败，是"看起来成功"的失败
如果 Agent 失败了并且报错，那还算好的——至少你知道它错了。真正危险的是那种静默失败：任务表面完成，工具也没报错，Agent 自己也觉得干得不错，但结果其实是错的。
这一周有两篇论文，分别从两个完全不同的场景，戳破了这种"静默失败"。
场景一：工具会忠实执行一个"不该执行"的操作
第一篇叫 "Reason Less, Verify More"（arXiv 2607.07405）。研究的是会调用工具的 Agent，比如一个帮你订机票、改签、退票的客服 Agent。
问题出在哪？很多工具的设计是"只要你给的参数格式对，我就执行"。它不检查这个操作在业务规则下到底允不允许。
作者在一个航空客服的测试环境（τ²-bench）里发现了一个惊人的数字：在那些预算受限的 Agent 失败案例里，78% 都属于这种"静默错误"。
具体长什么样？比如一个订单已经被取消了，但 Agent 又发出一个"修改这个订单乘客数量"的调用。工具照单全收、正常返回，Agent 以为自己成功改了，用户那边看起来也一切正常——直到某个环节真的出问题，才发现这笔操作从一开始就是无效的、甚至是被篡改的状态。工具不报错，Agent 不自知，这就是"静默"的可怕之处。
作者的解法特别朴素，朴素到有点反直觉：别让模型去"推理"这个操作该不该做，而是在真正执行"写操作"之前，加一道确定性的、只读的检查门（deterministic pre-execution gate）。
这道门不用大模型，就是一段普通的代码逻辑：执行前先读一下当前状态，检查"这个调用和当前状态是否矛盾"。订单已取消？那就拦住修改请求。
效果很直接：在 gpt-4o-mini 上，成功率从 29.6% 提到 42.0%，涨了 12.4 个百分点；即便在更强的前沿模型 gpt-5.2 上，也从 61.2% 提到 71.6%。四道简单的检查门，就补上了大模型再怎么"思考"都补不上的漏洞。
这篇论文的标题起得很妙——"少推理，多验证"。它点破了一个行业误区：我们总想让模型更聪明地"想清楚"该不该做某件事，但对于有明确规则的场景，一段确定性代码的检查，比让概率模型去"自省"要可靠得多。
场景二：自进化 Agent 的"考官"瞎了，它自己却不知道
第二篇更绝，叫 "The Blind Curator"（盲眼策展人，arXiv 2607.07436）。
背景是现在很火的"自进化 Agent"——它能自己积累技能，也能淘汰掉那些没用的坏技能。淘汰的机制很简单：一个内部的"考官"（judge）给每个技能的表现打分，得分太低的技能就被"退休"掉。
问题是：如果这个考官本身是有偏见的，会发生什么？
直觉上你会觉得"无非是多点噪声、评估不太准而已"。但作者证明了一件很反直觉的事：有偏考官不是简单地加噪声，而是会"静默地关闭"整个技能淘汰机制。
他们的发现分两层。第一层：如果考官的错误是"对称的"（有时高估、有时低估，平均下来抵消），那其实没事，技能淘汰照常工作。真正致命的是"误通过"偏差——就是考官倾向于把坏技能也判为"通过"。
第二层，也是最关键的：这种"误通过"偏差有一个尖锐的阈值。一旦越过这个阈值，基于贡献度的技能淘汰机制会被彻底禁用——而且你喂再多的数据都救不回来。坏技能永远留在系统里，拖累整体表现。
最阴险的地方在于：这种机制性的失败，在任何聚合指标上都看不出来。系统的总成功率可能只是缓慢下滑，你会以为是"数据分布变了"或者"任务变难了"，根本想不到是内部的淘汰机制早就死了。
作者给出的建议是：部署前做一次"廉价的缺陷注入审计"——故意往考官里注入一点已知偏差，看看淘汰机制会不会崩，从而摸清你系统的安全边界在哪。
这两篇论文放在一起看，指向同一个道理：Agent 系统里最危险的不是"报错的失败"，而是"沉默的失败"。它们不触发任何警报，却在悄悄地侵蚀系统。
三、任务失败了，到底该怪谁？——"失败归因"成了新学问
假设一个多 Agent 系统跑了 50 步，最后失败了。你怎么知道是哪个 Agent、在哪一步搞砸的？
这在过去几乎是靠人肉去翻日志。这一周，好几篇论文专门在攻这个"失败定位"问题。
抓真凶：定位到"具体哪个 Agent + 最早哪一步"
"Who Broke the System?"（谁搞垮了系统，arXiv 2607.07989）做的就是这件事：把失败同时定位到"哪个 Agent"和"最早的那个决定性错误步骤"。
为什么强调"最早"？因为多 Agent 交互里，错误会传染。第 10 步崩溃了，但根因可能在第 3 步某个 Agent 给出了错误信息，后面全被带偏。如果你只盯着崩溃点第 10 步去修，是治标不治本的。
它的做法是组合拳：用大模型做初步判断，再配几个"多视角独立评估器"从不同角度审查，最后用"置信度感知的聚合"把结论综合起来，还用轻量微调让这个"判官"越用越准。
去噪：从一堆乱糟糟的执行轨迹里提炼"根因"
另一篇 STRACE（arXiv 2607.07702）解决的是相关但不同的问题。
反思式的 Agent 优化有个老大难：真实的执行轨迹又长又乱，一条轨迹里可能 90% 的步骤都跟最终失败无关。如果你粗暴地截断，很可能把那个真正关键的"因果证据"给丢了。
STRACE 的思路分两层。批量层面：把大量失败案例里的共性模式挖出来，过滤掉冗余、保留有代表性的失败。单条轨迹层面：基于文本之间的依赖关系构建一张"依赖图"，做因果定位，把那些"非因果"的步骤剔除，只留下真正导致失败的关键模块。
打个比方你就懂了：假设一条轨迹有 40 步，最后失败。传统做法要么把 40 步全塞给模型让它"反思"（太长，抓不住重点），要么只留最后 5 步（可能把真正的病根切掉了）。STRACE 做的是——顺着"这一步用到了上一步的什么产出"这条线索，把 40 步连成一张依赖图，然后问：最终那个错误的输出，是沿着哪条依赖链传下来的？把这条链保留，其余跟它无关的枝节全部剪掉。最后可能只剩 6 到 8 个真正相关的步骤，模型一眼就能看出问题出在哪个模块。
在一个形式验证任务上，STRACE 把人类专家精心设计的 Agent，成功率从 42.5% 提到了 58.5%——相当于 1.4 倍的提升，而且是靠"想清楚该给 Agent 看什么信息"实现的，不是靠换更大的模型。这也印证了那句老话：喂给模型的上下文，不是越多越好，而是越准越好。
拆穿"结果一样、过程天差地别"
还有一篇 TraceProbe（arXiv 2607.06184），专门盯编程 Agent。
它的出发点很犀利：两个编程 Agent 可能都"解决了"同一个 bug，但一个是干净利落三步搞定，另一个是绕了二十步、反复试错、跳过验证、瞎搜一通最后蒙对的。在 resolve rate 上，这俩一模一样，都是"成功"。但它们的可靠性天差地别。
TraceProbe 把原始轨迹规范化成九类动作，再用规则去识别"反模式"——比如"搜索循环"（反复搜同样的东西找不到出路）、"跳过验证"（改完代码不测试就提交）。
它在 SWE-Bench 的 2500 条轨迹上跑出一个很有价值的发现："搜索循环"是最稳定的"这道题很难"的信号。也就是说，当你看到 Agent 开始反复兜圈子搜索，基本就能判断它陷进去了。这为"什么时候该喊停"提供了一个可观测的判据。
四、更进一步：失败其实在"第一步"就能预测
如果说前面是"事后验尸"，那 "Doomed from the Start"（出师未捷，arXiv 2607.06503）就是"事前算命"——而且算得还挺准。
这篇论文的观察是：Agent 经常在很早的时候就锁定了一条注定失败的路径，然后还傻乎乎地一路走到黑，白白烧掉大量算力。
关键发现是：这种失败，可以从模型的"内部表征"里，在第一轮就预测出来。
注意这里的对比很重要：如果你只看 Agent 表现出来的外部行为（说了什么、调了什么工具），此时去预测成败，准确率跟瞎猜差不多。但如果你去读模型内部的隐藏状态（hidden states），信号就清晰多了——模型自己"心里"其实早就"知道"这条路走不通，只是它的输出还没表现出来。
作者把这个信号做成了一个实用的"提前中止级联"（abort cascade）：所谓级联，就是一道接一道地设卡——每一轮都设一道校准过的门，任务要一路通过所有的门才继续跑，任何一道门判定"没戏了"就当场喊停。而且它有严格的统计保证——保证那些"最终真的会成功"的任务，会以用户指定的比例安全通过所有门，不会被误杀。
效果：在 TextCraft 任务上，设定 90% 召回目标时，Qwen-2.5-7B 节省了 47.1% 的推理算力，Llama-3.2-3B 节省了 37.2%。近一半的算力，本来是浪费在"注定失败还硬撑"上的。
这个思路我觉得特别有启发：它承认了大模型的一个特性——模型的"内部状态"往往比它的"最终输出"包含更多真相。输出是被概率采样和格式约束层层过滤后的结果，而内部表征更接近它"真实的判断"。抓住这一点，就能提前止损。
五、一个正在浮现的共识：给 Agent 装上"确定性的刹车"
把这一周的论文横向对比，你会发现一个很有意思的现象：好几篇完全独立的工作，不约而同地走向了同一个解法方向——在 Agent 执行动作之前，插入一道"确定性的、可验证的检查层"。
前面提到的 "Reason Less, Verify More"（2607.07405）是一个例子。另一篇 "Context-to-Execution Integrity"（上下文到执行的完整性，arXiv 2607.06000）把这个思想做得更彻底。
它提出一套"执行边界系统"：要求每一个动作调用，必须把三样东西绑定在同一份"动作清单"（action manifest）上——用哪些字段、产生什么精确的效果、有没有调用这个工具的权限。三者对不上，就拒绝执行。
在两个测试场景里（AgentDojo 的 720 个 episode，以及 400 个代码仓库的 Agent 任务），它实现了"零字段逃逸、零效果逃逸、零调用逃逸"。也就是说，任何越界的操作都被这道确定性的门挡在了外面。
这个思路其实不新鲜——它就是银行系统几十年来在做的事。你在 ATM 取钱，真正扣款前，后台一定有一段确定性的代码去检查："这张卡是否有效、余额是否够、单笔限额是否超标、今日累计是否超限"。这些检查绝不会交给一个"聪明但偶尔犯迷糊"的模块去凭感觉判断，而是写死成不可绕过的规则。Agent 领域现在做的，就是把这套"关键操作必须过硬性校验"的老规矩，重新搬回到大模型驱动的系统里来。
为什么大家都往这个方向走？我的理解是这样的：
大模型的本质是概率生成，它天然带有不确定性。你没法保证它 100% 不犯错——这是它的特性，不是 bug。那么，与其奢望模型永远想对，不如换个思路：把那些"绝对不能错"的关键决策，从概率模型手里拿出来，交给一段确定性的代码去把关。
这其实是把几十年来传统软件系统的安全思想——权限控制、状态校验、操作前置检查——移植到了 Agent 身上。模型负责"聪明地想办法"，确定性的门负责"守住不能碰的红线"。两者分工，各干各擅长的事。
这个范式我觉得会是接下来 Agent 工程化的主线之一。它不性感、不炫酷，但它是让 Agent 从"demo 能跑"走向"生产能用"的关键一步。
六、顺带一提：其他几个也在"往深里挖"的方向
除了失败模式，这一周还有几个方向值得记一笔，它们的共同点也是"从表面指标往机制深处走"。
一个是Agent 记忆。有篇 NapMem（arXiv 2607.05794）把记忆从"被动检索"重构成了"主动导航的动作空间"——过去 Agent 只是被动地拿到检索结果，现在它学会了像用工具一样，主动去选择查哪层记忆、查完再决定下一步。它把用户历史组织成一个"记忆金字塔"：最底层是原始对话记录，往上是归了类的记忆条目，再往上是话题脉络，最顶层是用户画像。Agent 可以根据当前问题，自己决定该从哪一层调取信息——回答"我上周说的那个项目进展如何"，它会先查话题脉络定位，再下钻到原始对话；而回答"我一般喜欢什么风格"，它直接读顶层画像就够了。这种"按需、分层、主动查"的记忆用法，是靠强化学习训练出来的。
还有篇更理论的（arXiv 2607.08032），干脆把 KV cache 压缩、提示词裁剪、Agent 长期记忆整合这几个看似无关的问题，统一成了同一个"率失真"问题——所谓率失真，是信息论里一个经典权衡：在存储或带宽有限的前提下，该保留哪些信息、以多高的精度保留，才能让最终效果损失最小。这篇论文一针见血地指出：现有所有方法决定"保留什么"的信号，本质都是注意力强度或近因性，而且都以同样的方式失败——在还不知道未来要查什么的时候，就不可逆地丢掉了稍后会用到的信息。
另一个是Agent 训练。有篇 SAO（arXiv 2607.07508）指出 GRPO 这个当红的训练算法，其"组内采样"机制其实不适配长程、异步的 Agent 训练场景，于是改用"单 rollout 采样"（rollout 指让 Agent 完整跑一遍任务、拿到一条从头到尾的轨迹）来降低偏差、提升稳定性。这套方法已经被用在训练一个 750B 参数的开源大模型的 Agent 能力上了。
这些方向和失败模式研究其实是一体两面：一边在诊断 Agent 为什么不行，一边在从记忆、训练的根子上重新设计它。
编者的一点思考
写完这波论文，我最大的感受是：Agent 领域正在经历一次"祛魅"。
前两年的叙事是"给大模型接上工具，它就能自主完成复杂任务"——听起来很美好。但这一周的八篇论文，等于集体承认了一件事：这个美好故事在真实、长程、有规则约束的场景里，漏洞百出。而且很多漏洞是"静默"的——不报错、不触警报，却在悄悄侵蚀系统。
我特别欣赏这批工作的务实态度。它们没有去追求"让模型更聪明"这种玄学，而是干了几件很工程、很扎实的事：把失败分类、定位到具体的人和步骤、在第一步就预测成败、以及最重要的——承认模型的概率本质，然后用确定性的代码去守住红线。
这里面有个更普适的道理，我觉得值得记住：当你没法保证一个组件永远正确时，正确的工程做法不是逼它变完美，而是在它周围建立可验证的边界。
另外，"内部表征比最终输出更诚实"这个发现（第四节那篇）我觉得会越来越重要。它意味着未来评估和监控 Agent，可能不能只看它"说了什么、做了什么"，还得看它"内部在想什么"。这既是机会，也带来新的问题——如果模型学会了"内部想一套、输出装另一套"，我们该怎么办？这一周也确实有论文（关于 CoT 监控被说服攻击攻破的）触及了这个隐忧。这大概是下一个要被密集研究的方向。
一个领域开始认真研究自己怎么失败的时候，往往才是它真正成熟的起点。从这个意义上说，2026 年的这个夏天，可能是 Agent 从"玩具"走向"工具"的一个不太起眼、却相当关键的转折点。
本文涉及的主要论文（可在 arxiv.org 搜索对应编号）：
2607.05775 — Beyond the Leaderboard：Agent 失败模式统一综述 2607.07405 — Reason Less, Verify More：用确定性门拦住"静默策略违规" 2607.07436 — The Blind Curator：有偏考官如何静默瘫痪自进化 Agent 2607.07989 — Who Broke the System？：多 Agent 系统的失败归因 2607.07702 — STRACE：从噪声轨迹里提取失败根因 2607.06184 — TraceProbe：编程 Agent 的过程诊断 2607.06503 — Doomed from the Start：从内部表征提前预测失败 2607.06000 — Context-to-Execution Integrity：Agent 执行边界系统
