Cursor 插件仓库开源：双格式与 Marketplace 机制

一个编码 Agent 的能力边界由什么决定？模型之外，答案越来越落在它挂载的工具上。Cursor 给出的做法是把插件做成一等公民：官方插件仓库 cursor/plugins 在 GitHub 开源，当前 4,382 star、366 fork，仓库创建于 2026 年 1 月，提交活跃至 8 月下旬。这个仓库同时承载了两件事：Cursor 插件规范的参考实现，以及 33 个可以直接安装的官方插件。

一个插件里能装什么

Cursor 文档的定义没有绕弯子：插件把 rules、skills、agents、commands、MCP servers、hooks 打包成可分发的 bundle。每种组件的分工如下：

表格里的两列对应两种格式，也是这套体系里最值得搞清楚的分界线。

双格式：开放标准与厂商扩展

第一种格式叫 Agent Plugins，是 open standard，规范版本 1.0.0，官网在 agent-plugins.org。它只打包两样东西：Agent Skills 和 MCP servers，manifest 是插件根目录的 plugin.json，需要带标准 schema 标识。这个标准的技术指导委员会成员来自 Amazon、Cursor、Microsoft、OpenAI 和 Vercel 的核心维护者，提案和决策全部公开。

第二种格式叫 Cursor Plugins，manifest 放在 .cursor-plugin/plugin.json，在标准格式之上增加 rules、agents、commands、hooks 和变量系统。两种格式可以在同一个 marketplace 里并存分发，Cursor 从 manifest 位置自动识别格式，安装流程一致。

兼容性设计上有一条关键承诺：符合 Agent Plugins 规范的插件在 Cursor 里无需修改即可加载。也就是说，一个想同时覆盖多个 agent 客户端的插件作者，可以只维护一份可移植包；需要用到 Cursor 专属能力时再加扩展层。这与 MCP（协议层标准）和 Agent Skills（技能格式标准）形成三层结构：协议、技能、打包分发各管一段。

仓库结构：marketplace 清单加独立插件目录

cursor/plugins 是一个多插件 marketplace 仓库。根目录的 .cursor-plugin/marketplace.json 列出全部 33 个插件，每个插件是独立目录，自带 manifest：

plugins/
├── .cursor-plugin/
│   └── marketplace.json    # marketplace 清单（列出所有插件）
├── plugin-name/
│   ├── .cursor-plugin/
│   │   └── plugin.json     # 单插件 manifest
│   ├── skills/             # Agent skills（SKILL.md + frontmatter）
│   ├── rules/              # Cursor rules（.mdc 文件）
│   ├── mcp.json            # MCP server 定义
│   ├── README.md
│   └── CHANGELOG.md
└── ...

33 个插件的构成：13 个 Cursor 官方工具类插件在仓库根目录，20 个三方产品集成放在 third_party/ 目录下，包括 gmail、google-drive、google-calendar、salesforce、playwright、github、zoom、x、gong、hubspot、intercom、clay、docusign、navan、profound、juicebox、outreach、amplemarket、ashby、circleback。

manifest 实例：playwright 插件

以 playwright 插件的 .cursor-plugin/plugin.json 为例，字段结构一目了然：

{
  "name": "playwright",
  "displayName": "Playwright",
  "version": "1.0.0",
  "minClientVersions": { "cursor": "3.13.0" },
  "description": "Navigate, click, screenshot, and test in a real browser.",
  "author": { "name": "Cursor", "email": "[email protected]" },
  "homepage": "https://github.com/microsoft/playwright-mcp",
  "repository": "https://github.com/cursor/plugins",
  "license": "MIT",
  "logo": "assets/logo.svg",
  "keywords": ["playwright", "browser", "automation", "testing", "e2e", "mcp"],
  "category": "integrations"
}

几个字段值得注意。minClientVersions 声明客户端版本门槛（playwright 要求 Cursor 3.13.0 及以上），这给插件依赖新 API 时提供了灰度手段。homepage 指向 microsoft/playwright-mcp，说明 MCP server 部分直接复用微软官方实现，Cursor 插件层做的是打包和规则封装。README 标注仓库整体为 MIT 许可，同时每个插件的 manifest 单独声明 license 字段。

官方插件都在解决什么问题

按仓库 README 的分类过一遍 13 个官方工具类插件，能看出 Cursor 自己把插件体系用在了哪些环节：

编排与并行方向，orchestrate 把大任务扇出到多个并行云 agent，内部按 planner、worker、verifier 角色划分并做结构化交接；thermos 做深度安全与正确性审计，用并行 subagent 跑严苛的代码质量评分；ralph-loop 实现自引用的迭代式 AI 循环（官方描述里叫 Ralph Wiggum 技术）。

评审与文档方向，pr-review-canvas 把 PR diff 按重要性分组渲染成评审画布，docs-canvas 把文档渲染成可导航的画布。这两个插件对应 Cursor 新加的 canvas 能力，官方还提供了 Hex Canvas（数据可视化）和 Atlassian Canvas（Jira 与 Confluence 实时视图）两类预置模板。

