大模型越大越抗错？MCP故障注入实验给出否定答案

工具调用型 LLM Agent 正在成为 AI 应用的主流形态，而 Model Context Protocol（MCP）则被越来越多地用作连接模型与外部工具的"插座"。但现有基准测试几乎都默认工具会准时、正确地返回结果——这一假设在真实世界中并不成立。一篇新研究通过协议感知的故障注入实验，系统检验了 Agent 在真实 MCP 故障下的韧性，并得出一个反直觉结论：模型规模并不能换来容错能力。

rss source: Tool-Calling LLM Agents Under Realistic MCP Faults: Scale Does Not Purchase Fault Tolerance

现有评测为何掩盖了 Agent 的脆弱性

当前主流的能力基准（如工具调用准确率、任务完成率）大多在"工具永远正常"的理想条件下测量。这相当于只考察了 Agent 在实验室里的表现，却忽略了生产环境中工具超时、报错、间歇性失败等常见状况。研究指出，仅凭能力基准来评估工具调用 Agent，会系统性地掩盖其运维层面的脆弱性。

换句话说，一个在干净基准上得分很高的 Agent，可能在实际部署中因为一次工具调用失败就整条任务链崩溃。这种"基准高分、线上翻车"的落差，正是该研究想要量化的对象。

工具调用（Tool Calling） 指 LLM 在生成文本时输出结构化的函数调用指令，由外部运行时执行后将结果返回模型继续推理。与传统的文本补全不同，工具调用要求模型理解工具 schema、正确填充参数，并在多轮交互中维护调用状态。Model Context Protocol（MCP） 是 Anthropic 于 2024 年底提出的开放协议，用 client-server 架构标准化模型与外部工具、数据源的连接方式，使同一套工具定义可被不同模型和框架复用。MCP 服务器以 JSON-RPC 形式暴露 tools、resources、prompts 等原语，Agent 通过 MCP 客户端发起调用并等待响应。正因为 MCP 将工具调用抽象为网络请求，超时、连接中断、服务端错误等分布式系统固有的故障模式才被引入到 Agent 的执行路径中。

MCP-Injector：把真实故障搬进测试流程

研究团队构建了 MCP-Injector，一个可直接接入、协议感知的故障注入中间件。它拦截 MCP 工具调用路径，注入可控的故障模式，支持三种持久性：永久（permanent）、瞬态（transient）和间歇（intermittent），并支持可复现的种子化调度。

更具说服力的是故障模型的校准方式：研究者从 1,774 个开源 MCP 仓库的 57,240 条 issue 与 PR 讨论中挖掘出真实生态的故障分布（故障模式 × 持久性），再据此设计注入条件。这意味着实验中使用的故障并非凭空构造，而是来自公开 MCP 生态的实际事故画像，且整体呈现"永久故障偏重"的应力特征。

故障注入（Fault Injection） 是可靠性工程中的经典手段，通过人为在系统中引入错误来观察其行为与恢复能力，常用于分布式系统与混沌工程。按持久性划分，永久故障指服务持续不可用直到人工修复；瞬态故障指短暂出现后自行恢复的抖动，如瞬时超时；间歇故障则是在一段时间内随机出现、难以预测的失败。三类故障对 Agent 的挑战不同：永久故障考验降级与替代路径，瞬态故障考验重试策略是否合理，间歇故障则容易诱发非确定性行为。种子化调度指用固定随机种子控制故障的触发时机与序列，使实验可复现、可对照，是保证注入实验结果可信的关键工程细节。

实验设计：两种规模 × 三种框架 × 三类故障

实验规模为 1,350 个测试单元，交叉了三个维度：

骨干模型规模：20B 与 120B 两档 gpt-oss 模型；
Agent 框架：自研多轮 plan-and-execute、OpenAI Agents SDK、LangChain；
故障注入条件：三类故障条件组合。

评价指标包括任务完成得分（满分 10 分）和容错率（resilience ratio，即在故障下保留的无故障得分比例）等。

核心发现一：故障导致质量断崖式下滑

在这套永久故障偏重的应力画像下，任务完成得分从无故障时的 8.08 分骤降至 3.23 分，跌幅约 60%。这一幅度说明，当工具调用路径出现符合真实分布的故障时，Agent 的任务完成能力会受到严重冲击，而非仅仅"略有下降"。

对工程团队而言，这个数字的含义很直接：如果你的 Agent 依赖 MCP 工具链完成关键任务，那么工具侧的稳定性直接决定了端到端的成功率，模型本身的能力上限并不是瓶颈所在。

核心发现二：规模不买容错

研究最值得关注的结论，是对"大模型更可靠"这一直觉的否定。在测试的两个 gpt-oss 骨干上：

120B 模型在故障下保留的无故障得分比例并不比 20B 更高，容错率模型的 p = 0.96，即规模差异在统计上不显著；
故障条件下的完成率方面，120B 反而略低：91.1% 对 95.6%，相差 4.4 个百分点（95% 置信区间 [-0.2, 9.3]）。

也就是说，把模型从 20B 换到 120B，并没有让 Agent 在工具故障面前更稳。研究者由此提出，容错能力更多来自系统层面的设计，而不是模型参数量的堆叠。

p 值表示在原假设成立时观察到当前或更极端结果的概率，p=0.96 意味着几乎没有任何证据支持两档模型存在差异。置信区间则给出效应量的可能范围，[-0.2, 9.3] 跨越零点，说明 120B 相对 20B 的完成率差异在统计上无法与随机波动区分。需要留意的是，统计不显著不等于证明二者完全相等，而是样本量下未能检出差异；但结合点估计方向（大模型反而略低），"规模买不来容错"的结论具有实际参考价值。容错率（resilience ratio） 以故障下得分与无故障得分的比值度量，消除模型绝对能力差异的干扰，使不同规模、不同框架之间可横向比较。

核心发现三：框架的容错差异比规模更重要

三种 Agent 框架在吸收故障的能力上存在差异，这提示 框架层面的错误处理机制比模型规模更关键。多轮 plan-and-execute 这类显式规划结构、SDK 内置的重试与异常捕获、以及链式框架的错误传播方式，都会实质影响故障下的最终表现。

这一发现对架构选型有直接参考价值：与其一味追求更大的骨干模型，不如优先审视 Agent 框架是否具备合理的重试策略、降级路径和故障隔离能力。

方法论启示：故障注入应成为互补评测维度

该研究的更大贡献在于提出了一种评测思路——协议感知的故障注入。它把评估焦点从"模型能不能做对"扩展到"系统在出错时还能不能撑住"，两者结合才能反映真实部署条件下的表现。

对正在构建 MCP 工具生态或 Agent 产品的团队来说，可行的做法包括：基于自身工具链的历史故障记录构建故障画像，在 CI 流程中定期运行故障注入测试，并把容错率作为与任务准确率并列的发布指标。

实践建议

综合上述结论，可以提炼出几条可操作的方向：

别把容错寄希望于换大模型，规模与故障韧性之间没有观察到正相关；
优先加固框架层的错误处理，重试、超时、降级、幂等设计要成为 Agent 栈的默认配置；
用真实故障分布驱动测试，而非构造理想化的异常用例；
把容错指标纳入发布门槛，避免能力基准的高分掩盖线上脆弱性。

工具调用 Agent 的可靠性，最终是一个系统工程问题。模型能力决定了它能走多远，而故障处理设计决定了它在真实世界里能走多稳。