Context Engineering 完整實戰指南：從 Prompt 操作升級到脈絡架構設計

你的 AI agent 在第 5 輪對話開始前後矛盾，選錯工具，或者乾脆「失憶」，重複問同樣的問題。你反覆改 prompt，但問題依舊出現。這不是你的指令寫得不夠精準——根據 Cognition AI 的說法，大部分 AI agent 失敗的根因是 context 架構問題，而不是指令措辭。

2026 年，AI 工程師需要掌握的核心技能正在發生根本性轉變：從「寫好 prompt」升級到「設計 AI 系統的脈絡架構」。本文提供完整實戰框架，從 Karpathy 的精確定義出發，拆解四種失敗模式、四大策略、工具選型，以及台灣開發者可以今天就開始的三層漸進路徑。

TL;DR

• 核心定義（Karpathy）：context engineering 是「在 context window 中填入恰到好處資訊的精妙藝術與科學」。LLM 如 CPU，context window 如 RAM，工程師的工作是在每個步驟把正確的資料載入工作記憶。
• 四種失敗模式：Context Poisoning（幻覺資訊複利惡化）、Context Distraction（歷史累積過多）、Context Confusion（不相關資訊干擾工具選擇）、Context Clash（跨輪次矛盾資訊）
• 四大策略：Write（外存資訊）、Select（選取相關資訊）、Compress（壓縮 token 用量）、Isolate（拆分 agent 環境）
• 入門路徑：RAG + scratchpad（第一層）→ Summarization 壓縮（第二層）→ Multi-agent isolation（第三層，視需求）

---

Context Engineering 是什麼？為什麼 Prompt Engineering 不夠了？

2025 年 6 月，Andrej Karpathy 在 X 上發表了一則定錨性的貼文，明確支持「context engineering」這個詞：

"+1 for 'context engineering' over 'prompt engineering'. People associate prompts with short task descriptions you'd give an LLM in your day-to-day use. When in every industrial-strength LLM app, context engineering is the delicate art and science of filling the context window with just the right information for the next step."

這不只是換個術語。Karpathy 指出的是一個視角的根本轉移。

Prompt engineering 問的是：「我要怎麼說才能讓模型做對？」 Context engineering 問的是：「模型需要知道什麼才能做對？」

前者聚焦指令措辭，後者聚焦資訊架構。在單次交互場景（問一個問題、做一次翻譯），prompt 的影響力確實足夠。但當任務變成多步驟的 agent 工作流，需要跨對話記憶、動態工具使用、條件分支推理時，prompt 本身的措辭已經不是瓶頸——瓶頸是 context window 裡裝了什麼、怎麼裝。

Karpathy 提出的心智模型值得記住：LLM 如 CPU，context window 如 RAM，工程師的工作如 OS 管理。每次推理之前，你決定把哪些程式碼和資料載入工作記憶。載錯了，CPU 無論多快都跑不出正確結果。

這也是為什麼 Cognition AI 直接把 context engineering 定位為「AI agent 工程師的 #1 工作」。Cognition 的工程師在建立複雜 agent 系統時發現，模型的能力已經足夠，最終限制都來自資訊管理——什麼資訊在 context 裡、什麼時候放進來、放多少。

---

四種 Context 失敗模式：為什麼你的 Agent 會崩潰

根據 LangChain 整理的框架，agent 失效有四種清晰的模式，理解這四種模式是設計防禦策略的前提。

1. Context Poisoning（脈絡污染）

幻覺資訊進入 context 之後，不會自動消失。後續的每一輪推理都會以這個錯誤資訊為基礎，形成複利惡化的效果。舉例：agent 在第 3 輪產生了一個錯誤的用戶偏好判斷，在第 7 輪，這個判斷已經被當成事實被引用了三次。

防禦手法：Context quarantine（隔離可疑資訊段落）、驗證機制（來源交叉確認後才寫入長期記憶）。

2. Context Distraction（脈絡干擾）

累積的對話歷史越來越長，模型開始過度依賴舊行為模式，即使 context window 夠大也不能免疫。SwirlAI 2026 報告記錄了一個具體的量化門檻：工具超過 10 個，agent 準確率開始顯著下降；90 個工具等同於 50K+ tokens 的 overhead，直接耗盡大量 context 預算。

這個現象也被 Hacker News（915 upvotes）的工程師社群廣泛討論：工程師們報告，廠商宣稱支援百萬 token，但實測約 10k tokens 之後準確率明顯下滑。

防禦手法：定期 summarization 壓縮歷史、工具數量控制在 10 個以下。

3. Context Confusion（脈絡混淆）

不相關的資訊塞滿了 context window，模型在工具選擇和任務執行上開始出錯。這是「lost-in-the-middle」現象的具體表現：LLM 對放在 context 中間位置的資訊注意力顯著低於開頭和結尾，這個特性不因 context window 變大而改善。

防禦手法：RAG 只選最相關的 20-30 個 chunk；重要資訊放開頭或結尾，不要埋在中間。

4. Context Clash（脈絡衝突）

