An update on recent Claude Code quality reports

Claude Code 近兩個月的大量品質投訴是真實的。Anthropic 的 postmortem（事後檢討報告）坦承：問題出在 harness（模型外層執行框架）的三個獨立 bug，而非模型本身退步。其中一個 3 月 26 日上線的 bug，讓 Claude 在用戶恢復長時間閒置的 session 後，此後每輪對話都喪失記憶積累，讓它看起來既健忘又重複——而這恰好是最難與模型退步區分的症狀。

兩個月投訴確認屬實：三個 Harness Bug 同時潛伏

Anthropic 在官方 postmortem 中坦承，近兩個月用戶反映的 Claude Code 品質下滑確實有根據，但模型本身並非問題根源。harness 層——負責管理對話歷史、工具呼叫、上下文傳遞等邏輯的工程系統——同時出現了三個彼此獨立的 bug，且每一個都複雜到足以單獨造成可觀察到的輸出品質劣化。

三個 bug 同時存在讓問題更難被快速定位。它們互不相關，卻在外部觀察者看來都只呈現「Claude 變差了」的同一副面貌。模型輸出本身的非確定性（non-deterministic，即相同輸入可能產生不同輸出）讓排查更加困難——工程層的邏輯錯誤和模型本身的行為差異，在輸出結果上幾乎難以分辨。

3 月 26 日的更新 Bug：閒置逾一小時的 Session 此後每輪失憶

三個 bug 中，Simon Willison 特別點名了 3 月 26 日引入的那一個，認為它最具代表性。

原始設計的意圖是：當一個 session 閒置超過一小時後，系統在用戶恢復工作時，會清除 Claude 積累的舊有 thinking（推理過程中的中間記憶）以降低回應延遲。這個清除動作應該只在 session 恢復的那一刻執行一次。然而，一個 bug 導致它在此後的每一輪對話都重複觸發——不是只有恢復時那一次，而是整個剩餘 session 的每輪都清空。

結果是：只要一個 session 曾被閒置超過一小時，Claude 之後就會在每輪對話中都喪失剛剛積累的上下文脈絡，表現得像是每輪都重新開始的健忘助理。從用戶角度，這個症狀與「模型能力退步」的表現幾乎完全重疊，在不了解內部機制的情況下，很難猜到是工程層面的問題。

Simon Willison 的 11 個閒置 Session：stale 工作法才是主力

Simon Willison 坦言，這個 bug 對他的衝擊尤其大。他習慣在 Claude Code 的 session 開啟後，離開一小時、一天甚至更久，之後再回來繼續工作——這正是觸發清除邏輯的典型使用模式。

他用 ps aux | grep 'claude '（列出系統執行中進程的 Unix 命令）查了自己的機器狀態，發現背景同時有 11 個 Claude Code session 在執行，而這還是在幾天前剛關掉幾十個之後的數量。他估計自己在這類「閒置後恢復」的 stale session（舊有工作會話）中花費的提示時間，比在剛開啟的全新 session 中花費的還要多。

這種工作模式在重度 Claude Code 用戶中相當普遍：許多人不是線性地完成一個任務才開新對話，而是同時維護多個長期推進中的工作脈絡。對這類用戶而言，這個 bug 幾乎等同於讓所有 session 在閒置一小時後降格為「沒有記憶的對話」，工作連貫性被系統性地打斷。

Agentic 系統開發者的工程警示：Harness 層比模型更難排查

Simon Willison 呼籲所有正在建構 agentic（自主代理式）系統的開發者仔細閱讀 Anthropic 的 postmortem。他的核心觀點是：harness 層的 bug 比模型本身的問題更難被發現，即使完全撇開模型的非確定性，工程複雜度本身就已足夠令人頭疼。

harness 在 agentic 系統中負責的邏輯遠不止「把輸入送給模型」：它管理 context window（上下文窗口）的壓縮策略、工具呼叫的執行順序與狀態追蹤、session 恢復時的歷史處理方式，以及各種邊緣情況的容錯邏輯。任何一個環節的細微偏差，都可能在不拋出任何錯誤訊息的情況下，悄悄改變模型的輸出行為。

這次事故說明了一個對開發者極有參考價值的教訓：harness 層的問題不讓系統崩潰，只讓模型「看起來更笨」。這正是最難被自動化測試捕捉、也最容易被誤判為模型退步的故障類型。

Harness Bug 不報錯、只讓模型假性退步——建構 agentic 系統時，工程框架的可靠性測試和模型評估同等重要。