Claude Code 源码解读 07：插件、Skills 与 MCP——三层扩展体系

Claude Code 源码解读 07：插件、Skills 与 MCP——三层扩展体系

如果把 Claude Code 想象成一台电脑，工具系统是它的 CPU，权限和 Hooks 是它的安全与 BIOS，那插件/Skills/MCP 就是它的应用程序层。但这三者不是同一个东西——它们解决不同层次的问题，理解它们的分工，你才能用对工具。

先理清这三个概念

我见过太多人把这三者混为一谈："我想扩展 Claude Code，用 MCP 还是 Skills？"这个问题本身就问错了。更准确的问法是：我要连接外部工具（MCP），还是要定义可复用的行为流程（Skills），还是要打包分享一整套配置（Plugins）？

三者不是替代关系，而是层层递进的打包单位：

MCP Server → 工具的提供者（连接外部系统） Skills → 行为的定义者（告诉 Claude 怎么做） Plugins → 配置的打包者（把技能、钩子、配置打成可分享的包）

MCP 是协议层，Skills 是执行层，Plugins 是分发层。

MCP：Model Context Protocol，不只是"工具集合"

MCP 是一个标准协议，Claude Code 用它来连接外部工具和服务。它的全称是 Model Context Protocol——这个命名本身就透露了设计意图：它不只是"给模型加工具"，而是"给模型提供上下文"。

一个 MCP 服务器可以暴露三类能力：

Tools（工具）：Claude Code 可以调用的函数，通过/mcp__serverName__toolName访问
Resources（资源）：Claude Code 可以读取的数据（如文件内容、数据库 schema）
Prompts（提示模板）：预定义的提示词片段，可被当作 slash command 使用

MCP 的执行架构

Claude Code 通过 stdio 或 HTTP 与 MCP 服务器通信。在 stdio 模式下，Claude Code 启动子进程，通过 JSON-RPC 格式的 stdin/stdout 收发消息：

// MCP 通信协议（简化）interfaceMCPRequest{jsonrpc:"2.0"id:numbermethod:stringparams?:{name?:stringarguments?:Record<string,unknown>}}interfaceMCPResponse{jsonrpc:"2.0"id:numberresult?:{contents:Array<{type:'text'|'image';text?:string;data?:string}>}error?:{code:number;message:string}}

MCP 工具的权限透传

一个容易踩的坑：MCP 服务器暴露的工具，其权限行为遵循 MCP 服务器本身的配置，而不是 Claude Code 的权限规则。也就是说，如果你的 MCP 服务器配置为允许所有操作，Claude Code 的denied规则可能管不到它。

反过来，MCP 工具可以被denied规则过滤，但一旦通过了过滤器，具体能做什么取决于 MCP 服务器的实现。这是 MCP 协议去中心化设计的一体两面——灵活性换来了配置复杂度的上升。

延迟加载：2026 年的重要改进

如果你配置了 50+ 个 MCP 工具，每次启动 Claude Code 都要把它们的 schema 加载到上下文里，会消耗大量 token。Claude Code 的解决方案是延迟加载：

启动时：只加载工具名称 → API 调用包含 defer_loading: true 首次调用时：通过 ToolSearch 动态加载完整 schema

这让 MCP 工具的上下文开销从"50 个完整 schema"降到"50 个工具名称 + 按需加载"。

Skills：可自动触发的行为定义

Skills 是 Claude Code 2026 年最重要的统一扩展模型。在旧版本里，slash commands 和 skills 是两个分离的概念——commands 靠用户手动触发，skills 靠模型自动匹配。现在它们已经合二为一。

SKILL.md 的结构

一个 Skill 就是一个文件夹，里面有SKILL.md文件。文件夹结构如下：

my-skill/ ├── SKILL.md # 主文件，定义行为 ├── scripts/ # 可选辅助脚本 │ ├── validate.sh │ └── format.js └── references/ # 可选参考文档 └── api-docs.md

SKILL.md的内容分两部分：YAML frontmatter（控制触发方式）+ Markdown 正文（定义行为）：

--- name: tdd-workflow description: Enforce TDD workflow: Red-Green-Refactor discipline for code changes disable-model-invocation: false user-invocable: true allowed-tools: Bash(npm:*), Bash(git:*), Read, Edit, Write context: fork agent: general-purpose argument-hint: <description of what to test> paths: - "src/**/*.ts" - "src/**/*.tsx" --- # TDD Workflow You are enforcing Test-Driven Development discipline. ## Rules 1. **Red**: Write a failing test BEFORE any implementation 2. **Green**: Write minimal code to make the test pass 3. **Refactor**: Improve code while keeping tests green ## Workflow $ARGUMENTS For each feature: 1. Write the test file first 2. Run tests to confirm failure (RED) 3. Write minimal implementation 4. Run tests to confirm pass (GREEN) 5. Refactor with confidence

