MCP 还是 Skills？一张图看懂 AI Agent 能力分层与 Token 优化策略

为什么会有这个争论

AI Agent 工具圈迭代极快，每隔两周就有新概念冒出来。不少人开始困惑：MCP 是不是过时了？应该全用 Skills？

仔细拆解会发现，喜欢 Skills 的人和喜欢 MCP 的人，需求完全不同——不是功能差异，是分发方式的差异。Skills 是给自己人用的，MCP 是给全世界用的。

MCP：AI 世界的 USB-C 统一接口

2024 年 11 月之前，AI 工具对接是碎片化的：让 Agent 读 GitHub 仓库要写一套代码，查数据库再写一套，发 Slack 消息又是一套。10 个 AI 应用连 20 个工具，理论上需要 200 个定制集成。

Anthropic 开源的 MCP（Model Context Protocol）做的事和 USB-C 统一充电口一样：定义一套标准协议，让任何 AI 即插即用地连接任何工具。10 个 AI + 20 个工具 = 30 个 MCP 实现，把 M×N 问题变成 M+N 问题，开发成本断崖式下降。

MCP 的致命问题：上下文爆炸

MCP 有一个严重副作用——吃掉你的上下文窗口。

每个 MCP Server 连接时，必须把所有工具定义（名称、描述、参数、示例）一次性塞进上下文。一个工具定义约 500-800 tokens，一个 MCP Server 通常有 10-20 个工具。真实数据：

• GitHub MCP Server：27 个工具，消耗约 18,000 tokens
• Playwright MCP Server：21 个工具，消耗约 13,600 tokens
• mcp-omnisearch：20 个工具，消耗约 14,200 tokens

有开发者配了 7 个 MCP Server，还没开始对话，上下文就被吃掉 67,000 tokens——占上下文窗口的 33%。更夸张的案例达到 82,000 tokens，占 41%。

这意味着你问 AI "2+2 等于几"，回答 "4" 只需要 5 个 token，但工具定义已经消耗了 15,000 tokens。简单问题的成本被放大了 3000 倍。

更糟糕的是，上下文被挤占后，AI 选错工具、传错参数的概率显著上升。实践中连接 2-3 个以上 MCP Server，工具使用准确性就会明显下降。

Claude Code 的补丁：Tool Search

Anthropic 意识到了这个问题。2025 年 1 月 Claude Code 推出了 Tool Search：

• MCP 工具不再预加载，而是按需发现
• 当工具定义超过上下文的 10% 时自动启用
• AI 需要某个工具时，先搜索再加载

效果立竿见影：从 77,000 tokens 降到 8,700 tokens，减少 85%。

但这只是打补丁。问题根源在于 MCP 的设计假设是"把所有工具摆出来让 AI 挑"，工具少没问题，工具多就撑不住。

Skills：渐进式披露的操作手册

Skills 从设计之初就采用了不同哲学——渐进式披露（Progressive Disclosure）。

打个比方：传统做法是新员工入职第一天把公司所有流程文档堆在桌上（MCP 的做法），Skills 的做法是先给一份简短岗位说明，遇到具体问题时再告诉他翻哪本手册的哪一页。

技术实现上分三层：

第一层：元数据（启动时加载）

• 只有名称和简短描述
• 每个 Skill 约 100 tokens
• 装 100 个 Skill 也只占 10,000 tokens

第二层：完整指令（相关时加载）

• AI 判断某个 Skill 与任务相关时，才读取完整 SKILL.md
• 建议控制在 5,000 tokens 以内

第三层：参考资料（需要时加载）

• 详细技术文档、API 说明、示例代码
• 按需读取，用多少加载多少
• 理论上可包含无限内容

一个 Skill 可以打包整套 API 文档和几百页参考手册，但只要任务不需要，这些内容永远不会占用上下文。

Skills 的杀手锏：自带脚本执行

很多人忽略了 Skills 的一个关键能力：可以自带可执行脚本。

典型的 Skill 文件夹结构：

my-skill/
├── SKILL.md          # 核心指令
├── scripts/          # 可执行脚本
│   ├── validate.py
│   ├── generate.sh
│   └── process.js
├── references/       # 参考文档
└── assets/           # 模板、配置文件

