Context-Engineering

一句話定義

「為下一步以正確的資訊填滿 context window 的精細工藝」（Tuana Çelik & Logan Markewich, LlamaIndex, 2025）；比 Prompt-Engineering 範圍更廣，涵蓋 context window 內所有元素的策略性 curation。AI Agent 視角下，李宏毅 把它定義為「LLM 的守門人 / 經紀人」：攔截在 LLM 與外界之間，幫 LLM 管理它一定有上限的輸入長度（2026-05-02-AI-Agent-Context-Engineering系統化）。

演算法形式：C = (P, M)、F 是核心

2026-05-02-AI-Agent-Context-Engineering系統化 李宏毅 把本概念形式化（vault 中第一次以演算法層寫下）：

沒做 context engineering（裸 LLM）：

C ← []
for t = 1, 2, 3, …:
    O_t ← LLM(C, I_t)        # I_t = 本輪輸入（人類訊息 / 工具輸出）
    C   ← C + I_t + O_t      # 簡單 append，最終會破 context window 上限

做了 context engineering：唯一改變是最後一行 →

C ← []
for t = 1, 2, 3, …:
    O_t ← LLM(C, I_t)
    C   ← F(C, I_t, O_t)     # F = 任意更新函式，本概念的核心

進一步把 記憶 區分出來 → C = (P, M)：

• P = 真的會丟給 LLM 的 prompt（語言模型看得到的部分）
• M = 存在硬碟、不會直接丟給 LLM 的記憶
• 演算法只把 P_t 餵給 LLM；load_memory 動作會更新 P、save_memory 動作會更新 M。

詞彙澄清（李宏毅 在影片中明確要區分）：

• Context = AI Agent 經歷過的一切（含 P + M）
• Prompt = Context 中真正進到 LLM 那一段（= P）
• 上課 / 文獻中兩詞常混用，但精確上兩者不同——本頁與 Prompt-Engineering 視為精確區分而非混用。

核心要點

• 與 Prompt-Engineering 的差異：prompt engineering 聚焦於任務指令；context engineering 涵蓋整個 context window，並一定要尊重 window 的容量限制。
• 一句話操作定義（2026-05-13-Stanford-AI系統課程）：context management 的本質是「把對的資訊在對的時間提供給 agent」。這個說法把本頁從 token 管理推回產品問題：當下任務到底需要使用者偏好、RAG 文件、工具結果、working memory 還是 archival memory？
• Context 構成元素：系統提示 / 使用者輸入 / 短期記憶 / 長期記憶 / 知識庫 / 工具定義與回應 / 結構化輸出 / 全域狀態。
• 五大技術：
  1. 知識庫 / 工具選擇：給 LLM 關於可用資源的資訊以便正確選擇
  2. Context 排序 / 壓縮：summarization、ranking
  3. 長期記憶儲存與檢索：VectorMemoryBlock、FactExtractionMemoryBlock、StaticMemoryBlock 等（LlamaIndex 提供）
  4. 結構化資訊：用結構化輸出避免 context 膨脹
  5. Workflow Engineering：用工作流取代「全部塞進一次 LLM 呼叫」——明確映射任務序列、分離 LLM 與確定性邏輯、建立驗證與錯誤處理
• 容量在 100% 之前已劣化（2026-04-30-Claude-Code完整教程 經驗值）：實測 context 使用率 20-40% 起品質就開始下降，不是接近上限才崩。原因是「所有東西都會累積」（每則訊息、每個檔案讀取、每段生成、每個工具回應），而劣化發生後再加 context 只會更糟。推論：context 容量是「工作區」而非「上限」——超過 1/3 ~ 2/5 就應該主動瘦身或重啟，不是等模型開始犯錯才動作。
• CLI-agent 場景的四個工程化做法（同來源）：
  1. Scope 對話：一個 conversation 一個 feature/task，不要一邊建 auth 一邊重構 DB（contexts will bleed together）
  2. 外部記憶體：讓 agent 寫入 SCRATCHPAD.md / plan.md，跨 session 持續、回來時直接讀檔接續
  3. 複製貼上重置：把 terminal 重要內容複製出來、跑 /compact 取摘要、/clear 後只貼回關鍵內容——比讓模型在劣化 context 中硬撐好
  4. 果斷 /clear：對話脫軌時清空，agent 仍會載入專案規範檔（CLAUDE.md），不會失去 project context。十次有九次比硬撐好。
