agent-01 · Context engineering 是 agent 的工作記憶 — 李宏毅老師經典的教學風格版

各位同學大家好啊，那我們就開始來上課吧。

今天這堂課呢，我們要講的是：agent-01 · Context engineering 是 agent 的工作記憶。

一言以蔽之：context engineering 不是把 prompt 寫漂亮一點，它其實就是替 LLM 這顆 processor 管理 working set。

今天的 roadmap 很簡單。我們先看最 naive 的 append-only agent 為什麼會爆掉，接著分清楚 prompt、context、memory、compression 與 observation，最後再看 sub-agent、on-demand skills 跟 agentic context management 怎麼進場。

你可能會想說，這不就是把原本的文章換一種講法嗎？不是。重點是我們要照著一條線走：先看 naive attempt 怎麼壞掉，再看 system 裡哪個 method 或 tooling 出來補洞。這樣你才會知道 failure 應該 debug 在哪一層。

風格說明：本文是受李宏毅教學風格啟發的教學式改寫，不是李宏毅老師本人撰寫、審閱或背書。

實用的 context stack

好，先不要急著講技巧。我們先把 stack 畫出來，因為你如果不知道每一層在哪裡，debug 的時候就只會一直怪 model。

這堂課最有用的讀法，是把它當成 taxonomy，而不是單一技巧。Context engineering 是決定 model 能看見什麼、什麼留在 prompt 之外、什麼被壓縮，以及哪些 evidence 能保存到足以被檢查的 layer。

對 agent builders，我會把 stack 拆成這幾層：

• Prompt-visible workspace：model 眼前看到的小型 active set。
• External memory：prompt 外部的 files、logs、notes、vector stores、playbooks 與其他 state。
• Compression：讓 long history 可用的 summaries、markers 與 pointers，但不能假裝沒有資訊損失。
• Bounded observations：tool results 在進入 model context 前先被 shaping。
• Sub-agent interfaces：messy branches 回傳 concise conclusions 加上可驗證 handles。
• On-demand skills：tool 與 procedure descriptions 只在 relevant 時載入，而不是每一步都帶著。

這個 taxonomy 也是 debugging checklist。Coding agent 如果 loop、hallucinate、漏看 file，或沒有 evidence 就自信地說「完成」，failure 可能在這些 context interfaces，而不只是 base model。

天真的 agent 只是把所有東西往後附加

最天真的做法是什麼？很簡單，全部往後貼。聽起來很誠實，對不對？但 agent 一做久，你就會發現這招很快壞掉。

最簡單的 agent loop 很容易想像。User 說了一句話。Model 回覆。Tool 回傳 observation。Agent 把所有東西都 append 到下一個 prompt。

粗略來說：

C_next = C_current + input + output

這感覺很誠實。沒有東西遺失。Model 可以看到完整 history。

它也很快就會壞掉。

Tool outputs 很長。File reads 很長。Logs 很長。Web pages 很長。幾個 cycle 之後，prompt 裡塞滿過時細節、失敗嘗試、巨大的 observations，以及只是在偶然上和當前決策相關的隨機 fragments。

Model 不只受 context length 限制，也受 attention 限制。即使 context window 很大，把唯一相關的 fact 埋在好幾頁無關文字中，也會讓任務變難。

課程把問題重新表述成一個函數：

C_next = F(C_current, input, output)

核心 engineering problem 不再是「我怎麼保留所有文字？」而是「update function F 應該做什麼？」

這個小轉換很重要。

Prompt 不等於 context

你可能會想說，prompt 不就是 context 嗎？其實不是喔。Prompt 是眼前這一小塊，context 是決定眼前能出現什麼的整套系統。

課程中最有用的區分之一，是 prompt 與 context 的差異。

Prompt 是 model 眼前正在看到的東西。

Context 更廣。它包含 agent 經歷過什麼、能 retrieve 什麼、disk 上存了什麼、有哪些 skills、寫過哪些 logs，以及哪些 memories 之後可能變得相關。