关键点：当 AI 运行 scripts/validate.py 时，脚本代码本身不会加载到上下文，只有执行结果会返回。

假设你有一个 500 行的 Python 脚本处理 PDF 表单。传统方式下 AI 要么自己写代码（消耗大量 tokens），要么读取脚本再执行（脚本内容占用上下文）。用 Skills，AI 直接运行预写好的脚本，整个过程可能只消耗 50 tokens 的输出结果。

脚本执行 = 零上下文成本 + 确定性结果

这些脚本通过 Agent 内置的 bash 工具执行，不需要 MCP。支持 Python、Bash、JavaScript 等，系统能跑的都能用。

真实案例：自动发布 X Article 的演进

这个案例完美展示了从 MCP 到 Skills 的转变。

需求：把 Markdown 文章自动发布到 X 的长文功能 X Article。

方案一：Playwright MCP

流程：Markdown → Python 脚本解析 → Playwright MCP 操作浏览器 → X Articles 编辑器自动化填充 → 保存草稿。

问题是上下文消耗飞快。Playwright MCP 有 22 个工具，光工具定义就占 8,000-10,000 tokens。更要命的是每次浏览器交互都要返回页面的 accessibility tree 快照，一个复杂页面可能几千 tokens。

发布一篇文章需要：打开页面、等待加载、点击编辑器、粘贴内容、上传图片、调整位置、保存草稿……每一步都是一次 MCP 交互。结果：一篇文章发完，上下文用掉 50,000+ tokens。

方案二：Skills + CDP 脚本

baoyu-post-to-x/
├── SKILL.md              # 简短的使用说明
└── scripts/
    └── x-article.ts      # 核心脚本，使用 Chrome CDP

核心变化：脚本直接调用 Chrome CDP（Chrome DevTools Protocol），绕过 MCP。传入 Markdown 文件路径，脚本自己完成所有浏览器操作，只返回最终结果："发布成功，草稿链接：xxx"。

AI 只需做一件事：调用脚本，传入文件路径。上下文消耗：几百 tokens。

对比

关键洞察：MCP 让 AI 一步步操作，每步都要理解、决策、执行。脚本把整个流程封装起来，AI 只管"开始"和"结束"。即使 MCP 支持了 Tool Search，上下文问题也没根本解决——工具定义只是一部分，真正的大头是交互过程中的中间结果。Skills 的脚本执行模式天然避开了这个问题。

怎么选：三个判断标准

做决策时问自己三个问题：

1. 谁来用？ 自己或团队内部 → Skills。给外部用户或客户 → MCP。
2. 怎么分发？ 能接受"把文件放到目录"的安装方式 → Skills。希望用户输入 URL 就能用 → MCP。
3. 解决什么问题？ 编码领域知识、定义工作流 → Skills。连接外部服务、对外暴露 API → MCP。

需要 MCP 的场景：连接远程 CRM、调用第三方 SaaS API（Slack、Notion、Jira）、查询云端数据库、访问需要认证的外部服务、做对外分发的服务。

不需要 MCP 的场景：读写本地文件、处理 PDF/Word/Excel、运行代码分析、执行 Git 操作、生成图表和可视化、优化团队工作流——这些用 Skills + 内置工具就够了。

未来格局与实操建议

最佳实践是两者配合：用 Skills 编码领域知识，用 MCP 连接外部服务。比如公司有一套特定工作流程——先查这个系统，再查那个系统，按特定顺序处理。领域知识用 Skills 写出来让 AI 理解，具体连接那些系统的能力靠 MCP 提供。

随着 Skills 生态成熟，MCP 的角色会收窄到"远程连接"这个核心场景。本地文件操作、浏览器自动化、数据处理这些任务，Skills + 内置工具就能搞定，且效率更高。

Anthropic 工程博客提到，他们用"代码执行 + MCP"的方法，把一个 150,000 token 的工作流压缩到了 2,000 tokens——核心思路就是让 AI 写代码调用工具，而不是预加载所有工具定义。这正是 Skills 的设计方向。

给独立开发者的建议：优先用 Skills 封装工作流程，复杂逻辑用脚本而非让 AI 一步步操作，只在必须连接远程系统时才引入 MCP。如果你只能先学一个，选 Skills——更轻量、更高效、更容易上手，能解决日常 80% 的问题。