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