/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](/code-agent/judgment/security-privacy-supply-chain)。其二，自動記憶會把你沒打算帶進來的舊偏好悄悄注入當前任務，反而是一種你沒控制的上下文污染。處理一次性敏感任務時，用暫時對話、或關掉記憶，是預設動作。
## 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](/code-agent/configuration/skills-hooks-subagents-plugins)。
## 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，全部高訊號。
結果差異不是「prompt 更聰明」，是 After 把模型的注意力，從「在 150K 雜訊裡撈訊號」變成「在 8K 全訊號裡執行」。多花的成本是前期三十秒的整理，省下的是一份對齊錯誤、得整個重做的產出。
## 工具對照
各家把同一組 context engineering 概念包裝成不同名稱（截至 2026-05，精確設定位置與查證見 [02-2](/code-agent/configuration/anthropic-claude-setup)、[02-6](/code-agent/configuration/other-tools-comparison)）。
| 機制 | Anthropic Claude（主範本） | OpenAI | Google | GitHub Copilot | Cursor |
| ----- | --------------------------------------------------- | --------------------------------------- | ------------------------- | --------------------- | --------------------------------- |
| 長期記憶 | Claude.ai 記憶 / Claude Code `CLAUDE.md`、`~/.claude/` | Saved Memories + Reference chat history | Personal context → Memory | instructions 檔（非自動記憶） | User Rules / Memories |
| 知識附加 | Projects 知識庫 / `@` 檔案引用 | Projects / Custom GPT Knowledge | Gems Knowledge / Drive 連接 | `#` 檔案、repo 索引 | `@` 檔案 / `@Docs` / codebase index |
| 主動壓縮 | 自動 compaction + `/compact`（可帶 focus） | 自動對話摘要 | 自動摘要 | 自動 | 自動 |
| 子代理隔離 | Subagent（獨立上下文、回傳結論） | 多代理 / Agents | Antigravity agents | （無使用者層對等機制） | Background agents |
**對照表只給座標，不給細節**
這張表的用途是讓你知道「同一個概念在你的工具叫什麼」。各 cell 的精確設定路徑、開關位置、版本差異屬快變動事實，統一在 [02-2](/code-agent/configuration/anthropic-claude-setup) 與 [02-6](/code-agent/configuration/other-tools-comparison) 查證並標註截至日期，本表不重複，以免出現多處不一致的版本。Copilot 與 Cursor 兩欄的部分機制名稱以較穩定的描述呈現，精確名稱以該工具官方文件為準。
## 常見誤區
**反模式清單**
* **把視窗容量當有效容量**：「有 200K 所以塞 200K」。有效容量遠小於物理容量，越滿越退化（第 3 節）。
* **全塞讓模型自己挑**：你以為是給模型更多資訊，實際是降低訊號雜訊比、把關鍵指令推進中段。少而準勝過多而雜。
* **以為開了長期記憶就不用管上下文**：自動記憶會注入你沒打算帶進來的舊偏好，是一種你沒控制的污染；且是記憶污染與提示注入的安全載體（[03-3](/code-agent/judgment/security-privacy-supply-chain)）。
* **靠對話口述持久約束**：自動壓縮會丟掉早期對話。要活下來的約束寫進 `CLAUDE.md`，它壓縮後會被重讀注入。
* **凡事都上 RAG**：相關資料小到能用 `@` 直接引用時，RAG 只是增加檢索不準的風險。先問規模，再決定手段。
* **讓主代理自己做發散探索**：探索雜訊會塞爆主視窗又干擾推理。發散子任務丟給子代理，主視窗只收結論。
## 自我檢核
**通過本單元的標準**
1. 給你一個跨多檔的複雜任務，你能說出「哪些該進上下文、哪些該留在外面用指標即時載入」，並講出理由嗎？
2. 你能解釋為什麼「把關鍵約束寫進 `CLAUDE.md`」比「在對話裡交代一次」更可靠？答案跟壓縮機制有關。
3. 你能指出你主力工具的長期記憶開關在哪、以及為什麼處理敏感任務時該關掉它嗎？
4. 下次任務視窗開始膨脹時，你的第一個動作是繼續塞、還是主動壓縮或派子代理？為什麼？
## 來源與延伸閱讀
事實主張依官方文件與原始研究，快變動項標註截至 2026-05。
* \[1] Anthropic, "Effective context engineering for AI agents," Anthropic Engineering, 2025.（注意力預算、即時載入、壓縮）[https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) （截至 2026-05）
* \[2] N. F. Liu, K. Lin, J. Hewitt, A. Paranjape, M. Bevilacqua, F. Petroni, P. Liang, "Lost in the Middle: How Language Models Use Long Contexts," *Transactions of the ACL*, 2024（arXiv:2307.03172, 2023）。[https://arxiv.org/abs/2307.03172](https://arxiv.org/abs/2307.03172)
* \[3] Chroma, "Context Rot: How Increasing Input Tokens Impacts LLM Performance," Chroma Technical Report, 2025. [https://www.trychroma.com/research/context-rot](https://www.trychroma.com/research/context-rot) （截至 2026-05）
* \[4] Anthropic, "How Claude remembers your project"（memory 與 `/compact`、壓縮後重讀 `CLAUDE.md`）與 "探索上下文視窗"（視窗載入順序與壓縮存活規則），Claude Code Docs. [https://code.claude.com/docs/en/memory](https://code.claude.com/docs/en/memory) 、 [https://code.claude.com/docs/zh-TW/context-window](https://code.claude.com/docs/zh-TW/context-window) （截至 2026-06）
* \[5] OpenAI, "What is Memory?" / "Memory FAQ"（Saved Memories、Reference chat history），OpenAI Help Center. [https://help.openai.com/en/articles/8983136-what-is-memory](https://help.openai.com/en/articles/8983136-what-is-memory) （截至 2026-05）
* \[6] Google, "Get personalization in Gemini Apps"（Personal context → Memory），Gemini Apps Help. [https://support.google.com/gemini/answer/16598623](https://support.google.com/gemini/answer/16598623) （截至 2026-05）
* \[7] Anthropic, "Create custom subagents"（子代理獨立上下文、工具集、回傳結論），Claude Code Docs. [https://code.claude.com/docs/en/sub-agents](https://code.claude.com/docs/en/sub-agents) （截至 2026-05）
* \[8] VectifyAI, "PageIndex: vectorless, reasoning-based RAG"（樹狀推理檢索、AlphaGo 啟發、FinanceBench 98.7% 官方自報、MIT 授權、MCP 支援），GitHub, 2025. [https://github.com/VectifyAI/PageIndex](https://github.com/VectifyAI/PageIndex) （截至 2026-05）
* 銜接：[01-1](/code-agent/foundations/why-correct-usage) 心智模型、[01-2](/code-agent/foundations/llm-agent-basics) token 與視窗的技術基礎、[02-2](/code-agent/configuration/anthropic-claude-setup) Claude 設定、[02-5](/code-agent/configuration/skills-hooks-subagents-plugins) Subagent、[03-3](/code-agent/judgment/security-privacy-supply-chain) 記憶污染與供應鏈風險。