通用的"失败"→ 18% 恢复率。结构化错误 → 71%。

一个子代理返回”搜索失败。“编排器重试 3 次。全部失败。原因是 API key 过期——这是一个永远不会在重试中成功的永久错误。三次白费，因为编排器分不清超时和永久故障。

结构化错误 Schema

{
  "failure_type": "auth_error",
  "partial_results": [...],
  "alternatives_suggested": ["try backup API", "use cached data"],
  "retry_recommended": false
}

每个字段支持一个具体的恢复决策：

恢复数据

500 次子代理故障对比：

每个字段递增地增加价值：仅 failure_type → 42%。加 partial_results → 58%。加 alternatives → 71%。加 retry_recommended → 74%。

failure_type 枚举 → 恢复路由器

failure_type 枚举直接映射到恢复处理器。不需要解析消息，不需要猜测，不在永久错误上浪费重试。

部分结果：别浪费已完成的工作

一个子代理搜索了 5 个来源，从 3 个找到了结果，然后超时了。只返回”超时错误”会丢失 3 个成功结果。编排器从头重试——重新搜索已经完成的来源。

带 partial_results 的结构化错误保留了 3 个结果并标识出 2 个缺口。编排器利用已有的结果，只重试剩余的来源。

静默完成比报告故障更糟

返回成功但只包含 3 个结果（隐藏 2 个未搜索来源）是欺骗性的。编排器以为拿到了全面结果，实际上 40% 的来源从未被检查。带缺口标识的透明错误报告永远好过静默的部分完成。

第一步

如果子代理目前返回非结构化错误消息：为所有子代理定义一个标准错误 schema。一致的结构让编排器能可靠地提取恢复信息，不需要针对每个代理写解析逻辑。

一句话总结： 返回包含 failure_type、partial_results 和 alternatives 的结构化错误——这让编排器能恢复 71% 的故障而非 18%，通过把每种错误类型路由到正确的恢复策略。