当用户觉得 Agent 变笨时，真正退化的往往不是模型
原文链接：AI 小老六
过去一段时间，X 上关于 Claude Code 的争论几乎都指向同一句话：它变笨了。
这类抱怨以前也有，但这次不太一样。最先喊出问题的，不是随手试玩的普通用户，而是那群最重度、最舍得付费、也最有判断力的开发者。他们每个月花 200 美元，把Claude Code当主力生产工具，用它改仓库、修 bug、做重构、跑长任务。也正因为用得深，他们最先感觉到一种很难描述、但越来越明显的变化：回答还是那套回答，任务也还能做，但真正需要耐心、上下文管理和深度推理的活，它开始掉链子了。
后来 Anthropic 自己发了 postmortem，承认确实出了问题。可这件事真正值得写的地方，并不是某个版本一时翻车，而是它把一个行业事实挑明了：当下的Coding Agent，出问题时看起来像“模型降智”，根子往往却不在模型本身。
问题出在系统！
这次不是体感，而是能量化的退化
把这轮讨论真正坐实的，是一份来自真实使用日志的分析。
AMD 的 AI 负责人 Sharon Zhou 把自己本地数千个 Claude Code session、二十多万次 tool call 和上万条 thinking block 拉出来做趋势统计，得出的结论很直接：Opus 4.6 之后，深度思考显著变浅，很多复杂任务开始更早进入“直接动手写代码”的阶段。与此同时，也有开发者独立定位到 cache 异常，发现对话本该命中的上下文缓存没有生效，模型每轮都在重新处理完整上下文，效果变差，token 消耗还更高。
这件事本身就很说明问题。一个全球级别的 Coding Agent 能力下滑，最先把它证明出来的，不是官方监控，而是用户从自己机器上的日志里反向做出来的。换句话说，现阶段很多 Agent 的质量退化，厂商未必比重度用户先知道。
Anthropic 暴露出来的，不止是三个 bug
Anthropic 在复盘里承认了三类问题。表面看，它们像是彼此独立的小事故；放在一起看，就能发现这其实是一套系统同时在多个位置变脆。
| 时间段 | 问题 | 直接后果 |
|---|---|---|
| 3 月初到 4 月初 | 默认reasoning effort从high调到medium | 延迟更低，但复杂任务更容易在没想透时就开工 |
| 3 月下旬到 4 月中旬 | idle session 的 thinking 清理逻辑有 bug | 上下文被反复清掉，模型更健忘，也更容易重复 |
| 4 月中旬几天 | prompt 加入过短输出约束 | 工具调用间解释过短，编码质量继续下滑 |
如果只是这样，这还只能算一次常见的软件事故。真正刺眼的地方在于，Anthropic 后来承认，内部员工日常用的版本和外部用户手里的 public build 并不完全一致。一些实验配置和内部开关把问题掩盖掉了，结果代码评审、测试和日常 dogfood 都没能把风险拦下来。
这其实比那三个 bug 更值得警觉。因为它说明今天很多 Agent 产品已经不是“上线一个模型接口”那么简单，而是带着prompt、缓存、调度、上下文裁剪、特性开关和服务端配置一起运行的复杂产物。只要内部与外部环境不一致，团队看到的就未必是用户真正用到的东西。
最值得警惕的，可能是默认值而不是 bug
如果只把这次事件理解为“几个 bug 叠在一起”，结论还是太轻了。更深的问题，是adaptive thinking这类设计在 Coding Agent 上到底该不该默认开启。
这个机制的逻辑并不难懂：模型自己判断任务难不难，再决定要不要深度思考、要想多久。对大多数普通请求来说，这确实合理。简单问题秒回，复杂问题再慢一点，公司还能省下大量 thinking token 和推理成本。从服务侧看，这几乎是一个顺理成章的优化。
问题是，Claude Code 的重度用户并不处在“普通请求”那一侧。
他们丢给工具的，不是写几行 demo，不是润色 README，而是跨几十个文件的老项目重构、生产环境才触发的 race condition、带隐式状态机的历史包袱代码。这类任务最怕的，不是回复慢一点，而是模型误判复杂度，以为事情很简单，结果在没看清依赖关系之前就开始写。
下面这个对比，差不多能解释为什么这个默认值会让人不安：
| 维度 | adaptive thinking默认开启 | 固定high或max effort |
|---|---|---|
| 响应速度 | 请求更快 | 所有请求都更慢 |
| 使用成本 | thinking token 更省 | 成本稳定偏高 |
| 复杂任务稳定性 | 取决于模型是否判断对难度 | 更稳，不容易把难题误判成小事 |
| 重度开发场景体感 | 方差大，偶尔“没想就上手” | 慢一些，但更可控 |
*图：默认策略一旦失配，复杂任务会比 benchmark 更早暴露退化*
问题恰恰在这里：“判断一个任务是否复杂”这件事，本身就需要足够好的判断力。把这个决定权完全交给模型，在客服问答或者轻量写作里也许问题不大，在 Coding Agent 里就容易出事。
更麻烦的是，默认值带来的退化常常不是断崖式的，而是滑坡式的。没有明显版本号，没有事故公告，没有某个时刻突然全线坏掉。用户只会感觉最近几周它越来越爱抢跑，越来越不肯认真读代码，直到某一天你才意识到，自己并不是运气差，而是默认行为已经被改过了。
Agent 早就不是“模型外面套一层壳”
这次事故最值得写进方法论的地方，在于它再次证明了一个已经越来越明显的事实：Agent 不是“模型 + wrapper”，而是一个多层系统。
*图：用户体感由模型、上下文、调度与缓存共同决定*
用户看到的“变笨了”，可能来自很多完全不同的地方：
- • 上下文裁剪错了，模型看起来像是记忆变差。
- • thinking 历史被过度清掉，模型会重复、会失去连贯性。
- • tool runtime 不稳定，长任务中途断掉，用户以为是模型不会做。
- • cache 命中异常，响应更慢、成本更高、表现也更飘。
- • prompt 或默认参数变了，模型开始偏向短答、快答、少思考。
其中任何一层出问题，最后都会汇总成同一种外部印象：“这个模型没有之前聪明了。” 这也是为什么很多厂商的模型 benchmark 没掉分，用户体感却已经明显变差。被评测的是模型，真正交付给用户的却是 Agent。
智谱的案例说明，这不是 Anthropic 一家的麻烦
如果说 Anthropic 这次暴露的是产品和 Agent 工程层的脆弱性，那么智谱在《Scaling Pain》里写出来的，则是更底层的另一面。
他们在高并发 Coding Agent 负载下遇到的异常，不是“不会写代码”这种表层问题，而是乱码、复读、生僻字这类看起来很像模型能力失常、实则出在服务基础设施上的故障。最后定位到的根因，是 PD 分离架构下的 KV Cache 竞态，以及 HiCache 加载时序缺失。也就是说，请求生命周期、缓存回收复用和数据加载之间的先后关系出了问题。
这件事的关键不在于具体技术细节，而在于它再次说明了同一件事：在真实线上环境里，模型输出质量和推理系统状态已经高度耦合。用户看到的是“怎么突然开始胡言乱语”，工程师最终修掉的却是 cache 的时序和调度问题。
把 Anthropic 和智谱放在一起看，结论其实相当统一：
- • 前者是 Agent 工程层出了问题，表现成能力退化。
- • 后者是推理基础设施层出了问题，表现成输出异常。
- • 两者共同说明，用户规模和推理负载正在跑得比监控和验证体系更快。
Fast、Smart、Cheap，今天仍然只能选两个
很多人把“模型变笨”理解成厂商偷偷削弱能力，但更常见的现实是另一种东西：工程取舍。
用户暴涨，推理资源紧，长上下文任务越来越多，厂商就会天然想往“更快一点、更省一点”那边挪。默认 effort 往下调一点，thinking 少一点，输出短一点，缓存更激进一点，看起来每一步都很合理。可这些局部优化一旦叠到 Coding Agent 这种长链路系统里，最后牺牲的往往就是最难量化、也最晚暴露出来的那部分质量。
*图：Agent 质量取决于速度、智能与成本之间的系统权衡*
而真正麻烦的是，最不能接受这类退化的人，通常正是付费最高、任务最复杂的那群用户。对他们来说，快不是第一位，对才是。一个花 200 美元买 Max 套餐、拿 Agent 去改大型仓库的人，通常愿意多等几十秒，但不愿意看到模型没想清楚就开始动刀。
所以这次事件最尖锐的矛盾，不是“Anthropic 出了 bug”，而是“面向平均用户的优化”和“面向重度开发场景的可靠性”发生了冲突。
真正缺的不是更强模型，而是更像样的运维能力
写到这里，其实已经能把问题说得更直接一点了。
Agent 的下一阶段竞争，未必首先是模型参数、榜单排名或者新功能数量，而是谁更像在运维一个真正的分布式系统。因为今天一个高频使用的 Coding Agent，至少已经同时面对这些难题：
- • 超长上下文如何裁剪，才不会把关键线索剪掉。
- • thinking 是否跨轮保留，保留多少，何时清理。
- • 长任务怎么 checkpoint，失败后怎么恢复一致状态。
- • cache 如何提速，又不因为回收和复用打乱结果。
- • 公网版本、灰度版本、内部版本怎样保证足够一致。
- • 线上到底用什么指标，才能尽早发现“看起来没报错，但用户已经觉得变笨了”。
*图：下一阶段竞争更像分布式系统的运维能力之争*
这套问题里，很多都不是传统模型评测能解决的。SWE-bench、LiveCodeBench、Aider 这类榜单当然重要，但它们测的是能力上限，不是产品系统在真实环境里的稳定下限。用户每天碰到的问题，则更接近另一种东西：一台在长任务、复杂上下文、本地环境差异和高并发压力下持续运转的工程机器，什么时候开始偏、开始抖、开始失真。
作为用户，监控不能只靠厂商
这次事件给重度用户最大的启发，其实很朴素：别把质量监控全部外包给平台。
真正有用的做法反而很“土”：
| 方法 | 看什么 | 为什么有用 |
|---|---|---|
| 盯本地 session 日志 | thinking 次数、tool calls、任务耗时、token 返回量 | 趋势比单次体感更可靠 |
| 维护私有评测集 | 固定仓库、固定 commit、固定 prompt 的复杂任务 | 能看出同一类问题是否持续退化 |
| 关注公开 benchmark | SWE-bench、Aider、LiveCodeBench 等 | 作为外部参照，避免只看个体体验 |
| 看社区异动 | 重度用户、研究者、工程师的集中吐槽 | 通常比官方公告更早暴露问题 |
这并不意味着用户要自己替厂商做 QA，而是说在 Agent 时代，真实质量的第一现场往往就在用户本地。最了解工具最近是不是开始偷懒、抢跑、丢上下文的人，通常不是发布说明，而是那个每天真的拿它干活的人。
最后的判断
Claude Code 这次事故之所以值得反复写，不是因为它罕见，恰恰是因为它太典型了。
模型能力在继续往上走，但围绕模型运行的 Agent 系统也在迅速变复杂。默认值、prompt、thinking 管理、缓存命中、长任务恢复、内部灰度、线上监控，这些东西单看都像细节，叠到一起却足以决定一个产品在重度场景里到底像不像“聪明工具”。
所以，当用户下一次说“这个 Agent 怎么变笨了”，最该先问的恐怕不是模型权重有没有变，而是整个系统里哪一层先开始失真了。
未来几年，模型公司的真正护城河，很可能不只是模型本身，而是有没有能力把几亿次 Agent 调用，当成一个需要认真观测、灰度、回滚和持续运维的复杂系统来管理。
谁先把这件事做好，谁才更可能留下来。
参考链接
[1]Anthropic: April 23 postmortem:https://www.anthropic.com/engineering/april-23-postmortem[2]AMD AI Director: 6,852 sessions analysis:https://x.com/alex_prompter/status/2043251644620525859[3]Anthropic: Adaptive thinking:https://platform.claude.com/docs/en/build-with-claude/adaptive-thinking[4]Z.ai: Scaling Pain:https://z.ai/blog/scaling-pain[5]Paweł Huryn: cache bug 分析:https://x.com/PawelHuryn/status/2042701413248307494