近期，社交媒體 X 上一條帖子集中反映了使用者對 Claude 的諸多不滿：文本和程式碼被加入機器可讀標記，Sonnet 5 的實際體驗未能匹配模型升級的聲勢，Fable 5 定價更高卻難以讓使用者明顯感到比 Opus 5 更強，且 Fable 5 的上下文僅使用約 20%–30% 時後續能力就開始下降。這些表面零散的問題，在 Claude 的技術棧中分別對應五個具體環節：生成機制、推理計算投入、模型分層、長上下文狀態管理以及 Agent 錯誤回灌。Anthropic 的瓶頸正從單點能力轉向軌跡可靠性。

第一宗罪：程式碼生成空間被壓縮

機器可讀標記嵌入普通文本時，技術難點在於既留下穩定訊號又不損害生成質量。但在程式碼場景中，這一難題顯著加劇，因為自然語言與程式碼的 token 分佈差異巨大。自然語言常存在多個語義接近的候選，模型擁有生成冗餘，文本水印可藉此在可接受 token 間微調取樣機率。而程式碼包含大量低熵位置：變數聲明後引用幾乎只能使用同一名字，JSON 的欄位、引號和括號受嚴格結構約束，函式引數必須符合介面，路徑、正則、SQL、Shell 命令中一個 token 變化就可能改變行為。這些位置的機率分佈尖銳，正確 token 佔據高機率，其他候選往往就是錯誤。因此，程式碼水印面臨的核心限制是編碼容量：若位置只有一種合理輸出，則幾乎沒有空間承載額外訊號；若僅在高熵位置嵌入標記，又會遇到程式碼短、結構化 token 比例高、可利用位置不足的問題。可檢測強度、生成質量與抗修改能力之間形成直接取捨。Anthropic 未公開 Claude 文本標記如何改變取樣，因此不能將 Claude Code 的質量變化直接歸因於某一種水印演算法。但可以確定的是，程式碼生成正承擔越來越多約束——除語義和執行正確性外，還需服從工具協議、結構化格式、安全規則和來源標記，而程式碼吸收額外約束的自由度遠小於自然語言。

第二宗罪：模型檔位變成計算曲線

Sonnet 5 的 adaptive thinking 帶來的變化不僅是讓模型多想一會。以往 Sonnet、Opus、Fable 可理解為固定能力點，現在加入 effort 後，同一模型可落在不同 test-time compute 區間，型號本身已不能完整代表一次請求實際投入的能力。在 Coding Agent 中，Claude 面對 bug 時需決定讀哪些檔案、追哪條呼叫鏈、保留幾個候選假設、是否執行測試、是否繼續檢查依賴，以及何時認為證據足夠。這些動作構成一棵搜尋樹：較低計算投入意味著更早剪枝、更快形成判斷；更高投入允許繼續搜尋和驗證，減少證據不足時直接執行的機率。因此 effort 調節的不是單純 thinking 長度，而是 Agent 任務允許展開的搜尋範圍。這改變了模型分層：若普通 coding 任務對 Opus 已不難，提高 effort 後 Opus 可能快速進入效能平台區，Fable 即使基礎模型更強，也沒有剩餘難度轉化為明顯體驗差，但使用者從請求開始就支付型號間的價格差。Fable 的價值更體現在陌生程式碼庫、多階段規劃、跨工具操作、長時間自主執行及錯誤恢復等任務上。高階模型出售的不再是“這一輪答案更強”，而是複雜軌跡裡的額外可靠性。但該優勢需任務足夠長才能展開，而任務拉長後，上下文狀態開始成為核心因素。

第三宗罪：能裝海量歷史，卻理不清當前狀態

看到 1M context，容易將其理解為巨大工作記憶體，因此當 Claude 僅使用 200K 或 300K token 就開始遺漏、反覆甚至狀態混亂時，顯得反直覺。但 context window 衡量的是容量，不是狀態一致性。長 Agent 會話不是靜態文件，而是不斷追加的執行歷史：檔案可能被多次修改，bug 最初被判斷為快取問題後來發現來自併發，測試先失敗後通過又因新修改重新失敗。舊內容不會自動刪除，新內容只是追加。問題已超出 retrieval：模型不僅要找到相關資訊，還要判斷這些資訊是否仍然有效。舊版函式與新函式高度相似，舊測試日誌與新日誌包含大量相同 token，已被推翻的分析也可能與當前問題語義相關。Attention 找到這些內容不難，難的是確定覆蓋關係。資料庫可依靠版本號、更新時間、事務和顯式欄位維護 current state，而自然語言 context 通常沒有這種結構，更接近 append-only log，模型需自行從事件順序恢復當前世界。因此，長上下文的複雜度與 token 佔用比例並非簡單對應：250K token 的靜態文件可能比 250K token 的 Agent 歷史容易處理得多。Thinking history 還會增加複雜度，會話中儲存的不只是“發生過什麼”，還可能包含“當時為什麼這麼判斷”，早期 reasoning 若建立在後來被推翻的假設上，仍可能因高度相關而繼續參與判斷。所以 1M context 的真正限制不只是能放多少資訊，而是當同一物件出現越來越多歷史版本後，模型能否穩定恢復當前版本。

