Agent Skills 怎么选

我第一次整理热门 Skill 时，最容易犯的错是把“看起来不错”直接翻译成“值得安装”。

skills.sh 上有安装量，GitHub 上有 star，仓库里也确实存在一个 SKILL.md。三个信号放在一起，很容易让人产生一种确定感：这么多人用、文件也在，装上应该就能工作。

真正跑到本机后，情况往往不是这样：

Skill 目录存在
≠ 依赖的运行时已经就绪
≠ 它能在我的项目里完成任务

这篇文章不做“最强 Skill 排行榜”。我会用 12 个热门候选解释一套更保守、也更容易复用的选择方法，并完整拆三个结果不同的案例：

• agent-browser：源码、运行时和 fixture 都闭环，进入优先试用；
• grill-me：安装量高，但依赖的 /grilling 没有随 Skill 一起闭环；
• React Best Practices：源码结构很好，但本轮没有完成真实任务验收，只能条件试用。

读完后，读者应该能够在 30–60 分钟内审计一个陌生 Skill，并留下来源、revision、许可证、运行时、副作用和验收结果，而不是只保存一个安装命令。

证据边界

Codex 的 Skill 发现与加载行为以 OpenAI Build Skills 和 Plugins 为准；第三方行为链接到固定 commit；skills.sh 只提供发现信号。X 上的讨论只帮助我提出问题，不支撑产品能力、star 或性能结论。

一分钟概览

1. 先分型，再比较。 指令型 Skill、规则库、工作流套件和 CLI 入口不是同一种东西。
2. 先过门禁，再谈推荐。 来源、许可证、运行时、副作用和验收任务有一项说不清，就不能写成“已验证”。
3. 热度只决定先看谁。 安装量不能证明适配 Codex，也不能证明本机任务闭环。
4. 安装要分三层验收。 Codex 能发现、命令能执行、任务能完成，需要分别检查。
5. 数值评分放到最后。 没有评分锚点和逐项证据的 94 分、93 分，只是伪精确。

1. 先分清自己正在选择什么

“Agent Skill”这个名称下面，实际混着几种完全不同的机制。如果不先分型，后面的比较会变成苹果、工具箱和操作手册同榜打分。

这也是我放弃“12 个候选统一排 1–12 名”的原因。对 frontend-design，我主要关心它会不会把一个小页面改成大面积视觉重做；对 agent-browser，我首先要确认 CLI 和浏览器能不能启动；对 Superpowers，则要检查它会怎样改变整个开发流程。三者的验收问题根本不同。

图 1：Agent Skill 从热度发现到安装决策的五道门禁

图 1：白底动效图。候选只有依次通过来源、许可证、运行时、副作用和任务验收，才进入安装决策；任一门禁失败都应回到“未验证”或“暂不建议”。

社区内容仍然有用，但只放在第一步。我会从 宝玉关于 Skill 与 SubAgent 上下文边界的讨论、Kaxil 的 Skill 工作流或代码维护 Skill 案例里发现“可能值得复用的工作流”，然后回到官方文档、固定源码和本地任务验证。社区经验负责提出假设，不负责替我下结论。

2. 五道门禁：不过门禁，不进入推荐

我现在不再一上来给 Skill 打 100 分，而是先做五项硬检查。这个顺序比权重更重要，因为有些问题不能靠其他高分抵消。

门禁一：能不能追到原始来源

至少记录四个字段：

repository
skill_path
commit / tag
checked_at

只保存 skills.sh 页面不够。目录里可能是 fork、复制品，也可能只是指向另一个命令的薄入口。仓库首页同样不够，因为 main 会继续变化；文章中的事实应该能追到具体 commit 下的具体文件。

如果我无法判断谁维护它，或者只能找到二次转载，状态直接记为“来源未验证”。

门禁二：具体目录能不能合法使用

公开可读不等于开源，根目录的 LICENSE 也不一定覆盖每个 Skill 子目录。

这次检查 Anthropic Skills 固定 revision 时，frontend-design、skill-creator 和 webapp-testing 使用 Apache 2.0；docx、pdf、pptx、xlsx 目录则附有另一套使用条款。这个差异会直接改变我的行动：前者可以继续评估项目级使用，办公文档套件则优先使用宿主已经提供并配好依赖的能力，不随手复制目录。

许可证不清楚时，正确状态是“未验证”，不是“先装再说”。

门禁三：Skill 文件之外还依赖什么

我把依赖拆成四层：

Skill 文件
→ CLI / runtime
→ 浏览器、解释器或系统程序
→ 外部服务、账号和凭据