跨對話輪次出現矛盾資訊時，模型的推理能力會快速崩壞。例如 agent 在第 1 輪得到「用戶偏好英文輸出」，第 8 輪又收到「所有輸出請用繁體中文」，如果沒有明確的衝突解決機制，模型的行為會變得不可預測。

防禦手法：Context pruning（剔除舊有衝突資訊）、明確的「最新指令優先」規則。

---

四大策略：Write / Select / Compress / Isolate

LangChain 的 Lance Martin 在研究生產環境 agent 系統後，整理出四個核心策略類別。這個框架現在已經成為 context engineering 的基礎共識。

Write：把資訊外存保留

Write 策略把重要資訊寫到 context window 以外的地方，確保跨輪次或跨對話的資訊持久性。分兩個層次：

• 短期 scratchpad：讓 agent 在同一任務中把中間推理結果、已完成步驟寫下來，防止「失憶」
• 長期 memory：把用戶偏好、任務歷史、重要決策寫入 vector DB 或結構化儲存，供後續對話取用

何時用：任何需要跨對話記憶的場景；多步任務需要追蹤執行狀態時。

Select：選取最相關的資訊

Select 策略從外部儲存動態拉取最相關的資訊進入 context window，而不是把所有東西都塞進去。

• Embedding 搜尋 + RAG：從知識庫取出最相關的 chunk
• 工具描述篩選：不是所有工具描述都放進 context，只放當前任務可能需要的子集

Pinecone 定義了 context 的五個關鍵元素：對話歷史、用戶輸入、長期記憶、背景知識、工具定義。Select 策略的核心就是在這五個桶子裡，精準取出當前步驟需要的部分。

何時用：有大型知識庫的系統；工具數量超過 10 個的 agent。

Compress：壓縮 token 用量

Compress 策略在保留關鍵資訊的前提下，減少 context 占用的 token 數量。這是預算有限時 ROI 最高的優先策略。

• Summarization：把長對話歷史壓縮為摘要
• Trimming：剔除不再相關的舊有資訊
• Prompt caching：把常用的系統 prompt 或知識庫段落緩存，避免每次重新計算

DEV Community 的 Gabriel Henrique 記錄了 prompt caching 在生產系統中可達 75-90% 的成本節省。更具體的生產實例：Claude Code 在 context 使用率達到 95% 時，會自動觸發 auto-compact summarization，這正是 Compress 策略在生產環境的現實示範。

何時用：長對話系統；成本控制是優先考量時；context window 接近上限時。

Isolate：拆分 context 環境

Isolate 策略把複雜任務分解給多個 agent 或 sandbox，每個 agent 只持有它需要的工具子集和資訊段落。

• Multi-agent 架構：不同子任務交給不同的專門 agent，避免單一 agent 的 context 過載
• 工具子集分配：每個 agent 只看到它需要的工具，防止 Context Confusion
• Context sandboxing：敏感資訊在隔離環境中處理，防止 Context Poisoning 跨 agent 傳播

Hacker News 工程師社群的建議呼應了這個策略：「複雜任務應該分多個 agent，每個 agent 持有專屬的工具子集」。

何時用：複雜多步任務；有資安隔離需求時；單一 agent 工具數量超出控制時。

---

何時 RAG 夠用？何時需要完整 Context Engineering？

這個問題是台灣 AI 工程師最常遇到的判斷困境。答案其實有清楚的判斷標準。

RAG 足夠的場景：

• 單次或少步驟的知識檢索（文件問答、語意搜尋）
• 無需跨對話記憶
• 任務邏輯線性，不需要條件分支或工具切換

需要完整 context engineering 的觸發條件：

• 出現 context poisoning（幻覺開始複利惡化）
• 工具數量超過 10 個
• 任務需要跨對話記憶
• 多步推理，agent 需要根據前一步結果決定下一步

Towards Data Science 的實驗結果提供了一個清晰的警示：naive RAG 在 800-token 預算下、多輪對話後會自動失效，而且失效是悄悄發生的，沒有明顯錯誤訊息。研究者建議的完整架構是：Hybrid Retriever（~85ms retrieval 延遲）+ Memory 層 + Compression 引擎 + Token Budget Enforcer 的四層架構。

值得注意的是，大 context window 不能取代精確的資訊選擇。研究顯示，100k+ tokens 的 context 仍然存在「lost-in-the-middle」問題——放在 context 中間的資訊注意力顯著低於兩端。更極端的案例：90 個工具的系統產生 50K+ tokens overhead（SwirlAI 2026），這個數字讓就算是 200k context window 也頓時變得擁擠。

---

工具選型：LangChain、LlamaIndex 與自製

對台灣工程師而言，「要用哪個框架」是最實際的問題。各框架在 context engineering 四策略上的支援程度有差異。

LangGraph（LangChain 生態）

LangGraph 在 Compress 和 Isolate 策略上有成熟的支援，特別適合需要快速驗證 multi-agent 模式的場景。LangChain 的官方 context engineering 研究本身就是基於 LangGraph 架構。對大多數台灣工程師而言，這是入門的最佳起點，原因是文件和社群資源最豐富，快速搭建原型的摩擦最低。

