上一篇討論了工具怎樣被發現和調用。工具執行以後，結果會回到模型；任務繼續推進，又會產生新的代碼、資料、判斷和測試輸出。這些信息怎樣進入下一輪推理，就是 Context Engineering 要處理的問題。

結合 Anthropic 的《Effective context engineering for AI agents》，本文從三個層次展開：

• 管理對象： Context 與 Prompt 有什麼區別，窗口容量為什麼不能代表信息利用質量。
• 每輪組織： 指令、工具、示例和歷史怎樣配合，怎樣按需檢索並逐步補齊資料。
• 長期維護： Compaction、Structured Notes 與 Subagents 分別怎樣處理歷史、狀態和探索細節。

下面用一個假設的 Java 項目排查貫穿全文：訂單回調疑似被重複處理，需要定位原因並補充迴歸測試；修改範圍限定在回調模塊，不調整支付 SDK。

一、Context Engineering 解決什麼問題h2

1. Prompt Engineering 與 Context Engineering 的區別h3

Prompt Engineering 關注怎樣表達目標、規則和預期輸出；Context Engineering 則進一步組織模型本輪推理能夠看到的完整信息，包括指令之外的工具定義、外部資料、消息歷史和執行結果。

面對回調問題，清楚的指令可以要求“定位重複處理原因，只修改回調模塊”。但模型要作出具體判斷，還需要看到回調入口、狀態更新邏輯，以及對應的失敗證據。指令説明要做什麼，代碼和日誌提供判斷的依據。

而且，不同階段需要的信息並不相同：

用户目標保持不變，支持行動的信息卻在持續變化。因此，上下文組織要跟着執行過程更新，不能只在任務開始時準備一次。

這裏還要區分外部環境擁有的信息與模型當前看見的信息。源碼存在倉庫中，筆記存在文件裏，只有相關內容被讀取並進入本輪輸入，才能直接參與模型判斷。這與執行環境中的文件狀態，是不同層次的問題。

2. Context Window 與 Context Rot：容量與信息利用h3

Context Window 規定模型能夠容納的 token 範圍，解決的是容量問題。但資料裝得下，仍然需要模型從中找到、關聯並正確使用關鍵內容。

例如，排查重複回調時，入口代碼、狀態更新和失敗斷言能夠補全因果關係；整份依賴下載日誌通常沒有同樣的價值。兩者都會佔用空間，卻不一定同樣有助於任務。

Anthropic 用 **Attention Budget（注意力預算）**描述信息處理能力的有限性。這裏可以把它理解為工程上的提醒：輸入越複雜，越需要有意識地組織信息，而不是一項能像 token 上限一樣精確扣減的配額。

Context Rot 則指長上下文中信息利用表現可能退化的現象。Chroma 的研究通過受控任務發現，模型表現會隨輸入長度和干擾內容變化，並不是均勻使用窗口中的所有信息。

這意味着，評估上下文不能只看長度。需要同時檢查材料是否相關、關鍵證據是否容易定位，以及當前模型在任務中是否能正確使用它們。長輸入並非一律無效，短輸入也不一定充分。

過時信息還需要單獨處理。舊日誌來自修改前的代碼，新的測試已經覆蓋了另一條路徑；如果沒有交代時間和版本，模型就可能把不同狀態混在一起。信息選擇既要控制數量，也要保持來源和狀態清楚。

二、每輪推理的上下文怎樣組織h2

3. System Prompt：明確目標、規則與交付要求h3

指令為行動提供方向。它需要足夠具體，讓模型知道依據什麼判斷；也要保留空間，讓模型能夠根據實際證據調整排查路線。

只寫“你是一名優秀的 Java 工程師”，沒有説明當前任務怎樣完成。反過來，提前窮舉所有文件和錯誤分支，又容易把尚未證實的判斷固定進流程。

對這個排查場景，可以把任務指導整理為：

目标：定位订单回调重复处理的原因，并补充相关测试。
范围：只修改回调模块，不调整支付 SDK 或无关接口。
证据：区分已复现问题、代码推断与尚未验证的假设。
交付：说明原因、修改点、实际验证结果和未解决问题。

這些要求明確了目標、邊界和交付標準，沒有規定每一步必須調用什麼工具。模型可以先查入口，也可以根據失敗日誌轉去檢查狀態更新；路線可以變化，任務邊界保持清楚。

系統指令、當前用户要求和任務資料可以分別組織，避免背景、規則與證據混成一整段。重要的是各部分職責明確，格式本身不是目的。

4. Tools、Examples 與 History：能力、用法和當前狀態h3

指令之外，模型還需要知道能使用什麼能力、怎樣使用，以及任務已經推進到哪裏。

工具定義清楚，模型才容易選擇合適的動作；結果清楚，模型才能繼續判斷。例如，測試輸出需要保留失敗用例、斷言和定位入口，通常不需要把所有重複的構建過程同等帶入下一輪。

