构建 AI 智能体的开发者面临一个反复出现的决策：当你的智能体需要超越代码的能力——网页搜索、图像生成、视频、存储——你该如何添加这些能力？
三种方法主导着讨论：MCP 服务器、Skills 和能力运行时（Capability Runtime）。它们常常被定位为竞争对手。但它们不是。它们在技术栈的不同层次解决不同的问题。
以下是选择的方法。
三个层次的定义
MCP 服务器：传输层
MCP（模型上下文协议）是 AI 智能体如何连接外部工具的开放标准。一个 MCP 服务器是一个轻量级程序，它暴露一组工具——搜索、数据库查询、文件操作——任何兼容 MCP 的智能体都可以调用。
MCP 解决的是连接问题：智能体如何发现并调用外部工具？它标准化了接口。每个工具不再拥有自己的协议，而是统一使用 MCP。
Skills：指令层
Skills（也称为智能体技能或 SKILL.md 文件）是教智能体如何使用工具或执行任务的 Markdown 文档。一个 Skill 会说明：「这是安装 CLI 的方法，这些是可用的命令，遇到这个错误时该这样做。」
Skills 解决的是指令问题：智能体连接工具后，如何知道该做什么？没有 Skill，智能体能看见工具，但不理解工作流程。
Capability Runtime：整合层
能力运行时是一个单一的 CLI（或 API），将多种能力——图像生成、视频、网页搜索、云存储、发布——整合在一个端点之后。不需要配置五个独立的 MCP 服务器，你只需安装一个工具。
能力运行时解决的是整合问题：如何给智能体提供多种能力，同时不被配置、凭证和 token 开销淹没？
层次图
┌─────────────────────────────────────────────┐
│ 你的 AI 智能体 │
│ (Claude Code, Cursor, Codex, Windsurf) │
├─────────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────────┐ │
│ │ MCP │ │ Skills │ │ Capability │ │
│ │ 服务器 │ │ (SKILL) │ │ Runtime │ │
│ │ │ │ │ │ │ │
│ │ 连接 │ │ 指导 │ │ 整合 │ │
│ │ 工具 │ │ 智能体 │ │ 能力 │ │
│ └─────────┘ └─────────┘ └─────────────┘ │
│ │
│ 传输层 指令层 整合层 │
└─────────────────────────────────────────────┘
这些层次中没有任何一个能替代其他的。事实上，它们在一起工作效果最好：
- MCP 连接你的智能体到能力运行时
- Skills 教会你的智能体如何使用运行时的命令
- 运行时整合能力，这样只需要连接和指导一件事
何时使用每一层
仅在以下情况单独使用 MCP 服务器：
你需要一到两个特定工具，并且有维护良好的 MCP 服务器。例如，通过自定义 MCP 服务器将智能体连接到公司内部数据库。或者通过现有的 MCP 服务器添加 GitHub 集成。
MCP 单独使用在以下情况有意义：
- 你只需要 1–2 项能力
- 能力是专用的（你的数据库、你的 API、你的 Jira）
- 你有 DevOps 支持来维护服务器配置
- 1–2 个服务器的 token 开销可以忽略不计
使用 Skills 当：
你希望智能体理解工作流程，而不仅仅是访问工具。一个 Skill 不只是列出命令——它教智能体顺序：安装、认证、配置、验证、使用。
Skills 在以下情况必不可少：
- 工具有多步骤的设置过程
- 错误处理很重要（「如果遇到 X 错误，尝试 Y」）
- 你希望智能体能够自主使用该工具
- 你在团队中共享该工作流程
使用能力运行时当：
你需要 4 项以上能力，配置开销变得难以管理。这是独立开发者和小团队最常见的场景。
能力运行时在以下情况有意义：
- 你的智能体需要图像、视频、搜索、存储和发布功能
- 你不想管理 6 个 API 密钥和 5 个 MCP 服务器配置
- 多个服务器的 token 开销正在影响智能体性能
- 你想要一次安装、一个凭证、一种输出格式
混合方案（大多数团队实际使用的）
在实践中，最好的设置通常是混合的：
MCP 服务器（专用工具）+ Capability Runtime（通用能力）+ Skills（工作流程指令）
你的智能体连接到：
- 1–2 个 MCP 服务器用于内部或专用工具（数据库、Slack、Jira）
- 1 个能力运行时用于通用能力（图像、视频、搜索、存储、发布）
- 1 个 Skill 文件教智能体如何使用运行时
这为独特需求提供了最佳选择，为其他一切提供了最小开销。
Token 的现实
混合方案不仅在概念上更清晰——它还有可衡量的影响。每个 MCP 服务器都会向智能体的上下文添加工具描述。使用 5 个 MCP 服务器，你仅在工具描述上就消耗 15,000–40,000 个 token。
使用 2 个 MCP 服务器 + 1 个能力运行时的混合设置将其降至约 8,000–14,000 个 token。这意味着额外 10–15% 的上下文被释放出来用于实际工作。
常见错误
错误 1：认为 MCP 就够了
MCP 连接工具。它不整合工具、不管理凭证、也不减少 token 开销。如果你运行 5 个以上 MCP 服务器，你的智能体在每个服务器上都在支付成本。
错误 2：认为 Skills 能替代工具
Skills 教授工作流程。它们不提供能力。一个 Skill 可以告诉你的智能体如何生成图像——但智能体仍然需要背后有真正的图像生成工具。
错误 3：认为运行时能替代 MCP
能力运行时整合通用能力。它们不替代专用集成的需求。你的智能体仍然需要 MCP 来连接内部数据库或 Jira。运行时处理大多数智能体共享的通用能力。
一张表做决策
| 你需要... | 使用... |
|---|---|
| 1–2 个专用工具 | MCP 服务器 |
| 智能体理解工作流程 | Skills |
| 4 项以上通用能力 | Capability Runtime |
| 以上全部 | 混合方案：MCP + Runtime + Skills |
总结
MCP vs Skills vs Capability Runtime 的争论没有抓住重点。它们是同一技术栈的三个层次，而不是三种竞争方案。
MCP 是 USB-C 接口。Skills 是说明书。能力运行时是插入的设备。
你的智能体需要全部三者。问题不是选哪一个——而是各用多少。
最后更新：2026 年 5 月