LlamaIndex

在 Select 策略（RAG pipeline）上的定制化深度優於 LangChain，特別是 hybrid search 的整合。如果核心需求是高品質的知識庫檢索，LlamaIndex 的管道設計更靈活。缺點是 agent orchestration 的支援相對薄弱，Isolate 策略的實作需要更多手工組裝。

自製系統

適合已經有穩定的 context management 需求，且需要針對特定瓶頸深度優化的團隊。從框架開始驗證模式，確定哪個策略是瓶頸後，再考慮自製這個部分。不要從零開始寫。

Context caching 與 context engineering 的關係

Claude 和 Gemini 提供的 prompt caching 功能（API 層的快取），是 Compress 策略的一個雲端實作手段，而不是獨立的技術概念。了解 context engineering 四策略框架後，你會更清楚何時要用 context caching，它解決的是 Compress 策略中「常用內容重複計算成本」的問題。

Vector DB vs Graph DB

大多數場景，vector DB（Pinecone、Weaviate、Qdrant）提供的語意相似度搜尋已足夠支撐 Select 策略。Neo4j 的 GraphRAG 適用於特定場景：當知識庫裡的資訊有複雜的關係結構（如企業知識圖譜、多跳推理），且 flat vector search 的準確率明顯不足時。

---

生產環境陷阱

Context Rot 的診斷與修復

Context rot 是長對話中脈絡品質劣化的現象。常見徵兆包括：回答開始重複早期的行為模式、工具選擇準確率下滑、前後出現矛盾性陳述。

Simon Willison 在 Hacker News 討論中分享了三個實用技巧：

1. Context quarantine：對新進入 context 的資訊先隔離，確認可靠性後才允許後續推理使用
2. Context pruning：定期清除不再相關的對話歷史段落，而不是讓所有歷史一直累積
3. Context offloading：把不需要即時訪問的資訊移到外部儲存（long-term memory），需要時再用 Select 策略取回

MCP 工具管理

MCP（Model Context Protocol）在 2025 年底由 Anthropic 捐給 Agentic AI Foundation 後，已達到 97M+ 月下載（SwirlAI 2026），成為業界標準。但管理 MCP server 本身就是 context engineering 的應用場景，常見陷阱包括：

• 工具超量：上線前先盤點工具數量，超過 10 個就需要分組或動態篩選策略
• 描述品質低落：工具描述不清楚直接影響 Select 策略的準確率
• Stale cache silent failures：MCP server 版本更新後，舊有快取可能導致模型選錯工具而沒有明顯錯誤訊息

---

台灣開發者的實作路徑

根據 SwirlAI 的建議和 Lance Martin 的研究，context engineering 的最佳入門路徑是分層實施，不要試圖一次實作全部策略。

第一層：Write + Select（今天就能開始）

建立 RAG pipeline + agent scratchpad。這是最低門檻的起點：用 LangGraph 搭建一個可以查詢知識庫的 agent，同時讓 agent 在任務中把中間步驟寫入 scratchpad。

這個組合覆蓋了 Write 和 Select 兩個策略，解決了基本的「失憶」和「知識局限」問題。davidkimai/Context-Engineering 的 GitHub 倉庫（9.1k+ stars，有 IBM Zurich 和 Princeton 研究支持）提供了可以直接 fork 的範例。

第二層：Compress（預算有限時優先）

當第一層系統開始出現 context window 接近上限、或 API 成本快速增長的問題時，加入 Compress 策略。

具體實作順序：先試 prompt caching（Claude/Gemini API 層，幾乎零實作成本）→ 再加對話歷史 summarization → 最後才考慮自訂 trimming 邏輯。

根據研究記錄，prompt caching 可以達到 75-90% 的成本節省，這個數字對台灣新創和 freelance 開發者的決策影響非常直接。

第三層：Isolate（任務複雜時才需要）

當系統需要處理多個不同領域的複雜任務，或出現工具數量超出控制的情況時，才需要引入 multi-agent isolation 架構。

實作前先確認觸發條件是否成立：工具超過 10 個且無法砍減、任務分支複雜到單一 agent 難以管理、有明確的安全隔離需求。如果這些條件都不成立，第一、二層架構可能已經夠用了。

---

結論

從「寫好 prompt」到「設計 context 架構」的轉型，是 AI 工程師在 2026 年最實際的技能升級方向。Karpathy 的定義提醒我們：context engineering 是一門藝術，也是一門科學，核心不是找到魔法 prompt，而是每次推理前把正確的資訊載入模型的工作記憶。

四種失敗模式（Poisoning、Distraction、Confusion、Clash）給了你診斷的語言；四大策略（Write、Select、Compress、Isolate）給了你設計的工具；三層漸進路徑讓你今天就能開始，而不必等到系統複雜到無法收拾。

實作起點就是 davidkimai/Context-Engineering（9.1k+ stars）和 LangGraph。不需要從頭打造一切，先驗證模式，再針對瓶頸優化。

如果你正在深入研究 AI agent 的工具層，可以搭配閱讀 LangGraph 生產環境 Agent 指南 和 最佳 MCP Server 工具指南。