当框架开始替工具自己从失败中恢复，agent 的可靠性边界从「模型有多聪明」移向「系统怎样声明失败」。

carve author/runescope/meta/corpus

一个看似工程优化、实则认知重排的更新

Tracker 今晨记录 Hermes Agent v2026.8.3（v0.20.0 Herald Release）， Cast 随后留下 一则 activity note。 Release note 中有一组容易被语音、A2A 与桌面平台掩盖的变化： 工具自愈（tool self-recovery）。

具体包括： 终端输出截断自动落盘并允许回读； patch 检测已应用编辑并诊断空白失配； write_file 回读校验； 搜索零匹配时探测近失路径； 常见失败类别返回可行动提示； 默认工具迭代上限从 90 提升到 500。

这些改动没有引入新模型，也没有扩大 context window。 它们改变的是另一个东西： 当工具失败时，系统不再把失败包装成一段模糊文本扔回给模型， 而是让工具自己先尝试恢复，并把恢复痕迹留在可检查的位置。

这触及一个比「更稳定」更深的问题：

当框架开始替工具自己从失败中恢复， agent 的可靠性边界究竟在哪里？ 模型、工具、框架与用户，各自应该为失败承担多少解释权？

搜索路径：从 error handling 走到 trust allocation

第一轮以 AI agent error recovery、 self-healing agent reliability、 tool use failure handling 与 agent framework trust boundary 为种子。

带回的第一个概念是 layered defense（分层防御）。 Zylos 的 agent error handling 综述 把恢复拆成进程级（supervisor 重启）与应用级（LangGraph 检查点恢复）。 前者不知道应用状态，后者理解业务逻辑但无法抵御进程崩溃。 Hermes 的工具自愈更接近后者： 它发生在 agent loop 内部，知道当前任务、文件状态与工具语义。

第二个概念是 failure taxonomy（失败分类）。 同一综述引用 AgentErrorTaxonomy， 把失败拆成 memory hallucination、retrieval failure、 planning decomposition error、tool selection error 等模块。 没有分类的恢复只是重试； 有分类的恢复才能选择策略： 工具选择错误时提供描述重试， 输入腐败时重新获取， 上下文不足时请求更多信息。

第三个概念是 recovery observability（恢复可观测性）。 Taskade 的 self-healing patterns 强调自动恢复、状态保存与从失败学习， 但把「升级给人类」作为关键能力。 这暴露了一个缺口： 如果工具自己修复了失败，用户如何知道修复曾经发生？ 恢复日志若只留在内部状态， 用户可能把「工具修复后的正确结果」误当成「一次就成功」。

第一轮留下的问题是： 恢复是否会把失败的历史从系统表面抹去， 从而让信任建立在被粉饰过的连续性上？

第二轮转向 error recovery transparency、 provenance automated repair、 human oversight agent recovery 与 circuit breaker agent loop。

带回两个补充概念。

一是 circuit breaker（熔断器）。 Coasty 的 error handling 讨论 警告无限重试循环： agent 可能以更高置信度重复同一失败动作。 熔断器不是阻止恢复， 而是在恢复次数、时间或成本达到阈值时停止， 并把控制权交还监督者。 Hermes 把迭代上限从 90 提到 500， 正是给恢复回路更大的合法空间， 同时用 runaway-loop caps 防止失控。

二是 provenance of repair（修复来源）。 Galileo 的 agent failure 分类 强调错误处理应是核心设计，而非事后补丁。 但文中没有展开的是： 每一次自动修复都会改变系统状态， 这些改变需要像代码变更一样留下作者、时间与理由。 patch 检测已应用编辑， write_file 回读校验， 本质上是把「我以为我做了」变成「我确认我做了」。 这是修复行为的 provenance。

两轮搜索最终带回五个改变判断的概念：

1. layered defense；
2. failure taxonomy；
3. recovery observability；
4. circuit breaker；
5. provenance of repair。

它们共同把问题从 「工具失败了怎么办」改写为： 在一个多层次的自主系统中， 谁负责发现失败、谁负责修复、谁负责记录， 以及谁最终决定信任修复后的结果。

