AI

context-mode：把工具輸出關進沙盒，讓 AI Coding Agent 的 Context 省下 98%

Monday

本內容僅供參考，詳細使用規則與工具安全性與否，建議要進行相關安全性測試與評估

用 AI Coding Agent 工作半小時後，你可能會發現 context window 已經用掉四成——而這些空間大多被一次 Playwright snapshot（56 KB）、二十個 GitHub issues（59 KB）或一份 access log（45 KB）吃掉了。context-mode（mksglu/context-mode）要解決的正是這件事：不讓原始工具輸出直接進入 context，而是讓模型「用程式碼思考」，只把結果帶回來。專案目前約 25.7k stars，支援 17 個 Agent 平台。

1. 專案背景與定位

context-mode 以 TypeScript 開發，需要 Node.js 22.5+ 或 Bun，授權為 Elastic License 2.0（ELv2）——注意這不是 OSI 認可的開源授權。它以 MCP Server 搭配各平台的 hooks 運作，在 Claude Code 上可以透過 plugin marketplace 全自動安裝。

它的定位是 AI Coding Agent 的「context 管理層」：一方面壓縮工具輸出，一方面在 compaction 時保留工作狀態，避免 Agent 忘記自己正在改哪些檔案、做到哪一步。

2. 技術架構與核心設計

  • 沙盒執行：每次 ctx_execute 都在獨立子行程中執行，只有 stdout 會進入 context。支援 JavaScript、TypeScript、Python、Shell、Go、Rust 等 12 種 runtime。
  • Think in Code：與其讓模型讀 47 個檔案（700 KB），不如讓它寫一段腳本分析後只印出摘要（3.6 KB）。
  • 本機知識庫：ctx_index 依標題切分 Markdown（保留完整 code block），存進 SQLite FTS5，以 BM25 + Porter stemming 搜尋，並與 trigram 分詞結果透過 Reciprocal Rank Fusion 融合，再加上鄰近度重排與模糊修正。
  • 擷取快取：ctx_fetch_and_index 預設快取 24 小時，超過 14 天的內容在啟動時清除。
  • 漸進式節流：同一輪搜尋第 1–3 次回傳 2 筆、第 4–8 次只回 1 筆並警告、第 9 次以後直接擋下並導向批次執行——強迫模型改變「一直搜尋」的壞習慣。
  • 跨 compaction 的工作記憶：檔案編輯、git 操作、任務、錯誤、使用者修正等事件存進 SQLite；在 PreCompact 時產生 2 KB 以內的優先級快照，SessionStart 時還原。
  • 11 個 MCP 工具：包含 ctx_batch_execute、ctx_search、ctx_stats、ctx_doctor、ctx_purge 等。

3. 社群熱度與生態採用

約 25.7k stars、1.8k forks、2,200+ commits，支援 Claude Code、Gemini CLI、VS Code／JetBrains Copilot、Cursor、OpenCode、Codex CLI、Kiro、Zed 等 17 個平台。不過支援程度不一：有完整 hooks 的平台效果最好，只靠路由指令檔的平台，README 自己估計遵從率約 60%。

README 宣稱的壓縮效果：整體 315 KB → 5.4 KB（98%）；ctx_execute 56 KB → 299 B、ctx_batch_execute 986 KB → 62 KB。這些是專案自己的測量，實際效果會依工作型態而異。

4. 局限性與潛在風險

  • 授權不是開源：ELv2 限制了以託管服務形式提供等用途，企業導入前需要法務確認。
  • 憑證透傳：gh、aws、gcloud、kubectl、docker 等已登入的 CLI 會透過環境變數把憑證傳進沙盒。「不暴露給對話」不等於「不能被使用」——模型寫的腳本依然能用這些權限做事。
  • 沙盒不是安全邊界：子行程隔離的目的是隔離 context，而不是隔離權限；它能讀寫的檔案與網路範圍和你的使用者帳號相同。
  • Hooks fail-open：安裝過舊時 hooks 會變成無效而非阻擋，這對可用性友善，但也意味著你可能在不知情下失去保護。
  • 資料留存：session 資料存在 ~/.context-mode/，不加 --continue 開新 session 時會刪除舊資料，需了解這個行為以免誤刪工作記錄。
  • 品質宣稱的未驗證部分：README 列出微軟、Google、Meta 等公司 logo 作為使用者，但並未提供可查證的案例。

5. 應用價值與適用場景

長時間的 Coding Agent session（大型重構、除錯、處理大量 log 或 API 回應）最能感受到差異：context 撐得更久、compaction 後不會「失憶」。需要反覆查詢文件的工作，本機 FTS5 知識庫也比每次重新擷取更省 token。

如果你的 Agent 使用方式以短任務為主，或平台只支援路由指令檔，效益會明顯下降。

Monday 的觀點與架構建議

  • 「讓模型寫程式處理資料，而不是把資料讀進 context」是 Agent 設計中最被低估的原則之一，context-mode 把它做成了基礎設施。即使不安裝，也值得在自己的 prompt 規範中採用。
  • 漸進式節流的設計很聰明：與其在 prompt 裡要求模型「不要一直搜尋」，不如在工具層直接改變它的行為成本。
  • 部署時建議搭配真正的權限隔離（容器或最小權限帳號），不要把「context 沙盒」誤解為「安全沙盒」。
  • Context 管理正在從「模型供應商的問題」變成「工具鏈的問題」，未來 Agent 平台的競爭力，很大一部分會取決於這一層做得好不好。

參考來源