深度探秘

從「寫好一句話」到「管好整個資訊環境」

什麼是「情境 context」？

情境（context） 指的是：模型在做一次推論（取樣）時，會被丟進去的所有 token。這包含：

• 系統提示（system prompt）
• 使用者的訊息
• 工具定義（tools）
• 外部資料、檢索結果
• 之前對話的訊息歷史

而提示工程（prompt engineering），只專注在其中一小塊：怎麼把「指令」這段文字寫好、組織好。它解決的是「怎麼下指令」。

情境工程（context engineering） 則是更大的問題：在 Agent 運作的每一個時間點，要決定「這一輪推論，到底該放哪些 token 進去」。它解決的是「怎麼持續策展整個資訊環境」。

可以說：提示工程是情境工程的一個子集合，是「寫一份文件」；情境工程是「管理一整座持續變動的資訊倉庫」。

為什麼會從提示工程走向情境工程？

早期使用 LLM，大多是「一次性任務」：分類一段文字、生成一段文案。這種場景下，寫好一個系統提示幾乎就是全部工作。

但當我們開始打造在多輪推論、長時間運作的 Agent（例如寫程式的 Agent、做研究的 Agent），問題就不再是「這句話寫得好不好」，而是：

• 系統指令該怎麼設計？
• 工具該怎麼給？
• 外部資料何時載入、载入多少？
• 舊的對話歷史，哪些該留、哪些該丟？

這些問題合在一起，就是情境工程要處理的範疇。

生活妙喻

寫考卷 vs 經營一間辦公室

提示工程：像是「寫一張完美的小抄」

想像你要參加一場考試，只能帶一張小抄進場。提示工程做的事，就是絞盡腦汁把這張小抄寫到最精簡又最有用——用什麼措辭、排版、範例，才能讓看小抄的人（模型）秒懂該怎麼答題。

寫完这張小抄，工作就結束了。這是一次性、靜態的任務。

情境工程：像是「經營一間持續運轉的辦公室」

情境工程更像是你在管理一間辦公室，而且這間辦公室每天、每小時都有新的信件、新的會議紀錄、新的待辦事項湧入。你的工作不是寫一份文件就結束，而是要不斷決定：

• 哪些信件要放在員工的桌上（隨時可見）？
• 哪些資料該收進檔案櫃，需要時再去查（就是後面會學到的「即時檢索」）？
• 開會紀錄堆積如山時，該怎麼整理摘要（後面會學到的「壓縮」）？
• 有些任務要不要外包給專門的小組去處理，只回報結果（後面會學到的「子代理」）？

這是一個持續、動態的策展過程——這正是情境工程和提示工程最大的不同。

實用超能力

打造 Agent 時，先問自己這個問題

從「寫得好」到「配得好」

下次設計一個 AI Agent 時，別只問：「我的 prompt 寫得夠好嗎？」而要問：

「此時此刻，喂進模型的這一整包 token，是不是最有可能引出我想要的行為？」

具體檢查清單

設計 Agent 的情境時，可以逐項檢查：

一個簡單流程

flowchart TD
    A[任務開始] --> B[思考本輪推論需要哪些資訊]
    B --> C[系統提示 是否在黃金高度]
    B --> D[工具 是否精簡好用]
    B --> E[歷史紀錄 是否該摘要或丟棄]
    C --> F[組裝成這一輪的情境]
    D --> F
    E --> F
    F --> G[送進模型做推論]
    G --> H[產生新資訊 回到B]

這個「思考 → 組裝 → 推論 → 產生新資訊 → 再思考」的迴圈，就是情境工程在 Agent 生命週期裡不斷重複的核心動作。

深度探秘

Token 越多不一定越好：認識「情境腐化」

Context Rot：上下文越長，記憶反而越不準

研究者透過「needle-in-a-haystack（大海撈針）」式的測試發現一個現象：隨著上下文視窗裡的 token 數量增加，模型準確回憶其中資訊的能力會下降。這個現象被稱為 context rot（情境腐化）。

重點是：

• 這不是某個模型的個別缺陷，而是所有模型都會出現的特性（只是程度不同，有些模型退化得比較平緩）。
• 因此，上下文必須被當成一種有限資源，而且是邊際效益遞減的資源——塞進去的 token 越多，每多加一個 token 帶來的幫助就越小，甚至開始造成干擾。

為什麼會這樣？「注意力預算」與 Transformer 架構

背後的根本原因來自 Transformer 架構本身：

• Transformer 讓每一個 token 都要跟其他所有 token 互相「關注」（attend）。
• 如果上下文中有 $n$ 個 token，兩兩互相關注就會產生 $O(n^2)$ 量級的配對關係。

$$\text{配對關係數} \approx \binom{n}{2} = \frac{n(n-1)}{2} = O(n^2)$$

當 $n$ 越大，模型要「兼顧」的配對關係就以平方速度暴增，模型能分配給每一組關係的注意力自然被稀釋、拉得更薄。這就像人類的**工作記憶（working memory）**是有限的——LLM 也有類似的「注意力預算（attention budget）」，每多一個 token 進來，就會消耗掉一部分預算。

此外，模型在訓練時看到的短序列比長序列多得多，因此模型對「長距離、跨越整個上下文的依賴關係」本來就經驗較少、專門處理這類關係的參數也較少——這也讓長上下文中的資訊檢索天生比短上下文吃力。

值得留意：這是一個漸進的效能坡度，不是斷崖式的懸崖。模型在長上下文中依然很有能力，只是精準度、長距推理的表現會逐漸打折扣。

生活妙喻

考前抱佛腳 vs 平時扎實複習的差別

想像你在準備一場開放式筆記考試

如果你可以帶著滿滿一箱參考資料進考場，聽起來很安心對吧？但實際上：

• 箱子裡資料越多，你翻找特定那一頁的時間就越長，也越容易翻錯頁、看漏關鍵句子。
• 你的注意力和精力是有限的，不管箱子裡塞了多少資料，你在考試時間內能「真正消化、正確運用」的資訊量是有上限的。

