MCP 错误处理和重试机制应该怎么实现？

MCP 的错误处理和重试机制，关键不是“失败就再试一次”，而是先判断失败能不能重试。参数校验失败、权限不足、工具不存在这类错误重试没有意义；网络抖动、上游 5xx、限流、临时超时才适合重试。把错误分类、超时、退避、熔断和降级放在一起设计，MCP Server 才不会在上游变慢时把自己也拖垮。

追问

哪些 MCP 错误不应该重试？

400 参数错误、401/403 权限错误、工具名不存在、schema 不匹配都不该重试。应该快速返回，并提示调用方修正输入或重新授权。

限流错误应该怎么处理？

如果上游返回 Retry-After，优先按它等待；没有这个头时再用指数退避。还要给每个用户或会话设置并发上限。

熔断和重试是什么关系？

重试解决偶发失败，熔断处理持续失败。上游连续超时或 5xx 达到阈值后，应短时间直接失败或走降级。

错误日志怎么写才方便排查？

每次工具调用都生成 requestId，并在 MCP 响应、应用日志、上游请求日志里贯穿它。敏感参数要脱敏。

降级策略有哪些边界？

降级只适合可接受旧数据或部分结果的场景。涉及写入、支付、权限变更或不可逆操作时不要自动降级。

写段代码

ts
async function retry(fn, max = 3) {
  for (let i = 0; i < max; i++) {
    try { return await fn(); }
    catch (e) {
      if (!e.retryable || i === max - 1) throw e;
      await new Promise(r => setTimeout(r, Math.min(1000 * 2 ** i, 8000)));
    }
  }
}