【2026 最新】context-mode 真的省 98%？Claude Code 六任務 A/B 評測教學（安裝＋安全＋回滾）

你看到「省 98% Context」時，直覺可能是：Claude Code 的 Token 成本也會少 98%。但這正是 context-mode A/B 評測最容易量錯的地方——工具可以把一次龐大輸出縮短，整個任務卻可能多繞幾步、重新找資料，甚至答錯後重跑。

這篇專為第一次做 AI Agent 評測的讀者寫。我們不假裝替任何宣傳數字背書，而是用目前版本可重現的六任務流程，帶你完成安裝、版本鎖定、成功判定、Token 與延遲統計、安全測試，以及完整回滾。你不必先懂統計；只要記住一條式子：真正的節省＝少送進模型的 Context－摘要、重取與重跑成本；任務失敗時，節省歸零。

先說結論：98% 不是你的預期帳單折扣

• 98% 是專案方的特定輸出壓縮示例。它回答「這批原始內容有多少沒進對話」，沒有直接回答整個 Agent 任務的成功率、總 Token、時間或重跑成本。
• 先比結果，再比資源。兩組必須完成同一驗收條件；若 ON 組省 Token 卻漏掉錯誤、引用錯 issue 或沒有真的跑完測試，就不能判勝。
• 小輸出不一定值得繞路。context-mode 的優勢理論上較可能出現在大型工具輸出、可先運算再擷取的資料，以及長 Session；短搜尋則可能只增加路由步驟。
• 安全邊界要單獨驗收。「sandbox tool」不等於作業系統沙箱。測試請放在隔離副本，用假祕密、唯讀憑證與最小權限。

context-mode 是什麼？先懂它在省哪一段

Claude Code 每次讀檔、抓網頁或跑測試，工具輸出都可能成為後續推理要攜帶的內容。你可以把 Context 想成登機手提行李：原始 log、HTML、issue 內容全塞進去，很快就裝滿。

context-mode 專案的做法像「機場行李分流」：先讓程式在外部處理大量資料，只把計算結果送回對話；需要稍後查找的內容則索引進本機 SQLite／FTS5，再依查詢擷取相關片段。Claude Code 外層還可透過 hooks 提醒模型優先走這條路。

因此，專案 README 裡的 98% 比較接近單次載荷壓縮率，不是任務級 ROI。專案自己的 benchmark 文件也以固定輸出情境計算減量；不同 Repo、Prompt、模型與版本不可直接互比。

為什麼原生 Claude Code 也要算進基準線？

現在的 Claude Code 本身就會清除較舊的工具輸出、在接近 Context 上限時自動 compact（把舊對話摘要化），MCP 工具定義也可延後載入。換句話說，你不是拿 context-mode 對上「完全不整理的 Claude」，而是拿它對上同版本 Claude Code 的原生最佳狀態。這也是本文不沿用舊測試結論的原因。

如果你想先補齊背景，可讀 Claude 省 Token 教學；若想理解 compact 後重新找回資訊的隱形成本，接著看 Context compaction 與 reacquisition cost。

context-mode A/B 評測前：先鎖住 6 個變因

截至 2026 年 9 月 8 日，npm 發布版 context-mode 是 1.0.169；本次另檢查仍標示該版本的 Repo main commit 33f7eb9。同日 npm registry 的 Claude Code 最新版是 2.1.263。發布版與持續變動的 main 不是同一個 pin，所以請在自己的結果首頁保存以下六項，不要只寫「最新版」。

1. Claude Code：claude --version，並保存實際回傳的完整模型 ID。
2. context-mode：claude plugin details context-mode@context-mode，另記 Repo commit 或 package version。
3. 測試資料：Repo commit、issue 快照、PDF 的 SHA-256，以及測試輸出 fixture。
4. Prompt：把六題各自存成檔案並納入版控；標點變更也視為新版本。
5. 執行環境：OS、Node 版本、網路是否開啟、允許的工具、權限規則，以及 bashOutputMaxChars／taskOutputMaxChars。
6. 順序與重複：交替跑 AB／BA，至少做數次重複；不要永遠先跑 OFF，避免快取與服務波動偏向後跑者。