一個有幫助的記號是：

context = P + M

P 是 prompt-visible context。M 是 external memory。

大多數糟糕的 agent designs 會把兩者混在一起。它們試圖讓 P 包含所有東西。於是你得到的就是塞滿 tool manuals、過去錯誤、raw logs 與舊 observations 的巨型 prompts。

更好的 design 會把 prompt 當成小型 active workspace。External memory 可以大很多，但應該留在外面，直到 agent 有理由讀取它。

這非常接近我希望 coding agents 採取的行為。不要把整個 repository 貼進 model。給它一張地圖、search tools、file readers，以及清楚規則，說明何時該檢查什麼。

壓縮是必要的，但也很危險

怎麼辦呢？Context 會滿，所以一定要壓縮。但壓縮不是免費午餐，它會把某些資訊丟掉。

History 一旦變長，compression 就不可避免。你可以 summarize 舊 turns、mask observations，或把長 tool outputs 存成 files，只在 prompt 裡留下 pointer。

課程討論了幾種 patterns：

• 用另一個 LLM summarize 舊 history
• 用短 marker 取代長 observation
• 把 raw logs 存到像 log1.txt 這樣的 file
• 只保留目前 task 需要的部分
• 請 sub-agent 處理分支並回傳短結果

危險在於 context collapse。

Summary 可能剛好移除後面變成必要的那個 fact。Agent 在 compression 前可能有足夠資訊可以解 task，compression 後卻因為重要 bit 被當成 noise 而失敗。

這就是為什麼 summarization 不應被視為無害的 cleanup step。它是一個 information bottleneck。你需要知道 task 在乎什麼。

課程提到的 ACON idea 很適合放在這裡：當 compression 導致失敗，就用 feedback 教 summarizer 不該丟掉什麼。我喜歡這點，因為它把 context engineering 視為 learning problem，而不只是 prompt-formatting problem。

Observation 才是真正的 context 殺手

比如說，真正把 context 撐爆的常常不是 model 的回答，而是 tool observation。這個地方很容易被低估。

課程裡一個細緻的點是：model 自己的 reasoning 與 actions 不一定是 context 成長的最大來源。Observations 才是。

一個 shell command 回傳 500 行。一個 file read dump 出整個 module。Browser scrape 回傳一整頁。Test run 印出巨大 stack trace。現在 model 必須在文字沼澤裡做決策。

這提示了另一個介入位置。與其事後 summarize 所有東西，不如一開始就阻止糟糕的 observations 進入 prompt。

更聰明的 read tool 不應永遠等於「read the entire file」。它可以是：

• 讀特定 line range
• 先搜尋相關 symbols
• 回傳 summary 加 line references
• 除非被要求，否則隱藏無關 output
• 把 raw output 保存在外部，供之後檢查

這就是 tool design 與 context engineering 開始模糊交疊的地方。能回傳更好 observations 的 tool，也是一個 context engineering tool。

Sub-agents 是壓縮裝置

Sub-agent 不是請一群小幫手來開會而已。從 context 的角度看，它其實是一台會做事的壓縮機。

課程對 sub-agents 的 framing 很有用，因為它切穿了一些 hype。

Sub-agent 不只是小型 coworker。它是一種保持 main context 乾淨的方法。

Main agent 可以說：去檢查這些 files、比較這些 papers，或測試這個 hypothesis。Sub-agent 會累積所有混亂的 intermediate context。當它回來時，main agent 收到的是短答案：找到了什麼、什麼失敗了、什麼重要。

那是帶有 agency 的 compression。

它也有風險。如果 sub-agent 回傳糟糕 summary，main agent 可能永遠看不到缺失的 evidence。所以 interface 很重要。好的 sub-agent 不只應該回傳 conclusion，也應該回傳 anchors：files、line numbers、commands、timestamps，或 parent 可以驗證的其他 handles。

這也是為什麼 agent 只說「done」時我不信任，除非它給我 path、diff、test result 或 reproduction。

