百萬Token白燒？Claude官方下場：5招治好上下文腐爛

新智元報道

編輯：元宇

【新智元導讀】給了100萬token，現(xiàn)在卻手把手教你怎么刪記錄！Anthropic官方承認：塞太多東西，Claude就會變蠢。面對失控的「上下文腐爛」，Anthropic連夜甩出5招救命指南。

Anthropic自己戳破了百萬上下文神話？

https://claude.com/blog/using-claude-code-session-management-and-1m-context

近日，Anthropic一篇關于「如何管理百萬上下文」的博客中再次提到了「上下文腐爛」（context rot）的問題，簡單說就是：

上下文越長，模型越蠢。

Anthropic解釋道，上下文窗口是指模型在生成下一條回復時能夠「看到」的全部內(nèi)容，它包括你的系統(tǒng)提示、迄今為止的對話內(nèi)容、每一次工具調(diào)用及其輸出，以及所有已讀取的文件。

目前，Claude Code的上下文窗口為一百萬個token。

但上下文并非越長越好。模型的注意力被分散到更多token上，更早的、已經(jīng)不相關的內(nèi)容會開始干擾當前任務，導致表現(xiàn)下降，這就是「上下文腐爛」。

這并非社區(qū)自造的概念，而是出自Anthropic官方博客。

早在今年2月Sonnet 4.6發(fā)布時，公告里就寫明了：Sonnet 4.6提供了測試版百萬token上下文窗口。

但百萬Token≠百萬有效Token。

你往對話里塞的每一條消息、每一次文件讀取、每一輪工具調(diào)用，都在稀釋模型的注意力。

早期那些已經(jīng)不相關的內(nèi)容不會自動消失，它們會像噪音一樣持續(xù)干擾當前任務。

提出問題后，Anthropic通過這篇博客給出了一套完整的管理方法。

先告訴你「你的對話在腐爛」，然后再手把手教你怎么治。

上下文越長

AI越蠢

先把「上下文腐爛」的機制拆開看。

100萬Token聽起來很多。

一個中型代碼庫，連文檔帶源碼，可能也就幾十萬Token。理論上你可以把整個項目塞進去，然后隨便問。

但模型的注意力是有限資源。

你兩小時前讀的那個配置文件、一小時前調(diào)試失敗的那段日志、半小時前探索的一條死胡同，全都還在窗口里，全都在搶模型的注意力。

這就是context rot的機制：模型被迫同時「記住」太多不相關的東西，沒法集中精力處理眼前的任務。

也許你會覺得，這不就和人類開會開久了走神是一個道理嘛。

的確如此。

信息過載導致注意力稀釋，這與能力無關，是帶寬問題。

更要命的是，當上下文快要撐到100萬Token上限時，系統(tǒng)會自動觸發(fā)「壓縮」（compaction）：

即把整段對話總結(jié)成一個更短的摘要，然后在新窗口里繼續(xù)工作。

這聽起來很智能，但自動壓縮發(fā)生的那一刻，恰恰是上下文最長、模型表現(xiàn)最差的時候。

用最蠢的狀態(tài)去做最關鍵的總結(jié)，這事兒本身就很難靠譜。

每一輪對話都是岔路口

Anthropic在博客里把每一次對話交互定義為一個決策節(jié)點。

每一輪交互結(jié)束后，你其實站在一個岔路口，不是只有「繼續(xù)聊」這一條路。

第一條：Continue。在同一會話中發(fā)送另一條消息，直接繼續(xù)聊。上下文還相關，沒必要折騰。這是最自然的選擇，大多數(shù)時候也確實夠用。

第二條：/rewind。連按兩下Esc，跳回之前某條消息，從那里重新來。

官方博客里有一個很精準的判斷：與其糾正，不如回退。

回退（Rewind）通常是更佳的修正方式。

比如Claude讀了五個文件，試了一種方法沒成功，你的本能反應是說「這個不行，換個方法」。

