AI 降智秒解（下）：清理常駐 MCP 和過時的 Skill

上一篇我把本機的 Agent 規則檔案從 6,594 行壓到了 736 行，砍掉了 88.8%。效果當時就立竿見影。

但我很快發現，事情只解決了一半。

平時寫程式碼，我手裡會同時開著 Claude Code、Codex 和 Antigravity。規則清爽之後，切到大任務時 Agent 偶爾還是會卡頓、響應變慢，甚至在選工具時繞遠路。翻開本機環境一看：不同用戶端裡的 Skill 數量根本對不上，以前隨手掛上去的幾個常駐 MCP 還在霸佔上下文，有些已經失效的軟連結還在悄悄報錯。

先放結論：模型變強後，不僅提示詞要精簡，工具鏈也必須斷舍離。被底座（Harness）內化的基礎 Skill 果斷退役，常駐 MCP 幾乎全拔掉改用輕量 Skill，最後把多 Agent 的擴充功能統一直連到 CC-SWITCH，配合雲備份解決換裝置同步。

💡 省流直通車：如果你只想給電腦裡的 Agent 徹底做一次只讀體檢和一鍵瘦身，可以直接跳到第六節 「讓 AI 跑的兩段治理提示詞」 複製執行。

---

一、很多 Skill，其實早就被底座內化了

上一篇我聊過一個公式：Agent = Model + Harness。

現在無論是 GPT-5.6-Sol 還是各類高推理模型（2026 年 8 月的環境），底座（Harness）本身就已經具備了精準的程式碼檢索、語法分析和編輯邊界意識，用戶端的工具鏈也有了底層校驗機制。

這就帶來了一個很多人容易忽略的問題：你半年前精心安裝的很多 Skill，現在已經變成了純粹的負資產。

比如以前我們為了讓 AI 別寫錯測試、規範 Git 提交或者做簡單的程式碼重構，會裝上一大堆教導型、模版型的輔助 Skill。但在今天的高智商模型和現代 Harness 面前，這些早就成了「模型常識」：

1. 白白擠佔上下文預算：Claude Code 官方文件寫明，Skill 列表的預算是上下文視窗的 1%（200K 視窗下大約 2K Tokens）。列表裝不下時，它會從你最少呼叫的 Skill 開始丟棄描述。無腦堆幾十個通用 Skill，其餘 Skill 的關鍵詞更容易被擠掉，真正重要的專屬工作流反而更難被自動觸發。
2. 陳舊 Prompt 反而限制大模型：很多第三方 Skill 裡的指令還是按照一兩年前老模型的脾氣寫的，充斥著囉嗦的教條規範。強模型讀了這些過時指令，容易束手束腳，表現出來就像「降智」。

所以這一輪治理的第一步，就是把那些教 AI 怎麼寫程式碼、做通用排查的內化型 Skill 全部退役，把珍貴的上下文空間留給專屬的業務工作流。

---

二、為什麼我把常駐 MCP 全拔了，改用 Skill？

除了清理過時的 Skill，另一個讓 Agent 變慢的元兇是：濫用常駐 MCP。

剛開始接觸 MCP（Model Context Protocol）時我也很上頭，恨不得把 GitHub、資料庫、搜尋、瀏覽器抓取全掛上去。終端一開，看著滿滿當當的工具列表很有安全感。

但跑了幾天就發現不對勁了，很快就卡頓了。

去看底層的互動日誌才明白兩者的巨大差異：

• MCP 的機制：工具能不能用、怎麼呼叫，都要靠用戶端把介面定義（JSON Schema 參數、欄位描述、巢狀類型）交給模型。拿我 2026 年 8 月時在用的版本說，每次發請求都得把已掛載 MCP 的全部介面定義塞進 Prompt，常駐 5 個 MCP，一行業務程式碼還沒開始寫，光工具宣告就燒掉了好幾千 Tokens。新版 Claude Code 預設開啟了 MCP tool search，只先載入工具名和伺服器說明，完整定義等需要時再取；但關掉 tool search、用老模型，或者自定義了 alwaysLoad 的工具，仍然會全量載入。
• Skill 的機制：平時常駐在上下文裡的，只有名字和一兩句描述（name + description）。哪怕掛了幾十個，預算之外的開銷也很小。只有當你明確提出相關需求、命中關鍵詞時，Agent 才會去讀完整的 SKILL.md。注意它並不是「用完即走」：讀進來的全文會留在上下文裡，直到下一次壓縮。所以該退役的 Skill 不退役，越用越佔地方。

