Anthropic 的 Claude 模型在程式碼生成和代理可靠性方面面臨技術挑戰

Anthropic 近期面臨 Claude 模型的多重技術挑戰。代碼生成因水印嵌入約束導致自由度下降；Sonnet 5 的 adaptive thinking 機制使同一模型可調節不同計算投入，模糊了產品線能力邊界；1M 上下文看似充裕，但長 Agent 對話中模型實際僅能有效使用約 20%-30%，之後便出現狀態混亂和遺漏；上下文壓縮時難以區分哪些資訊仍有效，臨時假設可能被誤轉為事實；Agent 主動修改環境後，模型開始分析自己創造的新錯誤而非原始問題。文章指出長 Agent 的可靠性越來越取決於狀態清晰度、動作可驗證性和錯誤可回滾能力，而非單純的模型單步表現。

文章作者、來源：雷鋒網

比模型跑分下降更麻煩的，是模型仍在升級，但用戶卻開始覺得越來越難用。

Anthropic 最近就有點這個味道。

這幾天 X 上有一則貼文，將 Claude 近期幾種典型的不滿集中呈現：文本和代碼開始被加入機器可讀標記，Sonnet 5 的實際體驗未能跟上模型升級的聲勢，Fable 5 售價更高，卻很難讓人明顯感受到它比 Opus 5 強在哪裡；還有一個更刺眼的回饋是，Fable 5 的上下文僅使用了約 20%–30%，後續能力便開始下滑。

這幾件事表面上沒什麼關係，一個像生成機制問題，一個像模型能力問題，一個像定價問題，還有一個乾脆像長上下文出了毛病。

但放到 Claude 現在的技術棧裡看，它們其實分別卡在 5 個很具體的位置：模型怎麼生成，推理時願意花多少計算，不同模型為什麼越來越難分層，長上下文為什麼沒裝滿就開始失效，以及實驗裡的能力為什麼到了真實 Agent 任務裡經常打折。

因此，Anthropic 最近的問題，可能不是簡單的「模型退步了」。更像是 Claude 越來越強之後，生成、計算、上下文和 Agent 運行時之間開始互相拖後腿了。

01

機器可讀標記放在普通文本裡，技術難點是既留下穩定信號，又盡量不改變生成質量。到了代碼，這個問題會明顯變難，因為自然語言和代碼的 token 分佈並不一樣。

論文：https://arxiv.org/pdf/2301.10226

自然語言經常存在多個語義接近的候選。同一個意思可以換詞、調語序，模型在很多位置擁有一定生成冗餘。文本水印的一類常見思路，就是利用這種冗餘，在多個可接受 token 之間輕微改變採樣概率，累積足夠長以後留下統計規律。

代碼卻有大量低熵位置。變量聲明之後，後續引用幾乎只能使用同一個名字；JSON 的欄位、引號和括號受嚴格結構約束；函數參數必須符合介面；路徑、正則、SQL、Shell 命令裡，一個 token 發生變化就可能直接改變行為。

從概率分佈看，這些位置往往非常尖銳。正確 token 占據很高概率，其他候選不是另一種表達，而可能就是錯誤。因此，代碼水印面對的核心限制其實是編碼容量。

如果一個位置只有一種合理輸出，它幾乎沒有空間承載額外信號；如果系統只在高熵位置嵌入標記，又會遇到代碼短、結構化 token 比例高、可利用位置不足的問題。

因此，檢測強度、生成質量和抗修改能力之間會形成直接取捨：信號太弱難以檢測，約束太強可能影響正確生成，而經過格式化、局部改寫後仍想保留檢測能力，又需要更高的信號冗餘。

Anthropic 並未公開 Claude 文本標記如何具體改變取樣，因此無法將 Claude Code 的品質變化直接歸因於某一種水印算法。

這裡能確定的是另一個變化：代碼生成正同時承擔越來越多的約束。除了語義和執行正確性，它還可能需要服從工具協議、結構化格式、安全規則和來源標記，而代碼本身能夠吸收這些額外約束的自由度遠小於自然語言。

02

Sonnet 5 的 adaptive thinking 帶來的變化，並不只是讓模型多想一會。

以前談論 Sonnet、Opus、Fable，很容易將它們理解為幾個固定能力點。現在加入 effort 以後，同一個模型可以落在不同的 test-time compute 區間裡，型號本身已經不能完整代表一次請求實際投入了多少能力。

