作者：simon · 2026-11-05
用 coding agent 的人大概都有过这种怀疑：怎么今天它好像笨了一点？
多数时候是你想多了。但 Anthropic 发过一篇复盘，承认那一阵用户的感觉不是错觉：有 3 个基础设施 bug 在间歇性地拉低回答质量。页面写的发布日是 2025 年 9 月 17 日，署名 Sam McAllister。我读完，用人话讲一遍，重点放在"为什么这么难查"。
先说结论
- 原文的立场很明确：问题来自 3 个基础设施 bug，不是为了省算力故意降质。原话："We never reduce model quality due to demand, time of day, or server load."（我们从不因为需求、时段或服务器负载降低模型质量。）这是厂商自己的说法，我没法独立验证。
- 3 个 bug 时间上互相叠，症状又因平台、模型、概率而不同，所以用户反馈看起来像"随机变差"。
- 最值得程序员带走的，是他们自己写的反思：评测没抓到用户感受到的退化，隐私规则又让工程师没法直接看出问题的对话。
- 我没有复现任何一个 bug，下面所有"我的看法"都是读后判断。
背景：同一个模型，跑在好几种硬件上
原文说，Claude 通过第一方 API、Amazon Bedrock 和 Google Cloud 的 Vertex AI 提供服务，硬件有 AWS Trainium、NVIDIA GPU 和 Google TPU 三类。他们的目标是：不管哪个平台接了你的请求，回答质量应该一样。
这也是后面故事的伏笔：同一个改动，在不同平台上可能表现完全不同。
三个 bug，各发生了什么
1. 上下文窗口路由错误。 8 月 5 日起，一部分 Sonnet 4 请求被错发到了为"即将推出的 100 万 token 上下文窗口"配置的服务器上，最初影响约 0.8% 的请求。8 月 29 日一次例行的负载均衡调整，意外让更多短上下文请求被送到那批服务器；8 月 31 日最糟的一小时，16% 的 Sonnet 4 请求受影响。原文还说，这段时间里发过请求的 Claude Code 用户，约 30% 至少有一条消息被错发。
另外，原文说他们的路由是"sticky"的：一次被错发，后面的追问很可能继续被送到同一类错误服务器。所以有人只是偶尔碰上，有人是一路踩。
按原文的数字，各平台受影响程度差得很远：Amazon Bedrock 上错发流量最高占 Sonnet 4 请求的 0.18%（从 8 月 12 日起）；Google Cloud 的 Vertex AI 上，8 月 27 日到 9 月 16 日之间受影响请求不到 0.0004%。修复在 9 月 4 日上线；第一方平台和 Vertex AI 在 9 月 16 日完成推广，AWS Bedrock 在 9 月 18 日完成。
2. 输出损坏。 8 月 25 日，他们给 Claude API 的 TPU 服务器部署了一个错误配置，导致生成 token 时出错：一次运行时性能优化，偶尔会给"按上下文本不该出现"的 token 很高的概率。原文举的例子是：用英文提问，回答中间冒出泰语或中文字符，或者代码里出现明显的语法错误。原文甚至写了一个例子："สวัสดี"。
我的看法： 你问的是英文问题，模型在中间非常礼貌地用泰语跟你打了个招呼。就是这个招呼，让人没法再把它当成"我今天看错了"。
影响范围：Opus 4.1 和 Opus 4 在 8 月 25 日至 28 日，Sonnet 4 在 8 月 25 日至 9 月 2 日；原文说第三方平台没有受影响。9 月 2 日回滚，并且在部署流程里加了针对"异常字符输出"的检测测试。
3. 近似 top-k 的 XLA:TPU 编译错误。 8 月 25 日他们上线了一段改进 token 选择方式的代码，意外触发了 XLA:TPU 编译器里一个原本就潜伏着的 bug。原文说已确认影响 Claude Haiku 3.5，也认为可能影响了 Claude API 上一部分 Sonnet 4 和 Opus 3；第三方平台没受影响。Haiku 3.5 在 9 月 4 日回滚，Opus 3 在 9 月 12 日回滚；Sonnet 4 上他们没能复现，但"为了保险"也一并回滚了。
这个编译器 bug 为什么难查
这一段是原文最有"工程味"的部分，我只讲脉络。
模型生成文字时，会先算出每个可能的下一个词的概率，再从中抽样。为了避免胡言乱语，会用 top-p 采样：只考虑累计概率达到某个阈值的那些词，原文写阈值通常是 0.99 或 0.999。
故事线是这样的：
- 2024 年 12 月，他们发现 TPU 实现偶尔会在 temperature 为 0 时，把概率最高的那个 token 丢掉，于是上了一个绕过问题的补丁。
- 根因是混合精度：模型用 bf16 算概率，而向量处理器原生是 fp32，编译器可能把一部分运算悄悄转成 fp32 来优化，开关是
xla_allow_excess_precision，默认为 true。结果几个本该对"谁概率最高"达成一致的运算，精度不一样，就吵起来了。 - 8 月 26 日，他们上线重写的采样代码来修这个精度问题，并移除了 12 月的补丁，因为以为根因已经解决。
- 然后暴露了更深的一个问题：近似 top-k（一种快速找出概率最高 token 的性能优化）有时会返回完全错误的结果，只在特定的 batch 大小和模型配置下出现。12 月那个补丁，一直在不经意间把它盖住了。原文原话："The December workaround had been inadvertently masking this problem."
我的看法： 这像把墙上的一块遮丑胶带撕了，才发现胶带下面本来就有一道裂缝。教训不是"别撕胶带"，而是：**拆一个绕过方案之前，先想想它可能还挡着别的东西。**这是我读完的判断，原文没有这么总结。
更折磨人的是，原文说这个 bug 的表现"frustratingly inconsistent"（令人沮丧地不稳定）：它会因为不相关的因素而变，比如这个运算前后跑了什么，或者有没有打开调试工具；同一个提示这次好好的，下一次就坏。
最后他们的做法是：改回精确 top-k，并把另外一些运算统一到 fp32 精度。原话："Model quality is non-negotiable, so we accepted the minor efficiency impact."（模型质量没得商量，所以我们接受了轻微的效率损失。）原文还说，在调查中发现精确 top-k 已经没有以前那么大的性能代价。
为什么这么久才发现
原文给的几条原因，我觉得对每个做 AI 应用的人都有参考价值：
- 评测没覆盖到。 原文说，他们跑的评测"simply didn't capture the degradation users were reporting"，部分原因是 Claude 往往能从孤立的错误里恢复过来。
- 隐私规则挡住了排查。 内部的隐私和安全控制，限制了工程师何时、怎样看到用户和 Claude 的对话，尤其是没有以反馈形式主动上报的那些。这保护了隐私，但也让工程师没法直接看到出问题的对话。
- 症状太杂。 每个 bug 在不同平台上、以不同比例，产生不同症状。原文说："It looked like random, inconsistent degradation."（看起来就是随机、不一致的退化。）
- 对噪声评测依赖太多。 原文承认 "we relied too heavily on noisy evaluations"。8 月 29 日负面反馈暴涨，他们没有立刻把它和那次"标准的"负载均衡调整联系起来。
他们说要改什么
原文列了三条：更灵敏的评测（能更可靠地区分正常和有问题的实现）；在真正的生产系统上持续跑质量评测，来抓到类似上下文窗口路由错误的问题；以及在不牺牲用户隐私的前提下，建设更好的调试工具来处理来自社区的反馈。
另外原文特别提到，评测和监控之外，还需要用户的持续反馈：具体变化的描述、遇到的异常行为样例、跨场景的规律，都帮他们定位了问题。它建议在 Claude Code 里用 /bug 命令，或者在 Claude 应用里用"踩"按钮反馈。
我的看法：给自己的 AI 应用抄两条作业
下面是读后判断，没有实测：
- 别只看离线评测。 原文自己的结论就是评测没抓到。如果你做的东西靠第三方模型，用户的"感觉变差了"值得有个渠道收上来，而不是只看跑分。
- 上线前先想"同一个改动在每个平台上会怎样"。 这篇的 3 个 bug 里，有 2 个原文明确说第三方平台没受影响，也有的只发生在一部分硬件上，所以一个全局的"整体看着没问题"并不能代表所有路径。
- 拆绕过方案要当成一次变更来评审。 见上面的"胶带"。
一句话带走
- Anthropic 说那一阵的质量下降来自 3 个基础设施 bug，不是故意降质；这是厂商自述。
- 3 个 bug 叠加、跨平台、概率性出现，所以像随机变差。
- 评测没抓到、隐私规则又限制了排查，是它自己总结的原因；你的应用也值得给用户反馈留一个口子。
同一系列，另一个平台上的相关文章
这篇复盘里有一条主线：自检"通过"了，线上还是出了问题。我在 CSDN 发过一篇同方向的：它验证过才删的：agent 的 dry-run 是干净的，线上文件还是没了，讲的是另一个场景下"验证是干净的，现实不是"。
参考与出处
- 《A postmortem of three recent issues》，Anthropic，页面显示 Published Sep 17, 2025，Team: Engineering，署名 Written by Sam McAllister。www.anthropic.com/research/a-… （2026-10-26 读取，核对了文中引语和数字）
- 文中带引号的英文都是原文原句，每句不超过 25 个词；所有数字、日期、模型名都来自原文自述，我没有第三方佐证。
- 原文有多处代码截图、时间线图和脚注，我只转述了大意，没有照搬。
