跳轉到主要內容
這個單元解決什麼問題prompt engineering 教你「這一句怎麼問」，context engineering 教你「模型在回答前，它的工作記憶裡應該有什麼、不該有什麼」，包括系統記憶體、外部資料注入、即時 RAG 檢索、工具調用狀態等等，統一用 context window 的視角來設計。在 agentic 工具上，模型會自己跑很多輪、自己累積讀檔與搜尋的結果，這時決定產出品質的，不是你某一句話的措辭，而是你對「進入視窗的一切」的管理。

​
學習目標

  • 能說出進入上下文視窗的四個來源，並判斷每個來源的相關性與成本。
  • 能解釋上下文腐化（context rot）與「lost in the middle」現象，並說出對「該塞多少」的實務影響。
  • 能說明壓縮、即時載入、子代理隔離如何在有限的上下文預算下管理資訊。
  • 能把「短期上下文」與「跨 session 長期記憶」分清楚，並對應到各工具的機制與風險。

​
1. 從 prompt engineering 到 context engineering

prompt engineering 的隱含假設是「一問一答」：你把問題雕琢到位，模型回一個答案，互動就結束了。這個假設在對話框時代成立，在 agentic 工具上失效。 Coding Agent 接到一個任務後，會自己讀檔、自己搜尋、自己執行、再根據結果決定下一步，一個任務可能跑幾十輪。每一輪的輸出都會堆回上下文視窗，下一輪的推理就建立在這堆東西之上。這時你能控制的槓桿，從「我這句話怎麼寫」變成「視窗裡此刻有什麼、它們的訊號雜訊比是多少」。 Anthropic 把 context engineering 定義為：在模型有限的「注意力預算（attention budget）」內，找出能最大化目標達成率的、最小的一組高訊號 token [1]。關鍵字是最小與高訊號。不是塞越多越好，是「剛好夠、而且都相關」。這跟工程直覺相反，多數人的第一反應是「把所有可能相關的都丟進去讓模型自己挑」，這正是品質崩壞的起點，原因見第 3 節。

​
2. 上下文的四個來源

進入視窗的東西，不管哪個工具，都可以歸到四類。每一類都有它的成本（佔多少 token、稀釋多少注意力）與相關性（對當前任務有多少幫助），你要對每一類都能做這個權衡。
  • 指令：系統提示、規則檔（CLAUDE.md / AGENTS.md / .claude/rules/）。這類訊號密度最高、最該留，因為它定義了模型的角色與約束，且整個 session 都在用。
  • 知識：附加的檔案、RAG 檢索回來的片段、@ 引用的內容。相關性差異最大的一類，引對了是關鍵證據，引錯了是純雜訊。
  • 歷史：當前對話的前文，加上跨 session 的長期記憶。會隨互動單調膨脹，是最需要主動壓縮的一類。
  • 工具結果：讀檔、grep、執行指令的回傳。常常體積巨大（一個 ls -R 或一份完整測試 log 動輒上千 token）卻只有一兩行真正有用。
把四個來源當成有預算的採購，不是吃到飽注意力預算是零和的。你多塞一份「可能有用」的檔案，等於從「確定有用」的指令與證據那裡，挪走了模型的注意力。每一個你放進去的東西，都該能回答「它為什麼非在這裡不可」。

​
3. 上下文腐化與 lost in the middle

「視窗有 200K token，所以我可以塞 200K」是錯的。視窗大小是物理容量，不是有效容量；模型用得好的部分，遠小於它能裝的部分。兩個有實證的現象支撐這個判斷。 Lost in the middle：Liu, et al.（2023）的研究發現，模型在長上下文裡的表現，與關鍵資訊的位置強相關，放在開頭或結尾時準確率最高，放在中段時顯著掉落，長到一定程度，中段資訊幾乎像沒給一樣 [2]。 Context rot：Chroma（2025）的技術報告測了 18 個模型（含 GPT-4.1、Claude 4、Gemini 2.5、Qwen3），發現模型對上下文的使用並非均勻，輸入越長、表現越不可靠；尤其當任務需要的是「語意比對」而非「字面比對」時，長輸入下的退化特別明顯 [3]。 兩個發現的共同含意很直接：更多上下文不等於更好，常常更糟。一份精準的 5K token 上下文，會打敗一份摻了大量「可能相關」雜訊的 100K token 上下文。對你的實務操作有兩個推論：
  1. 控制總量：寧可少而準。把「全塞進去讓模型自己挑」的衝動戒掉。
  2. 控制位置：最關鍵的指令與證據，放在上下文的開頭或結尾，不要埋在中段一大坨檔案內容裡。規則檔之所以有效，部分原因就是它通常被放在最前面。

​
4. 壓縮與即時載入：在預算內延續工作

