共计 3685 个字符，预计需要花费 10 分钟才能阅读完成。
https://www.anthropic.com/news/claude-code-plugins
目前用户可以便捷地整合 斜杠命令、子智能体、MCP 服务器、钩子 ，这标志着生态系统建设的重要进展。
OpenAI 之前也推出过 ChatGPT 插件，并且最近发布了 ChatKit 和 agent-builder。
你对 Claude Code Plugin 的未来发展有怎样的看法？
当前一线企业在生态竞争的态势又是怎样的？
Codex 是否有可能紧随其后？
Anthropic 再次进军市场，此次推出了全新的 Claude Code Plugin 插件系统（Customize Claude Code with plugins Anthropic）。根据官方的解释，这一系统旨在构建与分享模块化 AI 组件，并支持基于 Git 的去中心化分发方式。
1. 插件架构：为“可组合智能体”量身定制
Claude Code 插件系统的核心由四个主要部分组成，这些部分通过一个中央的 plugin.json 清单文件进行管理：
- 斜杠命令 (Slash Commands)：在 commands/ 目录下，为常见或复杂的任务设置自定义快捷方式。
- 子智能体 (Subagents)：位于 agents/ 目录下，专为特定任务（如 security-reviewer 或 performance-tester）设计的“专家”智能体。主 Claude 智能体能够自主调用这些子智能体以协作完成任务。
- 钩子 (Hooks)：在 hooks.json 中定义的事件驱动触发器，允许在工作流的关键时刻（例如文件写入后）自动执行操作，如运行代码格式化工具或测试套件。
- MCP 服务器 (Model Context Protocol)：在 .mcp.json 中定义，负责连接外部工具、API 和数据源。
完整插件的目录结构大致如下所示：
enterprise-plugin/
├── .claude-plugin/ # 元数据目录
│ └── plugin.json # 必需：插件清单
├── commands/ # 默认命令位置
│ ├── status.md
│ └── logs.md
├── agents/ # 默认智能体位置
│ ├── security-reviewer.md
│ ├── performance-tester.md
│ └── compliance-checker.md
├── hooks/ # 钩子配置
│ ├── hooks.json # 主要钩子配置
│ └── security-hooks.json # 额外钩子
├── .mcp.json # MCP 服务器定义
├── scripts/ # 钩子和实用脚本
│ ├── security-scan.sh
│ ├── format-code.py
│ └── deploy.js
├── LICENSE # 许可证文件
└── CHANGELOG.md # 版本历史
其中，.claude-plugin/plugin.json 是清单文件，提供必需的元数据信息。
值得一提的是，Claude Code 插件的层级结构似乎参考了 VS Code 和 Chrome 插件的理念，例如都使用核心清单文件（plugin.json 对比 package.json 和 manifest.json）来描述插件的元数据和入口点。同时，VS Code 插件可以向命令面板添加新命令（类似斜杠命令的功能），而钩子的概念则与 VS Code 的“激活事件”或 Chrome 插件的事件监听器（例如 onMessage）相似，都是在特定事件发生时触发相应逻辑。
然而，Claude Code 插件的基本哲学却截然不同，这一架构旨在服务于“可组合智能体”（Composable Agency）：高阶的“工作流协调器”插件能够编排多个单一功能的子智能体，实现端到端的自动化流程，例如全栈开发或安全加固。这已超越了传统 IDE 插件的能力范围。
2. 基于 Git 的去中心化分发模式
Anthropic 此次最具创新性的举动是其分发模式。它没有选择传统的中心化应用商店，而是构建了一个 基于 Git 的去中心化市场系统。任何包含 marketplace.json 文件的 Git 仓库都可以成为一个市场，用户可以通过 /plugin marketplace add user/repo 命令进行添加。
这种基于 Git 的原生方法显然汲取了 OpenAI 第一个版本的 ChatGPT 插件商店的教训，有效规避了几个关键问题：
- 高开发者门槛：OpenAI 要求开发者自行托管 API，导致许多插件被搁置。而 Claude Code 仅需要一个 Git 仓库即可。
- 可组合性不足：OpenAI 系统难以在单一工作流程中链接多个插件，造成了用户体验的碎片化。Claude Code 的子智能体架构正是为了解决这一问题。
- 中心化瓶颈：单一商店导致审核缓慢，劣质插件泛滥。
- 安全风险：用户数据被发送到大量未经审查的第三方服务，造成了巨大的隐私隐患。
3. 挑战：模型的“黑箱”与功能不足
虽然这套插件系统具备不少优势，但也存在短板。目前开发者面临的最大挑战源于底层 Claude Code 的不透明性。这个“黑箱”至少带来了以下几个关键问题：
- 行为不可预测 ：开发者无法精确控制主智能体
何时或为何调用某个工具或子智能体，调试过程更像是“提示工程”，而非确定性的软件开发。 - 缺乏可观测性：平台缺少检查模型推理过程的工具，开发者无法访问“决策日志”或设置“断点”。
- 性能天花板：任何插件的最终效果都受到 Claude Code 或更底层基座模型核心能力的限制，再优秀的设计也无法突破模型的根本性限制。
坦率地说，Anthropic 在工具层面的封闭策略令人费解。一方面是封闭的 Claude Code（这一部分显然没有基座大模型的技术壁垒），另一方面又在大力提倡开源的插件生态，这本身就显得矛盾且讽刺。
此外，作为一个新推出的插件系统，它还缺乏一些对构建复杂智能体至关重要的功能：
- 高级状态管理：系统缺乏明确机制，使得插件无法在不同用户会话间保持持久状态，这限制了构建需要长期记忆的智能体能力。
- 精细化的安全权限：虽然插件中的每个子组件都有权限控制策略，但插件框架本身似乎缺乏一个全局的精细沙箱化权限系统，用户在安装时无法为特定插件授予特定能力（例如，“允许只读访问 /src 目录”），这使得整个插件看起来仍处于一种原始的组件拼装阶段。
- 进程守护：随着插件数量的增加，Claude Code 本身逐渐变得复杂，随之而来的就是长时调用带来的一系列问题。它无法实现真正的、长期的、无人监督的自主运行，也缺乏在后台持续监控代码库或在中断后自动恢复任务的能力。当然，这一问题似乎可以通过特定插件来间接解决，但毫无疑问，原生集成的方案在性能上会更具优势。
4. 插件市场的策略：去中心化与中心化的平衡
Anthropic 选择去中心化的插件市场确实是一项大胆的决策，但在开放式创新与企业级控制之间也不可避免地引发了根本性的矛盾，特别是对于企业客户：
- 安全性：恶意行为者可以轻易发布执行有害命令或窃取敏感数据的插件，造成严重的安全隐患。
- 质量与可靠性：缺乏官方系统化战略支持，生态可能会变成充满废弃、有缺陷或低质量插件的“蛮荒西部”，侵蚀用户信任。
- 发现难题：随着社区市场数量的增加，用户难以找到符合其特定需求的高质量、可信赖的插件。
因此，Anthropic 未来很可能会走向一种混合或“联邦化”的市场模式，让中心化与去中心化共存，构建一个多层次的生态：
- 官方插件市场：由官方策划、审查和推荐，提供最高级别的信任保障。
- “认证创作者”方案：为优秀的社区开发者提供官方认可。
- 社区与私有市场：继续支持现有的基于 Git 的生态系统，以促进快速创新、服务特定小群体，并允许企业建立完全私有的内部插件市场。
5. 竞争态势：与 Codex 的直接对抗
如果说上半年 Claude Code 的表现令人瞩目，那么最近几个月，开发者们目睹了 OpenAI 的 Codex 迅速崛起，随着 GPT-5 系列模型的全面可用（GA）和 Codex CLI 的开源，这一领域的竞争愈发激烈。当前的开源工具链为 Codex 赢得了社区的支持，形成了与 Anthropic 封闭模式的鲜明对比。同时，随着新发布的 Codex SDK，OpenAI 显然在为其智能体生态系统奠定基础。一个专为 Codex 设计的复杂插件系统可能随时问世，这将对 Claude Code 的核心战略形成直接而强有力的挑战。
总体来看，新的 Claude Code 插件系统展示了 Anthropic 建设其“Coding 宇宙”的雄心。它使开发者能够为特定场景灵活定制工具和智能体。然而，OpenAI 的快速响应能力也不容小觑，一旦 Claude Code 的插件模式被成功验证，Codex 可能凭借其开源工具链的优势实现逆袭。这场竞争究竟哪一方将最终获胜，让我们拭目以待！
