原文链接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 暴露出来的不止是三个 bugAnthropic 在复盘里承认了三类问题。表面看它们像是彼此独立的小事故放在一起看就能发现这其实是一套系统同时在多个位置变脆。时间段问题直接后果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 的复杂任务能看出同一类问题是否持续退化关注公开 benchmarkSWE-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