昨天我們把 Context 想成 AI 的工作桌：系統規則、對話紀錄、目前問題、工具查到的資料，都可能暫時放在桌上。
但工作桌有一個殘酷的規則：不是桌子越大，就越適合把東西一直堆上去。
假設你請 Agent 幫忙規畫三天兩夜的台南旅行。它為了回答你，可能查了十幾家旅館、火車時刻、景點營業時間、雨天備案，以及幾個已經關門的店家。最後你真正想看的，也許只是一張表：住哪裡、怎麼走、每天做什麼、遇雨怎麼辦。
如果那些網頁原文、選單、跳出來的 Cookie 提示、搜尋失敗紀錄，全都一直留在主 Agent 的 Context 裡，就像出發前把所有收據、傳單和舊行程都塞進同一個背包。車票可能還在，但每次要找都得先翻半天。
這就是今天要處理的問題：
不只要決定什麼資訊該放進 Context，也要決定哪些探索應該在別的地方完成，最後只帶回真正有用的結果。
Anthropic 把 Context 視為有限資源：內容變長時，模型找出並正確使用重要資訊的能力可能逐漸變差；這種現象常被稱為 Context Rot。它也提醒，即使未來 Context Window 更大，資訊的相關性與干擾仍然會是問題，這裡稱為 Context Pollution。這不是說「多放一個字就壞掉」，而是提醒我們：每一段不相關內容，都可能搶走一點注意力。Anthropic 的說明
所以 Context Engineering 不只是「讓 AI 記得更多」。更像是：
讓該知道的人知道該知道的事；不必讓每個人同時背下整本百科全書。
假設你和 AI 開了一個對話，要一起準備報告：
我要做一份「台灣夜市文化」的簡報。
你們一路討論大綱、資料來源、投影片順序。這些內容都在同一條主線上，很有幫助。
可是聊到一半，你突然插進來：
對了，幫我想今天晚餐吃什麼。
最近股市綠油油，我可以抄底哪一隻？
下個月去東京住上野還是新宿？
剛剛那份履歷的自傳再潤一次。
好，回到夜市簡報。
每一題都合理，AI 也都能回答；問題是，這張「夜市簡報工作桌」現在同時放了菜單、股票、東京地圖與履歷。它們未必是錯誤資訊，卻會讓目前任務的主軸變模糊。
這就是最生活化的 Context Pollution：資料不是垃圾，只是放錯桌。
所以一個很實用的習慣是：
一個主要 Context
≈
一條主要工作線
小岔題不用每次都另開對話；但如果要開始一個會持續討論的新專案，開新 Chat 通常更乾淨。這不是 AI「失憶」，而是你替不同專案開不同資料夾：
夜市簡報/
日本旅遊/
履歷/
電腦疑難排解/
硬碟很大，不代表所有檔案都該放 Desktop；Context Window 很長，也不代表所有對話都該塞進同一串。
再回到旅行規畫。最直覺的流程是：
主 Agent
↓
搜尋景點
↓
打開很多網頁
↓
讀飯店、交通、評論與地圖
↓
把所有 Tool Results 留在 Context
↓
整理行程
最後的行程可能只有 500 字，但過程中讀進來的內容可能非常多，而且大部分只是「為了查到答案而暫時看過」。
真正對最後規畫有價值的，可能是這些：
## 台南三日行程：已確認事項
- 住宿：A 區到主要景點交通方便；入住規則已確認。
- 交通：第一天可搭火車，市區用公車與步行較順。
- 雨天備案：博物館與室內市集。
## 仍要確認
- 某間店今天到底有沒有營業，出發前再查一次。
## 來源
- 官方交通資訊
- 旅館官方頁面
- 景點官方公告
注意這不是把細節偷偷刪掉，而是把細節變成「可追查的來源」。主 Agent 不必把每個網頁的導覽列都背起來，卻仍能知道結論從哪裡來、哪一點還不確定。
這時就輪到 Subagent（子 Agent） 出場了。
你可以把它想成一位有明確任務的研究助理。主 Agent 說：「請查台南雨天景點，只回報開放時間、位置、適合原因與官方來源。」研究助理自己去翻資料；主 Agent 則繼續守著整份行程的目標與限制。
概念上像這樣：
┌─────────────────────┐
│ Research Subagent │
│ │
主 Agent ─任務→ │ 搜尋與閱讀資料 │
│ 比較多個來源 │
│ 記錄矛盾與不確定處 │
└─────────┬───────────┘
│
精簡摘要 + 證據
↓
主 Agent
關鍵不只是「多一個 AI，所以比較快」，而是 Context Isolation（上下文隔離）：研究助理在自己的工作桌上忙，主 Agent 的桌面不會跟著被塞滿。
研究用的 Subagent 可以在自己的工作桌上放滿搜尋結果、HTML、404 頁面與走錯路的紀錄。回到主 Agent 時，只帶回對決策有用的摘要、來源和風險。
Claude Code 的官方文件就把這列為適用情境：當旁支工作會淹沒主對話的搜尋結果、Log 或檔案內容，而你之後又不需要逐字引用它們時，交給 Subagent 在自己的 Context 完成，再回傳摘要。Claude Code：Subagents
初學者常會卡在這裡：我知道可以分工，但要輸入什麼？
先說清楚一件事：不是每個聊天工具看到 subagent_1 就會真的派出一位子 Agent。你必須使用本身支援 Subagent 或多 Agent 的工具；而在這些工具裡，最簡單的起點往往不是背一段神祕指令，而是用自然語言講清楚誰要查什麼、最後交回什麼。例如，主 Agent 要幫你規畫台南一日遊時，可以這樣說：
請把台南一日遊的資料蒐集拆成兩個子任務：
- subagent_1：搜尋明天台南市區天氣與降雨機率，
只使用官方氣象來源；回傳上午、下午、晚上摘要，
再給一項穿著或雨具建議，附來源網址。
- subagent_2：搜尋台南市區適合午餐的在地小吃，
優先找店家或官方觀光資訊；回傳 3 個選項、營業時間、
大概位置與來源網址；無法確認營業時間要標示「待確認」。
等兩份結果回來後，請你整合成一份一日行程；
不要把搜尋過程全文貼回來，只保留結論、來源和不確定處。
這段指令的重點不是 subagent_1、subagent_2 這兩個名字多厲害；它們只是方便我們辨認兩份工作。不同產品的實際呼叫方式可能不同：有些系統能依自然語言自行委派，有些需要在程式或設定檔中明確建立 Agent。不管工具介面怎麼變，清楚的任務說明都一樣重要。
這也回應了一個常見誤會：有 Agent 之後，是不是只要說「幫我弄好」？
Agent 可以協助你拆解問題，但你仍需要知道最後要做哪個決定，以及決定需要哪些資訊。想安排台南一日遊，至少要想到天氣會影響室內或戶外行程、美食要看地點與營業時間；因此才會知道要把「天氣」和「午餐」分成不同子任務。
這不表示每個人都要先變成氣象專家或美食部落客。比較像你去醫院前，知道要描述哪裡不舒服、何時開始、什麼情況會更嚴重；醫師仍是專家，但你的描述會決定檢查方向。
換句話說，好的 Prompt 不是咒語，而是你對任務的理解被說清楚：
我想完成什麼？
↓
要靠哪些資訊做決定？
↓
哪些部分可以各自獨立查？
↓
每位 Subagent 應交回什麼？
當你還不知道怎麼拆時，也可以先請主 Agent 協助：
「我要規畫台南一日遊。請先不要搜尋，先告訴我需要確認哪些問題，以及哪些可以各自交給 Subagent。」
先拆題、再委派，通常比一開始就把十個 Agent 放出去亂跑可靠得多。
這不只是比喻。Anthropic 公開介紹過它的多 Agent 研究系統：一個主 Agent 先規畫研究方向，再派多個專門的 Subagent 分頭搜尋；各自整理發現後，交回主 Agent 綜合成答案。它特別把 Subagent 描述成能過濾大量搜尋內容的角色。How we built our multi-agent research system
這個案例能支持「隔離探索、回傳濃縮結果」的設計；不過它不能支持「多 Agent 永遠比較好」的論點。那篇文章也指出：若工作高度互相依賴、每一步都要共用完整脈絡，硬拆成多個 Agent 反而可能增加溝通成本。
假設研究 Subagent 的路線是：
搜尋 1 → 找到舊公告
搜尋 2 → 網頁 404
搜尋 3 → 發現店家已歇業
搜尋 4 → 找到官方 FAQ
搜尋 5 → 找到最新公告
這些過程對研究者很重要，因為它要判斷最後該信哪個來源；但主 Agent 通常不需要逐筆重播。它真正該收到的是：
官方公告是目前採用的來源；舊公告已過期，歇業店家不納入行程。
除非那次 404 或矛盾會影響結論，否則它不必一直佔著主 Context。就像同學幫你查資料時，不會先從「我第一個關鍵字少打一個字」講起；你更需要的是結果、證據與還沒查清楚的地方。
過程中有用的資訊，不等於後續每一步都還有用。
Day 9 我們用過：
Agent ≈ Model + Harness
到了今天，可以再補一句：Harness 不只把資料送進模型，也負責決定哪些資料留在目前工作區、哪些工作交出去、哪些結果值得帶回來。初學時，可以先把 Harness 想成 Agent 外面的「工作管家」。
好的流程比較像：
主 Agent 定義子任務
↓
Subagent 在獨立 Context 探索
↓
回傳 Summary / Evidence / Uncertainty
↓
主 Agent 只用必要內容繼續推理
OpenAI Agents SDK 也把這件事做成可設計的選項，叫做 Handoff（交接）：預設會把對話歷史交給下一個 Agent，但開發者可以指定規則，改變它實際看到的歷史內容。初學者暫時不用背 inputFilter 這個設定；先記得「交接時要帶什麼資料」是可以設計的，就夠了。OpenAI Agents SDK：Handoffs
把同一份 Context 複製給十個 Agent，不會自動得到十倍智慧；有時只會得到十個一起找不到便當訂單的人。好的分工，是每個 Agent 都拿到完成自己任務所需、且足夠可靠的資訊。
看到這裡，很容易進入「什麼都外包」模式：查一個名詞派一位、改一個標點派一位、決定珍奶半糖還是微糖也成立一個委員會。
但 Context Isolation 有成本：主 Agent 得交代任務、限制和必要背景；Subagent 做完又得把結果說清楚。若任務需要不斷來回、每一步都依賴前面的細節，隔離反而可能讓它缺少關鍵脈絡。
可以用這張小判斷表：
| 工作特性 | 較適合的做法 |
|---|---|
| 要查很多資料，最後只需要結論與來源 | 交給 Subagent |
| 會產生大量 Log、網頁或檔案內容 | 交給 Subagent |
| 必須一直參考剛才的決策、反覆討論 | 留在主 Agent |
| 改一個小地方，交代成本比工作還大 | 留在主 Agent |
所以問題不是「要不要用 Subagent」，而是：
這段工作產生的中間資訊，之後還需要一直被主線使用嗎？
如果答案是「不用，給我結論、證據與不確定處就好」，它就很適合被隔離。
即使我們沒有岔題，也沒有亂讀網頁，長時間工作仍會慢慢塞滿 Context：
使用者要求
→ 模型分析
→ File Read
→ Tool Call
→ Tool Result
→ 修改與測試
→ 下一輪
這時常見的策略叫 Compaction（壓縮整理）：把快接近上限的對話，整理成一份可接力的摘要，再從較乾淨的 Context 繼續。把它想成寫一張「換人也接得下去」的交班便條。
它不是：
把以前全部忘記。
而是：
保留：目標、已完成工作、重要決策、失敗嘗試、
未解問題、下一步、關鍵檔案與證據位置
移除：重複對話、已不需要的原始 Tool Output
Anthropic 對 Compaction 的說法也很接近這個概念：保留架構決策、未解錯誤與實作細節，捨棄重複訊息或較早的原始工具輸出。真正困難的是「留下什麼」，不是單純把字數砍半。Effective context engineering for AI agents
想親眼看見壓縮會遺失哪些細節嗎？可以執行 Day 13 練習 Notebook：50 字摘要會帶走什麼？：它會先把一則約 300 字故事交給 Qwen 壓成 50 字，再把保留與可能遺失的元素攤開來比較。
假設你和 AI 做了十次嘗試，前九次失敗。糟糕的摘要是：
最後方案成功。
比較好的摘要是：
目標：讓會員能重設密碼。
已完成：寄信流程可正常發送。
已決定：重設連結有效期為 30 分鐘。
已排除：舊 API 不支援目前的驗證方式，勿再使用。
目前問題：手機版按鈕太窄。
下一步：修正版面後測試小螢幕。
下一個 Agent（或明天的你）不需要閱讀八小時逐字稿，卻不會把已證明行不通的方法再做一次。專案不用因為換了一個 Context 就重新投胎。
把 Day 12 和今天合起來，Context 不再只是「丟資料進去」：
資料與指令
↓
Harness 選擇、過濾、分派
↓
主 Agent 保留的內容
↓
Model 推理與使用工具
↓
保留重要結果；摘要或隔離其餘過程
↓
下一輪 Context
如果 Model 是負責思考的人，Harness 很像坐在門口整理公文的人：
什麼都直接往辦公室裡丟，再聰明的人也可能找不到桌面。
前一篇在問：AI 還需要知道什麼？
今天則多問一題：
哪些東西不必一直留在它眼前？
真正可用的 Agent，通常不是靠「更多資料 + 更長 Context + 更多工具」就完成；還要加上：
－ 不相關資訊
－ 過時資訊
－ 重複資訊
－ 不需要回傳的中間過程
知道什麼時候該搜尋，是能力；知道搜尋結果哪些該留下，也是能力。知道何時找研究助理、何時另開一個對話、何時寫好交接摘要，都是 Context Engineering 的一部分。
Context Engineering 到最後，不只是記憶工程；它也是：
選擇、隔離、壓縮與遺忘的工程。
下一篇我們會離開 Context Engineering，來看個人如何使用 OpenAI、Anthropic、Google、Ollama 與其他 AI 產品。
參考資料
iThome鐵人賽
看影片追技術