這就是 context rot 最貼切的比喻：資料量增加，不代表你能準確運用的資訊量也跟著等比例增加。超過一定程度後，多出來的資料反而變成「噪音」，讓你更難快速找到真正需要的那一句話。

為什麼會是 n² 而不是 n？

再想像一場有 $n$ 個人參加的酒會，每個人都想跟其他所有人打招呼、交換資訊。人數 $n$ 每多一個，新增的「兩兩配對」就會比新增的人數快得多——這正是組合數學裡「配對數量隨人數平方成長」的現象，恰好對應 Transformer 裡「每個 token 都要跟其他 token 互相關注」的機制。

人越多，酒會現場越吵、越難聽清楚每一段對話的細節——這就是「注意力被稀釋」的感覺。

實用超能力

把「情境視窗」當預算來管理

給 Agent 開發者的具體提醒

知道 context rot 的存在後，設計 Agent 時應該養成這些習慣：

1. 不要用「反正上下文夠大」當藉口，把所有能想到的背景資料都塞進去。上下文視窗大，只代表容量上限提高，不代表模型能同等精準地運用裡面每一段資訊。
2. 定期清理、精簡已經不再需要的資訊（例如很久以前呼叫工具的原始回傳結果）。
3. 把「這段資訊值不值得占用注意力預算」當成每次要不要放進上下文的判斷標準。

一個簡單的心智模型

flowchart LR
    A[Token 數量增加] --> B[配對關係以 n 的平方成長]
    B --> C[注意力預算被稀釋]
    C --> D[長距資訊檢索精準度下降]
    D --> E[Context Rot 情境腐化]

實際應用：三個問題自我檢查

下次要往上下文裡加東西之前，問自己：

• 這段資訊現在真的需要被看見嗎？還是可以之後再查（即時檢索，第三章會講）？
• 這段資訊已經很久沒被用到了嗎？是否可以摘要、丟棄（壓縮，第四章會講）？
• 有沒有辦法把這個任務外包給乾淨上下文的子任務處理（子代理，第四章會講）？

這三個問題，正好對應本書後面會展開的三大情境工程技巧。

深度探秘

兩個失敗極端，一個黃金地帶

Right Altitude：系統提示的「黃金高度」

好的系統提示應該清楚、直接、用語簡單，並且站在對這個 Agent 剛好合適的「高度」上說話。文中把這個恰到好處的高度稱為 right altitude（正確高度），它介於兩個常見的失敗模式之間：

失敗模式一：飛得太低——過度死板

工程師把非常複雜、瑣碎的 if-else 邏輯硬寫進提示裡，試圖精準控制 Agent 每一種情境下的行為。

問題：

• 提示變得脆弱（fragile）——情境稍有變化就可能失效。
• 維護成本隨時間持續增加，每次新增例外狀況都要再補一條規則。

失敗模式二：飛得太高——過度空泛

工程師只給模糊、高層次的指示，卻沒給模型足夠具體的訊號知道「預期輸出長什麼樣子」，或者誤以為模型跟自己有共同的背景知識（其實沒有）。

問題：

• 模型缺乏具體依據，容易產生不符預期的輸出。

黃金地帶：具體又有彈性

「Specific enough to guide behavior effectively, yet flexible enough to provide the model with strong heuristics to guide behavior.」

也就是：具體到能有效引導行為，但又保留彈性，讓模型能運用自己的推理能力，而不是照本宣科硬套規則。

組織系統提示的建議做法

建議把系統提示拆成清楚的區塊，例如：

<background_information>
... 背景資訊 ...
</background_information>

<instructions>
... 具體指令 ...
</instructions>

## Tool guidance
... 工具使用說明 ...

## Output description
... 預期輸出格式 ...

可以用 XML 標籤或 Markdown 標題來畫分區塊。不過文中也提醒：隨著模型越來越聰明，格式本身的重要性可能會逐漸下降，重點還是回到「內容夠不夠精準、夠不夠必要」。

生活妙喻

教新人做事，別當「機器人教官」也別當「甩手掌櫃」

想像你在教一位新來的實習生做事

太低：機器人教官型主管

有一種主管，會把每一個步驟都寫成「如果客戶說 A，你就做 B；如果客戶又說 C，你就改做 D……」，試圖預先窮舉所有可能的情境。

結果呢？只要客戶說出一句劇本外的話，這位新人就手足無措，因為他被訓練成「照本宣科」而不是「理解原則」。而且主管自己也很累，每天都要為新出現的例外狀況再補寫一條規則。

太高：甩手掌櫃型主管

另一種主管，只丟一句「你把這件事做好就行，細節你自己看著辦」，卻沒說清楚「做好」的標準是什麼、公司內部的慣例是什麼。新人只能瞎猜，猜錯了還被說「這種常識也不懂」——但那些「常識」從來沒人講過。

黃金地帶：懂得放權的好主管

真正厲害的主管，會清楚說明目標、原則、幾個關鍵案例該怎麼處理，然後放手讓新人依據這些原則自己判斷細節，遇到沒教過的情境也知道怎麼類推。

這正是好的系統提示該扮演的角色：給出足夠清楚的原則與範例，而不是窮舉所有分支，也不是丟出一句空話就走人。

實用超能力

先極簡起步，再依失敗案例補強

建議的實際操作流程

文中給出一個非常具體、可以直接照做的流程：

flowchart TD
    A[用最強模型寫一份最精簡的系統提示] --> B[實際測試在目標任務上的表現]
    B --> C[觀察哪裡出錯 記錄失敗模式]
    C --> D[針對失敗模式補上清楚指令或範例]
    D --> E[再次測試]
    E --> F{還有明顯失敗模式}
    F -- 有 --> C
    F -- 沒有 --> G[維持精簡並持續監控]

「minimal」不等於「短」

這裡有一個容易誤解的地方：文中特別強調——

「Note that minimal does not necessarily mean short; you still need to give the agent sufficient information up front to ensure it adheres to the desired behavior.」

也就是說，精簡（minimal）指的是「沒有多餘、無效的內容」，不是字數少。有時候把必要的背景資訊講清楚，反而需要比較多文字；重點是每一段文字都要有存在的理由。