例如 agent-browser 的核心能力不在那一个 SKILL.md 里，而在配套 CLI 和浏览器运行时；办公文档 Skill 可能依赖 LibreOffice、Pandoc、Python 或 Node 库；数据库 Skill 的文本可以读取，但最终 SQL 仍需要一个安全的数据库环境验证。

最小检查可以从这些命令开始：

Get-Command agent-browser -ErrorAction SilentlyContinue
Get-Command playwright-cli -ErrorAction SilentlyContinue
Get-Command browser-use -ErrorAction SilentlyContinue
Get-Command tldraw -ErrorAction SilentlyContinue

没有输出不是小问题，它说明“Skill 可发现”和“运行时可执行”已经脱节。

门禁四：它会改变什么状态

阅读 SKILL.md 时，我会专门找这些词和行为：

• 全局安装、-g、-y；
• 网络请求、在线 reference、远程脚本；
• 登录态、浏览器 profile、cookie、session；
• Git worktree、hooks、提交与分支操作；
• 数据库 migration、生产数据、外部消息；
• 遥测、日志、截图和临时文件。

副作用并不等于不能使用。真正的问题是：它有没有被写清楚，能不能限制在项目目录、测试账号、非生产数据和最小权限里。

门禁五：有没有一个可判定的真实任务

“成功安装”不是验收标准。第一次试用前，我会先写一张最小任务卡：

task: 在动态页面完成中文表单、文章导航和双视口检查
starting_state: 全新会话；固定 fixture；不使用运行时生成的 id
acceptance:
  - 提交后出现预期中文确认文本
  - DOM 重排后仍打开正确文章并验证 URL 和正文
  - 1440x900 与 390x844 截图存在
  - 控制台没有 error
failure_signals:
  - 切换到未声明的浏览器工具
  - 定位失败后手写动态 id
  - 没有最终状态验证

一个好 fixture 不需要大，但必须有明确输入、正确输出和失败信号。没有这张任务卡，“感觉它好像帮到了我”很难和真实收益区分。

3. 完整案例一：为什么 agent-browser 通过了

agent-browser 是这批候选里最能说明“三层验收”的例子。

3.1 热度只能把它送进候选池

2026-08-01 的 skills.sh 快照记录约 57.9 万次安装。这个数字让我愿意先看它，但没有进入推荐结论。

我真正审计的是 vercel-labs/agent-browser 固定 commit 下的 SKILL.md。这个 Skill 是一个很薄的发现入口：它要求通过 CLI 获取与当前版本匹配的核心工作流。换句话说，CLI 不是锦上添花，而是能力的一部分。

这一步得到的不是“值得安装”，而是一个依赖结论：

只复制 SKILL.md，不会得到完整的 agent-browser 工作流。

3.2 本机先暴露了运行时脱节

实验前，本机已经能找到 agent-browser Skill 目录，但 PATH 里没有对应命令。此时它只能被 Codex 发现，不能执行实际网页操作。

我没有直接做全局安装，而是在实验包中固定项目依赖：

{
  "agent-browser": "0.33.1",
  "@playwright/cli": "0.1.17"
}

然后用不会临时下载新版本的命令检查：

cd examples/agent-skills-practical-lab
npm install
npx --no-install agent-browser --version
npx --no-install playwright-cli --version

本机返回：

agent-browser 0.33.1
0.1.17

到这里仍然只证明运行时存在，还没有证明真实任务能完成。

3.3 用同一份 fixture 做任务验收

两套 CLI 使用相同输入，完成三项任务：

1. 在每次请求都会更换 id 的中文表单中填写“林檎 / 人工智能”；
2. 等待文章列表在 350ms 后改变 DOM 顺序，再搜索并打开指定文章；
3. 在 1440×900 和 390×844 下截图并检查控制台。

约束也固定：每次页面变化后重新获取语义快照，不使用运行时生成的 id，失败最多重试一次，不能临时切换工具。

运行命令是：

npm run experiment:browser

单次记录如下：

这里必须把边界说清楚：只有一次运行，所以 31.575 秒和 6.051 秒不能推出普遍性能差距；输出字节更少也不能自动等于更省模型上下文。但两者都在固定 fixture 上完成了任务，这足以证明本轮“可完成”。

3.4 最终决定

agent-browser 进入“优先试用”，但决定不是“全局安装最新版”，而是：

• Skill 和固定版本 CLI 一起使用；
• 先放在项目级依赖；
• 登录网站前确认 session、profile 和凭据保存位置；
• CLI 或 Skill 更新后重新跑 fixture；
• 需要通用 E2E 和现有 Playwright 工程时，仍保留 Playwright 作为基线。

