就在不少开发者把Claude当成日常生产力工具的时候，这家由OpenAI前研究副总裁Dario Amodei创办的AI公司，又在服务端栽了个跟头。根据Anthropic官方状态页status.claude.com的实时记录，本周二（6月23日）下午，旗下多个Claude型号同时出现错误率显著升高的情况，波及范围从普通用户的网页聊天界面一路延伸到企业级API接口。
事情大概是在UTC时间14:19左右开始发酵的。Anthropic工程师团队在状态页上挂出了第一条调查通告，措辞相当谨慎，只说是"多个型号的错误率升高"（Elevated Error Rates on Multiple Models）。不到六分钟，14:25更新称已经定位到根因，正在推送修复。到14:53，补丁部署完毕，服务进入监控观察期。然而直到15:28，官方还在持续刷新状态，表示"仍在密切关注是否存在其他潜在问题"——这种欲说还休的表态，通常意味着后台日志里还有些没清理干净的异常栈。
波及面比想象中宽
这次故障绝不是某个边缘节点的小打小闹。从官方披露的产品矩阵来看，几乎全线中招：面向C端用户的claude.ai聊天界面、开发者后台platform.claude.com、Claude API接口、Claude Code编程助手，以及Claude Cowork协作工具，状态页清一色标黄或标红。唯一独善其身的是政府版Claude（Government Claude），这条隔离线的存在本身就说明Anthropic在架构上确实做了政企隔离，关键时刻派上了用场。
社交媒体上很快炸开了锅。有用户在X（原Twitter）上吐槽："Claude到底在搞什么鬼？"配图显示全平台严重故障。这种情绪在开发者圈子里蔓延得很快——毕竟当你的CI/CD流水线里嵌了Claude API，每一次500错误都直接等于构建失败。
不过需要厘清的是，"错误率升高"和"服务完全宕机"是两个概念。根据Anthropic过往的事件分级标准，这类描述通常意味着部分请求返回异常或超时，而非整个平台彻底黑屏。换句话说，你可能发十条消息，有一两条报错，刷新一下又能继续聊。但对于把Claude集成进生产环境的企业客户来说，这种"半吊子"故障反而更难处理，因为你无法简单切换灾备，只能干看着日志里蹦出一堆HTTP 5xx。
Opus 4.8成了六月的"问题儿童"
如果单独看这一天的故障，或许还能用"偶发事件"搪塞过去。但把时间轴拉长到整个六月，情况就变得耐人寻味了。
就在周二这起多型号事件发生的同一天清晨，Claude Opus 4.8已经单独出过幺蛾子。UTC 06:28开始报错，折腾到08:45才消停。往前翻一天，6月22日凌晨，Opus 4.8、Opus 4.7、Opus 4.6、Sonnet 4.6和Haiku 4.5集体中招，虽然官方记录显示"已于凌晨解决"，但如此密集的跨型号故障，很难不让人怀疑底层推理集群或模型服务网关存在某种系统性隐患。
更具参考价值的量化数据出现在6月16日。那天Anthropic罕见地公布了具体数字：所有Sonnet和Opus模型在第一阶段错误率冲到了约10%，随后Opus 4.8在第二阶段单独"加餐"，平均错误率同样维持在10%上下。10%是什么概念？假设一个电商客服系统每秒处理1000次Claude API调用，意味着每秒有100个用户会收到"服务器繁忙"的提示。这种级别的抖动，对依赖实时交互的商业应用来说已经是红线边缘。
大模型竞赛背后的基础设施隐忧
Anthropic近一个月的状态页，几乎成了AI基础设施脆弱性的活标本。当行业舆论还在争论Claude Opus 4.8的推理能力是否超越GPT-5时，它的可用性却在实打实地拖后腿。对于正在评估AI供应商的企业采购方来说，SLA（服务等级协议）的含金量正在迅速上升——模型再聪明，三天两头抽风也是白搭。
值得玩味的是，Anthropic在历次事件通报中几乎从不披露具体技术根因。是GPU集群过热？是KV缓存管理出现内存泄漏？还是新模型部署时的A/B测试切流出了问题？外界只能猜测。这种信息不透明在toC场景下或许无伤大雅，但随着Claude API在越来越多的SaaS产品里扮演核心组件，开发者社区对可观测性和故障复盘的要求只会越来越高。
眼下服务已经恢复，状态页也重新变绿。但六月的这几页黄色记录，给Anthropic的可靠性团队敲响了警钟。在AI大模型商业化落地的关键窗口期，"能用"和"好用"之间，其实隔着一条叫做"稳定"的鸿沟。
扫一扫
770
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