動手檢查你的系統提示

下次寫系統提示時，逐條檢查：

1. 有沒有為了應付單一個案，寫了一大段死板的條件判斷？→ 考慮改成更通用的原則。
2. 有沒有某段指示，讀起來很空泛、模型可能不知道具體該怎麼做？→ 補一個具體範例。
3. 是否用區塊（XML 標籤／Markdown 標題）清楚劃分了背景、指令、工具說明、輸出格式？
4. 這段文字如果拿掉，模型的行為會變差嗎？如果不會，考慮拿掉。

深度探秘

工具是合約，不是隨手加的功能清單

工具：Agent 與環境互動的介面

工具（tools） 讓 Agent 能與外部環境互動、拉入新的資訊。因為工具定義了 Agent 能「知道什麼」與「能做什麼」的邊界，本節把工具比喻成一份合約（contract）——它精確界定了 Agent 的資訊空間與行動空間。

正因為工具這麼關鍵，設計時必須兼顧兩個效率面：

1. Token 效率：回傳的資訊要精簡，不要塞一堆無關雜訊。
2. 行為效率：工具的設計要引導 Agent 採取有效率的行動，而不是誤用、濫用工具。

好工具的三個特質

類比於設計良好的程式碼庫，好的工具應該：

• 自成一體（self-contained）：功能明確、不依賴太多外部假設。
• 對錯誤有韌性（robust to error）：輸入不完全符合預期時，也不會整個崩潰。
• 用途極度清楚：一看就知道「這個工具該在什麼情況下使用」。

輸入參數也要描述清楚、不含糊，並且發揮模型本身的優勢（例如讓模型擅長生成的自然語言參數，而不是要求模型精確計算複雜的座標數值）。

常見的失敗模式：工具集膨脹

最常見的問題之一，是工具集過度膨脹（bloated tool sets）——涵蓋太多重疊的功能，導致「該用哪個工具」變成一個模糊不清的決策點。

「If a human engineer can't definitively say which tool should be used in a given situation, an AI agent can't be expected to do better.」

也就是：如果連人類工程師都無法明確判斷該用哪個工具，就不能指望 AI Agent 能做得更好。

維持一個精簡、必要的最小工具集（minimal viable set of tools），不只讓單次任務更有效率，也讓長時間互動中的上下文維護與清理更容易。

生活妙喻

工具箱裡放什麼，決定了工人做事有多順手

想像你要幫一位師傅準備工具箱

情境一：工具箱塞滿了功能重疊的工具

工具箱裡有五種不同品牌、外觀相似、但功能有 70% 重疊的螺絲起子——師傅每次要用之前，都得先猶豫個幾秒：「這根到底跟另外那四根有什麼不一樣？」

結果是：每次動作前都多了一層不必要的判斷負擔，甚至可能拿錯工具、把螺絲弄壞。這正對應「工具集膨脹、功能重疊導致決策點模糊」的問題。

情境二：每個工具都貼著清楚標籤、功能不重疊

另一個工具箱裡，每種工具都只做一件事、標籤寫得清清楚楚：十字起子就是十字起子，扳手就是扳手，彼此功能不重疊。師傅拿到任何任務，幾乎不用思考就知道該伸手拿哪一個。

這正是好工具集該有的樣子：每個工具的用途單一而明確，彼此互補而非重疊。

工具的說明書 = 輸入參數的描述

工具上如果只寫「轉緊」，師傅還得猜要往哪個方向轉、轉幾圈；如果寫清楚「順時針轉三圈，扭力不超過 X」，師傅立刻就能精準操作。這就是「輸入參數要描述清楚、不含糊」的重要性。

實用超能力

設計工具前，先做這個檢查

設計 / 檢查工具集的實用清單

下次設計 Agent 的工具集時，逐項自我檢查：

一個簡單的判斷流程

flowchart TD
    A[列出候選工具清單] --> B{有兩個工具功能重疊嗎}
    B -- 有 --> C[合併或刪除重疊工具]
    B -- 沒有 --> D{人類工程師能明確判斷何時該用哪個工具嗎}
    D -- 不能 --> E[重新設計工具說明或邊界]
    D -- 能 --> F{工具回傳內容夠精簡嗎}
    F -- 不夠 --> G[精簡回傳格式 去除冗餘欄位]
    F -- 夠 --> H[納入最終最小可行工具集]
    C --> B
    E --> D
    G --> F

記住這條檢驗標準

如果連你自己（設計者）都要想個幾秒才能決定「這個情境該用工具 A 還是工具 B」，這就是一個警訊——該考慮合併、刪減，或者把工具的使用邊界寫得更清楚。

深度探秘

範例是模型眼中的「一張圖」

Few-shot Prompting：提供範例的老智慧

Few-shot prompting（提供範例）是業界公認的最佳實踐之一，本節也持續強力推薦這個做法。核心概念很簡單：與其只用抽象文字描述你想要的行為，不如直接給模型看幾個具體的正確示範。

「For an LLM, examples are the 'pictures' worth a thousand words.」

對 LLM 來說，一個範例往往比一大段抽象描述更能精準傳達「我要的就是這樣」。

常見誤區：把範例當成規則窮舉清單

然而，很多團隊會犯一個常見錯誤：試圖把「每一種可能發生的邊界情況（edge case）」都寫成一條規則塞進提示裡，變成一份落落長的清單。

本節明確不建議這種做法。原因呼應上一節「黃金高度」的精神：窮舉式的規則清單，本質上就是另一種形式的「過度死板」，會讓提示變得又臃腫又難維護，還未必真的涵蓋得了所有情況。

建議做法：精選、多樣、具代表性

取而代之，建議做法是：

• 精心挑選一組多樣化（diverse）、**具代表性（canonical）**的範例。
• 這些範例要能夠有效傳達 Agent 預期行為的核心模式，而不是逐一覆蓋每一個枝微末節的邊界狀況。

少量但精準的範例，往往比一份冗長的規則清單更能讓模型「抓到重點」，同時也更省 token、更好維護。

整體原則：Informative yet tight

