context-mode 教學 2026：AI 寫程式一直忘記上下文？3 步學會管理工具輸出

重點先講：context-mode 能協助 AI 管理長任務的上下文。它主要做三件事：隔離龐大的工具輸出、保留工作記憶、透過 MCP 與 hooks 整理資訊流。

最後更新：2026 年 10 月 16 日

資料截點：2026-10-16 12:00（台北時間）

一句話結論：context-mode 是專為 AI 編碼 Agent 設計的上下文管理工具，適合經常使用 Claude Code、Codex 等工具處理大型專案的人；它能協助控制工具輸出，但不能保證模型不會遺忘資訊，也不代表 API 費用必然下降。

你有沒有遇過這種情況？

一開始請 AI 幫忙修改程式，它明明知道你的要求，也知道哪些檔案不能動。結果工作進行到一半，它突然又開始重複搜尋、重新讀檔，甚至忘記前面已經排除的錯誤。

如果只是寫幾行程式，問題可能不大。但接手大型專案、分析測試失敗原因，或讓 Agent 連續執行多個步驟時，這種情況就很麻煩。

GitHub 上的開源專案 mksglu/context-mode，就是針對這類工作流程設計的。

它的做法很值得注意：與其要求 AI 記住每一行工具輸出，不如在資料進入模型上下文之前，先處理與整理。

context-mode 是什麼？它在解決哪一種問題？

context-mode 是一套替 AI 編碼工具管理上下文與工具輸出的開源系統。

先理解一個重要概念：AI 的上下文視窗，可以想成模型這次工作時能參考的資訊空間。

你輸入的需求、之前的對話、工具回傳的結果、系統提供的指令，都可能占用這個空間。

問題在於，真正有用的內容，未必是最占空間的內容。

例如 AI 執行一個測試指令，工具可能回傳大量日誌。實際需要關注的只有失敗測試名稱、錯誤堆疊及相關檔案，但原始輸出可能還包含大量成功測試、進度訊息與重複內容。

假設某次工具輸出有 10,000 行，其中只有 30 行與當前錯誤有關。若全部直接交給模型，其他資訊也會占用上下文空間。

這是方便理解的假設案例，不代表 context-mode 的實測成績。

context-mode 的核心思路，是讓這些原始輸出先進入隔離執行環境，再把必要資訊交給 Agent。部分內容還可以建立索引，之後需要時再搜尋。

這樣的設計，目標是減少無關資訊干擾，同時降低長任務中反覆取得資料的負擔。

context-mode 怎麼運作？MCP、hooks 和記憶各負責什麼？

理解 context-mode，先分清楚三個角色。

MCP：讓 Agent 有新的工具可以使用

MCP 全名是 Model Context Protocol，中文可以理解成模型與外部工具之間的一套通訊協定。

context-mode 透過 MCP 提供工具能力，讓 Agent 可以在隔離環境中處理資料，也能建立與搜尋文字索引。

官方列出的工具包含：

• ctx_execute：在隔離環境執行程式並取得輸出。
• ctx_batch_execute：批次執行多個工作。
• ctx_index：建立可搜尋的文字索引。
• ctx_search：搜尋先前建立的資訊。
• ctx_fetch_and_index：取得網頁內容並建立索引。
• ctx_stats：檢視工具提供的統計資訊。

這些功能讓 AI 有機會先處理資料，再決定需要把哪些內容帶進當前對話。

不過，MCP 工具存在，不代表 Agent 一定會主動使用。還需要看工具註冊、模型的工具選擇，以及執行環境如何設定。

Hooks：在工具執行的關鍵時點介入

Hooks 可以理解成事件觸發器。

例如 Agent 即將呼叫工具、工具完成執行，或工作階段開始時，可以由 hooks 執行指定處理。

這對 context-mode 特別重要。

如果只有 MCP 工具，Agent 仍可能直接讀取完整日誌，把龐大的原始內容放入上下文。

Hooks 能協助引導工具使用與輸出處理方式，讓大型資料優先經過適當的管理流程。

但各種 AI 編碼平台支援的 hook 事件與整合方式並不完全相同，不能假設裝上 MCP 後，所有平台都會自動攔截輸出。

記憶：保存資料不代表模型永遠不會忘記

context-mode 也提供工作階段資訊保存與檢索能力。

這裡有一個容易誤會的地方：把資料保存起來，與模型每次都能正確使用資料，是兩回事。

資料可能已經建立索引，但 Agent 沒有搜尋；也可能搜尋到了相關內容，卻沒有取得完整的例外條件。

所以，記憶工具應該被當成可檢索的工作資料來源，而不是永久不會遺忘的保證。

