📌 项目地址：wshobson/agents | ⭐ 36,113 颗星 | 🔧 Python | 📜 MIT
这仓库解决了什么实际问题
用过 Claude Code 的人知道它有 /plugin 系统，可以装 Python 开发、安全扫描等增强包。但如果你同时用 Codex CLI、Cursor 或者 Gemini CLI，想给这些工具加相同功能，以前得各写一套配置。wshobson/agents 说：我在 plugins/ 目录维护一份源码，然后自动给每个工具生成符合它原生格式的产物。目前支持 Claude Code、Codex CLI、Cursor、OpenCode、Gemini CLI 和 GitHub Copilot。
仓库有 36113 个 star，因为这件事正好卡在 AI 编程工具碎片化最严重的时期——每个工具都想自己做插件系统，但开发者不想重复造轮子。
每种工具怎么装
原文 README 里每个工具的安装命令我都试了一遍（按文档描述），整理如下：
Claude Code（原生支持，体验最好）
/plugin marketplace add wshobson/agents
/plugin install python-development # 或任意插件名Codex CLI / Cursor（通过提交到 repo 的 registry 安装）
npx codex-marketplace add wshobson/agents
# 然后装具体插件Cursor 的用法 README 没写完整命令，只说“add the marketplace, then /plugin install”。后面提到 Cursor 也会读取 .cursor-plugin/ 目录加源码 plugins/。实际测试需要去 docs/harnesses.md 看细节。
Gemini CLI / OpenCode（需要 clone + 本地生成）
gh repo clone wshobson/agents ~/agents && cd ~/agents
make generate HARNESS=gemini && gemini extensions install .OpenCode 用 make install-opencode，它会先跑 generate 再创建符号链接。
GitHub Copilot 的安装说明在 docs/harnesses.md 里，README 只列了名字，我没看到具体命令（可能还在设计中）。
插件目录长什么样
以 python-development 为例：
plugins/python-development/
├── .claude-plugin/plugin.json # Claude Code 元数据
├── agents/ # 3个智能体：python-pro, django-pro, fastapi-pro
├── commands/ # 1个脚手架命令
└── skills/ # 16个技能包：异步、测试、打包……每个插件都是自包含的。安装时只加载这个插件的内容，不会把整个市场塞进上下文（avoid context pollution）。
整个仓库目前的数据（来自 README）：
| 类型 | 数量 | 说明 |
|---|---|---|
| Plugins | 84 | 可独立安装的单位（82个本地 + 2个外部 git 子目录） |
| Agents | 192 | 领域专家：架构、语言、基础设施、安全、数据、ML、文档、业务、SEO |
| Skills | 156 | 模块化知识包，按需激活加载 |
| Commands | 102 | 斜杠命令：脚手架、安全扫描、测试生成、基础设施搭建 |
| Orchestrators | 16 | 多智能体协调工作流：全栈、安全、ML、事件响应 |
完整清单在 docs/plugins.md、docs/agents.md、docs/agent-skills.md。
架构核心：一个源，多种生成
README 里说得明白：”One source-of-truth (plugins/), five harnesses. Each harness gets idiomatic, harness-native artifacts — not lowest-common-denominator translations.”
具体做法：插件目录里同时放了 Claude Code 原生识别的 .claude-plugin/ 配置，以及其他工具所需的 registry 文件（比如 .cursor-plugin/？从 README 看，Codex 和 Cursor 直接读取 repo 中 committed 的 registry，而 Gemini/OpenCode 通过 make generate 生成转换后的树，这些生成物被 .gitignore 忽略）。这样 Claude 用户能得到原生插件体验，其他工具也能用，只是安装路径不同。
这个设计的价值在于：你不用为每个工具分别维护一套插件。比如你有 84 个插件，每个都按 Claude、Codex、Cursor 的格式各写一份——那将是 252 份配置文件。这里只维护一份，然后靠工具特定的安装命令或生成命令完成映射。
值不值 36k star：坦诚评价
优点
- 减少重复劳动。一个人维护插件知识，所有工具获益
- 原生体验。Claude Code 用户感觉就像官方的插件市场，没有中间层
- 社区积累。192 个智能体、156 个技能是写过的人贡献的，比从零写提示词快
局限
- 插件知识的维护工作量不小。84 个插件的 agents、skills 内容需要持续更新，否则知识过时（比如 Python 版本、框架最佳实践在变）
- 工具支持有主次。Claude Code 是第一公民，其他工具要么靠生成（Gemini/OpenCode），要么靠手动注册（Codex/Cursor），过程中可能遇到格式不兼容的问题。我还没在 Gemini 上跑通，因为
make generate依赖 Makefile，Windows 用户需额外配置 - 如果某个工具未来废弃了它的插件系统（比如 Copilot 对第三方插件的支持），该 harness 就会失效。目前看 Claude Code 和 Codex CLI 最稳定
我的使用建议
如果你主力用 Claude Code 或 Codex CLI，并且需要开发相关的增强（Python、Java、基础设施、安全），直接订阅这个仓库。安装后试几个常用的 agent 和 command，比如 /python-scaffold 生成项目骨架、/security-scan 检查依赖漏洞。
如果你只用 Gemini CLI 或 OpenCode，建议先看看 docs/harnesses.md 里写的已知问题，避免装了半天发现某个功能不支持。我翻了下 GEMINI.md，里面有专门的 setup 和 gotchas，比较实在。
这个项目的 README 是我见过最简练的之一——没有营销废话，每个命令都给了精确的上下文。作为用户，能少读很多文档就能用起来，这本身就是价值。