GitHub 趋势 · 第 32 期
你在 Codex 里装的插件，都出自这个 6,378 star 的仓库
#Agent工具#插件生态#官方仓库
我的判断：这个仓库一行「功能」都没有，但它决定了你在 Codex 里能看到、能装到哪些插件。它不是工具，是一份目录。README 第一句就把定位说得很直白——"a curated collection of Codex plugin examples"，Codex 插件示例的精选集合。你在客户端里看到的那个可安装清单，源头就是它里面的 .agents/plugins/marketplace.json。所以这一期不聊「怎么用」，聊的是一个更少被讨论的问题：当你的编码 Agent 开始有「应用商店」，这个商店的货架是谁摆的、货是从哪进的。
痛点场景：过去一年，我们这一系列写过不少 Agent 技能与插件——从 archify 到 superpowers，从 vercel-labs/skills 到 NVIDIA 的 SkillSpector。共同点是：装之前你总得自己判断「这东西靠不靠谱」。
但官方插件市场的出现，把判断方式变了。清单里躺着一百多个名字，看起来都是「官方的」——可它到底是官方自己写的代码，还是把第三方的包搬进了自己的仓库？装上去之后，代码是谁在维护、什么时候同步、同步的是哪个版本？这些问题在 UI 上通常只呈现为一行名字和一个「安装」按钮。而答案，恰好都写在这个仓库的提交记录里。
项目是什么
openai/plugins，仓库简介只有三个词：OpenAI Plugins。它 2026 年 3 月建仓时只有一句 placeholder README，6 月补上正式内容，最近一次提交在 2026-09-08。总 star 6,378、fork 837，本周新增 +753。
按 README 的约定，每个插件住在 plugins/<name>/ 下，必须带一个 .codex-plugin/plugin.json 清单，可选附带 skills/、.app.json、.mcp.json，以及插件级的 agents/、commands/、hooks.json、assets/。市场清单分两份：默认那份给普通用户，另一份 api_marketplace.json 面向 API key 登录的用户。
清单文件自己的描述是 name: openai-curated，displayName: Codex official。也就是说，你在 Codex 里看到的那个「官方」标签，指的就是这份 curated 清单——它是一份人工维护的收录名单，不是自动同步的镜像。
核心能力：把清单拆开看
我把默认市场清单拉下来数了一遍，一共 65 个插件条目，落在 10 个分类里。分布很不平均：
| 分类 | 条目数 | 代表条目 |
|---|---|---|
| Developer Tools | 27 | github、vercel、cloudflare、sentry、supabase、datadog、expo、coderabbit、temporal |
| Productivity | 12 | linear、notion、google-calendar、airtable、dropbox、clickup |
| Creativity | 9 | figma、canva、adobe、remotion、hyperframes、higgsfield |
| Communication | 5 | gmail、slack、teams、outlook-email、zoom |
| Education & Research | 4 | zotero、consensus、life-science-research、ngs-analysis |
| Data & Analytics | 3 | posthog、mixpanel-headless、data-analytics |
| Finance | 2 | stripe、public-equity-investing |
| Security / Business & Operations / Scientific Research | 各 1 | codex-security、shopify、boltz-api-cli |
除了数量，有三个细节值得单独拎出来：
- ▪62 个条目是「仓库内」的，3 个是「仓库外」的。前 62 个用
source: local指向本仓库的./plugins/xxx；三个例外是 CrowdStrike 的两个（直接指 GitHub 仓库地址）和 Qodo 一个（git-subdir，指向上游仓库的codex-packages/qodo子目录）。 - ▪每个条目都标了鉴权时机：大多数是
ON_INSTALL（装的时候就要求授权），7 个是ON_USE（用到才授权），其中就包括codex-security、public-equity-investing、data-analytics这几个敏感方向。 - ▪本系列写过的东西也在这份清单里。第 14 期的 obra/superpowers 是清单里的 superpowers（Developer Tools），第 18 期的 heygen-com/hyperframes 是清单里的 hyperframes（Creativity）。一个开源项目从「有 star」到「被官方目录收录」，在 Agent 生态里基本等同于拿到了分发渠道。
README 另外点名了几个「内容更丰富」的示例：plugins/figma（use_figma、Code to Canvas、Code Connect、设计系统规则）、plugins/notion（规划、研究、会议、知识沉淀）、plugins/build-ios-apps / build-macos-apps / build-web-apps（写 App 的全流程）、plugins/expo，以及 netlify、remotion、google-slides。
上手：这个仓库没有「安装命令」
这句话得说在前头，免得你 clone 下来发现不知道干什么。它不是给你 pip install 的东西，它是给客户端读的目录。README 里没有任何安装章节，唯一算得上「用法」的是两段约定——一是插件目录长什么样，二是市场清单放在哪：
# 一个插件包的结构（取自 README 原文） plugins/<name>/ .codex-plugin/plugin.json # 必需：插件清单 skills/ # 可选 .app.json # 可选 .mcp.json # 可选 agents/ commands/ hooks.json assets/ # 可选，插件级 # 两份市场清单（取自 README 原文） .agents/plugins/marketplace.json # 默认市场，指向 ./plugins .agents/plugins/api_marketplace.json # API key 登录用户
如果你是想「自己写一个插件」的开发者，那这套结构就是你要对齐的规范：写一个 .codex-plugin/plugin.json，把能力拆进 skills/、commands/、hooks.json，需要外部服务就加 .mcp.json。真想让插件出现在官方清单里，从前面的提交记录看，走的是 PR 审核制——仓库里那些「新增某插件到 curated marketplace」的提交，就是这条路。
我的判断
适合谁：正在给 Codex 写插件或 skill、想知道「官方认的结构长什么样」的开发者——这仓库就是那份事实规范，比任何二手教程都准；做企业采购或工具选型、需要说清「我们装的这个插件是谁在维护」的人；以及单纯想看看大厂怎么摆 Agent 应用商店货架的人。它信息密度不低，只是信息都在目录结构和 JSON 里，不在 README 的正文里。
不适合谁：想找一个开箱即用的工具来试的人——这里没有可运行的程序，装上也不会多出任何功能；以及指望它当「官方背书」来判断插件质量的人，原因见下面第一条坑。
几个坑（全部能从仓库的 README 与提交记录里读到原文）：
- ▪「收录」不等于「官方自研」，也不等于「代码干净」。README 自己的措辞是 examples（示例），清单名是 curated（精选）。提交 #390 的说明里写明：50 个精选插件中，Public Equity Investing 的测试套件有 30 个既有失败（"The complete 204-test Public Equity suite has 30 existing failures"），官方核实后确认这些失败在上游未修改的发行版里同样存在。收录是分发动作，不是质量认证。
- ▪大部分第三方插件的代码，是被「搬」进这个仓库的。同样来自 #390：这批插件是从各自的 release 下载后提交进来的（"Eight bundles were downloaded from their current releases"），每个插件包含完整 bundle、
.app.json与插件清单。好消息是供应链收敛在一处、官方做过审计（提交里提到扫描了 869 个文本文件找凭据与私钥模式、编译了 166 个 Python 文件）；代价是你拿到的版本取决于官方同步节奏，不是上游最新。 - ▪反而那三个不在仓库里的条目，是「活」的。Qodo 那条在收录说明里明确写了 follows the upstream default branch without a pinned ref——不钉版本、跟上游默认分支。CrowdStrike 两条直接指 GitHub 仓库地址，同理。这类条目的内容随时可能变，装的时候心里要有数：版本锁定在「仓库内条目」上是明确的，在「仓库外条目」上是没有的。
- ▪给 API key 用户的那份市场清单，仓库自己注明还没生效。提交 #333 的原文是 "note this doesn't take effect yet, we still need to wire up the plugins sync"。也就是说，
api_marketplace.json文件已经进仓库了，但同步链路还没接上——如果你是走 API key 登录的，别拿这份清单的条目数去对你在客户端里实际看到的东西。 - ▪仓库根目录没有 LICENSE 文件（文件树就
.agents、plugins、.gitignore、README.md四项）。这在意料之中——它是目录不是代码，各个插件的许可以各自上游为准。但如果你要把某个插件的代码copy进自己的项目，得回去看那个插件原始仓库的许可，别拿「它在官方仓库里」当授权依据。 - ▪别把它和别家的市场搞混。这一期只看 Codex 的目录；Claude 生态有自己的插件市场（含官方与社区两条线），Cursor 也有自己的插件规范仓库，两边都是独立维护、收录标准不同。
仓库：github.com/openai/plugins
总 star：6,378（截至 2026-09-11，本周 +753）；fork 837；主语言 JavaScript
许可证：仓库根目录未提供 LICENSE 文件；各插件许可以其上游仓库为准
清单规模：65 个插件条目 / 10 个分类（62 个仓库内条目 + 2 个 url 源 + 1 个 git-subdir 源）
活跃度：最近提交 2026-09-08；最近一次较大变更 #392（Add Qodo to curated marketplaces）
数据来源：GitHub Trending 官方页面 + 仓库 README / 文件树 / .agents/plugins/marketplace.json / 提交记录 #390、#392、#333
抓取时间：2026-09-11 05:40（GMT+8）
想问一句：你的团队在 Codex、Claude Code 这类工具里装插件，是有审核流程，还是看到名字顺眼就装？装完之后，有没有人真的去对过「仓库里这份代码」和「上游最新版」差了多远。评论区聊聊你们的做法。
下期预告：这一期聊了 OpenAI 的插件目录，下一期想把镜头转到另一家——cursor/plugins（7,365 star，本月 +4,683），Cursor 的插件规范与官方插件仓库，正好可以做一次跨平台对照：两家的市场是怎么组织的、收录标准差在哪、同一个 skill 迁过去要不要改。若核实后内容不够撑一期，就换月榜上的 volcengine/OpenViking（36,493 star，本月 +8,284）。
#Agent工具#插件生态#官方仓库