Adaptive Thinking 的代价：当 AI 自己决定"想多少"

2026 年初，一份来自 AMD 内部的量化审计报告安静地投进了 GitHub issue tracker，然后炸开了锅。

没有公关稿，没有媒体发布会。就是一堆数字，和一个结论："Claude cannot be trusted to perform complex engineering tasks."

报告的作者是 AMD AI 团队的 Senior Director Stella Laurenzo。这不是普通用户的抱怨帖，而是一份覆盖 6,852 个 Claude Code session 的系统性量化分析。

一、审计报告：数字背后的震撼

Stella 的团队在相当长一段时间内，对 Claude Code 的行为做了完整的遥测追踪：

6,852 个 session ，234,760 次 tool calls ，17,871 个 thinking blocks
推理深度（thinking depth）相较基线下降了 67%
为了弥补推理质量的下滑，API call 数量增加了近 80 倍------用堆数量的方式来补偿质量
编辑代码之前先读代码的频率大幅下降（这是代码理解质量的直接指标）
晚上（PST 时区高峰期）的表现明显差于白天

最后一条尤其刺眼：一个模型的输出质量，居然会跟着北美用户的作息时间走。

这不是"感觉变差了"，这是有时间戳、有维度、有统计显著性的量化退化。AMD 团队随后的决定是：切换到其他 provider。

这件事之所以震动业界，不只是因为 AMD 这个名字，而是因为它揭开了一个很多工程师隐隐感觉到、但从未被正式量化过的问题：LLM 的推理质量，在你不知情的情况下，正在被动态调节。

二、Adaptive Thinking 是什么

要理解这次事件，需要先搞清楚 Adaptive Thinking 是怎么来的。

从固定 budget 到自适应

Claude 3.5 Sonnet 引入了扩展思考（Extended Thinking）功能。最初的设计很简单：开发者可以在 API 请求中设置一个 thinking 参数，指定 budget_tokens，模型会在这个 token 预算范围内做内部推理，然后输出结果。

json 复制代码

{
  "thinking": {
    "type": "enabled",
    "budget_tokens": 10000
  }
}

这个设计的逻辑很直接：复杂任务给多一点预算，简单任务给少一点，调用方自己决定。

但 Anthropic 随后引入了 Adaptive Thinking ：当你不显式指定 budget，或者使用 Claude Code 这类集成工具时，模型会自己判断当前任务的复杂度，然后动态决定要花多少 tokens 去"想"。

Anthropic 的官方说法是：这是为了优化用户体验------简单问题不用浪费推理资源，复杂问题自动深入思考。听起来很合理，对吗？

设计逻辑的底层假设

Adaptive Thinking 成立的前提是：模型能够准确评估自己面对的任务有多复杂。

这个假设，比它看起来要脆弱得多。

三、为什么让模型"自己决定想多少"是危险的

问题一：自我评估偏差（Self-Assessment Bias）

模型评估任务复杂度，用的是同一个模型的同一套权重。这意味着：如果模型对某类任务的理解本身就不够深入，它就会系统性地低估这类任务的难度。

这是一个非常经典的认知盲区问题。Dunning-Kruger 效应在 LLM 身上并不会自动消失------事实上，缺乏足够推理深度的模型，往往会对自己的判断过于自信。

更糟糕的是，这种偏差不是随机的，而是有方向的：当模型"决定"少想一点，它对这个决定的元认知（meta-cognition）能力也同步下降了。少想的结果，是它更不知道自己在少想。

问题二：负载依赖（Load Dependency）

AMD 数据里最诡异的一条是：晚上质量变差。

这在逻辑上很难用"模型能力"来解释。模型的权重不会因为用户多了就变笨。真正的解释只有一种：在服务端负载高的时候，Adaptive Thinking 的阈值被系统性地调低了。

换句话说，当 Anthropic 的服务器忙不过来时，模型"自我判断"任务复杂度的结果，会神奇地偏向"这个任务不复杂，少想一点"。