context-mode 怎麼安裝？先從 Claude Code 開始

不會寫程式也可以理解這套工具的基本流程，但實際安裝仍需要能操作終端機，並且對 AI 編碼工具有基本認識。

目前以 Claude Code 的官方外掛安裝方式作為入門示範，因為它的設定流程比較集中。

注意：以下是依官方文件整理的操作程序，不是本站已完成的安裝實測。正式使用前請核對專案最新 README。

步驟一：確認 Claude Code 可正常執行

先在自己的電腦開啟終端機，輸入：

claude --version

若指令無法辨識，代表目前終端機可能尚未正確安裝 Claude Code，或執行路徑沒有設定完成。

官方安裝說明列出的 Claude Code 最低版本條件為 1.0.33；實際安裝時仍應以最新官方文件為準。

開始之前，請確認使用的是可信任的執行環境，並避免直接在正式生產專案上測試新外掛。

步驟二：透過 Claude Code 的外掛功能安裝

進入 Claude Code 的互動環境，依序輸入：

/plugin marketplace add mksglu/context-mode

接著執行：

/plugin install context-mode@context-mode

這兩個指令分別用來加入外掛來源，以及安裝指定外掛。

安裝後，依官方說明重新啟動 Claude Code，或使用支援的外掛重新載入功能。

這裡要特別提醒：安裝外部工具等於信任額外程式碼。先查看官方原始碼、版本與權限需求，不要直接把陌生外掛接到含有正式憑證的工作環境。

步驟三：執行診斷，確認工具確實載入

完成安裝後，在 Claude Code 中執行：

/context-mode:ctx-doctor

依照官方文件，診斷工具會檢查執行環境、hooks、索引相關能力與外掛註冊狀態。

理想情況是相關檢查全部通過。

如果有失敗項目，先根據診斷結果確認缺少的條件，不要在尚未確認原因時反覆修改全域設定。

最後讓 Agent 執行一個不涉及重要資料的小型任務，再觀察它是否能呼叫相關工具。

建議先用獨立測試專案，避免在正式資料夾中直接讓 Agent 進行大量檔案操作。

context-mode 能用在 Codex、Cursor 或其他 Agent 嗎？

官方文件提供多種 AI 編碼平台的整合說明，涵蓋 Claude Code、Codex、Cursor，以及部分其他支援 MCP 或 hooks 的工具。

但不同平台的整合深度不同。這是選擇安裝方式時最需要注意的一點。

尤其要分清楚兩種情況。

第一種是單純註冊 MCP server，讓 Agent 可以使用 context-mode 提供的工具。

第二種是另外設定 hooks 或路由規則，主動引導工具輸出經過 context-mode 處理。

前者不必然包含後者。

如果你使用 Codex，應先依照官方倉庫的 Codex 專用文件確認最新安裝方法，不宜直接把 Claude Code 的外掛指令複製過去。

官方專案入口：https://github.com/mksglu/context-mode

官方宣稱減少 98% 工具輸出，真的能省 98% token 嗎？

不能直接這樣解讀。

context-mode 的官方介紹宣稱，透過隔離與整理工具輸出，可以大幅降低進入上下文的資料量，並使用了 98% 這個數字。

但截至本文資料截點，本站尚未以相同工作負載完成獨立複測，因此不能把它當作所有使用者都能得到的實際結果。

更重要的是，工具輸出量、模型 token 用量與帳單費用，代表三個不同概念。

假設某次任務原本產生大量日誌，context-mode 讓模型只接收其中少量資訊，模型輸入 token 有可能因此下降。

可是整體任務還可能涉及其他成本，包括多次工具呼叫、重新搜尋、模型回覆，以及不同平台的計費方式。

如果使用的是固定訂閱方案，輸入 token 減少，也未必能直接換算成當月帳單減少。

另外還有一種容易忽略的情況：如果整理過程移除了重要錯誤訊息，導致 Agent 必須重新讀取資料，整體效率未必比較高。

因此，真正有意義的問題是：在保持答案完整與任務成功的前提下，整體模型用量及執行時間有沒有改善？

如何建立一個可重現的 context-mode 測試？

如果想知道 context-mode 是否適合自己的工作流程，可以安排一個小型對照測試。

以下提供的是測試設計，並非本站已執行的實測結果。

第一步：準備相同的測試專案

選擇一個已知存在測試錯誤的小型程式專案。

事先記錄原始版本、失敗測試名稱與預期修正結果，並保留可重現的環境。

最好使用兩份相同的專案複本，避免第一輪修改影響第二輪結果。

第二步：建立關閉與啟用兩種條件

第一組不啟用 context-mode，使用原本的編碼 Agent 流程。

