Skill 是什么、怎么写，这篇文章不准备展开介绍。这里聊的是另一件事：当跨 agent 工作越来越常见，工具转换间，沉淀的 skill 怎么办。

以我自己为例：同时用 Claude Code、Codex 和 Cursor 三个 agent（之前还有 Gemini CLI），并在它们各自的 skill 目录里积累了几十个 skill 之后，发生了什么以及我的应对之策。

为什么突然要管理 skill

不少其他作者说要管理 skill，是为了防治上下文腐败。他们安装了太多的 skill，以致于在决定召回用哪个 skill 时，出现打架冲突、召回准确率下降，以及影响正文内容表现的事。

我这边装的不多，没遇到过 skill 失灵的情况。更多遇到的是如标题所言的，在多个工作工具来回切换时，skill 咋整的问题。

典型情况就是 skill 没有全局安装，换了一个 agent 就看不到，要重装一遍。比如我在 Claude Code 里装了一个 grill-me skill（动手前让 AI 先把方案问透的技巧），用着顺手，切到 Codex 想用的时候发现它没挂在 Codex，需要重装。

这种情形本质上其实是：Claude Code、Codex、Cursor 现在都支持 skill，但各家"支持"不等于"保持同步"。每个 agent 有自己的 skill 目录、自己的 discovery 规则。你在一个地方改了 skill，默认不会同步到其他 agent 下面。

Skill 从"效率工具"变成了"需要跨工具治理的资产"，是这篇文章要讨论的。

快速回顾：Skill vs Prompt vs MCP

首先我们快速回顾下什么是 skill，以及之前的相似概念：Prompt、MCP。

Skill 不是 prompt 模板的简单升级。核心区别在"渐进式披露"：skill 是按需加载的，agent 判断当前任务需要某个 skill 才会去读；而 system prompt 是开局就全塞进 context，不管用不用得上都占着窗口。当你有几十个 skill 的时候，这个差异决定了 context 会否被无关信息稀释。

总的来说：Prompt 是一次性指令（用完即弃），MCP 管连接（能够得到外部工具和数据），Skill 管知识（知道该怎么用、遵守什么规范）。

单 Agent 下：Skill 怎么写算好

虽然当下，大家用 skill 都像安装软件一样，看到有人推荐效果好就安装了。再不济，也是让大模型直接生成，基本不会有人头铁自己写。但了解设计规范，能够帮我们识别优质 skill 和改进效果不佳的 skill，也是 AI 时代不可或缺的能力。

一个 skill 只做一件事。 这点和写代码的单职责原则完全一样。举个例子，我的 ref-options-strategies skill 只负责"有哪些期权策略、构成是什么、盈亏怎么算"，而"当前 IV 环境该买还是该卖、止盈止损怎么设"是另一个 skill（book-options）的事。两者在 description 里写清楚分工边界，agent 自己就能分流。

Description 要写得"push"一点。 如果 description 太保守，agent 在判断"要不要加载这个 skill"的时候会 under-trigger。我的 content-matrix skill 把"选题"“不知道写什么"“一鱼多吃"“内容复用"“还能写什么"“延伸方向"这些触发词全列进了 description，让 agent 在用户说出相关意图时能主动命中。但 SKILL.md 正文要克制，别什么都往里塞。

从结果出发，多写多调。 没有一步到位的 skill。我的 content-matrix 从最初"一坨规则"收敛到现在的"3x3 矩阵定位 + 延伸方向"结构，经历了好几轮迭代。ref-options-strategies 从一开始试图在一个文件里覆盖 58 个策略，到后来拆成"决策矩阵 + references 卡片 + 盈亏计算脚本"三层。写得好不好，从结果看：agent 能不能稳定触发、输出是否符合预期。

效果不满意的时候，回头把 Anthropic 和 Claude 的官方 skill 编写指南再多读读。上面这些也不是我自己想出来的，也是看他们官方说明文档提倡，然后应用发现"哎效果确实不错”。

跨 Agent 的 Skills 管理

问题定义

Claude Code 的 ~/.claude/skills/、Codex 的 ~/.codex/skills/、Cursor 的 ~/.cursor/skills/，三家都原生支持 skill 目录，放进去就能识别。问题是"怎么让改动同步下发、怎么避免挂载失败”。

回到开头那个场景：我的问题不是 skill 失灵，是重复安装。根因在于，三家 agent 各有自己的路径，并不倾向于做大统一中间仓库，也不会去读别人的路径。若无额外配置，默认情况下在 Claude Code 里更新的 skill 的 description，Codex 和 Cursor 里并不会生效。

市面上三条路线

为了搞清楚大家都怎么做的，我还在 V 站发了帖子咨询其他大佬。调研下来，目前社区里大致有三种做法：

路线 A：符号链接 路线 B：GUI 管理器 路线 C：单一源 + 薄适配
核心思路 一个 repo 存 skill 源文件，ln -s 软链到各 agent 目录 桌面应用，全局/项目双层作用域，批量操作 不追求自动同步，每个 agent 一层薄适配器
改一次同步 改源文件，全 agent 立刻生效 在 GUI 里操作，工具自动分发 源文件改完，适配器按需手动更新
优点 轻量，开发者友好，零依赖 非命令行用户友好，可视化管理 承认各 agent 差异，不强求统一
缺点 没有 GUI，没有版本管理界面 引入额外工具依赖 同步仍需人工介入
适合谁 重度终端用户 偏好图形界面的用户 对 agent 差异敏感的团队