• PTC / Minimal 是 context 成本的兩種不同切法（2026-08-18-DeepSeek-Harness四種模式）：PTC 讓模型先寫 TypeScript，把搜尋、循環、過濾、讀取與處理組成一次執行，減少 LLM → Tool → LLM 的 round trip，也減少無意義中間資料進入 context；Minimal 則從工具數量與 tool schema 下手，降低短任務固定 prompt 成本。但 Minimal 若缺少完整 compaction、Subagent、Workflow 等 context 管理能力，長 session 或大量 Bash 輸出時未必真的省 token。
• Compact 不能恢復品質：壓縮發生時模型已劣化，壓縮只縮短 token 數，不會把模糊的判斷變清晰。Compact 是延緩，不是解藥。
• Ralph-Loop 的 summary 變體是 context-engineering 在迴圈內部的具體做法（2026-05-02-Harness-Engineering駕馭工程 李宏毅 整理）：Ralph-Loop 一路把 v1 / feedback1 / v2 / feedback2 / … 累積進 context 會很快觸頂；常見變體 = 每輪 feedback 後做摘要、下一輪只用摘要。這是 context engineering 在多輪迴圈場景的具體工程化動作。
• Sonnet「上下文焦慮」（Anthropic 擬人化說法）：window 將滿時模型行為崩壞、想盡快結束——這是「容量在 100% 之前已劣化」在具體模型上的表現；對位 Claude-Code 視角的「20-40% 起品質下降」，但在 multi-turn / agent 場景下劣化點可能更早。Opus 較強，可走裸 Ralph Loop。
• Long context 仍需管理：即使模型支援百萬 token 級 context，也不代表可以每次把整個資料庫塞進去；latency、成本、更新效率與 lost-in-the-middle 類問題仍會讓 RAG / indexing / filtering 有價值。
• 三詞演化軸第二棒：本概念在 Prompt → Context → Harness 三詞中位於中段，負責「window 怎麼管」；harness 層覆蓋更廣（含工具與工作流），但其內部關於 context 的所有議題都仍由本概念處理。詳見 Prompt-Engineering > 三詞演化軸：Prompt → Context → Harness。

何時開始做 context engineering（時機紀律）

本節對位 Agent複雜度演化 階段 4——避免讀者把 context engineering 當作 day 1 就該上的「優雅架構」。

不是 day 1 就該上的東西——時機觸發點是「工具加到 3-4 個後 Agent 開始持續性變差」（2026-05-02-Agent神文沒告訴你的事）：

• 失控的具體現象：不是偶爾失敗，是性能持續性變差——成功率下降、準確率忽高忽低、聽不懂人說話、越做越亂。
• 不是模型不行，是「上下文的注意力犧牲」：工具一多 + 任務複雜 + 歷史對話 + 代碼 + 圖片各種信息一股腦塞進 → 太多太散 → 注意力被平均分散。
• 這時才真正需要 context engineering——做某類任務時讓模型只看到它需要看到的東西。

上下文隔離有意義的條件

對位 Sub-Agent：上下文隔離不是「加 sub-agent 就成立」，而要符合條件：

不同任務需要不同上下文才有意義——例（2026-05-02-Agent神文沒告訴你的事 影片 Agent）：

• 設計任務需要大量、開放、可發散的信息（風格 / 版式 / 元素 / 氛圍）
• 寫代碼任務需要盡量少且精確的信息（接口 / 格式 / 正確性）
• 混在一起會相互污染上下文 → 系統花大量時間理清楚

關鍵紀律：「如果 sub-agent 和頂層規劃者看到的上下文是一樣的，那這樣的 sub-agent 就完全沒有意義」——對位 Sub-Agent > 有效性紀律：主-副-context-一樣-=-毫無意義。

F 的常見實作 1：壓縮（治標）

為什麼需要壓縮——LLM 輸入有上限。本節整理 李宏毅 在 2026-05-02-AI-Agent-Context-Engineering系統化 中列出的五種變體。

(a) LLM Summary（OpenCode 內建）

• 把整個歷史紀錄（扣掉 system prompt）丟給另一個 LLM 做摘要 → 用摘要取代舊歷史。
• vault 中既有 Claude-Code /compact 指令的官方做法。

(b) Observation Masking（簡單粗暴法）

• 把舊工具輸出整段換成「這裡曾經有一個工具的輸出」一句話。
• 驚人的事實：2025-中 SWE-bench 比較 paper 顯示 observation masking ≈ LLM summary，許多 case 平手；簡單方法真的有用。
• Trajectory 延長現象（同 paper 的反例）：壓縮後 LLM 忘了已執行的工具又重做，整體 token 沒省到。

(c) 兩者混用（同 paper 結論的最佳策略）

