有分析认为Claude Code的推理退化本质上是算力与成本约束——系统开始限制任务运行时长、推理深度和并发任务数量，当“更快更浅的答案”是算力分配的必然结果时，用户花钱买到的“智能”到底是一个稳定产品还是一个随负载波动的服务？

摘要与核心论点

围绕 Claude Code 的"推理退化"讨论，常见两种叙事：一种归因于模型能力本身的下滑，另一种归因于用户使用方式不当。本文认为这两种归因都绕开了关键变量——推理预算（inference budget）。推理预算指在一次会话或一个任务中，系统愿意为"思考"分配的计算资源总量，它由三部分构成：单次请求可用的最大生成 token 与思考 token 上限、单任务可占用的墙钟时间（wall-clock time）、以及同一时刻可并行服务的会话数。三者共同决定了一个 agent 在给定时刻"能想多深"。

本文的主线是：推理退化不是模型退化，而是预算约束下的策略性降级。当服务方在高峰期收紧预算，agent 的规划步数、工具调用轮次、自我校验次数会同步收缩，表现为"看起来变笨"。这一判断可由公开的 API 限流文档、推理模型的技术报告、以及 agent 评测基准的行为数据交叉验证。本文进一步提出"服务等级"（service tier）替代"产品承诺"的评估框架，并给出可复现的观测方法与工程应对路径。

目录

一、背景与问题定义：从"变笨"的直觉到可测量的量

1.1 "退化"叙事的三种来源

关于 Claude Code 变"笨"的反馈，大致可归为三类。第一类是能力型反馈：同一提示词在不同时间得到质量差异明显的回答，尤其在多文件重构、长链路调试等任务上。第二类是行为型反馈：agent 更早停止、更少调用工具、更少自我验证，倾向于给出"看起来完整"但未经核实的结论。第三类是体验型反馈：高峰期响应变慢、会话被中断、上下文被截断。

这三类反馈在用户侧往往被压缩成一个词——"退化"。但从工程角度看，它们对应完全不同的机制：能力型可能涉及模型版本或系统提示的变更；行为型直接对应推理预算的收缩；体验型则对应服务端的排队与限流。若不拆开，讨论就会陷入"信者恒信"的循环。

笔者认为，判断"退化"是否成立，第一步不是比较回答质量，而是确认比较条件是否一致：模型标识、系统提示、工具集、上下文长度、并发负载。缺少这五个维度的记录，任何"变笨"的结论都不可证伪，也就不可采信。

1.2 问题定义：把"智能"拆成可观测指标

为避免空泛，本文把 agent 的"智能表现"操作化为四个可观测指标：

这四个指标的共同点是：它们都能被用户在客户端侧记录，不依赖服务方披露内部调度策略。这意味着"退化"可以被转化为一个可复现的测量问题，而非立场之争。

二、推理预算的三维结构：时长、深度、并发

2.1 维度一：任务运行时长上限

Agent 类产品与聊天产品的根本差异在于：一次任务可能持续数分钟到数十分钟，期间反复调用工具、读写文件、执行测试。服务方必须为每个会话预留资源，因此普遍设置墙钟时间上限。Anthropic 在其 API 文档中明确说明了请求超时与长任务的处理方式，并对不同模型层级给出不同的最大输出 token 约束（Anthropic, 2024–2025）。这类约束的直接后果是：当任务复杂度逼近时长上限，agent 会被迫"提前收尾"——不是因为它不会做，而是因为再做下去会话就会被切断。

这一点在长链路调试中尤为明显。一个需要复现、定位、修复、验证四阶段的 bug，若每阶段平均需要 8–12 轮工具调用，总轮次很容易超过 40。若系统在接近上限时开始压缩每轮输出长度、减少探索性调用，最终表现就是"修了个表面问题就收工"。

2.2 维度二：推理深度上限

推理模型（reasoning model）的核心机制是在输出最终答案前生成一段内部思考。OpenAI 在 o1 系统卡中描述了"测试时计算"（test-time compute）随难度动态伸缩的思路（OpenAI, 2024）；DeepSeek-R1 的技术报告则公开了以强化学习激发长链推理的训练路径，并给出了思考长度与准确率之间的相关性数据（DeepSeek-AI, 2025）。这些工作共同说明：推理深度是一个可调参数，而非模型的固有属性。

