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

新智元報(bào)道

編輯：元宇

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

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

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

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

上下文越長，模型越蠢。

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

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

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

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

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

但百萬Token≠百萬有效Token。

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

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

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

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

上下文越長

AI越蠢

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

100萬Token聽起來很多。

一個(gè)中型代碼庫，連文檔帶源碼，可能也就幾十萬Token。理論上你可以把整個(gè)項(xiàng)目塞進(jìn)去，然后隨便問。

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

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

這就是context rot的機(jī)制：模型被迫同時(shí)「記住」太多不相關(guān)的東西，沒法集中精力處理眼前的任務(wù)。

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

的確如此。

信息過載導(dǎo)致注意力稀釋，這與能力無關(guān)，是帶寬問題。

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

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

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

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

每一輪對話都是岔路口

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

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

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

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

官方博客里有一個(gè)很精準(zhǔn)的判斷：與其糾正，不如回退。

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

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

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

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

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

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

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

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

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

省事，但有損。

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

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

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

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

第五條，Subagents。

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

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

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

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

這五個(gè)動(dòng)作里，最容易被誤解的就是subagents。

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

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

官方文檔明確寫道：每個(gè)subagent都運(yùn)行在自己的上下文窗口中。

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

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

Anthropic內(nèi)部用的判斷標(biāo)準(zhǔn)也很簡單：

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

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

博客里給了三個(gè)典型場景：

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

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

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

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

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

啟動(dòng)一個(gè)Subagents，根據(jù)以下規(guī)范文件驗(yàn)證此項(xiàng)工作的結(jié)果；

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

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

警惕自動(dòng)壓縮的翻車時(shí)刻

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

什么時(shí)候翻車？當(dāng)模型無法預(yù)測你接下來要干什么的時(shí)候。

博客舉了一個(gè)例子：

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

但因?yàn)檎麄€(gè)會(huì)話主要圍繞調(diào)試展開，那個(gè)warning只是中途順帶看到的一眼，壓縮的時(shí)候已經(jīng)被丟掉了。

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

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

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

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

用最清醒的時(shí)候做壓縮，而不是等到最糊涂的時(shí)候被動(dòng)挨打。

說到底，自動(dòng)壓縮不是不能用，是不能盲信。

五條路

一個(gè)急救包

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

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

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

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

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

五種場景，五個(gè)工具，選對了上下文干凈，選錯(cuò)了模型變蠢。

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

百萬上下文的另一面

是百萬token的賬單

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

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

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

/usage是干什么的？

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

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

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

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

100萬上下文聽起來很美，但token不是免費(fèi)的。

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

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

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

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

提示詞工程之后

是上下文工程

退一步看全局。

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

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

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

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

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

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

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

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

參考資料：

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