wshobson/agents：一个从单一 Markdown 源生成五种 CLI 工具体系的插件市场
插件市场，汇集 94 个智能体插件、203 个代理、175 项技能与 109 条命令，统一以一份 Markdown 源维护，可被 Claude Code、Codex CLI、Cursor 等原生使用。
秒懂
- 它是什么？
- 这个仓库把 93 个插件、202 个 agent、181 个 skill 从一套 plugins/ 目录同时输出到 Claude Code、Codex CLI、Cursor、OpenCode 和 Copilot。它不是简单复制文件，而是为每个工具生成原生格式。
- 适合谁用？
- 如果你同时在 Claude Code 和 Codex CLI 或 Cursor 之间切换，并且受够了为每个工具单独维护一套 prompt 和 skill，这个仓库值得一试。它把内容源和工具适配分开，make generate 一次就能得到五种原生格式。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 2 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是多工具内容同步问题
很多团队在 Claude Code 里写了一套 agent 和 skill，换到 Codex CLI 或 Cursor 时发现格式不兼容，要么重写，要么用最低公分母的通用格式将就。wshobson/agents 的出发点正好相反：一套 plugins/ 目录作为唯一事实来源，然后通过 make generate 为五种 harness 生成各自的原生工件。README 里强调这不是 lowest-common-denominator translations，而是每个 harness 得到 idiomatic 的产物。这个定位很明确，它服务的是已经在多个 agentic CLI 之间切换的开发者，而不是只用一个工具的人。
从 plugins/ 到五种 harness 的生成机制
仓库的核心是 plugins/ 目录，每个插件是一个独立单元，包含 .claude-plugin/plugin.json、agents/、commands/ 和 skills/ 子目录。安装时只加载该插件的组件进上下文，而不是整个市场。生成过程由 Makefile 驱动，make generate-all 产出全部五种。Claude Code 是源格式，直接使用 marketplace.json 和 plugins/。Codex CLI 生成 .agents/plugins/marketplace.json 和每个插件的 .codex-plugin/plugin.json，其中 skills 和 agents 被 gitignored，只有注册表提交。Cursor 生成 .cursor-plugin/ 和 .cursor/rules/，并复用 .claude/ 目录。OpenCode 生成 .opencode/ 下的 agents、commands、skills，并且从 tools: allowlist 映射出 permission: 块。Antigravity 则是每个源插件生成一个自包含的 .antigravity/plugins/<p>/ 目录。这个设计的关键在于，每个适配器都要处理目标工具的约束，比如 Codex 有 8 KB skill 大小限制，命令被转换成 skill。
安装方式因工具而异
安装路径不是统一的。Claude Code 用 /plugin marketplace add wshobson/agents，然后 /plugin install python-development 安装单个插件。Codex 和 Cursor 通过提交在仓库里的注册表直接安装，Codex 用 npx codex-marketplace add wshobson/agents。Antigravity 和 OpenCode 需要先克隆仓库，然后运行 make generate HARNESS=antigravity 和 make install-antigravity，或者 make install-opencode，后者会运行 generate 并创建符号链接。这意味着如果你只想用 OpenCode，你仍然需要克隆整个仓库，而不能像 Codex 那样只添加注册表。这个差异在 README 里写得很清楚，但初次使用容易忽略。
插件内容与分层模型策略
仓库里统计有 93 个插件、202 个 agent、181 个 skill、105 个命令和 16 个 orchestrator。这些数字来自 README，我没有逐一验证。内容按领域划分，包括架构、语言、基础设施、安全、数据、ML、文档等。模型策略分五个层级，从 Tier 0 的 Fable 5 用于长时自主任务，到 Tier 4 的 Haiku 用于快速操作任务。Tier 2 是 inherit，表示使用用户当前选择的模型。这个分层是给 agent 内容指定默认模型用的，不是强制性的。实际使用中，如果你不认同这个分层，可能需要逐个修改 agent 配置，这是定制成本的一部分。
质量评估框架 plugin-eval
仓库自带一个名为 plugin-eval 的评估框架，位于 plugins/plugin-eval/。它分三层：静态分析是确定性的结构检查，耗时不到 2 秒且免费；LLM Judge 用 Haiku 和 Sonnet 对四个维度做语义评估，大约 30 秒；Monte Carlo 通过 50 到 100 次模拟运行统计可靠性，需要 2 到 5 分钟。命令是 uv run plugin-eval score path/to/skill --depth quick 和 uv run plugin-eval certify path/to/skill。这个框架的意义在于，它把 skill 质量从主观判断变成可重复的检查。但注意 certify 依赖 LLM 判断，这意味着评估结果会受模型版本和 prompt 影响，不是完全确定性的。如果你要把它接入 CI，需要接受这个不确定性。
外部集成与维护成本
仓库包含一个外部 git-subdir 条目 Pensyve，用于 Claude Code 的 memory 集成。Pensyve 本身维护对 Codex、Cursor、OpenCode 和 Copilot 的直接集成，但尚未支持 Antigravity。这意味着如果你用 Antigravity，你无法通过这个市场获得 Pensyve 的功能。维护方面，仓库提供了 make validate 做结构检查，make garden 检测漂移、死链接和大小超限。这些命令说明项目考虑了长期维护，但多 harness 生成意味着每次修改 plugins/ 都需要重新生成并验证所有目标。如果你的团队不熟悉 Makefile 和这些检查，维护成本会高于单工具方案。
限制与适用边界
这个仓库不是银弹。首先，它只解决内容分发，不解决 agent 能力本身，你的 skill 写得好不好仍然取决于内容质量。其次，多 harness 生成并不保证功能完全对等，README 明确指向 docs/harnesses.md 查看能力矩阵，说明每个 harness 的产物有差异。比如 Codex 的命令被转换成 skill，这可能丢失斜杠命令的交互语义。第三，Antigravity 和 OpenCode 需要克隆仓库并运行 make，这比 Codex 的注册表方式重。最后，模型分层策略中 Tier 0 的 Fable 5 标记为 opt-in 且 premium cost，如果你不小心配置了长时任务，可能会产生意外费用。
编辑结论
如果你同时在 Claude Code 和 Codex CLI 或 Cursor 之间切换，并且受够了为每个工具单独维护一套 prompt 和 skill，这个仓库值得一试。它把内容源和工具适配分开，make generate 一次就能得到五种原生格式。但如果你只用单一工具，或者你的团队不允许依赖个人维护的仓库，那它的多 harness 优势对你没有意义。先验证三件事：第一，docs/harnesses.md 里的能力矩阵是否覆盖你需要的功能，因为每个 harness 的生成产物并不完全一致；第二，Codex 和 Cursor 的注册表是提交在仓库里的，但 skills 和 agents 是 gitignored 的，你需要确认安装流程会从源重新生成；第三，plugin-eval 的 certify 命令是否满足你的质量门槛，它依赖 LLM 判断，不是纯静态检查。这个项目解决的是内容分发问题，不是 agent 能力本身，你的 prompt 质量仍然取决于你写的 skill 内容。
社区笔记