示例也應當有代表性。展示幾種不同的典型情況，比堆積大量近似例子更容易説明規則；需要覆蓋的行為不同，例子才有增加的理由。

歷史則要保留對後續有影響的狀態：當前目標、已確認結論、必要的失敗嘗試和未完成項。連續三次讀取相同文件產生的重複內容，可以縮減；“併發路徑尚未驗證”卻不能因為篇幅短就被刪掉。

信息是否值得保留，要看它對下一步判斷的作用。 同一段日誌在定位時可能需要完整讀取，原因查明後則可能只需保留關鍵記錄與原始文件入口。

5. Just-in-time Retrieval：在需要時取回資料h3

按需檢索的基本做法，是先保留輕量入口，再通過工具取得當前需要的內容。入口可以是文件路徑、鏈接、查詢條件或已保存結果的位置。

排查開始時，可以先搜索回調入口。找到 PaymentCallbackService.java後，再讀取相關方法；發現狀態更新由另一個模塊負責，再補充那部分實現。模型不必在第一次調用前讀完整個倉庫。

它改變的是資料進入 Context 的時機：

保存入口 → 判斷當前缺什麼 → 取得相關內容 → 依據結果繼續行動

文件名和目錄可以幫助定位，但結論仍要來自實際內容。看到 tests/裏的同名文件，能推測它與測試有關，不能直接認定它覆蓋了當前故障。

這種方式減少了提前加載的負擔，也增加了運行時查詢。資料定位錯誤，就會多走幾步；沒有合適工具，關鍵內容也可能一直找不到。

因此，可以把穩定且高頻的目標、約定提前提供，把大體積或使用不確定的資料留到需要時再取。預先檢索與 Agent 自主搜索可以配合，不必二選一。

6. Progressive Disclosure：逐層補齊相關信息h3

Progressive Disclosure（漸進加載）強調從粗到細地建立理解：每次取得的信息，幫助確定下一步應該讀什麼。

對回調問題，一段探索可以是：

1. 通過目錄和文件名找到候選模塊。
2. 通過搜索結果定位回調方法。
3. 讀取方法及相關調用，理解判斷與狀態更新。
4. 補充測試、日誌或協議説明，核對尚未確定的關係。

它與按需檢索密切相關，但關注點不同：按需檢索回答什麼時候取資料，漸進加載回答怎樣逐步深入資料。

如果冪等檢查與狀態更新分處兩個方法，讀取第一個以後還需要繼續補齊第二個。逐層加載的結束條件，是當前判斷已經擁有必要依據，而不是上下文已經足夠短。

這一過程也説明，上下文維護可以跟着 Agent Loop 進行：先組織已有信息，取得執行反饋，再更新狀態、清理冗餘，並決定下一輪還需要什麼。

三、長任務的上下文怎樣維護h2

即使按需讀取，長任務仍會積累很多歷史。接下來需要區分三類工作：怎樣縮短已有過程，怎樣保存重要狀態，怎樣安排新的獨立探索。

7. Compaction：壓縮會話歷史h3

Compaction 把較長曆史整理為更緊湊的表示，讓後續推理能夠依據摘要和必要材料繼續工作。

對回調排查，需要保留的是目標與範圍、已確認原因、實際修改、驗證結果和未解決問題；重複搜索或已無繼續價值的工具輸出，則可以縮減。

例如，下面兩份摘要提供的工作條件不同：

回調模塊已修復，測試基本通過。

已調整回調模塊的冪等檢查，順序重複回調測試通過；併發路徑尚未驗證。支付 SDK 未修改。相關差異與測試日誌已保存，下一步檢查併發測試。

第二份保留了已完成與未完成之間的邊界。下一輪據此知道應該繼續做什麼，也能回到代碼和日誌核對依據。

壓縮首先要避免遺漏關鍵事項，再減少冗餘。過度縮短可能把“部分測試通過”改寫成“問題解決”，也可能丟掉設計約束。摘要越緊湊，留下可回查入口越重要。

對於已經無關或能夠可靠重取的舊輸出，也可以清理原文。無法重現的關鍵失敗證據，則應先保存，不能默認再次執行一定得到相同結果。

8. Structured Notes：保存可恢復的任務狀態h3

Structured Notes 把進度和關鍵判斷寫到 Context 外，再在需要繼續時讀取。

與 Compaction 相比，它的重點不是縮短整段對話，而是維護一份明確的工作狀態。例如，任務筆記可以這樣組織：

task: 排查订单回调重复处理
scope: 回调模块与相关测试；不调整支付 SDK
confirmed:
  - 顺序重复回调测试已通过
pending:
  - 并发回调测试
  - 异常后的状态恢复
evidence:
  - 当前代码差异
  - artifacts/callback-test-run.log
next_action: 检查并发回调路径

