上篇我把本机的 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 还是各类高推理模型，底座（Harness）本身就已经具备了精准的代码检索、语法分析和编辑边界意识，客户端的工具链也有了底层校验机制。
这就带来了一个很多人容易忽略的问题：你半年前精心安装的很多 Skill，现在已经变成了纯粹的负资产。
比如以前我们为了让 AI 别写错测试、规范 Git 提交或者做简单的代码重构，会装上一大堆教导型、模版型的辅助 Skill。但在今天的高智商模型和现代 Harness 面前，这些早就成了“模型常识”：
- 白白挤占上下文预算：上篇提过，客户端给 Skill 列表分配的上下文预算通常非常苛刻（例如只有窗口的 1%~2%，200K 窗口下大约仅 2K Tokens）。无脑堆几十个通用 Skill，会导致真正关键的高级工作流（比如特定发布门禁、私有部署流）在初始化索引时直接被挤掉、搜不到。
- 陈旧 Prompt 反而限制大模型：很多第三方 Skill 里的指令还是按照一两年前老模型的脾气写的，充斥着啰嗦的教条规范。强模型读了这些过时指令，反而会束手束脚，表现得像“降智”。
所以这一轮治理的第一步，就是把那些教 AI 怎么写代码、做通用排查的内化型 Skill 全部退役，把珍贵的上下文空间留给专属的业务工作流。
二、 为什么我把常驻 MCP 全拔了，改用 Skill？
除了清理过时的 Skill，另一个让 Agent 变慢的元凶是：滥用常驻 MCP。
刚开始接触 MCP（Model Context Protocol）时我也很上头，恨不得把 GitHub、数据库、搜索、浏览器抓取全挂上去。终端一开，看着满满当当的工具列表很有安全感。
但跑了几天就发现不对劲了，很快就卡顿了。
去看底层的交互日志才明白两者的巨大差异：
- MCP 的机制：为了让模型知道每个工具怎么调用，客户端每次发请求，都必须把当前已挂载 MCP 的全部接口定义（完整的 JSON Schema 参数、字段描述、嵌套类型）一字不落地全部塞进 Prompt。常驻 5 个 MCP，一行业务代码还没开始写，光工具声明就烧掉了好几千 Tokens。
- Skill 的机制：平时常驻在上下文里的，只有一行名字和一句功能简介（name + description）。哪怕挂了几十个，总共也才占几百 Tokens。只有当你明确提出相关需求、命中关键词时，Agent 才会去读完整的
SKILL.md，属于典型的用完即走。
| 维度 | 常驻 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 '/Users/wardlu/.agents/skills'
排查后发现，我的 ~/.agents/skills 居然还指着一个早已弃用的坚果云路径：
~/.agents/skills -> /Users/wardlu/Nutstore Files/我的坚果云/CC-SWITCH/skills
之前换成了AWS S3，留下了一个悬空的“死链接”。安装器下载了文件，往目标目录写入时直接撞墙。
3.3 为什么数量永远对不上？
在那次排查中，我在不同地方看到了四组完全冲突的数字：
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，功能重合度高达 80%，对比后只保留功能最全的批量版本，测试 10/10 通过后归档旧版。
六、 让 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），把膨胀的提示词压回 700 行；
下篇我们厘清了 能力的边界（Skill / MCP / Harness），把内化冗余剔除、把常驻 MCP 拔掉、把多端工具统一收口到 CC-SWITCH。
两套动作做下来，最直接的体感就是：Agent 敲代码的响应明显轻快了，不再莫名其妙调错工具，换设备切环境也彻底告别了重复折腾。
工欲善其事，先利其器；但在 AI 时代，学会定期给工具做减法，可能比到处搜集工具更重要。
关于 Skill 的清理就说到这了，如果你觉得有帮助，欢迎点赞、转发、收藏和评论区留言。
p.s.可接 1v1 咨询和 skill & 工作流定制，欢迎联系。
