CCA-F 练习题库· Context Management & Reliability
在 Claude API 上，哪种 API 错误传播与重试的做法最有利于生产环境的可靠性？
- A永远不要重试任何失败的请求，连 429 rate_limit_error 也不重试；一次失败就意味着会话状态已损坏，唯一安全的恢复方式是关掉 SDK 内置的重试、丢弃该会话并从头开始。
- B立即且不做退避地重试每一个 4xx，包括 400 invalid_request_error 和 401 authentication_error，因为所有错误本质上都是瞬时的，第二次尝试就会恢复。
- C对瞬时失败（429 rate_limit_error、529 overloaded_error 以及 5xx api_error）采用指数退避重试，并遵循
retry-after头；官方 SDK 默认已经这样重试两次。 - D在紧密循环中不做退避地立即重试 529 overloaded_error，并忽略响应携带的任何
retry-after头，好让你比那些在同一端点上礼貌等待的调用方更早抢回容量。
正确答案：C
解析
Anthropic 的错误文档把 429（rate_limit_error）、529（overloaded_error）和 5xx（api_error）归类为可重试的瞬时失败，应当在遵循 retry-after 头的同时用指数退避重试；并把 400（invalid_request_error）和 401（authentication_error）归类为不可重试的客户端错误，重试也不会成功。官方 SDK 正是自动实现了这一行为，默认对瞬时失败重试两次（max_retries=2，可配置）。
- C的每一个分句因此都是准确的。
- B是错的，因为 400/401 是永久性的客户端错误，而不是瞬时错误，立即重试它们只会白白烧掉配额。
- A是错的，因为一次瞬时失败并不会损坏会话状态（Messages API 是无状态的——你把历史重新发送一遍即可），所以丢弃会话毫无必要。
- D是错的，因为在紧密循环中不做退避地重试 529，会放大它所应对的那种过载，并且忽略了 retry-after。除 C 之外，推荐的传播实践还包括：捕获 SDK 的类型化异常类，而不是对错误消息做字符串匹配，以及记录 request_id 以便寻求支持。
延伸阅读
本题为本站自有原创练习题，非任何官方考试内容；解析对照 Anthropic 公开文档撰写， 如与最新文档不符请以官方为准。想在限时环境下检验水平，可参加 模拟考（题目与本页题库不重叠）。