長任務一定會撞到視窗上限。處理方式有兩條主線。 壓縮（compaction）：把接近上限的對話摘要成一段結構化的總結，再用這段總結開一個新視窗繼續，是維持長程連貫性的主要手段 [1]。在 Claude Code 裡，這件事一部分自動發生（接近上限時先清掉舊的工具輸出，再摘要對話），一部分你可以主動用 /compact 觸發，還能帶焦點（如 /compact focus on the API changes）指定要保留什麼 [4]。 這裡有一個你必須知道的機制細節：早期對話在自動壓縮時可能被丟掉，但專案根目錄的 CLAUDE.md 不會，壓縮後 Claude 會從磁碟重讀並重新注入。子目錄的 CLAUDE.md 不會自動重注入，要等 Claude 下次讀到那個子目錄裡的檔案才重新載入；壓縮摘要也只保留你實際用過的 skill，沒用到的 skill 描述不會被帶回新視窗（截至 2026-06）[4]。這就是為什麼「持久的規則寫進 CLAUDE.md，而不是在對話裡口頭交代」是硬建議，口頭交代的約束會在某次壓縮後悄悄蒸發 [4]。
用官方互動式視覺化看視窗裝了什麼Anthropic 有一頁互動式的上下文視窗模擬，逐項標出 session 起手自動載入的東西（系統提示、自動記憶 MEMORY.md、環境資訊、MCP 工具、skill 描述、~/.claude/CLAUDE.md、專案 CLAUDE.md）與各自的 token 估計，並示範 /compact 後哪些留、哪些走：探索上下文視窗（官方）（截至 2026-06）。把它當成你的「視窗預算」對照表。
即時載入（just-in-time）：不要一開始就把所有可能用到的資料全載進來，而是讓代理持有輕量的指標（檔案路徑、查詢、連結），需要時才用工具把對應資料拉進視窗 [1]。對 Coding Agent，這意味著給它檔案路徑與搜尋能力，比把整個 repo 貼進去更好；對研究工作流，這意味著給它資料集的位置與讀取工具，而不是把整份資料倒進對話。
重要任務預留緩衝一個經驗法則（非官方數字，見 01-2）：跨多檔的重要任務，盡量在視窗用到約八成前就收斂或主動壓縮，留約兩成緩衝。視窗越接近滿載，前面 lost in the middle 與 context rot 的效應越強，模型越容易在你最不希望出錯的收尾階段掉鏈子。

​
5. 記憶：短期 vs 長期

「記憶」這個詞被各家用得很混，但底層只有兩種，分清楚才不會誤用。 短期上下文：單一 session 視窗裡的對話。session 一關就沒了，本質是工作記憶。前面四節談的都是這層。 長期記憶：跨 session 持久化的資訊，下次開新對話它還在。三家主力工具的機制與名稱不同（截至 2026-05）：
  • Anthropic Claude：Claude.ai 有跨對話的記憶功能；Claude Code 則用磁碟上的檔案做持久層，專案級 CLAUDE.md、使用者級 ~/.claude/，外加 ~/.claude/projects/<repo>/memory/ 的自動記憶（v2.1.59+ 預設開啟，可用 autoMemoryEnabled 或環境變數停用）[4]。它的長期記憶是檔案、可讀可審、可進版控，這對可重現性是優點。
  • OpenAI ChatGPT：分「Saved Memories」（明確要它記的事實偏好）與「Reference chat history」（自動參考過去對話）。設定在 Settings > Personalization；關掉「Reference saved memories」會連帶關掉「Reference chat history」[5]。
  • Google Gemini：在「Personal context」下的「Memory」設定，預設開啟，會從過去對話學習；另有把其他應用的記憶匯入 Gemini 的功能 [6]。
開了長期記憶，不等於可以不管上下文兩個常被忽略的代價。其一，長期記憶是安全面：跨 session 持久化的記憶，是記憶污染（memory poisoning）與提示注入的載體，惡意內容可以分多次植入、日後組裝觸發，細節與防護見 03-3。其二，自動記憶會把你沒打算帶進來的舊偏好悄悄注入當前任務，反而是一種你沒控制的上下文污染。處理一次性敏感任務時，用暫時對話、或關掉記憶，是預設動作。

​
6. 檢索與引用：把外部知識接進視窗

