AIREITER如果 Claude 处于 “almost done thinking” 状态，而你在想是不是哪里出问题了——其实并没有。这个状态表示 Claude 正在进行 extended thinking（其推理模式）：它在开始写作之前先规划答案。持续几秒，甚至 20–30 秒，都是正常的。不正常的是等上几分钟却没有任何返回。这是两个不同的问题，本指南会将它们区分开来，并分别提供修复方法。
“几乎完成思考”实际上是什么意思
“差不多想好了”是 Claude 在运行其扩展推理过程时显示的标签。模型不会立即逐个 token 地回复，而是会花费一部分“思考” token 预算来制定计划，然后再生成可见的答案。这与 Claude Code 中的“以高强度思考”以及 Claude 应用中的推理指示器所使用的是同一种机制。
最清晰的理解方式是：这个短语是一个进度信号，而不是一个错误。正如一条r/ClaudeCode 讨论串所说，延长推理的暂停是“Claude 在执行前进行规划，而不是服务器问题”。所以当你看到 claude almost done thinking 时，模型正在工作——唯一的问题是它是否工作了太久。
一个粗略的界线：
几秒到约 30 秒的思考时间 → 属于正常，尤其是在处理复杂推理或编码任务时。
数分钟都没有输出，并且反复发生 → 说明有问题；请直接查看下面的修复方法。
为什么它耗时这么久（或完全卡住）
缓慢和真正的卡死有不同的原因。导致变慢的有三件事：
扩展思考深度。在快速查找中，Claude 可能会倾向于投入比任务所需更多的推理精力——它会对一个其实不需要太多思考的问题“深思熟虑”。
顺序工具调用。在代理式使用（Claude Code）中，大部分实际耗时并不是模型推理——而是工具调用。对 Claude Code 延迟的一项拆解测得每次文件读取、搜索或测试运行作为一次同步往返大约需要 300–800ms，并指出这些操作默认不会并行运行——因此，一个触发十几个探索性调用的含糊提示，会在任何真正工作开始之前，把这些往返时间叠加成十多秒。
上下文膨胀。整个对话记录会在每一轮重新发送给模型。随着会话内容增多，响应会变慢，质量也会下降——同一项分析观察到，当会话大约超过上下文窗口的 60% 时，速度会出现明显下降，尽管确切临界点会有所不同（这就是对对话中深埋细节“丢在中间”的效应）。
真正卡住是一个单独的故障。一个已跟踪的 Claude Code 问题（#32526）描述了新会话卡在“thinking”上，并且永远不会生成输出——没有错误，甚至对一个简单的“hello”也是如此——而一个先前已打开的会话仍然运行正常。该报告来自一个负载很重的环境：许多 PreToolUse hooks、多个 MCP servers、80+ 已注册 skills，以及一个自定义（Bedrock）provider。如果你的会话从不返回任何一个 token，请把它视为卡住，而不是变慢。
如何修复它
快速修复（先试试这些）
/clear用于丢弃对话并重新开始——这是缓解上下文膨胀最快的方法。/compact用于总结并压缩上下文。请注意，它的设计本身就会丢失信息，因此请先将任何重要内容保存到文件中。重新启动会话，或者切换回一个仍在响应的旧会话——这是大多数用户在遇到卡住时采用的变通办法。
控制努力级别
最容易被忽视的速度杠杆是effort。Claude 往往默认使用高/最高推理；将 effort 与任务相匹配，能在常规工作中显著提升速度且不损失质量。实用速查表：
任务 | 工作量 | 原因 |
|---|---|---|
快速查找、摘要、格式化 |
| 无需深度推理；几乎即时 |
标准编码、起草 |
| 平衡 |
架构、疑难调试、数学 |
| 值得等待 |
如果不透明性让你感到困扰（Claude 默认会隐藏思考细节），Claude Code 可以显示一个思考摘要，这样你至少可以看到它在做什么。
当它真的卡住，而不只是变慢时
如果你得到零输出，那是挂起，不是深度：
减少启动负载 — 临时禁用额外的
PreToolUsehooks、未使用的 MCP servers 和 skills，然后重新打开会话。检查你的 provider — 自定义 model IDs 和 gateways（Bedrock 及类似服务）在不少卡住报告中都有出现。
使用
--verbose运行，查看它实际上在做什么：一长串文件读取指向 tool-call 问题；首个响应很慢且没有 tool calls 则指向 latency 或 context。
高级：通过 API 控制思考
应用程序对思考的控制有限。API 直接为你提供这种控制——如果你需要可预测的延迟，这就是实用的解决方案。上面速查表中的相同努力级别也是一个 API 参数，你还可以完全关闭扩展思考：
message = client.messages.create(
model="claude-opus-4-6",
max_tokens=4096,
thinking={"type": "adaptive"}, # Claude 决定思考多少
output_config={"effort": "low"}, # low | medium | high | max — 限制深度
# 或者，要完全跳过扩展思考：
# thinking={"type": "disabled"},
messages=[{"role": "user", "content": "..."}],
)在当前的 Claude 模型（Opus 4.6 及以上）中，你不再设置固定的 token 配额——而是设置一个努力级别（low 表示快速处理，最高到 max），或者直接关闭扩展思考。这与应用程序里隐藏的那个控制项是同一个杠杆，只不过现在作为你可控的参数暴露出来。（请参阅官方扩展思考文档获取当前参考——参数名称可能会在不同的 SDK 版本之间变化，所以请检查你正在使用的版本。）
任何与 Anthropic 兼容的 endpoint 都可以发起这些调用——官方 API，或像 AIReiter 这样的兼容镜像，在那里上面的请求可以原样工作。你使用哪一个并不那么重要，关键在于：thinking 控制位于 API 层，而这些应用并不公开它。
Claude “变差了”吗？
这就是潜伏在大多数“为什么 claude 几乎一直在思考”的搜索背后的问题，而诚实的答案是：通常这不是永久性的。很多被感知到的退化都可追溯到默认行为的变化——比如对思考预算的服务器端调整，或在更新中推出的保守默认值——而不是模型变笨了。社区对此有很多来回讨论，而反复得出的结论都一样：一旦你重新掌控，体验就会恢复——设置努力级别，清理臃肿的会话，并提供结构化提示。如果 Claude 这周感觉变差了，在断定它坏掉之前，先改这三件事。
常见问题
“almost done thinking” 是什么意思？
这意味着 Claude 处于其扩展推理模式，在写出答案之前先制定计划——这是正常的进度状态，不是错误。只有当它一直无法恢复时，才表示存在问题。
为什么 Claude 思考这么久？
三个常见原因：默认努力级别过高、agentic 会话中缓慢的顺序工具调用（每次约 300–800ms），以及过大的上下文窗口。降低努力级别、减少工具调用次数，以及清理上下文都会有所帮助。
Claude 会不会偶尔陷入思考卡住？
是的——这与缓慢不同。新会话可能会卡在“thinking”并且永远不返回输出，通常与繁重的 hook/MCP/skill 配置或自定义提供商有关。请重新启动会话，或返回到一个正常工作的会话。
Claude 没有完成回复——我该怎么办？
将其视为卡住：/clear 或重启，减少启动负载，并检查你的提供商。如果它只是变慢而不是停滞，则降低 effort 级别并缩小上下文。
我可以让 Claude 思考得更快吗？
是。对于常规任务，将 effort 设置为 low/medium，保持会话简短；如需完全控制，可在调用 API 时使用更低的 effort 级别，或禁用 extended thinking。