路线 C 认为不同 agent 的 discovery 规则本来就不一样，试图完全自动同步反而危险。但对于个人用户来说，我认为路线 A 的投入产出比最高。

我自己的方案

我目前用的是路线 A 为主，路线 C 的理念做补充。

路线 A 体现在共享层。 我有两个 skill 源仓库（git 管理），一个是读书/管理类（27 个 skill），另一个是量化/金融类（5 个 skill）。这 32 个 skill 通过 ln -s 软链到 ~/.agents/skills/。这个目录是跨 agent 的共享约定，Claude Code、Codex、Cursor 三家都会读取，改一次源文件全 agent 生效。各家 agent 默认安装 skill 时走的是自己的路径（~/.claude/、~/.codex/、~/.cursor/），但只要你手动放到 ~/.agents/，就不需要再给每家单独挂一份。

路线 C 体现在专属层。 不是所有 skill 都应该同步。Cursor 专攻写作场景（content-matrix、review-zh-blog 等），Codex 专攻量化回测（quant-trading 等），Claude Code 相对全能。这些 skill 只在对应 agent 下才有意义，硬同步到其他 agent 反而增加 discovery 时的噪音。这就是路线 C 说的"承认差异，不强求统一”。此外，Cursor 的 Figma、Notion、Stripe 插件自带 skill，由插件系统自动管理，不额外手动介入。

总量：共享 32 个 + 各 agent 专属约 20 个 + 插件自带若干，整体 60+。

一个容易混淆的点：共享目录不等于版本管理。 ~/.agents/skills/ 解决的是分发，让所有 agent 发现同一批 skill。但分发和版本管理是两码事。我的 book-skills 仓库是 git 管理的，有提交历史，可以做分支。skill 源仓库管"有没有版本记录”，~/.agents/ 管"谁能看到”，两者解决的不是同一层问题。

实际遇到的问题： 目前这种方式还是没法规避换设备的场景，比如切到服务器上，本地的 symlink 全部失效。不过这个场景在我这边出现不多，仅涉及模型和数据任务需要在服务器紧急 debug，手动同步对应 skill 即可。另外，skill被调用多少次这种观测性指标，目前只能通过少数第三方工具实现。若想要原生排除用得少的、过时的skill，目前还做不到。

未来可能的问题：Skill Rot 与 Context Rot

单个 skill 写得好，不等于多个 skill 一起用也好。有人把这也归类为"context rot"。

有论点认为，生产环境里 agent 往往同时加载 5-15 个 skill，单独测试没问题的 skill 叠加起来，会造成 context 被稀释、准确率下降。“臃肿的 skill 文件正在制造它要解决的问题”。

我目前 60+ 个 skill 同时挂着，ref-options-strategies、content-matrix、review-zh-blog、grill-me 这些职责完全不同的 skill 并存，没遇到过互相打架或触发混乱的情况。

为什么？我猜有几个原因。

一是我的 skill 各自职责足够单一，description 的区分度够高，“期权策略"和"内容矩阵"和"博客审阅"之间几乎不存在歧义，agent 不会搞混。

二是渐进式披露机制本身在起作用，agent 不会把 60 个 skill 的内容全塞进 context，只在判断需要时才加载。三是也许我还没碰到真正的边界，毕竟我的 skill 数量在个人用户里算多的，但离有人做到 345 个的规模还差得远。

但这不代表 context rot 不是一个真问题。如果 skill 扩展了、写得臃肿、description 重叠度高、或者同一个 agent 下堆了太多模糊的指令，完全有可能错误触发或者不触发。

Skill 是终极解决方案吗

目前来看，大多数讨论的结论是"skill + MCP + subagent 三不可缺”，这是正确的和稀泥。

Skill 解决的是"复用"问题，让你把反复要交代的知识固化下来，agent 按需取用。我在上一篇里提到的 grill-me skill 就是一个例子。

但 skill 不解决"多个能力叠加后的上下文治理"问题。当你的 skill 规模从两位数增长到三位数，谁先加载、谁的指令优先级更高、两个 skill 的 description 重叠时 agent 怎么选，这些问题我现在还未看到成熟解决方案。

往前看，skill 生态可能会往类似 python 管理包的方向走：版本管理、依赖声明、发布与安装分离。现在已经有人在做 skill 聚合平台，也有人做 GUI 管理器，使用量都不小了。

目前对个人用户来说，路线 A（symlink + 中心仓库）是投入最小的务实选择，路线 C（“单一源 + 薄适配器”）的思路可以作为补充。

回到开头

开头说的那个场景，换一个 agent 就要重装 skill，用 symlink 到 agent 目录下基本解决了。32 个共享 skill 改一次源文件，Claude Code 和通用 agent 目录同步生效。剩下的 agent 专属 skill，接受它们分散在各自目录里，不强求统一。

如果你单纯想省事，让各个工具把 skill 都统一安装到 ~/.agents/，也行。

参考资料

Skill 概念与基础

Skill 编写实践

跨 Agent 管理

Context Rot 与 Skill 腐败

Skill 生态展望

关于作者