这就是“通过”的实际含义：不是证明它在所有网页上最好，而是证明它在我的版本、环境和任务里完成了一次闭环。

4. 完整案例二：为什么 grill-me 没通过

grill-me 是反过来的例子：热度很高，源码也很短，但短不等于边界清晰。

固定到 mattpocock/skills@2ab9580 的目标文件 后，可以看到它只有 7 行，真正的动作是：

“Run a /grilling session.”

翻译成中文就是：启动一次 /grilling 会话。

这句话本身没有错，但它暴露了审计关键点：当前文件不是完整访谈工作流，而是一块路牌。真正需要继续追踪的是：

1. /grilling 在哪个宿主里注册；
2. 安装 grill-me 时是否同时安装这个命令；
3. Codex 当前环境能否调用它；
4. 下游命令的 Prompt、依赖、副作用和许可证是什么；
5. 命令不存在时有没有降级路径。

本轮没有找到能让这条链路在当前 Codex 环境闭环的配套命令，因此它在“运行时依赖”门禁失败。我的决定是“暂不建议单独安装”，而不是评价访谈方法本身没有价值。

这个案例给我的实用提醒是：

SKILL.md 越短，越要判断它是边界清楚，还是把复杂性藏到了别处。

以后看到“调用另一个 slash command”“运行某个脚本”“获取远程规则”时，我都会继续沿依赖链审计，直到找到真正执行工作的那一层。

5. 完整案例三：为什么 React Best Practices 只能条件试用

第三种情况既不是通过，也不是失败，而是证据还不够。

Vercel React Best Practices 固定 revision 的结构明显比薄包装完整：

SKILL.md       149 行
rules/          72 个 Markdown 规则文件
AGENTS.md    3,810 行 / 112,071 bytes

它把规则按 waterfalls、bundle、server、client、rerender、rendering、JavaScript 和 advanced 分类，并给规则标注影响等级。这个结构适合按问题读取具体 reference，而不是把整套知识一次塞进上下文。

但结构优秀不等于已经证明效果。本轮只完成了源码审计，没有为它单独运行多组 React 性能任务，因此我不会把它写成“已实测推荐”。

我的使用边界是：

• 先判断页面有没有请求瀑布、客户端状态、重包、长列表或重复渲染；
• 只读取相关类别和规则文件；
• 每个 finding 必须绑定真实代码和机制；
• 没有性能问题时，允许输出“不需要修改”；
• 不默认加载 112 KB 的完整 AGENTS.md；
• 在独立 Next.js fixture 上通过构建、行为和性能验收后，再升级为长期保留。

因此它进入“条件试用”。这个标签不是保守话术，而是在告诉读者：源码质量已经给出正面信号，任务收益仍然缺证据。

6. 三层验收：安装完成后还要检查什么

通过五道安装门禁后，我会在本机再做三层验收。它们回答的是三个不同问题，不能互相替代。

图 2：Skill 从可发现、可执行到可完成的三层验收

图 2：白底动效图。目录和 description 只让 Codex 找到入口；CLI、浏览器或解释器让工作流能够启动；只有 fixture 的断言通过，才算当前任务闭环。

第一层：可发现

按照 2026-08-10 核对的 OpenAI 文档，Codex 初始只需要 Skill 的名称、描述和路径来做发现，匹配后才读取完整 SKILL.md；初始 Skill 列表还受上下文预算限制，文档给出的上限是上下文窗口的 2%，并以 8,000 字符作为回退值。

这一层要检查：

• Skill 是否放在 Codex 会扫描的目录；
• name 和 description 是否能说明何时使用；
• 新任务中能否通过 /skills 或 $skill-name 明确触发；
• 隐式任务是否会误触发或漏触发。

目录存在只能证明入口可能被扫描，不能证明内部命令能跑。

第二层：可执行

这一层检查 Skill 要求的工具是否真的存在，并固定版本：

Get-Command <runtime-name> -ErrorAction SilentlyContinue
<runtime-name> --version
<runtime-name> --help

如果依赖只存在于项目 node_modules，就用项目命令调用，不要因为 PATH 没有全局版本又安装一份最新版。最小启动还应该验证浏览器、解释器、端口和外部凭据，而不只是 --version。

第三层：可完成

最后才运行真实任务，并保存：

• 固定输入和 Prompt；
• 工具与 Skill revision；
• 命令数、重试、失败和耗时；
• 产物、截图或代码 diff；
• 验收命令与退出码；
• 没有覆盖到的场景。

如果 Agent 中途换了另一套工具才完成，不能把成功归因给当前 Skill；如果只有截图、没有状态断言，也不能证明任务正确。

