关于 MCP 和 SKILLS 的一些看法
前言
众所周知，anthropic搞出了两套很有意思的协议：MCP 和 SKILLS
一句话概括
MCP 像 API，SKILLS 像说明书。
它们作用相近，但一个是 精确定义，一个是 灵活范化。
MCP：机器优先的“精确接口”
MCP（Model Context Protocol）说白了就是 给 AI 用的 API。
和你平时调用的天气 API 没啥两样——唯一区别是：调用方式被写进了提示词，告诉 AI “你可以这么用”。
工作流程
- 开发者定义好工具/接口
- 通过提示词注入，告知 LLM 调用规范
- LLM 按约定格式（如 JSON）返回调用请求
- 外部执行并返回结果
举个栗子
你想让 AI 调用一个天气 API：
传统 API 调用是这样的 curl “https://api.weather.com/today?city=beijing"
// MCP 方式：AI 返回特定格式（其实就是规定好LLM要返回啥） 我举个例子哈 这是你的prompt： 你好，你是个聊天机器人，我给你开放了一个tool，天气tool，如果你需要调用，则以json格式返回以下内容 其中city为城市名 { “tool_call”: “weather_api”, “parameters”: { “city”: “XXX” } } 然后AI就能自由的 “调用” TOOL了（其实就是返回一段指定格式的文本，然后你写个解析器去解析，然后联网操作什么的）
特点：
- 格式固定（如 JSON Schema）
- 机器可解析
- 适合结构化工具调用
- 像“遥控器”——按哪个键就执行哪个功能
SKILLS：人类优先的“操作手册”
SKILLS 则完全不同—它更像一本 使用说明书。
里面不写死格式，而是用 大白话 告诉 AI：
“想查天气？你先看看用户问的是哪个城市，然后去这个网址，把城市名拼在链接后面，拿到结果后再整理成中文回复……”
举个栗子
【SKILL：天气查询】
当用户询问天气时，你应该：
- 识别城市名称（中文或拼音均可）
- 访问 https://api.weather.com/v1/{city}
- 从返回的 JSON 中提取 temperature 和 condition
- 用友好的语气告诉用户，例如：“北京今天晴天，25°C，适合出门~”
如果用户没提城市，主动询问。
特点：
- 自然语言描述
- 包含策略、步骤、异常处理
- AI 自己理解并执行
- 像“教人做事”——学会后灵活应变
对比总结
| 维度 | MCP | SKILLS |
|---|---|---|
| 本质 | 结构化 API | 自然语言手册 |
| 适用场景 | 精确工具调用 | 复杂流程指导 |
| 灵活性 | 低（格式固定） | 高（AI 自行理解） |
| 开发成本 | 中（需定义 schema） | 低（写清楚即可） |
| 可维护性 | 高（机器校验） | 中（依赖 LLM 理解） |
| 典型例子 | 计算器、数据库查询 | 网页操作、多步推理 |
实际场景怎么选？
用 MCP 的场景
- 调用明确的外部 API（查天气、发邮件、查数据库）
- 需要稳定格式输出（如 JSON 给下游系统）
- 工具数量多，需要统一管理
- 对准确性要求极高（如金融交易）
用 SKILLS 的场景
- 复杂业务流程（如“帮我订个餐厅，如果满员就换一家”）
- 需要 AI 自主判断和调整
- 快速原型验证
- 不想写代码，只想用文字描述
一点个人看法
MCP 和 SKILLS 不是互斥的，甚至可以 组合使用：
用 SKILLS 做顶层规划，用 MCP 执行底层原子操作。
比如：
- SKILLS 说：“用户想订机票，你先查一下北京到上海明天有没有航班”
- 底层调用 MCP 的 search_flights 工具
- SKILLS 接着说：“有的话，挑最便宜的那班，然后用 MCP 的 book_flight 订掉”
分工明确：
- SKILLS 负责“怎么想”
- MCP 负责“怎么做”
最后
目前 MCP 和 SKILLS 都还在快速演进，Anthropic 的思路其实很清晰：
给开发者留精确接口，给 AI 留思考空间。
两者结合，才是未来 AI Agent 的正确打开方式。
附：在anthropic没有提出MCP时，我们如何使用ai进行辅助逆向belike
20260418
由 LiangYu 的 Hugo Manager 编写并一键推送到 GitHub 上