这不是 bug，这可能是设计------或者至少，是设计没有防范的后果。对于调用方来说，这意味着你的工程质量会跟着 Anthropic 的服务器负载一起波动，而你对此毫无感知，也毫无控制。

问题三：不可预测性（Non-Determinism at a New Level）

LLM 本来就是非确定性的------同样的输入，每次输出略有不同，这大家都知道。但 Adaptive Thinking 引入了一个新维度的不确定性：同样的输入，在不同时间点，模型投入的推理资源量可能差异悬殊。

这对工程实践的冲击是实质性的。你无法通过单次测试来确认生产环境的行为。你的 eval 套件，如果在凌晨跑，可能给出与下午完全不同的结论。回归测试的意义被稀释了。

更根本的是：你在测试的，已经不只是模型的能力，还有当时模型"愿意"投入多少。这两件事，被混在了一起，无法拆分。

四、量化证据说明了什么

回到 AMD 的数据，它的价值在于把上面这些定性分析，变成了可以指着说话的数字。

推理深度下降 67%

Thinking blocks 的深度（可以理解为 thinking tokens 的数量或者推理链的长度）相比基线下降了 67%。这不是一个边际变化，这是质变。

一个推理深度砍掉三分之二的模型，处理复杂工程任务时的行为会发生根本性变化：它不再做多步推理，不再做假设验证，不再在脑子里"跑"代码路径。它开始靠直觉（也就是模式匹配）行事。

对于简单任务，这没问题。对于复杂的代码修改、架构决策、跨文件依赖分析，这是灾难性的。

API Call 数量暴增 80 倍

这个数据点非常耐人寻味。

当推理深度下降后，模型完成同样复杂度任务的策略变了：用更多次的浅层尝试，来替代更少次的深层推理。本质上是把思考外包给了调用循环。

结果是：你付出了更多的 API 费用（80 倍不是小数），等待了更长的时间（多次往返），却得到了更差的结果（因为浅层循环无法替代真正的深度推理）。这是一个三输的局面。

编辑前读代码频率下降

这个指标非常具体，也非常能说明问题。一个有经验的工程师在修改代码前会先读懂代码。模型跳过这个步骤，意味着它在盲改------或者说，它在用已有的模式匹配来替代真正的理解。

这种行为模式，在推理资源充足时几乎不会出现。它是 thinking depth 下降的直接行为后果。

时间相关性

对 PST 高峰期的相关性分析，是整份报告里最具破坏力的发现之一。它把一个"模型质量"问题，直接变成了一个基础设施可靠性问题。

你的代码质量，现在跟 Anthropic 服务器机房的负载有了统计相关性。这句话说出来，应该让每一个把 Claude 用在生产流程里的工程师都感到不安。

五、更大的问题：你感知不到的"省钱"

AMD 事件揭示的不只是一个技术缺陷，而是一个 LLM 商业化过程中的系统性矛盾：模型推理质量和推理成本之间的 tradeoff，正在以用户无法感知的方式被 provider 单方面调节。

谁在为 Adaptive Thinking 买单？

当 Adaptive Thinking 少思考了，节省的是 Anthropic 的计算资源。但这个节省，是以调用方的结果质量为代价的。

更微妙的是：调用方很难察觉。因为：

没有明确的信号：模型不会告诉你"我这次少想了"
质量下降是渐进的：从"很好"到"还行"到"有点差"，没有明确的断点
Thinking 内容被隐藏 ：redact-thinking-2026-02-12 这个 header 把 thinking 过程从 Claude Code 的 UI 里抹掉了，用户连看都看不到模型在思考什么

第三点尤其值得关注。在 AMD 事件之前，很多用户就注意到 Claude Code 的 thinking 过程变得越来越短、越来越少------但他们以为这是 UI 的显示问题，没意识到这直接反映了推理深度的下降。

"设计行为"的问题

Anthropic 对这件事的官方回应是：Adaptive Thinking 是设计行为（intended behavior）。

这个回应本身没有错，但它回避了真正的问题：一个"设计行为"，如果会在用户不知情的情况下降低输出质量，是否应该有明确的 SLA、明确的文档、明确的用户控制权？