Tool descriptions 不應該全都塞在 system prompt 裡

再看一個很實務的問題：tool manual 要不要全部塞進 system prompt？直覺說塞越多越好，但其實會變成每一步都在繳稅。

另一個實用點：tool descriptions 本身也是 context。

如果你把每個 tool description 都 dump 進 prompt，藉此把大型 tool library 暴露給 model，那 tool manual 就會變成每一步都要付的稅。它也會讓 tool selection 更困難。

課程提到 MCP-Zero 與 on-demand skill loading 之類的方法。想法很直接：讓 tool 與 skill descriptions 可被搜尋，然後只載入相關的部分。

這基本上是 retrieval-augmented generation，只是對象不是 documents，而是 agent affordances。

我認為這對 long-lived personal agents 很重要。一個有用的 personal agent 可能有數百個微小 skills：email、calendar、code review、video editing、note taking、finance、deployment、writing。它不可能一直把每份 instruction 都保持 active。它需要一種方式記得某個能力存在，而不用把完整 manual 帶在腦中。

Agentic context engineering

最後再往前一步。能不能讓 agent 自己幫忙管理 context？可以，但這時候你就要開始設邊界。

最後一步，是讓 model 幫忙管理自己的 context。

課程稱之為 agentic context engineering。與其由 humans hard-code 整個 F，agent 可以維護 cheatsheet、更新 playbook、決定要儲存什麼，或自行搜尋 external memory。

例子包括：

• dynamic cheatsheets
• 會隨時間更新的 playbooks
• recursive language model style systems，把大型 context 存在外部，prompt 裡只保留 metadata

這很強大，也基於同一個原因令人不安。如果 agent 能編輯自己的工作筆記，它可以改進。它也可能寫下壞規則、保留錯誤教訓，或刪掉唯一重要的 constraint。

所以 system boundary 很重要。我不會讓 agent 隨意改寫自己的 root identity 或 safety rules。但讓它維護 task-level notes、project conventions 與 reusable tactics，不只合理，甚至必要。

我實際會採用什麼做法

如果要根據這堂課設計 agent，我會先從幾條無聊規則開始：

1. 讓 active prompt 保持小。
2. 把 raw outputs 存在外部。
3. Prompt 裡放 pointers，不放巨型 blobs。
4. 讓 tools 回傳 structured、bounded observations。
5. 把 sub-agents 用在混亂分支上。
6. 要求 sub-agents 回傳可驗證的 handles。
7. 按需載入 tools 與 skills。
8. 把 summaries 視為 lossy，並測試它們。
9. 讓 agent 維護 playbook，但保護 root rules。

這些都不 glamorous。這大概正是它重要的原因。

很多 agent failure 從外面看像 reasoning failure。有時確實是。但看完這堂課後，我會先問一個更基本的問題：這個 agent 有正確的工作記憶嗎？

概念清單

作為參考，這裡把課程中的主要概念集中列出：

• 把 context engineering 視為 update function：從 current context、input 與 output 生成 next context
• context window limits，以及為什麼長 tasks 需要 compression
• prompt-visible context 與 external memory 的差異
• P + M：prompt contents 加上 prompt 外部的 memory
• compaction、summarization 與 observation masking
• memory externalization：把長 outputs 存成 files，並只保留 active pointers
• context collapse：遺失 task 後來需要的唯一細節
• ACON-style feedback，用來改善 compression
• AgentFold 與 fold-style tools，用來把長 histories 轉成短 notes
• sub-agents 同時作為 parallel workers 與 context compression devices
• tool output 進入 model context 前的 observation filtering
• on-demand tool and skill loading，而不是把每份 manual 都 dump 進 prompt
• MCP-Zero-style discovery：只在需要時發現 tools
• agentic context engineering：dynamic cheatsheets、playbooks 與 model-maintained memory

來源與參考資料

本文觀看的主要來源：

• AI Agent (1/3)：核心技術 Context Engineering 基本概念解說