本節把系統提示、工具、範例、訊息歷史等所有情境組成部分，收斂成同一句指導原則：

保持情境**「資訊豐富但精簡（informative yet tight）」**。

生活妙喻

教畫畫：給幾張範例畫，別給一本規則手冊

想像你在教一位新手畫水果靜物

做法一：寫一本《水果畫法規則手冊》

你試圖把每一種水果、每一個角度、每一種光線條件下該怎麼畫，都寫成文字規則：「如果是蘋果且光源在左邊，高光要畫在……如果是橘子且光源在正上方……」

這本手冊會越寫越厚，而且永遠有你沒想到的組合——換一顆梨子、換一個陰天光線，規則手冊立刻不夠用。新手讀了老半天文字規則，還是不知道實際下筆該怎麼抓明暗。

做法二：給他看三、四張精選的範例畫作

你不寫規則手冊，而是挑三、四張風格多樣但都精準示範核心技巧的範例畫作——一張蘋果、一張橘子、一張逆光、一張順光。新手看完這幾張圖，就能自己抓到「明暗怎麼抓、質感怎麼表現」的核心模式，遇到沒教過的水果或光線,也能類推應用。

這正是為什麼「範例是一張圖，勝過千言萬語」——文字規則手冊試圖窮舉，範例畫作則是示範可以被類推的核心模式。

Informative yet tight：行李箱的打包哲學

把整個情境（系統提示＋工具＋範例＋歷史）想像成一個行李箱：你想帶足夠的東西讓旅程順利（informative），但也不想拖著一個塞爆到拉鍊快壞掉的行李箱到處走（tight）。每一件放進去的東西，都該有明確存在的理由。

實用超能力

怎麼挑出「精選範例」而不是「窮舉清單」

挑選範例的實用準則

下次要在提示裡加入 few-shot 範例時，用這個流程檢查自己是不是在做「精選」而不是「窮舉」：

flowchart TD
    A[列出想放入的候選範例] --> B{這個範例展示的是核心行為模式}
    B -- 是 --> C[保留]
    B -- 否 只是單一邊界案例 --> D{已經有其他範例展示類似模式}
    D -- 有 --> E[考慮刪除 避免重複]
    D -- 沒有 --> F[評估是否真的必要 或改寫成通用原則]
    C --> G[檢查範例之間是否夠多樣化]
    G --> H[整理成最終精選範例組]

三個自我提問

1. 這個範例在教模型「一種可類推的模式」，還是只在應付「一個特定情況」？ 如果是後者，它可能更適合寫成一條通用原則，而不是一個範例。
2. 我現有的範例組合夠不夠「多樣」？ 如果三個範例都長得很像，不如換成三個展現不同面向的範例，涵蓋面反而更廣。
3. 拿掉這個範例，模型的表現會明顯變差嗎？ 如果不會，它可能只是佔用了不必要的上下文空間。

呼應整章的核心原則

這正好對應到情境工程貫穿全文的核心哲學：

找到最小可能的、高訊號的 token 集合，最大化達成預期結果的機率。

無論是系統提示、工具，還是範例，都該用這句話當作最終檢驗標準。

深度探秘

從「先算好」到「用時再查」

Agent 的簡單新定義

本節先給出一個簡潔的 Agent 定義：

Agent 就是 LLM 在一個迴圈中自主地使用工具（LLMs autonomously using tools in a loop）。

隨著底層模型能力提升，Agent 能夠自主運作的程度也在提升：更聰明的模型，能讓 Agent 更獨立地在複雜問題空間中導航，並從錯誤中自行恢復。

兩種取得上下文資訊的策略

策略一：預先檢索（pre-inference time retrieval）

許多 AI-native 應用採用**基於嵌入（embedding-based）**的預先檢索：在推論之前，先把可能相關的資料一次性找出來、準備好，交給模型參考。

策略二：Just-in-time（即時）檢索

隨著領域朝更「agentic」的方向發展，越來越多團隊開始搭配 just-in-time context 策略：

• Agent 不預先把所有資料處理好，而是維護一些輕量的識別碼（lightweight identifiers）——例如檔案路徑、儲存好的查詢語句、網址連結。
• 在執行當下，透過工具動態地把資料載入到上下文中。

舉例來說，Anthropic 的 Claude Code 在做大型資料庫的複雜資料分析時，就是用這種方式：模型會自己寫出精準的查詢、把結果存起來，並運用像 head、tail 這類 Bash 指令去分析大量資料，完全不需要把整份資料物件載入到上下文裡。

這種方式其實很貼近人類認知：我們通常不會把整套知識庫都背下來，而是仰賴檔案系統、收件箱、書籤這類外部組織與索引系統，在需要時再去查找相關資訊。

Metadata（元資料）也是重要線索

除了節省儲存空間，這些「輕量識別碼」的元資料本身，也提供了幫助 Agent（和人類）判斷資訊意義的重要線索。例如：一個叫 test_utils.py 的檔案，放在 tests 資料夾裡，和放在 src/core_logic/ 資料夾裡，隱含的用途是不同的。資料夾結構、命名慣例、時間戳記，都是幫助判斷「這份資訊該怎麼用、什麼時候該用」的重要訊號。

漸進式揭露（Progressive Disclosure）

讓 Agent 自主導航、檢索資料，還帶來一個額外好處：漸進式揭露——Agent 能透過探索，一層一層逐步發現相關的上下文。每一次互動得到的線索（檔案大小暗示複雜度、命名慣例暗示用途、時間戳記暗示相關性），都能幫助 Agent 做出下一步判斷，像疊積木一樣一層層建立理解，同時只在工作記憶中保留真正必要的東西。

生活妙喻

背整套百科全書 vs 善用圖書館的索引卡

想像你要準備一份研究報告

做法一：把整套百科全書背下來

有一種做法，是試圖把所有可能用到的知識，事先一股腦全部記在腦子裡——就像把整套百科全書背下來再開始寫報告。

這樣做的問題很明顯：不只費時費力，而且腦袋（上下文）裝的東西越多，能不能準確調用其中某一條特定資訊，反而會越吃力（呼應第一章 context rot 的概念）。