參考連結：https://platform.claude.com/docs/en/build-with-claude/effort

這種變化在 Coding Agent 中尤其明顯。Claude 在面對一個 bug 時，不僅需要生成修改方案，還需要決定讀取哪些文件、追蹤哪條調用鏈、保留幾個候選假設、是否運行測試、是否繼續檢查依賴，以及何時認為證據已經足夠。

這些動作可以視為一棵搜尋樹。較低的計算投入意味著更早剪枝、更快形成判斷；較高的投入允許模型繼續搜尋和驗證，降低在證據不足時直接執行動作的機率。

參考連結：https://platform.claude.com/docs/en/build-with-claude/effort

因此 effort 調節的不是單純的 thinking 長度，而是一次 Agent 任務允許展開多大的搜索範圍。這會直接改變 Anthropic 的模型分層。

如果一個普通 coding 任務對 Opus 已經不難，提高 effort 以後，Opus 很可能快速進入性能平台區。Fable 即使擁有更強的基礎模型，也沒有多少剩餘難度可以轉化成明顯體驗差。

用戶卻從請求開始就要支付型號之間的價格差。於是 Fable 更容易體現價值的，不會是常規代碼解釋、小規模重構或者普通 debugging，而是陌生代碼庫、多階段規劃、跨工具操作、長時間自主執行，以及錯誤發生以後仍需要恢復的任務。

參考連結：https://www.anthropic.com/news/claude-opus-5

這意味著高階模型出售的東西正在發生變化。它賣的不再只是「這一輪答案更強」，而是更複雜軌跡裡的額外可靠性。

問題在於，這種優勢需要任務足夠長才能展開，而任務一旦拉長，模型能力就不再是唯一決定因素，上下文狀態開始進入核心位置。

03

看到 1M context，很容易把它理解成一塊巨大的工作記憶，因此當 Claude 只使用 200K 或 300K token 就開始遺漏、反覆甚至出現狀態混亂時，會顯得非常反直覺。

但 context window 衡量的是容量，不是狀態一致性。長 Agent 會話也不是一篇靜態文檔，而是一份不斷追加的執行歷史。

參考連結：https://platform.claude.com/docs/en/build-with-claude/context-windows

一個文件可能先後被修改幾次；某個 bug 最初被判斷成快取問題，後來發現來自併發；一個測試可能先失敗、隨後通過，又因為新的修改重新失敗。舊內容不會隨著狀態變化自動刪除，新內容只是繼續追加在後面。

這裡出現的問題已經不只是 retrieval。模型不仅要找到和當前任務相關的信息，還要判斷這些信息現在是否仍然有效。

舊版函數和新版函數高度相似，舊測試日誌和新測試日誌包含大量相同 token，已被推翻的分析也可能與當前問題在語義上高度相關。Attention 找到這些內容並不困難，困難的是確定它們之間的覆蓋關係。

資料庫可以依靠版本號、更新時間、事務和顯式欄位來維護 current state，自然語言 context 通常沒有這種結構。它更接近 append-only log，模型需要自行從事件順序中恢復現在的世界是什麼樣子。

參考連結：https://platform.claude.com/docs/en/build-with-claude/context-windows

因此，長上下文的複雜度並不會與 token 占用比例簡單對應。250K token 的靜態文檔可能比 250K token 的 Agent 歷史容易處理得多，因為後者包含大量被修改過的物件、階段性判斷、工具結果和已經失效的狀態。

Thinking history 會進一步增加這種複雜度。會話裡保存的不只是「發生過什麼」，還可能包含「當時為什麼這麼判斷」。如果早期 reasoning 建立在一個後來被推翻的假設上，那段推理仍然可能因為和當前問題高度相關而繼續參與後續判斷。

所以 1M context 的真正限制不只是能放多少資訊，而是當同一個物件出現越來越多歷史版本以後，模型還能不能穩定恢復當前版本。

04

當 context 繼續增長，compaction 看起來像一個自然辦法：把舊歷史壓短，再繼續執行。但 Agent 場景裡的 compaction 和普通摘要並不是一回事。

在摘要文章時遺漏一個例子，通常僅影響資訊的完整性；但在壓縮 Agent 軌跡時，遺漏一個仍然有效的限制條件，後續的執行路徑可能直接改變。

參考連結：https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools

