官方教程地址：https://anthropic.skilljar.com/
目前15门课，从零基础的Claude怎么用，到硬核的API开发、代码集成和MCP协议全都有。
之前的文章如下：
Claude Code 官方教程来啦！手把手带你学习Claude Code（一）
Claude Code 官方教程来啦！手把手带你学习Claude Code（二）掌握AI的四把钥匙：让你从"会用AI"到"用好AI"
Claude Code 官方教程来啦！Model Context Protocol（MCP）介绍（三） Introduction to Model Context Protocol
一文搞懂 MCP Client：AI 连接万物的"隐形桥梁"
你有没有想过，当你让 AI 去查 GitHub 仓库、读日历、发邮件的时候，中间到底发生了什么？今天，我们来拆解这座"隐形桥梁"—— MCP Client。
先说结论：MCP Client 是干什么的？
一句话概括——
MCP Client 是你的应用和 MCP Server 之间的通信中枢。
它帮你对接 MCP Server 提供的所有工具，把复杂的协议细节和消息交换全部包揽，让你的应用代码可以保持简洁干净。
打个比方：如果 MCP Server 是一家提供各种服务的超市，那 MCP Client 就是帮你跑腿的快递员。你只需要下单，它负责取货送达，你完全不用关心超市内部是怎么运作的。
通信方式：想怎么连，就怎么连
MCP 协议有一个非常优雅的设计理念，叫做传输无关性（Transport Agnostic）。
翻译成人话就是：客户端和服务端之间的通信方式，不是写死的，你可以自由选择。
最常见的方式，是 MCP Client 和 MCP Server 跑在同一台机器上，通过标准输入输出（stdin/stdout）直接通信，简单高效。
但如果你有更复杂的场景，它同样支持：
🔹 HTTP —— 适合 Web 服务场景，跨网络调用
🔹 WebSocket —— 适合需要实时双向通信的场景
🔹 其他网络协议 —— 灵活扩展，按需选择
这就好比你和朋友聊天，可以打电话、发微信、发邮件，甚至写信——沟通的"管道"不同，但传递的信息内容是一样的。这种设计让 MCP 的适用范围变得非常广泛。
核心对话：两种关键消息类型
连接建立之后，Client 和 Server 之间的交流，主要靠两组"问答"来完成：
第一组：工具发现
| 消息 | 方向 | 作用 |
|---|---|---|
ListToolsRequest | Client → Server | "你有哪些工具可以用？" |
ListToolsResult | Server → Client | "这是我的工具清单，请查收。" |
这一步就像你走进一家餐厅，先看菜单。Client 通过这组消息，了解 Server 当前能提供哪些能力。
第二组：工具调用
| 消息 | 方向 | 作用 |
|---|---|---|
CallToolRequest | Client → Server | "帮我执行这个工具，参数是这些。" |
CallToolResult | Server → Client | "执行完了，结果在这里。" |
这一步就是真正下单点菜了。Client 把具体的工具名称和参数传过去，Server 执行完毕后把结果返回。
整个对话模型简洁明了：先问有什么，再用什么。
完整流程拆解：一个请求的12步旅程
理论讲完了，我们来看一个真实场景。
假设用户问了一句："我在 GitHub 上有哪些仓库？"
这个看似简单的问题，在系统内部会经历一趟完整的旅程。我把它拆成 12 步，每一步都标注了角色和职责：
📌 阶段一：准备
① 用户提问 → 用户把问题提交给你的服务端
② 工具盘点 → 服务端需要知道当前有哪些工具可以提供给 Claude
③ 询问工具清单 → 服务端让 MCP Client 去查可用工具
④ 协议通信 → MCP Client 向 MCP Server 发送 ListToolsRequest，拿到 ListToolsResult
📌 阶段二：决策
⑤ 请求 Claude → 服务端把用户问题 + 工具列表一起发送给 Claude
⑥ Claude 判断 → Claude 分析后决定：需要调用某个工具来回答这个问题
📌 阶段三：执行
⑦ 发起调用 → 服务端让 MCP Client 执行 Claude 指定的工具
⑧ 真实 API 调用 → MCP Client 向 MCP Server 发送 CallToolRequest，Server 去调用 GitHub API
⑨ 数据回传 → GitHub 返回仓库数据，经 MCP Server 封装成 CallToolResult 回传
📌 阶段四：交付
⑩ 结果给 Claude → 服务端把工具执行结果发回给 Claude
⑪ 生成回答 → Claude 根据仓库数据，组织出一段自然语言回答
⑫ 用户收到答案 → 服务端把最终回答展示给用户
流程很长？确实。但仔细看你会发现——
每个组件的职责边界都非常清晰：
- 你的服务端：
负责编排整个流程
- MCP Client：
负责和 MCP Server 通信
- MCP Server：
负责对接外部 API
- Claude：
负责理解问题、决策工具调用、生成回答
各司其职，互不越界。
为什么你应该关注 MCP Client？
看到这里，你可能会问：这么多层封装，有必要吗？
答案是：非常有必要。
MCP Client 的价值，在于它把"和外部服务打交道"这件最脏最累的活，彻底封装掉了。
没有它，你需要自己处理协议握手、消息序列化、错误重试、超时管理……每接入一个新服务，就要重新造一遍轮子。
有了它，你只需要关心两件事：用户要什么，Claude 怎么答。 剩下的，MCP Client 帮你搞定。
写在最后
MCP 的设计哲学，和 Unix 管道很像——做好一件事，然后通过标准接口组合起来。
MCP Client 就是这个组合中最关键的连接件。理解了它的工作原理，你就掌握了构建 AI Agent 应用的核心拼图之一。
在接下来的内容中，我们会动手实现自己的 MCP Client 和 Server。理论到实践，就差这一步了。
准备好了吗？下一篇，我们开始写代码。 🔧
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连，你的支持是我持续输出的最大动力。
