从 Playwright 插件源码出发搞清楚三种扩展机制的运行方式、进程模型与适用场景引言在使用 Claude Code 的过程中我安装了一个 Playwright 插件用于浏览器自动化操作。但随之而来一系列疑问这个插件到底装了什么它是 Skill、MCP Server 还是 Plugin它们之间有什么区别.claude/目录下哪些地方可以放自定义脚本本文记录了我的完整探索过程。一、从一个 Playwright 安装说起我在 Claude Code 的settings.json中加了一行配置{enabledPlugins:{playwrightclaude-plugins-official:true}}重启后我的工具列表多了 24 个浏览器工具browser_navigate、browser_click、browser_snapshot等。那么问题来了——这些工具是怎么来的1.1 从插件到 MCP Server安装的插件文件位于C:\Users\用户名\.claude\plugins\cache\claude-plugins-official\playwright\关键文件是.mcp.json{playwright:{command:npx,args:[playwright/mcplatest]}}所以这个插件本质上就是一个配置封装——它告诉 Claude Code启动时通过npx拉起playwright/mcp这个 MCP Server。1.2 真正干活的代码在哪里MCP Server 的实际代码在 npx 的缓存目录%LOCALAPPDATA%\npm-cache\_npx\9833c18b2d85bc59\node_modules\playwright\mcp\ ├── package.json → playwright/mcp v0.0.78由 Microsoft 维护 ├── cli.js → 入口调用 playwright-core 的 MCP 工具注册函数 └── index.js → 导出 createConnection 依赖 ├── playwright → v1.62.0-alpha ← 真正的浏览器控制引擎 └── playwright-core → v1.62.0-alpha ← MCP 协议实现调用路径如下Claude Code └─ 启动时 spawn npx playwright/mcp常驻进程PID 41664 └─ node cli.js └─ 加载 playwright-core └─ 启动 Chromium 浏览器实例 └─ 等待 JSON-RPC 指令我在终端验证了这一点——电脑上确实有 4 个 node 进程在跑其中 2 个是npx壳进程2 个是cli.jsMCP Server一个是旧实例一个是当前活跃实例。二、Skill、MCP、Plugin 的三角关系通过 Playwright 和另一个开源项目 claude-vision-skill 的对比我搞清了三种模式的区别。2.1 三种模式对比表维度SkillMCP ServerPlugin本质注入到 Claude 的 prompt 指令独立运行的常驻进程Skill MCP Hook 的打包有进程吗无有node 常驻进程取决于内含什么通信方式纯文本写在 prompt 里stdin/stdout JSON-RPC组合上述两种安装方式放.claude/skills/name/SKILL.md放.mcp.json或settings.json/plugin install自动下载何时用告诉 Claude 怎么想/怎么做需要运行时代码浏览器、数据库、API一个功能需要多部分配合2.2 案例分析claude-vision-skill这个开源项目的文件结构非常简单claude-vision-skill/ ├── CLAUDE.md ← 告诉 Claude遇到图片不要用 Read调 node vision.js └── vision.js ← 一个独立脚本调千问 VL API 识图vision.js不是常驻进程被node vision.js xxx.jpg一次性调用就退出。所以它天然适合用Skill方式接入。接入方法把CLAUDE.md改名为SKILL.md顶部加上 YAML frontmatter--- name: vision description: 让无识图能力的模型通过调用千问 VL API 实现识图 --- # 识图能力 你的底层模型不具备原生识图能力。遇到图片时**不要用 Read 工具** 改用 vision.jsnode vision.js 图片路径 用中文描述这张图片然后放入.claude/skills/vision/SKILL.mdvision.js放入同目录scripts/下。2.3 决策流程当你拿到一个开源仓库按下面的线索判断看仓库里有什么文件 │ ├── 只有 .md / prompt 文件 │ → Skill不需要二进制放 .claude/skills/ │ ├── 有 package.json bin 入口如 cli.js │ → MCP Servernpx 启动配置在 .mcp.json │ └── 同时有 .mcp.json plugin.json skill 提示词 → Plugin走 /plugin install三、.claude/目录的标准结构经过查证官方推荐的.claude/目录结构如下项目根目录/ ├── CLAUDE.md ← 项目说明自动加载 ├── .mcp.json ← MCP Server 定义 ├── .claude/ │ ├── settings.json ← 项目级配置 │ ├── settings.local.json ← 本地配置不提交 git │ ├── commands/ ← 自定义斜杠命令/xxx │ │ └── deploy.md │ ├── agents/ ← 子智能体定义 │ │ └── code-reviewer.md │ ├── skills/ ← 技能 │ │ └── vision/ │ │ ├── SKILL.md ← 技能说明 │ │ └── scripts/ ← 技能引用的脚本 ✅ │ │ └── vision.js │ └── rules/ ← 条件规则glob 匹配加载 │ └── frontend.md关键结论Skill 的scripts/目录可以放源码——这是设计意图不是滥用普通项目脚本不要放.claude/下——它们是通用工具属于项目scripts/目录没有.claude/tools/这个目录——这是我之前猜的经查证并不存在四、附加思考npm vs npx vs pipx在探讨二进制管理方式时还延伸出了关于包管理的对比。4.1 npm 的隔离方式npm install局部 npm install -g全局 ─────────────── ───────────────── node_modules/ 全局 node_modules/ ├── package-a/ 所有包混在一起 ├── package-b/ 升级冲突是常态 └── package-c/ └── node_modules/ ← 冲突时嵌套解决 └── dep2.0/Node 生态不太需要 “pipx 等价物”因为npm install默认局部隔离且有嵌套解决冲突的能力。4.2 Python 为什么需要 pipx# pip 的 site-packages 是**纯扁平**的site-packages/├── package_a/├── package_b/├── dep_x/← 只有一个版本A 和 C 冲突即炸 └── dep_y/所以 Python 需要 pipx/venv 做物理隔离。4.3 快速对照场景NodePython局部隔离npm install天生venvpip install全局隔离不太需要pipx install✅即用即走npx缓存 14 天pipx run依赖冲突处理嵌套 node_modules不支持靠 venv 物理分隔五、总结Skill 注入 prompt 的文字指令可附带脚本在scripts/目录MCP Server 常驻后台进程通过 JSON-RPC 与 Claude Code 通信Plugin Skill MCP Hook 的打包一键安装区分三者的最快方法看仓库里有没有package.json bin 入口.claude/skills/是放自定义 Skill 和脚本的正确位置Python 工具用pipxNode 工具用npx/局部npm install各取所需本文基于 Claude Code DeepSeek v4-pro 环境实测所有进程状态、文件路径均为真实输出。