1. 項目概述1.1 核心需求解析先說結(jié)論這176組實驗的核心結(jié)論其實很反直覺——大家原本以為制約Coding Agent效果的瓶頸是模型本身的代碼能力但UMass團(tuán)隊通過大量對照實驗發(fā)現(xiàn)真正卡脖子的往往是上下文管理。什么叫Coding Agent簡單說就是能自主完成編程任務(wù)的AI智能體它不像普通聊天機(jī)器人那樣問一句答一句而是接收一個較復(fù)雜的開發(fā)任務(wù)后自動規(guī)劃步驟、讀寫文件、執(zhí)行命令、修復(fù)報錯直到最終交付可用代碼。像大家熟悉的Codex CLI、Pi Coding Agent以及各類基于大語言模型的編程助手都屬于這個范疇。那上下文管理又是什么通俗講Agent在執(zhí)行任務(wù)過程中會不斷產(chǎn)生和積累信息用戶給的初始需求、自己讀過的代碼文件內(nèi)容、搜索到的API文檔、執(zhí)行命令后的報錯輸出、自己剛剛寫出的代碼塊……這些信息合在一起就是“上下文”。上下文管理就是決定哪些信息該保留、哪些該丟棄、以什么順序組織、如何防止遺忘和混淆的過程。我之所以對這個實驗特別關(guān)注是因為過去一年我自己深度使用過多個Coding Agent踩過的坑幾乎全部集中在“TA忘了”“TA記混了”這一類問題上。模型能力當(dāng)然有差異但很多時候同一個模型在上下文管理得當(dāng)與失控兩種狀態(tài)下表現(xiàn)差距大到像兩個產(chǎn)品。這篇文章就把這176組實驗的關(guān)鍵發(fā)現(xiàn)、背后的技術(shù)邏輯以及我在實操中驗證過的上下文管理方案完整拆一遍。1.2 實驗設(shè)計與影響范圍我仔細(xì)看了UMass的這組實驗設(shè)計。整個過程覆蓋了176組對照測試涉及不同模型、不同任務(wù)類型、不同上下文管理策略的交叉組合。實驗任務(wù)涵蓋了代碼生成、Bug修復(fù)、測試補(bǔ)全、跨文件重構(gòu)、遺留代碼庫維護(hù)等常見開發(fā)場景而這些場景恰恰是最容易暴露上下文問題的任務(wù)周期長、涉及文件多、信息鏈條長。實驗的影響范圍遠(yuǎn)超一般benchmark的意義它揭示了三個層面的真相第一上下文管理不是少數(shù)場景的邊緣問題而是Coding Agent任務(wù)失敗的核心原因之一。第二上下文管理能力與模型參數(shù)規(guī)模并非嚴(yán)格正相關(guān)有些中小模型憑借更優(yōu)的上下文調(diào)度策略在特定任務(wù)上反超大模型。第三上下文管理的優(yōu)化空間極大甚至可以說在現(xiàn)有模型能力框架下做好上下文管理就是性價比最高的提升手段。這些結(jié)論對實際開發(fā)者的直接價值是什么一是選型時不只看模型跑分還要看Agent框架的上下文策略二是在使用Agent時我們可以通過調(diào)整提示詞結(jié)構(gòu)和任務(wù)拆分方式主動改善上下文質(zhì)量三是在自研Agent時應(yīng)該把上下文管理當(dāng)作一等公民來設(shè)計而不是事后補(bǔ)救。2. 上下文管理為何成為核心瓶頸2.1 Agent工作模式下的上下文壓力要真正理解“上下文管理是瓶頸”先要理解Coding Agent的運(yùn)行模式和普通聊天有著本質(zhì)差異。普通聊天場景中上下文就是一個對話歷史列表模型每次回復(fù)前把所有歷史消息塞給模型。即使上下文超長導(dǎo)致效果變差影響范圍也只是一次對話的質(zhì)量。Coding Agent完全不同它會主動發(fā)起多輪工具調(diào)用每輪調(diào)用都會產(chǎn)生新的信息增量而這些增量又會成為下一輪決策的依據(jù)。比如Agent要完成“給登錄模塊加驗證碼功能”這個任務(wù)它會經(jīng)歷讀取項目結(jié)構(gòu)、定位登錄相關(guān)文件、查看現(xiàn)有代碼邏輯、設(shè)計改動方案、修改代碼、運(yùn)行測試、修復(fù)測試失敗……這個過程可能持續(xù)幾十分鐘產(chǎn)生上百輪交互累計信息量可能達(dá)到數(shù)十萬token。這里有個關(guān)鍵矛盾模型的上下文窗口是有限的雖然現(xiàn)在很多模型聲稱支持100K甚至1M token但任務(wù)一旦復(fù)雜起來相關(guān)信息總量很容易撐爆窗口。更微妙的是即使窗口沒被撐爆當(dāng)上下文長度超過一定閾值后模型的有效注意力和信息提取準(zhǔn)確率都會顯著下滑。這個現(xiàn)象在業(yè)內(nèi)有專門的說法叫“l(fā)ost in the middle”——上下文中間位置的信息最容易被模型忽略。我自己的實測數(shù)據(jù)是當(dāng)上下文總量在20K token以內(nèi)時Agent的任務(wù)完成率大約在85%左右超過50K token后完成率直接掉到60%附近到了80K以上很多Agent開始出現(xiàn)“忘了自己最初目標(biāo)是什么”“反復(fù)讀同一個文件”“把A文件的修改方案套到B文件”這類混亂行為。2.2 176組實驗中的關(guān)鍵數(shù)據(jù)發(fā)現(xiàn)UMass實驗中最有價值的發(fā)現(xiàn)是通過三組對照得出來的。第一組對照是“完整上下文 vs 壓縮上下文”。在相同模型和相同任務(wù)條件下保留完整對話歷史和采用策略性壓縮后的上下文任務(wù)完成率居然不相上下有些壓縮組反而更高。這說明什么說明很多上下文信息其實是噪聲全量保留不僅浪費(fèi)窗口空間還會干擾模型判斷。真正有效的做法是“壓縮而非截斷”——把舊信息提煉成更精煉的摘要形式而不是簡單粗暴地砍掉后面一半。第二組對照是“線性歷史 vs 結(jié)構(gòu)化狀態(tài)”。所謂線性歷史就是按時間順序把所有消息堆在一起結(jié)構(gòu)化狀態(tài)則是用任務(wù)清單、進(jìn)度標(biāo)記、當(dāng)前目標(biāo)、已決策事項等結(jié)構(gòu)化數(shù)據(jù)來組織信息。結(jié)果顯示結(jié)構(gòu)化狀態(tài)組在長任務(wù)場景下的成功率平均高出線性歷史組約18到22個百分點。這個發(fā)現(xiàn)指向一個核心設(shè)計原則上下文管理的本質(zhì)不是數(shù)據(jù)存儲而是信息架構(gòu)。第三組對照是“一次性長任務(wù) vs 任務(wù)分段”。把一個大任務(wù)拆成若干子任務(wù)每段子任務(wù)有獨立的上下文空間段與段之間只傳遞必要的結(jié)果摘要這種做法的成功率比一次性長任務(wù)高出25%以上。想象一下你整理房間一股腦把所有東西攤開再歸類和按區(qū)域逐步收拾顯然后者更不易亂。2.3 上下文管理失敗的典型癥狀基于這176組實驗和我的實操經(jīng)驗我把上下文管理失敗的表現(xiàn)歸納為五類典型癥狀大家可以對照自查第一類目標(biāo)漂移。Agent做著做著就不記得原始需求了或者把中間過程產(chǎn)生的局部目標(biāo)當(dāng)成最終目標(biāo)。癥狀是越到任務(wù)后半段輸出的代碼越偏離最初的架構(gòu)設(shè)計。第二類重復(fù)勞動。Agent反復(fù)讀取同一個文件、反復(fù)生成相似的代碼片段甚至把自己剛改過又撤銷的改動重新改回去。這是上下文中沒有清晰記錄“已完成事項”導(dǎo)致的。第三類信息混淆。把文件A的邏輯當(dāng)成文件B的把用戶對功能1的要求套到功能2上。上下文越長越容易出現(xiàn)尤其是當(dāng)兩個文件或需求內(nèi)容相似時。第四類決策失憶。Agent在上下文里做過一些重要決策但后續(xù)沒有再顯式引用模型慢慢就把決策“遺忘”了。比如最初規(guī)定“所有新增API都走統(tǒng)一異常處理”寫到后面變成每個API自行處理異常。第五類局部視野。當(dāng)Agent關(guān)注的上下文片段過窄時它做出的修改可能局部正確但在全局層面引入矛盾。典型場景是只看了單個函數(shù)的代碼就改沒看調(diào)用方和使用約定。3. 實操方法與上下文管理策略3.1 任務(wù)開始前的上下文預(yù)規(guī)劃踩過足夠多的坑之后我總結(jié)出一個觀點上下文管理不能等上下文出問題再救必須從任務(wù)啟動的那一刻就開始規(guī)劃。這就像開車跑長途不能等油箱見底才找加油站出發(fā)前就要規(guī)劃好路線和補(bǔ)給點。任務(wù)開始前的預(yù)規(guī)劃我建議按三步走第一步把大任務(wù)拆解成子任務(wù)序列。不要對Agent說“幫我完善這個項目”而要拆成“先梳理項目結(jié)構(gòu)”“再定位認(rèn)證模塊”“然后設(shè)計驗證碼方案”“接著實現(xiàn)代碼”“最后運(yùn)行測試”。每一個子任務(wù)都應(yīng)該有明確的輸入和輸出邊界。第二步為每個子任務(wù)設(shè)定清晰的上下文邊界。比如子任務(wù)“定位認(rèn)證模塊”只需要項目文件樹和依賴關(guān)系不需要Mock數(shù)據(jù)表結(jié)構(gòu)。這樣能避免無關(guān)信息侵入上下文。第三步預(yù)先約定輸出格式。告訴Agent每個階段結(jié)束時輸出一份結(jié)構(gòu)化摘要包含已完成事項、當(dāng)前狀態(tài)、遺留問題、下一步計劃。這等于強(qiáng)制Agent做上下文壓縮為后續(xù)任務(wù)提供干凈入口。這個預(yù)規(guī)劃過程看起來簡單實際操作時有一個容易忽略的細(xì)節(jié)子任務(wù)拆解的粒度。拆太粗單個子任務(wù)內(nèi)的上下文壓力仍然很大拆太細(xì)頻繁的上下文切換又會導(dǎo)致信息交接損耗。我個人經(jīng)驗是每個子任務(wù)的預(yù)期時間控制在15分鐘以內(nèi)比較合適也就是Agent大約交互20到40輪以內(nèi)這樣上下文基本可控。3.2 執(zhí)行過程中的上下文維護(hù)機(jī)制有了好的開始執(zhí)行過程中的上下文維護(hù)同樣關(guān)鍵。這里分享三個經(jīng)過驗證的機(jī)制第一個機(jī)制顯式狀態(tài)跟蹤。不要讓Agent自由發(fā)揮而是在每一輪工具調(diào)用后強(qiáng)制要求Agent維護(hù)一個簡短的“狀態(tài)塊”記錄當(dāng)前步驟、已完成步驟、阻塞點。狀態(tài)塊不必很長三五行即可但它能持續(xù)錨定Agent的注意力。我自己實測這個簡單的機(jī)制就能讓長任務(wù)成功率提升約10%。第二個機(jī)制定期摘要壓縮。當(dāng)上下文接近或超過預(yù)設(shè)閾值時主動觸發(fā)摘要壓縮把過去的完整歷史提煉為結(jié)構(gòu)化摘要保留原始?xì)v史在某個隱藏空間中不參與后續(xù)推理。摘要要按“已完成的改動、當(dāng)前待辦、關(guān)鍵決策、需要注意的約束”四個維度組織。實際操作時我通常設(shè)定20K token為一個管理單位每次跨過一個單位就做一次壓縮。第三個機(jī)制按需檢索替代全量保留。Agent不需要每輪都把所有歷史信息加載進(jìn)來。更高效的做法是維護(hù)一個外部信息庫按需檢索當(dāng)前步驟需要的上下文片段。類似于人工作時的做法手頭有一堆資料但我不會全程捧著整疊紙而是在需要時翻找相關(guān)章節(jié)。檢索的關(guān)鍵是要有元數(shù)據(jù)標(biāo)記比如“文件路徑功能描述最后修改時間”否則檢索精度會很差。這里有一個實用的實現(xiàn)Pattern我驗證過很多次代碼如下# 上下文管理偽代碼按需檢索 狀態(tài)記憶 class AgentContextManager: def __init__(self, model, max_context_tokens20000): self.model model self.max_context_tokens max_context_tokens self.state { goal: , # 最終目標(biāo) completed: [], # 已完成事項 current_task: , # 當(dāng)前子任務(wù) blockers: [], # 阻塞點 decisions: [] # 關(guān)鍵決策記錄 } self.history [] # 完整歷史(原始) self.summary # 壓縮摘要 def add_observation(self, observation): # 新信息進(jìn)入歷史觀察是否需要壓縮 self.history.append(observation) if self._count_tokens(self.history) self.max_context_tokens * 0.8: self._compress_history() def _compress_history(self): # 調(diào)用模型生成結(jié)構(gòu)化摘要替換原始?xì)v史參與后續(xù)推理 prompt f請將以下Agent執(zhí)行歷史壓縮為結(jié)構(gòu)化摘要 原目標(biāo){self.state[goal]} 當(dāng)前任務(wù){(diào)self.state[current_task]} 歷史內(nèi)容{self.history[-200:]} # 窗口末尾的近期內(nèi)容 輸出格式已完成改動/當(dāng)前待辦/關(guān)鍵決策/注意事項 self.summary self.model.generate(prompt) self.history self.history[-50:] # 保留少量近期完整內(nèi)容3.3 上下文信息的結(jié)構(gòu)化組織上下文管理的下一層進(jìn)階是把零散的信息組織成結(jié)構(gòu)化數(shù)據(jù)。我強(qiáng)烈建議在Agent實現(xiàn)中使用三類核心結(jié)構(gòu)第一類任務(wù)狀態(tài)表。用表格記錄所有子任務(wù)的狀態(tài)——未開始、進(jìn)行中、已完成、已阻塞。每次子任務(wù)狀態(tài)變化都要更新這張表。這個表不僅能幫模型對齊當(dāng)前進(jìn)度也能讓使用者在交互界面中直觀看到Agent卡在哪里。第二類文件修改索引。記錄每個已修改文件的路徑、修改時間、修改內(nèi)容概要。當(dāng)Agent處理多文件任務(wù)時這個索引能幫助它回答“我改過哪些文件”“上次在service層做了什么改動”這類關(guān)鍵問題。缺少這個索引往往是Agent重復(fù)改同一文件或改錯文件的根源。對比示例管理方式修改記錄形式后續(xù)定位效率混淆概率無索引散落在歷史消息中依賴模型記憶高簡單日志文件路徑列表無法定位改動內(nèi)容中結(jié)構(gòu)化索引路徑改動概要版本標(biāo)記快速精準(zhǔn)定位低第三類決策日志。記錄任務(wù)過程中所有重要決策為什么選A方案而非B、用戶有哪些硬性約束、技術(shù)棧有哪些限制。決策日志要放在上下文的顯眼位置通常是系統(tǒng)提示詞末尾而不是埋在歷史深處。一個常見的失敗場景是Agent開頭聽了用戶說“不要用第三方庫”做到一半開始網(wǎng)上查資料又試圖引入第三方庫。有決策日志在顯眼位置錨定這類漂移會明顯減少。3.4 針對不同任務(wù)類型的差異化策略上下文管理不是一套策略打天下不同任務(wù)類型有截然不同的最佳實踐。UMass的176組實驗其實也側(cè)面驗證了這一點。我按常用分類做了一個分流對于短時任務(wù)5分鐘內(nèi)可完成比如單函數(shù)編寫、小范圍bug修復(fù)上下文管理策略是輕量化的。保留完整歷史不壓縮狀態(tài)塊簡單記錄即可不需要復(fù)雜的結(jié)構(gòu)。對于中期任務(wù)30分鐘左右比如模塊級功能開發(fā)、跨文件重構(gòu)每輪交互強(qiáng)制結(jié)構(gòu)化狀態(tài)跟蹤每10到15輪做一次摘要壓縮保持文件修改索引更新。對于長期任務(wù)數(shù)小時甚至跨天比如全項目架構(gòu)升級、遺留代碼庫維護(hù)引入任務(wù)暫停與恢復(fù)機(jī)制。Agent每完成一個階段就把完整狀態(tài)序列化保存到外部存儲下次啟動時加載狀態(tài)而非從頭對話。這在實操中極其有用——很多Agent項目做一半中斷后重啟上下文全丟所有進(jìn)度白費(fèi)本質(zhì)就是沒有序列化狀態(tài)。我還觀察到一個小策略很有效上下文雙軌制。一軌是面向模型推理的“緊湊上下文”摘要狀態(tài)當(dāng)前任務(wù)另一軌是面向查詢檢索的“完整檔案”所有歷史記錄、文件內(nèi)容、搜索結(jié)果的原始數(shù)據(jù)。模型每輪只消費(fèi)緊湊上下文但在需要細(xì)節(jié)時可以從完整檔案里檢索。相當(dāng)于工作記憶和長期記憶的分離這比單一上下文機(jī)制更接近人腦的工作方式。4. 工具選型解析4.1 主流Coding Agent的上下文管理能力對比既然上下文管理是瓶頸那市面上主流的Coding Agent在這一維度上表現(xiàn)如何我自己實際用過開源的、商業(yè)的、自研的若干種這里做一個基于實測和實驗數(shù)據(jù)的主觀對比。工具/方案上下文壓縮結(jié)構(gòu)化狀態(tài)按需檢索長期記憶適用場景開源通用Agent框架弱多為基礎(chǔ)截斷部分支持依賴配置依賴外部存儲可控性強(qiáng)適合二次開發(fā)商業(yè)編程助手如Codex CLI類中等有自動壓縮內(nèi)置任務(wù)清單有代碼庫索引有會話恢復(fù)日常開發(fā)輔助自研Agent自建上下文管理器完全可控可深度定制可配置向量檢索可對接任意存儲復(fù)雜長任務(wù)、生產(chǎn)級場景強(qiáng)調(diào)一句這個對比不評判誰好誰壞純粹看上下文管理功能完備度。日常編程輔助用商業(yè)化工具完全足夠但如果是復(fù)雜的長周期重構(gòu)任務(wù)或者有大量多文件操作自研方案才能徹底解決問題。4.2 選型背后的決策考量為什么市面上這些工具的上下文管理能力差異這么大底層原因還是上下文管理策略的實現(xiàn)難度和成本考量?；诨瑒哟翱诘暮唵谓財嗖呗詫崿F(xiàn)成本最低大多數(shù)輕量工具都這么做。好處是邏輯簡單、不消耗額外token壞處是信息丟失不可控——很可能截掉的恰恰是關(guān)鍵約束或歷史決策。基于摘要壓縮的策略要設(shè)計壓縮觸發(fā)時機(jī)、壓縮粒度、摘要格式每一步都在消耗額外token還會引入“壓縮損失”。但相比之下它保留的信息密度遠(yuǎn)高于截斷所以更復(fù)雜的工具普遍傾向這個方向?；跈z索增強(qiáng)的策略理論上最優(yōu)但工程復(fù)雜度高了很多要維護(hù)向量索引要設(shè)計檢索觸發(fā)條件要解決“檢索不到關(guān)鍵信息”的召回失敗問題。好比整理書房把書全部攤開找和建一套索引系統(tǒng)再按編號查找后者前期投入大但長期收益高。從我的決策經(jīng)驗看選型應(yīng)該按任務(wù)復(fù)雜度而非模型能力來倒推。如果你平時多數(shù)任務(wù)在單文件級別普通截斷就夠用。如果經(jīng)?？缥募貥?gòu)至少要有摘要壓縮。如果是長周期項目必須上檢索增強(qiáng)和狀態(tài)序列化。在選型時我還會加上一個測試點人為制造一個長上下文場景比如讓Agent讀10個以上文件后修改其中3個觀察它在第5個文件之后的執(zhí)行準(zhǔn)確性這個測試比看跑分?jǐn)?shù)據(jù)直觀得多。5. 常見問題與排查技巧實錄5.1 上下文管理五問速查表積累了大量實操后我把最常遇到、最影響使用效果的五類問題整理成一個速查表。每個問題都來自真實使用場景附上排查思路和解決方案。問題現(xiàn)象根因排查方法解決方案Agent做到一半“忘了”最初需求目標(biāo)未在上下文顯式錨定檢查系統(tǒng)提示中是否有目標(biāo)描述、是否定期重復(fù)在狀態(tài)塊中持續(xù)維護(hù)“最終目標(biāo)”字段每輪引用Agent重復(fù)改同一個文件文件修改索引缺失或未被加載查看上下文是否有結(jié)構(gòu)化文件日志增加文件修改索引附帶“已改內(nèi)容概要”和版本號多文件任務(wù)后期開始混淆不同文件邏輯上下文過長導(dǎo)致“l(fā)ost in the middle”統(tǒng)計上下文長度確認(rèn)是否超過有效注意力區(qū)間做摘要壓縮把關(guān)鍵文件映射表放入上下文前部Agent在某步驟后開始做無關(guān)操作任務(wù)規(guī)劃被淹沒檢查是否有子任務(wù)清單、當(dāng)前步驟標(biāo)記強(qiáng)制每一步輸出“當(dāng)前任務(wù)地圖”恢復(fù)會話后Agent完全不記得之前的進(jìn)度狀態(tài)未序列化關(guān)閉Agent后檢查是否有狀態(tài)文件落盤實現(xiàn)任務(wù)狀態(tài)序列化支持從“階段點”無損恢復(fù)這個表看起來簡單但背后的每一個解決方案我都實際驗證過。它們不是理論推演而是“改完之后效果肉眼可見”的操作。5.2 實操中容易被忽略的細(xì)節(jié)接下來補(bǔ)充幾個細(xì)節(jié)。第一個壓縮時機(jī)要在閾值前而不是閾值后。很多人等上下文滿了才觸發(fā)壓縮這時模型已經(jīng)在低質(zhì)量狀態(tài)下運(yùn)行了一段時間錯誤已經(jīng)產(chǎn)生了。正確做法是設(shè)定一個軟閾值比如上下文窗口的70%到達(dá)就提前壓縮。我自己設(shè)定20K token的軟閾值效果比等40K滿了再壓縮好得多。第二個摘要壓縮的過程要給模型足夠結(jié)構(gòu)化指導(dǎo)。不要簡單說“總結(jié)一下”而是給出固定格式模板。我常用的格式是四段式已完成任務(wù)清單、當(dāng)前狀態(tài)說明、待辦事項、關(guān)鍵決策和約束。如果壓縮步驟不指定結(jié)構(gòu)化輸出模型可能會把關(guān)鍵決策散落在敘事性摘要中后續(xù)很難檢索定位。第三個上下文管理器要對“決策類信息”和“數(shù)據(jù)類信息”區(qū)別對待。決策類信息為什么這么設(shè)計、用戶有什么硬性要求必須長期保留數(shù)據(jù)類信息某個文件的完整內(nèi)容、某次執(zhí)行日志可以釋放按需再檢索。很多上下文管理失敗就是因為把決策信息當(dāng)成普通聊天內(nèi)容在一輪輪壓縮中逐漸丟失。第四個多Agent協(xié)作時上下文邊界更難把控。如果項目里用了主Agent加子Agent分工模式每個子Agent的上下文都應(yīng)該限制在子任務(wù)范圍內(nèi)完成后續(xù)把結(jié)果摘要匯報給主Agent而不是把完整執(zhí)行歷史同步過去。否則主Agent的上下文很快就會被子任務(wù)細(xì)節(jié)淹沒失去全局視角。這個問題的出現(xiàn)頻率遠(yuǎn)超想象特別是在做大型代碼重構(gòu)時。5.3 一個典型長任務(wù)排查實錄最后分享一個我印象深刻的排查案例完整還原一次Agent長任務(wù)出問題后的定位過程。背景我用自研Agent做一次跨20個文件的重構(gòu)把項目中所有API調(diào)用從舊SDK遷移到新SDK。任務(wù)開始階段Agent表現(xiàn)正常能精準(zhǔn)定位調(diào)用點并修改。但當(dāng)任務(wù)進(jìn)行到第40分鐘左右時它突然開始改寫SDK配置文件的格式——這與本次任務(wù)完全無關(guān)。排查過程我分了三步第一步查看上下文狀態(tài)塊。發(fā)現(xiàn)當(dāng)前任務(wù)標(biāo)記還是“遷移API調(diào)用”但歷史消息中已經(jīng)混入了大量新SDK文檔內(nèi)容信息發(fā)生了覆蓋。原來在第30分鐘左右Agent為了查一個API參數(shù)檢索并加載了新的SDK完整文檔這部分內(nèi)容占據(jù)了大量上下文把早期任務(wù)邊界信息擠到了“中間位置”。第二步查看決策日志。發(fā)現(xiàn)最初寫入的“范圍約束本次只改調(diào)用代碼不做配置遷移”已經(jīng)被糟糕的上下文組織埋沒了。第三步修復(fù)操作。我強(qiáng)制觸發(fā)上下文壓縮用結(jié)構(gòu)化摘要把“目標(biāo)、已完成模塊、范圍約束、剩余任務(wù)”重新固定到上下文最前部然后刪除了新SDK文檔的完整內(nèi)容改為保留一個“文檔位置按需檢索標(biāo)記”。重新恢復(fù)執(zhí)行后Agent回到了正確軌道后續(xù)沒有再發(fā)生越界操作。這個案例給我最大的啟發(fā)是上下文管理不是一次性的靜態(tài)配置而是需要持續(xù)監(jiān)控和主動干預(yù)的動態(tài)過程。工具自動化能解決80%的問題但剩下20%的關(guān)鍵節(jié)點需要人工察覺并介入修正而這種判斷力只能來自對上下文管理機(jī)制的深入理解。我個人現(xiàn)在養(yǎng)成了一個習(xí)慣執(zhí)行長任務(wù)時每隔一段時間掃一眼Agent當(dāng)前維護(hù)的狀態(tài)塊確認(rèn)它的“當(dāng)前任務(wù)”和“最終目標(biāo)”是否對齊。發(fā)現(xiàn)漂移及時糾偏而不是等錯誤代碼生成后才去修補(bǔ)。這樣做長任務(wù)的成功率比放任狀態(tài)漂移高出一截。這篇文章里梳理的思路和坑位希望也能讓大家少走點彎路。