• 前期 observation masking（便宜）。
• 後期 context 仍逼近上限時，再用 LLM summary 一次大壓縮。

(d) Log 檔案外掛

• 把舊工具輸出寫進 log1.txt → context 只留「詳見 log1.txt」。
• 多數時候 LLM 不會回頭讀 → 等於把記憶從 prompt 裡移到硬碟（演化路徑：observation masking → log 外掛 → 完整 Agent-Memory 系統）。
• LLM 真需要時可呼叫 read 工具撈回。

(e) Sub-Agent：自主壓縮

• 主 agent spawn(subtask) 產生 sub-agent → sub-agent 完成後 return("結論")。
• 整段 sub-agent 對話被「壓縮」成 return 那句話——對主 agent context 而言這就是自主壓縮，導致 context length 呈鋸齒狀上升下降。

(f) AgentFold：訓練模型自主使用 fold 工具

• LLM 天生不喜歡壓縮自己的記憶——多次 paper 反覆驗證；OpenCode /compact 是寫死規則就是因為這點（如果讓 LLM 自己決定，它不會做）。
• AgentFold paper 解法：用 RL fine-tune 模型，逼它學會用 fold(start, end, summary) 工具自主壓縮。單純 prompt 不行，必須調參——這條紀律與 Sub-Agent 訓練同源。

為何 OpenCode 的壓縮觸發是寫死規則

• LLM 天生抗拒壓縮自己的記憶（同 Sub-Agent）。
• AgentFold paper 試過硬 prompt 模型用 erase 工具，模型仍不執行。
• 所以 Claude-Code / OpenCode 的 /compact 採取達到 context 上限就強制執行的硬規則路線——避開「讓 LLM 自己決定」這個陷阱。

F 的常見實作 2：記憶（治標 + 治本中間態）

把 context 一部分挪到硬碟外掛、需要時再 load 回來——既不丟（不像壓縮），又不佔 prompt（不像裸 append）。

• 基本兩個工具：save_memory（更新 M）+ load_memory（更新 P）。
• OpenCode 具體實作：memory_search + memory_get 兩工具；memory_get 帶起始行 + 行數避免一次讀爆 prompt。讀檔本身有過濾語意——這是治本精神延伸到 memory 子議題。
• 儲存結構研究：graph 形狀 / 時間戳 / 重要性分層 / save+load 時機，文獻汗牛充棟。
• 詳見 Agent-Memory。

F 的常見實作 3：過濾（治本）

與其等 context 太長再壓縮（治標），不如一開始就不要讓垃圾資訊進來。

Context 來源分析（兩篇 paper 結果一致）

• 一般 agent task：observation 佔 84%（檔案、工具長輸出）；action 6.5%；reasoning 9.6%。
• SWE 任務：read 程式碼佔 76%；execute 12%；edit 11.8%。

→ 絕大多數 context 是來自外界、沒過濾就直接吞下去的內容。

智慧型 Read 工具

• 傳統：LLM 說「讀 log」→ read 工具把整份檔案塞進 prompt → LLM 哽到。
• 改進：LLM 說「讀 log 裡跟修 bug 有關的內容」→ read 工具裡放一個小 LLM 做過濾 → 只把相關內容傳回。
• OpenCode 的 memory_get 起始行 + 行數參數也是同精神：read 不是無腦讀，是有選擇性地讀。

F 的常見實作 4：按需加載（On-Demand Loading）

工具描述塞在 system prompt 中也很佔空間。

• MCP-Zero paper 觀察：使用 GitHub 的工具描述就要 4600 token；多幾個工具就吃光 context window。
• 傳統 RAG（不夠好）：依使用者 query 從工具庫搜出相關工具——但 query 通常太模糊（「幫我修 bug」對應 read + edit + … 多個工具）。
• MCP-Zero 方法：讓 LLM 自己輸出「我需要怎樣的工具」的需求→ 再 retrieve。讓 AI 自主決定工具需求。
• OpenCode Skill 系統就是按需加載——並非把所有 skill 一次放進 prompt，而是要用時才從硬碟讀出來；對位 Verbalized-Feedback > Skill 化（永久化路徑）。

失敗模式：Context-Collapse

壓縮把任務真正在意的資訊壓沒了。

• 症狀：摘要本身完整，但任務原本能解、現在解不了。
• vault 對位案例：Meta agent 收信事件（2026-05-02-Harness-Engineering駕馭工程 末段）——agent 在 compact 過程中把「刪信前要人類同意」這條最關鍵指令一起壓掉，於是它就開始亂刪信。
• ACON paper 解法：用 Verbalized-Feedback 的方式，給負責摘要的 LLM 看一段「為什麼之前壓縮會讓任務變差」的 feedback——不調參數，但摘要品質提升。
• 詳見 Context-Collapse。

