Agent 到底怎么学会「做事」？
记忆系统解释了 Agent 怎么记住"你是谁"，知识编译解释了怎么组织"你知道什么"，协议层解释了 Agent 之间怎么对话。但"做事"这件事本身，一直没有一个干净的解释。
答案是 Skills，也就是程序性记忆。
我不想写"怎么用 Skill"的教程，想说清楚的是另一件事：Skill 为什么重要。把它拆到最里面，你会发现所有线索都指向同一个词——压缩。
没有 Skill 的 Agent：每次都从零摸索
看一个真实场景。
一个日常任务（给客户写一篇公众号文章并发布到官网），在 Agent 没有积累任何相关 Skill 时，平均需要 25 次工具调用。一个月之后，同样的任务降到了 8 到 10 次。
模型没变，工具没变，人也没变。变的是它做这件事的套路有多固定。
没有 Skill 时，Agent 每次都在重新摸索：
用户说「写一篇关于某产品的文章」
→ 我该用什么工具？先搜一下有没有模板
→ 有没有类似的文章可以参考？看看历史文章列表
→ 内容结构怎么定？先列个大纲
→ 配图用哪个生成器？
→ 发布到哪个 API？参数是什么？
→ 草稿创建成功了吗？检查一下
→ 发布成功了吗？再确认一下每一步都是一次选择，每次选择都有好几条岔路。整个过程像在一座没有地图的城市里找路，绕来绕去才到目的地。
有 Skill 之后：
用户说「写一篇关于某产品的文章」
→ 加载对应 Skill
→ 按步骤执行：确认主题 → 抓素材 → 生成内容 → 上传图片 → 创建草稿 → 发布
→ 完成岔路被砍掉了，只剩一条主干道。Agent 不再需要想"下一步该做什么"，它只需要照着做。
这不是模型变聪明了，是它不用再每次重新找路了。
为什么本质是压缩
把一个原本要 25 步才能说清楚的过程，变成一份 9 步的固定流程——这件事本身就是压缩。同样的结果，更短的描述。压缩比大概 2.78 倍，这就是这个 Skill 实打实的价值。
但它和 zip、gzip 那种文件压缩有个关键区别：文件压缩要求一字不差地还原，Skill 不要求。被 Skill 封装的行为，不需要和历史上某一次的执行路径完全一样，它只要在结果上完成同样的目标就行。
换句话说，Skill 的压缩允许"走样"。而恰到好处的走样，正是泛化——它记住的不是"上次我具体点了哪几个按钮"，而是"这类事情大概怎么办"。前者是死记一条路，后者是学会了认路。
这也解释了一件事：为什么太简略和太详细的 Skill 都不好。
- 太简略：Skill 本身很短，但它管不到的特例一大堆，每次还得现场临时发挥，等于没省事。
- 太详细：几乎什么都写死了，但又臃肿又死板，现实稍微变一点就对不上。
- 最好的那种：把常见情况讲得干脆利落，又给少数特例留了余地。
一句话：在能把事办成的前提下，尽量短。
具体到怎么写，可以借用视频压缩的思路：
- 必做步骤 = 关键帧，把核心流程完整记下来
- 差异部分 = 只记和默认路径不一样的地方，不重复啰嗦
剩下的就是不断校准。我的 Agent 每 15 次工具调用会做一次自检，看看现在的 Skill 库有没有"反复遇到、却还没被写进去的情况"，再决定是补一笔，还是干脆新建一个 Skill。
学一个 Skill，和大脑学骑车是一回事
这套机制和人脑学技能几乎一模一样。
学骑自行车、弹钢琴、写代码，初学时每一个动作都要刻意去想，脑子转得很累；熟练之后这些动作就"沉"下去了，几乎不占注意力，你可以边骑车边聊天。神经科学的说法是，技能从需要主动控制的前额叶，转移到了负责自动化的小脑和基底神经节。
Agent 的 Skill 做的是同一件事：把高频的动作，从"每次都要模型现场推理"，下沉成"直接调用的现成程序"。
没有 Skill，模型每次都得重新想一遍；有了 Skill，常做的事变成肌肉记忆。
省下来的不是一点点。每一次"重新想"都要烧 token、花时间，而照着现成流程走几乎不花脑子。这就是为什么同样的任务，练熟之后能从 25 步降到 9 步。
行业怎么做
不是只有我在想这个问题。Anthropic、OpenAI 和独立开发者社区，各自走了不同的路线，但解决的是同一件事：别让 Agent 每次都从零开始。
Anthropic 的路线是"存起来重复用"。 Prompt Caching 把长长的系统提示、指令集缓存住，后续请求直接引用，不用每次重新发一遍。更高一层，MCP（Model Context Protocol）定义了一套开放规范，让工具和能力可以被统一声明、跨平台复用。
OpenAI 的路线是"装箱分发"。 GPTs 把指令、知识文件、工具动作打包成一个可发布的单元，相当于把某个领域的做事方式压成一个能下载、能引用的包。
我自己的实践是"编成现成程序"。 SKILL.md 是一份纯 Markdown 的流程文件，Agent 按需加载、按需执行。它卡在中间：比 Prompt Caching 更有结构，比 GPTs 更轻、更开放。
| 维度 | Anthropic | OpenAI | 本地 Skill 文件 |
|---|---|---|---|
| 核心做法 | 缓存复用 | 打包分发 | 编成程序 |
| 规范格式 | MCP（开放） | OpenAPI + GPT Store | SKILL.md + YAML |
三条路在不同的层面解决同一个问题，而且完全可以并存——缓存解决"重复传输"，打包解决"怎么分发"，编译解决"怎么把一套做法精确封装好"。
好的 Skill 长什么样
理论讲完，讲实操。一个好用的 Skill，大致满足五条标准。
触发条件要精确
触发条件是 Skill 的"门牌号"，决定 Agent 在什么情况下会用它。写得越准，匹配越快。
❌ "用于查询数据"
✅ "当用户查询 ERP/CRM 的客户、项目、销售、采购、库存数据时使用此 skill"内容要分层
别把所有东西塞进一个文件。成熟的做法是入口文件保持精简（8 到 15k 字符），细节拆到子文档里，用到再加载。
skill-name/
├── SKILL.md # 入口：触发条件、路由规则、核心流程
├── references/ # 详细参考文档（按模块拆分）
├── scripts/ # 可执行脚本
└── assets/ # 静态资源步骤要明确
把任务拆成一步步确定的动作，模型不用在"我现在该干嘛"上反复纠结。
坑点要写下来
踩过的坑不是可有可无的附录，它是 Skill 最值钱的部分之一。比如："正文 HTML 含中文时，用文件写入方式，避免 shell heredoc 编码问题。"这种只有踩过才知道的事，直接写进去，Agent 就能绕过去。
交付要能自查
给 Agent 一份检查清单，让它每次输出前都能自己核对一遍，而不是"写完就算完"。
举个真实例子。我有一个"报告输出"的 Skill，解决的是：从对话里提炼内容，再渲染成 PDF / HTML / PPTX 等格式。它有几个点值得说：
一是先提取、再渲染。所有格式共享同一份中间数据，新增一种格式只要写一个渲染器。本质上是把"写什么"和"用什么格式输出"拆开，各管各的，互不拖累。
二是分层质检。从内容质量到视觉细节分成几层，每层都是具体可执行的规则，比如"任何情况下禁用饼图""数字列右对齐，文本列左对齐"。这些规则把 Agent 从"凭感觉生成"变成了"按规范执行"。
三是风格参数化。品牌色、Logo 作为参数传进来，不再藏在 prompt 里。不同风格的报告共享同一套渲染逻辑，只是参数不同——这又是一层压缩。
技能会迁移，这才是关键
到这里可以再往深想一步。
人能跨领域，靠的不是记住每个领域的 SOP，而是把一个领域学到的套路搬到新领域。厨师摸透了"火候"，去学烘焙时不用从零开始，因为控温这件事是相通的。
Agent 的 Skill 如果也能做到这一步，才真正有意思。
我在自己的 Skill 库里见到了这种迁移的雏形。比如"入口只做分发、具体逻辑下沉到子模块"这个套路，最早出现在业务数据查询的 Skill 里。后来报告输出、投资分析这些完全不同的 Skill，自然而然也长成了同样的结构——不是我刻意设计的，是因为这个套路本身就好用，到哪儿都适用。
再比如"先提取成统一格式、再按需渲染"，这个套路从报告输出迁到了数据分析，又迁到了内容发布。套路是跨任务的，只是具体字段不同。
当一个 Agent 的 Skill 库开始出现跨领域的套路复用，它就不只是在"记住怎么做事"，而是在"理解做事的结构"。
这有点像编程里的设计模式。Strategy、Observer、Factory 之所以有价值，不是因为它们是银弹，而是因为它们把"这类问题的本质是一样的"压缩成了一个能传播的名字。Agent 的 Skill 生态未来大概也会这样：不是每个领域都从头写一套，而是认出底层那几种通用套路，到处复用、组合。
我的思考
写完这篇，几个判断更清晰了。
Skills 不是可有可无的功能，是 Agent 的必然方向。 没有 Skills 的 Agent，就像没有长期记忆的人，每次对话都从零开始。你不会把正经的活儿交给一个永远长不大的系统。
"写 Skill"本身是门手艺。 想明白"在能办成事的前提下尽量短"之后，你自然知道什么样的 Skill 好：不是堆字数，是找那个"既简洁、又能覆盖足够多情况"的平衡点。精确触发、分层结构、明确步骤、写下坑点、能自查——这五条都是在逼近这个平衡。
能力上限不在模型参数，在压缩率。 两个 Agent 用同一个模型，有没有积累好 Skills，表现能差出一个数量级。参数竞赛正在触及天花板，但怎么把做事的套路压缩好，这件事还有巨大空间。
技能迁移才是终局。 当好的 Skill 不只能复用，还能把底层套路跨领域搬运时，Agent 生态才算真正成熟。这有点像 npm 之于 JavaScript：流通的不只是"别人写好的代码我能用"，而是"整个社区的解题套路在流通"。