當任務需要的知識不在模型訓練資料裡（你的論文、你的程式庫、最新文件），你得把它接進上下文。手段有兩類。 主動引用：你明確指定要載入什麼。@ 引用某個檔案、# 索引某個 repo、把檔案丟進 Projects（Claude / ChatGPT）/ Gems（Gemini）的知識庫。適合你已經知道哪幾份資料相關的情況，精準、可控。 RAG（檢索增強生成）：當資料量大到不可能全塞、你也不確定哪段相關時，先把資料切塊、向量化存進資料庫，查詢時只檢索回最相關的幾塊再放進視窗。它本質上是「即時載入」的自動化版本。你不需要為每個任務都上 RAG，先問：相關資料是否大到無法用 @ 直接引用？不是的話，直接引用更簡單也更準。 對研究者，這層的實務對應是：把要精讀的兩三篇論文用 @ 直接引用（精準），把要泛查的整個文獻庫接成知識庫或 RAG（規模）。別把這兩種搞反，泛查的東西全塞進視窗會觸發第 3 節的退化，精讀的東西丟進 RAG 又可能檢索不回關鍵段落。

​
向量檢索不是唯一解：以 PageIndex 為例

RAG 幾乎成了「外接知識」的同義詞，但向量檢索有結構性弱點，尤其在金融、法律這類高精度場景：語意相似不等於內容相關（查「營運利潤率」可能撈回一堆提到這詞的零散段落，卻漏掉真正含答案的那張表）、切塊破壞了原文的結構與語境、檢索結果不可追溯（你問不出「為什麼選這段」）。 PageIndex（MIT 授權的開源專案 [8]）走另一條路：vectorless、以推理取代相似度。它不做嵌入、不切塊，而是先把文件解析成一棵語意樹（每個節點帶標題、頁碼範圍與 LLM 生成的摘要），查詢時讓 LLM 像人類專家一樣讀目錄、定位章節、逐層往下推理，作法受 AlphaGo 的樹搜尋啟發 [8]。據其官方 repo，以此為底的系統在 FinanceBench 上達 98.7% 準確率（官方自報為 SOTA、明顯優於傳統向量 RAG；截至 2026-05）[8]。 兩條路的取捨：
維度PageIndex（樹狀推理）傳統向量 RAG
檢索機制LLM 逐層讀樹推理嵌入 + 餘弦相似度
預處理解析結構、生成節點摘要切塊、向量化
可解釋性高（檢索路徑即文件結構）低（只有數值距離）
推論成本與延遲較高（多次 LLM 推理遍歷節點）較低（向量距離計算極快）
最適場景單一深度文件（財報、合約）的精準問答大規模跨文件的模糊檢索
判準延續本節主線：先問規模與精度需求，再選手段。對一份結構清晰的長文件做高精度、可追溯的問答，樹狀推理檢索值得一試；在海量跨文件裡做模糊搜尋，向量檢索的速度與成本仍佔優，兩者也可混用。PageIndex 走 MCP，支援 MCP 的客戶端（如 Claude、Cursor）可直接接入（截至 2026-05）。

​
7. 子代理與上下文隔離

一個反直覺但極有效的技巧：把子任務丟給一個乾淨上下文的子代理（subagent）去做，主代理只接收它的結論。 為什麼有用？假設主任務需要「先搞清楚這個模組怎麼運作」。如果讓主代理自己去探索，它讀的二十個檔案、跑的十次 grep、走過的三條死路，全都會堆進主視窗，把後續真正要做的事擠到中段（觸發 lost in the middle），還燒掉大量 token。改成派一個子代理去探索，子代理在自己的獨立視窗裡翻完所有檔案，只回主代理一段「這個模組的運作摘要」。主代理的視窗裡，從頭到尾只有任務本身與這段乾淨摘要。 這就是隔離的雙重好處：省 token（探索過程不佔主視窗）與提品質（主代理不被探索雜訊干擾）。對應到工具，Claude 的 Subagent 機制就是為此設計，每個子代理有自己的上下文、自己的工具集、回傳結論而非過程 [7]，深入用法見 02-5。

​
8. 實務原則：最少必要上下文

把前七節收斂成可操作的判準。每次要往視窗裡放東西前，跑一遍：
  • 最少必要：預設不放，除非它能回答「為什麼非在這裡不可」。能用指標即時載入的，就不要預先全塞。
  • 高訊號優先：指令與直接證據留，「可能相關」的整包檔案砍。訊號雜訊比比絕對數量重要。
  • 管好位置：最關鍵的放開頭或結尾，不要埋中段。
  • 主動壓縮：長任務不要等視窗爆掉才被動壓縮，在收斂點主動 /compact 並指定焦點。
  • 持久的進檔案：要跨壓縮、跨 session 活下來的約束，寫進 CLAUDE.md，不要靠對話口述。
  • 隔離雜訊：探索性、發散性的子任務，丟給子代理，主視窗只收結論。