維度	常駐 MCP	本機 Skill
上下文佔用	高（全量載入完整 Schema 時尤其明顯；新版預設按需載入）	低（常駐僅一行描述，命中後展開）
執行開銷	涉及程序通訊、網路服務、外部鑑權	本機 CLI、腳本或純 Prompt 流程
副作用風險	容易發生外部誤寫、費用超支或超時	邏輯可控，權限侷限在本機或專案內
適用場景	強依賴外部動態資料（如真實資料庫讀寫）	確定性的開發規範、發布門禁、腳本工具

看清這個帳本後，我的策略變得極其乾脆：只要能寫成本機腳本或 CLI 的，全部做成 Skill；常駐的 MCP 幾乎全拔掉。

卸掉這些笨重的常駐介面後，終端響應明顯輕快了不少。

---

三、兩次翻車現場：多 Agent 的路徑到底有多亂？

想把工具鏈收拾乾淨，最怕的就是「憑感覺盲刪」。在實際排查中，我遇到了兩次非常典型的翻車場景。

3.1 現場一：差點誤刪整個全域目錄

最開始我想清理一個 GitHub 開源專案帶進來的擴充功能。該專案在本機建了一套 .claude/agents 和 .claude/skills。

我當時順手想執行 rm -rf ~/.claude/skills。幸好停下來核對了一下軟連結，才發現本機的 ~/.agents/skills 實際上是一個指向中央共享目錄的符號連結。如果當時連著連結一起清掉，其他 Agent 共用的一百多個 Skill 就會從它們的入口裡消失。

目錄名只能說明「這裡有個目錄」，根本說明不了它到底從哪裡來、誰在引用它。

3.2 現場二：安裝報錯，順藤摸瓜揪出懸空軟連結

在測試安裝 writing-plans 這個 Skill 時：

npx skills add https://github.com/obra/superpowers --skill writing-plans

CLI 提示已經下載完成，但緊接著底部刷出了十幾個紅色的 ENOTDIR 報錯：

ENOTDIR: not a directory, mkdir '~/.agents/skills'

排查後發現，我的 ~/.agents/skills 居然還指著一個早已棄用的同步盤路徑：

~/.agents/skills -> <同步盘>/CC-SWITCH/skills

之前換成了 AWS S3，留下了一個懸空的「死連結」。安裝器下載了檔案，往目標目錄寫入時直接撞牆。

3.3 為什麼數量永遠對不上？

在那次排查中，我在不同地方看到了四組完全衝突的數字（2026 年 8 月 23 日的本機快照）：

1. 物理共享目录扫描：227 个目录（约 220 个有效 SKILL.md）
2. 跨插件和运行时扫描：187 个 SKILL.md
3. CC-SWITCH 登记库：67 条记录
4. Claude Code 实际识别：68 个

其實每一組數字都沒錯，只是統計口徑完全不同：有的是磁碟物理資料夾，有的是外掛內部的臨時快取，有的是全域註冊表，有的是當前用戶端根據白名單和預算實際加載出來的結果。

把這些入口釐清後，一套健康的多 Agent 工具鏈必須分清：誰是唯一事實源，誰是相容軟連結，誰是用戶端的執行時索引。

---

四、統一納管：從 npx skills 分發到 CC-SWITCH 桌面管理

為了不再讓工具散落各處，我的管理方式經歷了兩個階段的演進：

4.1 命令列階段：用 npx skills 搞定多端分發

由社群提供的 npx skills CLI 非常適合做批次安裝與解除安裝：

npx skills add <skill-repository> --skill <skill-name>

它最大的好處是可以在安裝時一次性勾選多個目標 Agent（Claude Code、Codex、Antigravity 等），不用切到各個工具的根目錄下重複敲命令。

4.2 視覺化與換機階段：收口到 CC-SWITCH

CLI 解決了「安裝動作」，但解決不了「狀態監控」和「跨裝置同步」。當 Skill 變多之後，我更需要一個全域看板。

我把本機已有的 Skill 全部匯入到 CC-SWITCH 中，形成了現在的統一架構：

CC-SWITCH（全局控制面）
├── 统一查看 Skill、MCP 与插件清单
├── 可视化控制各 Agent 的启用 / 禁用状态
└── 一键配置云备份
        ↓
Claude Code / Codex / Antigravity（执行端）
        ↓
各自通过标准化入口读取同一份事实源

這套方案最大的爽點在於換新裝置：

以前換電腦，最痛苦的就是要把十幾個 GitHub 倉庫重新找一遍、一個個敲命令安裝，最主要的還是 skill 太多容易漏。現在只需在 CC-SWITCH 裡把備份一鍵拉取下來，所有 Agent 的 Skill 掛載和開關狀態就能基本恢復，省去重複折騰。

---

五、Skill 治理的三維分類法

做完這輪清理後，我不再把所有工具一股腦塞進全域目錄，而是把它們拆解為三個獨立的維度進行治理：

