一、MCP 与 Skills 的核心区别
1. 上下文加载策略（最本质差异）
| 维度 | MCP | Skills |
|---|---|---|
| 加载方式 | 全量预加载：启动时将所有工具的名称、参数 Schema、示例完整注入上下文 | 渐进式懒加载：仅在语义匹配成功后，按需加载对应技能的指令与资源 |
| Token 消耗 | 线性膨胀：工具越多，上下文占用越高，多工具场景下可占满 32K 窗口的 70% 以上 | 极低：仅在调用时传递必要信息，避免上下文污染 |
| 设计哲学 | 「把所有说明书摊在桌上」：依赖模型理解完整工具集 | 「用到时再翻说明书」：信任模型能按需匹配能力 |
2. 架构与实现复杂度
- MCP：基于 JSON-RPC 2.0 的重型协议，需实现完整的 Server/Client 通信、认证、状态管理，调试依赖复杂 JSON 日志，可观测性差。
- Skills：轻量标记式定义（通常为 Markdown/JSON 片段），无额外协议层，直接映射为本地 CLI/API 调用，调试与可组合性接近原生命令行。
3. 安全与灵活性
- MCP：多模型协作与跨进程通信带来数据共享风险，权限管理僵化，初始化配置繁琐。
- Skills：每个技能为独立沙箱化算子，权限边界清晰，支持工作区/用户/系统多层级优先级，迭代速度更快。
二、OpenClaw 原生拒绝 MCP 的核心原因
1. 性能与成本考量
MCP 的「上下文开销」与 OpenClaw 追求的低延迟、高并发目标冲突： - 多工具场景下，MCP 会挤占大量推理空间，导致响应变慢、成本飙升。 - OpenClaw 采用 Skills 渐进式加载，将上下文开销控制在最低水平，更适合生产环境。
2. 架构设计理念冲突
OpenClaw 核心设计是「本地优先、极简依赖」： - MCP 引入重型协议栈，增加系统复杂度，违背「减少依赖、快速迭代」的原则。 - Skills 与 OpenClaw 沙箱化、模块化架构天然契合，可直接复用 CLI/Shell 生态，无需额外适配。
3. 安全与隐私风险
- MCP 跨进程/跨模型的通信模式，存在数据泄露与权限滥用风险。
- Skills 采用沙箱隔离，每个技能仅拥有最小必要权限，更符合 OpenClaw 对安全与可控性的要求。
4. 生态与工程实践
- OpenClaw 从诞生起就拥抱 CLI 生态，认为「最好的协议是没有协议」，直接调用系统命令更透明、可调试。
- MCP 过度工程化，与开发者长期形成的命令行工作流脱节，实际落地体验差（如 Perplexity 弃用）。
三、补充：MCP 的适用场景与局限性
- MCP 仍有价值的场景：电商导购、轻量工具集成等对上下文成本不敏感、需结构化调用的场景。
- Skills/CLI 更优的场景：高并发生产环境、复杂任务流水线、需要频繁调试与可观测性的开发场景。