摘要：Agent Skills 生态在这一年里完成了从「稀缺」到「过剩」的转变：官方仓库、社区市场、个人作品集里的技能多到装不完，新的瓶颈不再是「怎么写一个技能」，而是「怎么从一堆自我描述都很漂亮的技能里，挑出真正能干活的那个」。本文把「找 skill」当成一条完整的选型工程来做：先拆解技能的三层货架结构，说明每一层分别能验证什么；再给出一套检索—画像—试跑的三步验收工序，附配套的技能画像审计脚本；然后用这套工序对 DeepSkill 的作品展厅做了一次完整实测，记录真实的筛选结果与淘汰理由。结论是：市场技能的可用率远没有宣传页暗示的那么高，但三步工序可以在半小时内把「看起来能用」和「验证过能用」区分开——无论技能来自哪个市场，验证真实能力都比轻信自我描述可靠。
一、现象：技能供给爆炸之后，瓶颈从「怎么写」移到了「怎么选」
过去一年，Agent Skills 从一个实验性概念变成了基础设施。Anthropic 把技能的渐进式加载机制（描述常驻上下文、正文按需读取、脚本直接执行）写进了工程博客（参见 Equipping agents for the real world with Agent Skills），官方技能仓库 anthropics/skills 里沉淀了一批质量较高的参考实现；OpenClaw 这类常驻 Agent 把技能目录变成了个人助手的「手艺库」；各种第三方市场和作品集平台上，个人开发者上传的技能以每周几十个的速度增长。
供给爆炸的直接后果是：写技能的教程已经过剩，选技能的方法论严重缺位。社区里最常见的求助从「这个技能怎么写」变成了「有没有好用的 XX 技能推荐」。而推荐这个动作本身就很脆弱——推荐者验证过的往往只是「我装上跑通了一次」，而这次跑通距离「在你的环境、你的任务、你的权限边界下可复现地跑通」还隔着一整条验证鸿沟。
更微妙的是，技能这种产物天然擅长「自我描述得很美」。一个 SKILL.md 的 frontmatter 描述就是写给模型看的广告位：作者有充分的动机把触发条件写得宽一些（让技能更容易被选中）、把能力写得满一些（让读者点进来）、把依赖和限制写得含糊一些（免得吓跑用户）。这和开源软件的 README 经济学一模一样，但技能的门槛更低——不需要打包、不需要发布流程、一个 markdown 文件加两个脚本就能上架——所以「宣传与实际的落差」在技能市场上被进一步放大。
我们观察到的典型循环是这样的：用户在市场里看到一个大而全的「全能办公助手」技能，装上，前两天惊喜，第三天发现它在自己只需要查天气的时候也抢着出场，第五天发现它内置脚本在读自己的环境变量，最后卸载了事，并得出「市场上的技能都不行」的结论。这个结论的后半句其实是错的——市场上确实有能用的技能，错的是选型方式：用「看描述 + 装上试一次」来选技能，本质上是在验证作者的写作能力，而不是技能的真实能力。
本文要回答的问题因此很具体：当我们说「去市场找个 skill」的时候，这条链路应该怎么设计，才能让每一步都留下可验证的证据？
二、机制剖析：一个 Skill 的「三层货架」决定了你能验什么
在给方法之前，先把一个技能拆开看。按照渐进式加载的设计，一个技能在 Agent 眼中有三层结构，每一层的「可见成本」和「验证价值」都不同：
第三层：脚本/资源（执行时才触碰）
┌─────────────────────────────────┐
│ 真实能力所在，也是真实风险所在 │
│ shell / 文件读写 / 网络请求 │
├─────────────────────────────────┤
第二层：正文 SKILL.md（命中后按需加载）
┌─────────────────────────────────┐
│ 操作流程、步骤、边界说明 │
│ 决定任务能否被复现地完成 │
├─────────────────────────────────┤
第一层：frontmatter 描述（常驻上下文）
┌─────────────────────────────────┐
│ 「广告位」：名称 + 一句话描述 │
│ 决定技能何时被选中，最容易被美化 │
└─────────────────────────────────┘
这三层结构直接决定了选型验证的三个切入点：
第一层验触发。 描述常驻上下文，意味着它在每一次任务路由中都会被模型看到。描述写得宽，技能就会在不该出场的时候出场（误触发）；写得窄或含糊，该出场时唤不醒（漏触发）。这一层的验证手段是构造触发样本集做矩阵测试——我们在之前 OpenClaw 审计的文章里把这套方法叫「触发面扫描」，它同样适用于市场选型：装之前先看描述，预判它会在哪些表述上被激活，装之后用样本验证预判。
第二层验复现。 正文是作者声称的操作流程。验证方式是把正文当成一份 SOP，人工走一遍：每一步的输入是否明确、依赖是否声明、失败分支有没有交代。一个常见信号是正文里写着「调用某 API」但通篇没有说明 key 从哪来——这类技能在你机器上的第一次运行大概率以报错告终。
第三层验安全与依赖。 脚本是真实能力也是真实风险。安全社区的报告反复证明这个层面的问题不是理论威胁：安全研究者发布的 ClawHavoc 报告在公开技能与工具仓库中识别出上千个恶意技能，Snyk 的 ToxicSkills 分析也指出相当比例的社区技能存在不同等级的安全隐患（该报告见 Snyk 对 Agent Skills 生态的风险分析）。对选型来说，第三层的验证手段是静态画像：扫描脚本中的敏感操作模式，对照技能自我声明生成权限面报告。
还有一个常被忽略的信号源是市场自身的评分与评论。它们有价值，但价值有限：技能的评论样本量通常很小，且评论者与你一样缺少验证工具——「好用」两个字背后可能是完全不同的任务、环境和权限边界。评分适合用来做初筛（大量明确负评的候选直接跳过），不能替代你自己采集的证据。把评分当结论，等于把别人的选型风险当成自己的验证结果。
三层合起来，可以给「找 skill」下一个工程化的定义：选型 = 对候选技能的三层分别采集证据，再决策是否装载。凡是跳过证据采集直接装载的环节，都是在用生产环境当测试环境。
三、实测方法：检索—画像—试跑的三步验收工序
把上一节的框架落到操作层面，是一条三步工序。它的设计原则只有一条：每一步都产出可存档的证据，淘汰决策必须引用证据而不是印象。
3.1 第一步：用任务反推检索词，而不是用热词找任务
大多数人找技能的路径是从市场首页的热门榜单开始逛，这有个结构性问题：热门榜单排序的是下载量与新鲜度，而你的装载决策应该由任务需求驱动。正确的起点是先写下你最近一周真实想让 Agent 完成的三到五个任务（例如「每周把多个数据源汇总成周报」「给截图批量打标签入库」），再从任务描述里提取检索词。这样检索到的每个候选技能都自带验收标准——你手里有真实任务，试跑环节就不需要人工构造用例。
检索词的提取有一个实用技巧：优先用「动词 + 宾语」的具体动作短语，而不是抽象的领域名词。想找周报汇总能力，搜「每周汇总数据源」「生成周报草稿」的命中质量，通常高于搜「办公自动化」——后者会同时召回日程管理、邮件整理、会议纪要等一堆弱相关候选，反而把真正对口的技能埋进去。另外，每个任务最好准备两到三个同义表述轮换检索，因为不同作者对同一能力的命名差异可能很大：有人叫「周报生成」，有人叫「日报汇总」，还有人藏在「数据聚合」这种名字底下。
3.2 第二步：画像审计——装之前给候选技能拍一张「X 光片」
对检索命中的候选，先不装载，把技能包下载到隔离目录做静态画像。画像脚本要做四件事：解析 frontmatter 的描述与触发词、扫描正文中的依赖声明完整性、用敏感操作模式库扫描脚本权限面、检查是否自带回滚方式（比如是否有卸载脚本、是否修改共享配置文件）。下面是我们在用的画像脚本骨架：
# skill_profile.py —— 市场技能装载前静态画像脚本
import json, re
from pathlib import Path
SENSITIVE = {
"shell": [r"child_process", r"\bexec\b", r"os\.system", r"subprocess"],
"fs": [r"readFile", r"writeFile", r"shutil\.(move|copy|rmtree)"],
"network": [r"fetch\(", r"requests\.", r"httpx\.", r"urllib"],
"secret": [r"\.env", r"process\.env", r"api[_-]?key", r"credential"],
}
DEP_HINTS = [r"pip install", r"npm install", r"requires?", r"依赖[:：]"]
def profile(skill_dir: Path) -> dict:
report = {"skill": skill_dir.name, "caps": {}, "dep_declared": False}
for f in skill_dir.rglob("*"):
if f.suffix not in {".md", ".py", ".js", ".ts", ".sh"}:
continue
text = f.read_text(encoding="utf-8", errors="ignore")
for cap, pats in SENSITIVE.items():
hits = [p for p in pats if re.search(p, text, re.IGNORECASE)]
report["caps"][cap] = report["caps"].get(cap, 0) + len(hits)
if f.name == "SKILL.md" and re.search("|".join(DEP_HINTS), text, re.I):
report["dep_declared"] = True
return report
def verdict(r: dict) -> str:
caps = r["caps"]
if caps.get("secret", 0) and not r["dep_declared"]:
return "REJECT: 涉密访问且未声明依赖与用途"
if caps.get("fs", 0) + caps.get("shell", 0) > 10:
return "REVIEW: 高权限面，需人工核对每处引用"
return "OK"
for d in Path("./candidates").iterdir():
if d.is_dir():
r = profile(d)
print(f"[{verdict(r):>7}] {r['skill']} caps={r['caps']} dep={r['dep_declared']}")
画像产出三条硬性淘汰线：涉密访问但正文没解释用途的直接淘汰（合法的密钥使用一定会写明 key 的申请与配置方式，含糊即动机可疑）；高权限面但零依赖声明的进入人工复核队列；完全无脚本纯流程型的技能重点看正文复现性。这条工序的价值在于把「安全感」从一种感觉变成了一份可以逐行核对的报告。
3.3 第三步：金丝雀试跑——用你的真实任务验触发与复现
通过画像的候选进入试跑：装载进一个隔离的测试 Agent（或至少是一个不碰生产数据的会话），跑三个用例——你的真实任务、一个与技能描述擦边但不该触发的干扰任务、一个故意的错误输入。三个用例的构造有具体讲究。真实任务用你本周确实要做的事，输入数据用脱敏后的真实样本——合成数据会掩盖技能对边界情况的处理方式；干扰任务选一句「语义上沾边但意图不同」的表述，比如技能做周报汇总，干扰用例就用「帮我把这周的会议纪要整理一下」，考察描述里的触发词是否宽到把整理类请求也吞进来；错误输入则故意给一个缺失字段的文件或一个不存在的路径，好的技能应该报错清晰并原样退出，坏的技能会创建半成品文件、留下缓存，甚至把错误吞掉返回一个「成功」。三个用例分别回答三个问题：正事能不能办成、闲事会不会抢戏、出错时行为是否体面。三个答案构成一份试跑记录，与画像报告一起存档。装载决策必须同时引用两份证据，任何一份缺失都视为未验证。
四、实测记录：用 DeepSkill 的作品展厅走一遍完整流程
方法说完了，用它跑一遍真实环境。我们选取了 DeepSkill 的作品展厅作为本次实测的样本市场——它把技能作品以带预览的画廊形式陈列，可以直接在装载前读到 SKILL.md 的关键信息，适合完整走通三步工序。
检索环节。 按第一步的方法，我们先写下本周真实任务清单，从中提取了两组检索词：一组围绕「周报汇总」，一组围绕「图片批量处理」。在展厅里按任务词检索，分别命中 6 个和 4 个候选——数量适中，说明按任务反推检索词能有效收缩候选集；相比之下直接逛热门榜单会面对几十个与本周任务无关的技能，那不是选型是逛街。检索阶段同步做了一次粗筛：标题或描述与任务意图明显错位的候选直接标记跳过，这个动作只花了两分钟，但把画像环节的工作量砍掉了近三分之一——选型链路里最经济的过滤器永远在最早的环节。
画像环节。 十个候选全部下载到隔离目录跑画像脚本，结果分布如下：
| 画像结果 | 数量 | 典型发现 |
|---|---|---|
| 直接可用（OK） | 3 | 权限面干净，依赖声明完整，正文步骤可复现 |
| 需人工复核（REVIEW） | 4 | 权限面偏高但正文有解释；或依赖声明含糊 |
| 直接淘汰（REJECT） | 3 | 涉密访问无说明 / 脚本含硬编码外部地址 / 正文与脚本能力不符 |
三个直接淘汰的案例值得展开，因为它们恰好对应三层结构各自的花招：一个是「周报汇总」类技能，画像发现脚本读取 .env 但正文只字未提密钥用途，属于第一层描述与第三层行为脱节；一个是「图片处理」技能，脚本里硬编码了一个统计上报地址，属于典型的隐形外联；还有一个描述写着「自动生成数据报告」，正文却是空壳——三层里只剩第一层的广告位。
试跑环节。 通过画像的 3 个 OK 技能加 2 个复核后放行的技能进入金丝雀试跑。5 个里 4 个通过三用例测试；剩下一个在干扰用例上翻车——它的描述把触发条件写得太宽，一句与周报无关的「帮我把这个表格看看」也把它唤醒了，并且顺手把表格内容写进了它自己的缓存目录。触发矩阵测试再次证明了它在选型里的位置：这是画像扫不出来、只有行为测试才能暴露的问题。
这次实测还有一个隐性收益值得记录：三份 REJECT 证据和那份触发矩阵，连同每条淘汰理由，都沉淀成了结构化的存档。下一次再检索同类能力时，这些记录就是现成的负面清单——已确认含隐形外联的作者、描述过宽的技能类别，可以直接跳过重复验证。选型工程的复利不在单次省下的四十分钟，而在于证据库会随时间累积成你自己的技能信誉库，让每一轮「找 skill」都比上一轮更快、更准。
实测结论。 十个候选，最终装载 4 个，装载率 40%。这个数字与我们在其他市场抽样观察到的量级一致——它不是在说这个市场不好，而是在说任何市场都默认不替你做验收。三步工序的总耗时约四十分钟，其中大半花在人工核对 REVIEW 队列上；相比「装上试、出事删」的旧循环，这些时间买到的确定性是划算的。
五、选型对比：市场现成、自研与现场生成，怎么组合
跑完实测，可以回答一个更上位的问题：技能的三个获取渠道——市场现成、自己写、让模型现场生成——各自适合什么场景。三者的结构差异如下：
市场现成 自研技能 现场生成
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 获取成本：低 │ │ 获取成本：中 │ │ 获取成本：低 │
│ 验证成本：中 │ │ 验证成本：低 │ │ 验证成本：高 │
│ 触发匹配：泛 │ │ 触发匹配：准 │ │ 触发匹配：一次性│
│ 维护主体：作者 │ │ 维护主体：你 │ │ 维护主体：无人 │
│ 适合：高频通用 │ │ 适合：核心流程 │ │ 适合：临时杂务 │
└──────────────┘ └──────────────┘ └──────────────┘
三个渠道的关键差异在验证成本与复用次数的比值上。现场生成（每次任务临时让模型写脚本）单次成本最低，但每次都要重新验证，且不沉淀——它适合一次性杂务，绝不适合变成每周都手工重跑的伪工作流。市场现成技能的验证成本是一次性的，如果技能高频复用，这个成本会被摊薄；但它验证的是作者的能力，且供应链漂移（作者更新）会持续引入新的验证义务。自研技能验证成本最低——你对自己的任务和权限边界最清楚——但写作本身要花时间。
由此可以推出一个务实的组合策略：核心流程自研，通用高频任务从市场选型（走三步工序），一次性杂务现场生成并明确标注「不入库」。这个策略的隐含前提是：无论技能从哪来，入库前都要过同一条验收线。渠道可以不同，验证标准不能有双轨。
团队场景下这条线还要再加一道工序：把个人的验证证据变成团队的共享资产。成员 A 用三步工序验证过的技能，其画像报告与试跑记录应该进团队仓库；成员 B 再遇到同类需求时，先查证据库再决定是否重复验证。市场把技能的复制成本降到了零，而团队要管理的恰恰是验证结论的复用——技能可以被无数人装载，但为它背书的证据只应该被采集一次。
六、总结
回到本文开头的问题：当技能供给从稀缺变成过剩，「找 skill」就不再是一个逛店行为，而是一条选型工程链路。这次对 DeepSkill 作品展厅的实测给出的答案是具体的三步：用任务反推检索词收缩候选集，用静态画像在装载前暴露权限面与依赖问题，用金丝雀试跑验证触发边界与复现性——每一步都留下可存档的证据，淘汰决策引用证据而非印象。40% 的装载率提醒我们，市场上「看起来能用」和「验证过能用」之间，隔着的那段距离恰恰是使用者自己必须走完的。
这也再次呼应了这个系列一贯的主张：Agent 生态里的一切能力声明——无论是模型的自我介绍、技能的 frontmatter 描述，还是市场页面的宣传语——都只是待验证的假设。真正可靠的工作方式，是让每一次装载决策背后都有一份你能指出来的证据。如何验证 Agent/Skill 的真实能力，而不是轻信自我描述，这不是一句口号，而是一套可以像本文这样落到脚本与表格上的日常工序。
关于 Deep Skill Finder
Deep Skill Finder 是一个持续运转的技能发现与验证项目：从真实用户的讨论与求助中采集「大家到底想让 Agent 做什么、卡在哪里」，把这些问题沉淀为选题与测试用例，再对市面上的 Agent 技能做实测评测——包括技能触发准确性、依赖完整性、权限面与复现性等维度，产出横向对比与方法论文章。如果你正在为自己的 Agent 挑选技能，或想了解某类技能的真实可用性，可以关注 DeepSkill 的作品展厅与后续评测更新；如果你在使用某类技能时踩过坑，也欢迎把你的经历反馈给我们，它们会成为下一轮实测的测试用例。技能生态正在快速膨胀，愿每一次装载都有证据背书。
