最近一段时间，不少开发者遇到 Claude 返回 500、工具调用无法解析、长任务跑几十分钟不出结果、输出语言漂移等问题，但也有人完全没受影响。本文把这几类现象分开归因，给出从判断故障归属到拆分长任务、重试策略、语言约束的可操作清单，并说明哪些做法存在账号与合规风险。
现象：几类问题被混在一起说
最近一段时间，关于 Claude 的抱怨明显集中：有人遇到直接返回 500 错误，有人看到工具调用解析失败（提示模型返回的 tool call 无法解析，重试同样失败），也有人遇到不报错但"不干活"的情况——一个复杂问题跑十几分钟甚至几十分钟，只消耗了很少的 token，结果迟迟出不来。还有人提到长任务跑到后面，回复里开始冒出日文、韩文。
与此同时，另一部分用户表示自己用了很久从没遇到，或者只在某天中午、凌晨的短时间窗口里不稳定。这种分歧本身很有信息量：它说明这些现象不是单一原因造成的，把"服务挂了""模型变笨了""我的用法有问题"混为一谈，很难对症。下面把可能的原因拆开看。
常见原因拆解
服务端容量与短时降级
中午和凌晨是反馈最集中的两个时间点，这和容量高峰、批次任务调度的时间特征是吻合的。值得注意的一个细节是：官方状态页显示可用性仍在 99% 以上，但用户实际重试十次仍然失败。这并不矛盾——状态页的统计通常按请求成功率或时间窗口聚合，短时降级、部分模型或部分区域受影响时，页面未必会变红；而个体用户在一次失败任务上的体感，是 0% 和 100% 的区别。
结论：状态页可以用来判断"是不是大范围故障"，但不能用来否定你自己的报错。
长任务与大上下文
上下文越长，每一轮生成越慢，工具调用这种结构化输出的容错空间也越小。一个跑了几十分钟的会话，往往已经积累了大量工具返回结果、文件内容和中间日志，模型在长上下文末端出现注意力分散、格式跑偏、语言漂移，都是常见表现。语言漂移尤其典型：任务越长、上下文里混杂的语言材料越多，越容易在末尾发生输出语言偏移。
工具调用的格式脆弱性
工具调用要求模型输出严格结构化的内容。一旦输出被截断、混入了多余的解释文字，或者链路中途被打断，客户端就会解析失败。更麻烦的是，如果重试时仍然带着同一份已经"脏掉"的长上下文，很可能连续失败，最后表现为重试若干次后彻底放弃。
客户端与网络链路
代理抖动、连接被重置、笔记本合盖休眠导致长连接断开，都会以"重试失败"的形式呈现，看起来和服务端故障几乎一样。这类问题在长任务上尤其容易被误判，因为任务本来就跑得久，中途断一次就前功尽弃。
排查与应对清单
第一步：先判断是服务端还是本地
| 现象 | 更可能的原因 | 先做什么 |
|---|---|---|
| 简单请求（如"回复 ok"）也报 500 | 服务端 | 查官方状态页与公告，等待恢复 |
| 简单请求正常，只有长任务失败 | 上下文或链路 | 拆分任务、新建会话 |
| 报错集中在特定时间段，多人同时反馈 | 服务端短时降级 | 错峰执行，避免连续重试 |
| 换网络（如手机热点）后恢复 | 本地链路 | 检查代理与连接稳定性 |
| 工具调用解析失败且重试无效 | 上下文被污染 | 新建会话重来，而不是原地重试 |
建议顺手记录出现问题的具体时间、所用模型、错误原文。同一波故障里，这些信息能帮你快速确认是不是普遍问题，也方便日后回溯。
第二步：把长任务拆短、让状态落盘
这是最有效、也最不依赖服务端状态的一条。具体做法：
- 先出计划，再执行：让模型先把任务拆成步骤写成文件，确认无误后再逐步执行，而不是一句话丢进去跑四十分钟。
- 强制落盘进度：每完成一个阶段，让它把已完成项、待办项、关键结论写进一个进度文件；中断后从文件续跑，而不是靠对话历史续跑。
- 控制单次输入规模：不要一次把整个仓库或整份日志塞进去，改成按文件、按模块分批喂。
- 设置阶段验收点：每个阶段结束让它输出一句自检结论，你确认后再进入下一阶段。
请按以下流程工作：
1. 先把任务拆成不超过 6 个步骤，写入 plan.md，不要开始执行；
2. 每完成一步，把结果和下一步写入 progress.md；
3. 单步失败时停下来报告错误，不要静默重试；
4. 所有输出使用简体中文。
第三步：重试要有策略
失败后连续点击重试，通常只会放大问题：请求还是同样的上下文，服务端还是同样的负载。更稳妥的顺序是：
- 先停手，确认是不是普遍故障（状态页、社区反馈）；
- 压缩上下文或直接新建会话，再重试一次；
- 工具调用解析失败时，让它改用更简单的路径——先输出纯文本结果，由你手动写入文件，绕开结构化输出的脆弱点；
- 仍然失败就换模型或换时间段，不要在一个不可用的通道上耗时间。
第四步：处理输出语言漂移
语言漂移几乎都发生在长会话末端，靠"提醒一句"往往治不住。更实际的做法是：
- 在项目级配置或系统提示里固定输出语言，而不是只在第一条消息里说；
- 长任务分段，每段开头重申一次语言要求；
- 一旦发现漂移，直接开新一轮会话，把结论摘要带过去，不要在已经被污染的上下文里继续修补。
第五步：准备备用通道
如果任务对时间敏感，准备一条备用路径比事后抱怨有用：订阅制套餐和 API 的容量池、限流策略不同，关键任务可以单独走 API；也可以在其他模型上做交叉验证，判断是"模型能力问题"还是"服务可用性问题"。
另外，如果任务本身要跑很久，而你的本地机器会休眠、会切换网络，那么中断点很可能不在服务端。把长任务放到一台长期在线的机器上运行是可选方案之一，例如整机托管在新加坡机房的独享远程 Mac，按月租用、远程连接使用，能减少本地休眠和网络切换带来的中断。需要说明的是，这类做法只降低客户端侧的不确定性，解决不了服务端的 500 和容量降级。
需要谨慎的做法
遇到不稳定时，容易有人想到共享账号、买卖账号或绕过地区限制。这些做法通常违反服务条款，随时可能被封禁，且账号里往往存着代码、密钥和对话历史，共享意味着这些内容暴露给他人。合规的替代路径是：使用官方支持的地区与计费方式，团队场景走团队版或企业版以获得更明确的配额与支持渠道。
小结
把这波问题归结成"模型变笨了"并不准确。更合理的判断是：短时容量降级造成了集中报错，长上下文和结构化工具调用放大了失败概率，而本地网络与休眠则贡献了一部分看起来一样的故障。
可以立刻执行的三件事：
- 报错时先分清是服务端还是本地，别在原地连续重试；
- 所有长任务改成"计划落盘 + 分阶段执行 + 进度写文件"；
- 语言和输出格式要求写进项目配置，而不是靠每条消息提醒。
状态页的可用性数字和你的实际体验出现落差，是聚合口径造成的，不必因此怀疑自己的判断。具体可用性数据、套餐限流规则和模型列表会随时调整，请以官方最新说明为准。