F 之上：Agentic-Context-Engineering

「為什麼 F 一定要人類工程師寫死？讓 LLM 自己來啊」

• 把 F 也交給 LLM——本質 = 用 Prompt-Engineering 來做 Context-Engineering。
• 代表 paper 系列：Dynamic Cheatsheet（早期）→ ACE playbook（修改而非寫）→ Recursive Language Model（metadata + LLM 自寫程式做 RAG）。
• 詳見 Agentic-Context-Engineering。

與其他概念的關係

• 父概念對比：Prompt-Engineering——前者把焦點從「prompt 指令」推到「整個 context window」。
• 駐留 agent 場景的職責分工（Claude-Code 等 CLI-agent）：兩者在工具堆疊中各管一段——Prompt-Engineering 管「該說什麼」（CLAUDE.md 書寫 / plan mode 指令 / slash commands 模板 / 單次任務指令）；本概念管「window 怎麼管」（容量監測 / 外部記憶體 / scope 對話 / copy-paste 重置 / 果斷 /clear）。CLAUDE.md 是交界點——內容屬 prompt engineering，載入時機與上下文成本屬 context engineering。詳見 Prompt-Engineering > 駐留 agent 場景的職責分工。
• 包含技術：RAG 是其中一種「知識庫 / 工具選擇」與「context 排序」的具體實作；context engineering 涵蓋 retrieval 但不限於它。
• 與 LLM-Wiki 同屬「LLM 如何利用上下文」的討論，但路徑不同：LLM Wiki = 「ingest 一次、累積成持久 wiki」；Context Engineering = 「每次任務動態 curate 整個 context window」。兩者可並用。
• 對 Agent 與 Augmented-LLM 至關重要：Anthropic 在「Building Effective Agents」中強調 agent 的每一步都需要決定 context window 該放什麼；五大 workflow pattern（Prompt-Chaining / Routing / Parallelization / Orchestrator-Workers / Evaluator-Optimizer）每一個都是 context engineering 的具體實踐。LlamaIndex 列的「Workflow Engineering」技術即此精神。
• 工具落地：Claude-Code 的 CLAUDE.md（系統提示層的常駐配置）+ 外部記憶體（跨 session 持續）+ scope 對話（每個 conversation 一個任務）+ compact / clear 工具集，是 context engineering 在 CLI-agent 開發場景的完整工具堆疊。
• 演算法層子議題集合（2026-05-02-AI-Agent-Context-Engineering系統化 拓展）：
  • Agent-Memory——C = (P, M) 中 M 部分的具體實作軸
  • Sub-Agent——壓縮 F 變體之一，自主壓縮機制
  • Context-Collapse——壓縮 F 失敗模式
  • Agentic-Context-Engineering——把 F 也交給 LLM 自己做的方法論流派

相關來源

• 2026-08-18-DeepSeek-Harness四種模式 — 補入 PTC / Minimal 兩種 context 成本取捨：批處理減少 tool-call 往返與中間資料，精簡工具集降低短任務固定 schema 成本
• 2026-04-28-LlamaIndex-Context-Engineering
• 2026-04-28-Anthropic-Building-Effective-Agents
• 2026-04-30-Claude-Code完整教程 — 「容量在 100% 前已劣化」具體經驗值（20-40% 起）+ CLI-agent 場景四個工程化做法（scope 對話 / 外部記憶體 / copy-paste reset / 果斷 /clear）
• 2026-05-02-Harness-Engineering駕馭工程 — Ralph Loop summary 變體 + Sonnet「上下文焦慮」+ 三詞演化軸第二棒對位
• 2026-05-02-AI-Agent-Context-Engineering系統化 — vault 第一份系統化整理本概念到演算法層的來源（李宏毅 AI Agent 系列 1/3）：C = (P, M) + F 五種壓縮變體 + 治標 vs 治本（過濾 + 按需加載）+ context collapse 失敗模式 + Agentic Context Engineering 流派
• 2026-05-02-Agent神文沒告訴你的事 — 何時開始做 context engineering 的時機紀律（工具 3-4 個後注意力犧牲）+ 上下文隔離有意義的條件（不同任務需要不同上下文）+ 「主 / 副 agent 看一樣 context = 毫無意義」對位
• 2026-05-13-Stanford-AI系統課程 — 補入 context management 的產品化定義（對的資訊在對的時間）、working / archival memory 語境與 long context 仍需檢索管理的取捨

備註