但這樣做的問題是，那次失敗嘗試的全部中間過程還留在上下文里，繼續(xù)污染后續(xù)判斷。

更聰明的做法是rewind到讀完文件那個節(jié)點，帶著新信息重新發(fā)一條更精確的指令：別用方案A，foo模塊沒暴露那個接口，直接走B。

有用的文件讀取保留了，失敗的嘗試丟掉了。上下文干干凈凈。

你也可以讓Claude總結(jié)它學到的內(nèi)容并創(chuàng)建一條交接信息。這有點像未來的Claude給過去的自己留了一封信：這條路我試過了，走不通。

第三條：/clear。開啟一個新會話，附帶一段簡要說明：之前做了什么、現(xiàn)在要干什么、哪些文件相關。

好處是零腐爛，上下文完全由你控制。壞處是費事，所有背景都得你自己寫。

第四條：/compact。讓模型總結(jié)當前對話，用摘要替換掉原來的歷史記錄。

省事，但有損。

你可以附上引導指令：/compact focus on the auth refactor, drop the test debugging（聚焦認證重構，刪掉測試調(diào)試。）

讓它知道什么該留什么該扔，而不是去猜。

/clear和/compact看起來相似，但行為截然不同：

/compact由模型決定什么重要，你省心但可能丟關鍵信息，而/clear由你自己寫下關鍵內(nèi)容，費事但精確。

第五條，Subagents。

把一塊工作交給一個擁有獨立上下文的子智能體，干完活只把結(jié)論帶回來。

當你知道接下來的任務會產(chǎn)生大量中間輸出，但你只需要最終結(jié)論時，subagent是最干凈的方案。

它拿到一個全新的獨立上下文窗口，在里面完成所有臟活，中間過程全部留在子窗口里，最后只有一份結(jié)論帶回主會話。

Subagents：你的一次性調(diào)查員

這五個動作里，最容易被誤解的就是subagents。

很多人一聽「子智能體」就往「多智能體協(xié)作」上聯(lián)想：團隊分工、并行處理、AI員工開會討論。

但Anthropic這篇博客里講的subagents，核心價值只有一個：上下文隔離。

官方文檔明確寫道：每個subagent都運行在自己的上下文窗口中。

它可以讀大量文件、做大量搜索、跑完整個調(diào)查流程。但最終，只有摘要和一小段元數(shù)據(jù)會回傳給主會話。

那些海量的中間過程，全部留在子智能體的一次性上下文里。你的主會話不會被這些噪聲污染。

Anthropic內(nèi)部用的判斷標準也很簡單：

我之后還需要這些工具輸出本身嗎，還是只需要最終結(jié)論？

如果答案是后者，就交給subagent。

博客里給了三個典型場景：

讓subagent基于規(guī)格文件驗證工作結(jié)果；讓subagent去讀另一個代碼庫，總結(jié)它的認證流程，然后你自己來實現(xiàn)；讓subagent根據(jù)你的git改動去寫文檔。

這三個場景有一個共同點：過程很重，結(jié)論很輕。

所以subagent的本質(zhì)不是你的同事，和你在一塊干活，更像是你的「一次性調(diào)查員」。

它的工作簿在任務結(jié)束后就可以扔掉，你只需要拿走最后那頁報告。

雖然Claude Code會自動調(diào)用Subagents，但你也可以給它更明確的執(zhí)行指令，比如：

啟動一個Subagents，根據(jù)以下規(guī)范文件驗證此項工作的結(jié)果；

派生一個Subagents去閱讀另一個代碼庫，并總結(jié)其身份驗證流程的實現(xiàn)方式，然后你自己以相同的方式實現(xiàn)它；

派生一個Subagents，根據(jù)我的Git變更來編寫此功能的文檔。

警惕自動壓縮的翻車時刻

Anthropic在博客里坦承了一個很多開發(fā)者已經(jīng)踩過的坑：自動壓縮（compaction）翻車。

