---
url: /ai/theory/agent-skills-evolution.md
description: >-
  通用型 Skills 终将被用户无感知甚至消失，自己给别人写通用 Skills
  没有价值；未来真正值钱的，是被精打细磨过的领域知识技能包——它们会被商品化、订阅化。这是我的 Agent Skill 演进观。
---

![Agent Skill 演进观封面](https://media.xiaolin.fun/docs/img-agent-skills-evolution/infographic-01.png)

从 2025 年 10 月 Anthropic 正式发布 Claude Skills 算起，到现在也就大半年时间，Agent Skills 已经成了 AI 圈最热的关键词。打开小红书、抖音，铺天盖地的不是“必备 Skills”就是“超好用的 Skills”，再不然就是“宝藏 Skills”；企业端更夸张，腾讯 WorkBuddy、QClaw 以及不少大厂内部都掀起了“Skills 运动”，直接给员工下 KPI 让人提交 Skills。这股热潮来得快，消耗得也快，最近甚至开始有点退烧，但我越看越觉得，很多讨论的出发点是反的。

这里想系统聊一下我的看法：**通用型 Skills 终将被用户无感知，自己给别人写通用 Skills 没多大价值，未来真正值钱的，是被精打细磨过的领域知识技能包。**

## 先给 Skill 分个类

谈演进趋势之前，得先把 Agent Skills 分清楚。在我看来，Skills 应该明确地分成三类，各自的演化路径完全不同：

![Skill 的三分类](https://media.xiaolin.fun/docs/img-agent-skills-evolution/infographic-02.png)

### 一、通用工具型 Skills（工具类）

最常见的一类，也是社区里写得最多的一类。它们要么是某个 CLI 工具的配套 Skills（教 Agent 怎么用这个工具），要么是把开放世界的通用知识沉淀成可复用的指导包。典型例子：

* `commit-message-writer`：根据 git diff 生成 commit message。
* `pr-reviewer`：根据 diff 做 PR 审阅。
* `readme-generator`：给项目生成 README。
* `gh-cli-skill`：把 GitHub CLI（`gh`）的各种子命令、参数、典型场景封装成 Skill，让 Agent 知道什么时候该用 `gh pr create`、什么时候该用 `gh issue close`。
* `lark-cli-skill`：把飞书/Lark CLI 的命令体系封装成 Skill，让 Agent 能熟练处理消息、文档、日程、审批等通用协作场景。

这一类 Skill 的本质是把通用工具链 / 开放知识和大模型接起来。它们的共同特征：

* 不依赖业务上下文。
* 任何一个开发者拿过去都能直接用。
* 写起来最容易，也最容易撞车。

### 二、领域专家型 Skills（业务专家多年的经验，精打细磨）

这一类是真正的硬通货，但社区里讨论得最少。典型例子：

* 跨境电商的 Listing 写手，知道怎么写标题能过平台审核、关键词怎么布局能拿自然流量。
* 律所的合同审阅，知道哪些条款是高风险、哪些表述有合规隐患。
* 医生的病历摘要，知道哪些信息该留、哪些该隐、术语怎么规范化。
* SRE 的故障复盘，知道一份合格的复盘文档应该有哪些字段、哪些归因、哪些改进项是必须有的。

这类 Skill 的共同特征：

* 强依赖行业 know-how，不是模型能凭空生成的。
* 写得越细，越值钱；写得越粗糙，越没价值。
* 复用频率极高，因为同行业的同类任务会重复出现。
* 质量方差极大，不固化就一定会漂。

### 三、个人专属 Skills（私有记忆 + 个人习惯）

最后一类是只服务于一个人的 Skill。典型例子：

* 把自己的工作记录、个人偏好、常用链接、踩过的坑沉淀成 Skill。
* 给自己定制的写作风格、汇报模板、思考框架。
* 把零散的 dotfiles、shell 历史、IDE 配置背后的 why 沉淀下来。

这一类 Skill 的特征：

* 别人拿过去基本用不上。
* 但对本人来说价值极大，相当于把个人经验外置成了一个可以随时调用的协作者。
* 写起来最私人，也最难被商品化。

## 一个反共识的判断：通用型 Skills 终将无感知

社区里很多人在教如何写一个通用 Skill，我反而认为：

> **用户对通用型 Skills 应该是无感知或轻感知的，自己给别人写通用型 Skills 可能没有多大价值。**

为什么这么说？因为通用工具型 Skills 注定会走一条被集成、被吞并的路。

第一，通用工具本身就不稀缺。任何人基于公开规范，几天就能写出一个 `commit-message-writer`。这类 Skill 的护城河几乎为零，今天能写出来，明天别人也能写出来。

第二，工具类 Skills 一定会被官方/平台收编。当某个 Skill 真的被大规模使用，它的下一个版本一定是直接集成进 CLI/IDE/Agent Runtime 本身，而不是继续作为 Skill 存在。回顾工具发展史，所有插件化的东西，最终都会被原生化。

更进一步，**官方工具配套 Skills 应该由官方自己维护、用户无感使用**。以 `gh-cli-skill` 为例：用户根本不需要感知它的存在——只要基于 AI Agent 调用 `gh` 命令，Skill 就会自动从 GitHub 官方拉取最新版本。如果反过来让用户自己去搜、自己装、自己同步，那才是反人性的设计。同理，`lark-cli-skill` 应当内置在飞书/Lark 官方客户端里，随官方升级自动迭代——用户不知道原来还有个 `lark-cli-skill` 才是最理想的状态。

第三，架构上通用 Skills 注定走向集中托管。Skill 的本质就是一堆 Markdown + 脚本，每个用户本地仓库都在重复存放完全相同的内容。理想的做法是：纯提示词（Markdown）部分内炼进 Agent Runtime 或 LLM Server，由服务端统一托管、按需下发；只有那些必须在本地执行、组装本地上下文的脚本才留在客户端。在当前 Agent 架构下，客户端是唯一的折中点（脚本必须本地跑、上下文必须本地组装），但服务端化是必然趋势——没人愿意在 100 台机器上维护 100 份一模一样的 `commit-message-writer`。

第四，通用 Skills 缺少评价机制，未来一定会长出 “Skills大众点评” 这类东西。官方工具配套 Skills 由官方背书，权威性没问题；但用户想用一个特定功能的 Skill 时，社区里动辄几十个同类实现，怎么选？看 Star？看下载量？这里存在一个明显的正反馈悖论——使用量越高的 Skill 越被推荐，越被推荐使用量越高。早期 GitHub 上的热门 Skill 就是这么卷出来的。没有真实使用效果、采纳率、失败率的评价体系，用户就只能盲选。**未来一定会衍生出 Agent 世界的大众点评或高德必吃榜——基于真实调用数据为 Skills 评分、定级、进出。**

举个具体的例子：早期 Git 客户端有大量第三方插件提供 diff 高亮、blame 视图，现在这些功能都已经默认内建到 Git、IDE、SourceTree 里面了。**通用 Skills 会走一模一样的路线：从插件 → 默认能力 → 用户根本不知道它的存在。**

所以，写通用 Skills 给别人用，注定是一份看上去热闹、实际上没沉淀的工作。

## 通用型 Skills 怎样变得无感知：三种技术形态

无感知不是一个口号，从软件工程的设计思想看，它或许有明确的技术形态。

### 1. 物理 Skills 层（用户可感知）

在用户的本地工作目录或家目录下，有一类 Skills 是物理存在、用户可感知的——比如 `.claude/skills`、`~/.claude/skills`、`.agents/skills`、`~/.agents/skills` 这些约定目录下的 Skills。它们的典型来源：

* 官方工具配套 Skills（如 `gh-cli-skill`、`lark-cli-skill`），随工具升级而更新。
* 用户主动安装 / 拉取的第三方 Skills，比如从 GitHub Awesome List 或企业内部仓库克隆下来的。
* 项目级 Skills，放在仓库 `.claude/skills` 下随代码一起版本管理。

这一层 Skills 用户是看得见、摸得着的——可能是 clone 下来的文件夹、可能是 `npm install -g` 装的，也可能是 IDE/Agent 启动时自动加载的。热路径上 Agent 优先在这一层匹配，命中就直接用。

### 2. 缓存 Skills 层（用户无感知）

物理 Skills 不可能应有尽有——它本质上是用户或项目愿意装的那一份。**真正做到应有尽有的，是 Agent 在后台维护的缓存层 Skills**：

```
Skill 知识层
├── 远端源：GitHub Awesome List、官方文档、Stack Overflow 高赞答案
├── 本地缓存：.cache/skills/<task>/<source>.<hash>
└── 运行时：Agent 按需加载、按需淘汰
```

这一层用户完全无感知：

* 冷启动：第一次遇到某类任务时联网搜，结果落盘到 `.cache/skills/`。
* 热路径：物理层未命中时，自动到缓存层匹配；命中直接读本地，零网络开销。

#### 两层共享同一套生命周期管理机制

物理层和缓存层虽然分工不同，但**必须受同一套生命周期管理机制约束**——周期更新保证新鲜度、可清理机制防止膨胀。Agent 后台统一调度这两件事，对用户都是无感的。

* **周期更新**
  * 物理层：官方工具配套 Skills（`gh-cli-skill`、`lark-cli-skill`）随官方升级自动拉取最新版；用户主动安装的第三方 Skills 支持 `skill update` 一键同步上游。
  * 缓存层：按天/周周期性地去远端检索是否存在更新、采纳率更高、被验证更好的版本，若发现则异步替换本地。

* **可清理机制**
  * 物理层：项目级 Skills 随仓库清理；用户级 Skills 提供 `uninstall` / `purge` 子命令；长期未被调用、且优先级队列排末位的 Skills 进入待清理队列，到期自动归档或删除。
  * 缓存层：长期未命中、长期未被调用、且优先级队列排末位的缓存条目自动淘汰，本地不会被爆。

**关键判断**：当物理层 + 缓存层都够用时，**绝不能因为够用就直接放弃去了解业界有没有更好的实践**——否则会错过最先进生产力的迭代。一个 80 分的旧 Skill 用三年，远不如一个 95 分的新 Skill 用三个月。

两层的意义是：**物理层保显性可管理（用户能装、能删、能 review），缓存层保隐性全覆盖（让用户即使不装也能用上业界最新）**。分层决定 Skills 放在哪，生命周期决定 Skills 怎么活——这两件事必须作为整体来管理，否则任何一层单兵突进都会让另一层失效。

![物理层与缓存层双层管理](https://media.xiaolin.fun/docs/img-agent-skills-evolution/infographic-04.png)

### 3. 按使用频率与采纳度划分优先级（优先队列）

通用 Skills 数量会爆炸式增长，必须引入优先级机制。设想一个类似优先队列的结构：

| 维度 | 含义 | 权重建议 |
|------|------|----------|
| 调用频率 | Skill 在最近 N 天被调用了几次 | 高 |
| 用户采纳率 | Agent 给出的建议里，用户实际采用了多少 | 高 |
| 失败率 | 使用后被回滚/重写的比例 | 负向 |
| 来源权威度 | GitHub stars、官方文档、社区评分 | 中 |

调用频繁 + 采纳率高 + 失败率低的 Skill 自动升权，被 Agent 默认启用；反之则降权，进入淘汰队列。

这个机制的本质是：让被验证过的最佳实践自动浮上来，让过时/无效的 Skill 自动沉下去。用户无需手动管理 Skills，Agent 自己会择优。

#### 缓存晋升：高频 Skills 可晋级为物理 Skills

优先级队列不仅决定哪些 Skill 被启用，还决定它们住在哪里。

**当一个缓存层 Skill 的调用频率和价值被验证到一定程度时，Agent 可以自动把它晋升为物理层 Skill，纳入 Git 管理**：

* 晋升路径：`.cache/skills/<task>/` → `.agents/skills/<task>/`（物理目录） → 写入 Git。
* 晋升触发条件：调用频率超过阈值（如 30 天内被调用 N 次） + 用户采纳率 > 阈值 + 失败率为 0。
* 晋升后的好处：
  * 跨 workspace 迁移：新机器 `git pull` 一下就把自己用顺手的 Skills 一起带过来。
  * 跨设备同步：物理层 Skills 跟着 Git 走，缓存层 Skills 不入库。
  * 可审计、可 review：晋升的 Skill 变成显式资产，使用者能明确感知我在用这个。

反过来也成立：物理层 Skills 长期不被调用、采纳率持续走低时，会被降级回缓存层，腾出 Git 空间，避免个人 Skills 列表被一堆过时内容堆满。

完整的工作目录结构：

```
~/workspaces/my-project/
├── .git/
└── .agents/
    ├── skills/         # 物理 Skills（含晋升来的，建议入 git）
    │   ├── commit-helper/    # 来自缓存层晋升
    │   └── lark-helper/      # 来自缓存层晋升
    └── memory/         # 个人专属记忆（建议进 git）
        ├── preferences.md
        ├── past-decisions.md
        └── style.md
```

通用 Skills 缓存不一定要入库（随用随拉），但**物理层 Skills + 个人专属记忆一定要入库**。换台电脑、换一个 workspace，pull 一下代码就把自己用顺手的 Skills 一起拉过来了。

## 自媒体越宣传，越说明通用 Skills 不该被关注

回头看最近各种 Skill 入门教程、十大必装 Skills 这类自媒体内容，它们越火，恰恰越说明通用 Skills 的命运：

* 它们的内容很轻——几分钟就能讲完一个 Skill；
* 它们的读者很广——面向所有 AI 用户；
* 它们的变现路径很短——卖课、卖社群、接广告。

但也正因为如此，它们注定是通用型内容。

> 如果是工具型的、开箱即用的通用 Skills，普罗大众根本无需关注。

真正需要关注的，是：

* **领域专家型 Skills**——那才是需要自己长期沉淀、可以拿出来卖的资产。
* **个人专属 Skills**——那才是只服务于自己、跟随自己一辈子的数字记忆。

通用 Skills 的最佳归宿，就是默默躺在本地缓存里、按使用频率排队、被 Agent 自动择优调用。**当一个 Skill 真正做到这一点，它的作者应该感到骄傲——因为它已经成功到让用户忘记了它的存在。**

***

## 真正值钱的是：领域专家型 Skills

![领域专家型 Skills 的四大稀缺性](https://media.xiaolin.fun/docs/img-agent-skills-evolution/infographic-05.png)

与通用工具型 Skills 形成鲜明对比的是，**领域专家型 Skills 才是未来真正能产生价值、甚至被商品化的资产**。

它的价值来自四个稀缺性：

1. 经验稀缺：领域专家多年的实战经验，是模型无法凭空生成的。
2. 口径稀缺：每个行业都有自己的黑话、合规要求、禁区表达，这些只能在实战中沉淀。
3. 复用稀缺：同行业、同场景的任务会高频重复，每一次复用都摊薄了 Skill 的边际成本。
4. 质量稀缺：不固化就一定会漂，固化下来就能稳定输出。

更关键的是，**领域专家型 Skills 是可以对外销售的**。

> 未来 SKILL 会变成领域知识技能包，像 App Store 一样被上架、被订阅、被评分。

一个跨境电商运营多年的老板，把自己的 Listing 写作经验封装成 Skill，卖给其他中小卖家；
一个资深律师，把合同审阅经验封装成 Skill，按调用次数收费；
一个资深 SRE，把故障复盘与应急响应经验封装成 Skill，企业按席位订阅。

这不是科幻，这是 Skill 商品化的必然路径。原因很简单：

* 通用能力会被模型原生吸收，免费。
* 领域经验无法被模型原生吸收，必须由专家持续供给并维护。
* 凡是必须由专家持续供给并维护的东西，最终都会商品化。

回到个人层面，这也是为什么我前面说：

> **自己给别人写通用型 Skills 没有多大价值，而自己沉淀领域专家型 Skills，是真正能积累复利的事情。**

## 个人专属 Skills：另一条被低估的路

最后想单独说一下个人专属 Skills。社区里很少有人讨论这一类，但我认为它被严重低估了——**它才是每个用户最需要关注的，是自我提效的关键**。

它的价值不在于被复用，而在于把个人经验外置成一个 24 小时在线的协作者。几个具体场景：

* **写作**：把个人的思考框架、段落结构、标题套路沉淀成 Skill，让 Agent 写出来的初稿直接就是我会写的样子，而不是 ChatGPT 的样子。
* **代码**：把团队的代码风格、命名规范、Review 偏好沉淀成 Skill，Agent 生成的代码直接过 Code Review。
* **决策**：把当遇到 X 情况，我通常会先做 Y，再做 Z这种决策习惯沉淀下来，让 Agent 在关键时刻给出和自己判断一致的建议。

这些 Skill 别人拿不走，也不指望别人拿走，但它把一个人的经验价值从每天 8 小时扩展到了每天 24 小时。

#### 自我蒸馏：一种戏谑，也是一种现实

网上流行一种说法：**把自己的 Skills 蒸馏给 Agent，把自己也蒸馏了，就可以在被裁之后，以数字生命的形态继续在公司里工作**。

这虽然是段子，但背后的逻辑很现实——个人专属 Skills 才是自我提效的关键。一个员工如果连自己的 Skills 都没沉淀下来，谈何提效？谈何复用？谈何议价？

但要不要把自己蒸馏成可被替代的形态，这事儿得看立场。我自己有两个视角：

* **视角一（企业视角）**：员工是螺丝钉，少了谁公司都能运转。所谓的 Skills 运动看起来是赋能，**但本质上是给工具配了个人，而不是给人配了个工具**——企业想要的不是一个更强的员工，而是一个可被无限复制的工具人。
* **视角二（个体视角）**：每个员工都是独一无二的，特性、个性、工作模式、思考方式都不一样。
  * 从个体时间维度看：一个人在 25 岁、35 岁、45 岁的 Skills 截然不同；甚至同一个人每天的 Skills 都在变化——今天的状态和明天的状态会差很多。
  * 从群体维度看：允许个体的差异性和个性，才是给创新、进步留的口子；把所有员工都炼化成标准件，创新也就死了。

我的结论很明确：既不看好炼化员工的观点——那是把人当工具；更不认可把个人专属 Skills 强塞给别人用的观点——那不是分享，是强人所难，是把自己用顺手的私货强行灌输给别人，堪比老一辈把自己的人生经验 Skills 强加到晚辈身上——谁受得了？

**个人专属 Skills 的最佳归宿，就是留给自己、跟随自己、随自己一起进化。**

## 三类 Skills 的演进方向

最后用一张表收个尾，三类 Skills 的演进方向完全不同：

| 类别 | 演进方向 | 是否商品化 | 写给别人的价值 |
|------|----------|------------|----------------|
| 通用工具型 | 被平台收编 → 用户无感知 | 几乎不可 | 低 |
| 领域专家型 | 上架成领域知识技能包 → 被订阅 | 可，且应被商品化 | 高（最值得做） |
| 个人专属型 | 外置成个人协作者 → 持续进化 | 不可，但值得长期沉淀 | 无，但自己用最值 |

如果要给一个行动建议，那就是：

* **别再花时间写通用型 Skills 给别人了**，那份作者署名的虚荣收益，很快会被模型原生吸收掉。
* **把时间花在领域经验沉淀上**，把多年积累的 know-how、口径、禁区、验收标准封装成可复用、可售卖、可订阅的领域知识技能包。
* **顺手把自己的个人习惯也沉淀成 Skill**，这件事不性感，但它是少数能跟自己一辈子、且越用越值钱的数字资产。

**未来的 Agent 生态，最稀缺的从来不是 Skill 的数量，而是 Skill 背后那一份被精打细磨过的领域经验。**

***

## 备选标题

> 以下为已弃用的旧标题，仅作留档，不再使用。

* Agent Skills 演进趋势：通用无感、领域值钱、个人专属
* 别再给别人写通用 Skill 了：未来值钱的是领域知识技能包
* Agent Skills 三分类：工具类、领域专家类、个人专属类
* Skill 写给谁？写给别人的通用 Skill 没价值，写给自己的最值钱
* 当 Skill 变成商品：领域专家才是 Agent 时代真正的赢家