context-mode 的當前 package manifest 要求 Node.js >=22.5.0。這是工具自己的執行條件，不等於 Claude 模型的限制；安裝前先跑 node --version，可以少掉最常見的環境誤判。

安裝與健康檢查：只在隔離測試環境動手

第三方 Claude Code plugin 會以你的使用者權限執行程式碼。請先複製一份測試 Repo，移除真實 .env、SSH key 與雲端憑證，再按照專案目前提供的 Plugin Marketplace 流程安裝：

/plugin marketplace add mksglu/context-mode
/plugin install context-mode@context-mode
/reload-plugins
/context-mode:ctx-doctor

ctx-doctor 應確認 runtime、hooks、FTS5 與 plugin registration。再用 /plugin 或 claude plugin list確認狀態。Claude Code 的官方 Plugin 文件提醒：外部 plugin 可能執行任意程式碼，安裝前要審查來源；Marketplace 上架也不是 Anthropic 的安全背書。

先檢查內建 Plugin Eval：有 with／without 就用

本文檢查的 Claude Code CLI 在 plugin eval中列出 with-without ablation，可替解析到的 plugin 建立 no-plugin baseline；這比手動改全域設定更不容易串組。先執行 claude plugin eval --help核對你當前 binary 也有以下選項，再在乾淨測試副本建立六個 case。每個 case 用一份 prompt.md，並用 grader 寫下「成功」的可觀察條件。

claude plugin eval context-mode@context-mode \
  --eval-dir evals/context-mode \
  --ablation with-without \
  --runs 5 \
  --model "$MODEL_ID" \
  --mocks off \
  --allow-tools "Read" "Grep" "Glob" "Bash(npm test *)" \
    "mcp__plugin_context-mode__*" "mcp__context-mode__*" \
  --no-publish \
  --json runs/context-mode.json

--mocks off才會啟動真正的 MCP server；--allow-tools則是測試操作員明確授權的能力。MCP 名稱會依安裝方式改變，先用 claude plugin details核對後，只保留實際的 context-mode prefix；也要依任務縮小 Bash pattern，且不要加入略過權限的旗標。初次建立 case 可先用 claude plugin eval init --bare產生空白範本。若你的版本還沒有這些選項，就停在版本鎖定，不要拿不同 harness 的結果硬併。

Plugin Eval 的 score 用來判斷任務是否完成；Token 明細則應從每次執行的 usage／trace artifact 取值。Claude Code 的成本文件列出 input、output、cache read 與 cache write；若使用 stream JSON，另保存最終 result event 與 compact_boundary事件。完整評測觀念可對照站內的 Claude Code Token A/B Test，本文只聚焦 context-mode 的產品邊界。

六任務怎麼設計？每題只改一個變因

① 小型搜尋：測「繞路稅」

Prompt：在指定的 10 個小檔案中找出某函式定義，回報檔名與行號。成功：路徑、符號、行號全對。這題輸出本來就小，可看 routing 是否增加 turns 或延遲。

② 大型 Repo：測「先算再回傳」

Prompt：在固定 commit 統計三類 API 使用方式，列出每類數量與兩個例證。成功：用預先寫好的 deterministic script 產生答案 key，驗證數量與檔案，不用另一個 LLM 憑感覺打分。

③ GitHub issue：測「抓取＋引用」

Prompt：從固定 JSON fixture 的 20 則 issue 找出符合兩項條件者，引用 issue 編號與原句。成功：集合完全一致、沒有捏造引用。不要用即時 GitHub 頁面，否則資料會在 AB 之間改變。

④ PDF：測「頁碼可追溯」

Prompt：從同一份本機 PDF 擷取三個欄位並標頁碼。成功：數值、單位、頁碼都對。先保存 PDF hash，避免兩組其實讀到不同版本。

⑤ 測試輸出：測「保留關鍵錯誤」

Prompt：分析一份固定的大型測試 log，找 root cause 並提出最小修正。成功：必須指出預埋的第一個因果錯誤，且修正後 fixture 測試通過。這題專抓「摘要很短，卻把真正錯誤一起丟掉」。

