研究與觀察AI 趨勢與技術研究
AI ENGINEERING / ARTICLE 02
AI 工程研究 · 正式發表

Claude Code Mods 怎麼用？與 Skill、MCP、Hook 的差異和選型

Claude Code Mods 可觀察、改寫執行事件並建立互動面板。本文比較 Skill、MCP、Settings Hook 與 Mod 的責任，搭配自動化測試情境說明導入順序、安全風險及版本注意事項。

作者 Luke Hou 發布： 研究資料查核： AI 趨勢與技術研究

一個 Coding Agent 正在執行測試，連續幾輪都碰到相同的 Selenium timeout。人只看得到不斷增加的輸出，卻很難立刻判斷：這是新的失敗、重複的嘗試，還是測試仍卡在同一個步驟？

要替這種工作流加上規則和觀測能力，Claude Code 已有幾條擴充路線。Skill 適合提供工作方法；MCP 連接外部系統；Settings Hook 在固定事件執行檢查。2026 年 10 月 1 日推出的 Claude Code Mods，則讓開發者可以直接處理 Claude Code 的執行事件、共享狀態，並在終端機介面畫出互動面板。

這個差異會影響工程設計。對已經有一套 Python 測試程式或 Agent 工作流的團隊，選對擴充層次，通常比一開始就寫出功能龐大的 Mod 更有價值。

Mod 可以觀察或改變 Claude Code 的執行事件

Anthropic 把 Mod 定義成一種 Claude Code Plugin。開發者在 JavaScript 或 TypeScript 模組註冊事件處理函式，Claude Code 發生工具呼叫、權限檢查、提示詞送出、回合變化或介面重繪時，就會執行對應函式。

以 tool.call 事件為例，Mod 可以先檢查工具呼叫，再讓原本的流程繼續；某些事件也支援改寫或直接接手處理。開發者還可以把多次事件累積成 session 狀態，繪製 prompt 上方的資訊列或側邊面板。這些能力讓 Mod 特別適合顯示工具呼叫次數、Agent 活動、上下文用量及需要人工注意的操作。

官方文件指出，終端機版自 Claude Code v2.1.287 起支援 Mods，且預設啟用。Claude Desktop 的 Code tab 也有支援，但各執行介面的顯示能力不同：VS Code 的聊天面板與 claude -p 可以執行適用的事件處理，卻不會呈現相同的自訂 pane／band。設計 Mod 前應先確認實際使用介面。

來源：Claude Code Mods 官方概覽；v2.1.287 發布紀錄

Skill、MCP、Settings Hook 與 Mod 各自負責不同問題

機制主要用途通常如何使用適合的情況
Skill把工作方法、程序與判斷規則交給模型撰寫 SKILL.md，由使用者或 Claude 載入測試設計 SOP、失敗分類、Code Review、交接格式
MCP server提供外部資料與可呼叫的工具註冊遵循 MCP 的本機或遠端服務查詢 GitHub、工單、測試證據、經授權的 API
Settings Hook在 Claude Code 指定事件時執行固定動作或檢查在 settings.json 設定 command、HTTP 等 handler執行前檢查、固定記錄、敏感操作阻擋、通知
Mod處理執行事件、共享狀態、改寫互動與呈現原生介面在 Plugin 內撰寫 JS／TS 事件處理函式即時狀態面板、互動確認、進階執行觀測

這四種機制可以放在同一個工作流，甚至打包在同一個 Plugin。選型時先看需求：模型反覆需要同一套做事方法，可以寫 Skill；缺少外部資料，優先評估 MCP；只想在執行某個事件時跑既有檢查腳本，可用 Settings Hook；需要原生介面或跨事件狀態，才值得採用 Mod。

另有一個命名細節：Anthropic 在 Mods 文件中，也把 Mod 的處理函式稱作「hook」。它和 settings.json 定義的 Settings Hook 採用不同的 API 與事件模型，移植時不能只換事件名稱。

來源：Anthropic 官方機制比較；Skills；MCP；Hooks

自動化測試除錯可以用一個組合方案

以下是建議的設計情境，用來說明責任分工；並不代表已經量測過實際節費、成功率或執行時間。

假設 Selenium E2E 測試連續失敗，團隊想保留可追溯證據，同時讓操作者快速看懂現在發生什麼事：

  1. 由 Skill 定義失敗分析方法：先看案例識別、錯誤類型與必要的畫面／log；分辨環境、定位器、測試資料與產品問題，沒有證據就標待確認。
  2. 由 MCP 或既有 API 取得經授權的工單、PR 與測試報告。資料存取與寫入權限仍由後端控制。
  3. 由 Settings Hook 執行確定性的事件檢查或留下必要紀錄，例如敏感命令驗證、測試結束後保存報告索引。
  4. 由 Mod 在 Claude Code 內顯示目前 Agent、最近一次工具呼叫、失敗類型與人工待處理事項。第一版先以只讀狀態呈現，不接手工具批准。
  5. 由實際測試執行器或工作流控制程式維護強制停止條件。連續失敗上限、時間預算、是否允許重跑，都應由可測試的狀態機判斷，避免只靠模型記得一段文字規範。

