有關 Context Engineering
實作中的領悟
在我做 AI 工具整合與應用的過程中，一開始我也像大多數人一樣，專注於提示工程：寫怎樣的 prompt 才能讓模型輸出正確的答案。但隨著專案規模擴大、對話輪數變多、跨工具協作越來越複雜，我漸漸感受到問題不只是 Prompt，而是整體脈絡管理。如果脈絡塞太多無關資訊，它就會「失焦」。
實驗脈絡壓縮（Compaction）、記憶寫入外部（Agentic Memory）、子智能體分工（Sub-agent Architecture）等策略是透過 AI 開發軟體工程的新議題。在這一路 Claude Code 也給了我許多現成的指令支持，像是 /compact 只是其中一環。下面我簡要列出它的其他常用指令與功能，幫助你更快上手。
Claude Code 功能
根據官方文檔與使用者資料，以下是幾個 Claude Code 的重要 Slash 指令與功能：
|
指令／功能 |
說明 |
|---|---|
|
/clear |
清除對話歷史，重置脈絡窗口，讓後續操作不被舊內容干擾。 |
|
/cost |
顯示目前 session 的 token 使用量與花費統計。 |
|
/help |
顯示可用指令清單與用法說明。 |
|
/init |
初始化一個專案（建立 CLAUDE.md 檔案等初始設定）。 |
|
/memory |
編輯或查看 Claude 的記憶檔案（外部儲存記憶 / 資料）。 |
|
/agents |
管理子智能體（subagents），可把特定任務交給子智能體處理。 |
|
/config |
查看或修改配置設定。 |
|
/model |
切換或設定使用的模型版本。 |
這些指令讓你在使用 Claude Code 開發與互動時，可以更靈活地管理脈絡、記憶與任務分工。原文翻譯自 Anthropic Applied AI 團隊文章：
以下是正文翻譯：
脈絡（Context） 是 AI Agent 的一項關鍵但有限的資源。本文將探討如何有效策劃與管理這個驅動智能體的脈絡。
在過去幾年裡，應用型 AI 的焦點主要放在 提示工程（Prompt Engineering）。但現在，一個新術語逐漸浮現：脈絡工程（Context Engineering）。使用語言模型已經不再只是尋找正確的提示語，而是要回答一個更廣泛的問題：「什麼樣的脈絡配置最有可能生成我們想要的模型行為？」
所謂脈絡，指的是在大型語言模型（LLM）取樣時包含的一組 token。工程上的問題，是如何在 LLM 的內建限制下，最佳化這些 token 的效用，從而穩定達成預期的結果。換句話說，操控 LLM 的核心在於思考「脈絡」，也就是：在任何時刻，考慮 LLM 可用的整體狀態，以及這些狀態可能導致的行為。
本文將探討正在興起的脈絡工程藝術，並提供一個精煉的思維模型，協助我們建構可控又高效的智能體。
Context Engineering vs Prompt Engineering
在 Anthropic，我們認為脈絡工程是提示工程的自然進化。
- 提示工程：著重於撰寫與組織 LLM 的指令，以獲得最佳輸出（例如如何設計系統提示）。
- 脈絡工程：則是策略集合，目的是在推理過程中策劃並維持「最佳的一組 token（資訊）」，涵蓋提示以外所有可能進入脈絡的資訊。
在 LLM 工程的早期，大部分應用（除了日常對話）都需要精心設計的一次性提示，用於分類或生成任務。因此，提示工程的重點是如何寫出有效的提示。然而，隨著我們開始打造更強大的智能體，能進行多輪推理並在更長的時間跨度下運作，我們需要的是：如何管理整個脈絡狀態（包含系統指令、工具、MCP、外部數據、訊息歷史等）。
一個在迴圈中運行的智能體會不斷生成新的數據，這些數據可能與下一輪推理相關，因此必須持續精煉。脈絡工程的藝術與科學，正是從這不斷演變的資訊宇宙中，挑選出要放進有限脈絡窗口的內容。
為什麼 Context Engineering 很重要
儘管 LLM 的速度越來越快，能處理的數據量越來越大，但我們觀察到，LLM 與人類一樣，在某個臨界點後會失去專注或產生混淆。
研究「大海撈針」測試時發現一個現象：脈絡腐化（Context Rot）。隨著脈絡窗口的 token 增加，模型準確回憶脈絡資訊的能力會下降。
雖然不同模型的退化曲線不同，但這是所有模型都會出現的特徵。這意味著：
- 脈絡必須被視為一種 有限資源，且存在邊際效益遞減。
- 就像人類的工作記憶有限一樣，LLM 擁有一個「注意力預算（Attention Budget）」。每增加一個 token，這個預算就會被消耗，使得精心策劃脈絡變得必要。
原因來自於 Transformer 架構：
- 每個 token 必須能與脈絡中的所有其他 token 交互，導致 n² 關聯關係。
- 當脈絡越長，注意力就會被攤薄。再加上訓練資料多以短序列為主，模型對長序列的處理能力天生不足。
雖然有技術（如位置編碼插值）能讓模型應對長序列，但仍會導致效能下降。因此，脈絡工程在設計可靠的 AI Agent 時至關重要。
有效 Context 的組成
良好的脈絡工程，就是找到最小的一組高訊號 token，以最大化達成目標的機率。
系統提示（System Prompts）
- 應該清晰、直接，用正確的「高度」描述任務。
- 過於繁瑣 → 脆弱且難維護；過於模糊 → 缺乏訊號。
- 最佳解：具體到足以引導，靈活到足以泛用。
建議將提示分為結構化區塊（如 <背景資訊>、<指令>、## 工具指引、## 輸出描述等），使用 XML 標籤或 Markdown 標頭清楚劃分。
工具（Tools）
- 工具是智能體與外部世界互動的橋樑。
- 工具應該：
- token 效率高，
- 功能邊界清晰，
- 錯誤可控。
- 常見錯誤是工具集過於龐大，導致判斷混亂。最小可行工具集更容易維護。
範例（Examples / Few-shot Prompting）
- 少量典型範例比「填滿所有邊界情況」更有效。
- 對 LLM 來說，範例就是「一張值千字的圖片」。
訊息歷史（Message History）
- 要保持資訊緊湊，不要讓冗餘訊息佔據有限脈絡。
脈絡檢索與智能搜尋
許多 AI 應用會在推理前，透過 嵌入檢索（Embedding Retrieval） 提取脈絡。隨著發展趨勢，更多團隊採用 即時檢索（Just-in-time Retrieval）。
- 預處理模式：事先把所有可能用到的資訊放進脈絡。
- 即時模式：保留輕量索引（檔案路徑、查詢語句、連結），在需要時才動態載入。
Claude Code 採用即時檢索，可針對大型資料庫寫查詢、取結果、用 bash 工具（head/tail）分析，而不是把整個資料庫載入脈絡。這與人類的方式相似——我們依靠檔案系統、書籤，而不是記住所有細節。
這種方式雖然較慢，但能讓智能體逐步探索、逐步揭露相關脈絡，並保持專注。
長時任務的脈絡工程
長時任務（如大型程式碼遷移、研究專案）常超出 LLM 的脈絡窗口，需要特殊技巧：
- 壓縮（Compaction）
- 將臨近上限的對話總結壓縮，保留關鍵決策與細節，捨棄冗餘訊息。
- 風險是壓縮過度會丟失重要但隱性的上下文。
- 結構化筆記（Structured Note-taking / Agentic Memory）
- 智能體定期將筆記存到外部，日後再載回脈絡。
- 例如 Claude Code 的 TODO 列表、遊戲智能體的地圖與進度追蹤。
- 子智能體架構（Sub-agent Architectures）
- 讓不同專門子智能體負責子任務，各自維持乾淨脈絡，再由主智能體整合結果。
- 適合複雜研究與分析場景。
結論
脈絡工程 代表著我們與 LLM 共建方式的根本轉變。
隨著模型變得更強，挑戰不再只是「寫出完美提示」，而是 謹慎策劃在每一步放入模型的有限注意力預算中的資訊。
不論是：
- 為長任務進行壓縮，
- 設計高效的工具，
- 或讓智能體在需要時即時探索環境，
原則始終相同：找到最小、最高訊號的一組 token，以最大化達成目標的可能性。
✍️ 撰文：Anthropic 應用 AI 團隊
Prithvi Rajasekaran, Ethan Dixon, Carly Ryan, Jeremy Hadfield
貢獻成員：Rafi Ayub, Hannah Moran, Cal Rueb, Connor Jennings
特別感謝：Molly Vorwerck, Stuart Ritchie, Maggie Vo