一、MCP 与 Skills 的核心区别
1. 上下文加载策略
这是最本质的差异。MCP 采用全量预加载方式，启动时将所有工具的名称、参数 Schema、示例完整注入上下文。这种方式导致 token 消耗线性膨胀，工具越多，上下文占用越高。设计哲学是「把所有说明书摊在桌上」，依赖模型理解完整工具集。
Skills 采用渐进式懒加载，仅在语义匹配成功后，按需加载对应技能的指令与资源。Token 消耗极低，仅在调用时传递必要信息，避免上下文污染。设计哲学是「用到时再翻说明书」，信任模型能按需匹配能力。
2. 架构与实现复杂度
MCP 基于 JSON-RPC 2.0 的重型协议，需实现完整的 Server/Client 通信、认证、状态管理，调试依赖复杂 JSON 日志，可观测性差。
Skills 是轻量标记式定义，通常为 Markdown 或 JSON 片段，无额外协议层，直接映射为本地 CLI/API 调用，调试与可组合性接近原生命令行。
3. 安全与灵活性
MCP 多模型协作与跨进程通信带来数据共享风险，权限管理僵化，初始化配置繁琐。
Skills 每个技能为独立沙箱化算子，权限边界清晰，支持工作区、用户、系统多层级优先级，迭代速度更快。
4. MCP、Skill、Subagent 的三层定位
三者各自解决不同层次的问题：
**MCP（连接层）**解决的是"AI 能不能做这件事"——让 AI 能够访问数据库、API 等真实世界的信息，打通外部系统的连接通道。
**Skill（方法层）**解决的是"AI 能不能稳定地做好这件事"——通过标准化流程（SOP）确保任务每次都能高质量完成，将"会做"变为"稳定地做"。
**Subagent（调度层）**解决的是"复杂任务能否被拆开高效完成"——通过多代理协作来组织和调度任务，让单个复杂任务被合理分配给不同子代理并行处理。
二、选型判断：三步法
实际选择可以遵循三步判断：
第一步：需要访问外部系统吗？ 如果需要（如查数据库，调 API），就先使用 MCP。
第二步：这类任务会反复出现，且需要结果稳定吗？ 如果是（如日志排查、生成周报），就在 MCP 之上增加 Skill，将"会做"变为"稳定地做"。
第三步：这个任务非常复杂，单个代理处理会混乱吗？ 如果是（如大规模重构、跨系统数据分析），再考虑引入 Subagent，进行任务拆分和协作。
三、OpenClaw 原生拒绝 MCP 的核心原因
1. 性能与成本考量
MCP 的上下文开销与 OpenClaw 追求的低延迟、高并发目标冲突。多工具场景下，MCP 会挤占大量推理空间，导致响应变慢，成本飙升。OpenClaw 采用 Skills 渐进式加载，将上下文开销控制在最低水平，更适合生产环境。
2. 架构设计理念冲突
OpenClaw 核心设计是本地优先、极简依赖。MCP 引入重型协议栈，增加系统复杂度，违背减少依赖、快速迭代的原则。Skills 与 OpenClaw 沙箱化、模块化架构天然契合，可直接复用 CLI/Shell 生态，无需额外适配。
3. 安全与隐私风险
MCP 跨进程、跨模型的通信模式存在数据泄露与权限滥用风险。Skills 采用沙箱隔离，每个技能仅拥有最小必要权限，更符合 OpenClaw 对安全与可控性的要求。
4. 生态与工程实践
OpenClaw 从诞生起就拥抱 CLI 生态，认为最好的协议是没有协议，直接调用系统命令更透明、可调试。MCP 过度工程化，与开发者长期形成的命令行工作流脱节。
四、各层适用场景
MCP 仍有价值的场景：电商导购、轻量工具集成等对上下文成本不敏感、需要结构化调用的场景。
Skill 更优的场景：高并发生产环境、复杂任务流水线、需要频繁调试与可观测性的开发场景。
Subagent 适合的场景：复杂任务拆分，如大规模代码重构、跨系统数据分析、需要多步骤协作的复杂工作流。
五，一句话总结
MCP 看「是否能访问外部」，Skill 看「是否要稳定执行」，Subagent 看「是否要复杂拆分」。