Claude 无法响应：分清平台故障与账号问题，做好多模型兜底
订阅 Claude 后频繁遇到无法响应、retrying 报错，很多人第一反应是账号被封或网络有问题。这篇按「平台侧 / 账号侧 / 本地侧」三层拆解排查顺序，说明状态页、错误信息该怎么看，SLA 在个人订阅里意味着什么，并给出用模型网关做兜底、长任务断点续跑的具体做法，以及故障期间不值得做的那几件事。
付费订阅的 AI 编程工具一旦变成日常主力，稳定性问题就会从「体验瑕疵」升级成「工作流中断」。典型场景是：写代码写到一半，消息发出去却回不来，界面提示 Your message was sent, but Claude couldn't respond — try again；换节点、换网络、重启客户端都没用；过一会儿状态页更新为已实施修复、正在监控。更让人焦虑的是，你无法第一时间判断这到底是平台挂了、账号被限了，还是自己网络出了问题。
这类讨论里通常混着三种情绪：想退款止损的、想找备用方案的、以及认为「谁家都会故障，不值得上纲上线」的。情绪之外，真正有用的是把问题拆开看——故障出在哪一层、能做什么兜底、哪些操作纯属浪费。
先分清故障出在哪一层
AI 服务不可用，表面上都是「没反应」，但成因分三类，处理方式完全不同。
| 层级 | 典型表现 | 判断方法 |
|---|---|---|
| 平台侧 | 多个地区节点同时失败，错误文案高度一致，状态页出现 incident | 换网络、换设备仍复现；官方状态页有对应时间窗 |
| 账号侧 | 只有你不行，别人正常；出现限流、额度、支付或组织权限相关提示 | 换一个账号对比；查看用量与账单页面 |
| 本地侧 | 换设备或换网络后恢复；代理、DNS、客户端缓存相关 | 直连与代理分别试；清缓存、重装客户端 |
从实际反馈看，绝大多数「突然全部不可用」属于平台侧：不同地区的节点同样失败，说明不是出口 IP 的问题；错误提示统一为服务端未能返回，说明请求已经到达，只是后端没算出来。这种情况下继续折腾本地环境意义不大。
反之，如果只有你一个人的请求持续失败，且伴随用量、支付或权限相关字样，那就要去账号侧找原因，而不是等平台恢复。
报错之后的处理顺序
按下面的顺序走，能省掉大部分无效操作。
- 先看官方状态页，确认当前是否有进行中的 incident，以及开始时间、影响范围、是否已进入监控阶段。这一步能把 90% 的猜测直接排除。
- 换一条独立链路验证：用手机热点开一个最短的新会话，发一句「你好」。如果新会话也失败，基本可判定平台侧；如果新会话正常而旧会话报错，考虑上下文过长或该会话状态异常。
- 看错误类型而不是错误文案：重试耗尽（类似
retrying 15/15后仍失败）通常意味着服务端持续 5xx 或超时；如果是 429 或额度类提示，则是限流。两者处理方式不同。 - 不要在原会话里反复重发。长对话重发的代价是双倍的：消耗额度，还会把失败尝试堆进上下文，恢复后模型更容易答偏。
- 记录时间点。如果你在用 API 或自动化任务，把失败的时间戳、请求 ID、返回码留下来，这对后续判断是自己代码的重试逻辑有问题，还是服务端故障，很重要。
自动化任务要区分「重试」和「重跑」
脚本或 Agent 里如果只写了固定次数的重试，遇到长时间故障就会整批失败。更稳的写法是把任务拆成可恢复的步骤：每一步的中间结果落盘，失败时记录断点，恢复后从断点继续，而不是从头再跑一遍。这一点在长时间运行的批处理任务里尤其关键。
「一个 9」的 SLA 到底意味着什么
讨论里提到服务等级只有一个 9，这不是情绪化表达，可以算一下：99% 的可用性，按 30 天计，每月允许约 7 小时不可用；99.9% 则约为 43 分钟。差一个数量级，感受完全不同。
需要提醒的是：面向个人的订阅套餐，通常在服务条款里并不承诺可用于生产的企业级 SLA，故障补偿也以官方条款为准，不存在「按未使用天数自动折算退款」的通用规则。真正带合同级 SLA 和赔付条款的，一般是企业协议或经由云厂商渠道购买的服务。具体条款请以官方最新说明为准，不要依据社区传言做决策。
这也解释了一个常见的分歧：有人觉得「工具而已，不好用就退订」，有人觉得「按月付费还这种稳定性无法接受」。两种立场其实对应不同的使用强度——把 AI 当偶尔用的助手，和把它当成流水线的一环，对可用性的要求本来就不一样。
降低单点依赖的可操作做法
与其在故障发生时决定要不要退订，不如提前把「供应商不可用」当成一个必然会发生的事件来设计工作流。
1. 在模型之上加一层抽象
不要让编辑器、Agent 或脚本直接绑定某一家 SDK。用兼容 OpenAI 协议的统一网关（例如开源的 litellm）做路由，配置主模型和备用模型：
model_list:
- model_name: primary
litellm_params:
model: anthropic/<你的模型 ID>
api_key: os.environ/ANTHROPIC_API_KEY
- model_name: backup
litellm_params:
model: openai/<你的模型 ID>
api_key: os.environ/OPENAI_API_KEY
router_settings:
fallbacks: [{"primary": ["backup"]}]
大多数 CLI 工具和插件支持通过环境变量指定 base_url 与 api_key 指向自建网关，具体变量名请查阅对应工具的官方文档，不同版本可能不同。
需要注意取舍：不同厂商的模型在长上下文、工具调用、代码风格上差异明显，fallback 只适合兜底，不要指望表现等价。备用模型更适合承担「不阻塞流程」的任务，关键产出仍建议回到主模型复核。
2. 把长任务做成可续跑
- 让每一步产出中间文件，而不是全部堆在上下文里；
- 提示词里明确写「从上次中断处继续，不要重复已完成部分」；
- 批处理任务分批提交，单批失败不影响其他批次。
3. 让执行环境本身不成为变量
如果用 Claude Code 这类工具跑长时间任务，中断往往不是因为模型挂了，而是本地机器休眠、断网、代理抖动导致连接断开。把执行环境放到一台长期在线、网络出口稳定的机器上（例如托管在机房、按月租用的远程 Mac），可以把这个变量单独隔离掉：任务在远端持续跑，本地只负责查看结果，本地网络波动不会打断会话。这不是必需项，但如果你的痛点主要是「跑到一半断了」，值得考虑。
4. 保留一条最低成本的备用通道
不一定要同时订阅多家。保留一个 API 账户或一个免费额度通道，用于故障期间验证「是不是只有我这儿不行」，成本很低，信息量很大。
故障期间不建议做的几件事
- 不要在长会话里连续刷「continue」。既消耗额度，也会让上下文充满无效往返。
- 不要因为一次故障就冲动重置或更换账号。账号买卖、共享、代充这类做法本身违反服务条款，出问题后没有申诉空间，风险远大于收益。
- 不要相信「故障后额度会重置，赶紧猛跑」这类说法。补偿政策以官方公告为准，按传言安排大批量任务，容易在额度上吃亏。
- 不要把所有自动化都挂在一个没有超时和熔断的脚本上。没有上限的重试会在故障期间放大请求量，也让你更难判断真实错误。
顺带回答：continue 和 go on 有区别吗
语义上几乎没有差别，模型对两者的理解都接近「接着说」。真正影响续写质量的是上下文里有没有明确进度信息。比换个词更有效的做法是给出具体指令，例如「继续实现剩下两个函数，已完成的部分不要重复输出」。这一点建议自己在实际任务里对比验证，不同模型和不同上下文下的表现并不一致。
小结
遇到服务不可用，先花两分钟确认是不是平台侧问题，能省掉大量无效排查；确认之后，与其反复重试，不如把精力放在两件事上——把长任务改成可断点续跑的形态，以及在工具链里留一条备用通道。订阅制 AI 工具的稳定性短期内不会变成「永不断线」，把它当作会定期抖动的基础设施来设计工作流，比在每次故障时决定要不要退订更划算。涉及具体套餐条款、补偿政策与接口参数的部分，请以官方最新文档为准。