工程基建方向，cursor-team-kit 封装 CI、代码评审、发布、本地自动化和验证的团队工作流；create-plugin 负责新插件脚手架和校验；agent-compatibility 用 CLI 扫描仓库兼容性并审计启动、校验和文档；cli-for-agent 沉淀了一套 CLI 设计模式，覆盖 flags、带示例的 help、管道、错误处理、幂等和 dry-run，目标是让 CLI 能被编码 agent 可靠调用；cursor-sdk 对接 TypeScript SDK；continual-learning 用高信号要点做 AGENTS.md 的增量记忆更新；teaching 面向技能图谱、练习计划和复盘。pstack 由 Lauren Tan 维护，主打少写代码、写高质量代码的并行工作流。

三方集成里最典型的案例是 Google Workspace。Cursor 在 8 月 3 日的 changelog 中专门介绍了 Gmail、Google Drive 和 Google Calendar 三个插件：agent 可以搜索和读邮件、起草发送消息、打标签管理会话，可以搜索和组织 Drive 文件，可以读写日历、找空闲时段，全程不用离开 Cursor。

分发与治理：Marketplace 怎么运转

插件的分发载体就是 Git 仓库。官方 Marketplace（cursor.com/marketplace）里的每个插件都经过人工审核，且必须开源，更新版本同样要过审。社区插件和 MCP server 则放在 cursor.directory。

安装路径：在 Cursor 侧边栏打开 Customize，找到目标插件，点 Install 并选择 project 或 user 作用域。

企业侧有独立的 team marketplace 机制。Teams 计划可建 1 个团队 marketplace，Enterprise 计划不设上限。管理员通过 Dashboard 的 Plugins 页面管理，支持从 GitHub 仓库导入，或用官方模板仓库 fieldsphere/cursor-team-marketplace-template 起步。每个插件可选三种下发模式：Default Off（开发者自行决定是否安装）、Default On（默认安装但可退出）、Required（强制安装且不可卸载）。权限可以按 Organization Groups 收窄，组成员支持通过 SCIM 从身份提供商同步。

自动更新依赖 Cursor GitHub App：开启 Auto Refresh 后，仓库每次 push 都会触发重新索引，最快粒度为每 10 分钟一次，连续 push 会被合并到最新 commit 处理。对于从 GitHub 整体导入的 marketplace，Auto Refresh 每次 push 都会重读完整 manifest，新增插件自动被发现。

自己写一个插件要几步

第一步，建目录选格式。只需要可移植的 skills 和 MCP server，选 Agent Plugins：根目录放 plugin.json、skills/ 和 mcp.json。需要 rules、agents、commands 或 hooks，选 Cursor Plugins：manifest 放 .cursor-plugin/plugin.json。

第二步，写 manifest。Agent Plugins 的最小模板：

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "my-plugin",
  "description": "Portable code review tools",
  "version": "1.0.0",
  "author": { "name": "Your Name" }
}

第三步，本地测试。把插件目录放到 ~/.cursor/plugins/local/my-plugin，重启 Cursor 或执行 Developer: Reload Window，验证 rules、skills、MCP server 是否正确加载。迭代阶段可以 symlink 仓库目录进 local 路径，免掉反复复制。

第四步，提交发布。入口在 cursor.com/marketplace/publish，多插件仓库用 .cursor-plugin/marketplace.json 声明清单。官方还提供 cursor/plugin-template 模板仓库和 agent-plugins.org 的作者指南作为起点。

对开发者的实际影响

这套体系对不同角色的意义可以分开看。写内部工具的团队，team marketplace 加 Required 模式等于把「全组统一 lint 规则、统一提交规范」从 wiki 文档变成随 IDE 分发的强制配置，SCIM 组同步让权限跟着身份提供商走，不需要在 Cursor 里手工维护名单。做 SaaS 产品的团队，third_party/ 里 20 个集成插件给出了现成模板：接 MCP server、配 skills 和 rules、写好 plugin.json 就能进官方 Marketplace 的审核队列，相比自己维护浏览器扩展分发链路要短。插件作者最关心的跨客户端问题，Agent Plugins 标准给了明确答案：可移植层只包含 skills 和 MCP server，这部分一次打包多处可用；rules、hooks 这类与客户端行为耦合的组件留在各家的扩展命名空间里，不打肿标准本身的体积。

版本管理上有两个容易踩的点。minClientVersions 只做门槛声明，依赖新 API 的插件需要自己维护版本策略，老客户端上装了新插件的行为取决于客户端的容错而非 manifest。Auto Refresh 的 10 分钟合并窗口意味着高频 push 的仓库不会即时反映每个 commit，CI 里跑插件一致性校验的话，等待窗口要按这个粒度预估。

对整个编码 agent 生态，这个仓库把「插件」从各家私有格式推向了事实上的分层标准：MCP 管协议，Agent Skills 管技能格式，Agent Plugins 管打包分发，三层各自的治理都已经在公开仓库里运转。Cursor、OpenAI、Amazon、Microsoft、Vercel 同坐一个技术指导委员会，这个信号本身比 33 个插件的内容更有分量。

来源

• cursor/plugins 仓库（README、marketplace.json、playwright manifest、GitHub API 元数据）
• Cursor 文档：Plugins
• Agent Plugins 开放标准
• Cursor Changelog：Google Workspace Plugins（2026-08-03）