因為 compaction 必須解決的不是「哪些內容重要」，而是「哪些內容現在還算數」。一段歷史裡可能同時存在已經完成的任務、後來被推翻的判斷、當前仍然成立的介面約束、過期測試結果和臨時 workaround。壓縮器需要把這些時間狀態重新整理成一個能夠供下一轮繼續工作的表示。

如果「目前懷疑問題來自緩存」被壓縮為「問題來自緩存」，臨時假設就變成了事實；如果一個已經廢棄的方案仍然進入摘要，後面的 Agent 可能重新沿舊路徑執行；如果某項關鍵限制沒有進入摘要，它之後甚至不會再被模型看到。

因此，compaction 的關鍵指標不是壓縮率，而是狀態保真。這也是 Git、測試、任務文件、memory 和結構化 handoff 在長時 Agent 中越來越重要的原因。

它們不是單純增加模型能看到的資訊，而是在把一些需要長期成立的狀態，從自然語言歷史中移到外部系統。Git 明確當前程式碼版本，測試給出可驗證結果，任務檔案記錄完成情況，結構化狀態區分當前結論和歷史嘗試。

上下文可以保留豐富歷史，但不能長期承擔全部狀態管理職責。

參考連結：https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

05

前面的幾個問題仍然可以理解成模型如何處理輸入。Agent 再往前一步，因為它會主動修改環境。

在普通聊天中，模型答錯一次，錯誤通常只停留在輸出文本中。Agent 可以修改代碼、執行命令、安裝依賴、調整配置，並讀取這些操作產生的新結果。

於是錯誤不再只是判斷錯誤，還會變成環境變化。假設 Claude 把一個 bug 錯判成快取問題，於是修改快取邏輯、重試機制和幾個呼叫點。測試隨後出現一批新的異常。

這些異常是真實的，但它們並不是原始 bug 自然產生的，而是上一輪修改製造出來的。這會讓 Agent 進入一種很特殊的失敗模式：模型開始分析自己創造出來的數據分佈。

參考連結：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

如果它能識別「這些新錯誤是在上一輪修改之後出現的」，還可以回滾並重新檢查原始假設；如果沒有建立這層因果關係，就可能繼續把新錯誤視為獨立問題，一個接一個修補。

此時每一步局部操作都可能有依據，但整條任務軌跡已經偏離原來的問題。所以長 Agent 的可靠性不能只看單步正確率。更關鍵的是錯誤進入環境以後，系統能不能檢測、歸因和恢復。

Git diff 可以告訴模型哪些變化剛剛發生，測試可以驗證某項行為有沒有被破壞，checkpoint 和 rollback 可以限制錯誤擴散，獨立 evaluator 則可以在模型自己的解釋之外提供額外校驗。

這些組件的作用，本質上是在給 Agent 增加閉環糾錯能力。

參考連結：https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

06

許多 benchmark 測試的是：給模型一個已初始化的環境，它能否完成任務。真實的 Agent 多了一層困難：環境會隨著模型自身的動作不斷變化。因此，兩個最終通過率相近的模型，實際體驗可能完全不同。

一個模型可能前期判斷很準，但一旦走錯就不斷沿錯誤路徑修補；另一個模型單步未必明顯更強，卻能更快發現某次修改製造了新問題，然後回滾重新選擇路徑。

只看終點，很難區分這兩種行為。如果 Agent 任務繼續拉長，更有意義的指標會變成 compaction 之後關鍵狀態保留了多少、錯誤修改發生以後能否找到引入錯誤的步驟、隨著工具調用增加內部任務狀態是否繼續和真實環境一致，以及發生偏航之後需要付出多大代價才能恢復。

這些指標測的不是一次 response 有多聰明，而是一條 trajectory 能不能保持可控。

綜上所述，Anthropic 最近暴露出來的幾類問題，其實落在不同層面。這些問題集中出現以後，Claude 的技術瓶頸也開始發生變化。

過去更像是在問模型能否解出某一道題，現在更難的是另一件事：當任務運行數小時、經過數十輪工具調用、幾次狀態壓縮和多次代碼修改以後，系統還能不能維持一份可信的當前世界。

模型能力持續增長，只能提升每一步判斷的上限。而長 Agent 能否穩定運作，越來越取決於另一套能力：狀態是否清晰，動作是否可驗證，錯誤是否可回滾。