第四宗罪：壓縮的是歷史，重新生成的是狀態

當 context 繼續增長，compaction 看似自然：把舊歷史壓短再繼續執行。但 Agent 場景的 compaction 與普通摘要不同。摘要文章少掉一個例子，影響通常只是資訊完整度；壓縮 Agent 軌跡時，遺漏一個仍有效的限制條件，後續執行路徑可能直接改變。compaction 必須解決的不是“哪些內容重要”，而是“哪些內容現在還算數”。一段歷史中可能同時存在已完成任務、被推翻判斷、仍成立的介面約束、過期測試結果和臨時 workaround，壓縮器需將這些時間狀態重新整理成可供下一輪工作的表示。若“目前懷疑問題來自快取”被壓成“問題來自快取”，臨時假設就變成事實；若已廢棄方案仍進入摘要，後續 Agent 可能重走舊路徑；若關鍵限制未進入摘要，它之後甚至不會被模型看到。因此 compaction 的關鍵指標不是壓縮率，而是狀態保真。這也是 Git、測試、任務檔案、memory 和結構化 handoff 在長時 Agent 中越來越重要的原因——它們將需長期成立的狀態從自然語言歷史移到外部系統：Git 明確當前程式碼版本，測試給出可驗證結果，任務檔案記錄完成情況，結構化狀態區分當前結論和歷史嘗試。Context 可保留豐富歷史，但不能長期承擔全部狀態管理職責。

第五宗罪：模型修補自己製造的 Bug，錯誤越來越大

Agent 會主動修改環境，這是與普通聊天的根本區別。普通聊天中模型答錯一次，錯誤停留在輸出文本；Agent 可修改程式碼、執行命令、安裝依賴、調整配置，再讀取新結果。於是錯誤不再只是判斷錯誤，還會變成環境變化。假設 Claude 將 bug 錯判為快取問題，修改快取邏輯、重試機制和呼叫點，測試隨後出現一批新異常。這些異常是真實的，但並非原始 bug 自然產生，而是上一輪修改製造出來的。這使 Agent 進入特殊失敗模式：模型開始分析自己創造出來的資料分佈。若它能識別“這些新錯誤是在上一輪修改之後出現的”，可回滾並重新檢查原始假設；若未建立因果關係，就可能繼續將新錯誤視為獨立問題，一個接一個修補。此時每一步區域性操作都有依據，但整條任務軌跡已偏離原始問題。因此長 Agent 的可靠性不能只看單步正確率，更關鍵的是錯誤進入環境後系統能否檢測、歸因和恢復。Git diff 可告知模型哪些變化剛發生，測試可驗證行為是否被破壞，checkpoint 和 rollback 可限制錯誤擴散，獨立 evaluator 可提供額外校驗。這些元件的作用本質上是給 Agent 增加閉環糾錯能力。

結語：Benchmark 缺的是軌跡可靠性

許多 benchmark 測的是給定初始化環境後模型能否完成任務，而真實 Agent 多了一層困難：環境會隨模型自身動作不斷變化。因此兩個最終通過率接近的模型，真實體驗可能完全不同：一個前期判斷準但走錯後不斷沿錯誤路徑修補；另一個單步未必更強，卻能更快發現修改製造的新問題並回滾重選路徑。只看終點難以區分這兩種行為。若 Agent 任務繼續拉長，更有意義的指標將變成：compaction 後關鍵狀態保留多少、錯誤修改後能否找到引入錯誤的步驟、工具呼叫增加時內部任務狀態是否與真實環境一致、發生偏航後恢復代價多大。這些指標測的不是單次 response 的聰明程度，而是一條 trajectory 能否保持可控。Anthropic 最近暴露的問題落在不同層面，集中出現後，Claude 的技術瓶頸正從“能否解出某道題”轉向“當任務執行數小時、經過幾十輪工具呼叫、多次狀態壓縮和程式碼修改後，系統能否維持一份可信的當前世界”。模型能力增長提高每一步判斷的上限，而長 Agent 能否穩定工作，越來越取決於狀態是否清楚、動作是否可驗證、錯誤是否可回滾。