Skip to content

09-extensions-plugins-skills-mcp-lsp.md

Latest commit

 

History

History
177 lines (121 loc) · 6.16 KB

09-extensions-plugins-skills-mcp-lsp.md

File metadata and controls

177 lines (121 loc) · 6.16 KB

09. 扩展体系：Plugins、Skills、MCP、LSP

这篇讲什么

这一章把四条扩展链路放在一起讲：技能、插件、MCP、LSP。它们是 Claude Code 从“内建 CLI”演化为“可扩展平台”的核心。

先给结论

从当前快照看，Claude Code 的扩展能力不是单点机制，而是至少有四套并行体系：

  • markdown/frontmatter 驱动的 skills
  • 带 marketplace/builtin 概念的 plugins
  • 面向外部工具和资源的 MCP
  • 面向编辑器语义能力的 LSP

它们既各自独立，又会在命令系统、工具系统和 AppState 中汇合。

源码依据

Mermaid 图：扩展体系汇合图

flowchart LR
    A[skills] --> E[commands / SkillTool]
    B[plugins] --> E
    B --> F[MCP servers / LSP servers]
    C[MCP] --> G[MCPTool / resources / prompts]
    D[LSP] --> H[LSPTool / editor semantics]
    E --> I[commands.ts]
    F --> J[AppState.plugins / AppState.mcp]
    G --> J
    H --> J
    I --> K[用户入口]
    J --> K
Loading

Skills：更轻量的能力注入

src/skills/loadSkillsDir.ts 暴露了 skill 体系的几个关键事实：

  • 它支持从不同 source 加载 skills 或 commands 目录。
  • skill 内容基于 markdown/frontmatter 解析。
  • 会处理 description、allowedTools、whenToUse、hooks、paths、model、effort 等 frontmatter。
  • 可以区分 inline 和 fork 执行上下文。

这说明 skill 更像“带元数据的可注入 prompt/工作流片段”，而不仅是文本模板。

Plugin：更完整的分发与集成单元

src/types/plugin.ts 显示，一个 plugin 可携带的东西远不止命令：

  • commands
  • agents
  • skills
  • hooks
  • output styles
  • MCP servers
  • LSP servers
  • settings

而 src/plugins/builtinPlugins.ts 又表明插件至少分成两类：

  • 内建插件
  • 其他来源插件

内建插件会出现在 /plugin UI 中，并可以被启用或禁用。

Plugin 命令与 Skill 是怎么映射的

src/utils/plugins/loadPluginCommands.ts 很关键，因为它展示了插件 markdown 文件如何变成命令：

  • 会递归收集 markdown 文件。
  • 会识别 SKILL.md。
  • 会根据目录层级生成命令命名空间。
  • 同时支持普通 markdown 命令文件和 skill 目录。

这说明插件并不是只能装“二进制功能”，它也能装 markdown 驱动的命令和 skill。

Plugin Schema 说明了什么

src/utils/plugins/schemas.ts 表明插件生态并不只是“随便从网上拉代码”，它至少考虑了：

  • marketplace 名称规范
  • 官方 marketplace 名称保留
  • impersonation/homograph 风险
  • 相对路径校验
  • .mcpb / .dxt bundle 路径

这反映出插件体系已经进入了“需要市场和分发治理”的阶段。

MCP：外部工具和资源接入层

src/services/mcp/client.ts 可直接确认 MCP 客户端支持多种 transport：

  • StdioClientTransport
  • SSEClientTransport
  • StreamableHTTPClientTransport
  • WebSocket transport

同时它还负责：

  • 连接 MCP server
  • 列工具、列资源、列 prompts
  • 处理认证与 session 失效
  • 处理 tool call result 与内容截断/持久化

这意味着 MCP 在 Claude Code 里不是单个工具，而是完整的外部能力总线。

MCP 配置从哪里来

src/services/mcp/config.ts 展示了 MCP 配置来源和写入方式：

  • 当前目录下的 .mcp.json
  • 全局/项目/托管配置
  • plugin 提供的 MCP servers
  • Claude.ai/enterprise 相关配置

该文件还表明：

  • 写 .mcp.json 时会做原子写入与权限保留。
  • plugin 提供的 MCP server 会做签名级去重。

LSP：语义能力接入层

src/services/lsp/manager.ts 说明了 LSP 的工作方式：

  • 全局单例管理器。
  • 启动阶段异步初始化。
  • 失败时不会阻塞整个系统。
  • 至少一个 server 健康连接时，LSP 能力才算可用。

这是一种比较标准但很实用的“后台初始化、前台按可用性降级”的做法。

这四套扩展如何汇合

它们最终会进入这些汇合点：

  • 命令系统：plugin commands、plugin skills、bundled skills、dynamic skills
  • 工具系统：MCPTool、SkillTool、LSPTool
  • AppState：mcp、plugins、agentDefinitions
  • UI：/plugin、/mcp、/skills

对使用者的意义

如果你是用户，这一层决定了：

  • 你能否安装或启用插件。
  • 某些命令是不是来自插件/skill，而不是内建命令。
  • Claude Code 是否能调用外部 MCP server。
  • 语义编辑、诊断、跳转等编辑器能力是否可用。

对研究者的意义

如果你是研究者，这一层决定了：

  • 平台的扩展边界在哪里。
  • 哪些能力是内建，哪些是后装。
  • 哪些地方需要额外关注供应链与权限风险。

这一章的工作结论

Claude Code 的扩展体系已经明显超出“命令插件”范畴，而是形成了 prompt、市场、协议、编辑器语义四条并行能力线。理解这一点，才能正确判断某个功能究竟属于核心内建能力，还是一个外接扩展面。

延伸阅读