做法二：善用圖書館的索引卡與書籤

另一種更聰明的做法，是不預先背誦全部內容，而是隨身帶著一張索引卡，上面記著「氣候變遷資料在三樓 B 區第 5 排」、「這份報告的原始數據存在某個資料夾」。真正要寫到那一段時，才走去書架把那本書抽出來翻閱。

這正是 just-in-time 檢索的精神：維護輕量的「路標」（識別碼），需要時再去現場取用完整資訊，而不是把所有東西都預先扛在身上。

資料夾名稱本身就是線索

你在圖書館裡看到一本書放在「科普讀物」區，和看到同一本書放在「學術參考資料」區,你對它的期待與用法會不一樣——書架分類本身就是有意義的線索。這正對應 test_utils.py 放在 tests/ 資料夾和放在 src/core_logic/ 資料夾,傳達的訊息完全不同。

實用超能力

設計 Just-in-time 檢索系統的實務要點

Claude Code 分析大型資料庫的具體流程

flowchart TD
    A[收到資料分析任務] --> B[Agent 自行寫出精準查詢]
    B --> C[執行查詢並把結果存起來]
    C --> D[用 head tail 等指令分析結果片段]
    D --> E{需要更多細節嗎}
    E -- 需要 --> B
    E -- 不需要 --> F[整理成最終分析結論]

整個過程中，完整的原始資料物件從未被整個載入到上下文，只有 Agent 主動查詢、篩選後的片段才會出現在上下文中。

打造 Just-in-time 系統的三個實用要點

1. 善用有意義的命名與資料夾結構：檔名、路徑本身要能傳達用途線索，讓 Agent（和人類協作者）一看就懂。
2. 提供適合探索的工具：像 head、tail、grep、glob 這類工具，讓 Agent 能在不載入整份資料的情況下，快速篩選出重點片段。
3. 善用時間戳記與檔案大小等 metadata：這些訊號能幫助 Agent 判斷資訊的新舊程度與複雜度，做出更聰明的探索決策。

應用到你自己的專案

如果你在打造一個需要處理大量文件或資料庫的 Agent，可以問自己：

• 我是不是把所有資料都預先塞進了 prompt，而不是讓 Agent 自己去查？
• 我的檔案／資料命名夠不夊清楚，能傳達足夠的線索嗎？
• 我有沒有給 Agent 足夠的探索工具（查詢、篩選、瀏覽），讓它能實踐 just-in-time 策略？

深度探秘

沒有絕對的贏家，只有適合的取捨

即時探索的代價

上一節介紹的 just-in-time 檢索雖然強大，但本節提醒：天下沒有白吃的午餐，這裡存在明確的取捨（trade-off）：

• 速度：即時在執行當下才去探索、查詢，天生比「預先算好、直接讀取」要慢。
• 工程要求高：需要非常用心、經過深思熟慮的工程設計，才能確保 LLM 擁有合適的工具與判斷準則（heuristics），去有效導航它的資訊環境。
• 風險：如果缺乏妥善引導，Agent 可能會：
  • 誤用工具
  • 走進死胡同（chasing dead-ends）
  • 沒找到真正關鍵的資訊

這些都會白白浪費上下文額度。

混合策略（Hybrid Strategy）

正因為即時探索有這些代價，在某些情境下，最有效的 Agent 反而會採用混合策略：

• 部分資料預先載入：為了速度，先把某些確定會用到的資料準備好。
• 保留自主探索的空間：讓 Agent 依當下情況，自行決定要不要進一步探索。

「最適合的自主程度」（right level of autonomy）取決於具體任務的性質。

Claude Code 的實際案例

Claude Code 正是採用混合模式的代表案例：

• 預先載入：CLAUDE.md 檔案會被「天真地」（naively，也就是不經篩選地）直接放進上下文，作為隨時可見的背景資訊。
• 即時探索：像 glob、grep 這樣的基礎工具（primitives），讓 Claude Code 可以在執行當下自由導航環境、隨需檢索檔案。

這種混合設計，有效繞開了兩個常見的痛點：

• 索引過時（stale indexing）：預先建立的索引可能很快就與實際程式碼脫節。
• 複雜的語法樹解析（complex syntax trees）：不需要維護一套複雜、容易過時的程式碼結構索引系統。

混合策略更適合哪些場景？

本節指出，混合策略可能特別適合內容變動較不頻繁（less dynamic content）的領域，例如法律或財務工作——這類場景中，預先準備好的核心資料相對穩定，值得投資預先載入；但仍保留探索空間應付個案差異。

面向未來的原則

隨著模型能力持續進步，Agent 設計的趨勢會朝向：讓更聰明的模型更自主地行動，人類介入與預先規劃的比例逐漸降低。但鑑於這個領域進展飛快，本節給出一個歷久不衰的建議：

「Do the simplest thing that works.」——做最簡單、有效的事。

生活妙喻

出差打包：隨身包 vs 到當地再買

想像你要出差一週

純預先準備型

有些人會把整趟旅程「可能用到」的東西全部塞進行李箱——各種天氣的衣服、備用藥品、轉接頭、應急用品。優點是速度快（到當地不用現場張羅），缺點是行李箱又重又佔空間，很多東西其實根本用不到。

純現場探索型

另一種人幾乎不帶東西，什麼都打算「到當地再買、再找」。優點是行李輕便，缺點是萬一到了才發現當地買不到某個急需的東西（例如你常吃的藥），會非常麻煩，而且每件事都要花時間現場摸索,速度慢。

混合策略：聰明的老手做法

真正有經驗的商務旅行者，通常會這樣做：

• 一定會用到、難以現場取得的東西（如護照、常用藥、轉接頭）：預先打包好，放進隨身包，一到目的地就能立刻用（對應 CLAUDE.md 被直接載入上下文）。
• 可能用到、當地容易取得、或需求視情況而定的東西（如當地才知道的天氣狀況該穿什麼）：不預先囤貨，到當地再依實際情況現場解決（對應 glob／grep 的即時探索）。

