1.概述
如果说大模型的推理能力决定了“它有多聪明”，那么 MCP 决定了它到底能不能在真实世界里把事做完。这篇文章不是简单介绍一个新名词，而是试图回答一个很多工程师心里都在问的问题：Claude 的 Skills 和 MCP，到底解决了什么？为什么它看起来比传统的 Tool / Function Calling 更“重”？
2.内容
2.1 从一个真实问题说起
先说一个很常见的场景。你让一个大模型帮你做一件事：
- “帮我查一下这个用户的资料、最近 30 天的订单，然后给出运营建议。”
而传统 LLM 的做法往往是：
- 用 Prompt 告诉模型“假装你查了数据库”
- 或者用 Function Calling 勉强调用一两个接口
- 或者在外部代码里硬写流程
问题是，这些方式都存在明显短板：
- Prompt 是假能力
- Function Calling 是半自动
- 外部流程是模型被动执行
Claude 的 Skill + MCP，试图从底层解决这个问题。
2.2 什么是 Claude Skills？先把误解说清楚
很多人第一次听到 Skill，会下意识理解为：
但实际上 Claude Skills 和传统 Tool 并不是一个层级的东西。
1.直观理解一下
- Tool：“这是一个函数，你可以调用。”
- Skills：“这是一个你被允许使用的能力边界，我已经帮你定义好了输入、输出和规则。”
2.Skill 更像什么？
- 像一个系统 API + 类型系统 + 权限边界的组合体
3.一个 Skill 至少包含什么？
一个完整的 Claude Skill，通常包含：
- 能力名称（Name）
- 能力描述（给模型看的）
- 输入参数结构（JSON Schema）
- 输出结果结构（JSON Schema）
- 实际执行逻辑（运行在 Skill Server 中）
也就是说，Skill 本身是“声明式”的，模型并不关心你是 Python、Java 还是 Rust 实现的。
2.3 MCP（Model Context Protocol）到底是什么？
先给一个不那么官方的定义：
- MCP 是一套让大模型“安全、可控地使用外部能力，并把结果纳入推理过程”的协议。
这三点，恰恰是很多 Tool 方案做不到的。
1.MCP 解决的核心不是“怎么调函数”
而是这几个问题：
- 模型怎么知道有哪些能力可以用？
- 模型怎么理解这些能力能干嘛？
- 模型怎么保证参数不会乱传？
- 执行结果怎么回到上下文继续推理？
- 整个过程怎么被人类治理？
MCP 是在解决“模型与现实系统之间的协议问题”。
2.4 整体架构：Claude 是大脑，MCP 是神经系统
先看一张整体结构图：
关键点在这里：
- Claude 不直接接触数据库
- Claude 不直接发 HTTP 请求
- Claude 只和 MCP “说话”
这就像：大脑不会直接控制肌肉纤维，而是通过神经系统发信号。
2.5 一次完整的 MCP 调用流程
我们把一次完整调用拆开来看。
1.场景
用户说：
- “帮我查一下 test@example.com 这个用户的信息。”
Claude 首先做的是 语义判断：
- 这是一个“查用户”的请求
- 当前上下文里有没有能完成这件事的 Skill？
- 如果 MCP Client 注册过类似：
Claude 就会继续。
2️⃣ Claude 生成 MCP 调用（结构化）
不是自然语言，而是类似这样的结构化请求：
- { "tool": "get_user_by_email", "arguments": { "email": "test@example.com" } }
3️⃣ MCP Client 做校验
MCP Client 会检查：
- Skill 是否存在
- 参数是否符合 Schema
- 是否有权限调用
不通过，直接拦截。
4️⃣ Skill Server 执行真实逻辑
比如：
5️⃣ 返回结构化结果
- { "id": "u_123", "name": "Alice", "email": "test@example.com", "level": "VIP" }
注意这里不是“展示给用户”，而是：作为新上下文继续推理。Claude 可能会接着分析、对比、总结，最后才生成自然语言回复。
2.6 一个最小可运行的 MCP Skill 示例
下面这个示例非常简单，但已经具备 MCP 的完整形态。
- from mcp.server import Server server = Server("user_service") @server.tool() def get_user_by_email(email: str) -> dict: """ Query user information by email """ if email == "test@example.com": return { "id": "u_123", "name": "Alice", "email": email, "level": "VIP" } return {} server.run()
- 没有 prompt
- 没有 AI 逻辑
- 只是纯能力定义
但 Claude 会自动理解：
2.7 为什么 MCP 对 Agent 特别重要？
如果你做过 Agent，一定踩过这些坑：
- 流程写死
- 状态难维护
- 一步失败全盘崩
- 能力越多越混乱
MCP 的好处在于：
- Agent 不需要提前写死流程，模型可以动态规划。
一个典型 Agent 行为：
- 用户需求： “帮我分析这个用户最近的消费情况，并给出建议。”
- 调用 get_user_profile
- 调用 search_orders
- 汇总数据
- 给出分析和建议
- 你不需要写 if/else 流程。
2.8 MCP 和 Function Calling 的本质区别
很多人会问：
- “这和 OpenAI 的 Function Calling 有什么区别？”
简单说一句：
- Function Calling 是能力点，MCP 是能力体系。
2.9 在真实工程中如何用好 MCP？
一些经验之谈：
Skill 设计建议
- 一个 Skill 只做一件事
- 输入输出一定要稳定
- 不要返回自然语言
- 错误也要结构化
不要做的事情
- 把业务逻辑写进 Prompt
- 一个 Skill 干五六件事
- 让模型自己拼 SQL
- 让 Skill 返回“分析结论”
2.10 我对 MCP 的一个判断
站在工程视角，我认为：
- MCP 是目前最接近“大模型操作系统接口”的设计之一。
它做的不是让模型“更聪明”，而是让模型：
3.总结
如果你只是做 Demo，MCP 可能显得有点“重”。
但如果你在做的是：
- 企业级 AI 助手
- AI 编程系统
- 多 Agent 自动化平台
那 MCP 不是“可选项”，而是迟早要走到的那一步。
4.结束语
这篇博客就和大家分享到这里，如果大家在研究学习的过程当中有什么问题，可以加群进行讨论或发送邮件给我，我会尽我所能为您解答，与君共勉！
另外，博主出新书了《Hadoop与Spark大数据全景解析》、同时已出版的《深入理解Hive》、《Kafka并不难学》和《Hadoop大数据挖掘从入门到进阶实战》也可以和新书配套使用，喜欢的朋友或同学， 可以在公告栏那里点击购买链接购买博主的书进行学习，在此感谢大家的支持。关注下面公众号，根据提示，可免费获取书籍的教学视频。
公众号：
作者：哥不是小萝莉 ［关于我］［犒赏］
出处：http://www.cnblogs.com/smartloli/
转载请注明出处，谢谢合作！
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