已確認、待驗證、證據與下一步被分開，後續不必從幾十輪對話裏重新整理這些關係。

筆記還需要隨工作更新。代碼再次修改以後，舊測試結果對應的是舊版本；假設被推翻，也要修訂判斷。保存和取回都成功，內容仍然可能過時，所以恢復時需要結合當前環境核對。

外部記錄提供持久狀態，讀取操作讓狀態重新進入模型輸入。 兩個環節缺一不可，寫出一個文件並不代表後續調用自動獲得了它。

9. Subagents：隔離獨立探索的上下文h3

當任務可以分成相對獨立的探索，可以讓子 Agent 使用自己的上下文處理細節，再向主 Agent 返回結論和證據。

例如，一個分支檢查業務代碼中的狀態變化，另一個分支核對協議裏的重試含義。各自可以搜索、讀取和判斷，主 Agent 則重點處理兩份結果之間的聯繫。

這裏的收益不是擴大主模型的窗口，而是把局部探索留在各自的 Context，減少主上下文承接的原始過程。如果最後把所有搜索記錄完整拼回來，信息負擔仍然會回來。

返回結果需要説明結論、依據、未確認項與覆蓋範圍。“沒有發現問題”太模糊；“檢查了順序重複回調，尚未檢查併發狀態更新”才能支持下一步安排。

這種拆分也有成本：輸入需要交代背景，輸出可能遺漏細節，主 Agent還要彙總。需要頻繁共享完整前序判斷的任務，未必適合切開。

上下文隔離也不自動提供文件隔離。如果子 Agent 共用工作目錄，仍需另行管理修改衝突；這裏討論的是信息分工，不是執行環境的隔離機制。

三種策略可以放在一起比較：

它們可以組合：子 Agent 返回發現，主 Agent 將確認的狀態寫入筆記；歷史過長時，再壓縮對話。三者處理不同對象，不應全部歸為一種“自動記憶”。

把信息選擇、檢索與狀態維護連起來h2

回到回調排查，指令提供目標與邊界，工具和資料提供行動能力與判斷依據。按需檢索控制內容進入的時機，漸進加載逐步補齊關係；任務變長以後，再分別處理歷史、外部狀態與獨立探索。

這些安排需要隨着新證據更新。出現新的失敗，不應繼續沿用舊摘要中的成功結論；已經保存且可重取的細節，也不必一直佔據當前窗口。

我理解的上下文質量，最終要落到具體行動上：能否找到相關代碼，能否區分已驗證與待驗證，能否保留修改範圍，以及恢復以後是否能接着推進。

Context Engineering 不是儘量多放資料，也不是一味縮短輸入，而是讓當前信息足以支持行動，並讓重要狀態在執行過程中保持清楚。

幾個關鍵問題，串起信息選擇與長期維護h2

Prompt 已經寫清楚，為什麼還需要 Context Engineering？

指令説明目標與規則，但模型還需要代碼、資料、工具定義和執行結果才能判斷。任務推進後，這些內容會變化。Context Engineering 管理的是每輪完整輸入，清楚的 Prompt 是其中一部分。

沒有裝滿 Context Window，為什麼模型仍可能漏掉信息？

容量上限説明能夠容納多少，不保證每條信息都被同樣可靠地使用。輸入長度、干擾內容和任務要求都會影響表現。需要檢查關鍵證據是否相關、容易定位，以及模型是否實際用對了它。

按需檢索和漸進加載有什麼區別？

按需檢索安排取資料的時機，漸進加載安排探索的層次。可以先按需取得一份完整文檔，也可以從目錄和摘要開始逐層深入；兩者都以取得充分依據為目標。

怎樣判斷一段信息可以移出當前上下文？

先看它是否仍影響下一步，再看能否可靠重取。有版本和入口的源碼可以按需回讀；臨時出現的失敗日誌則應先保存。可以移出當前輸入，不等於可以丟失唯一證據。

Compaction 與 Structured Notes 能互相替代嗎？

不能完全替代。Compaction 壓縮當前歷史，Notes 保存明確的外部狀態。摘要可以引用筆記，筆記也可以幫助壓縮後恢復，但前提是內容準確、入口可用，並在需要時實際讀取。

子 Agent 怎樣減少主上下文的負擔？

獨立處理局部探索，返回足夠支持整體判斷的結果，而不是全部原始過程。收益來自分工和篩選，同時要處理遺漏、證據回查與協調成本；它沒有改變主模型的窗口上限。

怎樣判斷上下文管理確實改善了任務？

不僅看節省了多少 token，還要看目標與範圍是否保留、判斷是否依據當前證據、驗證狀態是否準確，以及恢復任務時是否減少了遺漏和重複工作。更短的輸入只有仍能支持任務時才有價值。

參考資料h2

• Anthropic · Effective context engineering for AI agents
• Chroma · Context Rot: How Increasing Input Tokens Impacts LLM Performance