MCP 实战手册：边界、分工与 Windows 配置坑

谁解决什么

Plugin 是容器，里面可以塞 Skills、.mcp.json、commands、hooks；Skill 读手册；MCP 开通道。缺一层事就做不全，但单干一个 Skill 时没必要硬套插件壳。

MCP：连接层

• 传输：stdio（本地）+ Streamable HTTP（远程）。独立 SSE 已废弃，新接入别再写 sse。
• 配置：claude mcp add 或手写 .mcp.json。
• 作用域：local / project / user。

MCP 只负责接通；怎么用好那条连接，是 Skill 的事。

Skills：能力层

• 一个文件夹 + SKILL.md（YAML + 正文）。
• description 决定会不会被自动唤起：写糊了等于白装。
• slash command 已并入 Skills：.claude/commands/deploy.md 与 .claude/skills/deploy/SKILL.md 都会注册 /deploy。
• 可手动 /skill-name；只想手触、别自动：disable-model-invocation: true。
• 路径：~/.claude/skills/ · .claude/skills/ · 插件内 skills/。
• 渐进披露：元数据常驻，正文与脚本用到才加载。

Skill ≠ 子代理：子代理另起上下文；Skill 是塞给当前 agent 的说明书。

Plugin：分发层

1
my-plugin/
2
├── .claude-plugin/
3
│   └── plugin.json    # 只有清单在这里
4
├── commands/
5
├── skills/
6
├── agents/
7
├── hooks/
8
└── .mcp.json

何时上 Plugin：已经攒了一组 Skill + MCP，要给团队一键装。单个 Skill 或一条 MCP，直接放就行。

选型怎么判

1. 要摸外部系统 → MCP
2. 要固定流程、恰当时机自己上 → Skill
3. 只要手动快捷 → Skill（命令式轻量写法）
4. 要整包交付 → Plugin
5. 要独立上下文/工具集 → 子代理，别拿 Skill 硬顶

常见误会：Skills 与 MCP 二选一（其实常并用）；Skill 只能自动触发；slash 与 Skill 两套机制；还在用已废弃 SSE；插件目录放错。

相关阅读

• Skill 装不上，多半是目录或多套了一层
• Claude Code 必装 MCP：先三件，再慢慢加

素材来源：CSDN 原文

MCP：统一怎么接外面

MCP（Model Context Protocol）是开放连接标准：AI 应用用同一套规矩发现、暴露、传递和调用外部能力——数据源、工具、工作流、外部应用。

官方说法（2026-08-11 核对）：开源标准，用来把 AI 应用接到外部系统；类比就是 AI 侧的 USB-C——值钱的是统一插头，不是某一个外设。见 modelcontextprotocol.io/introduction。

记住这句就够：重点不是某个工具，而是统一连接方式。

Skills：把「做得对」打包带走

Skills 是可复用能力包：说明、知识、脚本、模板……把领域里怎么把事做稳的经验捆好，任务来了直接调用。

周报：接得上 × 做得对

别空谈互补，看一张销售周报怎么叠。

1. MCP：数据库 / 文件系统 / 搜索——原料接得上
2. Skills：先查哪些表、周报结构、风险检查、脚本模板——方法复用
3. 产出：像样的销售周报

只有插头没有菜谱，会乱炖；只有菜谱接不上库，是纸上谈兵。

三层栈：模型 · 连接 · 任务组织

把 MCP / Skills 塞进成熟 AI 的分层里，误会基本消掉。

公式六个字：模型 + 连接 + 任务组织。
选型时先问「我缺的是插头还是菜谱」，别再问「MCP 和 Skills 哪个更强」。

跟旁边那张三件套卡别搅

本篇不讲 CLI，也不讲具体怎么配某个 Host。若要「连接 / 方法 / 执行」三件一起看，站内已有：一张图讲清 MCP、Skills 和 CLI 怎么分工。彼=三件选型；本篇=两概念层位 + 三层栈，别硬并成一篇。

三件东西，各管一块

分不清时先对号：要不要动手、要不要按套路做事、要不要连外面。

不是替代，是叠在一起用

图中间是 AI Assistant，三件分别贴到不同部位：

• Skills → 教它怎么做
• CLI → 帮它动手执行
• MCP → 帮它连外部世界

图脚那句够用：Skills 管方法，CLI 管执行，MCP 管连接。

不是谁取代谁。缺方法会瞎干，缺手脚落不了地，缺连接就困在本地沙盒。

先想清楚你要哪种能力

选型顺序可以很粗暴：本地命令/文件/环境 → CLI；要稳定复用同一套做法 → Skills；要跨系统拿数据/调服务 → MCP。

实战里怎么叠

图上三块是叠着的，不是三选一：

1. Skills = 告诉 AI 怎么做
2. CLI = 让 AI 真正去执行
3. MCP = 让 AI 连上更多工具和数据

最佳实践：通常不是三选一，而是组合使用。

例：用 Skills 固化流程 + 用 CLI 执行命令 + 用 MCP 连接知识库。

页脚快速记忆也顺手背掉：

传输与 scope

user：claude mcp add / list / remove；-e 传环境变量，-H 传 HTTP 头。

八件实用 MCP（Windows 命令形态）

