一个被低估的失败模式

本周两则动态值得放在一起看。
其一，一份新公开的 Agent 评测基准 ScrambleToolBench 给出了一个反直觉的结果：在工具说明被移除、环境规则中途变更的条件下，即便上下文中存在正确的工具映射记录，当前头部的模型 Agent 仍会反复调用已失效的旧工具，陷入无效重试循环。
其二，智能体互联的两个开放协议在同一周归入同一中立基金会治理，国内也出现了面向跨端互联的新协议提案。Agent 之间的接口标准化正在加速。
这两件事指向同一个工程事实：Agent 系统的可靠性瓶颈，正在从"模型够不够聪明"转移到"工具契约是否稳定"。而业界目前的普遍做法，仍把工具接口当作构建期的静态绑定——这是本文要讨论的核心问题。

一、问题定义：契约漂移（Contract Drift）

在典型的 Agent 架构中，工具以 schema 描述（名称、参数、返回结构）注入模型上下文，模型依据描述决定调用。这一机制隐含了三个假设：
接口是稳定的：工具名、参数结构在运行期内不变；
语义是稳定的：同名工具的行为不会随版本升级而改变；
失败是可识别的：调用失败时返回结构化错误，而非静默降级。
真实生产环境三条都不成立。接口会改版、权限会调整、服务会限流、返回格式会悄悄增加字段。模型面对的实质上是一个持续漂移的契约，而它的决策依据仍是注册那一刻的快照。
ScrambleToolBench 暴露的正是这一断层：模型并非"不知道"工具变了，而是缺乏机制把运行时的失败证据转化为对工具契约的更新——错误被当作偶发的执行失败（值得重试），而非契约失效的信号（应当放弃该路径）。

二、为什么"重试"是最危险的默认策略

多数 Agent 框架对工具调用失败的默认处理是重试。在契约漂移场景下，重试会造成三重损耗：
成本放大：每次无效调用都伴随一轮模型推理，在按 token 计费的链路中直接累积成本；
上下文污染：失败堆栈被反复注入上下文，挤占有效信息窗口，干扰后续推理；
状态风险：若失效工具是写操作，盲目重试可能产生非幂等副作用。
根因在于：框架层把"工具不可用"建模为瞬态故障，而契约漂移是持续性故障。两者的处置策略完全相反——前者重试，后者断路。

三、设计模式：把工具契约提升为运行时一等公民

对应的架构改造可以归纳为四个机制。
3.1 能力协商（Capability Negotiation）

工具注册不再是部署期的一次性动作，而是运行期的握手过程。Agent 在会话建立时主动拉取工具的当前能力描述与版本号，而非使用打包进提示词的静态快照：

session.bootstrap:
for tool in registry:
manifest = tool.fetch_manifest() # 运行时拉取
assert manifest.schema_version in SUPPORTED_VERSIONS
context.bind(tool.name, manifest) # 绑定当前契约
3.2 健康探测与断路（Health Probe & Circuit Breaker）

借鉴微服务治理的成熟实践，为每个工具维护滑动窗口内的失败率统计。连续 N 次结构性失败（超时、schema 校验错误、权限拒绝）触发断路，将该工具从可调用列表中摘除，并触发契约重新协商：

on_tool_error(tool, err):
window[tool].record(err)
if window[tool].structural_failure_rate > THRESHOLD:
breaker.open(tool) # 断路
registry.refresh_manifest(tool) # 重新协商契约
planner.notify_unavailable(tool) # 告知规划器，而非重试
关键区分点在于失败分类：网络超时归为瞬态（可重试），schema 不匹配与 404/410 归为契约失效（必须断路并上报规划层）。
3.3 降级链（Fallback Chain）

每个能力域维护有序的工具降级链：主工具断路后，规划器按预设优先级切换到替代实现，直至退化到"请求人工介入"或"明确告知无法完成"。降级链的意义在于把失败显性化——系统以可控方式降级，而不是在单一失效路径上空转。
3.4 影子校验（Shadow Validation）

对高风险工具，在真实执行前先做 dry-run 校验：以验证模式调用接口，确认参数被接受、返回结构符合预期，再执行真实操作。代价是一次额外调用，收益是把契约失配拦截在副作用发生之前。
四、架构示意

┌─────────────┐ 能力协商/版本拉取 ┌──────────────────┐
│ Planner │ ◄───────────────── │ Tool Registry │
│ (模型侧规划) │ │ (动态契约中心) │
└──────┬──────┘ └────────▲─────────┘
│ 调用请求 │ 契约失效上报
▼ │
┌─────────────┐ 断路/降级决策 ┌────────┴─────────┐
│ Dispatcher │ ◄──────────────── │ Circuit Breaker │
└──────┬──────┘ │ + Health Window │
│ 实际执行 └──────────────────┘
▼
┌─────────────┐
│ Tool APIs │ ──► 失败分类：瞬态(重试) / 契约失效(断路+重协商)
└─────────────┘

五、对端云协同场景的特别意义

上述问题在端侧 Agent + 云端工具的架构中被进一步放大：端侧设备的模型上下文与算力有限，每次无效调用都消耗宝贵的推理预算与网络往返；云端接口的迭代节奏又远快于端侧固件的更新节奏，契约漂移几乎必然发生。
因此端云协同系统尤其需要：端侧只缓存契约摘要，执行前做轻量校验；云端集中维护契约版本与降级策略。这也解释了为什么互联协议的标准化与容错机制必须同步推进——协议解决"如何描述契约"，容错机制解决"契约漂移时怎么办"，两者缺一不可。
结语

ScrambleToolBench 类基准的价值，不在于证明模型"不够聪明"，而在于标定了 Agent 工程化的下一处短板：把工具接口当作静态配置的系统，必然在动态环境中失效。能力协商、失败分类、断路降级、影子校验——这些模式在微服务领域早已成熟，Agent 架构需要做的，是把它们从基础设施层上移到模型可感知的规划层，让"工具不可用"成为规划输入，而非异常堆栈。
可靠性竞争的下半场，比的不是谁的模型更强，而是谁的系统在契约漂移时退化得更优雅。