Agent 擁有更多 context，表面上應該更聰明。實務上卻常出現相反結果：提示詞越長，重要限制越容易被埋住；歷史記憶越多，舊規則與新規則越容易同時出現；為了避免遺漏，把整個知識庫送進模型，反而讓每一次判斷都更慢、更貴，也更難追查。

真正需要的不是 Maximum Context，而是 Minimum Sufficient Context：足以讓 Agent 在特定任務與風險條件下做出正確下一步的最小脈絡集合。

「最小」不是省 token 的口號，「充分」也不是讓模型覺得自己知道答案。這個概念必須由任務結果來驗證：少了某類資訊，成功率會下降或風險會上升；再加入更多資訊，結果沒有改善，甚至開始受干擾。只有這樣，才能找到工程上的邊界。

為什麼 All Context 會失敗

Anthropic 的 context engineering 指南把 context 當作有限資源，強調保存清楚訊號、漸進揭露與在需要時取回資料。即使模型 context window 持續變大，注意力、延遲、成本與資料治理仍然有限。

把所有內容一次放入，至少有四個問題：

  1. 相關性稀釋：真正影響任務的限制被大量背景資訊包圍。
  2. 時間衝突：舊版本、舊偏好與新狀態同時出現，模型只能猜哪一個較新。
  3. 權限擴散：原本只適用某個專案的敏感資訊，被帶進不相關任務。
  4. 責任模糊：回答出錯時，很難知道是檢索、排序、來源、規則還是模型推理造成。

MemGPT以分層記憶管理有限 context，核心啟示不是「外接一個更大的資料庫」，而是不同資訊應有不同駐留位置與載入時機。記憶的價值取決於調度，而不是容量。

三個溫度層，對應三種取用成本

可以先把 Personal Context 依使用方式分成 hot、warm 與 cold 三層。這同樣是實作分類，不是正式標準。

Hot context：每一步都要遵守

Hot context 放短小、穩定且高影響的內容，例如這次任務目標、明確禁令、輸出格式、可用權限與驗收條件。它應該可讀、可測，並控制在足以被持續注意的範圍。

常見錯誤是把所有組織規範都設成 hot。若一份規則有數百條，Agent 仍然無法在每一步同等重視。更好的做法是保留不可違反的 invariant，再按工作階段載入相關細節。

Warm context：任務開始時組裝

Warm context 包含專案結構、近期決策、相關偏好與這次進度。它通常由任務路由器根據範圍組合，而不是永久常駐。像 AGENTS.md的巢狀指令與 closest-wins 邏輯，就提供一種按專案位置決定規則範圍的方式。

Cold context：需要時才查

Cold context 是完整來源、歷史事件、低頻知識與大量附件。它不必直接進 prompt，而是保留可搜尋的索引、時間、來源與權限。Agent 先知道「有這類資料」以及「何時應查」，再透過工具按需取回。

Agent Skills 規格採 progressive disclosure，先用名稱與描述判斷是否相關，需要時才載入完整指令與資源。這種做法適合程序知識，但 Skill 是否正確、是否過期，仍需要獨立驗證。

Sufficient 必須包含完成條件

很多 context pipeline 只在任務開始前選資料，卻沒有把完成條件放進來。Agent 知道怎麼做，卻不知道什麼才算做完，最後只能以自己生成的文字判斷成功。

Minimum Sufficient Context 至少要回答五件事：

  • Objective：這次要改變什麼，不做什麼。
  • Constraints：權限、時間、格式、安全與不可破壞的條件。
  • Relevant state：環境現在在哪個版本與進度。
  • Available actions：可以使用哪些工具，以及何時需要核准。
  • Outcome oracle：用什麼外部證據判定完成或失敗。

最後一項經常被忽略。若任務是部署網站，oracle 可以包含建置成功、正式網址回應、關鍵內容存在與錯誤監控；若任務是更新資料，則要從目的端查回，而不是只看寫入請求回傳 200。

τ-bench以環境最終狀態評量工具型 Agent，Anthropic 的 Agent eval 指南也提醒評估要涵蓋多次試驗與失敗模式。這些做法讓 sufficient 不再由 prompt 長度決定，而由可觀察結果決定。

用 Context Budget 取代無限追加

實作時，可以替每個任務設定 context budget。Budget 不只計算 token，也包含敏感性、更新成本與錯誤影響。每一段候選脈絡進入前，先問：

  1. 它會改變哪個決策？
  2. 來源是否仍有效？
  3. 與現有規則衝突時怎麼處理？
  4. Agent 是否有權在這個任務使用？
  5. 若不放入，能否在需要時透過工具取得？

無法回答第一題的內容，多半不必進入 hot context；需要完整證據但低頻使用的內容，應留在 cold layer；會改變高風險行動的資料，則要帶著 provenance 與人工核准條件。

壓縮也不能只追求更短。摘要如果移除版本、限制與反例，會讓字數下降，風險卻上升。理想壓縮應保留決策所需的 invariant、未解問題與回查入口，並標示它是衍生內容，而非原始來源。

用刪減實驗找到真正的最小集合

Minimum Sufficient Context 不能只靠直覺設計。可針對一組重複任務做簡單的 ablation：先只給目標與工具，再依序加入 Profile、State、Knowledge、Experience，觀察任務成功率、追問次數、延遲、成本、錯誤引用與人工介入。

接著反向刪減。若移除某一類資料，結果沒有明顯改變，它可能不必常駐；若移除後高風險錯誤增加，就應把它提升為必要 invariant。不同任務會得到不同答案，不能期待一套全域 prompt 同時服務研究、寫作、部署與客戶溝通。

也要把「正確拒絕」列入成功。缺乏必要來源時，Agent 應該知道自己沒有充分 context，而不是用語氣填補空白。LongMemEval把 abstention 納入長期記憶評量，正是因為找不到答案時不亂答，也是 context 品質的一部分。

Personal Context 的成熟度，不在於 Agent 能背出多少關於你的資料，而在於它能否為每個任務組出足夠、可信、獲授權且可追溯的脈絡。知道全部看起來很強；知道現在需要什麼、缺什麼，以及何時應停下來確認，才是可靠的 Agent Experience。

參考來源