Agent Skills 与 MCP 的关系演进 🔄
"Skills 和 MCP 不是竞争关系，而是同一技术栈的两个层次。"
1. 核心问题
2024 年 11 月，Anthropic 推出了 Model Context Protocol (MCP)。仅仅一年后的 2025 年 10 月，同一家公司又推出了 Agent Skills。这引发了开发者社区的困惑：
- Skills 会替代 MCP tools 吗？
- 为什么 MCP 只有 tools 流行，prompts 和 resources 不流行？
- 为什么出现 Skills 里调用 MCP 的模式？
- 为什么出现 mcp2cli 这些桥接工具？
本文将深入探讨这些问题，揭示 2026 年 AI 工程生态的演进方向。
2. Skills vs MCP：不是替代，是分层
2.1 技术栈的两个层次
┌─────────────────────────────────────────────────────────────────┐
│ AI Agent 技术栈分层 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Layer 3: Agent Skills │ │
│ │ (高层抽象 - "部落知识" Tribal Knowledge) │ │
│ │ │ │
│ │ • 封装最佳实践和工作流 │ │
│ │ • 减少 context window 占用 │ │
│ │ • 提供用户友好的接口 │ │
│ │ • 可以调用 MCP 或 CLI │ │
│ └────────────────────────────────────────────────────────┘ │
│ │ │
│ │ 调用 │
│ ▼ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Layer 2: Model Context Protocol (MCP) │ │
│ │ (中层协议 - 标准化连接) │ │
│ │ │ │
│ │ • 标准化的 JSON-RPC 协议 │ │
│ │ • 企业级安全和审计 │ │
│ │ • 跨平台互操作性 │ │
│ │ • 工具发现和权限管理 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │ │
│ │ 连接 │
│ ▼ │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Layer 1: CLI / Direct APIs │ │
│ │ (底层实现 - 直接执行) │ │
│ │ │ │
│ │ • 最快的执行速度 │ │
│ │ • 最低的延迟 │ │
│ │ • 适合本地原型开发 │ │
│ │ • 缺乏标准化和安全控制 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘2.2 为什么 Skills 没有"杀死"MCP
根据 The Skills vs MCP Debate 的分析：
"Skills did replace MCP for some use cases - specifically, the ones that were over-engineered to begin with. But MCP didn't die. It found its proper scope."
Skills 替代的场景：
- 简单的本地文件操作
- 单用户原型开发
- 不需要审计的工作流
MCP 保留的场景：
- 企业级应用（需要审计、权限控制）
- 多用户协作环境
- 需要标准化接口的系统集成
- 安全敏感的操作
2.3 实际案例：Skills 调用 MCP
markdown
---
name: enterprise-data-access
description: Securely access enterprise databases with audit logging. Use when querying production data or generating reports.
---
# Enterprise Data Access
## Instructions
1. Use MCP postgres server for database queries
2. All queries are logged for compliance
3. Results are automatically sanitized
## Example
When user asks "Show me last month's sales":
1. Connect to MCP postgres server
2. Execute: `SELECT * FROM sales WHERE date >= NOW() - INTERVAL '1 month'`
3. Return formatted results
## MCP Configuration
This Skill requires the postgres MCP server:
```json
{
"mcpServers": {
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres"],
"env": {
"DATABASE_URL": "postgresql://..."
}
}
}
}
**这种模式的优势**：
- Skills 提供简洁的用户接口
- MCP 提供标准化的数据访问
- 审计和安全由 MCP 层处理
- 用户无需了解 MCP 细节
---
## 3. MCP 三大能力的采用差异
### 3.1 为什么只有 Tools 流行？
MCP 定义了三种能力：**Tools**、**Resources**、**Prompts**。但截至 2026 年初，采用情况极不均衡：
| 能力类型 | 采用率 | 原因 |
|:---|:---|:---|
| **Tools** | ⭐⭐⭐⭐⭐ 非常高 | 解决了最直接的需求：AI 执行操作 |
| **Resources** | ⭐⭐ 较低 | 与 Tools 功能重叠，价值不明显 |
| **Prompts** | ⭐⭐⭐ 中等（2026 年开始上升）| 早期价值不明显，现在用于治理 |
### 3.2 Tools 的成功
```typescript
// Tools 解决了核心问题：让 AI 执行操作
{
name: "execute_sql",
description: "Execute SQL query on database",
inputSchema: {
type: "object",
properties: {
query: { type: "string" }
}
}
}为什么成功：
- 直接映射到 LLM 的 function calling 能力
- 清晰的输入输出契约
- 易于理解和实现
- 解决了"AI 如何与外部系统交互"的核心问题
3.3 Resources 的困境
typescript
// Resources 设计用于提供数据
{
uri: "file:///path/to/data.json",
name: "Configuration Data",
mimeType: "application/json"
}为什么不流行：
- 与 Tools 功能重叠：读取数据可以用
read_filetool 实现 - 缺乏明确的使用场景：何时用 Resource，何时用 Tool？
- 增加了复杂度：开发者需要理解两套概念
根据 Why we deleted (most of) our MCP tools：
"When an agent can run
nx show project myappin the terminal and read the output, why do we need a dedicated MCP resource?"
3.4 Prompts 的复兴（2026）
typescript
// MCP Prompts - 可复用的提示模板
{
name: "code_review",
description: "Perform code review with security focus",
arguments: [
{ name: "file_path", required: true },
{ name: "focus_area", required: false }
]
}2026 年 Prompts 开始被重视的原因：
- 运行时控制：Prompts 成为 Agent 行为的控制点
- 治理需求：企业需要标准化 AI 的推理方式
- 安全合规：通过 Prompts 注入安全策略
根据 MCP Prompts, Runtime Control, and Governance：
"MCP Prompts are more than reusable templates. In production agent systems, they act as runtime control surfaces that shape reasoning, tool selection, and safety."
Cursor 的支持（2026 年初）：
New MCP Features in Cursor 报道，Cursor 开始支持：
- Prompts: 可复用的提示模板
- Resources: 动态上下文注入
- Elicitation: 引导式对话
- Dynamic Tools: 运行时工具生成
4. CLI vs MCP：速度与治理的权衡
4.1 "MCP is dead. Long live the CLI" 争论
2026 年初，一篇题为 "MCP is dead. Long live the CLI" 的文章在 Hacker News 获得 85 点赞和 66 条评论，引发了激烈讨论。
CLI 支持者的观点：
- 更快的执行速度（无 JSON-RPC 开销）
- 更简单的实现（直接调用命令）
- 更好的调试体验（可以手动测试）
- 适合本地开发和原型
MCP 支持者的观点：
- 企业级安全和审计
- 标准化的接口和权限管理
- 跨平台互操作性
- 适合生产环境
4.2 性能对比
根据 Why MCP Beats CLI for VMware AI Agents：
简单调试工作流的任务完成率：
• CLI: 28% 更高的完成率
• 但代价是：缺乏审计、权限控制、错误恢复
企业级工作流：
• MCP: 更高的可靠性和安全性
• 支持复杂的工具链和错误处理4.3 mcp2cli：桥接两个世界
为什么出现 mcp2cli：
bash
# mcp2cli 将 MCP server 转换为 CLI 命令
mcp2cli install @modelcontextprotocol/server-github
# 现在可以直接调用
github-mcp list-repos --owner anthropics使用场景：
- 本地开发：快速测试 MCP 功能
- 脚本集成：在 shell 脚本中使用 MCP 能力
- 调试：手动测试 MCP server
- 渐进式迁移：从 CLI 逐步迁移到 MCP
根据 Competitor or Partner in the Race of AI?：
"CLIs are better than MCP for agents in certain scenarios. Not the other way around. And with Skills taking off, 2026 is shaping up as the year of pragmatic tool selection."
5. Compiling MCP to Skills
5.1 新趋势：MCP → Skills 编译
Compiling MCP to Skills 提出了一个重要观点：
"Tool descriptions occupy more context window space, increasing response time and costs. For agents with thousands of tools, this means processing hundreds of thousands of tokens before reading a request."
问题：
- 大型 MCP server 暴露数百个 tools
- 每个 tool 的 description 占用 context window
- 导致延迟增加和成本上升
解决方案：将 MCP tools 编译为 Skills
┌─────────────────────────────────────────────────────────────────┐
│ MCP to Skills 编译流程 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 输入: MCP Server (100+ tools) │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ tools/list_repos, tools/create_issue, │ │
│ │ tools/get_pr, tools/merge_pr, ... │ │
│ └────────────────────────────────────────────────────────┘ │
│ │ │
│ │ 编译 │
│ ▼ │
│ 输出: Agent Skills (语义分组) │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Skill: "github-repo-management" │ │
│ │ → 调用 MCP tools: list_repos, create_repo │ │
│ │ │ │
│ │ Skill: "github-issue-tracking" │ │
│ │ → 调用 MCP tools: create_issue, list_issues │ │
│ │ │ │
│ │ Skill: "github-pr-workflow" │ │
│ │ → 调用 MCP tools: get_pr, merge_pr, review_pr │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
│ 优势: │
│ • Context window 占用减少 80%+ │
│ • 语义分组提高匹配准确率 │
│ • 保留 MCP 的安全和审计能力 │
│ │
└─────────────────────────────────────────────────────────────────┘5.2 实现示例
原始 MCP Server（100+ tools）：
typescript
// GitHub MCP Server
server.setRequestHandler(ListToolsRequestSchema, async () => ({
tools: [
{ name: "list_repos", description: "List repositories...", ... },
{ name: "get_repo", description: "Get repository details...", ... },
{ name: "create_repo", description: "Create a new repository...", ... },
{ name: "list_issues", description: "List issues...", ... },
{ name: "create_issue", description: "Create an issue...", ... },
{ name: "get_pr", description: "Get pull request...", ... },
{ name: "merge_pr", description: "Merge pull request...", ... },
// ... 93 more tools
]
}));编译后的 Skills：
markdown
---
name: github-repo-management
description: Manage GitHub repositories - list, create, update, delete repos. Use when working with repository-level operations.
---
# GitHub Repository Management
## Available Operations
- List repositories
- Get repository details
- Create new repository
- Update repository settings
- Delete repository
## Implementation
This Skill uses the GitHub MCP server. Operations are mapped to MCP tools:
- `list_repos` → List repositories
- `get_repo` → Get details
- `create_repo` → Create new
- `update_repo` → Update settings
- `delete_repo` → Delete
## Example
User: "Show me all my public repos"
→ Calls MCP tool: list_repos(visibility="public")效果：
- Context window 从 ~50K tokens 降到 ~5K tokens
- 匹配准确率提高（语义分组）
- 保留了 MCP 的所有能力
6. 2026 年的最佳实践
6.1 选型决策树
用户需求
│
├─ 本地原型开发，单用户？
│ └─ 使用 CLI 或 Skills (直接调用)
│
├─ 企业级应用，需要审计？
│ └─ 使用 MCP + Skills (封装)
│
├─ 需要跨平台互操作？
│ └─ 使用 MCP
│
├─ 工具数量 > 50？
│ └─ 使用 Skills (编译 MCP)
│
└─ 需要运行时治理？
└─ 使用 MCP Prompts + Skills6.2 推荐架构
┌─────────────────────────────────────────────────────────────────┐
│ 2026 推荐架构 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 用户交互层 │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Agent Skills (用户友好的接口) │ │
│ │ • 封装常见工作流 │ │
│ │ • 减少 context window 占用 │ │
│ │ • 提供最佳实践指导 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 协议层 │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Model Context Protocol │ │
│ │ • 标准化接口 │ │
│ │ • 安全和审计 │ │
│ │ • 权限管理 │ │
│ │ • Prompts 用于治理 │ │
│ └────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ 执行层 │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ CLI / Direct APIs (快速执行) │ │
│ │ • 本地工具 │ │
│ │ • 系统命令 │ │
│ │ • 第三方 APIs │ │
│ └────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘6.3 实际案例：企业 AI 编码助手
markdown
# 场景：企业级 AI 编码助手
## 架构选择
1. **Skills 层**：
- `code-review` Skill：封装代码审查工作流
- `security-scan` Skill：封装安全扫描流程
- `deploy-check` Skill：封装部署前检查
2. **MCP 层**：
- GitHub MCP Server：代码仓库操作（需要审计）
- Jira MCP Server：任务管理（需要权限控制）
- Slack MCP Server：通知发送（需要速率限制）
3. **CLI 层**：
- `git` 命令：本地代码操作
- `npm` 命令：依赖管理
- `eslint` 命令：代码检查
## 为什么这样设计？
- **Skills**：提供一致的用户体验，减少 token 消耗
- **MCP**：企业级操作需要审计和权限控制
- **CLI**：本地操作最快，无需网络开销
## 数据流示例
用户: "Review this PR and deploy if tests pass"
1. Skills 层：`code-review` Skill 被触发
2. MCP 层：调用 GitHub MCP 获取 PR 信息（审计日志记录）
3. CLI 层：运行 `npm test`（本地执行）
4. MCP 层：调用 Slack MCP 发送通知（权限检查）
5. Skills 层：返回格式化的结果给用户7. 未来展望
7.1 Skills 和 MCP 的协同演进
根据 Why do we need MCP if skills exist now?：
"MCP standardized how agents authenticate and interact with external services. Skills encode the tribal knowledge that helps agents use tools effectively. They're complementary, not competing—and CLIs bridge the gap for local-first workflows."
预测：
- Skills 将成为主要的用户接口
- MCP 将成为企业级的标准协议
- CLI 将继续用于本地开发
- 三者共存，各司其职
7.2 MCP Prompts 的崛起
2026 年，MCP Prompts 将从"不流行"变为"关键能力"：
驱动因素：
- AI 治理需求：企业需要控制 AI 的行为
- 合规要求：金融、医疗等行业需要标准化推理
- 成本优化：通过 Prompts 减少不必要的工具调用
应用场景：
- 注入安全策略
- 强制代码规范
- 控制工具选择逻辑
- 实现 A/B 测试
7.3 工具生态的整合
2024: MCP 推出，主要是 Tools
2025: Skills 推出，开发者困惑
2026: 生态整合，各层次明确
2027: 预测 - 统一的开发体验2027 年可能的形态：
- 开发者编写 Skills（高层抽象）
- Skills 自动编译为 MCP 或 CLI（根据场景）
- 统一的调试和监控工具
- 跨平台的 Skills 市场
8. 关键要点总结
8.1 核心观点
| 问题 | 答案 |
|---|---|
| Skills 会替代 MCP 吗？ | 不会。Skills 是高层抽象，MCP 是底层协议，两者互补 |
| 为什么只有 Tools 流行？ | Tools 解决了最直接的需求。Prompts 和 Resources 的价值在 2026 年才显现 |
| 为什么 Skills 里调用 MCP？ | Skills 提供用户接口，MCP 提供标准化和安全能力 |
| 为什么出现 mcp2cli？ | 桥接 MCP 和 CLI，满足本地开发和调试需求 |
8.2 选型建议
场景 推荐方案
─────────────────────────────────────────────────
本地原型开发 CLI + Skills
企业级应用 MCP + Skills
跨平台集成 MCP
大量工具（50+） Skills (编译 MCP)
需要运行时治理 MCP Prompts + Skills8.3 最佳实践
- 分层思考：Skills（用户接口）→ MCP（协议）→ CLI（执行）
- 按需选择：不要过度工程化，根据实际需求选择合适的层次
- 渐进式采用：从 CLI 开始，需要时引入 MCP，最后封装为 Skills
- 关注治理：企业应用优先考虑 MCP 的审计和权限能力
- 优化 Context：使用 Skills 减少 context window 占用
延伸阅读
Skills 与 MCP 关系：
- The Skills vs MCP Debate: Understanding Two Layers of the Same Stack
- Why do we need MCP if skills exist now?
- Agent skills vs Model Context Protocol - How do you choose?
CLI vs MCP 争论：
- Competitor or Partner in the Race of AI?
- MCP vs CLI for AI Agents: Why Direct APIs Win (2026)
- Why we deleted (most of) our MCP tools
MCP Prompts 复兴：
- MCP Prompts, Runtime Control, and Governance for AI Agent Systems
- New MCP Features in Cursor: Prompts, Resources, Elicitation & Dynamic Tools
编译 MCP 到 Skills：