事件驱动的失败自愈

它解决什么问题

宿主 Agent 把任务丢进后台执行之后，并不代表「发出去就完事」。模型服务 429 限流、网络超时、子代理陷入死循环、工作流节点逻辑异常，都会让任务在无人看管时悄悄死掉。更糟的是反过来：自动重试太激进，把已经成功的媒体生成请求又提交了一遍，或者对付款、删库这类最终动作也「好心」重试一次，造成重复计费和不可逆事故。

本技能是被动响应型的：不主动轮询，只在宿主 Agent 收到后台任务异常信号、或 check_pending_tasks 返回 failed 状态时被调用，再按一套明确的规则决定「重试、补偿、还是直接转人工」。

核心能力与工作步骤

• 错误归因优先：瞬态错误（网络超时、429、503、模型暂时不可用）走全抖动退避，最多 3 次；逻辑错误（死循环、幻觉、输出格式错）最多重试 1 次并附加纠错 prompt；致命错误（400 参数校验、401/403 权限、404 资源不存在）重试 0 次，直接标记不可恢复。
• 事务属性优先：恢复任何任务前先判断动作副作用等级——只读、可逆、可补偿、最终动作。最终动作在任何错误下都不重试；可逆动作重试前先调用撤销 API 清理残局；可补偿动作先触发补偿工作流。这一优先级高于阶段-错误矩阵。
• 幂等与防循环：基于错误类型 + 错误摘要计算语义指纹，与历史错误语义相似度超过 90% 即熔断；同时检查该任务 ID 是否已在当前会话中恢复过。
• 全抖动退避：t_base = 5s、t_max = 60s，每次重试时间在 [0, 当前最大退避时间] 内均匀随机，多任务并发失败时天然打散，不会惊群。
• 按任务类型执行恢复：subagent 用 subagent_reply(threadId, 纠错/续跑指令) 续跑，逻辑错误需附失败日志摘要与纠错 prompt，上下文较长时先提取关键摘要再注入；workflow 调用 workflow(resumeFromRunId=taskId)，平台不支持则通知用户；media 附原始参数重新提交生成请求。

恢复尝试后立即向会话上下文输出结构化摘要，并记录任务 ID、语义指纹、重试次数、事务属性与状态（resumed / human_pending / failed）。

适用边界与注意点

禁止的反模式：对最终动作（付款、部署、删库）自动重试；仅按进度百分比判断是否恢复；语义相似度略低于 90% 就误熔断，会漏掉真实新错误；media 重提交前不清理上次失败产物，造成脏数据与重复计费；静默吞掉致命错误。

信号缺失时的推断：事务属性未提供时，media 默认 可逆，subagent 与 workflow 默认 只读，但 subagent 的 prompt 中出现发送、提交、部署、付款、删除等关键词时升级为最终动作。阶段缺失时按 Processing 处理，推断结果必须在恢复摘要中显式标注。

语义相似度计算：优先用平台 embedding 算余弦相似度；无 embedding 时降级为「错误类型 + 关键词集合 Jaccard 相似度」近似，阈值放宽至 0.8 并标注为 fallback。达到重试上限、致命错误、同类错误重复出现、涉及最终动作、token 累积消耗超阈值时，都会触发升级通知。

已知待完善点：文档标注仍需补充真实平台 check_pending_tasks 的返回格式样例，以提升推断准确率。