什么時候翻車？當模型無法預測你接下來要干什么的時候。

博客舉了一個例子：

你做了一次很長的調(diào)試會話，自動壓縮觸發(fā)了，模型把整個排查過程總結(jié)了一遍。然后你突然說：「現(xiàn)在修一下bar.ts里那個warning。」

但因為整個會話主要圍繞調(diào)試展開，那個warning只是中途順帶看到的一眼，壓縮的時候已經(jīng)被丟掉了。

這事棘手在哪？觸發(fā)自動壓縮的那一刻，恰恰是上下文最長、模型表現(xiàn)最打折的時候。

你讓一個已經(jīng)「走神」的模型來決定什么信息重要、什么可以丟掉。

好在百萬Token窗口給了一個緩沖區(qū)。

你不用等到自動觸發(fā)，可以提前主動/compact，并附上說明：接下來要做什么、哪些信息必須保留。

用最清醒的時候做壓縮，而不是等到最糊涂的時候被動挨打。

說到底，自動壓縮不是不能用，是不能盲信。

五條路

一個急救包

雖然最自然的做法就是繼續(xù)下去，但另外四個選項可用于幫助你管理上下文。

這五條路拼在一起，本質(zhì)上就是一套防治「上下文腐爛」的急救包。

Anthropic官方示意圖：五種上下文管理動作，從左到右保留的舊上下文越來越多

官方博客在文末放了一張決策表，按場景匹配工具：

每一次回車，都是一次上下文決策。

五種場景，五個工具，選對了上下文干凈，選錯了模型變蠢。

因此，每一輪交互之后，都該花一秒鐘想想：我的上下文還干凈嗎？接下來該走哪條路？

百萬上下文的另一面

是百萬token的賬單

除了管上下文質(zhì)量，Anthropic這次還做了另一件事：

讓開發(fā)者看見自己的消耗。

博客開頭就說了，/usage這個新命令的推出，「來自我們和客戶進行的多次交流」。

/usage是干什么的？

根據(jù)Claude Code官方命令文檔，它的作用是「顯示套餐使用上限和速率限制狀態(tài)」。

注意，這不是一個上下文管理工具。

它不壓縮、不回退、不清理，只做一件事：讓你看見自己用了多少，還剩多少，有沒有撞上限流。

但這恰恰是開發(fā)者最焦慮的事。

100萬上下文聽起來很美，但token不是免費的。

一個長會話跑下來，你到底消耗了多少配額？自動壓縮會不會在你不知情的情況下觸發(fā)，丟掉關鍵信息？你離速率限制還有多遠？

以前這些問題沒有答案，現(xiàn)在Anthropic給了一個透明窗口。

這個功能很小，但表明Anthropic已經(jīng)意識到，百萬上下文時代，「用得起」和「用得好」是兩個必須同時解決的問題。

光給能力不給可見性，開發(fā)者遲早會踩坑然后流失。

提示詞工程之后

是上下文工程

退一步看全局。

今年2月，Anthropic發(fā)布Sonnet 4.6，公告里確認了100萬token上下文窗口（beta）。

那篇公告解決的是「能不能」的問題：模型能不能撐住這么長的上下文。

用戶反饋也很正面：它在改代碼前更能有效讀取上下文了。

4月15日這篇博客，解決的是「怎么用」的問題。它直接承認了現(xiàn)實局限，然后給出一套系統(tǒng)化的管理方法。

兩步合在一起，構成了一個完整的閉環(huán)：先給你武器，再教你怎么用不傷到自己的錢包。

Prompt engineering這幾年被講爛了。但真正決定AI編程天花板的，可能是下一個詞：context engineering（上下文工程）。

怎么喂上下文、什么時候清理、哪些信息該隔離、哪些該保留，這些問題以前靠直覺，現(xiàn)在Anthropic開始給方法論了。

上下文工程，正在成為AI編程時代的必修課。

參考資料：

https://claude.com/blog/using-claude-code-session-management-and-1m-context