09 · 怎么连外部服务
翔宇跟了很多人讨论 Claude Code 的局限。多数人觉得是模型不够强。但追到底发现，有一类需求不管模型多强都搞不定——不是脑子的问题，是手不够长。MCP
翔宇跟了很多人讨论 Claude Code 的局限。多数人觉得是模型不够强。但追到底发现，有一类需求不管模型多强都搞不定——不是脑子的问题，是手不够长。MCP 就是给 AI 接上一双标准化的手。——翔宇
要点速览
- 你将理解为什么 Claude Code 住在你电脑里却依然「够不到」很多东西
- 你将理解 MCP 的三层架构（Host-Client-Server）各自在做什么
- 你将理解 Tools、Resources、Prompts 三种能力的本质区别
- 你将理解传输方式和配置范围的设计逻辑
- 你将理解 Elicitation 为什么是 MCP 从「单向调用」走向「双向对话」的关键一步
1. 住在你电脑里，但够不到的东西
第 1 篇我们拆了「位置」——Claude Code 住在你电脑里，所以它能读文件、改代码、跑命令。这是它和 ChatGPT 的核心区别。
但试想一个场景。你让 Claude Code 帮你做一件事：「看看 GitHub 上那个 PR 的评论，然后把 Jira 上对应的 ticket 状态改成已完成。」
它愣住了。
不是因为它不理解你说的话。也不是因为它不够聪明——即使换上最强的模型也一样。
问题在于：GitHub 的数据在 GitHub 的服务器上。Jira 的数据在 Jira 的服务器上。这些东西不在你的文件系统里，也不是一个命令就能拿到的。Claude Code 住在你的电脑里，但你的电脑不等于整个世界。
第 1 篇解决的是「AI 在浏览器里够不到你的代码」，这篇要解决的是「AI 在你电脑里够不到外部世界」。同一个问题，只是换了一层。
那怎么办？我们从最朴素的方式开始搭。
2. 最朴素的方式：手动帮它够
没有任何特殊工具的情况下，你可以帮它写一个 Shell 脚本，用 GitHub 的 API 拉评论，再用 Jira 的 API 改状态。然后让 Claude Code 执行这个脚本。
能行。这是第一块积木。
但你很快会碰到一个问题：每个外部服务的 API 都不一样。GitHub 用 REST，Slack 用 WebSocket，数据库用 SQL 连接。你得为每个服务写一套对接代码。10 个服务就是 10 套。
好，这是成本问题，忍忍也能接受。再加第二块积木。
认证方式也不一样。有的用 API Key，有的用 OAuth，有的用账号密码。每换一个服务就重新折腾一遍认证。
第三块积木。你写了这些脚本，你同事想用怎么办？他得重写一遍，因为你的脚本里写死了你的认证信息和你的使用方式。
三块积木摞在一起，你看到了什么？——不是技术上做不到，是没有一个统一的标准。每个服务都是一座孤岛，每次连接都是手工搭桥。
🧠 底层逻辑 想一想：历史上有没有类似的问题？一堆不同的设备，每个都有自己的接口，导致适配成本极高？
3. 加一个需求：统一接口
你一定经历过这个时代。抽屉里一堆线：iPhone 用 Lightning，安卓用 Micro-USB，相机用 Mini-USB，老笔记本用圆形充电口。出门一趟，得带四根线。
然后 USB-C 出现了。一个接口连所有设备。充电、传数据、接显示器，全用这一个。
MCP 做的事情和 USB-C 一模一样，只不过连的不是物理设备，而是软件服务。
MCP 全称 Model Context Protocol（模型上下文协议）。它定义了一个标准接口：所有 AI 工具按这个标准发请求，所有外部服务按这个标准响应。AI 工具只需要懂 MCP 这一种「插口」，就能连上所有服务。
但类比总有边界。USB-C 是物理接口，MCP 是软件协议。USB-C 是被动的线缆——你插上去，它传数据；而 MCP 的连接是主动的——AI 可以决定什么时候调用什么工具，甚至 MCP 服务器可以反过来向用户提问（这个后面再搭）。所以记住：USB-C 类比帮你理解「一个标准连所有服务」这件事，但别把它推得太远。
有了统一接口，那个「10 个服务 10 套代码」的问题变成了什么？
4. 再加一个需求：规模化——M×N 变成 M+N
这里有一个特别值得停下来想的数学关系。
假设世界上有 10 个 AI 工具（Claude Code、Cursor、Windsurf……），100 个外部服务（GitHub、Jira、Slack、各种数据库……）。
没有 MCP 的世界：每个 AI 工具都得为每个服务写一套对接代码。10 x 100 = 1000 套代码。
有 MCP 的世界：每个 AI 工具只需要实现 MCP 客户端（10 个），每个服务只需要实现 MCP 服务器（100 个）。10 + 100 = 110 个组件。
1000 vs 110。不是「好一点」，是量级的差异。随着数量增长，差距会越来越大。200 个 AI 工具、1000 个服务？没有 MCP 是 200,000 套代码，有 MCP 是 1,200 个组件。
🎨 打个比方 这就是「协议」的魔法。HTTP 做了同样的事——浏览器不需要知道服务器用什么语言写的，服务器也不需要知道用户用什么浏览器。一个协议隔开了两边的复杂性。MCP 对 AI 工具做的事情和 HTTP 对 Web 做的事情在结构上完全相同。
到这里，我们有了统一接口和规模化的基础。下一步，拆开看看 MCP 的内部结构长什么样。
5. 拆开 MCP：三个角色
MCP 有三个角色。别被术语吓到，用酒店来理解。
你住酒店。你打电话给前台说「我要一杯咖啡」。前台不会自己跑去磨咖啡——前台把你的需求转给餐饮部，餐饮部做好送到你房间。
| 角色 | 在 MCP 中叫什么 | 干什么 | 在酒店里是谁 |
|---|---|---|---|
| 你 | 用户 | 发出请求 | 住客 |
| 前台 | Host（主机） | 接收请求，协调调度 | 酒店前台 |
| 管家 | Client（客户端） | 和具体服务对接，一对一 | 专属管家 |
| 服务部门 | Server（服务器） | 提供具体能力 | 餐饮部/客房部/礼宾部 |
Claude Code 就是 Host。 它是整个系统的协调中心。
Host 内部有多个 Client，每个 Client 对接一个 Server。注意这个一对一关系——一个 Client 只和一个 Server 说话。你的「GitHub 管家」只负责 GitHub，你的「数据库管家」只负责数据库。互不干扰。
想一想：很多人把 Client 和 Server 搞反。记住一个简单的判断——Claude Code 这边是 Client（它发请求），外部服务那边是 Server（它响应请求）。 就像你（Client）去餐厅点菜，厨房（Server）接单做菜。
6. 三种能力——手、眼睛、流程手册
有了架构，下一层：MCP 给 AI 接上了什么能力？
不是只有一双手。它定义了三种不同的能力，官方叫「原语」（Primitives）。名字听着玄，拆开看很直觉。
a. Tools（工具）——手
Tools 是可执行的操作。「创建一个 GitHub PR」「发一条 Slack 消息」「往数据库插一条数据」——这些都是 Tools。
关键点：Tools 的控制权在 AI 手里。 你不需要告诉 Claude Code「现在调用 GitHub 的 create_pr 工具」。你只需要说「帮我提个 PR」，它自己判断该用哪个工具、传什么参数。
这和命令行脚本的区别在于：脚本是你写死流程让它执行，Tools 是 AI 自己判断什么时候需要用什么。
b. Resources（资源）——眼睛
Resources 是只读的数据源。比如一个文档、一张数据库表的 schema、一份配置文件。
注意「只读」这两个字。Resources 不会改变任何东西——它的作用是给 AI 提供上下文。就像你在做决策前先看一眼参考资料。
c. Prompts（提示）——流程手册
Prompts 是可复用的交互模板。比如「代码审查」这个动作，每次审查的步骤是一样的：先看整体结构、再看逻辑、最后看风格。把这个步骤做成一个 Prompt 模板，每次直接调用。
💬 通俗讲 三种能力用一句话记：Tools 是做事的手，Resources 是看资料的眼睛，Prompts 是标准化的流程手册。 手改变世界，眼睛观察世界，流程手册确保每次操作一致。
想一想：你日常工作中有没有一些操作是每次步骤一样的？如果有，那就是 Prompts 适合做的事。而如果你想让 AI 去执行一个动作、产生实际效果，那是 Tools 的领域。
7. 传输方式——怎么送信
前面搭了「说什么」（三种能力），现在搭「怎么说」（传输方式）。
还是酒店的比方。你可以打电话找前台（远程通信），也可以走到前台面对面说（本地通信）。MCP 有三种传输方式：
| 传输方式 | 怎么理解 | 什么场景用 |
|---|---|---|
| HTTP | 打电话——远程通信，标准方式 | 连接云服务（GitHub、Sentry 等） |
| SSE | 发传真——能用，但过时了 | 仅部分老服务还在用，已标记废弃 |
| stdio | 面对面说——本地通信，零延迟 | 连接本地运行的服务 |
为什么 SSE 被废弃了？SSE（Server-Sent Events）是单向的——服务器向客户端推送数据，但客户端向服务器发消息需要另外的通道。HTTP 的 Streamable HTTP 模式解决了这个问题：用同一个连接实现双向通信。一个通道替代了两个，更简洁也更可靠。协议演进的方向总是朝着更少的概念、更统一的模型。
8. 配置范围——你的工具箱给谁用
MCP 服务器配好之后，有一个你必须理解的设计：它在多大范围内生效？
三种范围，用快递柜的比方：
本地范围（local）——你家门口的快递柜。只有你在这个项目里能用。换一个项目就没了。这是默认选项。
项目范围（project）——办公室的快递柜。整个团队都能用。配置存在项目的 .mcp.json 文件里，提交到代码仓库后同事也能看到。
用户范围（user）——你随身带的钥匙。不管你打开哪个项目，这个 MCP 服务器都在。适合那些你到处都用的工具。
🔑 关键点 大多数新手会犯的一个错：装了 MCP 服务器，换个项目发现没了。原因就是默认范围是 local。如果一个工具你每天都用（比如搜索、浏览器控制），应该设成 user 范围。
9. 最后一块积木：Elicitation——从单向到双向
到这里，我们搭了：统一接口 → 三层架构 → 三种能力 → 传输方式 → 配置范围。整栋楼快盖完了。但还缺一块。
传统的 MCP 交互是单向的：Claude Code 向 MCP 服务器发请求，服务器返回结果。就像你去自动售货机——投币、按按钮、取饮料。机器不会反过来问你「你确定要这个口味吗？」
但现实世界的交互很少是纯单向的。你去餐厅点菜，服务员可能会问「牛排要几分熟？」「要不要加芝士？」这些信息是你点菜的时候没说的，但服务员需要才能做出你想要的菜。
Elicitation 就是让 MCP 服务器具备「反问」能力的机制。
工作流程很直觉：MCP 服务器在执行过程中发现需要额外信息 → 它向 Claude Code 发起一个 Elicitation 请求 → Claude Code 把这个请求展示给你（像一个弹出的表单）→ 你填完 → 信息返回 MCP 服务器 → 服务器继续执行。
🧠 底层逻辑 Elicitation 的本质是把 MCP 从「函数调用」模型升级到了「对话」模型。函数调用是同步的、一次性的——给输入、返回输出。对话是可以来回的——中间可以追问、可以澄清。这个转变让 MCP 能覆盖的场景大幅扩展。比如部署工具在部署前需要你确认目标环境，数据库工具在执行危险操作前需要你输入确认码。以前这些场景只能通过 Hooks 或者额外的脚本来绕路实现，现在 MCP 服务器本身就能优雅地处理。
10. 回头看全貌
现在把所有积木摆在一起。
从最朴素的「手动写脚本」出发，我们一步步搭出了：
统一接口（不再每个服务一套代码） → 三层架构 Host-Client-Server（协调、对接、提供能力各司其职） → 三种能力 Tools/Resources/Prompts（手、眼睛、流程手册） → 传输方式（本地 stdio、远程 HTTP） → 配置范围（local/project/user） → Elicitation（服务器能反问用户）。
这就是 MCP 的完整画面。
理解它之后，你看 Claude Code 的方式会变。以前你可能觉得它就是一个「能读文件、能跑命令的 AI」。现在你会意识到，它是一个可以连接你整个技术栈的节点——代码在 GitHub、任务在 Jira、监控在 Sentry、沟通在 Slack、数据在 PostgreSQL。这些以前需要你在不同标签页之间切来切去做的事情，现在可以用一句自然语言串起来。
但注意——能做到不等于应该一股脑全做。从一个你最需要的连接开始。对大多数开发者来说，这个连接大概率是 GitHub 或者你的数据库。
🎯 一句话理解 MCP 不是给 AI 加脑子，是给 AI 接手。它解决的不是「能不能想到」，是「能不能够到」。
11. 温和纠偏：一个常见误解
「MCP 服务器越多越好」
恰恰相反。每个 MCP 服务器都会消耗上下文窗口——因为 Claude Code 需要知道每个工具的描述和参数。装 20 个 MCP 服务器，Claude Code 在开始工作前就已经吃掉了大量 token 来理解这些工具。
这和电脑装软件一个道理。你不会把 App Store 里所有 APP 都装上——虽然每个都可能有用，但它们占空间、拖慢启动速度。只装你真正在用的。少即是多。
顺便纠正两个次要的误解。MCP 不是 Claude Code 专属的——它是开源协议，Cursor、Windsurf、任何 AI 工具都能实现。MCP 也不替代命令行——它补充命令行够不到的那些外部服务。
12. 你真的懂了吗
这篇拆了一个概念：连接。
- 有人说「Claude Code 什么都能干，不需要 MCP」。你能解释为什么这不对吗？它「够不到」的东西具体是什么？
- MCP 的三层架构中，Client 和 Server 分别在哪一端？你能画出它们的关系吗？
- Tools 和 Resources 都是 MCP 提供的能力，它们的核心区别是什么？用一个现实世界的例子说明。
- USB-C 类比在什么地方成立，什么地方不成立？如果有人把这个类比推到极致（「MCP 就是一根线」），你怎么纠正？
- Elicitation 解决的问题，如果没有 Elicitation，你会怎么绕路解决？