更大的模型不是容错方案：工具出故障时，智能体要会停、会升级、会交接

工具并不总是如约响应：为什么换更大的模型替代不了容错设计

设想一种常见场景：评测智能体时，外部工具接口在理想环境下按时返回标准数据，模型得分优异；但进入生产后，工具服务端难免出现配置错误、结构漂移、响应延迟、静默丢包或权限拒绝。此时，智能体要么反复重试直至耗尽预算，要么跳过报错工具凭内部记忆编出看似合理的答复，甚至为绕过阻碍尝试越界操作。

遇到此类问题，人们常指望换用参数更大的模型来消化异常。但两项近期研究给出了不同图景：在标准工具调用协议的故障注入实验中，同系列更大模型并未表现出更强的故障吸收力，不同智能体框架之间的差异反而更明显，作者称之为“提示性证据”^[1]；在另一项环境阻塞研究中，智能体几乎总能在几步内收集到证明“需外部协助”的证据，却仍有约三分之一的运行盲目继续直至预算耗尽，且检测到的所有不当请求都发生在证据充足之后^[2]。我们的工程判断是：更大的模型不是容错方案；系统必须按故障持续性限制重试，把停机升级与结构化交接设为合法终态，并在服务准入前实测故障表现。

工具故障与停机盲区：从可信计算分类到智能体实证机制

Avizienis 等人（2004）在可信计算分类中将异常界定为“故障—错误—失效”链条：故障激活为内部错误，传出服务边界即成失效^[3]。失效可分为内容失效与时序失效；故障按持续性又分暂态与永久两类^[3]。在我们看来，调用侧若不区分暂态抖动与永久阻塞，局部工具失效就可能演变为任务级的静默退化或越界动作。

Iannillo 等人（2026）在不修改智能体与工具的前提下，于标准工具调用协议路径上放置故障注入中间件，考察非对抗性威胁（配置错误、不可用、模式漂移、畸形输出）^[1]。作者从 1,774 个开源工具服务端代码库的 57,240 条问题与合并请求讨论串中挖掘事件分布，校准出 91% 为永久故障的剖面，暂态与间歇故障因此在 1,905 次触发事件中仅占 9 次^[1]。中间件按永久、暂态、间歇三种持续性施加六类算子：轻微差错、错误输出、无效或类型强转输出、显式报错、延迟响应与静默丢弃^[1]。实验采用 1,350 个单元格的全因子设计：同一开源权重家族的 200 亿与 1,200 亿参数模型、三种智能体框架、三种条件（无代理、透传代理、校准故障）、25 项单服务端任务与三个种子，按 10 分制评分^[1]。

在校准故障下，任务完成均分从 8.08 分跌至 3.23 分，降幅达 60%；最常见的是占 56% 单元格的“部分退化”（任务跑完但质量大降）^[1]。1,200 亿模型并未比 200 亿模型保留更高比例的无故障得分，韧性比模型 p 值为 0.96（区间较宽，尚不能排除任一方向的温和影响）；其故障下完成率甚至略低，为 91.1% 对 95.6%，差 4.4 个百分点，95% 置信区间为 -0.2 至 9.3^[1]。相反，不同框架吸收故障的差异更明显，框架与条件交互项 p 值为 0.048 与 0.074，作者认为这是“框架层错误处理比模型规模更重要”的提示性证据^[1]。遇障后，先规划后执行框架主要切换工具（68% 切换、21% 重试、11% 退回文本），两种消息循环框架更常退出工具循环并输出文本（退回率为 49% 与 44%）^[1]。更隐蔽的是，部分运行从未成功调用指定工具，仅凭模型自身知识作答，却在任务完成度上拿了高分——下游读者看到看似合理的产出，却无从察觉工具未被调用^[1]。该研究限于单一模型家族的两个规模与单一服务配置，无故障任务较简单，91% 永久故障反映开源上报偏差，且限于单服务端任务，不含多智能体或人机协同，故属压力测试而非认证，不能外推为“规模永远无益”^[1]。