手写 .mcp.json 何时划算

批量改多台机器、或 CLI 一行写烦时，直接编 JSON 与 claude mcp add 等价。注意逗号/引号；密码与 token 只放本机，入库前打码。

路径速查：

• 项目：项目根\.mcp.json
• 用户：C:\Users\<用户>\.claude\settings.json 的 mcpServers

和「必装推荐」怎么拼

清单选型看 Claude Code 必装 MCP：先三件，再慢慢加；Windows 可跑命令形态以本篇表格为准。

相关阅读

• Claude Code 必装 MCP：先三件，再慢慢加
• Codex 想长期好用，得同时拴两根绳子

素材来源：CSDN 原文

管理命令

1
claude mcp list
2
claude mcp add <名> -s user -- <启动命令>
3
claude mcp remove <名>

第一批（建议先装）

第二批 / 第三批

• 增强：Sequential Thinking、mcp-run-python、数据库 MCP
• 按需：Playwright、Figma、Repomix/DeepWiki、Task Master

Playwright 用 @executeautomation/playwright-mcp-server；Sequential Thinking 用 @modelcontextprotocol/server-sequential-thinking。

为啥这几件值得先装

坑

• 一次装太多 → 资源占满、工具列表噪音大。
• Windows 上裸 npx 可能截断 stdio；要 cmd /c 包一层（见 Windows 上 MCP：先记住 cmd /c）。
• 密钥走 env，别写进仓库；token 打码后再分享配置。

相关阅读

• Windows 上 MCP：先记住 cmd /c
• MCP、Skills、Plugin 不是三选一

素材来源：CSDN 原文

最核心的取舍：子进程隔离，不搞进程内驱动

整个项目最关键的设计决策，根子在一个历史包袱上——MediaCrawler 的配置全挂在全局 config 模块上。CLI 解析完直接改写 config.KEYWORDS、config.PLATFORM 这些全局变量，平台采集代码内部也直接读它们。

这意味着什么？一个进程里跑两个任务，全局配置互相污染。 你给任务 A 设的关键词，任务 B 也跟着变。而 MCP Server 恰恰要支持多任务、要并发，跟「全局单例」天然冲突。

三条路摆面前：

我选了子进程隔离。理由特别实在：MediaCrawler 自带完整 CLI，子进程方案零改动复用源码，进程边界天然把 config 污染问题解决了，代价只是每次冷启动 Chromium 那几秒——完全可接受。为快那么一点去背进程池的复杂度，不划算。

MCP 侧最终暴露六件工具：search_posts / get_post_detail / get_comments 负责提交采集任务，get_task_status 轮询进度，get_login_state / list_platforms 查状态。

长任务必须拆成「提交 + 轮询」

采集是分钟级的活：一个关键词搜 20 条帖子带评论，三到五分钟很正常。而 MCP 工具调用是有超时约束的，同步阻塞不可行。

所以接口拆两类：

• 快操作（查登录态、列平台、查任务状态）→ 同步返回
• 采集动作 → 提交后返回 task_id，AI 自己轮询 get_task_status

AI 拿到的是一套能自主编排的流程：提交 → 轮询 → 拿到 save_dir → 按需读文件。数据量大时绝不能整包塞回 MCP 返回值——会直接撑爆 agent 上下文，只回摘要和落盘路径。

登录态这关，直接复用它自己的机制

MediaCrawler 的登录态不是存个 cookie 文件，而是用 Playwright 的 launch_persistent_context(user_data_dir="browser_data/{platform}")——整个 Chromium 用户目录落盘。扫码登录一次，之后每次启动浏览器自动带上 cookie。

所以 MCP 侧根本不用管登录流程，只做两件事：

1. 让用户手动跑一次 main.py --lt qrcode 扫码，登录态落到 browser_data/
2. get_login_state 探测该目录在不在，就能判断有没有登录态

比自己在 MCP 里重新实现一遍登录流程省事得多，也稳得多。

四个坑，比方案本身值钱

防封号：少量、多类型、单并发

爬虫最怕封号，测试策略必须克制：每种采集类型各测一次、量调到最小、严格串行。

• 三种采集类型（search / detail / comments）各跑一次
• search 受平台限制最小 20 条，detail / comments 就 1 帖 5 评论
• 并发永远为 1（信号量控制），任务之间留间隔，绝不堆请求

验证到这一步，三条采集路径全部真实跑通：search 采到「AI编程」关键词的 20 条帖子加评论；detail / comments（指定帖子、指定帖子评论）在修好参数 bug 后也都成功，单个任务三到四分钟。

项目长这样

1
mediacrawler-mcp/
2
├── server.py                # MCP 入口，注册 6 个工具
3
├── mediacrawler_mcp/core/   # 子进程编排 + 任务状态机（并发/超时/回收）
4
├── tests/                   # 协议层冒烟 + 编排链路 + 场景 loop 测试
5
└── README.md                # 安装 / 登录 / 挂载到 Claude Code 的说明

整套做下来最大的感受：CLI 项目封装成 MCP 的难度不在写工具，而在摸清上游的架构约束——全局状态、参数命名、平台行为，每个都可能是坑。先把这些摸清楚，剩下就是把「拼参数、起进程、收日志」这种机械活写对而已。