Frontmatter 的关键字段

自动触发的判断机制

这是 Skills 最巧妙的部分。当用户描述一个任务时，Claude 会检查所有已加载 skill 的description字段，用 Embedding 或关键词匹配找到相关的 skill，然后自动激活它们。

这意味着你不需要记住要调用哪个 skill——Claude 会根据任务上下文自己判断。这与 MCP 的工具发现机制异曲同工，但 MCP 发现的是外部工具，Skills 发现的是内部行为流程。

实战：一个 production-readiness 检查 skill

--- name: production-check description: Check code changes for production readiness before deployment disable-model-invocation: false user-invocable: true allowed-tools: Bash, Read, Grep, Glob context: fork agent: Explore --- # Production Readiness Check Review recent changes for production deployment readiness. ## Checklist 1. **Tests**: Are there tests for changed code? 2. **Error handling**: Are error cases handled? 3. **Logging**: Is production logging appropriate (not verbose DEBUG)? 4. **Security**: Any hardcoded secrets or SQL injection vectors? 5. **Performance**: N+1 queries or obvious performance bottlenecks? 6. **Documentation**: Are API changes documented? Review files in ${CLAUDE_SKILL_DIR}/references/ for team standards.

这个 skill 可以手动调用（/production-check），也可以被自动触发（当任务涉及"部署"、“上线”、"发布"等关键词时）。

Plugins：打包、分发与共享

Plugins 是三者中最直接了当的概念——它是把 Skills、Hooks、Agents、MCP 配置和说明文档打包成独立目录结构的机制。

目录结构

my-plugin/ ├── .claude-plugin/ # 插件元信息目录（不要放在里面的子目录） │ └── plugin.json # 插件清单 ├── skills/ │ └── my-skill/ │ └── SKILL.md ├── agents/ │ └── my-agent.md ├── hooks/ │ ├── hooks.json │ └── hooks-handlers/ │ └── session-start.sh └── README.md

plugin.json是关键：

{"name":"tdd-workflow","version":"1.0.0","description":"Enforces Test-Driven Development workflow","authors":["Your Name <you@example.com>"],"skills":["skills/tdd-workflow"],"agents":["agents/tdd-auditor.md"],"hooks":["hooks/hooks.json"],"allowedPermissionMode":"acceptEdits"}

与普通配置的对比

为什么不用.claude/目录下的直接配置，而要打包成插件？

答案是可移植性。~/.claude/skills/是你个人的配置，my-plugin/可以发布到 GitHub、NPM 或 Claude 的插件市场。别人安装你的插件，不需要手动复制文件，一条命令搞定全部。

# 安装插件claude pluginaddgithub-username/my-plugin# 或者本地开发claude --plugin-dir ./my-plugin

官方插件生态

Claude 维护了一套官方插件，包括：

• security-guidance：代码安全扫描钩子
• learning-output-style：学习风格的输出格式化
• explanatory-output-style：详细解释模式的输出
• ralph-loop：代码质量循环工具
• hookify：Hooks 配置示例合集

研究这些插件的源码是学习如何写好 Skill 和 Hook 的最佳途径。

三者如何配合

一个真实场景：你在公司搭建了一个代码审查流水线。

MCP 层：连接 GitHub MCP 服务器，获取 PR 信息、提交记录、代码 diff
Skills 层：定义code-reviewskill，告诉 Claude 如何做审查、检查哪些方面
Plugins 层：把上述所有打包成company-code-review插件，发布给团队成员

用户：`/code-review`（或：Claude 自动触发） → 激活 code-review skill → 通过 GitHub MCP 获取 PR 数据 → 通过 Hook 检查 diff 是否有敏感操作 → 生成审查报告

这就是三层扩展体系的典型应用：MCP 提供外部数据源，Skills 定义行为逻辑，Plugins 负责打包分发。

理解扩展体系的设计哲学

回顾这三层，有一个清晰的演进路径：

MCP是最早出现的，解决的是"Claude 能连接什么外部系统"的问题。它的设计受 REST API 的影响——工具、资源、提示模板，这些概念都是从传统 API 设计里借鉴的。

Skills是后来出现的，解决的是"如何让 Claude 遵循特定工作流程"的问题。它的设计受 LLM 原生思维的驱动——description-based 触发、fork 隔离上下文、自动加载。

Plugins是打包层的整合，解决的是"如何把配置变成可分发产品"的问题。它的设计受 package manager 的影响——清单文件版本锁定、依赖声明、自动发现。

理解这个演进，能帮助你判断什么时候用哪个工具，以及如何组合它们。

下一章，我们将综合运用本系列的所有知识，从零搭建一个简化版的 Code Agent——这不是为了替代 Claude Code，而是通过亲手实现来加深对每个子系统的理解。