我先说个体会：给 Agent 加个能力，最崩溃的不是写 Prompt，也不是调模型参数，而是你得在 GitHub 上从一个仓库点到另一个仓库，像黑夜海里捞针一样找现成的 Skill。我记得有天晚上想给手头的 Agent 配一个“抓取网页内容并整理成 Markdown 周报”的能力，结果一搜关键词，冒出来一堆叫 expert、plugin、tool、skill 的项目，每个 README 都写得天花乱坠，真正能跟我的 Agent 框架顺利对接的没几个。翻到凌晨两点，收藏夹多了 30 多个仓库，真正跑通的只有 2 个。后来的转机是我发现了那份 76.6k Star 的官方技能清单——里面整理好了 1000+ 个 Skill，把日常开发、办公、数据分析、内容创作这些场景的能力一次性覆盖了大半。废话不多说，这篇就把我那一晚上踩的坑、总结的经验，以及这份清单到底怎么用、怎么配、怎么避雷，完整写给你。
1. 为什么给 Agent 加个技能这么让人头大
1.1 先还原一下“翻一晚上 GitHub”的现场
我当时的任务听起来很简单：让 Agent 能够接收一个 PDF，自动提取里面的表格，再汇总到 Excel。我当时想的是“这需求太常见了，肯定有现成的 Skill”。结果打开 GitHub 一搜，看到的情况是这样的：
- 有人做了一个“PDF 表格提取工具”，Star 超过 4000，点进去一看依赖了三个版本的解析库，跟我的环境冲突；
- 有人做了“智能表格处理器”，但设计目标是处理 CSV 和 JSON，PDF 只是顺带提了一嘴；
- 还有一个“全能文档技能包”，里面确实有 PDF 提取能力，但整体安装方式是把自己的一套工具链全部塞进来，装完之后整个环境都变了样。
这就是最典型的场景：不是没有 Skill，而是有太多了，且没有一个统一标准。每个作者都按自己的想法设计目录结构、配置文件、触发方式。你想“组装”一个能用的能力，得先读懂每个作者的设计哲学。这比从零写一个脚本还要累。
我后来跟几个也在搞 Agent 的朋友聊，大家的第一反应出奇一致：“翻 GitHub 翻到怀疑人生。”有人翻过更狠的，为了给 Agent 加一个“发送邮件并抄送”的能力，对比了六个仓库，最后发现每个仓库维护的协议都不一样，有的用 JSON 定义动作，有的用 YAML，有的直接把动作写死在代码里。你很难复制粘贴——因为连“粘贴”的前提都没有，你得先做一遍适配。
1.2 Agent 技能（Skill）到底是个什么东西
在继续说之前，先把概念对齐一下。很多人以为 Skill 就是一段更长的 Prompt，这是最大的误解。Prompt 是“告诉模型怎么想”，Skill 是“给模型配好工具和操作手册，让它能动手做”。
用生活类比来说：Agent 像一个刚入职的全能实习生，脑子聪明，什么任务都能听懂，但手上没有工具，也不知道公司的具体流程。Skill 就是分配给这个实习生的“工具包 + 操作手册”。工具包负责实际执行（比如解析 PDF、调接口、读写数据库），操作手册负责告诉 Agent 什么时候用哪个工具、按什么顺序执行、输出格式长什么样。
所以一个合格的 Skill 至少包含三部分：
- 触发条件——在什么场景下模型应该主动调用这个 Skill；
- 执行流程——明确先做什么、后做什么，每一步的输入输出是什么；
- 资源依赖——需要哪些第三方库、API Key、外部服务。
理解了这一点，就能明白为什么手工翻仓库那么痛苦：你以为你在找一个“工具”，实际上你要找的是一整套“工具 + 使用说明 + 触发逻辑”的组合。单独找到一个脚本没用，还得看它能不能被你的 Agent 框架识别和调度。
1.3 手工挖掘 Skill 仓库的三大痛点
我复盘了一下那晚的经历，手工挖 Skill 的痛点其实高度集中，可以归纳成三条：
第一，质量参差不齐却看不出好坏。Star 数量并不等于可用性。有些项目靠漂亮的 README 和截图吸引了大量 Star，但代码可能很久没更新，问题区堆了几十个未回复的 issue。比如我遇到的那个“PDF 表格提取工具”，Star 有 4000+，但最后一次 commit 是在两年前，依赖的库早就进入 EOL（停止维护）状态了。
第二，依赖冲突是真正的噩梦。每个 Skill 都是一套或多套第三方依赖。当你同时想用“PDF 提取”“网页抓取”“Excel 生成”三个 Skill 时，三个 Skill 各自依赖的库可能要求同一个底层包的不同版本。手工解决这种依赖地狱，轻则半小时，重则直接让你想重装系统。
第三，没有一个统一的“插拔”标准。不同作者对 Skill 的定义完全不同：有的要求你把脚本放到特定目录，有的要求你在配置文件里注册 URL，有的甚至要求你改框架源代码。这导致“装一个 Skill”变成一场小型的系统改造工程。装上之后，想卸载也卸不干净。
这三个痛点叠加起来，就能解释为什么“翻 GitHub 一晚上”会成为 Agent 开发者的常态。我们缺的不是能力，而是缺一个标准化的能力仓库：有清晰目录、有统一结构、有质量审查、有依赖管理。这也是我后面为什么对那份 76.6k Star 的官方清单这么看重——它把上面三个痛点一次性解决了。
2. 76.6k Star 的官方技能清单究竟强在哪
2.1 官方维护与社区众包的双层机制
在找到这份清单之前，我其实看过好几个“awesome”类的技能汇总仓库。那些仓库本质上是链接收藏夹，靠人工维护一堆外链，点进去还是同样的混乱。而 76.6k Star 这份清单不一样，它不是一个“导航页”，而是一个真正意义上的“技能市场源码库”。
它的维护机制是“官方主理 + 社区提交”。官方团队定义好 Skill 的标准格式、目录分类、命名规范，然后开放提交渠道。社区开发者写好的 Skill 以 Pull Request 的形式交上来，经过自动化检查（格式、依赖、安全性扫描）和人工抽查后合入主线仓库。这就相当于一个自带质量过滤器的市场：你拿到的每个 Skill 至少已经过了一轮初步体检，而不是某人随手扔上去的“半成品”。
76.6k Star 这个数字本身也说明问题。在开源世界里，Star 可以被“引流”，但很难被长期“维持”。这么多人收藏、点赞、克隆，说明这个仓库不是一次性热点，而是一个持续产生价值的活项目。我后来每次遇到一个新需求，第一反应不再是搜索“xxx skill github”，而是直接去这份清单的目录里找。它已经从“参考资源”变成了“默认工具库”。
2.2 Skill 的统一结构让“一次配齐”成为可能
这份清单能承载 1000+ Skill 还不乱，靠的就是统一的内部结构。每个 Skill 都是独立目录，内部结构高度一致。我拿一个“网页内容总结”类的 Skill 举例，它的目录长这样：
web_summarizer/ ├── SKILL.md # 技能描述与触发定义 ├── scripts/ │ ├── fetch_page.py # 抓取网页内容 │ └── generate_summary.py # 生成结构化摘要 ├── requirements.txt # 依赖清单 ├── reference/ │ └── examples.md # 使用示例 └── assets/ └── icon.png # 展示图标这套结构最大的价值在于“可预测”。你只要看过任何一个 Skill，就知道其他所有 Skill 该怎么读、怎么改、怎么装。SKILL.md 是给模型读的说明书，scripts 里的脚本是给机器执行的工具，requirements.txt 是依赖锁，reference 是给开发者看的人话文档。所有人都在同一套框架下写东西，你就不需要“适应每个作者的习惯”了。
官方团队在结构设计上是动过脑子的，不是随便拍脑袋定的目录。他们把“模型的思考”和“脚本的执行”明确分开：模型靠 SKILL.md 理解任务调度，脚本负责精确计算和调用外部资源。这样设计有很明显的好处——模型不直接跟系统 API 打交道，而是通过 Skill 间接操作，出错面更小，行为更可控。
2.3 “一次配齐”背后是动态加载，不是暴力堆料
我第一次看到“1000+ Skill 一次配齐”这句话时，心里是犯嘀咕的。一千多个技能全装进 Agent，显存吃不吃得消？上下文窗口塞不塞得下？启动会不会慢到怀疑人生？
后来看了它的运行机制才明白，这份清单的“配齐”并不是把 1000 个 Skill 全部加载进内存，而是把 1000 个 Skill 做成了一个大型索引目录。Agent 在运行时会根据用户任务的语义，动态匹配最合适的 Skill 来加载。需要处理 PDF 时，才把 PDF 相关的 Skill 加载进来；需要写代码时，才把代码生成的 Skill 拉起来。
用生活化类比就是：你不是把整个工具箱焊死在身上，而是随身带一份“工具箱总目录”。干活的时候扫一眼目录，开对应抽屉，拿出对应工具。目录可以很大，但手上每次只有需要的两三件工具。这样“一次配齐”是配齐了目录和仓库，而不是配齐了运行时的全部资源。这也解释了为什么它敢收纳 1000+ 的 Skill——因为大部分 Skill 平时只是“躺”在仓库里吃灰，不会干扰运行。
这个设计对我的启发很大。以前我倾向于“精挑细选三五个 Skill 装进去”，总觉得少而精是稳的。但问题是，Agent 的任务千变万化，你今天配了 PDF 能力，明天可能就需要图表生成，后天又冒出个语音转文字的需求。每次都要手动找、手动加、手动调，成本极高。把它理解成一个“按需挂载”的系统后，我才真正接受“全量配齐、按需加载”这个思路。
3. 1000+ Skill 是怎么组织起来的
3.1 按能力域而不是按工具分目录
看完目录结构，我最大的感受是：这份清单的分类学非常“贴近任务”，而不是“贴近技术”。它没有按“Python 工具”“API 封装”这种技术栈来分类，而是按“你想让 Agent 帮你完成什么”来分类。
我随手记了下主要的几个大分类：
- 内容创作：写作辅助、文案改写、翻译润色、SEO 标题生成；
- 数据工作：表格处理、数据分析、图表绘制、CSV 清洗；
- 开发辅助：代码审查、测试生成、依赖分析、文档注释；
- 自动化流程：网页抓取、表单填写、定时任务、邮件处理；
- 日常效率：会议纪要、简历筛查、日程规划、笔记整理；
- 多模态处理：图片 OCR、语音转文字、视频片段抽取、音频转写。
这种分类方式的好处是：你不需要预先知道“某个工具叫什么名字”，只需要知道“我想解决什么问题”。以前我找 Skill 是从技术栈出发，比如“我需要一个 Python 实现的 PDF 解析库”，然后在各种代码仓库里翻；现在我是从任务出发，直接进“数据工作”类目，找到 PDF 解析相关的 Skill。整个搜索心智模型被简化了一大截。
3.2 一个“复杂 Skill”的内脏解剖
分类目录只是外壳，真正体现能力的是 Skill 内部的实现质量。我挑一个平时用得最多的“代码审查 Skill”来解剖，它也是这 1000+ 里比较有代表性的一个。
code_review/ ├── SKILL.md ├── scripts/ │ ├── analyze.py # 静态分析 + 调用 lint │ ├── collect_diff.py # 获取本次代码变更 │ └── format_report.py # 生成审查报告 ├── requirements.txt ├── reference/ │ ├── rules.md # 团队代码规范 │ └── examples.md # 良好与问题的对照示例 └── assets/ └── review_template.mdSKILL.md 里写清楚了触发条件：当用户要求“review 这段代码”或“看看这次提交有没有问题”时，Agent 应该调用这个 Skill。执行流程分三步：先用 collect_diff 拿到变更，再让 analyze 跑静态检查，最后用 format_report 生成结构化报告。每一步有明确的输入输出说明，模型知道自己该在什么节点做什么决策。
这个设计有意思的地方在于“模型和脚本的分工”。真正逐行查逻辑的工作交给脚本，模型只负责“理解需求、编排流程、解释结果”。这样即使模型的推理能力不那么强，也能通过脚本过一遍基础检查，然后结合模型的理解输出高质量报告。这种“弱模型 + 好工具 > 强模型 + 没工具”的体验，是我用这个清单后最直接的感受。
3.3 社区提交如何保持质量下限
1000+ 的规模意味着什么？意味着一定有大量第三方开发者在向这个仓库贡献。人一多，质量就参差，这是开源世界的铁律。那么这份清单是怎么守住质量下限的？
从实际操作看，它做了三件事：
第一，自动化检查和强制格式。所有提交的 Skill 必须符合标准目录结构，SKILL.md 必须包含固定的字段（name、description、when_to_use、steps 等），不符合的直接被 CI 拒绝。依赖清单也必须经过安全扫描，有已知高危漏洞的包会被拦下。
第二，功能验证的沙箱机制。官方团队会维护一套测试用例，新的 Skill 提交后，会被放在隔离环境里，用真实的任务跑一遍。比如“PDF 提取”会被要求处理三个不同格式的样例文件，全部通过才能合入。这保证了 Skill 不是“看着能用”，而是“真能用”。
第三，活跃度管理。长期没有任何更新、且问题未被维护者回应的 Skill，会被打上“维护不活跃”的标签，甚至进入淘汰流程。我第一次看到这个机制还挺惊讶的，因为大多数开源仓库只进不出，能主动淘汰低质量内容，说明这个仓库是把“维护”当作长期承诺在做。
4. 实操：从零到一给 Agent 配齐 Skill
4.1 前期准备与基线检查
我假设你手头已经跑通了一个基础的 Agent 项目，不管是用官方 CLI 还是自己写 Python 代码调用都行。在开始往里面塞 Skill 之前，先做三个基线检查，不然后面出问题你都不知道从哪排查。
第一，确认 Agent 框架版本。Skill 清单是跟着框架走的，不同大版本的框架对 SKILL.md 的解析逻辑有差异。你可以在配置文件里查看版本号，或者用框架自带的命令打印版本。如果你用的是旧版本框架，建议先升级到最新稳定版，否则装了新格式的 Skill 可能识别不了。
第二，确认 Python 环境干净。我强烈建议建一个独立的虚拟环境给 Agent 用，不要直接用系统的全局 Python。因为装 Skill 的过程会拉取大量依赖，如果全局环境里已经有各种项目的历史依赖残留，很容易发生冲突。建新环境命令很简单：
python3 -m venv agent_env source agent_env/bin/activate第三，准备一个“任务测试集”。不要等装完了再想测试用例，提前写 3 到 5 个你真实会用到的小任务，比如“提取这个 PDF 的目录页”“把这段语音转成文字”“总结这个网页的核心观点”。后续每装一个 Skill，就用对应的任务测一遍，这样能快速判断哪个环节出了问题。
4.2 拉取官方清单与安装
有了干净环境后，拉取这份 76.6k Star 的清单本身只要一条命令：
git clone https://github.com/example/skills-repo.git cd skills-repo pip install -r requirements.txt（仓库地址我做了脱敏处理，实际使用请以官方文档为准。）
这里我多说一句：不要直接把这个仓库 fork 回来当成自己的版本管理。因为 1000+ Skill 的更新非常频繁，你 fork 一份之后，想再同步官方更新就得处理大量冲突，非常痛苦。更合理的做法是：把官方仓库作为一个“上游引用”，你在自己的项目里通过依赖的方式引入它，而不是把代码复制进来。
安装完基础依赖之后，可以跑一下官方自带的健康检查脚本，它会列出当前环境中哪些 Skill 的依赖没装全、哪些 Skill 跟你的框架版本不匹配。这一步能提前发现很多问题，省得后面一个个 Skill 试错。
4.3 三种启用方式：全量、分类、白名单
这是配置的核心环节，也是我踩过最多坑的地方。我实测下来，启用 Skill 有三种方式，适用场景完全不同：
方式一：全量启用。把清单里所有 Skill 都设为可用。适合本地开发、测试阶段，因为你也不知道哪个 Skill 有用，先全开着跑几天，观察日志里哪些 Skill 被触发得最频繁。但别在生产环境这么干，哪怕 Skill 是动态加载，框架启动时也会对全部 Skill 做一次扫描和校验，规模大了启动时间还是会变长。
方式二：分类启用。只启用“数据工作 + 开发辅助”这类跟你的业务强相关的分类。我自己的主力环境就是用这个模式，只开了四五个分类，目录索引小了，匹配精度反而更高。适合生产环境。
方式三：白名单精确启用。只精确指定几十个 Skill，不管分类。适合任务非常固定的场景，比如你的 Agent 只做“邮件处理”和“表格生成”两件事，那就别开全量了，精准白名单最省心。
配置方式一般是在 agent 的配置文件里加一段：
{ "skills_enabled": ["data_table", "pdf_extract", "web_summarize", "mail_draft"], "skills_scan_mode": "whitelist" }具体字段名以你用的框架为准，但思路是一样的。我第一次用的时候图省事直接全量启用，结果发现日志刷得飞快，一半是无关 Skill 的“尝试匹配失败”记录。改成白名单后，日志明显清爽，排查问题也容易多了。
4.4 给 Skill 配置实际参数
Skill 装完了，不代表它开箱就能用。很多 Skill 需要你提供外部配置，比如 API Key、文件路径、默认模板。这里我强烈建议：把配置放在 Agent 的环境变量或应用配置层里，不要改 Skill 源码。原因很简单——Skill 是跟着官方仓库存活的，你改了源码，下次 git pull 更新时就直接冲突了，之类的麻烦一堆。
以“邮件草拟 Skill”为例，它需要知道 SMTP 服务器地址、发件人邮箱、默认签名。正确的做法是在 .env 文件里写：
SMTP_HOST=smtp.example.com SMTP_PORT=465 SENDER_EMAIL=alice@example.com SENDER_NAME=Alice DEFAULT_SIGNATURE=Best regards, Alice然后 Skill 里的脚本通过读取环境变量拿到这些配置，而不是硬编码在代码里。这样做的好处有三个：升级 Skill 不丢配置、切换环境（测试/生产）不用改代码、敏感信息不会随着仓库提交。我的经验是，凡是需要登录或密钥的 Skill，一律走环境变量注入，永远不要放在 SKILL.md 里。
4.5 快速验证 Skill 是否生效
光配置完不算数，得有一套快速验证的手段。我的做法是三步：
第一步，看日志。把 Agent 的日志级别调到 debug，然后构造一个跟 Skill 触发条件完全匹配的最简任务。比如验证“网页抓取”Skill，就让它“抓取 example.com 的首页标题”。在 debug 日志里，你会看到框架扫描 Skill 的流程：先匹配描述、再判定意图、最后选定某个 Skill 并开始执行。如果日志里出现了“已匹配 skill: web_summarize”类似的信息，说明触发链路是通的。
第二步，查输出。Skill 执行完会返回结构化结果。以“网页抓取”为例，输出应该包含抓取时间、成功标志、正文摘要。如果脚本报错，日志里通常会有红字堆栈。这时候先看依赖有没有装齐，再看 API Key 有没有配对，这两条占了我全部排查经历的八成。
第三步，做对照实验。同一个任务跑两次，一次开 Skill，一次关掉 Skill。如果关掉后任务完成质量显著下降甚至直接失败，说明 Skill 真的在起作用，而不是“环境里本来就藏着能力”。这个对照步骤很多人跳过，但它能帮你确认这个 Skill 是否值得留在白名单里。
5. 常见问题与排查技巧实录
5.1 问题速查表
我整理了一张高频问题表，都是我自己和身边人实际碰到过的：
| 现象 | 大概率原因 | 处理办法 |
|---|---|---|
| 提示 Skill 不存在或无法加载 | 未把 Skill 目录加入扫描路径 | 检查配置文件里的 skills_path，确保指向仓库根目录 |
| 安装依赖时报包冲突 | 全局 Python 环境太脏 | 用虚拟环境重装，别硬解 |
| Skill 能加载但任务触发不了 | SKILL.md 的描述写得太泛 | 改白名单模式，或调整匹配阈值 |
| 脚本执行报错“模块缺失” | 依赖没装到当前环境 | 检查 pip list，确认 requirements.txt 有没有被安装进对应环境 |
| 中文路径或文件名乱码 | 系统编码不是 UTF-8 | 启动前设置 PYTHONUTF8=1 |
| 启动扫描耗时很长 | 全量启用了所有 Skill | 改用分类启用或白名单模式 |
| 更新后原来能用的 Skill 失效 | 上游框架或 Skill 接口变了 | 查看官方迁移文档，改配置适配 |
这张表我贴在了自己的笔记软件里，每次出问题就对着查。你会发现绝大多数问题不是“能力不行”，而是“环境配置没对齐”。
5.2 权限与安全：别忽略的隐性成本
Skill 虽然方便，但本质上是让 Agent 获得执行外部操作的能力。你在启用一个 Skill 时，相当于给 Agent 发了一张“操作许可证”。我在用这份清单时特别关注三种风险类型：
第一种是网络类 Skill。网页抓取、API 调用，这些技能会让 Agent 发起外部请求。在沙箱环境里跑没问题，但如果接到生产系统，就得考虑请求频率限制、目标域名白名单、以及返回内容的可信度校验。
第二种是文件系统类 Skill。文件读取、批量重命名、格式转换，这些技能如果权限过大，Agent 可能会误改到不该碰的文件。我建议给这类 Skill 指定一个专门的工作目录，比如 ./agent_workspace，在配置里把父目录访问权限禁掉。这个操作成本很低，但能避免“Agent 把你项目里的源码当草稿纸改掉”这种惨剧。
第三种是凭据管理类 Skill。凡是跟邮件、数据库、第三方系统对接的 Skill，都要做到“最小可用权限”。比如邮件 Skill 只给它一个专用发件账号，不要让 Agent 有机会用你的管理员账号发邮件。我在实际使用中专门建了一个配置模板，标注每个 Skill 需要的权限边界，按模板配置就不会漏。
这些安全考量在官方文档里其实都有提及，但很少有人强调。我的建议是：不管多着急，先把权限边界划清楚再启用新 Skill。你在本地折腾可以随意点，一旦准备推向生产，这条就是铁律。
5.3 从零写一个自己的 Skill：一个最简模板
这份清单最大的价值不只是“拿来用”，它还提供了一个清晰的标准，让你能把自己独有的能力贡献进去。我按照它的标准写过两个自定义 Skill，整体流程已经熟练到五分钟能搭出骨架。下面是最简模板：
my_tool/ ├── SKILL.md └── scripts/ └── run.pySKILL.md 的核心结构如下：
--- name: my_tool description: 当用户需要“从一串编号里提取订单号并查询状态”时使用 --- ## When_to_Use - 用户提到订单号、运单号、查询状态 - 用户给出编号列表并要求批量处理 ## Steps 1. 读取输入中的编号列表 2. 调用 run.py 解析并查询 3. 返回结构化结果：订单号、状态、预计时间 ## Requirements - requests>=2.31.0写完后在配置里把 my_tool 加进白名单，就可以直接用了。这里面最关键的是 description 的写法：不要写泛泛的“这是一个订单查询工具”，而要写“当用户提到订单号/运单号时使用”。因为框架是靠这套描述来决定匹配的，描述越具体，触发越准确，误触率越低。
这个模板让我意识到，官方清单的价值不仅是“给你 1000 个现成的”，更是给你一套“生产新能力的流水线”。以前我想给 Agent 加一个内部工具，得考虑接口设计、文档、调用约定；现在只需要按标准格式把脚本和说明写好，框架会自动完成调度和匹配。这份标准化，才是它在 76.6k Star 的背后真正值钱的部分。
5.4 我实测后的几条独家建议
最后说几条我在真实项目里跑出来的经验，这些不属于任何官方文档，纯粹是踩过坑之后攒下的。
第一，别一上来就想着“把 1000+ 全部配齐”。我第一次就是这个心态，结果日志爆炸、匹配错乱，反而不如一开始只开 20 个常用 Skill。正确路径是：先全量开一两天记录触发日志，然后根据日志收敛到白名单，最后只在白名单里做增量。
第二，一定要建立“本地快照”。这份清单更新很勤，但有时候新版本反而会引入问题。我每次觉得当前版本状态稳定，就打个标签或者复制一份快照目录。要不要升级，看你有没有遇到必须修的问题。稳定优先，追新放在第二位。
第三，把清单的分类标签融入自己的笔记体系。这套分类法本身就是很值钱的“任务图谱”。我遇到一个新需求，先不在 GitHub 里搜索，而是拿着任务描述去对照它的分类目录，确认“这个任务属于哪个能力域”。一旦归类清晰了，解决方案往往就水落石出。这个过程比你漫无目的地翻仓库高效得多。
第四，多留意触发描述（description）的措辞。我调试过很多次“Skill 明明装了却触发不了”的问题，最后发现都是 description 里的表述太抽象，框架在语义匹配时无法把用户任务和 Skill 对齐。你可以主动给描述加几个关键词变体，比如“PDF”“表格提取”“parse table”，命中率会明显提高。
把这份清单用顺手之后，我给 Agent 加新能力的流程从“翻 GitHub 一晚上”变成了“查分类目录十分钟”。真正花的成本不再是找代码，而是理解“我到底想让 Agent 做什么、边界在哪里”。不管你是刚接触 Agent 的新手，还是已经被各种插件折腾到怀疑人生的老用户，我都建议你从这份官方清单开始，先把它跑起来，再谈按需裁剪。你会发现，Agent 能力的上限，有时候真不是模型决定的，而是你手里那份技能清单的完整度决定的。
