# I still prefer MCP over skills

> 来源：[HackerNews](https://david.coffee/i-still-prefer-mcp-over-skills/)

# I still prefer MCP over skills：为什么在AI代理架构中，模型上下文协议仍是更优解？

## 背景与概述

在AI应用开发领域，一个核心问题是如何让大语言模型（LLM）与外部工具、数据源和系统进行有效交互。近年来，两种主流方案逐渐成形：一种是各大AI平台（如OpenAI、Anthropic）推出的“技能”（Skills）或“工具”（Tools）框架，另一种是开源的**模型上下文协议（Model Context Protocol，MCP）**。

最近，一篇在HackerNews上引发热议的技术文章《I still prefer MCP over skills》深入探讨了这一选择。作者David基于实际开发经验，阐述了为什么在许多场景下，MCP相比平台特定的技能框架更具优势。这一讨论触及了AI应用架构的核心：我们应该选择封闭但易用的平台方案，还是开放但需要更多投入的标准化协议？

随着AI代理（AI Agents）从概念验证走向生产环境，这一选择变得尤为关键。开发者需要权衡开发效率、系统灵活性、供应商锁定风险以及长期维护成本。本文将深入分析MCP与技能框架的差异，并解释为什么MCP正在成为越来越多开发者的首选。

## 核心内容

### 1. 平台技能框架的局限性

各大AI平台提供的技能框架（如OpenAI的Function Calling、Anthropic的Tools）确实降低了入门门槛。开发者只需按照平台规定的格式定义函数，模型就能自动调用这些功能。然而，这种便利性背后隐藏着几个关键问题：

- **供应商锁定**：为OpenAI GPTs编写的技能无法直接迁移到Claude或本地部署的模型中
- **功能受限**：平台通常对技能的类型、调用频率和复杂度设有限制
- **透明度不足**：技能调用过程像黑盒，调试和监控困难
- **扩展性差**：难以集成复杂的业务逻辑或需要状态管理的工具

### 2. MCP的开放性与标准化优势

MCP由Anthropic提出，是一个开放协议，定义了AI模型与外部资源交互的标准方式。它的核心优势在于：

- **跨模型兼容**：同一套MCP服务器可以在不同模型间复用
- **协议标准化**：明确定义的HTTP/SSE接口和JSON Schema
- **开发灵活性**：可以用任何编程语言实现MCP服务器
- **生态系统丰富**：开源社区已经贡献了大量现成的MCP服务器实现

```python
# 一个简单的MCP服务器示例（Python）
from mcp import Server, StdioServerTransport
import asyncio

server = Server("example-server")

@server.list_tools()
async def handle_list_tools():
    return [{
        "name": "get_weather",
        "description": "获取指定城市的天气信息",
        "inputSchema": {
            "type": "object",
            "properties": {
                "city": {"type": "string"}
            }
        }
    }]

@server.call_tool()
async def handle_call_tool(name: str, arguments: dict):
    if name == "get_weather":
        city = arguments.get("city", "北京")
        # 实际调用天气API
        return f"{city}的天气是晴朗，25°C"
    
async def main():
    async with StdioServerTransport() as transport:
        await server.run(transport)

if __name__ == "__main__":
    asyncio.run(main())
```

### 3. 实际开发中的对比体验

在实际项目中，MCP的优势更加明显：

- **调试体验**：MCP服务器可以独立运行和测试，不依赖特定的AI平台
- **版本控制**：MCP配置可以像普通代码一样进行版本管理
- **本地开发**：完全可以在本地环境中开发和测试AI代理，无需API密钥
- **性能优化**：可以针对特定工具进行缓存、批处理等优化

### 4. 长期维护的考量

从项目生命周期角度看，MCP提供了更好的长��维护性：

- **技术债务可控**：避免被特定平台的API变更所绑架
- **团队协作顺畅**：前后端团队可以并行开发，通过MCP协议对接
- **迁移成本低**：更换底层模型时，工具层基本无需改动

### 5. 社区与生态系统的力量

MCP作为开放协议，正在吸引越来越多的贡献者：
- 官方和社区维护的工具库不断丰富
- 开发工具和调试工具日益完善
- 最佳实践和设计模式逐渐形成

## 技术分析

### MCP架构解析

MCP采用客户端-服务器架构，其中：
- **MCP客户端**：通常是AI模型或代理框架，通过标准协议与服务器通信
- **MCP服务器**：提供工具、数据源等能力的后端服务
- **传输层**：支持stdio、HTTP、SSE等多种传输方式

### 协议设计亮点

1. **资源（Resources）与工具（Tools）分离**
   - 资源：只读数据源，如数据库查询结果、API数据
   - 工具：可执行操作，可能产生副作用

2. **增量更新机制**
   - 支持服务器主动推送资源更新
   - 减少轮询开销，提高实时性

3. **强类型接口定义**
   - 使用JSON Schema明确定义输入输出
   - 提供更好的开发体验和错误处理

### 与技能框架的技术对比

| 特性 | MCP | 平台技能框架 |
|------|-----|-------------|
| 协议开放性 | 开放标准 | 私有实现 |
| 传输协议 | HTTP/SSE/stdio | 通常为HTTP |
| 身份验证 | 灵活支持多种方案 | 平台特定方案 |
| 工具发现 | 动态发现 | 静态配置 |
| 状态管理 | 服务器端管理 | 通常无状态 |

### 性能考虑

MCP的额外协议层确实引入了一些开销，但这些开销在实际应用中通常是可接受的：
- 连接建立后，通信开销很小
- 可以批量处理工具调用
- 支持连接复用和持久化

## 实践建议

### 1. 何时选择MCP？

在以下场景中，MCP是更好的选择：
- 项目需要支持多个AI模型或供应商
- 工具逻辑复杂，需要独立部署和扩展
- 团队已有后端服务，希望复用现有能力
- 对供应商锁定有顾虑

### 2. 快速上手指南

```bash
# 1. 安装MCP开发工具
pip install mcp

# 2. 创建简单的MCP服务器（参考上面的代码示例）

# 3. 使用MCP客户端进行测试
npm install @modelcontextprotocol/sdk

# 4. 集成到AI代理框架中
# 大多数现代AI框架（如LangChain、LlamaIndex）已支持MCP
```

### 3. 开发最佳实践

- **工具设计**：保持工具单一职责，输入输出明确
- **错误处理**：提供有意义的错误信息，帮助模型理解失败原因
- **文档完善**：为每个工具编写清晰的描述和示例
- **版本管理**：为MCP服务器定义版本号，支持平滑升级

### 4. 生产环境部署建议

1. **安全性**：
   - 实施适当的身份验证和授权
   - 对工具调用进行限流和审计
   - 敏感操作需要二次确认

2. **可观测性**：
   - 记录所有工具调用的日志
   - 监控响应时间和成功率
   - 设置告警机制

3. **性能优化**：
   - 对频繁使用的资源进行缓存
   - 考虑使用连接池
   - 实施负载均衡

### 5. 迁移策略

如果已有基于平台技能的项目，可以逐步迁移：
1. 先为非关键功能实现MCP版本
2. 并行运行两套系统进行对比
3. 逐步将更多功能迁移到MCP
4. 最终完全切换到MCP架构

## 总结

在AI应用快速发展的今天，架构选择往往决定了项目的长期成功。虽然平台提供的技能框架在入门阶段更加便捷，但MCP以其开放性、标准化和灵活性，为严肃的AI应用开发提供了更坚实的基础。它不仅是技术上的优化，更是对开发自主权和项目可持续性的投资。随着AI生态的不断成熟，像MCP这样的开放标准将越来越重要，它们确保了创新不会被单一平台所限制，而是能够在整个生态系统中自由流动和进化。对于正在构���下���代AI应用的开发者来说，现在投入时间学习和采用MCP，将是面向未来的明智选择。