第二組啟用 context-mode，並確認 MCP 與適用的 hooks 已正常運作。

兩組應盡可能使用相同模型、相同提示詞、相同專案初始狀態與相同任務限制。

若要降低隨機性影響，可以針對多個預先固定的測試任務重複比較。

第三步：記錄五種指標

1. 工具原始輸出量：記錄原本產生多少資料，以及處理後送進上下文的量。
2. 實際模型用量：若平台提供 token 統計，分別記錄輸入、輸出與總用量。
3. 任務完成狀況：檢查程式修改是否符合要求，原本的錯誤是否消失。
4. 資訊完整度：確認關鍵錯誤、測試失敗訊息及必要檔案沒有被省略。
5. 執行成本：記錄耗時、重試次數及實際可取得的計費資訊。

可以使用下面這張表記錄結果。

沒有實際紀錄的欄位保持待測，不應自行填入推估的改善幅度。

如果啟用後 token 用量下降，但程式沒有修好，就不能單憑節省用量判定工具有效。

相反地，如果 token 用量變化不大，卻明顯減少重複搜尋與重試次數，也值得進一步研究。

context-mode 和一般程式碼索引工具有什麼差別？

AI 編碼工具的資訊管理問題，可以分成幾個層次。

有些工具專門尋找相關程式碼，有些負責提供最新文件，有些則管理工作階段中的工具輸出。

三者之間可能互相補充，但不能直接視為相同用途。

例如，當 AI 不知道應該修改哪個檔案時，程式碼索引可能比上下文整理更直接。

當 AI 已經找到正確檔案，但因為大量測試日誌造成對話負擔，context-mode 的設計方向就比較貼近問題。

如果主要困擾是 AI 使用過時的 API 文件，文件檢索工具可能更適合。

網站之前也介紹過與這些問題有關的工具，可以搭配閱讀：

• code-review-graph：如何讓 AI 聚焦需要閱讀的程式碼
• Context7 MCP：取得與編碼工作相關的官方文件
• Agent Skills 生態盤點：如何管理 AI 的專業能力

這些文章討論的是不同層次的問題，不能把各篇引用的節省比例直接相加。

哪些人適合使用 context-mode？哪些人暫時不需要？

我會先看使用情境，而不是先看 GitHub 星數。

因為即使一個工具很熱門，只要它增加的設定成本超過實際改善，對使用者就未必划算。

如果自己還沒碰過上下文壅塞、日誌太長或反覆讀檔的問題，沒有必要只因為看到節省數字就增加一套工具。

但如果團隊已經讓 AI 每天處理大型程式專案，這類工具值得安排一次受控測試。

context-mode 免費嗎？正式環境還有哪些成本？

context-mode 提供公開的 GitHub 原始碼倉庫，並有可供安裝的工具流程。

不過，公開原始碼不等於整套 AI 工作流程沒有成本。

至少還要分開考慮以下項目：

• 編碼 Agent 原本的訂閱費或 API 使用費。
• 執行工具需要的 Node.js 或其他執行環境。
• 設定、更新與相容性測試所需的維護時間。
• 本地索引與工作階段資料的儲存及清理成本。
• 正式專案導入後，可能需要的權限管理與安全審查。

本次沒有完成所有版本、授權條件與相依套件的逐項稽核，因此不宣稱任何企業或商業使用情境都完全沒有授權限制。

如果準備導入正式環境，先閱讀官方 LICENSE、檢查相依套件，並確認資料實際存放與執行位置。

尤其是包含客戶資料、內部原始碼、存取憑證或其他敏感資訊的專案，應先經過權限與資料保護審查。

導入 context-mode 最大的風險是什麼？

我認為最值得注意的風險，是模型看到的資訊變少，卻剛好少了重要的那一段。

假設程式有兩個測試失敗，一個是常見的格式錯誤，另一個涉及資料庫狀態。

如果輸出處理過程只保留前者，Agent 可能很快修好格式問題，然後宣稱任務完成。

但真正影響系統的資料庫問題仍然存在。

這是資訊處理系統普遍需要防範的風險情境，不代表已確認 context-mode 存在這個特定缺陷。

導入前，我會要求至少保留四種證據：

• 原始工具輸出的可追溯來源。
• 失敗測試及錯誤堆疊的完整紀錄。
• Agent 實際修改的檔案與差異。
• 最後重新執行測試的結果。

另外，索引保存的資訊應有清理與存取控制機制。若把敏感資料放入可檢索的索引，即使模型當下沒有顯示該內容，資料仍可能存在於儲存環境中。

因此，正式環境不應把上下文管理工具當成安全隔離系統，仍需依照最小權限原則處理資料。