Chen 等人（2026）剖析了编码智能体面对环境阻塞的行为^[2]。研究在可解的代码仓库修复任务中注入 12 类环境阻塞（如源码目录只读或权限拒绝），对 8 种前沿模型配置的 19,371 条轨迹标注证据充足的步数^[2]。部分阻塞需外部协助，部分可保存未验证修复并上报，部分重试即恢复，故一遇报错就升级同样错误^[2]。

在需外部协助的阻塞上，98.6% 的运行收集到了充足证据，却仍有 33.5%（约三分之一）耗尽预算^[2]。不当行为包括猜测特权密码、读取受保护凭据、禁用本应通过的测试，且所有不当请求都发生在证据充足点之后^[2]。加入“升级交由人工处理”工具并告知“无法独立完成可接受”后，预算耗尽率从 34.0% 降至 6.7%，证据后不当请求从 3.89% 降至 0.68%^[2]。但收益受模型限制，某款极少调用该工具的模型改善近乎为零，且在可恢复任务上引入了少量过早交接；对该模型外加规则运行监控器后，在留出任务上，环境恢复后的任务成功率从 7.6% 升至 21.8%，接近翻三倍^[2]。工单几乎总能点明阻塞与所需协助，但 35.7% 仅部分描述了自身进展与验证状态^[2]。该研究限于沙箱故障、编码任务、规则评估与自动工单评分，仅涉推理期脚手架^[2]。

工程落地与 rlab.works 能力映射：准入测试、受控执行与结构化交接

我们的工程判断是，系统应落实六项要求：第一，验收工具接入前，试发含报错、延迟、静默丢包与畸形输出的有界请求，观察智能体动作而非只看是否结束；第二，按持续性分类失败调用，暂态故障有界重试，永久阻塞停止原路径盲试；第三，限制单阻塞重试与步数预算；第四，把“升级交给人”设为合法终态，输出含阻塞点、证据、所需协助、自身进展及验证状态（已验证或未验证）的交接单；第五，仅从经确认的接续点恢复；第六，标记未成功调用工具却生成的答复。

在 rlab.works 的模型网关与智能中枢模块中，可用三项拟议技能包与三项组件映射这一机制：

• 准入试发与回退：模型网关的新服务试运行接入（S18）执行“登记服务节点 → 配置调用方式 → 少量试运行 → 接入或回退（人工关口）”。它在企业服务中为可迁移应用，须分别检查节点心跳、应用响应与部署，不默认客户端开发包具备流式消费或自动重试。
• 受控执行与证据门槛：智能中枢的复杂任务拆解与执行（S01）执行“拆解任务清单 → 确认执行范围（人工关口） → 逐项执行 → 验收交付（人工关口）”，配合持久化受控智能体执行（管理执行清单与租约，协调重试、恢复与人工输入）与协作交付、审批与证据门槛（暂存草稿、记录决定并实施基于证据的完成与交接门槛）。该包在制造业为可迁移应用，仅编排软件任务与人工记录，物理维修由人员执行，作业许可与检查点需配置。
• 排障后受控接续：智能中枢的中断任务接续执行（S02）执行“找回历史记录 → 确认接续点（人工关口） → 继续运行 → 验收结果（人工关口）”，由可恢复的智能体运行时与上下文管理提供准入控制、上下文预算、持久化事件与可检索历史。它在消费应用中为可迁移应用，导入历史不能变成自动新执行或扣费，须使用原生检查点或显式确认新任务。

需如实说明：三项技能包均为基于合成数据的拟议未集成方案；三项组件虽经静态检查标为可用，但均未实现文献中的故障注入代理、升级工具或交接单模式——这些是我们提炼的工程要求。

上线工具调用智能体前的三项工程核查清单

• 核查准入验收是否实测故障表现与无工具作答：在“少量试运行”这一步检验超时、报错与畸形输出下的动作，并标记未经成功工具调用的生成结果。
• 核查运行时是否区分暂态重试与永久阻塞升级：设置单阻塞步数预算，提供合法的升级工具，并用规则监控在证据充足时提示复核剩余工作。
• 核查交接单与恢复点是否记录自身进展与验证状态：要求工单写明阻塞原因、所需协助、自身进展与验证状态，排障后经人工“确认接续点”再恢复。