给 agent 装一个技能，等于给它多一双手。问题在于，这双手不一定长在你的胳膊上。
技能市场的好处是生态，坏处也是生态：任何一个陌生人写的一段脚本，都能变成你的 agent 在你机器上的一个动作。我那套配置里收了 22 个技能包，分给四个 agent 之后，每个角色手里只有 8 到 18 个——不是装不起，是不敢装。
先看清单：谁装了哪些
技能不是平均分的，配置里写得很清楚（节选）：
{
"agents": {
"list": [
{ "id": "main", "skills": [
"feishu-doc", "feishu-drive", "feishu-perm",
"feishu-wiki", "clawhub", "github",
"skill-creator", "weather", "brainstorming",
"canvas-design", "writing-plans",
"systematic-debugging",
"using-superpowers", "webapp-testing",
"docx", "pdf", "pptx", "xlsx"
]},
{ "id": "coder", "skills": [
"feishu-doc", "feishu-drive", "feishu-perm",
"feishu-wiki", "clawhub", "github",
"skill-creator", "weather"
]}
]
}
}
主管多出来的是设计与协调类：brainstorming 负责在动手前把目标收敛成可确认的设计，writing-plans 负责拆步骤，systematic-debugging 负责按流程排查。三个下属共享的是执行类底座：飞书四件套、github、clawhub、skill-creator、weather。
这里有个文档写了但很容易看漏的语义：agents.entries.*.skills 是逐 agent 的替换，不是合并。给某个 agent 写 8 条，不是在基线上再加 8 条，而是"只剩这 8 条"。表现不是报错，而是它某天突然不会用某个工具了。
三个问题
装之前我会问三个问题，任何一个答不上来就先不装。
它要什么？ 网络出口、凭据、能写哪些目录。一个"只是查天气"的技能要求读你的主目录，这件事本身就是答案。
谁能唤起它？ 只在我明确要求时可用，还是聊天里任何一句话都可能触发？后者意味着别人发给 agent 的一段文本，也可能变成一次工具调用。
出事了怎么退？ 能不能一条命令卸干净，会不会留下后台进程、新配置文件、新凭据。
装之前：读代码，不读简介
名字和 star 数不构成任何保证。我按这个顺序看：
SKILL.md里声明的能力和权限- 真正的脚本，尤其是它拼出来的命令
- 来源与维护状态，以及有没有第三方审计结论
第三方技能市场自己也会提醒：仓库里的东西没经过审计，用之前自己看源码和权限。这句话不该只当免责声明读。
还有一类风险容易被忽略：提示注入。agent 会照它读到的内容行动，而它读到的内容可能来自一封邮件、一个网页、一份别人给的文档。技能只是把这条攻击面又扩大了一圈——它让 agent 更有能力"照做"。
装之后：必须配，必须验
我的 MEMORY.md 里存着两条硬规则，是长期记忆里最先写下来的那种：
#### Pre-installation
- Must perform risk assessments and scan skill files.
Installation is only permitted if the risk is low
and no malicious scripts are present.
#### Post-installation
- Skills must be configured and tested.
They are only retained if testing passes;
otherwise, they must be removed.
USER.md 里还有一条对应偏好：装完新技能，必须检查它需要什么配置（API Key、环境依赖）。
这条不是洁癖，是有具体形态的：飞书那套技能要 App ID、App Secret，还要在开发者后台把对应的权限勾上；少一样，调用回来的是权限或凭证错误，不是"我不会"。你看到的是 agent 说"操作失败了"，很容易怪模型笨，其实是工具没通。
所以验收方式必须是跑一次真实任务，不是"装上就算成功"。跑不通就删，不留"以后再说"——留着的技能会在某天静默失败，而你那时已经忘了它存在。
一次技能上线的固定动作
把三个问题落成可重复的流程，最后是这样五步：
- 扫。 先看
SKILL.md和脚本，确认它要什么、有没有可疑的命令拼接。这一步不过，后面不用看。 - 装。
openclaw skills完成安装（也可以从市场用npx clawhub install拉）。装完先别急着给它派活。 - 配。 该给的 API Key、环境依赖、权限范围补齐。这一步最容易被跳过，也最容易在两周后变成"它怎么又不行了"。
- 跑。 用一次真实任务验证，不是"echo 一下通了"。
- 留或删。 跑通就写一条使用规则进
TOOLS.md，跑不通就卸干净，并在ERRORS.md里留一句为什么。
第 3 步和第 4 步合起来才叫"装好了"。只做第 2 步，等于给自己加了一个只会在关键时刻失效的开关。
技能越多，能力不一定越强
清单里 22 个包，按角色分下去之后，真正每天被调用的通常只有三五个。剩下的躺在列表里，只在特定任务时才被想起。
代价有两份。一份是上下文：每个技能的名字和描述都要进 prompt，18 条描述的固定开销，是每次对话都在付的。另一份是冲突：两个功能重叠的技能同时存在，agent 可能选错那个，而它自己不会告诉你"我选错了工具"。
所以我现在的判断标准变成了：这个技能解决的事，我一个月会碰几次？ 少于一次的，需要时再装。
装在哪，比装几个更要紧
同一款技能，装给谁不一样。我现在按三条分：
- 能写文件的，不给只该看的角色。 测试 agent 的活是验证，它的价值在于"不会顺手修好"，所以它的技能表里没有那些直接改产出物的工具。
- 能对外说话的，只装给主管。 发消息、发邮件、公开发布这类能力，四个 agent 各有一份，就等于四个出口，你根本记不住谁在什么场合说过什么。
- 能花钱的，装在能被看见的地方。 调用付费 API 的技能放在主管那边，是因为主管的会话里有完整的任务上下文，它知道这次调用值不值。
clawhub、skill-creator、github、weather 加上飞书四件套，这八个是四个 agent 的公共底座——它们要么是协作必需，要么是低风险。
权限边界：allowlist 与沙箱
技能加载分三层：agent 自己的工作区、共享根 ~/.openclaw/skills、以及从 ClawHub 这类市场装的。加载完还要过一遍 allowlist 才算真的可用。命令行用 openclaw skills 管：搜索、安装、更新、校验。
但 allowlist 管的是"能不能用"，不是"能用它做什么"。真隔离要单独开沙箱，一般定三件事：访问模式（能读、能写、还是碰不得）、网络策略、用哪个镜像。
被拦住的时候也别急着怀疑模型，先分三层看：是沙箱不让、是工具策略不让、还是提权没开。很多"它为什么用不了某个工具"的问题，答案都在这一层。
红线看着像礼貌，其实是降误伤
- 删除用可恢复的方式，别直接抹掉
- 对外发送（邮件、公开发布）先问
- 群里该沉默就沉默，一条消息最多一个反应，不连发
成本是偶尔多问一句"我可以做吗"，收益是不会出现"它怎么把这个发到群里了"这种事故。这笔账我认为很划算。
定时任务也是治理的一部分
- 心跳适合"可以批量、时间可以漂"的检查：收件箱、日历、有没有新消息
- 定时任务适合"必须准点、要独立会话、只执行一次"的事
别用一堆心跳去做本该精确定时的事，反过来也别为了一次检查专门建一个 job。
这块还在演进：官方已经把旧的 heartbeat 监视器迁到了普通的 automation jobs 上。照抄半年前的教程，很容易踩空。
收尾
能力是借来的，责任是自己的。
装了十个技能不代表它变强了，可能只是你多了十个不知道什么时候会响的开关。