維度	決策選項	實際處理方式
存放位置	全域 / 專案級	全域通用放 ~/.cc-switch/skills；專案專屬（如特定程式碼庫發布流程）放專案根目錄
管理方式	CC-SWITCH / CLI	絕大多數通過 CC-SWITCH 統一匯入與管理；臨時測試走 npx skills
啟用範圍	全量啟用 / 指定 Agent / 停用	高頻核心工具全開；重型低頻工具設為按需勾選，用完即關

• 保留在全域的高頻守門員：如 public-repo-git-gate（防止敏感金鑰外洩）、發布檢查等硬性門禁，所有專案和 Agent 全量常駐。
• 退役與清理項：早期教 AI 寫單測、做常規程式碼查錯的通用 Skill，確認已被現代模型和 Harness 內化後，全部移出。
• 合併重複項：比如之前系統裡有多個不同來源的 Web Store 圖片裁剪 Skill，功能高度重合，對比後只保留功能最全的批次版本，測試全部通過後歸檔舊版。

---

六、讓 AI 跑的兩段治理提示詞

如果你也想給自己的電腦做一次徹底的 Agent 工具鏈體檢，不需要手動去翻各個深層目錄。我把這套只讀分析與精準執行的邏輯整理成了兩段提示詞。

6.1 提示詞一：只讀全面盤點（先摸底，別急著刪）

请对本机所有 AI Agent 的扩展与工具配置进行只读全面盘点，严禁修改、删除或移动任何文件。

请结合实际目录结构、配置与 CLI 帮助，识别当前存在的 Agent 运行时及其入口（如 Claude Code、Codex、Antigravity 等），并检查是否存在 CC-SWITCH、插件管理器或其他统一管理面。

重点盘点并核对以下内容：
1. 内化候选：识别出哪些 Skill 仅提供通用基础语法、常规代码重构或基础 Git 提示，已经完全被现代大模型和 Harness 能力内化，可建议退役；
2. 真实路径与软链接：检查 ~/.cc-switch/skills、~/.agents/skills、~/.claude/skills 等目录，排查是否存在悬空链接或套娃引用；
3. MCP Server 现状：盘点已配置的 MCP 工具，分析其上下文 Schema 占用、权限范围及调用成本，标出哪些可被轻量本地 Skill 替代；
4. 重复与孤儿缓存：排查跨 Agent 重复安装的 Skill 及 ~/.claude/plugins 中的无用孤儿缓存。

输出要求：
将结果按【建议退役的内化项 / 建议保留的全局项 / 项目级专属项 / 重复候选 / 异常软链接】清晰分类。
列出名称、物理路径、所属 Agent、占用风险及建议处置方式。

最后给出：
1. 真实可用库存与统计口径差异说明；
2. 识别出的冲突与悬空软链接；
3. 推荐的唯一事实源收敛方案；
4. 确认可安全执行的精简计划。

6.2 提示詞二：確認清單後動工（帶備份與閉環驗收）

请严格按照刚才我们确认并批准的清单执行优化，切勿扩大范围。

执行安全规范：
1. 执行任何移动或删除前，先在 ~/.agent-instructions-backups/ 创建带当前时间戳的完整备份目录，保存原路径、软链接与配置快照，并生成 SHA256 校验；
2. 保留指定的唯一事实源（如 ~/.cc-switch/skills），修复或重建标准兼容入口软链接（如 ~/.agents/skills），严禁跨目录重复拷贝；
3. 对确认退役的内化 Skill、重复 Skill 和插件孤儿缓存执行移出与归档；
4. 同步更新相关的 lock 文件、metadata 记录与数据库；
5. 如果配置了 CC-SWITCH 云备份，在操作完成后生成同步校验报告。

执行后逐层验收并输出报告：
- 真实物理目录与有效 SKILL.md 数量变化；
- 符号链接的目标指向是否健康可用；
- 各 Agent 客户端（Claude Code / Codex / Antigravity）实际加载和识别到的工具状态；
- 最终按【已验证完成 / 需人工确认 / 被阻塞】分类汇报，不以简单的命令退出码代替真实结果。

---

結語

上一篇我們守住了 規則的邊界（AGENTS.md / CLAUDE.md），把膨脹的提示詞壓回 736 行； 這一篇我們釐清了 能力的邊界（Skill / MCP / Harness），把內化冗餘剔除、把常駐 MCP 拔掉、把多端工具統一收口到 CC-SWITCH。

兩套動作做下來，最直接的體感就是：Agent 敲程式碼的響應明顯輕快了，不再莫名其妙調錯工具，換裝置切環境也基本告別了重複折騰。

工欲善其事，先利其器；但在 AI 時代，學會定期給工具做減法，可能比到處蒐集工具更重要。