OpenClaw 火了,但 Skills 你真的会用吗?
不到100天，250，829 个 GitHub Star，OpenClaw 超越了 React 十余年积累的记录。
这件事本身不重要。重要的是它说明了一件事：Agent 正在从“玩具”变成“工作流基础设施”。
当一个工具开始影响你每天的业务效率和数据安全，Skills 的设计质量就不再是技术细节，而是产品决策。越来越多的 PM 开始问：Skills 到底怎么设计？装多少合适？哪些场景值得投入？边界在哪里？
很多人第一眼看 OpenClaw 的架构，会把 Skills 理解成“插件”，类似 Chrome Extension 那种逻辑——装上去，能力就扩展了。
Skills 的本质是 Markdown 文件。不是代码，不是 API 接口，是一份说明书。
它告诉 Agent：这个工具叫什么名字，什么时候该用它，怎么用。Agent 读懂了说明书，再去调用背后的工具或 API 完成任务。
这个区别很关键。插件是能力的实体，说明书是能力的索引。装了 100 个插件，你有 100 个能力。装了 100 份说明书，Agent 在每次对话开始前都要把这 100 份说明书翻一遍，找出这次可能用得上的那几份——而翻说明书这件事，本身就在消耗成本。
OpenClaw 在每次对话开始时，会把所有可用技能的名称和描述注入到 System Prompt 里。每个技能大约消耗 24 个 Token 的基础开销，加上 name 和 description 的内容，一个写得稍微详细点的技能描述，轻松到 120 个 Token。
50 个技能，每轮对话仅技能描述部分就要多付出数千个 Token 的额外开销。社区实测显示，如果改成按需召回（每次只注入最相关的几个技能），单次会话的技能相关 Token 开销可以降低数倍以上。
这还不是最深的问题。Token 成本只是账单上的数字，更隐蔽的代价是：System Prompt 越长，Agent 的注意力越分散，技能召回的准确率越低，最终降低的是任务完成质量。装太多技能，不只是在多花钱，是在主动降低 Agent 的判断精度。这是一个系统性约束，不是成本优化问题。
这不是一个随便说的数字。15 个以内，Agent 能在合理的 Token 范围内做完整的技能匹配；超过这个数，你就要认真考虑是否值得引入向量检索来做按需召回。
大多数情况下，超过 30 个技能之后，不是“不能用”，是“你的架构需要升级了”。
ClawHub 上现在托管了数万个技能，其中已被标记为恶意的超过 820 个。
这不是小概率事件。这是一个正在爆炸式生长的生态里，必然会出现的结构性风险。在这个生态里选技能，你面对的不是一个经过审计的应用商店，而是一个几乎没有门槛的开放市场。
在这个前提下，「一个技能只做一件事」不只是设计原则，是自我保护逻辑。
好的技能设计长这样：calendar-sync 只管日历，email-assistant 只管邮件，github-integration 只管代码仓库。每个技能的权限申请，和它的功能描述严格对齐。日历技能要读写日历，邮件技能要读写邮件，就这么多。
坏的技能设计长这样：universal-api-connector，请求所有权限，能处理一切数据流。
后者不只是设计丑陋——ClawHub 上已确认的恶意技能里，主要特征之一就是“什么都能干”：伪装成超级管理员工具实际上传 SSH 密钥，伪装成加密货币钱包管理器实际收割 API Key，或者请求所有权限、拦截 Agent 与其他技能之间的全部数据流。
一个技能要求的权限越出它声称的功能范围，这就是红线。
description 字段决定两件事：Agent 在什么情况下会调用这个技能；如果你引入了向量检索，这个技能能不能被准确召回。
写差了，结果不是技能用不上，是 Agent 在不该用的时候触发了它，或者在该用的时候找不到它。
好的写法：“Feishu document read/write operations. Use when user needs to read， create， update， or search Feishu/Lark documents， wikis， or drive files.”
区别不是信息量，是触发条件的明确程度。Agent 需要知道的不是“这个技能是干什么的”，而是“我在什么情况下该想到用这个技能”。这是两个问题，很多人只回答了前者。
description 写差了，不是技能用不上，是 Agent 在帮你做错误的决策——而你可能根本不知道它用错了。
竞品监控。 每天自动检查竞品定价变化，汇总发到 Slack。这件事人工做，要打开 N 个网页，记录，对比，发消息。Skills 做，设置一次，每天自动跑。
会议前简报。 会议开始前 30 分钟，自动拉取参会者背景和上次互动记录，发到你手机上。你进会议室之前已经知道对方上次聊了什么。
销售线索跟进。 每天扫描新注册用户，按公司规模分类，自动发送个性化的第一封跟进邮件。PLG 团队非常适合这个。
支持文档自动化。 每周分析重复出现的支持工单，自动提炼，创建 FAQ 更新任务。
这些场景的共同特征是：触发条件明确，执行路径固定，结果可验证，出错代价低。
Skills 主要解决的是效率问题，而不是信任问题。
凡是需要信任背书的场景，Skills 的设计逻辑从根本上就不匹配。
企业合规场景。 社区技能没有 SLA，没有安全审计，开发者可以随时放弃维护，也没有 SOC 2、GDPR 这些合规认证。如果你的数据有驻留要求，或者流程有审计要求，社区技能不是正确的工具选择——不是“慎用”，是“结构上不匹配”。
涉及敏感数据的核心业务。 财务系统、医疗数据、客户 PII——这些场景需要经过专业审计的能力模块，不是开放市场上 star 数还不错的开源项目。
关键业务流程。 技能可能被放弃维护。如果一个流程的中断会直接影响业务，你需要有 SLA 保障的东西。Skills 生态目前给不了这个。
这不是 Skills 的缺点，是它的边界。边界内它是杠杆，边界外它是风险。
设计或选择一个 Skills 之前，问自己这五个问题：
-
-
-
description 描述的是触发条件，还是只是功能说明？
-
-
五个问题，都能答“是”，装上去。有一个答不上来，先停一下。
Skills 生态的逻辑，和所有快速生长的生态一样：它不会等你准备好。
边界搞清楚了，它是杠杆；边界没搞清楚，它是风险放大器。这不是警告，是这个生态的运行规律。
夜雨聆风
