交流群即將上線
06 · 上下文用完了怎麼辦
症狀先說
聊到第四十輪，你會發現它開始：忘了你半小時前定的約定、 把已經改好的地方又改回去、反覆讀同一個檔案。
這不是模型變笨了，是上下文裡塞滿了噪音。官方文件裡有兩個詞說得挺準：
- 上下文汙染：有用資訊被雜亂的中間輸出淹沒。
- 上下文腐化：隨著聊天被相關性低的細節填滿，效能逐漸下降。
探索記錄、測試日誌、堆疊跟蹤、指令輸出——這些中間產物一旦全留在主執行緒裡， 真正要緊的需求和約束就被擠到角落了。
三條出路
一、壓縮
Codex 會在歷史記錄逼近閾值時自動壓縮，把前面的對話濃縮成摘要。相關配置項：
| 配置項 | 作用 |
|---|---|
model_context_window | 當前模型可用的上下文視窗 Token 數 |
model_auto_compact_token_limit | 觸發自動壓縮的 Token 閾值（不設就用模型預設值） |
model_auto_compact_token_limit_scope | 閾值按什麼算：total（完整當前上下文，預設）或 body_after_prefix（只算壓縮視窗字首之後的增長量） |
壓縮不是免費的：它把細節換成了摘要，之前那些「你說過不要動 X」的具體約定 有可能在這一步被抹平。所以更好的做法是別等它壓縮。
二、開新工作階段
最簡單也最被低估的一招。一個任務幹完就開新的，別在一個工作階段裡連著做三件不相關的事。
關鍵約定寫在 AGENTS.md 裡，開新工作階段不用重講—— 這也是上一篇為什麼值得先做。
需要接著之前那次幹：
bash
codex resume三、拆給子智慧體
要讀的東西實在太多的時候，別讓主執行緒去讀。讓它派子智慧體去讀， 只把結論帶回來。這是官方明確推薦的用法：
子智慧體工作流將容易產生干擾資訊的工作移出主執行緒。
主智慧體守住需求、決策和最終輸出；子智慧體去探索、跑測試、翻日誌， 返回摘要而不是原始輸出。
在 CLI 裡直接要求就行：
text
用并行子智能体审查这个分支：一个看安全风险，一个看测试缺口，一个看可维护性。
三个都跑完之后，按类别汇总发现，带上文件引用。執行期間用 /agent 檢視和切換各個智慧體執行緒。
代價是 Token：每個子智慧體獨立用模型和工具，所以子智慧體工作流比同等的單智慧體執行更費。 另外先用在探索、測試、分流、總結這類以讀為主的任務上； 多個智慧體同時改程式碼容易衝突，協調開銷也大。
詳細用法見 進階 03 · 子智慧體與並行。
一個實用的順序
上下文吃緊的時候按這個順序想：
- 這段對話還有必要繼續嗎？ 任務換了就開新工作階段。
- 那些日誌和探索結果，主執行緒真的需要嗎？ 不需要就拆給子智慧體。
- 約定是不是每次都在重講？ 寫進
AGENTS.md。 - 確實是一個長任務？ 再去調壓縮閾值。
大部分人卡在第 4 步調參數，其實問題在第 1 步。
下一步
快速上手到這兒就完了。接著可以：
- 想讓它接上公司的工具 → 進階 02 · 用 MCP 接上你的工具
- 手上有具體的活 → 實戰案例
- 想查某個配置項 → 官方文件映象