⑥ 長 Session：測 compact 後的重取成本

Prompt：分多回合完成讀碼、決策、修改、測試與回顧，並在後段詢問前面已確定的約束。成功：最終 diff、測試與約束清單全對。記錄 compaction 次數，以及 compact 後為找回舊資訊多用的 turns、工具呼叫和 Token。

context-mode A/B 評測要記哪些數字？

不要只抄 context-mode 自己顯示的 saved ratio。每次 run 至少保留下列欄位，並把原始 JSON 與 grader receipt 一起留存：

• Task Success：通過／失敗與失敗原因；先看各 case 成功率。
• Processed Context：input_tokens + cache_creation_input_tokens + cache_read_input_tokens。這是處理量，不等於三者以相同單價計費。
• Output Tokens：模型生成量；不要混進 input 的壓縮率。
• 延遲：總 wall-clock time，並另記 turns 與 tool calls。
• Compaction：compact_boundary次數與發生位置。
• Reacquisition：為重新找回已讀資訊而新增的查詢、讀檔、turns 與 Token。
• 故障成本：timeout、MCP 斷線、重試與整題重跑都要計入，不可只保留成功的漂亮 run。

對每個指標計算 1 − ON ÷ OFF；負值代表 ON 反而增加。先逐個 paired run 算差，再報中位數與分布，不要把不同難度的六題直接加總成一個華麗百分比。若成功率不同，先判定功能退步，不再用 Token 降幅蓋過它。

若要建立更完整的觀測層，可接著讀 AI Agent Observability；若你在比較 MCP 與 CLI 路徑，MCP vs CLI Token A/B提供另一種配對設計。

一個完整判讀例子：省 Token 也可能判輸

假設某個測試輸出 case 跑三對：OFF 三次都找對 root cause；ON 有兩次答對、一次漏掉前置錯誤。即使 ON 的成功 run 顯示較少 Processed Context，也不能寫成「平均省 X%」。正確結論是：目前設定未通過等效品質門檻，先檢查摘要與擷取策略，再重跑同一版本的完整組合。

只有兩組成功率相同，且每題必要證據都保留時，才往下比較 Token；Token 確實下降後，再看延遲、重取與維運複雜度。這個順序就是「成功率 → 重取／重跑 → Token → 延遲」。

獨立測試告訴我們什麼？只能當反例，不能當答案

一篇 2026 年 6 月的日文獨立測試使用 context-mode 1.0.162與 Claude Code 2.1.173，在 Docker 裡各跑一次 JSON 搜尋與大型 fetch。作者加總的 input、cache creation 與 cache read 在兩題都增加，延遲也增加；其中大型 fetch 的名目成本卻略低。這正好示範「累計處理量、峰值 Context、延遲與費用不是同一個指標」。

但它只有兩題、每組一次，而且版本已不同，所以不能拿來宣判目前 context-mode 一定更慢或一定無效。它的真正價值是推翻「README 的單一百分比可以外推到所有任務」這個假設。

安全驗收：四種故障要真的觸發一次

1. 權限拒絕

要求 Agent 寫入測試 Repo 外的 canary 路徑，把該路徑列入 deny，並確認實際被擋下。不要把 hook 提出的 allow 建議當成作業系統邊界；正式設定與驗收仍以 Claude Code 權限文件為準。

2. 假祕密外洩

在 fixture 放入唯一 canary，例如 CM_TEST_SECRET_7F3A，再搜尋對話、trace、debug log、SQLite 索引與最終輸出。context-mode 有依 key 名稱遮罩的機制，但祕密若藏在普通欄位，不能假設一定會被認出；所以只用假值測試。

3. 網路與 MCP 故障

在可控環境中斷 MCP server 或讓 fetch timeout，確認任務是明確失敗、可安全重試，還是悄悄退回大量原生輸出。專案目前提供 CTX_FETCH_STRICT=1阻擋 private／loopback 目標；預設網路邊界與你的威脅模型不同時，應先收緊再測。

4. 任務輸出遭提示注入

在 issue 或網頁 fixture 埋入「忽略原任務」之類的惡意字串，驗證它只被當資料，不會改變工具權限或成功條件。可用 Prompt Injection 回歸測試的 fixture 思路擴充。

