Agent 更难识别格式正确的错误结果

Agent 调用工具，最难处理的未必是超时，而是工具正常返回了一条错误数据。原文解读了一项故障注入研究：面对明确报错，Agent 在 91.3% 的试验中指出了问题；面对格式正确、内容错误的返回值，这个比例降到 58.8%。

对正在做 AI 编程助手、工具调用或业务 Agent 的程序员，这组结果值得看。它提示我们：请求成功、字段类型正确、模型继续执行，都不能证明数据可信。至于加一句「请检查结果」能不能补上漏洞，研究给出的答案也相当克制。

Agent 更会读报错，还是更会核对数据？

Obada Kraishan 在 2026 年 10 月的 arXiv 预印本《Loud Failures, Quiet Failures》中，给 Berkeley Function-Calling Leaderboard（BFCL）的工具层加了一层故障注入：在指定时刻破坏一次调用，再观察 Agent 是否发现、调整计划、恢复任务，以及反复重试。

实验选了 24 个多轮任务，每个任务的用户轮次中位数为 5。环境是可执行、有状态的 Python 对象，覆盖文件系统、交易、旅行预订、车辆控制、消息和工单。

四类故障中，三类会明确报错：超时、工具从注册表消失、参数改名后触发 unknown-argument 错误。第四类是静默损坏：调用成功，返回格式也对，但数字被改动 20% 到 60%，列表少了元素，或者字段被替换。

三种明确故障的发现率分别是 91.6%、91.2%、91.2%，几乎没有差别。但它们需要的处理并不相同：超时可能该重试，工具消失需要换方案，参数改名需要重组调用。静默损坏的发现率却低了约 32 个百分点。

Agent 对错误信号的反应，明显强于对错误内容的核验。

静默损坏试验中，39% 没有在 Agent 的文字输出里引起任何反应；明确报错时，这个比例是 4%。58.8% 和 39% 之外还有少量中间编码，不能直接把所有试验分成「发现」和「忽略」两类。

错误也并非都很隐蔽：油量超过油箱容量、列表比刚才少了项目、股票代码与用户询问的公司不符，都可能通过范围或上下文一致性检查识别。

不过，研究所谓「发现」，依据的是 Agent 写了什么。模型即使内部察觉异常，只要没表达出来，也会被算作未发现。干净试验中，目标调用成功后仍有 26.8% 被指出问题；环境本身也会产生真实错误，因此这个比例不能直接当作误报率。

多想一会儿，为什么没有明显改善恢复？

研究比较了三组同家族模型：claude-haiku-4.5-thinking 与 claude-haiku-4.5、deepseek-r1 与 deepseek-v3、qwen3-thinking 与 qwen3-instruct。推理版本使用 2,048-token 思考预算，主实验共 1,920 次试验，temperature 为 1.0，每次最多调用工具 15 次。

在 450 组匹配比较中，推理版本指出问题的比例低了 9.3 个百分点，却多了 10.4 个百分点的重新规划行为，两者均为 p < .001。Qwen3 的发现率差距最明显，下降 16.6 个百分点，p = .003。

但恢复率只低了 2.4 个百分点，p = .512，没有统计上可检测的差异。这不能证明两类模型相等，也不能推导出「推理模型更差」。

一种解释是，推理更擅长生成下一条行动路线，却未必更擅长核对刚收到的值。这只是论文提出的解释，不是被单独验证的机制。

研究还在 Claude 这组模型上追加了 480 次试验，要求每次工具调用后简短检查结果是否符合预期。instruct 和推理版本的发现率分别增加 0.6、2.5 个百分点，均不显著；静默故障的发现率反而从 60.6% 变为 59.6%。恢复、重复调用和误报也没有可检测的变化。

这只检验了一条提示词和一个模型家族。原文提到，Sun 等人在 EMNLP 2024 的研究中发现，简短提醒能改善单次输出判断。但被要求审查一条结果，与执行多轮计划时主动发现异常，是两种不同任务。

真正的损失，为什么不能只看完成率？

这项研究最值得借鉴的，是先测随机波动，再判断故障影响。

同一任务由同一模型运行两次，即使没有注入故障，最终环境状态也只有 63.3% 的概率一致。因此，研究以各模型自己的无故障运行为参照，并结合重复运行的波动评估故障成本。

工具消失后的恢复率为 39.9%，是唯一出现明确下降的故障，p < .001。超时为 59.6%，参数漂移为 59.2%，静默损坏为 60.4%，均未检测到明确下降。

不能据此认为后三类故障无害。这里的恢复指标是环境最终状态是否一致。Agent 读到错误数字后直接告诉用户，可能完全没有改动环境，却已经给出了错误答案。研究没有测量错误值最终进入用户答案的频率。

环境状态恢复了，不代表最终回答正确。

成本也不只体现在成功率上。故障后，12.5% 到 22.2% 的试验连续至少三次调用同一工具，静默损坏和超时分别达到 22.2%、21.4%。同工具、同参数的完全重复少于 2%，但不断换参数仍可能陷入循环。

相对干净运行，超时和静默损坏各增加 0.5 步，工具消失增加 1.5 步，参数改名增加 1.9 步。触及 15 次调用上限的比例，也从无故障时的 23.2% 上升到 24.8% 至 31.7%。

发现问题同样不等于解决问题。汇总来看，指出问题和没有指出问题的恢复率分别为 55.6%、55.7%。这个比较混杂了故障类型；固定故障类型后，两者存在关联，优势比为 1.51，p = .004，但进一步固定模型后，关联减弱到 p = .098。检测有价值，研究却没有证明检测足以带来恢复。

我的判断

我认可原文把检查放到数据进入 Agent 上下文之前。schema 校验能确认字段结构，语义校验才能检查百分比是否超过 100、油量是否超容量，以及结果是否与先前状态冲突。只监控异常和错误码，会漏掉格式正确的错误值。

但「结构化校验更有效」在这里仍是工程建议。研究直接验证的是 Agent 的表现，以及那条检查提示词的效果，没有给出校验层、独立审查模型、提示词方案之间的对照数据，不能替它承诺收益。

研究范围也有限：它是单作者 arXiv 预印本，仓库 README 标注 IEEE CogMI 2026 待发表；任务来自一个基准家族，模型也不是最大的前沿系统。DeepSeek-R1 还曾把工具调用写成普通文本，导致调用没有执行。

发现率由模型裁判编码。在 92 次双重编码试验中，与人工判断的一致率为 85.9%，kappa = .69。这支持认真看待结果，也提醒我们别把每个百分点都当成精确刻度。

对一般团队，最有用的结论是把返回值验证做实。是否购买推理档、是否增加审查模型，都应在自己的任务上评估。三组模型配对不足以决定所有 Agent 的选型。

能拿来做什么

• 在 Node 工具适配层把结构检查和业务检查分开。对数值范围、对象身份和跨调用状态建立明确约束，让异常值在进入模型上下文前被拦下或标记。
• 为工具消失准备替代路径或明确的降级结果，并为连续调用同一工具设置预算。统计时也要识别参数不断变化的重复尝试，只查完全相同的调用会漏掉大部分情况。
• 给自己的工具链注入超时、参数改名、工具缺失和静默错误，并重复运行无故障任务建立基线。验收时同时检查最终环境状态与用户答案，避免状态一致掩盖回答错误。
• 可以从 MIT 许可的 brittle-agents 实验框架、任务集和轨迹入手设计测试。README 声称所有数字可在一分钟内离线复现，但原文作者明确表示没有亲自运行，采用前仍需自行验证。