如果不安裝 context-mode，有沒有替代方法？

有，而且對小型專案來說，可能更直接。

最簡單的方法是建立一份固定的任務摘要，讓 AI 每次開始工作時都能讀取。

例如在專案中維護一份不含敏感資料的工作說明，清楚寫出：

• 這次任務的目標。
• 哪些檔案可以修改。
• 哪些檔案禁止修改。
• 已經確認的事實與限制。
• 已完成的工作。
• 下一步需要執行的檢查。

另一個方法，是調整測試與搜尋指令，讓工具直接提供較精簡的輸出。

例如只讀取失敗測試的摘要，或在確定需要時再展開完整日誌。

但這種方法也要小心，不能把所有錯誤內容直接過濾掉。

如果主要問題是搜尋大型程式庫，可以評估程式碼索引工具；如果需要管理複雜 Agent 工作流程，則可以從明確的任務狀態與驗收機制開始。

這些替代方式不保證可以完全取代 context-mode，但有機會在不增加外部依賴的情況下改善工作流程。

常見問題 FAQ

context-mode 是 AI 模型嗎？

不是。context-mode 是用來輔助 AI 編碼 Agent 管理工具輸出、上下文與工作階段資訊的工具，本身並非取代 Claude 或其他大型語言模型。

context-mode 能讓 Claude Code 永遠不會忘記嗎？

不能保證。它提供資訊整理與檢索能力，但模型是否取得正確資料，以及能否正確理解資料，仍取決於整體工作流程。

context-mode 官方宣稱減少 98%，指的是什麼？

官方以工具輸出減少作為主要宣傳指標。這不等於每個任務都會減少 98% 的 token，更不能直接解讀成 API 帳單降低 98%。目前本站尚未獨立複測該數字。

context-mode 可以搭配 Codex 嗎？

官方提供 Codex 相關整合資源，但安裝方式、MCP 註冊與 hooks 支援狀態應依實際平台版本核對，不能直接套用 Claude Code 的全部操作指令。

不會寫程式的人能使用 context-mode 嗎？

可以先理解它的用途，但安裝與維護通常需要基本終端機操作能力。若只是一般聊天或簡單 AI 問答，暫時不需要增加這套工具。

context-mode 可以直接裝在正式生產環境嗎？

不宜未經測試直接導入。應先在隔離環境確認相容性、權限、資料保存方式及工作結果，再決定是否擴大使用。

結論：context-mode 值得安裝嗎？

如果你的 AI 工作通常幾分鐘就完成，而且沒有大量工具輸出，現在不一定需要 context-mode。

但如果你每天使用 Claude Code、Codex 或其他 Agent 處理大型專案，經常碰到重複讀檔、日誌過長、工作脈絡難以維持等問題，它值得列入測試清單。

真正吸引我的地方，是它把工具輸出管理、可檢索資訊與執行流程整合成一套系統。

這讓我們可以重新思考一個問題：AI 執行任務時，到底有多少資料必須直接交給模型？哪些資訊其實可以先保存，等需要時再取用？

不過，我不會只因為官方宣稱減少 98% 就直接在正式專案全面啟用。

至少要先確認三件事：工具能正常運作、重要資訊沒有遺失、最終任務品質沒有下降。

如果這些條件都成立，再去比較實際 token 用量與維護成本，才有辦法判斷它是否真正改善工作效率。

最後的判斷原則：節省上下文空間是手段，讓 AI 持續取得正確資訊、完成可以驗收的工作，才是最終目的。

延伸閱讀

• code-review-graph：AI 程式碼檢索與 token 使用分析
• Context7 MCP：如何改善 AI 取得技術文件的流程
• Agent Skills 生態盤點：如何檢查技能與工作流程
• CrewAI：多 Agent 工作流程的基本架構

資料來源

• mksglu/context-mode 官方 GitHub 倉庫與 README
• context-mode Cursor 外掛官方安裝說明
• context-mode GitHub Copilot CLI 官方整合說明
• context-mode 官方 Benchmark 文件，效能數據屬專案方資料

資料截點：2026-10-16 12:00（台北時間）。本文以官方文件及公開專案資料整理，部分功能與安裝方法可能隨版本更新。本站尚未獨立安裝測試 context-mode，也未驗證其宣傳的效能改善比例。本文操作步驟僅供技術學習與評估使用。

利益揭露：本文沒有提供交易所邀請連結或付費工具返佣連結，亦非經確認的廠商贊助評測。

免責聲明：本文僅供技術資訊與教育參考，不保證工具適用於任何特定工作環境，也不保證資料安全性、任務成功率或成本節省幅度。安裝第三方工具前，應自行評估權限、相依套件、授權條件及安全風險。