技能包：Agent 的能力开始像软件包

01熟悉的场景THE FAMILIAR SCENE

打开技术社区，满屏都是"给你的 Agent 装上这个技能""skills 合集，一键增强"。装了几个，有的确实好用，有的装完 Agent 反而更笨了。于是困惑：这东西该跟吗？该学吗？还是又一波两个月就过气的热闹？

判断一个新东西值不值得学，有个省力的办法：看它是不是某个老故事的重演。技能包恰好是——它重演的是软件史上"库和包管理器"的故事。看懂了这一层，跟或不跟都不慌。

F-006 讲过：Agent 的能力是清单给的——给什么工具，它才能干什么。但那张清单一直有个门槛：每样工具都要有人写、有人接。能力的供给，卡在开发者手里。

技能包（skills）把这件事往前推了一步：把"怎么干一类活"整体打包——一份写给模型看的说明书（什么时候用、按什么步骤、注意什么），加上可选的脚本和工具。Agent 接到相关任务时，把这个包装进工作台（F-011 的词），照着手册干活。

变化的本质是分发方式：能力从"接线"变成了"装包"——可分发、可安装、可复用，像极了软件包。公开可见的动向里，围绕技能包的规范和框架最近密集出现；哪一套会成为通行标准还要观察，但"能力被打包分发"这个方向，和当年库、包管理器的出现是同一个故事结构——一旦活可以打包，生态就会围着包长起来。

拆开一个技能包，通常是三层：

说明书。写给模型看的操作手册：何时触发、怎么做、边界在哪。它本质上是预先写好的上下文——F-011 讲的"材料"，只是按需装载。

工具。可执行的脚本或程序，模型照说明书调用。这就是 F-006 讲的"手"，只是跟着手册成套地来。

依赖声明。这个包需要什么环境、什么权限。最容易被忽略，恰恰最该先看——理由到第 04 节。

三层拆清，它和相邻概念的关系就顺了：提示词是你手写的指令，技能包是预先写好的成套指令加工具；MCP 管的是"插座"（工具怎么统一接入），技能包管的是"活法"（一类活怎么成套地干）。插座和活法不互斥，一个包可以经由插座用工具。

既然是包，软件包的老教训直接适用，一条都不用发明：

装之前读一遍。说明书虽然是写给模型的，你也读得懂。不读就装，等于让一段陌生文本指挥你的 Agent——F-012 讲过网络墙管的两个方向里，有一个正是"外面的指令被塞进来"，而不经审查的技能包，是自己开门把指令请进来。

最小安装。每个包都占工作台的地方（F-011：用不到的材料在占地方、在稀释、在制造打架的机会）。装十个技能的 Agent，常常不如装两个的利索。跟软件依赖一样：装得越多，坏得越怪。

看来源和权限。包有作者，作者有立场；依赖声明里要的权限，就是它将来能干的事。软件供应链的全部戒心——来路不明的包、要权过大的包、久无人维护的包——搬过来一条不落。

纪律之外，还有一个给学习者的机会：技能包把"造能力"的门槛降到了写作层——写一个好技能包，难点不在代码，在把一类活的决策写清楚：什么时候干、按什么步骤、哪里会翻车。这正是 F-008 说的决策层——把自己反复干的一类活写成包，是把隐性决策显式化的绝佳练习，受益的首先是写包的人自己。

这份底稿的坐标系都在站内：能力从清单来、插座怎么统一，见 F-006；工作台与稀释，见 F-011；装包等于在房间墙上开口，口开在哪、多大，见 F-012；边界不清的代价，见 N-006。

底稿负责把包拆开给你看；装不装、信不信，判断在笔记里。