1. 任務(wù)對(duì)話(huà)上下文到底在解決什么問(wèn)題用過(guò) WorkBuddy 這類(lèi) AI 工具的人大概率都遇到過(guò)一種很割裂的體驗(yàn)第一輪對(duì)話(huà)里你告訴它“幫我重構(gòu)這個(gè)模塊用 Python 3.11 的類(lèi)型注解風(fēng)格”它干得漂漂亮亮等你接著追問(wèn)“那把這個(gè)思路套到另一個(gè)文件上”它卻像失憶了一樣要么重新問(wèn)你用什么語(yǔ)言要么干脆給你一段風(fēng)格完全不同的代碼。這不是模型變笨了而是任務(wù)對(duì)話(huà)上下文沒(méi)管好。所謂任務(wù)對(duì)話(huà)上下文說(shuō)白了就是 AI 在完成一個(gè)任務(wù)的過(guò)程中能夠“記住”并“理解”的所有信息總和。它包含你之前說(shuō)過(guò)的話(huà)、AI 自己給出的回答、你上傳的文件內(nèi)容、系統(tǒng)預(yù)設(shè)的指令、以及工具調(diào)用產(chǎn)生的中間結(jié)果。這些內(nèi)容并不是無(wú)限往里塞的它們最終都要被序列化成 Token 流喂給模型而模型能接收的 Token 數(shù)量是有硬上限的這個(gè)上限就是大家常聽(tīng)到的Context Window上下文窗口。WorkBuddy 這個(gè)工具之所以把“任務(wù)對(duì)話(huà)上下文”單獨(dú)拎出來(lái)做一套機(jī)制是因?yàn)樗嫦虻牟皇情e聊場(chǎng)景而是長(zhǎng)周期、多步驟、帶工具調(diào)用的任務(wù)型工作流。比如讓它幫你把一個(gè)需求拆成任務(wù)清單、逐個(gè)生成代碼、再跑測(cè)試、最后匯總報(bào)告這一整套流程下來(lái)上下文會(huì)迅速膨脹。如果不做管理要么撞上窗口上限直接報(bào)錯(cuò)要么因?yàn)槿颂酂o(wú)關(guān)內(nèi)容導(dǎo)致模型注意力渙散、輸出質(zhì)量斷崖式下跌。這篇文章適合三類(lèi)人看第一類(lèi)是剛上手 WorkBuddy、搞不清為什么聊著聊著就“失憶”的新手第二類(lèi)是已經(jīng)踩過(guò)compact相關(guān)報(bào)錯(cuò)、想徹底搞明白背后機(jī)制的進(jìn)階用戶(hù)第三類(lèi)是想把 WorkBuddy 集成進(jìn)自己工作流、需要理解上下文邊界在哪里的開(kāi)發(fā)者。我會(huì)從設(shè)計(jì)思路講到實(shí)操細(xì)節(jié)再到常見(jiàn)報(bào)錯(cuò)排查盡量把每個(gè)“為什么”都講透。2. 上下文機(jī)制的整體設(shè)計(jì)與核心思路拆解2.1 為什么不能把所有歷史都塞進(jìn)去很多人第一反應(yīng)是既然模型支持 128K 甚至更長(zhǎng)的窗口那我全塞進(jìn)去不就行了理論上可以實(shí)踐上很虧。原因有三層。第一層是成本。Token 是要花錢(qián)的而且很多平臺(tái)的計(jì)費(fèi)方式是輸入 Token 和輸出 Token 分開(kāi)算。你每輪都把幾萬(wàn) Token 的歷史重新發(fā)一遍費(fèi)用會(huì)線性甚至指數(shù)級(jí)上漲。我實(shí)測(cè)過(guò)一個(gè)中等復(fù)雜度的重構(gòu)任務(wù)如果完全不裁剪上下文跑完十輪對(duì)話(huà)消耗的 Token 是裁剪后的 6 到 8 倍。第二層是質(zhì)量。這一點(diǎn)反直覺(jué)但非常重要上下文不是越長(zhǎng)越好。模型在處理超長(zhǎng)上下文時(shí)中間部分的信息容易被“稀釋”業(yè)界管這叫“l(fā)ost in the middle”現(xiàn)象。你把三天前的閑聊和當(dāng)前任務(wù)混在一起模型反而抓不住重點(diǎn)。所以精準(zhǔn)的上下文比冗長(zhǎng)的上下文更有價(jià)值。第三層是穩(wěn)定性。窗口越接近上限請(qǐng)求失敗的概率越高。你可能見(jiàn)過(guò)error running remote compact task: codex ran out of room in the models context這類(lèi)報(bào)錯(cuò)本質(zhì)就是上下文塞爆了壓縮任務(wù)本身都跑不起來(lái)。2.2 WorkBuddy 的分層上下文模型基于上面這些考量WorkBuddy 采用的是分層管理思路我把它拆成四層來(lái)理解層級(jí)內(nèi)容生命周期是否參與壓縮系統(tǒng)層系統(tǒng)指令、角色設(shè)定、工具定義整個(gè)會(huì)話(huà)否始終保留任務(wù)層當(dāng)前任務(wù)目標(biāo)、約束條件、關(guān)鍵決策任務(wù)周期否優(yōu)先保留對(duì)話(huà)層用戶(hù)與 AI 的歷史消息滾動(dòng)窗口是主要壓縮對(duì)象工具層工具調(diào)用參數(shù)與返回結(jié)果單次調(diào)用是結(jié)果可摘要這個(gè)分層的關(guān)鍵在于系統(tǒng)層和任務(wù)層是“錨點(diǎn)”對(duì)話(huà)層和工具層是“可壓縮的浮層”。當(dāng)上下文逼近上限時(shí)WorkBuddy 會(huì)優(yōu)先壓縮對(duì)話(huà)層和工具層把冗長(zhǎng)的歷史對(duì)話(huà)摘要成一段簡(jiǎn)短描述把大塊的工具返回結(jié)果提煉成結(jié)論。這樣既保住了任務(wù)的方向感又騰出了空間。2.3 compact 機(jī)制的設(shè)計(jì)意圖熱詞里頻繁出現(xiàn)的compact就是這套壓縮機(jī)制的核心動(dòng)作。它的設(shè)計(jì)意圖不是“刪掉歷史”而是“用更少的 Token 表達(dá)同樣的信息”。舉個(gè)生活化的類(lèi)比你整理房間不是把東西扔了而是把散落各處的雜物裝進(jìn)收納箱貼上標(biāo)簽。下次要用的時(shí)候看標(biāo)簽就知道箱子里是什么。compact 觸發(fā)通常有兩種情況一是主動(dòng)觸發(fā)當(dāng)上下文使用率達(dá)到某個(gè)閾值常見(jiàn)配置是 70% 到 80%時(shí)自動(dòng)執(zhí)行二是被動(dòng)觸發(fā)當(dāng)請(qǐng)求因?yàn)槌L(zhǎng)失敗時(shí)系統(tǒng)嘗試壓縮后重試。理解這個(gè)區(qū)別很重要因?yàn)楹芏鄨?bào)錯(cuò)恰恰發(fā)生在被動(dòng)壓縮階段——壓縮任務(wù)本身也需要調(diào)用模型如果此時(shí)模型資源緊張就會(huì)失敗。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 Token 到底是怎么算的要管好上下文先得知道 Token 是怎么消耗的。Token 不是字?jǐn)?shù)也不是字符數(shù)它是模型分詞器Tokenizer切分后的最小單位。英文里一個(gè)常見(jiàn)單詞通常是 1 個(gè) Token一個(gè)生僻詞可能被切成 2 到 3 個(gè)中文里一個(gè)字通常是 1 到 2 個(gè) Token具體取決于分詞器。粗略估算的話(huà)可以記住幾個(gè)經(jīng)驗(yàn)值英文約 4 個(gè)字符 1 個(gè) Token中文約 1.5 到 2 個(gè)字符 1 個(gè) Token。代碼比較特殊因?yàn)榉?hào)多往往比自然語(yǔ)言更費(fèi) Token。一段 100 行的 Python 代碼可能就要 800 到 1200 個(gè) Token。實(shí)操中你不需要手算WorkBuddy 一般會(huì)在界面上顯示當(dāng)前上下文的 Token 用量。但你要有這個(gè)意識(shí)你上傳的每一個(gè)文件、粘貼的每一段日志都在吃 Token 預(yù)算。我見(jiàn)過(guò)有人把整個(gè)項(xiàng)目的日志文件拖進(jìn)去結(jié)果一輪對(duì)話(huà)就爆了窗口。3.2 上下文窗口的邊界與預(yù)留這里有個(gè)容易被忽略的細(xì)節(jié)上下文窗口不是全部給輸入的。模型的輸出也要占空間而且工具調(diào)用的返回也要占空間。所以實(shí)際可用的輸入預(yù)算通常是窗口大小減去一個(gè)預(yù)留值。假設(shè)模型窗口是 128KWorkBuddy 通常會(huì)預(yù)留 8K 到 16K 給輸出和工具調(diào)用。那么你的輸入實(shí)際上限大概是 112K 到 120K。如果你把輸入塞到 125K請(qǐng)求就會(huì)失敗。這就是為什么有時(shí)候你看著“還沒(méi)滿(mǎn)”但就是報(bào)錯(cuò)。提示在配置上下文策略時(shí)把壓縮閾值設(shè)在窗口的 70% 左右比較穩(wěn)妥。留出的 30% 是給輸出、工具調(diào)用和壓縮任務(wù)本身用的緩沖。3.3 哪些內(nèi)容該保留哪些該壓縮這是實(shí)操中最考驗(yàn)判斷力的地方。我的經(jīng)驗(yàn)是遵循“三留三壓”原則必須保留的任務(wù)的核心目標(biāo)和驗(yàn)收標(biāo)準(zhǔn)這是方向丟了就全亂已經(jīng)確認(rèn)的關(guān)鍵決策比如“用 PostgreSQL 不用 MySQL”用戶(hù)明確表達(dá)的偏好和約束比如“不要用第三方庫(kù)”優(yōu)先壓縮的冗長(zhǎng)的探索性對(duì)話(huà)比如“你試試這個(gè)”“不行換那個(gè)”的來(lái)回大塊的原始數(shù)據(jù)比如完整的日志、完整的文件內(nèi)容已經(jīng)完成的中間步驟的詳細(xì)過(guò)程保留結(jié)論即可這個(gè)原則背后的邏輯是模型需要的是“當(dāng)前狀態(tài)”和“下一步該做什么”而不是“我們是怎么走到這里的”。過(guò)程對(duì)人有價(jià)值對(duì)模型的價(jià)值有限。3.4 自定義指令對(duì)上下文的影響熱詞里有個(gè)workbuddy自定義指令推薦這跟上下文管理關(guān)系很大。自定義指令本質(zhì)上是系統(tǒng)層的一部分它每輪都會(huì)參與請(qǐng)求所以指令寫(xiě)得越長(zhǎng)每輪消耗的固定 Token 就越多。我見(jiàn)過(guò)有人寫(xiě)了 2000 字的自定義指令結(jié)果每輪對(duì)話(huà)光指令就吃掉 3000 多 Token。十輪下來(lái)就是 3 萬(wàn) Token 的純開(kāi)銷(xiāo)。所以自定義指令要精煉把真正影響行為的規(guī)則寫(xiě)進(jìn)去別寫(xiě)成說(shuō)明書(shū)。一個(gè)實(shí)用的技巧是把長(zhǎng)期穩(wěn)定的規(guī)則放自定義指令把當(dāng)前任務(wù)的特殊要求放在對(duì)話(huà)里說(shuō)。這樣任務(wù)結(jié)束后特殊要求隨對(duì)話(huà)一起被壓縮掉不會(huì)長(zhǎng)期占用預(yù)算。4. 實(shí)操過(guò)程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 從零配置一套上下文策略假設(shè)你現(xiàn)在要用 WorkBuddy 做一個(gè)中等規(guī)模的重構(gòu)任務(wù)我按實(shí)際操作順序走一遍。第一步明確任務(wù)邊界。在開(kāi)始前先用一段話(huà)把任務(wù)目標(biāo)、范圍、約束寫(xiě)清楚作為第一條消息發(fā)出去。這段話(huà)會(huì)成為任務(wù)層的錨點(diǎn)后續(xù)壓縮時(shí)會(huì)優(yōu)先保留。比如任務(wù)把 utils 目錄下的 5 個(gè)文件重構(gòu)為類(lèi)型注解完整的 Python 3.11 風(fēng)格。 約束不引入新的第三方依賴(lài)保持現(xiàn)有函數(shù)簽名不變每個(gè)函數(shù)補(bǔ)充 docstring。 驗(yàn)收mypy 檢查通過(guò)現(xiàn)有單元測(cè)試全部通過(guò)。第二步分批投喂文件。不要一次性把 5 個(gè)文件全傳上去。先傳 1 個(gè)讓 AI 處理完確認(rèn)風(fēng)格符合預(yù)期再傳下一個(gè)。這樣做的好處是前面的處理結(jié)果會(huì)作為“風(fēng)格樣例”留在上下文里后面的文件處理會(huì)更一致同時(shí)避免了單輪 Token 爆炸。第三步設(shè)置壓縮閾值。在 WorkBuddy 的配置里把自動(dòng)壓縮閾值設(shè)在 70%。這個(gè)值不是拍腦袋來(lái)的前面算過(guò)留 30% 給輸出和工具調(diào)用。如果你用的是長(zhǎng)窗口模型可以適當(dāng)放寬到 75%但別超過(guò) 80%。第四步監(jiān)控 Token 用量。每處理完一個(gè)文件看一眼用量。如果發(fā)現(xiàn)增長(zhǎng)過(guò)快說(shuō)明某個(gè)環(huán)節(jié)產(chǎn)生了大量冗余內(nèi)容及時(shí)清理。比如工具返回的完整文件內(nèi)容如果已經(jīng)處理完可以讓它只保留摘要。4.2 手動(dòng)觸發(fā) compact 的時(shí)機(jī)自動(dòng)壓縮雖然省心但有時(shí)候你需要手動(dòng)控制。我的經(jīng)驗(yàn)是在任務(wù)階段切換時(shí)手動(dòng)觸發(fā)一次 compact 最劃算。比如從“代碼生成”階段切換到“測(cè)試驗(yàn)證”階段此時(shí)前面的生成過(guò)程細(xì)節(jié)已經(jīng)不重要了壓縮掉能騰出大量空間。手動(dòng)觸發(fā)的方式通常是在對(duì)話(huà)里輸入特定指令或者點(diǎn)擊界面上的壓縮按鈕。觸發(fā)后你會(huì)看到歷史對(duì)話(huà)被折疊成一段摘要。這時(shí)候要檢查一下摘要有沒(méi)有丟掉關(guān)鍵決策。如果丟了手動(dòng)補(bǔ)一句“注意之前確認(rèn)用 PostgreSQL”把它拉回來(lái)。4.3 工具調(diào)用結(jié)果的精簡(jiǎn)處理工具調(diào)用是 Token 消耗大戶(hù)。一次文件讀取可能返回幾千 Token一次命令執(zhí)行可能返回上萬(wàn) Token 的日志。如果這些結(jié)果全部原樣留在上下文里幾輪就爆了。我的做法是讓工具返回結(jié)果時(shí)就走摘要路徑。比如讀文件不要返回全文返回“文件 X共 N 行關(guān)鍵函數(shù)有 A、B、C其中 A 的實(shí)現(xiàn)是……”。執(zhí)行命令不要返回完整日志返回“命令成功/失敗關(guān)鍵輸出是……錯(cuò)誤信息是……”。如果工具本身不支持摘要那就在拿到結(jié)果后讓 AI 先總結(jié)一遍然后你手動(dòng)把原始結(jié)果從上下文里刪掉只留總結(jié)。這個(gè)操作稍微麻煩但對(duì)長(zhǎng)任務(wù)來(lái)說(shuō)是必須的。4.4 一個(gè)完整的上下文生命周期示例我把一個(gè)真實(shí)任務(wù)的上下文變化記錄下來(lái)你能直觀看到每個(gè)階段的狀態(tài)階段操作上下文用量備注開(kāi)始發(fā)送任務(wù)定義2K任務(wù)層錨點(diǎn)建立處理文件1上傳生成驗(yàn)證18K含文件內(nèi)容和生成結(jié)果處理文件2上傳生成驗(yàn)證34K累積增長(zhǎng)階段切換手動(dòng) compact12K壓縮掉過(guò)程細(xì)節(jié)處理文件3-5批量處理45K有樣例參考效率提升測(cè)試階段運(yùn)行測(cè)試修復(fù)58K工具結(jié)果占大頭收尾生成報(bào)告62K未觸發(fā)壓縮安全可以看到如果沒(méi)有中間那次 compact到測(cè)試階段就會(huì)逼近 80K接近很多模型的實(shí)用上限。壓縮一次直接省下 22K這就是主動(dòng)管理上下文的價(jià)值。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 compact 相關(guān)報(bào)錯(cuò)速查熱詞里出現(xiàn)頻率最高的就是各種 compact 報(bào)錯(cuò)我整理成一張表方便對(duì)照排查報(bào)錯(cuò)信息關(guān)鍵詞可能原因排查方向selected model is at capacity壓縮任務(wù)調(diào)用的模型資源緊張換一個(gè)模型執(zhí)行壓縮或稍后重試stream disconnected before completion網(wǎng)絡(luò)中斷或流式響應(yīng)被切斷檢查網(wǎng)絡(luò)穩(wěn)定性關(guān)閉流式模式重試codex ran out of room in context壓縮前上下文已超限手動(dòng)清理歷史降低壓縮閾值unexpected status 401 unauthorized認(rèn)證憑證失效重新登錄檢查 Token 有效期your access token could not be refreshed刷新令牌失敗退出重新登錄檢查系統(tǒng)時(shí)間transport error / network error網(wǎng)絡(luò)層問(wèn)題檢查代理設(shè)置、DNS、防火墻這些報(bào)錯(cuò)里selected model is at capacity和stream disconnected是最常見(jiàn)的兩個(gè)。前者本質(zhì)是資源問(wèn)題不是你的配置問(wèn)題換個(gè)模型或者錯(cuò)峰重試就行。后者多半是網(wǎng)絡(luò)抖動(dòng)尤其是流式輸出時(shí)連接一斷整個(gè)壓縮就失敗了。5.2 Token 失效與登錄問(wèn)題的處理熱詞里還有一堆token exchange failed、sign-in could not be completed之類(lèi)的登錄報(bào)錯(cuò)。這里的 Token 和上下文里的 Token 是兩碼事前者是認(rèn)證令牌后者是計(jì)費(fèi)單位別搞混了。認(rèn)證 Token 失效的典型表現(xiàn)是昨天還能用今天打開(kāi)就提示登錄失敗。常見(jiàn)原因有三個(gè)一是 Token 自然過(guò)期這個(gè)重新登錄即可二是系統(tǒng)時(shí)間不準(zhǔn)導(dǎo)致 Token 校驗(yàn)失敗校準(zhǔn)時(shí)間就能解決三是網(wǎng)絡(luò)環(huán)境變化觸發(fā)了安全校驗(yàn)這種情況換個(gè)網(wǎng)絡(luò)環(huán)境試試。注意遇到token exchange failed: token endpoint returned status 403這類(lèi)報(bào)錯(cuò)先別急著反復(fù)重試反復(fù)失敗可能觸發(fā)風(fēng)控。先檢查網(wǎng)絡(luò)環(huán)境和系統(tǒng)時(shí)間再重新登錄。5.3 上下文“失憶”的排查思路比報(bào)錯(cuò)更隱蔽的問(wèn)題是“AI 好像忘了之前說(shuō)過(guò)的”。排查這個(gè)要按順序來(lái)先看是不是被壓縮掉了。檢查最近的 compact 記錄看關(guān)鍵信息有沒(méi)有進(jìn)摘要。如果沒(méi)進(jìn)說(shuō)明它被判定為低優(yōu)先級(jí)你需要手動(dòng)重申。再看是不是被淹沒(méi)了。上下文里塞了太多無(wú)關(guān)內(nèi)容關(guān)鍵信息被稀釋。這時(shí)候清理一下無(wú)關(guān)內(nèi)容把關(guān)鍵約束重新強(qiáng)調(diào)一遍。最后看是不是模型本身的問(wèn)題。有些模型在長(zhǎng)上下文下確實(shí)會(huì)“走神”這時(shí)候換個(gè)模型試試或者把任務(wù)拆得更細(xì)。我的經(jīng)驗(yàn)是關(guān)鍵約束要定期重申。別指望說(shuō)一次模型就永遠(yuǎn)記住尤其是在長(zhǎng)任務(wù)里。每隔幾輪用一句話(huà)把核心約束再點(diǎn)一遍成本很低效果很好。5.4 幾個(gè)我踩過(guò)的坑第一個(gè)坑是過(guò)度依賴(lài)自動(dòng)壓縮。有次我跑一個(gè)長(zhǎng)任務(wù)沒(méi)管上下文結(jié)果自動(dòng)壓縮把一段關(guān)鍵的接口定義摘要成了“定義了若干接口”細(xì)節(jié)全丟了后面生成的代碼全對(duì)不上。從那以后我在關(guān)鍵節(jié)點(diǎn)都會(huì)手動(dòng)檢查摘要質(zhì)量。第二個(gè)坑是把日志當(dāng)上下文。有次調(diào)試一個(gè) bug我把幾百行日志全貼進(jìn)去結(jié)果那一輪直接爆窗口。后來(lái)學(xué)乖了先自己篩出關(guān)鍵幾行再貼進(jìn)去。第三個(gè)坑是自定義指令寫(xiě)太長(zhǎng)。前面提過(guò)每輪都吃 Token。我精簡(jiǎn)到 300 字以?xún)?nèi)后同樣的任務(wù)省了將近 20% 的 Token。第四個(gè)坑是在壓縮時(shí)切換模型。有次壓縮任務(wù)失敗我隨手換了個(gè)模型重試結(jié)果新模型對(duì)上下文的理解方式不同摘要出來(lái)的東西風(fēng)格全變了。后來(lái)我固定用同一個(gè)模型做壓縮保持一致性。6. 上下文優(yōu)化的進(jìn)階技巧6.1 用結(jié)構(gòu)化格式降低 Token 消耗同樣的信息用不同格式表達(dá)Token 消耗能差不少。我的實(shí)測(cè)經(jīng)驗(yàn)是表格比自然語(yǔ)言省列表比段落省鍵值對(duì)比列表更省。舉個(gè)例子描述一個(gè)函數(shù)的約束自然語(yǔ)言寫(xiě)法是“這個(gè)函數(shù)接收兩個(gè)參數(shù)第一個(gè)是字符串類(lèi)型的名稱(chēng)第二個(gè)是整數(shù)類(lèi)型的數(shù)量返回值是布爾類(lèi)型表示是否成功”。換成鍵值對(duì)就是函數(shù): process_order 參數(shù): name(str), count(int) 返回: bool后者 Token 消耗大概是前者的三分之一。所以在給 AI 傳遞結(jié)構(gòu)化信息時(shí)盡量用緊湊格式。6.2 分任務(wù)隔離上下文如果你同時(shí)跑多個(gè)不相關(guān)的任務(wù)千萬(wàn)別在同一個(gè)會(huì)話(huà)里做。每個(gè)任務(wù)開(kāi)一個(gè)新會(huì)話(huà)上下文互不干擾。這看起來(lái)是常識(shí)但我見(jiàn)過(guò)有人為了“方便”把所有任務(wù)堆在一個(gè)會(huì)話(huà)里結(jié)果上下文里一半是無(wú)關(guān)內(nèi)容模型頻繁串臺(tái)。WorkBuddy 支持多會(huì)話(huà)管理善用這個(gè)功能。一個(gè)任務(wù)一個(gè)會(huì)話(huà)任務(wù)結(jié)束就歸檔需要時(shí)再開(kāi)新的。6.3 上下文模板化對(duì)于重復(fù)性的任務(wù)把任務(wù)定義、約束、驗(yàn)收標(biāo)準(zhǔn)做成模板每次開(kāi)新任務(wù)直接套用。這樣既保證了任務(wù)層錨點(diǎn)的質(zhì)量又省去了每次重新組織語(yǔ)言的時(shí)間。模板本身不占額外 Token因?yàn)樗褪悄愕谝粭l消息的內(nèi)容。我常用的模板結(jié)構(gòu)是任務(wù)目標(biāo)、輸入說(shuō)明、約束條件、驗(yàn)收標(biāo)準(zhǔn)、輸出格式。五段式每段一兩句話(huà)總共控制在 200 字以?xún)?nèi)。6.4 監(jiān)控與調(diào)優(yōu)的閉環(huán)上下文管理不是一次配置就完事的需要持續(xù)監(jiān)控和調(diào)優(yōu)。我的做法是記錄每次任務(wù)的 Token 消耗曲線找出消耗異常的環(huán)節(jié)。比如發(fā)現(xiàn)某類(lèi)工具調(diào)用特別費(fèi) Token就針對(duì)性地優(yōu)化它的返回格式。這個(gè)閉環(huán)跑幾輪之后你會(huì)對(duì)自己的任務(wù)模式有清晰的認(rèn)知配置也會(huì)越來(lái)越精準(zhǔn)。到那時(shí)候上下文管理就從“救火”變成了“預(yù)防”任務(wù)成功率會(huì)明顯提升。7. 關(guān)于上下文管理的一點(diǎn)個(gè)人體會(huì)我在實(shí)際使用 WorkBuddy 處理長(zhǎng)任務(wù)的過(guò)程中最大的體會(huì)是上下文管理的本質(zhì)是信息優(yōu)先級(jí)管理。工具提供的 compact、閾值配置、分層機(jī)制都是手段真正決定效果的是你判斷“什么信息在什么階段最重要”的能力。這個(gè)能力沒(méi)法靠配置解決只能靠實(shí)踐積累。我的建議是每次任務(wù)結(jié)束后花兩分鐘復(fù)盤(pán)一下這次上下文里哪些內(nèi)容是真正有用的哪些是白占空間的。積累幾次之后你對(duì)信息價(jià)值的判斷會(huì)越來(lái)越準(zhǔn)配置也會(huì)越來(lái)越順手。最后分享一個(gè)小技巧如果你不確定某段內(nèi)容該不該保留就問(wèn)自己一句“如果刪掉它下一步會(huì)不會(huì)做錯(cuò)”。如果答案是“不會(huì)”那就大膽壓縮掉。上下文空間是稀缺資源留給真正影響決策的信息。