看到 Jason Liu 寫了一個 Context Engineering 系列，一共五篇，覺得蠻有料的。Jason Liu 是 AI 顧問，長期幫企業建 agentic RAG 系統，也從 Claude Code、Cursor、Devin 這些 coding agent 中汲取了不少實戰經驗。

這系列的核心觀點是: 我們已經遠遠超越了 prompt engineering 的階段。現在要設計的是一整套工具回應、互動模式和資訊流架構，讓 agent 具備「情境感知」能力，能在複雜的資訊空間中有效導航。

以下是五篇的重點摘要:

1. 工具輸出設計 (Tool Response)

📎 Beyond Chunks: Why Context Engineering is the Future of RAG

這篇是系列起點，也是最容易馬上動手改善的地方。核心觀點:

🔹 Context Offloading 策略: 傳統 RAG 回傳 chunk 就結束了，但在 agentic 系統裡，你應該先回傳 snippet 摘要，讓模型自己判斷是否需要 load full page。就像先給目錄，再決定要不要翻開整章。一個簡單的 load_pages() 函數就能大幅提升 agent 的推理品質。

🔹 工具輸出本身就是 prompt engineering: 你可以直接在工具回應裡塞 instruction，用 XML 結構包裝結果、加上 metadata 和系統指示，來引導 agent 下一步的行為。工具的命名、參數設計、回傳格式都會直接影響 agent 的推理模式。

🔹 Faceted Search 提供「周邊視野」: 工具輸出除了 chunk 本身，還要包括 metadata (來源、日期、分類、計數等)。這些 facets 讓 agent 看到整個資料地景，能引導它探索多元路徑，而不是只盯著 top-k 結果。

🔹 他提出四個層級的演進: 最基本的 chunk → 帶 metadata 的 chunk → 多模態內容 → facets 加上查詢精煉。每一層都讓 agent 更聰明地使用工具。

2. Subagent 架構

📎 Slash Commands vs Subagents: How to Keep AI Tools Focused

這篇講的是 context pollution 的問題，用 Claude Code 做了很直觀的對比:

🔹 Subagent 是什麼: 具有自己指示、工具與記憶的獨立 AI 助手。每個 worker 在隔離環境中執行雜亂的工作 (跑測試、讀 log、查 git history)，然後只帶回精煉後的重要結果。

🔹 為什麼需要隔離: 如果把測試結果直接倒進主對話，你原本乾淨的 5,000 token 計畫會被 150,000 token 的 log 淹沒，91% 都是垃圾。用 subagent 處理，同樣的工作只需 21,000 token，76% 是有用資訊——效率差 8 倍。

🔹 讀寫分離原則: 讀取操作 (搜尋、查資料、分析) 可以大規模平行，多個 subagent 同時跑沒問題。但寫入操作 (改檔案、更新狀態) 需要單線程，避免衝突。

🔹 關鍵判斷: subagent 應該處理定義良好的任務然後回傳結果，而不是嘗試持續協作。想成是派一個人去辦事再回來報告，不是拉一個人進會議室一起開會。

3. Compaction 壓縮策略

📎 Two Experiments We Need to Run on AI Agent Compaction

這篇比較理論，但觀點很有意思:

🔹 壓縮不只是存事實，而是保存「學習軌跡」: 他用了一個很好的類比——如果 in-context learning 是梯度下降，那 compaction 就是 momentum。當你壓縮「我試了 X 失敗了，然後 Y 成功了因為 Z」，你保存的是通往成功的優化路徑，不只是最終答案。

🔹 壓縮時機很重要: 在任務完成 50% vs 75% 做壓縮，效果可能差很多。太早壓縮可能丟失關鍵的學習脈絡，太晚又可能 context window 已經爆了。

🔹 需要實驗你的壓縮模式: 不同的壓縮 prompt 可以用來做不同分析——偵測失敗模式、分析語言切換、聚類使用者回饋。哪些對話軌跡能保留學習成果、哪些會造成維護負擔，這些都需要實驗才知道。

🔹 他提了一個有趣的想法: 用專門的 compaction prompt 來做 trajectory observability，類似 Anthropic 的 Clio 研究，但專門分析 agent 行為而不是聊天對話。

4. Agent Framework 與形式

📎 Context Engineering: Agent Frameworks and Form Factors

這篇比較偏策略面，幫你釐清到底該建什麼:

🔹 三種形式選一個再開始: Chatbot (對話介面)、Workflow (事件驅動的自動化)、Report (產出結構化文件)。不要把該做 workflow 的東西硬塞進 chatbot，也不要讓報告生成器變成對話式的。

🔹 何時用 MCP: 如果你的工具需要跨多個 AI 平台使用 (Claude Desktop、ChatGPT 等)，MCP 值得投資。但如果只服務單一應用，直接 API 呼叫加上 OpenAI SDK 更快。決策因素: 客戶端多樣性、團隊是否已有 MCP 基礎設施、工具複雜度、人力分配。

🔹 自主性層級: 從完全確定性的 if/else (Step 0) → 單次 AI 函數呼叫 (Step 1) → prompt chain (Step 2) → graph state machine (Step 3) → tool-calling loop (Step 4)。不是所有東西都需要做到 Step 4，很多時候 Step 1 或 2 就夠了。

5. 用 Claude Code 做 Agent PoC

📎 Context Engineering: Rapid Agent Prototyping

這篇非常實用:

🔹 問題: 大多數團隊花好幾個月建 agent framework，結果才發現核心想法根本不 work。應該先驗證再建基礎設施。

🔹 方法: 用 Claude Code 的 claude -p 模式，把任何目錄變成 agent 執行環境。寫一個 CLAUDE.md 當 system prompt，把工具包成 CLI 指令，讓 Claude Code 處理執行迴圈。結構就是: CLAUDE.md + tools/ + tests/scenarios/。

🔹 核心洞見: 如果 Claude Code 在具備完美工具存取且沒有限制的情況下都無法讓系統運作，你的正式版本很可能也無法。反過來說，如果在這個 harness 裡成功一次，這個想法就是可行的。

🔹 這個方法還可以跨 agent 做評測——同樣的 tools/ 和 tests/，換不同的 coding agent 來跑，比較 pass rate、時間和成本。

以上，這系列從工具輸出設計、subagent 架構、壓縮策略、框架選擇到快速原型驗證，基本上涵蓋了建 agentic RAG 系統的關鍵決策點。特別推薦第一篇 (工具輸出) 和第二篇 (subagent)，這兩個是最容易馬上拿去改善現有系統的。