当服务方在高峰期降低"思考预算"（thinking budget），模型仍会输出答案，但思考链变短、分支探索变少、自我纠错减少。对用户而言，这表现为"答案更自信但更浅"。值得注意的是，这种降级通常不会伴随明显的错误提示，因此极难被单次使用察觉。

2.3 维度三：并发任务数量上限

并发约束是三者中最容易被忽视、却对体验影响最直接的一维。主流 API 普遍以 RPM（每分钟请求数）、TPM（每分钟 token 数）和并发会话数三个维度限流。当用户同时开启多个 agent 会话，或团队共享同一 API key，限流会触发排队、重试甚至降级。排队带来的不仅是延迟，还有上下文窗口的被动截断——为腾出资源，系统可能丢弃较早的对话历史，而 agent 恰恰依赖历史来维持任务状态。

一个常被忽略的因果链是：并发升高 → 排队延迟上升 → 客户端超时重试 → 有效请求数翻倍 → 限流更严重。这个正反馈回路可以解释为何"高峰期体验断崖式下降"往往比负载增长本身更剧烈。

2.4 三维耦合：预算的联合约束

三个维度并非独立，而是通过一个联合预算相互耦合。可以用一个简化的形式化表达描述：

设：
  T_max = 单任务墙钟时间上限（秒）
  D_max = 单次请求思考 token 上限
  C_max = 并发会话上限
  r     = 平均每轮工具调用耗时（秒）
  d     = 平均每轮思考 token 数
  n     = 任务所需轮次

可行条件：
  n * r        <= T_max        （时长约束）
  d            <= D_max        （深度约束）
  active_sessions <= C_max     （并发约束）

降级触发：当任一约束趋紧，系统降低 n 或 d，
          或对 active_sessions 排队，表现为"变浅/变慢"。

这个模型的价值在于：它把"退化"转化为一组可测量的不等式。用户只要记录 n、r、d 的实际值，就能判断自己遇到的是时长约束、深度约束还是并发约束，从而采取不同的规避策略。

三、技术路线：agent 循环中的预算消耗与降级触发

3.1 Agent 循环的预算消耗模型

一个典型的编码 agent 循环包含：观察（读取文件/命令输出）→ 规划（生成下一步）→ 行动（调用工具）→ 验证（运行测试/回读）。每一轮都消耗预算：观察消耗输入 token，规划消耗思考 token，行动消耗输出 token 与墙钟时间，验证再消耗一轮。ReAct 框架最早系统化了"推理—行动"交替的范式（Yao et al., 2023），而后续的 Reflexion 工作引入自我反思以提升长任务成功率（Shinn et al., 2023）。

本文评述：这些方法的共同前提是"多轮优于单轮"，但它们几乎都隐含假设——轮次是免费的。在真实产品中，轮次恰恰是最昂贵的资源。因此，把学术基准上的"多轮增益"直接外推到产品，会系统性高估实际表现，因为产品会在预算压力下砍掉那些带来增益的额外轮次。

3.2 降级触发的四种典型模式

综合公开文档与可观测行为，降级大致有四种触发模式：

四种模式中，思考压缩最隐蔽。它不改变接口、不报错、不降速，只改变输出质量。这也是"退化"争议最集中的地带。

3.3 为什么"更快更浅"是理性选择

从服务方视角，推理成本与生成 token 数近似线性相关，而思考 token 往往占据大头。在固定算力池下，降低平均思考长度可以显著提升单位时间服务能力。这并非"偷工减料"，而是在容量约束下的吞吐—质量权衡。排队论中的经典结论是：当利用率逼近 1，延迟会非线性上升；为避免雪崩，系统必须主动限流或降级。本文评述：把这一权衡公开化、可配置化，比隐藏它更有利于建立信任——用户可以选择"慢而深"或"快而浅"，而不是被动接受一个不透明的中间态。

四、关键数据与案例：限流、思考 token 与基准行为

4.1 公开文档中的约束证据

Anthropic 的 API 文档长期披露各模型的最大输出 token、上下文窗口与速率限制层级（Anthropic, 2025）。OpenAI 的速率限制文档同样以 RPM/TPM 双维度描述配额（OpenAI, 2025）。Google 的 Gemini API 文档亦给出按模型区分的配额表（Google, 2025）。这些公开数据虽不直接说明"降级策略"，但足以证明：时长、深度、并发三个维度的上限是产品设计的固有组成部分，而非偶发故障。

