多智能体错误传播

这里有两条容易混淆的轴需要先分开：

• 一条是HTTP层面的真错误——429 rate_limit_error、500 api_error、529 overloaded_error、连接错误、400 invalid_request_error、401 authentication_error等，这些在SDK里表现为异常，需要区分"瞬时故障、值得重试"和"请求/凭证本身有问题、重试无意义"两类；

• 另一条是Claude返回的stop_reason——它是HTTP 200的成功完成状态，包括end_turn、tool_use、refusal、pause_turn、model_context_window_exceeded等，每一种都有自己该走的处理路径，不是"出错了就重试"那么简单。

考点的第二层，是多智能体架构里子智能体到coordinator（协调者）之间的错误传播设计。

当一个子智能体（比如负责网页检索的subagent）遇到超时或工具调用失败时，它应该如何把这个失败"告诉"上游？一个常见反模式是子智能体自己在内部兜底，把失败伪装成一个"成功但空"的结果往上传，结果是拥有全局视野、本该做恢复决策的coordinator完全看不到问题发生过，下游的synthesis agent也无法区分这是"合法的空结果"还是"被掩盖的失败"，最终产出的报告悄悄缺了一块内容却没有任何异常信号。

真正稳妥的做法，是把失败连同足够的上下文（失败类型、原始尝试的参数、已拿到的部分结果、可能的替代方案）结构化地一起往上传，把恢复决策权留给有全局视角的一层，而不是让每个子智能体各自决定"要不要装作没事发生"。

出题角度大致从三层设卡：

• 一是SDK重试语义，考你能否分清429/500/529这类瞬时故障（自动指数退避重试、遵守retry-after）和400/401这类客户端永久性错误（重试无意义）的边界；

• 二是stop_reason与处理策略的配对，考你是否会把refusal、pause_turn、model_context_window_exceeded这些"成功但特殊"的结束状态，误当成需要退避重试的系统故障来处理；

• 三是给一个具体的多智能体场景（如research coordinator调度web search subagent），让你判断怎样的错误传播设计才算"给了coordinator做智能恢复决策的信息"，并识别"把失败伪装成success"这种最隐蔽也最常考的反模式。