Cursor开源120+插件,Agent接管一切

我最近把 cursor/plugins 翻了一遍。第一反应不是“哇好强”，而是“终于有人把这件事写下来了”。

AI 编程助手的问题从来不是模型笨。你给它一个干净的新项目，它写得挺好。但让它进一个跑了三年的仓库，它就开始瞎猜：不知道你们不用 any，不知道提交前要跑 typecheck，不知道那个 utils 目录是历史遗留不许动。每次开新对话都像换了个新来的实习生，你还得从头讲一遍规矩。

💡 引言：MCP 火了两年，大家以为多装几个 server 就解决了。结果是协议有了，怎么组织这些能力、怎么管上下文、怎么写规则，全靠各团队自己摸索。三个月后 prompt 文件变成没人敢删的垃圾堆，这个场景我见过太多次。

所以 cursor/plugins 这个仓库值得看一眼。2026 年 1 月开源，现在 14703 star、1514 fork，TypeScript 为主，MIT。定位写在描述里：插件规范加官方参考实现。

🚀 它到底给了什么

仓库结构很朴素。根目录一个 marketplace.json 汇总所有插件，每个插件一个目录，里面一个 plugin.json 清单，再加上 skills/、rules/、mcp.json 这几样。

我觉得有意思的地方在于它把上下文分了层。

• •
  plugin.json 只放元数据，名字、作者、分类、描述。Agent 挑工具的时候扫一眼就行，几乎不占上下文。
• •
  rules/*.mdc 是常驻的，项目级约束，比如“不许用 any”。这类东西本来就该一直在。
• •
  skills/SKILL.md 是按需的，带 frontmatter，只有任务相关时才注入。

你可以理解成：rules 是贴在墙上的员工手册，skills 是抽屉里的操作手册。大部分时间抽屉是关着的。

对比一下很多团队的做法——把所有规范拼成一个五千行的 system prompt 每次都塞进去——这套分层至少在成本上更讲道理。

continual-learning 那个插件我觉得更值得看。它把对话增量提炼成短条目追加到 AGENTS.md，只留真正值得记的。记忆文件最怕的就是越滚越脏，滚到最后模型自己都不看。这个设计算是正面回应了那个问题。

🚀 编排这块，官方给了几个参考实现

orchestrate 是 planner / worker / verifier 三个角色加结构化交接。大任务先拆，分发下去，最后 verifier 收口。它想解决的是单体 agent 越写越偏还自己发现不了的问题。

thermos 做的是分支审查。安全审计、正确性检查、一份挺严的代码质量评分表、并行子代理，还有可选的 merge-ready PR 流程。我看了一下评分表的维度，不是那种“代码写得很优雅”的客套话，是真的会挑刺。

ralph-loop 是让 agent 反复迭代到收敛。名字来自 Ralph Wiggum。听起来有点玄，实际就是把“生成、验证、修正”这条链显式化。

advisor 的逻辑是成本分层：平时用便宜模型跑量，卡住了或者要做大决策了，再去问更强的模型。

还有 pstack、dyl-stack、pr-review-canvas、docs-canvas 这些，风格各不相同。pstack 是先想清楚再动手，写得少但质量高；dyl-stack 强调先找根因再打补丁。这些不是能直接用的产品，更像别人的工作流摆在那里给你参考。

🚀 MCP 集成：一百多个目录

third_party/ 下面是重点。GitHub、Playwright、Gmail、Google 全家桶、Salesforce、HubSpot、Zoom、Shopify、QuickBooks、Workday、飞书、X、BigQuery、Statsig、Tailscale，基本覆盖了常见的 SaaS。

两个细节能看出官方确实想过生产环境。

QuickBooks 插件里写明了：所有创建、更新、发送动作，先给预览，用户确认后才执行。这条不是客套话，是底线。Agent 直接改账本这种事，出了就是事故。

tailscale 插件让 agent 通过你的 tailnet 访问内网 MCP server，每个成员用自己的设备。企业内网这块，算是给了个能落地的路子。

🚀 和别的方案比

自己堆 prompt 当然也行，但你写不出 thermos 那套评分体系，也很难自建一百多个 SaaS 的封装。这不是能力问题，是规模问题。

Copilot Extensions 那类东西是把 AI 塞进 IDE 的按钮里。cursor/plugins 更像是把 IDE 变成 agent 的操作系统。区别在于前者给你功能，后者给你一套怎么组织功能的范式。

通用 MCP 客户端只有协议，没有规范，各家用各自的写法，生态是碎的。这个仓库至少把 marketplace 和清单格式定下来了。

🚀 装之前，几个真实的坑

• •607 个 open issue。
  生态跑得太快，插件质量参差。上生产前自己把 SKILL.md 读一遍，别只看描述。
• •别一次装十个。
  skills 是按需加载没错，但 rules 是常驻的。装多了等于给自己塞噪声，反而拖慢。
• •凭据问题。
  这些集成要 OAuth token，用最小 scope，别把主账号 token 交给 agent，写操作一定要 preview。
• •插件会持续更新
  ，建议 pin 住 commit，纳入 code review。
• •最后一条：别把 verifier 当免责声明。
  AI 审查能挡住大部分低级错误，架构层面的判断还是得人来。thermos 挑刺挑得再狠，它也不知道你们下个季度要往哪走。

🚀 想试试的话

git clone https://github.com/cursor/plugins.gitcd plugins && ls third_party/github/.cursor-plugin/

挑一个插件，按 plugin.json、skills/SKILL.md、rules/*.mdc 的顺序读一遍，十分钟能看懂范式。

然后把需要的目录放进项目的 .cursor/ 下，或者用 create-plugin 脚手架自己建一个。

rules 换成你们团队的规范，mcp.json 换成你们自己的 server。

先跑通一个再说。

🚀 我的判断

这个仓库的价值不在那 120 个插件。插件会过时，模型会换代。

团队的差距以后可能不在选哪个模型，而在你有没有把工作流沉淀成可复用的资产。模型大家都能用，资产是攒出来的。

不过也别把它当银弹。14700 star 说明关注度高，不代表每个插件都能直接用。挑几个真正对得上你痛点的，读代码，改，再上。剩下的大部分，让它躺在收藏夹里也没什么损失。