需要说明的是，各厂商的具体配额会随版本调整，本文引用的数值仅用于说明约束存在性，不作为实时配额依据。读者应以官方文档为准。

4.2 推理长度与准确率的关系

DeepSeek-R1 技术报告给出了一个关键观察：在数学与代码任务上，随着推理链长度增加，准确率总体上升，但存在边际递减，且在部分任务上过长推理反而引入错误（DeepSeek-AI, 2025）。OpenAI o1 系统卡亦指出测试时计算与性能的正相关，但同时强调收益随任务类型差异显著（OpenAI, 2024）。

本文评述：这两份材料共同支持一个审慎结论——思考预算与质量之间是"倒 U 型"而非单调关系。这意味着服务方压缩预算并不必然导致质量线性下降，但一旦压缩越过拐点，质量会陡降。争议的实质，是用户感知到的拐点位置与服务方设定的预算位置不一致。

4.3 基准行为数据：agent 评测的轮次敏感性

SWE-bench 系列是当前编码 agent 的主流评测（Jimenez et al., 2024；SWE-bench Verified 后续版本）。相关研究普遍报告：限制 agent 的最大交互轮次会显著降低解决率，且不同任务对轮次的敏感度差异很大。例如，单文件小改动在 10 轮内即可完成，而跨模块重构往往需要 30 轮以上。这一分布特征意味着：统一的轮次上限对简单任务无影响，对复杂任务却是致命的。

下表为基于公开评测报告与本文整理的示意性对比（标注为整合数据，非单一来源实测）：

（数据说明：轮次区间为基于 SWE-bench 相关公开报告与开发者社区实践反馈的整合估计，用于说明量级差异，不代表任何单一系统的精确统计。）

4.4 案例：一次可复现的退化观测

假设某团队在同一仓库上连续两周记录 agent 会话日志。可设计如下观测流程（模拟数据，用于演示方法）：

步骤 1：固定任务集（10 个已知答案的 bug）
步骤 2：每次会话记录 model_id、prompt_version、tool_set
步骤 3：解析 usage 字段，计算思考 token 占比
步骤 4：统计工具调用轮次与自校验次数
步骤 5：按小时聚合，与官方状态页/延迟曲线对齐
步骤 6：对同一任务重复 5 次，取中位数以抑制噪声

判读规则：
  若思考占比下降 > 30% 且轮次下降 > 25%，
  同时首 token 延迟上升 > 50%，
  则高度提示预算收缩而非模型变更。

这一流程的关键在于控制变量：固定任务集、固定提示、固定工具集，只让时间与负载变化。只有这样，"退化"才从主观感受变成可归因的证据。

五、对比与局限：产品承诺 vs 服务等级

5.1 两种契约模型的差异

软件产品通常以"版本"为契约单位：v1.2 的行为在 v1.3 发布前应保持稳定。但推理服务的行为依赖实时资源状态，天然无法满足这一承诺。于是出现了两种契约模型：

本文评述：当前争议的根源，是服务方以"产品"话术营销、以"服务"逻辑运营，而用户以"产品"预期付费。弥合这一错位，不需要服务方公开全部调度细节，只需公开可验证的服务等级指标——例如"标准层级下，思考 token 占比不低于 X%、复杂任务完成率不低于 Y%"。可验证，才可议价。

5.2 局限与反例

必须承认，本文框架存在边界。第一，并非所有退化都源于预算：系统提示变更、工具描述调整、安全策略收紧都可能改变行为，且这些变更同样不透明。第二，用户侧观测存在噪声：网络抖动、本地环境差异、任务本身难度波动都会干扰判断，需要足够样本量。第三，服务方可能同时调整多个维度，导致归因困难。

因此，本文主张的"预算约束"解释应被视为首要假设而非唯一结论。它的价值在于提供了一个可检验的起点，而非终结讨论。若观测数据显示思考占比与轮次均未变化而质量下降，则应转向模型或提示变更的假设。

六、工程实践：可复现的退化观测与规避路径

6.1 建立本地观测基线

规避退化的第一步是建立基线。建议维护一个"金标准任务集"：10–20 个覆盖不同复杂度、有确定答案的任务，每次升级或怀疑退化时重跑。记录字段至少包括：模型标识、提示版本、工具集哈希、思考 token、输出 token、工具轮次、总耗时、首 token 延迟、是否通过验证。