這種「該預先準備的先準備好，該視情況再應變的就保留彈性」的做法，正是混合策略的精神。

法律 / 財務工作為何更適合混合策略

處理法律合約或財務報表時，核心的法規條文、公司財報格式相對穩定不常變動——這就像出差目的地的基本資訊（時區、貨幣）幾乎不會變，值得預先準備好；但每個具體案件的細節仍需要臨場查閱，保留探索彈性。

實用超能力

為你的 Agent 選擇合適的檢索策略組合

決策流程：該預先載入，還是即時探索？

flowchart TD
    A[列出這個 Agent 可能需要的資訊類型] --> B{這份資訊幾乎每次任務都會用到嗎}
    B -- 會 --> C{內容是否穩定 不常變動}
    C -- 穩定 --> D[考慮預先載入 例如 CLAUDE.md 模式]
    C -- 常變動 --> E[即使常用 仍考慮即時查詢 避免索引過時]
    B -- 不一定 --> F[採用即時檢索 給予探索工具如 glob grep]
    D --> G[組合成混合策略]
    E --> G
    F --> G

Claude Code 案例給我們的實用啟示

記住這條長期不變的準則

做最簡單、有效的事（do the simplest thing that works）。

不需要一開始就設計出最複雜精巧的檢索架構。先用最簡單的組合（例如先全部預先載入，或先全部即時查詢）測試，觀察哪裡卡住、哪裡浪費資源，再逐步調整成適合你任務特性的混合比例。隨著模型越來越聰明，你可能會發現需要人工預先安排的部分越來越少。

深度探秘

當任務長過一個上下文視窗該怎麼辦？

長任務的挑戰

有些任務——像是大型程式碼庫的搬遷（migration），或是橫跨數十分鐘到數小時的深度研究專案——所需的 token 總量，遠遠超過單一上下文視窗能容納的範圍。這類任務要求 Agent 在一連串行動中，持續維持連貫性（coherence）、上下文，以及朝目標前進的行為。

單純「等待更大的上下文視窗」聽起來是個誘人的解法，但本節提醒：無論上下文視窗多大，只要追求最強的 Agent 表現，就仍然會遇到情境污染（context pollution）與資訊相關性的問題（回顧第一章的 context rot）。

因此，Anthropic 發展出三個處理長任務情境污染的具體技巧，本節先介紹第一個：壓縮（compaction）。

Compaction 是什麼？

Compaction（壓縮）：把一段快要超過上下文視窗上限的對話，進行摘要，然後用這份摘要重新開啟一個新的上下文視窗，繼續任務。

Compaction 通常是情境工程中，用來提升長期連貫性的第一道防線（first lever）。它的核心精神是：用高保真度（high-fidelity）的方式蒸餾出對話內容的精華，讓 Agent 能以最小的表現折損繼續工作。

Claude Code 的實際做法

在 Claude Code 中，Compaction 的實作方式是：

1. 把訊息歷史傳給模型，請它摘要並壓縮最關鍵的細節。
2. 模型會保留：架構決策、尚未解決的 bug、實作細節等關鍵資訊。
3. 模型會丟棄：重複、冗餘的工具輸出結果，或不再重要的訊息。
4. Agent 接著用這份壓縮後的摘要，加上最近存取過的五個檔案，繼續任務。

使用者的體驗是：任務可以無縫延續，不必擔心上下文視窗爆掉。

Compaction 的藝術：抓平衡

壓縮真正困難的地方在於：該保留什麼、該丟棄什麼。過度激進的壓縮，可能會遺失一些當下看起來不重要，但之後才顯現關鍵性的細節。

給實作者的建議是採用兩階段調校法：

1. 先追求高召回率（recall）：確保壓縮提示能捕捉到對話追蹤中每一個相關的重要資訊，寧可多留一點。
2. 再逐步提升精確度（precision）：反覆迭代，剔除多餘、無關的內容。

最安全、最輕量的壓縮：清除工具結果

文中舉了一個低垂的果實（low-hanging fruit）——最安全、影響最小的壓縮形式：清除工具呼叫結果（tool result clearing）。邏輯很簡單：一旦某個工具在訊息歷史深處被呼叫過，Agent 通常不再需要重新看到那份原始回傳結果。這項功能已經在 Claude Developer Platform 上以正式功能推出。

生活妙喻

會議記錄從落落長逐字稿，變成一頁精華摘要

想像一場橫跨好幾天的專案會議

如果每一次接著開會，都要把過去所有會議的逐字稿全部重讀一遍，你會發現：

• 花費大量時間在重讀已經沒用的細節（例如某個早就解決的小問題來回討論了十分鐘）。
• 真正重要的決議（例如「我們決定用方案 B，原因是成本考量」），反而被淹沒在逐字稿的海量文字裡。

這正是不做壓縮、任由對話歷史無限累積的處境——就像第一章講的 context rot：資訊越多，反而越難精準抓到重點。

好的會議記錄員該怎麼做？

一個厲害的會議記錄員，不會逐字照抄，而是：

1. 保留：最終決議、還沒解決的爭議點、下一步待辦事項。
2. 省略：已經討論完、達成共識、不會再被翻出來的細節來回。

下一次會議開始前，與會者只需要看這份精華摘要，就能快速接續進度——不需要從頭讀完所有逐字稿，卻依然掌握關鍵脈絡。這正是 Compaction 的精神：不是「全部記住」，也不是「全部忘記」，而是有技巧地蒸餾出精華。

「清除工具結果」就像丟棄過時的附件

想像會議記錄裡附上了每一次討論時秀出的完整 Excel 報表——如果那份報表已經在第二次會議討論完、結論也寫進了會議紀要,你還需要在第十次會議的紀錄裡再翻出那份原始 Excel 全文嗎？通常不需要,結論已經被保留下來了。這正是「清除工具結果」的直覺：原始的工具輸出資料一旦已經被消化、結論已被記錄,就不必再佔用空間反覆保留。

實用超能力

動手調校你自己的 Compaction 系統

Compaction 流程圖