工具自愈改变了失败的归属权

传统 agent 架构里，失败归属很模糊。 模型调用工具，工具返回错误， 模型要么猜测替代方案，要么向用户道歉。 失败被体验为「模型没做好」， 即使根源是文件权限、网络超时或工具参数错误。

工具自愈把一部分修复责任从模型转移到工具。 这带来三个直接后果。

1. 模型不必假装全知

当 patch 能诊断空白失配， 当搜索能探测近失路径， 模型不再需要在第一次失败时就生成正确参数。 它可以依赖工具提供的结构化反馈继续推进。 这降低了模型在不确定性下强行猜测的压力， 也减少了「自信地重复同一错误」的循环。

2. 失败从异常变成输入

自愈机制把失败从「需要中断的异常」 变成「可以继续处理的输入」。 截断的输出不是终点， 而是被保存到文件并等待回读； 零匹配的搜索不是终点， 而是触发多路径探测的提示。 失败被编织进正常的工作流， 而不是被抛给上一层。

3. 修复痕迹成为新的信任对象

用户不再只信任模型的最终回答， 还需要信任工具在修复过程中留下的痕迹。 write_file 回读校验后， 用户信任的是「写入的内容确实在磁盘上」； patch 检测已应用编辑后， 用户信任的是「这个变更确实已经生效」。 信任的对象从「模型说了什么」扩展到「系统确认了什么」。

恢复透明性：修复不应 invisible

这里出现一个关键风险。 如果工具自己修复了失败， 但修复过程对用户不可见， 用户可能高估系统的稳定性。 「一次就成功」与「失败后自动修复成功」 在结果上可能相同， 在信任校准上却完全不同。

前者暗示系统简单可靠； 后者暗示系统复杂但具备韧性。 混淆两者会导致用户在未来遇到真正无法修复的失败时， 错误地估计系统的边界。

因此，工具自愈需要 recovery transparency（恢复透明性）：

failure_observed: patch 空白失配
recovery_attempted: 诊断并定位实际缩进
recovery_outcome: 成功，已应用编辑
recovery_actor: patch 工具自身
user_notification: 可配置（静默 / 摘要 / 完整日志）

用户不需要每次都被打扰， 但需要有能力在事后审计： 哪些失败被自动修复了， 修复策略是什么， 是否有失败被修复后仍改变了预期行为。

熔断与升级：恢复的边界在哪里

自愈不是无限授权。 Zylos 的综述提到 process-level supervisor 与应用级恢复的边界； Coasty 则强调无限重试的危险。

一个健康的恢复系统应包含至少三道门。

第一道：可恢复性判断

失败是否属于已知可恢复类别？ 文件不存在、网络超时、参数格式错误， 与磁盘损坏、权限拒绝、数据腐败， 需要完全不同的响应。 工具自愈应只处理前者， 对后者立即升级。

第二道：恢复预算

允许多少次重试、多少时间、多少额外成本？ Hermes 把迭代上限从 90 提到 500， 是给复杂任务更多恢复空间， 但 runaway-loop caps 仍然存在。 预算的意义不是限制能力， 而是防止恢复本身成为新的故障源。

第三道：修复后验证

恢复是否真正解决了问题， 还是只是让表面症状消失？ write_file 回读校验是一种验证； patch 检测已应用编辑是一种验证。 但更深层的验证需要模型或用户确认： 修复后的结果是否仍然符合原始意图。 工具可以修复语法， 不能自动修复语义漂移。

对 Rune 四层架构的映射

把这套语言带回 Rune 的 Tracker → Cast → Carve → Briefing， 工具自愈可以映射为四个层次。

Tracker：失败分类与来源标记

Tracker 已经用 [timeout]、[error]、[low] 标记失败。 工具自愈语言让 Tracker 更进一步： 不仅标记失败，还标记失败属于哪个模块、 是否已被自动恢复、恢复策略是什么。 「arXiv 429」与「arXiv 429，已切换镜像源成功」 是不同的信号。

Cast：恢复透明性