7. 12 个候选重新分档后的结果

下表不是通用排行榜，而是这次审计的行动记录。安装量只决定候选顺序，不进入最终结论；“已实测”和“仅源码审计”分开显示。

完整记录可以下载为 CSV。表里保留了对象类型、revision、许可证、依赖、副作用、本地状态和证据等级，读者可以直接复制后替换成自己的候选。

这里还需要区分两个名字：本文的 find-skills 指 Vercel 仓库中的候选；我本机另有一个名为 find-skill 的社区 Skill。它们不是同一个来源，也不能因为功能相似就共用审计结论。

8. 30 分钟完成一次安装前审计

如果只想把方法用到下一个 Skill，可以按下面的节奏执行。

0–5 分钟：先写任务，不要先安装

写清一个真实任务、输入和验收命令。例如：

任务：审查当前 Next.js 页面中的请求瀑布
输入：app/page.tsx 与相关数据获取代码
验收：每条 finding 必须有 file:line、机制和修改建议
失败：只输出通用最佳实践；读取与任务无关的全部规则

没有真实任务，就无法判断 Skill 带来的是帮助还是额外流程。

5–10 分钟：追到原始文件

记录仓库、Skill 路径、commit、许可证和核对日期。再回答：

• 是维护者原始目录还是 fork？
• SKILL.md 是完整工作流还是入口？
• 是否引用 references、scripts、在线 URL 或另一个命令？

10–20 分钟：检查边界和副作用

完整读取 SKILL.md，只沿它明确要求的路由继续读 reference。特别检查：

• 触发条件和不适用场景；
• 输入、输出和停止条件；
• 强制措辞与不可跳过流程；
• CLI、浏览器、Python、Node、系统程序；
• 网络、凭据、会话、遥测和全局安装；
• 写文件、Git、数据库和外部系统副作用。

20–25 分钟：固定版本并做最小启动

优先使用项目级安装。版本检查、--help、浏览器启动和最小输入都成功后，才标记“可执行”。不要在这一步接触生产账号和真实数据。

25–30 分钟：运行 fixture 并作出四档决定

只允许四种结果：

如果想保存一份更完整的检查项，可以下载安装前审计清单。

9. 哪些情况下根本不需要安装

不是每个好 Prompt 都需要变成长期 Skill。以下情况我通常直接停在发现阶段：

一次性任务，没有重复价值

如果指令只会使用一次，直接写进当前任务通常更便宜。Skill 会增加发现描述、版本、维护和误触发成本。

宿主已经提供同类能力

本机已经有 document、pdf、presentations、spreadsheets 或 skill-creator 等能力时，先确认宿主版本是否已经包含运行依赖和权限边界。重复安装同名社区版本，反而会让触发来源变得不清楚。

下游依赖无法追踪

只要出现“调用另一个命令”，却无法找到命令定义、安装方式和版本，就先停下。安装一个路牌不会获得目的地。

第一次试用就要求全局、静默、批量安装

-g -y 很方便，也会把未经验证的指令暴露给所有项目。第一轮应放在隔离项目，通过任务验收后再决定是否提升到用户级。

只能在生产数据上验证

数据库 migration、外部消息、真实账号和不可逆操作，不适合作为第一次 Skill 验收。先构造非生产 fixture，或者把状态保持为“未验证”。

10. 我最终保留的方法

这次审计后，我不会再问“这个 Skill 火不火”，而是按下面的顺序问：

它属于哪一种机制？
→ 原始来源和具体 revision 在哪里？
→ 许可证是否覆盖这个目录？
→ 真正运行的 CLI、浏览器或服务是什么？
→ 会写什么状态、保存什么凭据、访问什么网络？
→ 哪个 fixture 能证明它完成了我的任务？
→ 当前证据允许我写“已实测”，还是只能写“条件试用”？

热门、已安装和真正可用不是同一件事。热度把候选送到桌面，源码审计解释它会做什么，运行时检查证明它能启动，fixture 才证明它在当前任务里完成闭环。

系列下一篇继续拆 Superpowers：给 Codex 加上工程纪律，然后是 agent-browser 的语义快照实测和前端 Skill 三件套。关于 Skill 的目录、渐进式加载和 eval，可以回到 Codex Skills 入门与进阶篇。

参考资料

• OpenAI：Build Skills
• OpenAI：Plugins
• skills.sh
• obra/superpowers@44c9b2d
• vercel-labs/agent-browser@da1237e
• vercel-labs/agent-skills@7c180d9
• anthropics/skills@b29e7cf
• supabase/agent-skills@1207767
• microsoft/playwright-cli@eee5a18