flowchart TD
    A[對話接近上下文視窗上限] --> B[把訊息歷史交給模型做摘要]
    B --> C[保留架構決策 未解決bug 實作細節]
    B --> D[丟棄重複工具輸出 過時訊息]
    C --> E[產生壓縮後的摘要]
    D --> E
    E --> F[搭配最近存取的檔案 重啟新上下文視窗]
    F --> G[Agent 繼續任務]

調校 Compaction 提示的實用步驟

1. **收集複雜的真實 Agent 執行紀錄（agent traces）**作為測試素材。
2. 第一輪：衝高召回率。寫一版壓縮提示，先確保幾乎所有重要資訊都被保留下來，容忍一些冗餘。
3. 第二輪：提升精確度。逐步檢視壓縮結果，找出「其實沒有幫助、可以刪掉」的內容，反覆修正壓縮提示。
4. 優先處理低風險的壓縮：例如先實作「工具結果清除」，這是相對安全、影響小的第一步。
5. 持續監控：留意是否有「壓縮後才發現遺漏了關鍵資訊」的情況，回頭補強壓縮提示的召回率。

自我檢查清單

設計自己的壓縮機制時，問自己：

• 我的壓縮邏輯有沒有明確區分「該留」（架構決策、未解 bug）與「該丟」（重複的工具輸出）？
• 我是先追求「不遺漏」，還是一開始就急著追求「精簡」？（建議順序是先不遺漏，再精簡）
• 有沒有做過「壓縮後繼續任務，結果發現關鍵資訊不見了」的事後檢討？

深度探秘

把記憶寫到上下文視窗之外

什麼是結構化筆記（Structured Note-taking）？

結構化筆記，也稱為代理式記憶（agentic memory），是第二個處理長任務情境污染的技巧。核心做法是：

Agent 定期把筆記寫下來，儲存在上下文視窗之外的地方；這些筆記會在之後需要的時候，被重新讀取、拉回上下文中。

這個技巧提供了開銷很小（minimal overhead）的持久記憶（persistent memory）。常見的具體例子包括：

• Claude Code 建立的待辦清單（to-do list）。
• 自訂 Agent 維護的一份 NOTES.md 檔案。

這種簡單的模式，讓 Agent 能夠：

• 追蹤複雜任務的進度。
• 維持關鍵的上下文與依賴關係——這些細節原本很容易在幾十次工具呼叫之間被沖散、遺失。

案例：Claude 玩《Pokémon》

本節用一個很有趣的非程式碼案例，展示記憶技巧的威力：Claude 玩《精靈寶可夢 Pokémon》。

Agent 在數千個遊戲步驟中，維持著精確的計數與追蹤，例如：

「過去 1,234 步，我一直在 Route 1 訓練我的寶可夢，Pikachu 已經朝著 10 級的目標，升了 8 級。」

在完全沒有被明確教導任何記憶結構的情況下，這個 Agent 自己發展出：

• 探索過區域的地圖。
• 記得已解鎖的關鍵成就。
• 維護戰鬥策略筆記，記錄哪些招式對哪些對手最有效。

上下文重置之後，Agent 會讀取自己先前寫下的筆記，接著繼續進行長達數小時的訓練或地城探索。這種「跨越摘要重置階段仍能保持連貫」的能力，讓原本只靠 LLM 上下文視窗本身、不可能達成的長期策略變得可行。

Memory Tool：正式產品化

作為 Sonnet 4.5 發布的一部分，Anthropic 在 Claude Developer Platform 上推出了一個公開測試版的記憶工具（memory tool）：

• 透過**檔案系統式（file-based）**機制，讓儲存與查閱上下文視窗之外的資訊變得更容易。
• 讓 Agent 能夠：
  • 隨時間累積知識庫。
  • 在多個工作階段（session）之間維持專案狀態。
  • 在不需要把一切都塞進上下文的情況下參考先前的工作。

生活妙喻

隨身筆記本：睡一覺醒來，靠昨天寫的筆記接續工作

想像你在玩一款需要好幾天才能通關的長篇遊戲

每天晚上你都要去睡覺（相當於 Agent 的「上下文重置」），第二天醒來，你已經不記得昨天發生的細節了。但只要你有寫日記／筆記的習慣，隔天早上翻開昨天寫的那頁，馬上就能接續：

「昨天我在森林區打到第三個 boss 失敗了兩次，發現用火系招式比較有效，還剩一個藥草還沒撿。」

光靠這一小段筆記，你就能立刻恢復狀態、繼續前進，完全不需要重新把前幾天玩過的每一秒都回想起來。

這正是結構化筆記的精神：不需要把所有細節都硬塞進大腦（上下文視窗），只要有一份可靠的筆記，重置後也能快速接上進度。

Claude 玩 Pokémon 就像一個很會寫遊戲筆記的玩家

有些玩家天生就會自己整理攻略筆記：哪裡的寶可夢比較好練、哪個技能對哪種對手特別有效、地圖哪些地方還沒探索過。這些筆記不是遊戲內建功能要求的，而是玩家自己養成的習慣——正如文中強調的：Claude 是「在完全沒有被提示該怎麼組織記憶的情況下」自己發展出這些筆記結構的。

NOTES.md 就像你貼在桌前的便利貼牆

把待辦事項、進度、關鍵決策寫在便利貼上貼在桌前，即使你去開了一整天會、腦袋暫時被別的事情占滿，回來看一眼便利貼牆，馬上就能想起「我剛才做到哪裡了」。NOTES.md 對 Agent 來說,就是這面便利貼牆。

實用超能力

為你的 Agent 設計一套筆記系統

結構化筆記的運作流程

flowchart TD
    A[任務開始 Agent 逐步執行工作] --> B[定期把關鍵進度寫入筆記]
    B --> C[筆記儲存在上下文視窗之外 例如檔案系統]
    C --> D[上下文視窗接近上限或發生重置]
    D --> E[Agent 讀取先前寫下的筆記]
    E --> F[依筆記內容接續任務 而非從零開始]
    F --> B

設計 NOTES.md 或待辦清單時的實用建議