同一個研究任務，兩種上下文管理 任務：「根據這個 repo 的現有架構，幫我實作一個新的資料載入模組，風格要跟現有的一致，並參考這十篇論文裡的最佳實踐。」 Before（全塞，憑感覺）：把整個 repo（80 檔）拖進對話，把十篇 PDF 全貼上，然後說那句話。視窗瞬間用掉 150K token，真正的指令那句話埋在最前面、早被一堆檔案內容推到「中段」。模型開始實作，風格跟某個不相關的舊模組對齊（因為那個檔案剛好排在它還「看得到」的位置），論文裡的關鍵做法則完全沒被引用到（埋在中段，context rot）。 After（最少必要 + 隔離）：
  1. 先寫四行 CLAUDE.md：專案的命名慣例、錯誤處理規約、「新模組對齊 src/loaders/ 下的現有實作」。
  2. 只用 @src/loaders/base_loader.py 精準引用那一個要對齊的範本檔。
  3. 派一個子代理讀那十篇論文，回一段「資料載入相關的三個最佳實踐 + 出處」。
  4. 主代理視窗裡此刻只有：四行規則（開頭）、一個範本檔、一段論文摘要、那句任務。約 8K token，全部高訊號。
視窗內容（After）
┌─────────────────────────────────────────┐
│ CLAUDE.md 四行規則           ← 開頭    │
│ base_loader.py 範本                     │
│ 子代理摘要：三個最佳實踐                 │
│ 任務指令                     ← 結尾    │
│ 總計 ≈ 8K token，全高訊號              │
└─────────────────────────────────────────┘
結果差異不是「prompt 更聰明」，是 After 把模型的注意力，從「在 150K 雜訊裡撈訊號」變成「在 8K 全訊號裡執行」。多花的成本是前期三十秒的整理，省下的是一份對齊錯誤、得整個重做的產出。

​
工具對照

各家把同一組 context engineering 概念包裝成不同名稱（截至 2026-05，精確設定位置與查證見 02-2、02-6）。
機制Anthropic Claude（主範本）OpenAIGoogleGitHub CopilotCursor
長期記憶Claude.ai 記憶 / Claude Code CLAUDE.md、~/.claude/Saved Memories + Reference chat historyPersonal context → Memoryinstructions 檔（非自動記憶）User Rules / Memories
知識附加Projects 知識庫 / @ 檔案引用Projects / Custom GPT KnowledgeGems Knowledge / Drive 連接# 檔案、repo 索引@ 檔案 / @Docs / codebase index
主動壓縮自動 compaction + /compact（可帶 focus）自動對話摘要自動摘要自動自動
子代理隔離Subagent（獨立上下文、回傳結論）多代理 / AgentsAntigravity agents（無使用者層對等機制）Background agents
對照表只給座標，不給細節這張表的用途是讓你知道「同一個概念在你的工具叫什麼」。各 cell 的精確設定路徑、開關位置、版本差異屬快變動事實，統一在 02-2 與 02-6 查證並標註截至日期，本表不重複，以免出現多處不一致的版本。Copilot 與 Cursor 兩欄的部分機制名稱以較穩定的描述呈現，精確名稱以該工具官方文件為準。

​
常見誤區

反模式清單
  • 把視窗容量當有效容量：「有 200K 所以塞 200K」。有效容量遠小於物理容量，越滿越退化（第 3 節）。
  • 全塞讓模型自己挑：你以為是給模型更多資訊，實際是降低訊號雜訊比、把關鍵指令推進中段。少而準勝過多而雜。
  • 以為開了長期記憶就不用管上下文：自動記憶會注入你沒打算帶進來的舊偏好，是一種你沒控制的污染；且是記憶污染與提示注入的安全載體（03-3）。
  • 靠對話口述持久約束：自動壓縮會丟掉早期對話。要活下來的約束寫進 CLAUDE.md，它壓縮後會被重讀注入。
  • 凡事都上 RAG：相關資料小到能用 @ 直接引用時，RAG 只是增加檢索不準的風險。先問規模，再決定手段。
  • 讓主代理自己做發散探索：探索雜訊會塞爆主視窗又干擾推理。發散子任務丟給子代理，主視窗只收結論。

​
自我檢核

通過本單元的標準
  1. 給你一個跨多檔的複雜任務，你能說出「哪些該進上下文、哪些該留在外面用指標即時載入」，並講出理由嗎？
  2. 你能解釋為什麼「把關鍵約束寫進 CLAUDE.md」比「在對話裡交代一次」更可靠？答案跟壓縮機制有關。
  3. 你能指出你主力工具的長期記憶開關在哪、以及為什麼處理敏感任務時該關掉它嗎？
  4. 下次任務視窗開始膨脹時，你的第一個動作是繼續塞、還是主動壓縮或派子代理？為什麼？

​
來源與延伸閱讀

事實主張依官方文件與原始研究，快變動項標註截至 2026-05；採 IEEE 編號制。