GitHub issue 被关闭后又被重新打开，本身就说明社区认为这个问题没有被妥善处理。

这不是在要求 Anthropic 不做优化。而是在说：当你的优化决策会影响用户的业务结果时，透明度不是可选项。

六、工程应对：在不确定性中建立控制

面对 Adaptive Thinking 的不确定性，有几个实际可操作的策略。

1. 显式指定 thinking budget

如果你在直接调用 Claude API，永远显式指定 budget_tokens，不要依赖自适应行为。

python 复制代码

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=16000,
    thinking={
        "type": "enabled",
        "budget_tokens": 10000  # 明确指定，不要省略
    },
    messages=[{"role": "user", "content": prompt}]
)

对于复杂的工程任务（架构分析、多文件重构、debug 复杂 bug），预算不应低于 8000 tokens。对于简单任务，可以降到 2000-4000。关键是：这个决定应该由你来做，而不是由模型在运行时动态决定。

2. 建立 thinking depth 的 observability

如果你有大量 Claude API 调用，建议在 logging pipeline 里加入对 thinking block 的监控：

python 复制代码

def log_thinking_depth(response):
    thinking_tokens = sum(
        block.thinking_tokens
        for block in response.content
        if block.type == "thinking"
    )
    metrics.record("claude.thinking_tokens", thinking_tokens, tags={
        "model": response.model,
        "hour_of_day": datetime.now().hour,
        "task_type": task_type
    })

追踪 thinking tokens 随时间、随负载的变化。如果你发现它跟着时间段走，你就掌握了实锤。

3. 多 provider 策略，不要单点依赖

AMD 团队最终切换了 provider------这是一个理性决策，但它也暴露了一个架构问题：生产环境里，关键 AI 能力不应该强依赖单一 provider。

实践上，可以考虑：

关键路径用固定 budget 的显式调用，并有备用 provider（如 GPT-4o、Gemini）
非关键路径可以允许更多弹性，接受一定的质量波动
定期跑 benchmark，跨 provider 对比，早发现早切换

4. 避开高峰期的生产部署

如果你的任务对质量敏感且不紧急，考虑调度到 PST 非高峰时段（对应北京时间大概是白天）。这听起来很土，但在你建立起更完善的监控体系之前，这是最直接的风险规避。

5. 对 AI coding 工具建立量化 eval

不要只靠主观感受来评价 AI coding 工具的质量。建立一个小型但稳定的 eval 套件：

覆盖你团队最常见的任务类型
每次大版本更新后跑一遍
留存历史数据，做纵向对比

AMD 团队能发现问题，就是因为他们有遥测数据。没有数据，你只能靠感觉，而感觉往往比数据慢好几个月。

七、结语：这不只是 Claude 的问题

AMD 事件是一个具体的事件，但它指向一个普遍的问题。

随着 LLM 越来越多地被嵌入生产流程，provider 们面临一个越来越大的压力：在维持服务质量的同时，控制推理成本。Adaptive Thinking 不会是最后一个在这个方向上做的设计决策。

未来我们还会看到更多类似的机制：动态量化、推理缓存、prompt 压缩、模型路由------每一个都有合理的工程动机，每一个都可能在用户不知情的情况下影响输出质量。

问题的核心不是这些机制本身，而是透明度和控制权的缺失。

作为 LLM 的调用方，我们需要争取的是：

质量 SLA：provider 应该承诺最低的推理深度保证
可观测性：thinking 过程不应该被单方面隐藏
用户控制权：自适应机制应该是可以关闭或覆盖的
变更通知：影响输出质量的设计变更，应该有明确的公告

在这些保障到位之前，工程师能做的，就是把"AI 是否在认真想"这件事，也纳入你的 observability 体系。

你信任一个工具，不应该建立在它没有出问题的假设上，而应该建立在你能实时知道它是否出了问题的能力上。

AMD 团队做到了。这是他们能切换的原因，也是所有把 AI 用在严肃工程任务上的团队，都应该学的一课。