1. 記錄「進度」而非「過程細節」：像「Pikachu 已升到第 8 級，目標 10 級」這種濃縮的狀態描述，比記錄「每一步發生了什麼」更有效率。
2. 記錄依賴關係與未解問題：例如「這個函式還依賴另一個尚未完成的模組」，避免任務接續時漏掉重要的關聯。
3. 定期更新，而非只在最後補寫：筆記的價值在於「隨時可被重置後的自己讀懂」，因此應該在關鍵節點就即時記錄。
4. 考慮使用 Memory Tool 這類檔案系統式機制：讓筆記可以跨越多個工作階段（session）持續累積，而不只是單次任務內有效。

檢查你的 Agent 是否需要結構化筆記

如果你的 Agent 符合以下任一種情況，就值得考慮加入結構化筆記機制：

• 任務會橫跨多次上下文重置或摘要才能完成。
• 任務有明確的階段性里程碑，例如「完成模組 A → 完成模組 B → 整合測試」。
• 需要在多個工作階段之間保留專案狀態,而不只是單次對話內有效。

深度探秘

不要一個人扛下全部上下文

子代理架構（Sub-agent Architectures）

這是第三個、也是本章最後一個處理長任務情境污染的技巧：子代理架構。

核心概念是：不要讓單一個 Agent 試圖在整個專案過程中維持所有狀態，而是讓專門化的子代理（specialized sub-agents）分別處理範圍明確的任務，各自使用**乾淨（clean）**的上下文視窗。

具體的分工模式是：

• 主代理（main agent）：負責掌握高層次的計畫（high-level plan），進行協調（coordinate）。
• 子代理（sub-agents）：負責執行深入的技術工作，或使用工具尋找相關資訊。

關鍵的效率設計在於：每個子代理可能會用掉數萬個甚至更多的 token 進行深度探索，但最終只回傳一份精簡濃縮的摘要給主代理——通常只有1,000 到 2,000 個 token。

這樣做的好處：清楚的關注點分離

這種架構達成了清楚的關注點分離（separation of concerns）：

• 細節搜尋的上下文，被隔離、封裝在子代理內部，不會外溢污染主代理的上下文。
• 主代理可以專心**綜合分析（synthesizing and analyzing）**各個子代理回報的結果，不需要背負每個子代理探索過程中的所有細節雜訊。

這個模式在「How we built our multi-agent research system」一文中有詳細討論，該研究顯示：在複雜的研究任務上，多代理系統相較於單一代理系統，有顯著的表現提升。

三種長任務技巧，各自的最佳戰場

本節最後把三個長任務技巧做了清楚的比較，指出該用哪個技巧,取決於任務特性：

即使模型能力持續進步，如何在延伸的長時間互動中維持連貫性，仍會是打造更有效 Agent 的核心挑戰。

生活妙喻

總編輯與外派記者：不用事事親自跑現場

想像一間報社在做一則跨國調查報導

沒有分工的做法：總編輯事事親力親為

如果總編輯試圖自己一個人飛到每一個城市、翻閱每一份原始文件、訪談每一位當事人，他的腦袋（上下文）很快就會被海量的細節塞爆，反而難以做出全局的判斷——這正是「context rot」在新聞編輯室的翻版。

有分工的做法：派出外派記者，只回報精華

更聰明的做法，是總編輯（主代理）派出好幾位外派記者（子代理）分頭到不同城市深入調查。每位記者可能翻閱了成堆的文件、訪談了十幾個人（相當於用掉數萬個 token 深度探索），但回報給總編輯的，只是一份精簡的調查摘要（相當於 1,000–2,000 token 的濃縮結果）：

「在 A 城市，關鍵證人證實了 X；在 B 城市，文件顯示 Y 可能不成立。」

總編輯不需要知道記者翻遍多少檔案櫃、繞了多少路才得到這個結論——他只需要專心綜合這些精華摘要，寫出最終的整篇報導。

這正是子代理架構的精神：細節探索留在「現場」（子代理），只有精華才回傳給「總部」（主代理），讓總部能保持清晰的全局視角。

三個技巧就像三種不同的專案管理風格

• 壓縮像是「開會記錄濃縮」：適合需要持續來回討論的專案。
• 結構化筆記像是「專案進度看板」：適合分階段、有明確里程碑的工作。
• 多代理像是「派外派記者分頭調查」：適合需要平行深入探索多個方向的複雜研究。

實用超能力

判斷該不該引入子代理，以及怎麼選擇長任務技巧

子代理架構的運作流程

flowchart TD
    A[主代理制定高層次計畫] --> B[將任務拆解成多個範圍明確的子任務]
    B --> C[子代理1 使用乾淨上下文深入探索]
    B --> D[子代理2 使用乾淨上下文深入探索]
    C --> E[子代理1只回傳精簡摘要 約1000到2000 token]
    D --> F[子代理2只回傳精簡摘要 約1000到2000 token]
    E --> G[主代理綜合分析所有摘要]
    F --> G
    G --> H[產出最終結果]

三選一的判斷指南

設計長任務 Agent 時，用這個表格快速判斷該優先採用哪個技巧（也可以組合使用）：

flowchart TD
    A[分析任務特性] --> B{任務需要大量來回對話}
    B -- 是 --> C[優先考慮 壓縮 Compaction]
    B -- 否 --> D{任務有清楚階段性里程碑}
    D -- 是 --> E[優先考慮 結構化筆記]
    D -- 否 --> F{任務需要平行深入探索多個方向}
    F -- 是 --> G[優先考慮 多代理架構]
    F -- 否 --> H[重新評估任務特性 或組合使用多種技巧]

實際應用檢查清單

考慮引入子代理架構前，問自己：

1. 這個任務能不能拆成範圍明確、彼此相對獨立的子任務？
2. 每個子任務是否需要大量探索才能得到答案，但最終結論本身可以濃縮成精簡摘要？
3. 主代理真正需要的是綜合判斷，而不是每個子任務的所有中間過程？

如果三個答案都是「是」，子代理架構很可能適合你的場景。反之，如果任務本身高度依賴連續、密集的來回對話，壓縮技巧可能更合適；如果任務有清楚的階段性進度要追蹤，結構化筆記可能更合適。