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 是分发层。MCPModel Context Protocol不只是工具集合MCP 是一个标准协议Claude Code 用它来连接外部工具和服务。它的全称是 Model Context Protocol——这个命名本身就透露了设计意图它不只是给模型加工具而是给模型提供上下文。一个 MCP 服务器可以暴露三类能力Tools工具Claude Code 可以调用的函数通过/mcp__serverName__toolName访问Resources资源Claude Code 可以读取的数据如文件内容、数据库 schemaPrompts提示模板预定义的提示词片段可被当作 slash command 使用MCP 的执行架构Claude Code 通过 stdio 或 HTTP 与 MCP 服务器通信。在 stdio 模式下Claude Code 启动子进程通过 JSON-RPC 格式的 stdin/stdout 收发消息// MCP 通信协议简化interfaceMCPRequest{jsonrpc:2.0id:numbermethod:stringparams?:{name?:stringarguments?:Recordstring,unknown}}interfaceMCPResponse{jsonrpc:2.0id: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.mdSKILL.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 confidenceFrontmatter 的关键字段字段作用name成为/name命令出现在/菜单descriptionClaude 用来判断是否自动触发的关键词disable-model-invocationtrue 只能手动调用不自动触发user-invocablefalse 隐藏菜单只作为背景知识allowed-toolsClaude 使用此 skill 时可用的工具白名单context: fork在独立子 Agent 上下文运行不污染主对话agent子 Agent 类型Explore、Plan、general-purposepathsglob 模式限制此 skill 在哪些路径下激活自动触发的判断机制这是 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**: N1 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.mdplugin.json是关键{name:tdd-workflow,version:1.0.0,description:Enforces Test-Driven Development workflow,authors:[Your Name youexample.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代码质量循环工具hookifyHooks 配置示例合集研究这些插件的源码是学习如何写好 Skill 和 Hook 的最佳途径。三者如何配合一个真实场景你在公司搭建了一个代码审查流水线。MCP 层连接 GitHub MCP 服务器获取 PR 信息、提交记录、代码 diffSkills 层定义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而是通过亲手实现来加深对每个子系统的理解。