1. 三條新聞背后其實(shí)是同一件事在三個(gè)方向上的推進(jìn)2026年10月2日這天AI圈子里同時(shí)冒出來三條看起來八竿子打不著的消息加州那邊給OpenAI遞了傳票Claude Code宣布開放Mod化能力Meta在推一個(gè)讓模型自己改寫上下文的方案。單獨(dú)看每一條都能寫一篇分析但把它們擺在一起看你會(huì)發(fā)現(xiàn)它們指向的是同一個(gè)趨勢——AI系統(tǒng)正在從一個(gè)封閉的黑盒產(chǎn)品變成一個(gè)可被外部約束、可被第三方擴(kuò)展、可被自己迭代的基礎(chǔ)設(shè)施。這個(gè)判斷不是硬湊的。傳票代表的是外部監(jiān)管力量開始要求AI公司交出內(nèi)部運(yùn)作的細(xì)節(jié)這是可被約束Claude Code的Mod化代表的是工具鏈開始允許開發(fā)者往里面插自己的東西這是可被擴(kuò)展Meta讓模型改寫自己的上下文代表的是模型開始具備對(duì)自身輸入做二次加工的能力這是可被自己迭代。三個(gè)方向合起來就是AI從產(chǎn)品走向基礎(chǔ)設(shè)施的完整路徑。我寫這篇東西不是要復(fù)述新聞而是想把這幾個(gè)事件里真正值得技術(shù)人員關(guān)注的點(diǎn)拆開講清楚。尤其是Claude Code的Mod化和Meta的上下文改寫這兩個(gè)是能直接落到你日常開發(fā)工作里的東西。至于傳票那件事我會(huì)從它對(duì)做AI應(yīng)用的團(tuán)隊(duì)意味著什么這個(gè)角度聊而不是去討論法律層面的東西——那不是我們該操心的我們該操心的是合規(guī)成本會(huì)不會(huì)傳導(dǎo)到API價(jià)格和調(diào)用限制上。這篇文章適合幾類人看正在用Claude Code或者類似AI編程工具的開發(fā)者、在做Agent架構(gòu)設(shè)計(jì)的技術(shù)負(fù)責(zé)人、以及關(guān)心AI工具鏈未來走向的產(chǎn)品經(jīng)理。如果你只是想知道今天發(fā)生了什么那看新聞標(biāo)題就夠了但如果你想搞清楚這些變化會(huì)怎么影響我下周要寫的代碼那接著往下看。2. Claude Code開放Mod化為什么這件事比看起來重要2.1 從只能用官方功能到可以自己插東西Claude Code剛出來的時(shí)候它的定位很明確一個(gè)命令行里的AI編程助手你給它指令它幫你改代碼、跑命令、查文件。功能很強(qiáng)但邊界也很清楚——你只能用Anthropic官方提供的那些能力想加點(diǎn)自己的東西沒門。Mod化的開放改變了這個(gè)局面。所謂Mod化本質(zhì)上就是開放了一套擴(kuò)展接口允許第三方開發(fā)者往Claude Code的執(zhí)行流程里插入自定義邏輯。這個(gè)邏輯可以是一個(gè)新的工具調(diào)用、可以是一段預(yù)處理腳本、也可以是一個(gè)對(duì)輸出結(jié)果的二次加工層。我舉個(gè)具體的場景你就明白了。假設(shè)你的團(tuán)隊(duì)有一套內(nèi)部的代碼規(guī)范檢查工具以前你用Claude Code生成代碼之后得手動(dòng)跑一遍檢查工具發(fā)現(xiàn)不符合規(guī)范再讓Claude改。Mod化之后你可以寫一個(gè)Mod讓Claude Code在生成代碼之后自動(dòng)調(diào)用你的檢查工具把不合規(guī)的地方直接反饋給模型讓它自己修。整個(gè)過程不需要你手動(dòng)介入。這就是Mod化的價(jià)值它把Claude Code從一個(gè)獨(dú)立的工具變成了一個(gè)可以被集成進(jìn)你現(xiàn)有工作流的組件。2.2 Mod機(jī)制的技術(shù)實(shí)現(xiàn)邏輯雖然官方還沒有放出完整的Mod開發(fā)文檔但從目前透露出來的信息和同類工具的設(shè)計(jì)慣例來看Mod機(jī)制大概率是這樣運(yùn)作的Claude Code在執(zhí)行任務(wù)時(shí)會(huì)經(jīng)過幾個(gè)固定的階段——接收用戶輸入、規(guī)劃執(zhí)行步驟、調(diào)用工具、生成輸出。Mod化的核心就是在這些階段之間插入鉤子Hook讓外部代碼可以在特定時(shí)機(jī)介入。一個(gè)典型的Mod生命周期大概包含這幾個(gè)部分階段作用典型用途輸入預(yù)處理在模型看到用戶輸入之前做加工注入項(xiàng)目上下文、過濾敏感信息工具注冊向Claude Code注冊自定義工具接入內(nèi)部API、數(shù)據(jù)庫查詢輸出后處理在模型輸出之后做二次加工格式校驗(yàn)、合規(guī)檢查、自動(dòng)提交執(zhí)行攔截在工具調(diào)用前后插入邏輯權(quán)限校驗(yàn)、操作審計(jì)這個(gè)設(shè)計(jì)思路和VS Code的插件系統(tǒng)、Webpack的Loader機(jī)制是一脈相承的。核心思想都是不修改核心代碼通過外部擴(kuò)展來改變行為。注意Mod化開放初期接口大概率不會(huì)很穩(wěn)定。如果你打算基于它做生產(chǎn)級(jí)別的集成建議先做一層適配層把Mod接口和你的業(yè)務(wù)邏輯隔離開這樣官方接口變了你不用重寫全部代碼。2.3 對(duì)國內(nèi)開發(fā)者的實(shí)際影響國內(nèi)用Claude Code的開發(fā)者不少但很多人卡在安裝和配置這一步。Mod化開放之后安裝流程本身不會(huì)變但配置會(huì)多出一個(gè)Mod加載的環(huán)節(jié)。如果你現(xiàn)在還沒把Claude Code跑起來這里簡單說一下關(guān)鍵步驟。首先你需要一個(gè)能正常調(diào)用的API環(huán)境這是前提。然后通過npm安裝Claude Code的命令行工具安裝完成之后用你的憑證做一次登錄驗(yàn)證。驗(yàn)證通過之后你就可以在終端里直接用claude命令喚起它了。Mod化之后你需要在配置文件里額外指定Mod的加載路徑。這個(gè)配置大概率會(huì)放在~/.claude/config.json或者項(xiàng)目根目錄的.clauderc文件里。具體格式等官方文檔出來再確認(rèn)但邏輯上就是告訴Claude Code去哪個(gè)目錄加載Mod。有個(gè)坑提前說一下Mod的加載順序會(huì)影響執(zhí)行結(jié)果。如果兩個(gè)Mod都試圖修改同一段輸出后加載的會(huì)覆蓋先加載的。所以如果你裝了多個(gè)Mod一定要搞清楚它們的執(zhí)行優(yōu)先級(jí)。這個(gè)在官方文檔里可能會(huì)用priority字段來控制數(shù)值越小越先執(zhí)行。2.4 自己寫一個(gè)Mod需要什么準(zhǔn)備寫Mod本質(zhì)上就是寫一個(gè)符合接口規(guī)范的模塊。從目前Claude Code的技術(shù)棧來看它大概率支持TypeScript和JavaScript兩種語言來寫Mod。如果你平時(shí)寫Node.js那上手會(huì)很快。一個(gè)最小的Mod大概長這樣以下是根據(jù)常見插件系統(tǒng)設(shè)計(jì)的推測代碼非官方示例// my-mod/index.ts export interface ModContext { projectPath: string; userInput: string; modelOutput?: string; } export function onBeforeModelCall(ctx: ModContext): ModContext { // 在模型調(diào)用前注入項(xiàng)目信息 ctx.userInput [項(xiàng)目路徑: ${ctx.projectPath}]\n${ctx.userInput}; return ctx; } export function onAfterModelCall(ctx: ModContext): ModContext { // 在模型輸出后做格式檢查 if (ctx.modelOutput ctx.modelOutput.includes(TODO)) { console.warn(輸出中包含未處理的TODO請檢查); } return ctx; }這個(gè)結(jié)構(gòu)很直白導(dǎo)出一組生命周期函數(shù)Claude Code在對(duì)應(yīng)時(shí)機(jī)調(diào)用它們。你可以在函數(shù)里做任何Node.js能做的事情——讀文件、發(fā)HTTP請求、調(diào)數(shù)據(jù)庫都行。寫Mod的時(shí)候有個(gè)經(jīng)驗(yàn)盡量保持Mod的冪等性。也就是說同一個(gè)輸入跑兩次結(jié)果應(yīng)該是一樣的。因?yàn)镃laude Code在某些情況下可能會(huì)重試執(zhí)行流程如果你的Mod有副作用比如每次都往文件里追加內(nèi)容重試的時(shí)候就會(huì)出問題。3. Meta讓模型改寫自己的上下文Agent記憶管理的新思路3.1 上下文窗口不夠用是所有Agent的通病做Agent開發(fā)的人都有一個(gè)共同的痛上下文窗口永遠(yuǎn)不夠用。你給模型塞了系統(tǒng)提示、塞了歷史對(duì)話、塞了工具返回結(jié)果、塞了檢索到的文檔還沒開始干正事呢窗口就滿了。常見的解法是做摘要壓縮——把歷史對(duì)話用另一個(gè)模型總結(jié)成一段短文本然后替換掉原始對(duì)話。這個(gè)方案能用但有個(gè)明顯的問題摘要是有損的你永遠(yuǎn)不知道被壓縮掉的那部分信息里有沒有后面會(huì)用到的關(guān)鍵細(xì)節(jié)。Meta這次提出的方案換了個(gè)思路不讓外部模型來壓縮而是讓模型自己在執(zhí)行任務(wù)的過程中主動(dòng)改寫自己的上下文。模型覺得哪部分信息不重要了就把它刪掉或者精簡覺得哪部分信息需要保留就把它挪到更顯眼的位置。這個(gè)思路的核心洞察是模型自己最清楚它下一步需要什么信息。外部摘要模型不知道你接下來要干什么但正在執(zhí)行任務(wù)的模型知道。所以讓它自己管理上下文理論上比外部壓縮更精準(zhǔn)。3.2 自我上下文改寫的具體機(jī)制從目前公開的信息來看這個(gè)機(jī)制大概包含三個(gè)動(dòng)作第一個(gè)動(dòng)作是標(biāo)記。模型在執(zhí)行過程中會(huì)對(duì)上下文里的每一段內(nèi)容打一個(gè)重要性標(biāo)簽。這個(gè)標(biāo)簽不是靜態(tài)的而是隨著任務(wù)推進(jìn)動(dòng)態(tài)變化的。比如一開始你塞了一段API文檔進(jìn)去模型標(biāo)記為中等重要等它把API調(diào)用寫完了這段文檔的重要性就降到可刪除了。第二個(gè)動(dòng)作是重寫。模型可以對(duì)自己上下文里的內(nèi)容做改寫把長段落壓縮成短句把冗余的示例刪掉把關(guān)鍵信息提取成列表。這個(gè)過程和人類做筆記很像——你看一本書的時(shí)候不會(huì)把整本書背下來而是把關(guān)鍵點(diǎn)記成筆記。第三個(gè)動(dòng)作是重組。模型可以調(diào)整上下文里各段內(nèi)容的順序把當(dāng)前任務(wù)最相關(guān)的信息放到最前面或者最后面。這個(gè)是有講究的因?yàn)槟Ｐ蛯?duì)上下文開頭和結(jié)尾的內(nèi)容注意力更集中中間部分容易被忽略。把關(guān)鍵信息放在首尾能提高它被用到的概率。3.3 和現(xiàn)有Agent記憶方案的對(duì)比現(xiàn)在主流的Agent記憶方案大概有三種全量保留、滑動(dòng)窗口、外部摘要。我把它們和Meta這個(gè)方案放在一起對(duì)比一下方案原理優(yōu)點(diǎn)缺點(diǎn)全量保留所有歷史都塞進(jìn)上下文信息不丟失窗口很快爆掉滑動(dòng)窗口只保留最近N輪對(duì)話實(shí)現(xiàn)簡單早期關(guān)鍵信息丟失外部摘要用另一個(gè)模型壓縮歷史節(jié)省窗口摘要質(zhì)量不可控自我改寫模型自己管理上下文精準(zhǔn)度高實(shí)現(xiàn)復(fù)雜度高自我改寫方案最大的優(yōu)勢是精準(zhǔn)但代價(jià)是復(fù)雜度。模型需要額外花token來做上下文管理這件事而且如果模型判斷失誤把重要信息刪了后面就找不回來了。提示如果你現(xiàn)在在做Agent項(xiàng)目不建議一上來就上自我改寫方案。先用滑動(dòng)窗口加關(guān)鍵信息置頂?shù)姆绞脚芡鞒痰葮I(yè)務(wù)穩(wěn)定了再考慮引入更復(fù)雜的上下文管理機(jī)制。3.4 這個(gè)思路對(duì)Agent架構(gòu)設(shè)計(jì)的啟發(fā)Meta這個(gè)方案給我最大的啟發(fā)不是具體實(shí)現(xiàn)而是它背后的設(shè)計(jì)哲學(xué)把上下文管理從外部工程問題變成模型內(nèi)生能力。以前我們做Agent上下文管理是工程師寫代碼來控制的——什么時(shí)候截?cái)唷⑹裁磿r(shí)候摘要、什么時(shí)候注入都是硬編碼的邏輯。但Meta的思路是這些決策應(yīng)該交給模型自己做因?yàn)槟Ｐ捅裙こ處煾私猱?dāng)前任務(wù)需要什么。這個(gè)思路如果走通了會(huì)改變Agent架構(gòu)的設(shè)計(jì)方式。以后的Agent可能不再需要一個(gè)專門的記憶管理模塊而是模型本身就具備記憶管理能力。工程師要做的只是給模型提供工具和約束具體怎么管理記憶讓模型自己決定。當(dāng)然這個(gè)思路也有風(fēng)險(xiǎn)。模型自己管理上下文意味著你對(duì)上下文的控制力變?nèi)趿?。如果模型判斷失誤你可能很難排查問題出在哪里。所以在實(shí)際落地的時(shí)候建議保留一份完整的上下文日志方便出問題的時(shí)候回溯。4. 加州傳票O(jiān)penAI做AI應(yīng)用的團(tuán)隊(duì)該關(guān)注什么4.1 這件事的本質(zhì)是監(jiān)管開始要細(xì)節(jié)了加州給OpenAI發(fā)傳票這件事從技術(shù)人員的角度看核心信息只有一個(gè)監(jiān)管機(jī)構(gòu)不再滿足于AI公司自己發(fā)布的透明度報(bào)告而是要直接調(diào)取內(nèi)部數(shù)據(jù)。傳票要求提供的東西大概率包括模型訓(xùn)練數(shù)據(jù)的來源、模型評(píng)估的方法、以及模型在特定場景下的表現(xiàn)數(shù)據(jù)。這些東西以前是公司內(nèi)部機(jī)密現(xiàn)在要被外部審查。對(duì)做AI應(yīng)用的團(tuán)隊(duì)來說這件事的直接影響是你依賴的API提供商可能會(huì)因?yàn)楹弦?guī)成本上升而調(diào)整服務(wù)條款或者價(jià)格。這不是危言聳聽合規(guī)是有成本的成本最終會(huì)傳導(dǎo)到下游。4.2 合規(guī)成本會(huì)怎么傳導(dǎo)到開發(fā)者身上傳導(dǎo)路徑大概有三條第一條是API價(jià)格。如果OpenAI需要投入更多資源做合規(guī)這部分成本可能會(huì)體現(xiàn)在API定價(jià)上。雖然短期內(nèi)不太可能大幅漲價(jià)但長期來看價(jià)格下降的速度可能會(huì)放緩。第二條是調(diào)用限制。合規(guī)要求可能會(huì)讓API提供商對(duì)某些類型的調(diào)用做更嚴(yán)格的限制。比如涉及個(gè)人數(shù)據(jù)的處理、涉及自動(dòng)化決策的場景可能會(huì)要求額外的審核或者認(rèn)證。第三條是服務(wù)條款。API的使用條款可能會(huì)變得更細(xì)對(duì)哪些能做、哪些不能做有更明確的規(guī)定。這對(duì)開發(fā)者來說意味著需要花更多時(shí)間讀條款避免踩線。4.3 技術(shù)團(tuán)隊(duì)可以提前做的準(zhǔn)備面對(duì)這種趨勢做AI應(yīng)用的團(tuán)隊(duì)可以提前做幾件事第一把API調(diào)用做一層抽象。不要讓你的業(yè)務(wù)代碼直接依賴某一家API的SDK而是封裝一層自己的接口。這樣如果某家API的服務(wù)條款變了你只需要改適配層不用動(dòng)業(yè)務(wù)代碼。第二保留調(diào)用日志。合規(guī)審查的時(shí)候能拿出完整的調(diào)用記錄是很重要的。日志里至少要包含調(diào)用時(shí)間、調(diào)用參數(shù)、返回結(jié)果、以及調(diào)用的業(yè)務(wù)場景。第三關(guān)注替代方案。不要把所有雞蛋放在一個(gè)籃子里。至少了解兩到三家同類API的接入方式萬一主用API出問題能快速切換。注意這里說的替代方案指的是功能對(duì)等的同類服務(wù)不是讓你去搞什么特殊通道。合規(guī)運(yùn)營是底線不要在這個(gè)問題上動(dòng)腦筋。5. 把三條新聞串起來看AI工具鏈的可擴(kuò)展性競賽5.1 為什么大家都在做可擴(kuò)展Claude Code做Mod化、Meta做上下文自我改寫、OpenAI被要求做透明度——這三件事表面上方向不同但底層邏輯是一致的AI系統(tǒng)正在從封閉產(chǎn)品變成開放平臺(tái)。封閉產(chǎn)品的特點(diǎn)是功能由廠商定義用戶只能用現(xiàn)成的。開放平臺(tái)的特點(diǎn)是核心能力由廠商提供但擴(kuò)展能力由生態(tài)共建。Claude Code的Mod化就是典型的平臺(tái)化思路——Anthropic提供核心的編程能力具體的行業(yè)適配、工作流集成交給第三方開發(fā)者來做。這個(gè)轉(zhuǎn)變的原因很簡單AI編程工具的通用能力已經(jīng)卷到頭了。大家都能生成代碼、都能改bug、都能跑命令功能上拉不開差距。接下來的競爭點(diǎn)在于誰能更好地融入開發(fā)者的實(shí)際工作流。而工作流是千差萬別的靠廠商自己一個(gè)個(gè)適配是不可能的只能開放接口讓生態(tài)來做。5.2 對(duì)開發(fā)者的機(jī)會(huì)在哪里這個(gè)趨勢對(duì)開發(fā)者來說機(jī)會(huì)在于做最后一公里的適配。通用AI工具能解決80%的問題但剩下20%的行業(yè)特定問題需要懂行的人來做適配。比如你是做金融的你知道金融代碼有哪些特殊的合規(guī)要求你可以寫一個(gè)Mod來讓Claude Code生成的代碼自動(dòng)符合這些要求。這個(gè)Mod對(duì)別人可能沒用但對(duì)你的團(tuán)隊(duì)價(jià)值巨大。再比如你是做嵌入式開發(fā)的你知道哪些C語言寫法在嵌入式環(huán)境里是危險(xiǎn)的你可以寫一個(gè)Mod來做實(shí)時(shí)檢查。這種行業(yè)know-how是通用工具廠商不具備的也是你的護(hù)城河。5.3 現(xiàn)在就可以開始準(zhǔn)備的事情如果你想抓住這波機(jī)會(huì)現(xiàn)在可以做幾件事第一把你團(tuán)隊(duì)內(nèi)部的代碼規(guī)范整理成可執(zhí)行的規(guī)則。不管是Mod化還是其他擴(kuò)展機(jī)制前提是你得有明確的規(guī)則。如果規(guī)則只存在于老員工的腦子里那沒法自動(dòng)化。第二學(xué)一點(diǎn)TypeScript。從目前的信息來看Claude Code的Mod大概率用TypeScript寫。TypeScript的接口和類型系統(tǒng)用來定義Mod的生命周期鉤子很合適。如果你只會(huì)Python花幾天時(shí)間過一遍TypeScript的基礎(chǔ)語法夠用了。第三關(guān)注官方文檔的更新。Mod化剛開放文檔肯定不完善但官方會(huì)陸續(xù)補(bǔ)充。建議把Claude Code的官方博客加到RSS里有更新第一時(shí)間知道。6. 實(shí)操層面如果你現(xiàn)在就想動(dòng)手試試6.1 環(huán)境準(zhǔn)備中最容易卡住的幾個(gè)點(diǎn)不管你是想試Claude Code還是想研究Meta的上下文改寫思路第一步都是把環(huán)境跑起來。根據(jù)我自己的經(jīng)驗(yàn)國內(nèi)開發(fā)者最容易卡在三個(gè)地方第一個(gè)是Node.js版本。Claude Code對(duì)Node版本有要求太低跑不起來。建議用nvm裝一個(gè)LTS版本別用系統(tǒng)自帶的舊版本。第二個(gè)是網(wǎng)絡(luò)環(huán)境。這個(gè)不多說反正你得保證能正常訪問npm倉庫和API端點(diǎn)。如果公司網(wǎng)絡(luò)有限制提前找IT開白名單。第三個(gè)是憑證配置。Claude Code需要你登錄才能用登錄方式跟著官方指引走就行。憑證配好之后建議先跑一個(gè)最簡單的命令測試一下比如讓它讀一個(gè)文件然后告訴你文件里有什么。能跑通再往下做。6.2 一個(gè)最小可用的Mod示例假設(shè)你已經(jīng)把Claude Code跑起來了想試試Mod化。下面是一個(gè)最小可用的Mod示例功能是在Claude Code每次生成代碼之后自動(dòng)檢查代碼里有沒有硬編碼的密鑰以下代碼為示意具體接口以官方文檔為準(zhǔn)// secret-checker-mod/index.ts const SECRET_PATTERNS [ /api[_-]?key\s*[:]\s*[][^][]/i, /password\s*[:]\s*[][^][]/i, /token\s*[:]\s*[][^][]/i, ]; export function onAfterModelCall(ctx: { modelOutput?: string }) { if (!ctx.modelOutput) return ctx; for (const pattern of SECRET_PATTERNS) { const match ctx.modelOutput.match(pattern); if (match) { console.warn([SecretChecker] 檢測到可能的硬編碼密鑰: ${match[0]}); // 這里可以進(jìn)一步做自動(dòng)替換或者阻斷 } } return ctx; }這個(gè)Mod的邏輯很簡單在模型輸出之后用正則掃一遍發(fā)現(xiàn)可疑的硬編碼密鑰就告警。你可以根據(jù)自己的需求擴(kuò)展這個(gè)邏輯比如把檢測到的密鑰自動(dòng)替換成環(huán)境變量引用。6.3 調(diào)試Mod的實(shí)用技巧寫Mod最煩的是調(diào)試。因?yàn)镸od是嵌在Claude Code的執(zhí)行流程里的出問題了不好定位。我自己的做法是第一在Mod里加詳細(xì)的日志。每個(gè)生命周期函數(shù)進(jìn)來和出去的時(shí)候都打一條日志把輸入輸出都記下來。這樣出問題的時(shí)候能快速定位是哪個(gè)環(huán)節(jié)出的錯(cuò)。第二先用假數(shù)據(jù)測試。不要一上來就接真實(shí)的Claude Code流程先寫一個(gè)簡單的測試腳本手動(dòng)調(diào)用你的Mod函數(shù)傳一些假數(shù)據(jù)進(jìn)去確認(rèn)邏輯沒問題了再接入。第三做好異常處理。Mod里的代碼如果拋異常可能會(huì)影響Claude Code的正常執(zhí)行。所以每個(gè)可能出錯(cuò)的地方都要包try-catch出錯(cuò)的時(shí)候至少保證不影響主流程。提示Mod的日志建議寫到單獨(dú)的文件里不要和Claude Code自己的日志混在一起?；煸谝黄鸬脑捙挪閱栴}的時(shí)候很難過濾。7. 關(guān)于Agent上下文管理我踩過的一些坑7.1 上下文不是越長越好剛開始做Agent的時(shí)候我總覺得上下文塞得越多模型表現(xiàn)越好。后來發(fā)現(xiàn)完全不是這么回事。上下文太長會(huì)導(dǎo)致兩個(gè)問題一是模型注意力分散關(guān)鍵信息反而被忽略了二是推理成本直線上升響應(yīng)速度變慢。實(shí)測下來上下文長度和任務(wù)完成質(zhì)量的關(guān)系是一條倒U型曲線。太短了信息不夠太長了噪音太多中間有個(gè)最優(yōu)區(qū)間。這個(gè)區(qū)間因任務(wù)而異需要你自己測。7.2 摘要壓縮的時(shí)機(jī)很關(guān)鍵用外部模型做摘要壓縮的時(shí)候時(shí)機(jī)很重要。壓得太早后面需要的信息被壓沒了壓得太晚窗口已經(jīng)快滿了壓縮效果不好。我的經(jīng)驗(yàn)是在上下文使用率達(dá)到70%左右的時(shí)候開始?jí)嚎s。這個(gè)閾值不是固定的你可以根據(jù)任務(wù)的復(fù)雜度和模型的表現(xiàn)來調(diào)整。簡單任務(wù)可以設(shè)高一點(diǎn)復(fù)雜任務(wù)設(shè)低一點(diǎn)。7.3 保留一份原始上下文作為兜底不管用什么上下文管理方案都建議保留一份完整的原始上下文。這份原始上下文不參與模型調(diào)用只用于出問題的時(shí)候回溯。我遇到過好幾次這樣的情況模型突然說我不記得之前提到的那個(gè)配置了然后我去查原始上下文發(fā)現(xiàn)是摘要壓縮的時(shí)候把那段信息壓掉了。有了原始上下文至少能快速定位問題不用從頭復(fù)現(xiàn)。8. 接下來值得盯的幾個(gè)信號(hào)Claude Code的Mod化文檔什么時(shí)候出完整版、Meta的上下文改寫方案有沒有開源實(shí)現(xiàn)、加州那邊的事情會(huì)不會(huì)導(dǎo)致API條款變化——這三個(gè)是我接下來會(huì)重點(diǎn)關(guān)注的。對(duì)普通開發(fā)者來說最實(shí)際的還是Claude Code的Mod化。因?yàn)樗苯雨P(guān)系到你每天寫代碼的方式。如果Mod生態(tài)能起來以后你用Claude Code的體驗(yàn)會(huì)和現(xiàn)在完全不一樣——不再是用一個(gè)通用工具而是用一個(gè)被你自己定制過的工具。Meta那個(gè)方案短期內(nèi)落地到生產(chǎn)環(huán)境的可能性不大但它的思路值得學(xué)。如果你在做Agent項(xiàng)目可以試著在現(xiàn)有架構(gòu)里加一點(diǎn)讓模型自己管理上下文的邏輯哪怕只是讓模型自己決定哪些歷史對(duì)話可以刪效果可能都比硬編碼的滑動(dòng)窗口好。至于傳票那件事我的態(tài)度是關(guān)注但不過度反應(yīng)。合規(guī)是大趨勢但傳導(dǎo)到開發(fā)者層面需要時(shí)間。與其焦慮不如把前面說的那幾件準(zhǔn)備工作做了——抽象API調(diào)用層、保留調(diào)用日志、了解替代方案。這些事不管監(jiān)管怎么變都是該做的。