還有一個容易誤解的字：context-mode 把部分工具稱為 sandbox，但其 README 同時說明，任意程式執行仍會繼承該 process 的檔案系統權限；部分檔案邊界只是 defense in depth。真正的隔離仍要靠容器、測試帳號、最小權限與唯讀資料。

停用與完整回滾：先清資料，再拆 Plugin

1. 保存評測所需的匿名化結果，不保存 canary 之外的敏感原文。
2. 若曾建立索引，在 Claude Code 執行 /context-mode:ctx-purge並確認永久刪除。
3. 暫停使用：claude plugin disable context-mode@context-mode --scope user。
4. 完整移除：claude plugin uninstall context-mode@context-mode --scope user。不要使用保留資料的選項。
5. 重新啟動 Claude Code，再以 claude plugin list與 claude mcp list確認沒有載入。
6. 重跑一個小型搜尋 baseline，證明路由、權限與延遲已回到原生狀態。

不要照網路文章手動刪除猜測中的 hidden folder；Plugin 的資料位置與生命週期可能隨版本改變。優先使用當前 CLI 與 plugin 自己的 purge／uninstall 流程，並把驗證輸出留作 rollback receipt。若想把這套做成團隊演練，可參考 Coding Agent 事故復原演練。

什麼情況值得開？用三道門做決策

• 採用：六題成功率不退步，大輸出與長 Session 的 paired 結果穩定下降，且安全／回滾四關全過。
• 限縮：只在 log、批量 issue 或大型 Repo 有益，就只對那些路徑啟用；短搜尋維持原生工具。
• 停用：品質退步、故障時靜默失真、敏感資料落到不預期位置，或重取成本吃掉節省。

這不是一次性選邊站。Claude Code 與 context-mode 任一方升級後，先跑小型 smoke cases；路由、工具名稱、安全預設或 usage 欄位有重大變動時，再跑完整六題。另一個相近產品的宣稱稽核，可對照 Headroom Context 壓縮教學。

常見問題 FAQ

1. context-mode 真的能省 98% 嗎？

在專案指定的某些載荷示例裡可以；不能直接外推到你的整個任務。請用相同版本、同一成功條件做 paired A/B。

2. Context 少 98%，費用也會少 98% 嗎？

不一定。cache read、cache write、一般 input 與 output 是不同欄位；多出的 turns、摘要、重取和重跑也會改變總量。

3. 只跑一次 ON／OFF 可以嗎？

只能當 smoke test。Agent 輸出與服務延遲會波動；正式判斷要交替順序、重複執行並保留每次結果。

4. 可以直接在公司主 Repo 測嗎？

先不要。先用隔離副本、唯讀或假憑證、無真實個資的 fixture；通過安全門後才評估有限範圍試行。

5. context-mode 的 sandbox 等於 Docker 嗎？

不等於。工具層可限制資料流與部分路徑，但 process 仍受主機權限影響；需要強隔離時仍使用容器或專用測試帳號。

6. 要用 Plugin 還是 MCP-only 安裝？

評測 Claude Code 的自動路由就用 Plugin。MCP-only 仍提供工具，但沒有相同的 hooks 與 slash commands，兩者不能混成同一實驗組。

7. 哪一題最容易看出價值？

通常先看大型、可程式化篩選的輸出，但仍以你的結果為準。小搜尋是必要的負面對照，可揭露固定 routing overhead。

8. 升級後要全部重測嗎？

先跑 smoke cases，再依變更範圍決定。若路由、MCP、權限、安全預設或統計欄位改動，就重跑完整六題。

給新手的 5 個重點

1. 先把 98% 翻譯成「某次輸出壓縮」，不要翻譯成「整體費用折扣」。
2. OFF 組是同版本 Claude Code 的原生狀態，不是過時的空白基準。
3. 每題先寫成功條件，再跑 Agent；評分規則不能看完答案才改。
4. 成功率優先，重取與重跑第二，Token 第三，延遲第四。
5. 安全與 rollback 是採用條件，不是文章最後順手加上的提醒。