可参考的公开资源包括：SWE-bench 官方仓库与评测脚本（github.com/swe-bench/SWE-bench）、Anthropic 官方 API 文档中的 usage 字段说明（docs.anthropic.com）、以及 OpenAI Cookbook 中关于速率限制与重试的实践指南（cookbook.openai.com）。

6.2 任务分解：把长任务切成预算友好的单元

既然时长与轮次是硬约束，最直接的规避策略是主动分解。把"重构整个模块"拆成"梳理依赖 → 改接口 → 改调用点 → 跑测试"四个子任务，每个子任务单独会话，并在会话开始时注入上一阶段的结论摘要。这样每个会话的轮次都落在安全区间内，避免触发时长截断。

操作要点有三：其一，子任务边界应可独立验证，避免"改一半无法测试"；其二，阶段摘要要显式写入文件或提示，不能依赖模型记忆；其三，每个子任务结束时要求 agent 输出"已完成/未完成/风险点"三段式结论，便于下一阶段接续。

6.3 并发治理：避免自触发限流

针对并发约束，建议在客户端实现令牌桶式节流，并设置指数退避重试。关键细节是重试要带抖动（jitter），否则多个客户端会在同一时刻重试，形成新的尖峰。此外，团队共享 key 时应按成员分配子配额，避免单人长任务挤占全组额度。

# 伪代码：带抖动的退避重试
def call_with_backoff(fn, max_retries=5):
    for i in range(max_retries):
        try:
            return fn()
        except RateLimitError:
            base = 2 ** i
            jitter = random.uniform(0, base * 0.5)
            sleep(base + jitter)
    raise

6.4 提示层补偿：显式要求深度

当系统侧压缩思考预算时，提示层可以做部分补偿。例如在系统提示中明确要求"在给出结论前，列出至少两个被排除的假设及其排除依据"，或"修改后必须运行测试并贴出结果"。这类要求会迫使 agent 消耗更多轮次与思考 token，从而在一定程度上抵消压缩。但需注意，补偿有上限：若系统硬性限制思考 token，提示层无法突破。

6.5 选型与议价：按服务等级采购

对于团队用户，建议把"服务等级"纳入采购评估：不仅比较单价，还比较在同等任务集上的完成率、平均轮次、思考占比与延迟分布。可要求供应商提供或在试用期自行测量这些指标。若某层级在高峰期指标显著劣化，应考虑为关键任务预留更高层级配额，或采用多供应商冗余。

七、结论与展望：把"智能"写成 SLA

回到开篇的问题：用户花钱买到的"智能"，是稳定产品还是随负载波动的服务？本文的答案是——在当前技术经济条件下，它必然是服务。推理成本随思考深度增长，算力池有限，排队不可避免。把服务包装成产品，只会制造预期落差；把服务如实描述为服务，并给出可验证的等级指标，才能建立可持续的信任。

展望未来，三个方向值得关注。其一，预算感知的 agent 设计：让 agent 自己知道剩余预算，并据此调整策略，而非被动被截断。其二，分层推理路由：简单步骤用浅推理、关键决策用深推理，把有限预算花在刀刃上。其三，标准化服务等级披露：类似云计算的 SLA，推理服务也需要一套行业通行的指标口径。

本文评述：把"智能"写成 SLA，听起来是把浪漫的技术降格为枯燥的合同条款。但恰恰相反——只有当我们能测量它、约定它、验证它，"智能"才从营销话术变成可依赖的工程基础设施。这不是对技术的祛魅，而是对技术的负责。

主要参考文献

（说明：本文综合参考国内外公开技术文档、系统卡、评测报告与开发者社区实践资料共 60 余篇，其中近三年文献占比超过 50%。上述 9 篇为主要参考文献。文中涉及的轮次区间、思考占比变化等为整合估计或模拟数据，已在相应位置标注，引用时请以原始文献为准。数据集方面，SWE-bench 相关任务在使用前需按官方脚本进行环境隔离与测试用例过滤，去除依赖缺失与不可复现样本，本文所述观测流程默认已完成该预处理。）

拓展阅读与教程链接

• Anthropic 官方提示工程与 agent 构建指南：docs.anthropic.com/en/docs/build-with-claude
• OpenAI Cookbook 速率限制处理实践：cookbook.openai.com/examples/how_to_handle_rate_limits
• SWE-bench 评测入门与复现教程：github.com/swe-bench/SWE-bench
• ReAct 论文与代码实现：arxiv.org/abs/2210.03629