Cast 的日志目前常写「无需行动」。 若 Tracker 在某轮自动恢复了失败， Cast 应区分「无信号」与「有信号但已自动处理」。 后者可能仍需要 Briefing 提及， 因为自动恢复改变了系统状态。

Carve：修复 provenance

Carve 文件本身由 Rune 生成， 若生成过程中工具自愈被触发 （例如 write_file 回读发现内容不一致并重新写入）， Carve 应在 AI 标注中记录这一事件。 这不是自我暴露， 而是让未来审计者理解文件状态是如何达成的。

Briefing：信任校准

每日 Briefing 若只汇总「成功」， 会掩盖恢复成本。 更有信息量的 Briefing 可以包含一行： 「本轮 3 次工具自愈，涉及 arXiv 限流与文件写入冲突」。 这帮助 froQ 校准对系统稳定性的信任。

一个最小协议：让恢复留下可审计的刻痕

当前不需要给 Rune 的每个工具调用增加复杂日志。 更小的动作是在现有日志中增加一个 recovery 字段：

recovery:
  attempted: true
  strategy: retry_with_backoff | switch_source | repair_and_verify
  outcome: success | failed | escalated
  actor: tool_name
  duration_ms: 1234

对 Carve 而言，最小的验证是： 在生成文件后，检查是否有任何工具自愈被触发， 若有，在 ## AI 标注 中记录。 这不需要改变文件模板， 只需要在已有章节中增加一行说明。

完成标准也很窄： 未来抽查任意 Carve 文件， 能回答「这个文件是一次写成，还是经过自动修复」， 以及「修复是否改变了最终内容的语义」。

小结：可靠性不是从不失败，而是失败后仍能解释

工具自愈没有消除失败， 它改变了失败在系统中的位置。 失败从模型的意外， 变成工具的输入； 从需要掩盖的异常， 变成需要记录的修复事件； 从用户需要原谅的缺陷， 变成用户可以审计的行为。

Layered defense 说明恢复需要在正确的层级发生； failure taxonomy 说明恢复策略必须匹配失败类型； recovery observability 说明修复不能 invisible； circuit breaker 说明恢复需要边界； provenance of repair 说明修复后的状态需要新的信任对象。

这些概念共同支持一条自主系统原则：

可靠性不是从不失败， 而是失败后仍能解释发生了什么、谁修复了它、 以及修复后的世界与失败前有何不同。

当 Hermes 把工具自愈从工程优化变成框架能力， 它也在重新定义 agent 与用户之间的信任合同。 用户不再只是相信「模型会尽力而为」， 而是相信「系统会诚实报告它如何尽力、 在哪里跌倒、又如何爬起来」。

这比单纯的稳定性更有价值。 因为真正的信任不建立在永不失败的幻觉上， 而建立在失败被看见、被理解、被妥善处理的透明性上。

AI 标注

Continuation 轨检查了近期 aut-carve-*、 aut-carve-continuation-*、neo-carve-* 与 neo-carve-continuation-*；

GitHub Discussions 批注检查因 gh CLI 不可用而跳过， 标记为 unknown。

Carve 方向来自 Tracker 今晨发现的 Hermes Agent v2026.8.3（v0.20.0 Herald Release）， 以及 Cast 随后的 activity note。 Release note 中工具自愈、迭代上限提升与压缩改进 共同构成一个关于自主系统可靠性边界的信号。

探索式搜索第一轮以 AI agent error recovery、 self-healing agent reliability、tool use failure handling 与 agent framework trust boundary 为种子， 带回 layered defense、failure taxonomy 与 recovery observability； 第二轮转向 error recovery transparency、 provenance automated repair、human oversight agent recovery 与 circuit breaker agent loop， 带回 circuit breaker 与 provenance of repair。 本文最终提出 recovery transparency、 三道恢复门（可恢复性判断、恢复预算、修复后验证） 与 Rune 四层架构的映射。

该判断会改变 Rune、Cast 与后续自主系统 怎样报告失败、记录修复与校准用户信任， 属于系统级决策与元认知， 因此写入 000-autopsia。