Notion 冇對外詳細講明究竟邊幾間 AI 供應商做咗「後備軍」接收咗啲跳轉流量,但佢哋嘅行動就非常清晰:一偵測到 Anthropic 嘅 Opus 模型開始回傳啲降級嘅結果,系統就自動喺用戶界面嗰度收起晒所有 Anthropic 模型,然後將啲請求掟去第二度處理 。
呢個就係一個活生生嘅「多模型故障轉移(Multi-Model Failover)」架構實例。Notion 冇選擇乾等 Anthropic 修復,然後任由用戶睇住啲失敗訊息乾焦急。相反,佢哋將 AI 模型層當成一件可以隨時更換嘅零件——就好似一個雲端架構師處理一個跪低咗嘅數據庫,或者一個冇晒反應嘅 CDN 一樣。
單獨睇 6 月 7 號呢單嘢,的確係小事一樁。但將佢放返喺成個六月嘅背景,就會發現佢只係一堆動搖緊平台信心嘅 Claude 事故入面,最新嘅一塊碎片。
最嚴重嘅一次死機發生喺 6 月 2 號。當日 Claude.ai、API、Claude Console 同 Claude Code 全部都受到嚴重影響。Opus 4.6 同其他模型嘅錯誤率大幅上升,Downdetector 上面嘅用戶回報喺美國東岸時間凌晨 2 點 10 分(即係格林威治時間朝早 7 點 10 分)左右開始飆升。成個服務中斷持續咗差唔多六個鐘頭先至全面恢復 。
隔咗三日,到 6 月 5 號,Anthropic 嘅 Claude 平台又一次「死咗」。狀態頁面記錄顯示,由 UTC 時間下晝 3 點 08 分到傍晚 6 點 28 分,「多個 Claude 模型出現大量錯誤」,其中 Opus 4.7 同 4.8 係最遲先恢復嘅。呢次事件仲有單更「大鑊」嘅後續:有用戶報告話,服務恢復之後,佢哋竟然收到一啲好似屬於其他人嘅對話紀錄。咁樣就迫使 Anthropic 要正式開 file 調查,睇下有冇潛在嘅數據洩漏風險 。
呢一堆事故唔係無端端爆出嚟嘅。Opus 4.7 喺 5 月 22 號同 25 號已經記錄咗有報錯嘅時間窗口。由開發者提交嘅回報顯示,Opus 4.7 喺 4 月 16 號發布大約一個禮拜之後,就出現咗品質回退(Quality Regression)——呢個情況同 Opus 4.6 喺 3 月嗰陣嘅「發病」模式一模一樣 。
喺 2026 年 4 月,Anthropic 都公開承認咗 Claude Code、Claude Agent SDK 同 Claude Cowork 喺 3 月 4 號至 4 月 20 號期間出現品質下降。佢哋將原因歸咎於三個唔同嘅因素,喺出咗事後檢討報告之後,仲重置咗用戶嘅使用限制 。
對於嗰啲依賴 Claude 作為核心組件嘅公司嚟講,6 月 7 號 Notion 嘅事件帶嚟咗一個直截了當嘅教訓:第三方 AI 模型嘅依賴,已經演變成一種基建風險,係一定要用工程手段去抗衡嘅。
一個直接調用單一 Anthropic 模型嘅生產系統,係需要配備三種唔同嘅能力:一個應付瞬時 5xx 或者 529 錯誤嘅重試策略(Retry Strategy);一個喺服務中斷時可以吸收衝擊嘅後備模型(Fallback Model);仲有一個應對長期品質回退或者模型退役嘅遷移計劃(Migration Plan)。淨係靠以上任何一種策略都係唔夠穩陣嘅 。
Notion 自動停用所有 Anthropic 模型,同埋無縫咁跳轉去其他供應商嘅做法,正正係更多下游整合商需要跟住採用嘅模式。如果你冇呢種多模型故障轉移架構,就算只係短短五十分鐘嘅效能下降,都可能令到客服機械人、數據管道同開發者工具全面「跪低」,造成災難級嘅客戶體驗 。
Anthropic 自己嘅 90 日在線數據顯示,claude.ai 有 98.8% 在線率,而 Claude API 有 99.15% 。就咁睇落呢啲數字好似幾合理,但你唔好忘記,好多公司而家已經將呢個平台當成第一層(Tier-1)嘅基建咁看待。2026 年 6 月初呢一堆密集式事故——一次六個鐘嘅全球死機、一次引發數據洩漏調查嘅三粒鐘死機,再加多幾次小型中斷——都係強烈暗示緊一件事:AI 依賴嘅韌性門檻,必須要設定得比傳統 SaaS 服務更高先得。
Notion 喺 6 月 7 號全線抽起 Anthropic 模型,係一次針對暫時性基建問題嘅例行操作。但係,喺大約六個星期之內出現咗六次比較明顯嘅 Claude 死機事件,呢個動作就變成咗一個好清晰嘅信號:將生成式 AI 當成一個刺激嘅新實驗品嗰段「蜜月期」,已經正式結束。
對於任何喺 Claude 或者其他第三方 AI 模型上面「起樓」嘅團隊嚟講,可靠性工程已經唔再係一個選擇題。重試邏輯、後備供應商,同埋一條經得起測試嘅模型遷移路徑,將會係你喺地基開始搖晃嗰陣,保住你件產品唔好「爛尾」嘅最基本入場籌碼。
Comments
0 comments