這種分工可以保留 Python／Selenium runner 的測試真相，並把 Claude Code 視為操作與分析介面。如果工作流跨多個 Agent CLI 或多台機器，應考慮獨立的事件服務或側邊控制台，避免把共用狀態綁死在單一 Claude Code session。

第一個 Mod 可以從只讀觀測開始

官方的最小 Mod 具有 Plugin manifest、hooks/hooks.json 與事件模組。下列 JavaScript 僅示範註冊函式，並非可獨立安裝的完整 Plugin：

let toolCalls = 0

export function register(on) {
    on("tool.call", async ($, event, next) => {
        toolCalls += 1
        return next(event)
    })
}

這段程式會在同一個模組載入期間累計工具呼叫數，並讓事件照常執行。要把數字顯示在畫面上，還要依 Mods UI API 註冊相應事件與繪製邏輯。官方提供的 token-weather 範例，已展示將上下文資訊放在提示詞上方；blast-radius 則示範高風險命令執行前的互動確認。

拿到完整 Plugin 後，可以先在本機檢查，再透過單次 session 載入測試：

claude plugin validate ./my-mod
claude --plugin-dir ./my-mod

這兩個命令的前提是 ./my-mod 已包含完整且符合當前 Claude Code 版本要求的 Plugin 檔案。升版時，應重新驗證事件型別、功能相容性、意外錯誤與顯示降級行為。官方 API 仍在快速變動，本機產生的型別宣告應作為實際開發依據。

來源：Claude Code 官方 Mod 開發教學；官方範例專案

Mod 的權限範圍需要獨立評估

Mod 會以使用者的權限執行，可能讀寫檔案、啟動程序、連網、讀取環境變數、看到提示詞與工具呼叫，甚至在特定情況下替使用者核准工具。官方也明確指出，Mods 沒有安全 sandbox；Claude Code 對 Bash 工具的沙箱隔離，不能直接套用到 Mod 自己啟動的程序。

管理員設定的 deny rule 和 managed hook 可以控制 Claude 的工具操作，但不應假設它們會以相同方式限制 Mod 自己的檔案或程序 API。安裝第三方 Mod 前，至少要檢查程式碼來源、是否真的需要檔案寫入／連網／模型呼叫，以及 claude plugin validate 列出的事件與 API 能力。

特別需要留意的是：Mod 本身也可以攔截 permission 事件，因此不能把單一 Mod 當成整套組織安全邊界。敏感資料隔離仍要由作業系統、後端授權、組織政策與明確的審計機制共同負責。

來源：Anthropic Mods 安全說明；企業管理文件

近期版本修正了 Hook 的失敗處理

Claude Code Mods 於 2026 年 10 月 1 日公開後，幾個版本內就持續新增事件與修正邊界行為。原研究記錄到 v2.1.292 的 prompt.autocomplete、模型快取和 Agent 事件更新；截至 2026 年 10 月 10 日再次查核，官方 Releases 已更新至 v2.1.296，發表時間換算為台灣時間 10 月 10 日。

v2.1.295 新增 command／HTTP Settings Hook 的 onFailure: "block" 選項。這讓符合條件的 handler 在無法啟動、逾時或異常退出時可以選擇阻擋操作，適合需要明確失敗關閉策略的檢查。不過，實際阻擋範圍仍取決於 Hook 的事件、匹配條件與設定；程式導入前應刻意測試 timeout、例外與重新啟動情境。

同版也新增 $.ui.notify 讓 Mod 發出通知，並修正與 Mod guard、hook worker、權限檢查相關的問題。v2.1.296 接著新增 subagent 的 autoCompactWindow 設定，並修正 managed settings 的 Hook 拒絕行為、Mod prompt.submit 中斷處理等問題。這些變更提醒我們，初期導入宜固定版本及回歸測試，避免把一次跑得動當成長期相容。

來源：Claude Code v2.1.292；v2.1.295 官方發布紀錄；v2.1.296 官方發布紀錄

導入順序應由觀測逐步走向控制

對長時間 Agent 工作流，我會先做一個只讀的執行狀態面板：記錄必要的工具事件、失敗類別與等待人工處理的節點，先確認它能否降低查找問題的時間。這是工程建議，尚未提供實測效益數據。

如果下一步要加入操作阻擋，可以把安全檢查獨立成可測試的模組，再處理確認、拒絕、逾時與恢復。真正影響資料或部署的強制規則，仍應交由實際控制系統執行。遇到需要跨工作階段的證據鏈，也要先定義哪些資料能記錄、保存多久，以及誰能存取。

當需求只是固定 SOP、取得一個外部資料源或執行既有檢查，Skill、MCP 和 Settings Hook 都有更直接的做法。Mod 的優勢會出現在需要即時互動、執行事件整合及 Claude Code 原生可視化的場合。這也是評估是否值得承擔額外維護與安全成本的合理起點。

主要參考資料