微軟把 Context Engineering 升格為單獨一課：4 種 context failure 跟一個成本悖論（拆解微軟官方 L12 / L13）
微軟在 AI Agents for Beginners 第 12 課直接把「Context Engineering」立成獨立章節——這件事本身就是訊號：context 管理已經從「prompt engineering 的延伸」升格成跟記憶、規劃、工具並列的核心 agent 能力。這篇拆解第 12 + 13 課，重點放在 4 種 context failure 的緩解、Mem0 / Cognee / Azure AI Search 的記憶層選型、以及微軟版本沒明說的 4 個 trade-off。
為什麼這課要叫「Context Engineering」，不是「Prompt Engineering Pro」
微軟給的定義很乾淨：Prompt engineering 是「設計一組 static instructions 來引導 agent」；Context engineering 是「管理一組 dynamic information 確保 agent 在時間軸上一直拿到它需要的東西」。前者寫一次就定型，後者要持續調整。這個區分聽起來簡單，但實務上對組織能力的要求差距很大——prompt engineering 可以一個 prompt engineer 搞定，context engineering 需要設計 pipeline、定 trigger、管 lifecycle。
更值得停下來看的是 context 的 5 種來源分類：Instructions（prompt + 工具描述）、Knowledge（事實 + RAG + 記憶）、Tools（function / API / MCP server 定義）、Conversation History（對話歷史）、User Preferences（用戶偏好）。這 5 類進 context window 的節奏不同——Instructions 是 setup 階段一次性、Tools 是當下 call 之前 dynamic、Conversation History 是累積式、User Preferences 是跨 session 拉進來。分類做好，後面的「什麼進、何時進、怎麼組織」才有結構去回答。
6 個實務管理策略（Lesson 12 全覽）
微軟列了 6 個 practical strategy，這 6 個的順序值得注意——從輕量到重型：
- Agent Scratchpad：在 context window 之外的檔案 / runtime object 存當下 session 的筆記、需要時再讀回來。輕量、適合單 session。
- Memories：跨 session 的儲存。比 scratchpad 重一層、要管 lifecycle。
- Compressing Context：context 接近上限時用 summarization 或 trimming 壓縮。中等成本（每次壓縮要呼 LLM）。
- Multi-Agent Systems：每個 agent 自己一個 context window、用分散來避免單窗爆掉。重型、跨 agent state 同步成本高。
- Sandbox Environments：跑 code 或處理大量資料時開 sandbox、只把結果讀回 context、不把全部 raw data 塞進 context。
- Runtime State Objects：複雜任務用 container 儲存每個 subtask 結果、context 只連到當前 subtask、結束就釋放。
這個列表的隱含順序：先用最輕的（scratchpad、compression）能解就解；解不掉再升到 multi-agent / sandbox / state object。直覺常顛倒——看到複雜任務就想用 multi-agent，結果是用大砲打蚊子。多數 agent 用 scratchpad + compression 已經夠。
4 種 Context Failure 跟緩解
這節是第 12 課最具體的價值。微軟列了 4 種 context failure、每個都帶 Travel Booking 案例：
Failure 1：Context Poisoning — 成本悖論
什麼是：LLM 生了一個 hallucination（例如「某小型機場有直飛巴黎」實際沒有），這條假資訊進了 context、後續一直被引用、agent 一直嘗試訂這條不存在的航線。
官方緩解：在資訊進長期記憶之前做 validation；偵測到污染就 quarantine、開新 context thread。
沒明說的 trade-off：Validation 本身的成本——驗證一個 flight 存不存在要呼 real-time API 或 LLM call，每筆都驗會很貴。實務上需要分層：高代價動作（不可逆訂票、付款）前必驗；低代價建議（草擬行程）可以延後到 commit 階段才驗。微軟給了原則、沒給「何時驗」的判斷準則——這條判斷在每個應用都不同、必須自己設計。
Failure 2：Context Distraction — 取捨無通用法則
什麼是：context 太長、模型開始過度關注累積的歷史、忽略訓練時學的能力。可能 context window 還沒滿就開始出錯。Travel 案例：你聊了 2 年前背包客旅遊細節聊很久、然後問「找下個月便宜機票」、agent 卻一直回去問你「你的登山裝備需求」、忘了當前請求。
官方緩解：定期 summarization 把舊歷史壓成摘要、保留重點、丟掉細節。
沒明說的 trade-off：summarization 是有損壓縮——什麼算重點、什麼算可丟，沒通用法則。Travel 案例裡「2 年前的背包客細節」要丟，但那位用戶可能下次真的想規劃一趟背包客旅行——丟太多會讓 personalization 失去深度。Distraction vs learning（從歷史中學偏好）是一條真實的張力、不是純技術問題。實務上要分「臨時 context」（可激進壓縮）vs「persistent memory」（保守更新）兩層管理。
Failure 3：Context Confusion — Tool Loadout RAG 的循環風險
什麼是：agent 有太多 tool 可用、模型在選擇時混淆、call 了不相干的 tool。小模型特別嚴重。Travel 案例：你問「在巴黎怎麼移動」、agent 卻 call book_flight（誤以為要訂飛機到巴黎內部）。
官方緩解：用 RAG 做 tool loadout 管理——tool 描述存 vector database、根據當前 query 動態選相關 tool。微軟提到研究建議 tool 數量限制在 30 以下。
沒明說的 trade-off：tool loadout RAG 本身會 hallucinate——vector similarity 抓出來的 tool 不一定真的最相關。極端例子：用戶問「在巴黎怎麼移動」、tool RAG 抓出 rent_car 跟 book_flight（因為 description 都含「Paris」「travel」這類詞）、漏掉真正該抓的 public_transport_info。用 RAG 解決 confusion 等於把問題從「LLM 選 tool」轉移到「RAG 選 tool」——問題沒消失、只是換層。所以微軟「30 以下」這個數字是因為 RAG 也不可靠才硬性限制 tool 總數，不是 RAG 解決了一切。
Failure 4：Context Clash — Pruning vs Scratchpad 的取捨
什麼是：context 內有衝突資訊（例如先說「我要 economy class」、後來說「這趟改 business」）、agent 拿到衝突搜尋結果、不知道該優先哪個。
官方緩解：用 context pruning（新指令進來、舊指令明確移除）或 offload 到 scratchpad（先在 scratchpad 對齊衝突、再寫回 main context）。
沒明說的 trade-off：Pruning 簡單、但會吃掉「對話脈絡」——用戶可能想看 agent 知道我之前說 economy class、現
Lesson 13 — 7 種記憶型態 + 3 種儲存方案
第 13 課把 memory 拆得很細：Working / Short Term / Long Term / Persona / Workflow-Episodic / Entity / Structured RAG 7 種。實務上不必每種都實作、但要知道記憶不是單一一坨——「跨 session 留下用戶偏好」（Long Term）跟「保留這次任務的步驟序列」（Episodic）是不同需求、要分開設計。
3 種儲存方案的選型：
- Mem0：兩階段管道（extraction + update）。先用 LLM 從對話摘要、提取新記憶；再用 LLM 決定是「add / modify / delete」既有記憶。儲存層是 hybrid（vector + graph + key-value）。這個架構的關鍵是 update 包含 delete——許多自製 memory 系統只做 add、不做 delete、結果 memory 累積到無法使用。Mem0 把「決定該不該刪」也外包給 LLM。
- Cognee：dual-store（vector + graph）+ hybrid retrieval。優勢是「不只記相似度、也記實體間關係」——適合需要理解「為什麼這兩件事相關」的場景。代價是建置 + 維護 graph 比純 vector 重。
- Azure AI Search 做 Structured RAG：適合企業資料量大、需要高 precision/recall 的場景。微軟說 Structured RAG 比傳統 chunk + embed 「superhuman precision and recall」，但要先把資料整成 structured 形式（不是丟一坨文件就能用）。
選型判斷：個人化偏好為主 → Mem0；需要實體關係推理 → Cognee；企業級結構化資料 → Azure AI Search。不是哪個比較強、是適用場景不同。
Knowledge Agent — 自我改進的標準模式
第 13 課介紹的「knowledge agent」pattern 值得記住：用一個獨立的 agent 觀察主對話、決定哪些值得記、提取摘要、存進 knowledge base、下次用戶查詢時 retrieve 回來補充 context。
這個 pattern 的核心是「決定要記什麼」跟「執行對話」分到兩個 agent——主 agent 專心服務用戶、knowledge agent 專心做記憶 curation。微軟提到的優化：knowledge agent 可以用更便宜的快模型先做 triage、判斷「值不值得進一步處理」、只有 trigger 才呼貴模型。這條優化對成本影響很大。
我的觀察 — 微軟版本沒明說的 4 個 trade-off
Trade-off 1：Context engineering 是 ops 能力、不是 prompt 能力
第 12 課全文重點在「策略」、但實務上 context engineering 跑得好不好主要看 ops 能力——summarization trigger 怎麼定、memory delete policy 怎麼寫、tool loadout 怎麼版本管理。這些都不是寫 prompt 解決、是寫 pipeline 解決。團隊如果只有 prompt engineer 沒有 platform engineer、context engineering 會卡在「設計很好、跑不起來」。
Trade-off 2：四種 failure 緩解都把成本往別處推
Poisoning → validation 多花 API call；Distraction → summarization 多花 LLM call；Confusion → tool loadout RAG 多花 vector query；Clash → scratchpad 多一層運算。沒有免費的 context 管理——每個緩解都把成本從 token 推到 latency 或推到外部呼叫。設計時要把這個成本也算進去、不是「加緩解就好」。
Trade-off 3：記憶層的「該不該記」比「怎麼記」難
Mem0 把這個外包給 LLM、Cognee 用結構提示、Azure AI Search 用 schema 強制——3 種都是不解決問題、轉移問題。最後還是要在某個地方寫「這類資訊值得記、那類不該記」的 policy。policy 寫不好、記再多也只是噪音。實務上多數團隊低估這條的工程量。
Trade-off 4：Multi-agent 是 context 隔離手段、不是萬靈丹
Lesson 12 把 multi-agent 列為 6 個 context 管理策略之一，這個 framing 很重要——multi-agent 的價值不只是「分工」、也是「context 隔離」（每個 agent 自己一個 window、不互相污染）。但 multi-agent 帶來 coordination overhead、agent 間 state 同步本身也是 context engineering 問題。把 multi-agent 當解藥要小心：它解了 context 大小問題、引入 context 分散問題。我自己在實作多 AI 工具協作時走過這條路、最後採用的設計是「不共享 conversation context、共享資料走檔案系統、人在中間做橋接」——核心就是把 context 隔離當顯性設計、不假設 agent 之間「無縫」是好事。
常見問題
Context engineering 跟 RAG 是同一件事嗎？
不是。RAG 是「從外部知識庫拉資料進 context」的一種技術；context engineering 是整體管理 context 進出的學問——包含 RAG、prompt 設計、memory、tool loadout、compression、conversation history 管理等等。RAG 是 context engineering 的工具之一、不是全部。第 12 課的 5 種 context type 裡，Knowledge 那類才主要用 RAG，其他 4 類各有自己的管理策略。
沒有 Azure 訂閱也能做 context engineering 嗎？
完全可以。Context engineering 的核心是設計判斷、不綁特定平台。Mem0 是獨立開源工具、Cognee 是獨立開源、Agent scratchpad / Runtime state object 是設計 pattern 不需要任何 service。Azure AI Search 只在「需要企業級 structured RAG」場景才必要。多數團隊起手用 Mem0 或自製 sqlite-based scratchpad 就能跑很遠。
「該不該記」的 policy 怎麼設計？
實務上分 3 層：(1) 必記——用戶明確說的 preference（「我吃素」「不喜歡早班機」）；(2) 條件記——agent 推得的偏好（「這次選 business、可能是商務出差不是個人偏好」）需要二次確認或標記低信心；(3) 不記——一次性 context（這次行程的特殊需求、出差後就過期）。Mem0 的 LLM-driven update 可以幫忙判斷、但 policy 提示要明確、否則 LLM 會亂判。
原文出處：Microsoft AI Agents for Beginners — Lesson 12 Context Engineering、Lesson 13 Agent Memory
延伸閱讀：本站既有文章 為什麼我故意讓兩個 AI 工具不知道彼此存在 — 多工具協作的 Context 隔離原則（2026-05-10 gwarket 改版實戰、四工具協作 context 隔離三要件）
