一、Manus 的核心洞察：KV-Cache 命中率是唯一指標
💡 來源背景
Manus 官方博客
全球百萬用戶級 AI Agent
4 次完整框架重寫
Manus 是全球用戶量最大的 AI Agent 產品之一。經過 4 次完整的框架重寫後，他們得出了一個關鍵結論：
「KV-cache 命中率是生產環境 AI Agent 最重要的單一指標。」
以 Claude Sonnet 為例，快取命中與否有 10 倍成本差距。而 Agent 的特性是輸入遠大於輸出（輸入：輸出 ≈ 100:1），因此 prefix caching 的效益極為巨大。
🏗️ Manus 的三條鐵律
- Append-Only 架構 — 永遠只追加，不修改之前的內容。哪怕只改動一個 token，後面整段快取全部失效
- 穩定的 Prompt 前綴 — 避免時間戳等動態元素放在前面，確保系統 prompt 部分完全不變
- 確定性序列化 — JSON key 排序固定，不能有隨機性
💡 實踐啟示：每次 session 注入的 workspace context 順序應保持穩定（如 AGENTS → SOUL → USER → MEMORY），且前綴部分盡量不頻繁變動，可大幅提升快取命中率。
二、Anthropic 官方的四大策略
📝 Writing — 把資訊存到 Context Window 外面
Anthropic Engineering Blog
- 用 NOTES.md / TODO.md 追蹤進度，讓 Agent 擁有持久化的外部記憶
- 範例：Claude 玩 Pokémon 時，跨數千步精確追蹤「過去 1,234 步我一直在 Route 1 訓練」
- 核心概念：Context Window 是工作記憶，檔案系統是長期記憶
🔍 Selecting — 按需載入，不預載
- 保持輕量指標（檔案路徑、URL、query），需要時才讀取完整內容
- Progressive Disclosure — Agent 通過探索逐步發現所需 context
- 混合策略：少量關鍵資訊預載（如 CLAUDE.md），其餘用 glob/grep 按需獲取
🗜️ Compressing — 保留精華，丟棄冗餘
- 定期壓縮對話歷史為結構化摘要
- Tool Result Clearing — 工具輸出用完就清，這是最安全的壓縮方式
- 調優原則：先最大化 recall（確保不丟重要資訊），再優化 precision（去除多餘）
🔀 Isolating — Sub-agent 各管各的
- 主 Agent 統籌全局，Sub-agent 在獨立 context window 裡執行具體任務
- Sub-agent 可能用了幾萬 token 做分析，但只回傳 1,000-2,000 token 的精煉結果
- 在複雜研究任務上，比單 agent 有顯著品質提升
💡 四維框架精髓：Write（寫出去持久化）→ Select（按需拉進來）→ Compress（壓縮保精華）→ Isolate（隔離降耦合）。這四個維度構成了完整的 context 管理策略。
三、SkillReducer 論文：量化證明「少即是多」
📄 論文背景
arXiv 2603.29919
2026 年 3 月發表
這篇學術論文直接研究了「Skill 檔案的 token 浪費」問題 — 當 AI Agent 載入過多指令和範例時，會發生什麼？
38.5%
核心可執行規則
佔 Skill 檔案比例
75%
Token 節省幅度
（359K → 84K）
25.3%
壓縮後品質提升
（Less-is-More 效應）
🔑 最反直覺的發現
- 壓縮後 86% 的 Skills 品質持平或更好
- 25.3% 品質明顯提升 — 這就是 Less-is-More 效應
- 只有 4.7% 是真正的壓縮損失
- Description 壓縮 48%（中位數 59%）
- Body 內容壓縮 39%（每個 Skill 省約 1,000 tokens）
🛠️ 方法論（兩階段）
- Stage 1：用 delta debugging 找出最小充分的路由描述 — 刪到不能再刪
- Stage 2：把內容分為「核心規則（永遠載入）」和「補充模組（按需讀取）」
💡 實踐啟示：大型 Agent 配置檔（如 3000+ 字的系統指令）中，大約只有 40% 是核心規則，其餘 60% 可以改為按需載入。純敘述式改成結構化格式，就能再省 30% tokens。
四、Google ADK 的「Scope by Default」原則
🌐 設計哲學
Google Developers Blog
Agent Development Kit
Multi-Agent Framework
「每次 model 調用和 sub-agent，只看到最小必要 context。Agent 必須主動伸手去拿更多資訊。」
📋 四大具體做法
- Artifacts 用 Handle 模式 — 大檔案（CSV、PDF）預設只放輕量引用，Agent 需要時才用 LoadArtifactsTool 載入，用完就卸載
- Context Caching 分層 — 穩定前綴（系統指令、身份）vs 可變後綴（最近對話、工具輸出），充分利用 prefix caching
- Scoped Handoffs — 交接任務時可選 include_contents: none，只傳必要指令，不帶歷史包袱
- Memory 是搜索式的 — 不是永遠釘在 context 裡，而是用相似度搜索按需注入
🧠 記憶的兩種觸發模式
- 被動回憶（Reactive）：Agent 意識到需要知識時，主動呼叫 load_memory_tool
- 主動回憶（Proactive）：系統對用戶輸入做相似度搜索，自動注入相關片段
💡 實踐啟示：MEMORY.md 這類長期記憶不應整個釘死在 context 中。更好的做法是只放一行索引，搭配 memory_search + memory_get 按需獲取，頻道 ID 表、專案索引等靜態資料移到可搜索檔案。
五、Claude Code 的壓縮機制與 80/20 法則
📐 核心原則
ClaudeFast Code Kit
SFEIR Institute 分析
Context 不是倉庫，是工作記憶。填到最後 20% 時，複雜任務的品質會明顯下降。
30%
結構化 Prompt
比敘述式省 tokens
3×
多 Session 架構
180K → 3×40K
🔧 具體實踐
- 結構化 vs 敘述式：結構化 Prompt（列表 + 直接指令）比敘述式省 30% tokens（450 → 280 tokens），且壓縮後保真度從 71% 提升到 92%
- 多 Session 架構：一個 180K token 的飽和 session 改為 3 個 40K 的目標 session，並行工作
- Session Memory 機制：壓縮時產生的摘要持久化存儲，下次壓縮不需重新摘要，直接增量更新
六、綜合結論：五大優先級行動方案
綜合以上五大來源的最佳實踐，我們將 Context Engineering 的優化策略歸納為五個優先級：
| 優先級 |
策略 |
來源 |
預期效果 |
| P0 |
KV-Cache 友好架構
確保 system prompt 前綴穩定不變，context 追加不修改（append-only） |
Manus |
10x 成本差距
ROI 最高 |
| P1 |
Progressive Disclosure
把 workspace context 拆分為「核心」(38%) +「補充」(62%)，核心永遠載入，補充按需拉取 |
SkillReducer
Anthropic |
Token 減少 40-75% |
| P2 |
Memory 從「釘死」改「搜索」
長期記憶不全文注入，改用相似度搜索按需獲取 |
Google ADK |
Context 空間釋放
精準度提升 |
| P3 |
Sub-agent Context 隔離
Sub-agent 只帶最小必要 context，回傳 1-2K 精煉結果 |
Anthropic
Google |
品質提升
上下文不互相污染 |
| P4 |
結構化 Prompt 改造
從敘述式改成結構化格式（列表 + 直接指令） |
Claude Code |
省 30% tokens
壓縮保真 71%→92% |
🎯 核心理念：Context Engineering 不是「把所有資訊塞進去」，而是「在正確的時間，以最小的成本，提供最相關的上下文」。這些不是理論空想 — 是有百萬用戶級產品（Manus）、學術論文（SkillReducer）、和平台官方（Anthropic、Google）背書的實踐。