在跑編碼智能體對比測試以前我一直以為同一個模型配不同框架成績波動主要來自調(diào)用方式、工具編排和代碼注入差異。后來測試次數(shù)多了發(fā)現(xiàn)真正被低估的是上下文這一層當上下文窗口接近上限時模型沒有變?nèi)蝿?wù)沒有變但回答質(zhì)量、修改準確率和早期指令遵守度會明顯下滑。更麻煩的是不同框架對上下文的處理策略完全不同有的拼原始記錄有的滾動裁剪有的自動摘要有的先壓縮工具結(jié)果。于是“固定模型、調(diào)整框架”時成績波動就成了必然現(xiàn)象。這篇文章不是要推薦某一個框架而是想把“上下文窗口”作為關(guān)鍵變量拿出來講清楚它占用了什么內(nèi)容緊張時模型會有什么表現(xiàn)不同框架管理上下文的方式會造成多大差異以及做評估和落地時應(yīng)該按什么順序去排查。適合正在選 agent 框架、調(diào)優(yōu)編碼智能體會話、或者發(fā)現(xiàn)模型越改越亂的開發(fā)者讀。1. 編碼智能體的上下文窗口里到底裝了什么1.1 不只是對話歷史還有文件內(nèi)容、工具結(jié)果和推理過程一個編碼智能體在執(zhí)行任務(wù)時上下文內(nèi)容通常包括系統(tǒng)提示詞、用戶需求、倉庫文件內(nèi)容、相關(guān)代碼片段、編譯器或運行工具的輸出、之前的對話歷史、模型自己生成的推理步驟以及多個工具調(diào)用的返回值?？雌饋硪粋€任務(wù)只要問一句“幫我修復(fù)這個接口”實際上模型每讀一個文件、每執(zhí)行一條命令結(jié)果都會重新進上下文持續(xù)占用窗口。很多人以為上下文窗口只是用來裝聊天記錄其實在編碼場景里聊天記錄反而不是大頭。占比高的通常是文件快照、代碼片段和工具輸出。一個幾百行的文件讀進來可能就吃掉幾千個 token連續(xù)執(zhí)行幾次測試、列出目錄、查看報錯token 消耗會快速增長?？蚣苋绻粫嚎s或裁剪長時間會話后上下文就會進入緊張狀態(tài)。理解這一點很重要。上下文緊張導(dǎo)致的波動并不是模型突然變笨而是關(guān)鍵信息在窗口里被稀釋或截斷。模型仍然有推理能力但它可能已經(jīng)看不到任務(wù)開頭約定的接口名、路徑、邊界條件和禁止事項于是只能靠后文里的零散信息去猜結(jié)果自然飄。1.2 上下文緊張時模型能力被什么因素拖下去了我自己在連續(xù)測試編碼智能體時最?？吹降纳舷挛木o張表現(xiàn)有四類。第一早期指令丟失。任務(wù)一開始明確說過“不要修改配置文件”跑了一段時間后模型開始動配置甚至把之前改好的配置改回去。第二重復(fù)勞動。模型不知道自己已經(jīng)實現(xiàn)了某個函數(shù)又重新寫了一遍或者反復(fù)修改同一個文件。第三改變已有邏輯。在修新問題時順手把之前能跑通的邏輯改了回歸測試開始失敗。第四輸出變短且缺少結(jié)構(gòu)。模型不再按約定的格式提交代碼而是給一個粗略總結(jié)或者只給建議而不給具體補丁。如果上下文還沒滿但這些現(xiàn)象已經(jīng)出現(xiàn)說明上下文使用效率已經(jīng)不行了。這時候需要先檢查當前上下文用量而不是急著換模型或換框架。因為換模型或換框架可能暫時緩解但根因是信息管理方式?jīng)]有匹配任務(wù)規(guī)模。這里也涉及一個模型機制層面的原因。Transformer 這類模型在長上下文里注意力會被大量無關(guān) token 分散早期信息更容易被淹沒。即使窗口沒有物理溢出只要塞進了太多冗余內(nèi)容模型對關(guān)鍵約束的敏感度也會下降。所以“上下文緊張”不完全等于“窗口塞滿”也包括“窗口里有用信息占比過低”。2. 固定模型只換框架我看到的成績波動不是偶然2.1 一組小樣本觀測同一個任務(wù)在不同框架下的表現(xiàn)為了把“模型”這個變量去掉我近期做了一輪小樣本對比測試。固定同一個模型版本固定同一套代碼庫和任務(wù)描述分別在三個 agent 框架里各跑一定次數(shù)的同類編碼任務(wù)。任務(wù)包括修一個接口、補一個單測、整理一段邏輯不算復(fù)雜但需要多次讀文件和運行命令。從結(jié)果上看任務(wù)較短時三個框架的完成率差異不大。一旦任務(wù)長度變長、需要讀取的文件變多成績開始拉開波動幅度也變大。最明顯的一種情況是上下文占用到高位后有的框架仍然能穩(wěn)定按早期約束執(zhí)行有的框架開始自我發(fā)揮不再遵守初始提示詞里的條件甚至出現(xiàn)改了舊功能再修新功能的情況。需要說明的是這個結(jié)果只是我自己小樣本觀測的結(jié)論不是通用基準。不同模型、不同任務(wù)規(guī)模、不同倉庫結(jié)構(gòu)下排序可能會變。但有一個規(guī)律是穩(wěn)定的上下文越緊張框架之間的成績差距越容易出現(xiàn)。這也是為什么評估編碼智能體時不能只測短任務(wù)就下結(jié)論。2.2 波動不等于框架能力差先看上下文占用曲線看到一個框架表現(xiàn)差很容易讓人直接說“這個框架不行”。我建議先別急著歸因把上下文占用曲線拉出來看。有些框架在單輪短任務(wù)里很順因為初始提示詞和工具結(jié)果都能完整放進窗口。等任務(wù)變長框架如果繼續(xù)把全部歷史原文和工具輸出都塞進去模型就要在大量冗余信息里找關(guān)鍵點效果自然下滑。這不是模型能力問題也不是框架不會寫代碼而是上下文管理策略沒有為長任務(wù)做優(yōu)化。反過來有些框架在任務(wù)開始時看起來響應(yīng)慢可能是因為框架在做上下文整理把歷史摘要化、把文件內(nèi)容按需讀取、把工具結(jié)果壓縮成關(guān)鍵片段。這種慢在長任務(wù)里可能換來更穩(wěn)定的輸出。所以判斷一個框架要看它在上下文緊張后的表現(xiàn)而不是只盯前幾個回合。這里可以引入一個更結(jié)構(gòu)化的視角把框架按上下文策略分成三類來看全量拼接型、滾動裁剪型、摘要壓縮型。三者入口表現(xiàn)相似長任務(wù)里差異很大。2.3 三類常見上下文策略的直觀對比下面是我平時記錄時用的表格方便做橫向比較策略類型上下文緊張時可能的行為典型優(yōu)點典型風(fēng)險全量拼接歷史、文件、工具輸出原文都保留窗口快速增長信息保真早期事件不會被主動刪除上下文擁擠后注意力分散早期指令易被淹沒滾動裁剪超出限制時丟棄最早內(nèi)容只保留最近幾輪窗口壓力可控響應(yīng)能維持早期約束、任務(wù)目標可能被靜默丟棄摘要壓縮定期把舊對話和工具結(jié)果壓縮為摘要節(jié)省窗口關(guān)鍵信息可以長期保留摘要會丟失細節(jié)模型可能只知道做過不知道怎么做這張表的結(jié)論不是“摘要最好”或“全量最差”而是提醒換框架時必須知道框架默認在做什么。如果項目要求穩(wěn)定執(zhí)行早期約束但框架卻在滾動裁剪任務(wù)剛開始的規(guī)則很快會被截掉成績自然波動。識別框架的上下文策略比單純比較“誰生成的代碼能跑”更能解釋波動來源。3. 框架管理上下文的方式才是波動的主要來源3.1 執(zhí)行上下文、數(shù)據(jù)流和內(nèi)容重寫機制我平時看一個 agent 框架會先看三件事執(zhí)行上下文怎么組織、數(shù)據(jù)流怎么傳遞、歷史內(nèi)容會不會被重寫。執(zhí)行上下文可以理解成框架替模型維護的“工作臺”。有些框架把工作臺做成一個大文本所有內(nèi)容都往里堆有些框架則把任務(wù)狀態(tài)、文件快照、工具結(jié)果分開存放模型每次閱讀時只拿到需要的部分。后者在長時間任務(wù)里更穩(wěn)因為它減少了無關(guān)內(nèi)容對注意力分布的干擾。數(shù)據(jù)流指的是工具調(diào)用結(jié)果怎么回到上下文。如果框架每次跑完一條命令都讓模型重新閱讀完整輸出長任務(wù)里會大量消耗窗口。更合理的做法是在工具返回后提取關(guān)鍵字段、生成結(jié)構(gòu)化摘要再決定是否寫入上下文。這個設(shè)計直接決定上下文增長速度。內(nèi)容重寫機制則包括摘要壓縮、上下文裁剪、歷史清理。難點在于壓縮之后早期約束可能丟失。設(shè)計者需要在“保存全部歷史”和“控制窗口占用”之間做取舍。這個取舍直接決定固定模型后框架成績在上下文緊張時波動多大。有時候用戶會在會話里遇到“提問時好像沒有上下文”的情況。這種問題往往不是模型沒有記憶能力而是框架沒有把前幾輪的結(jié)論傳給下一輪。會話隔離、上下文清空、工具結(jié)果不追加到歷史都可能造成這種觀感。這種情況下?lián)Q模型、調(diào)溫度參數(shù)用處不大。更有效的做法是改變工作流比如每一輪都讓模型輸出一個階段性結(jié)論下一條消息里主動帶上這個結(jié)論再往下問。3.2 會話記憶、保存與恢復(fù)對長任務(wù)的影響還有一類問題經(jīng)常被忽略會話上下文能不能保存下次能不能恢復(fù)。編碼智能體經(jīng)常會出現(xiàn)做到一半中斷的情況。如果重新打開時上下文全部丟失模型只能根據(jù)新會話里的少量信息重新判斷任務(wù)。某些框架支持把會話導(dǎo)出、生成摘要、下次繼續(xù)體驗差異很大。對于長任務(wù)我會建議不要依賴框架默認的記憶能力。可以自己維護一個“任務(wù)進度文檔”每完成一個子任務(wù)就更新一次然后把它作為參考文件傳給后續(xù)會話。這比讓模型從幾十輪對話歷史里翻找狀態(tài)更可靠也能顯著降低上下文占用。另外有些框架或工具設(shè)置里提供了上下文壓縮選項例如把超過一定長度的歷史內(nèi)容先摘要化。這類功能能緩解窗口緊張但要留意壓縮時機。如果任務(wù)剛開始就壓縮可能把關(guān)鍵需求提前簡化掉如果等到快溢出才壓縮壓縮過程本身可能耗費不少 token。實際使用時要先小范圍驗證觀察壓縮后模型是否還記得關(guān)鍵約束。3.3 同一個模型不同框架下為什么“像換了個人”固定模型后換框架有些人會覺得“同一個模型變聰明了又變笨了”。在這個表象背后通常有四個因素在起作用。第一個是系統(tǒng)提示詞長度和內(nèi)容。框架可能為了注入工具說明、輸出格式、代碼規(guī)范疊加一長串提示詞。這些內(nèi)容占用上下文也影響模型對用戶需求的理解。第二個是上下文裁剪閾值。不同框架對窗口上限的設(shè)定不同有的允許接近上限時繼續(xù)請求有的會在到達一定比例后就強制裁剪。第三個是工具調(diào)用格式的復(fù)雜度。工具格式如果復(fù)雜模型要多花 token 在“符合格式”上留給問題推理的空間就少了。第四個是歷史保留策略。有的框架保留完整歷史有的只保留最近 N 輪有的把歷史摘要化后拼接模型的“可見信息”完全不同。所以遇到“同一個模型換了框架成績變差”時不要只怪模型。最好先導(dǎo)出兩個框架實際發(fā)給模型的 prompt看看到底差在哪里。很多時候差異不在模型內(nèi)部而在框架塞給模型的內(nèi)容和順序。4. 怎么把“換框架”變成一次可信的對比測試4.1 前置條件固定模型版本、任務(wù)集和輸入范圍如果想讓測試結(jié)論稍微可信一點第一步是把變量固定住。模型版本要固定包括模型名稱、上下文窗口參數(shù)、temperature 這類采樣參數(shù)也要盡量一致。任務(wù)集要固定最好挑同一份代碼庫、同一個 bug 描述、同一套驗收條件。輸入范圍也要固定比如規(guī)定測試時只能讀取哪些目錄、不允許外部搜索。這里有一個容易忽略的點很多框架會默認攜帶不同的 system prompt導(dǎo)致你名義上固定了模型實際發(fā)給模型的上下文并不一樣。這種差異會影響測試結(jié)果但不一定代表框架真實能力的高低。更好一點的做法是把框架自帶的系統(tǒng)提示詞也導(dǎo)出來記錄作為變量之一。如果你需要對比的框架比較多可以先做一輪“短任務(wù)篩選”再做一輪“長任務(wù)復(fù)測”。短任務(wù)用來排除明顯不可用、啟動有問題、工具調(diào)用不穩(wěn)定的框架長任務(wù)用來觀察上下文緊張時的表現(xiàn)差異。先短后長成本更低結(jié)果也更清晰。4.2 記錄順序先上下文量再任務(wù)結(jié)果最后失敗模式我建議每跑一次任務(wù)都按這個順序記錄開始時間、模型版本、框架版本。初始提示詞長度和上下文占用。任務(wù)過程中工具調(diào)用次數(shù)、輸入輸出 token 總數(shù)。任務(wù)結(jié)束時上下文剩余量是否發(fā)生裁剪、壓縮、摘要。任務(wù)結(jié)果是否完成任務(wù)按驗收標準打分。失敗模式改了哪些文件是否破壞已有邏輯是否重復(fù)實現(xiàn)已有功能。把第 2 到第 4 步放在結(jié)果之前是因為如果不記錄上下文很多“成績波動”沒法解釋。你可能會以為是框架策略差異其實只是任務(wù)跑太久把上下文塞滿了。為了看得清楚可以用一個示例命令從日志里篩上下文相關(guān)記錄# 示例在 agent 運行日志中查找 token 和上下文占用信息 grep -iE context|token|prompt agent_run.log | tail -n 40文件名和字段按實際框架的輸出調(diào)整。關(guān)鍵是形成一條“上下文占用曲線”把每個階段的占用記錄下來。這樣任務(wù)失敗時能判斷是模型能力不夠還是上下文已經(jīng)過載。建議任務(wù)開始前先把上下文使用量、模型名、框架版本記下來。沒有這些基線成績波動很難歸因。4.3 判斷標準完成度、修改范圍、回歸行為判斷編碼智能體成績不能只看“它最后有沒有輸出”。同一個任務(wù)可能模型輸出了完整代碼但順手刪了原有功能也可能它改對了文件但跑了三步?jīng)]編譯。所以我給自己定了四條驗收維度。第一是完成度需求描述里的點是否都覆蓋有沒有漏掉邊界條件。第二是修改范圍是否只動該動的文件有沒有改配置、改無關(guān)代碼、破壞已有測試。第三是回歸行為修改完成后原本通過的測試是否仍然通過。第四是遵守度早期提示詞里明確說的限制在較長任務(wù)里是否還被遵守。這四條比單看“能不能跑通”更能反映上下文緊張時的真實表現(xiàn)。測試數(shù)量也很重要。同一個任務(wù)只跑一次偶然因素會很大。我通常每個配置至少跑 5 輪如果時間緊也要跑 3 輪看結(jié)果是否穩(wěn)定。如果同一個框架在同樣任務(wù)下有時成功有時失敗多半不是模型隨機性而是上下文使用策略對輸入順序、文件讀取順序比較敏感。5. 上下文緊張時的處理順序與排查鏈路5.1 先分清楚表現(xiàn)遺忘、重復(fù)、還是回歸破壞上下文緊張時的現(xiàn)象不同處理辦法也不同。我建議先把現(xiàn)象分清楚。如果是早期指令遺忘也就是任務(wù)開頭說的限制后文不再遵守優(yōu)先檢查上下文里是否還保留著任務(wù)目標的核心約束。如果是重復(fù)勞動模型反復(fù)實現(xiàn)已經(jīng)存在的功能可能它沒有看到最新的文件狀態(tài)優(yōu)先檢查文件快照和工具結(jié)果是否及時更新。如果是改變已有邏輯修新問題時破壞了原有功能優(yōu)先檢查框架是否把修改過的文件重新注入上下文以及回歸測試結(jié)果是否被模型看到。光憑現(xiàn)象直接調(diào)模型參數(shù)通常是低效的。我會先寫一條簡短的排查記錄比如“任務(wù)進行到第幾輪、上下文占用多少、最后一次看到原始需求是什么時候”。有了這些信息再決定下一步。5.2 再查上下文占用日志、token 統(tǒng)計、工具調(diào)用次數(shù)上下文占用不是“感覺上差不多”要去看日志和統(tǒng)計數(shù)據(jù)。大部分框架會在請求日志里帶上 token 統(tǒng)計包括輸入 token、輸出 token、緩存 token。如果沒有現(xiàn)成統(tǒng)計可以數(shù)一下同一個會話里的工具調(diào)用次數(shù)和文件讀取次數(shù)也能判斷窗口消耗的大致水平。我一般會先看兩個指標輸入 token 是否接近模型窗口上限。接近時所有表現(xiàn)問題都先按上下文緊張?zhí)幚?。工具調(diào)用結(jié)果是否被重復(fù)注入。如果同一份文件內(nèi)容出現(xiàn)兩次以上說明框架可能在浪費窗口。看到這些指標后再判斷該調(diào)框架還是調(diào)模型。如果上下文占用還在低位但模型表現(xiàn)差那可能是提示詞、模型能力或任務(wù)本身的問題如果占用已經(jīng)很高優(yōu)先減少內(nèi)容量而不是折騰模型參數(shù)。5.3 最后調(diào)框架策略壓縮、裁剪、重塑或拆任務(wù)處理上下文緊張通常有幾條路。第一條是壓縮已有內(nèi)容。把歷史對話變成摘要把文件內(nèi)容只保留關(guān)鍵段落把工具輸出截取關(guān)鍵報錯。第二條是裁剪冗余內(nèi)容。刪除重復(fù)的文件快照、過長的日志、已經(jīng)失效的中間結(jié)果。第三條是重塑會話結(jié)構(gòu)。把任務(wù)分成“目標—步驟—狀態(tài)—結(jié)果”幾個部分讓模型每次只看當前需要的部分而不是從頭到尾再讀一遍。第四條是干脆拆任務(wù)。一個會話只處理一個子任務(wù)每次結(jié)束時輸出結(jié)論文件下一個會話再讀取這個文件。這四條路線不是互斥的。實際項目里經(jīng)常要先裁剪再摘要最后還要拆任務(wù)。如果框架本身不支持靈活調(diào)整那就要在應(yīng)用層自己做處理比如讓它讀取一個精簡版的項目說明而不是直接讀整個倉庫。注意如果上下文已經(jīng)接近上限不要急著換一個參數(shù)繼續(xù)重跑先清理無效歷史、固定關(guān)鍵約束。否則新參數(shù)大概率也救不回來。6. 實踐結(jié)論做編碼智能體評估先看上下文再看成績6.1 不要把上下文管理完全交給框架默認配置現(xiàn)在不少框架一上來就給你一個很順暢的體驗打開倉庫、解釋需求、開始生成。但默認配置通常是為了通用場景設(shè)計的不一定適合你的長任務(wù)。如果一個框架默認把所有文件都塞進上下文短任務(wù)沒問題長任務(wù)會越來越慢、越來越飄。如果你工作的倉庫很大建議先看框架有沒有“按需讀取文件”的設(shè)置有沒有“忽略目錄”“文件白名單”“工具結(jié)果截斷”這類選項。我在實際項目里會把 agent 接入時輸出的默認 system prompt、工具說明文檔、項目說明文件都審一遍刪掉不必要的長文本。這個操作不復(fù)雜但對上下文占用影響很大。很多成績波動不是發(fā)生在模型層而是在框架層把上下文“喂”得太亂、太多。6.2 模型能力與框架策略要一起評估從模型側(cè)看長上下文模型并不等于可以隨便往窗口里塞。Transformer 這類模型在很長的上下文里注意力會被大量無關(guān) token 分散早期信息更容易被淹沒。所以選擇模型時除了看窗口長度還要看它在中長上下文里是否仍然能保持對早期指令的敏感度。從框架側(cè)看同一個模型在摘要壓縮、滾動裁剪、全量拼接三種策略下表現(xiàn)可以差很多。模型蒸餾、模型融合這些話題經(jīng)常被討論它們是模型層的能力優(yōu)化但如果你不解決框架層的上下文浪費再強的模型也會被冗余信息拖累。一個更穩(wěn)的評估方法是做“模型乘框架”的小矩陣。先固定框架換不同模型看模型差異再固定模型換不同框架看框架差異。每輪都記錄上下文占用和任務(wù)結(jié)果。這樣可以定位到波動是模型帶來的還是框架帶來的。6.3 落地建議建立基線、記錄上下文、拆小任務(wù)如果要把編碼智能體真正用在項目里我的建議有三條。第一建立基線。每個項目固定一個模型版本、一個框架版本、一組驗收用例跑一次完整測試記錄當時的上下文占用和完成度。以后升級模型或換框架都以這份基線為對照。第二記錄上下文。每次任務(wù)開始前和結(jié)束后把 token 統(tǒng)計、上下文剩余量、是否發(fā)生裁剪寫進日志。不要等出問題了再回去翻。第三拆小任務(wù)。盡量讓一個會話做一件事長任務(wù)用外部文件保存狀態(tài)和結(jié)論?，F(xiàn)在我做編碼智能體相關(guān)項目看的已經(jīng)不是它能跑通多少題而是上下文占用越過閾值后它還能不能穩(wěn)定遵守早期約束。很多看起來像模型能力的問題其實是上下文管理問題。固定模型、調(diào)整框架時成績波動越明顯越應(yīng)該先去看框架到底怎么處理上下文。