Mcp on Kalend's Blog

A2A 协议深度解析：为什么说它是 AI Agent 时代的 HTTP

Fri, 12 Jun 2026 08:00:00 +0800

引子：Agent 世界的「巴别塔」

现在的 AI Agent 生态，像极了没有统一语言的巴别塔——LangGraph 说一种方言，CrewAI 说另一种，AutoGen 又是第三种。框架越来越多，Agent 之间却互不相通。

每对 Agent 想要协作，就得写定制胶水代码。5 个 Agent 需要 10 对集成，10 个 Agent 需要 45 对——N² 的复杂度，根本不靠谱。

Google 在 2025 年 4 月 Cloud Next 大会上发布了 A2A（Agent-to-Agent）协议，干的就是这件事：给 Agent 世界定一个统一通信标准。

先说结论：A2A 不是又一个炫技协议，它是 Agent 互联网的基础设施层。就像 HTTP 之于 Web——你不需要每天手写 HTTP 请求，但它无处不在。A2A + MCP 将成为所有多 Agent 系统的标准配置，一个管 Agent 间通信，一个管工具连接。

第一章：为什么需要 A2A？

N² 的集成噩梦只是表象，更深层的问题是：每个框架都在用自己的方式定义「Agent 是什么」「怎么找到另一个 Agent」「任务怎么流转」。

类比互联网早期：每个网络有自己的协议栈，跨网通信需要专门的网关。直到 TCP/IP 一统天下，才有了真正的互联网。A2A 想做的事一模一样——给 Agent 定义一套通用的「TCP/IP」。

A2A 的核心主张很简洁：

Agent 之间不需要暴露内部实现（不共享 memory、不共享 tools）
只需要暴露能力描述和标准接口
任何框架构建的 Agent 都能发现彼此、协商交互方式、协作完成任务

这套思路被 Linux Foundation 采纳，现在以 Apache 2.0 开源在 a2aproject/A2A，GitHub 上已超过 24,000 Stars。

为什么不是 MCP？ 因为 MCP 解决的是 Agent 和工具之间的连接（相当于 USB 接口），而 Agent 之间的协作需要更复杂的状态管理、生命周期控制和协商机制——这些 MCP 的无状态模型做不了。就像 USB 和 HTTP 不矛盾，MCP 和 A2A 也不矛盾。

第二章：三个核心概念

A2A 只围绕三个原语构建，极简但够用。理解这三个概念，就理解了 A2A 的全部设计哲学。

Agent Card——Agent 的 DNS + 名片

每个 A2A Agent 在 /.well-known/agent.json 路径下暴露一个 JSON 文件，描述自己的能力、端点、认证方式。

这东西本质就是 Agent 的 DNS 记录 + 数字名片合体：别人不需要知道你内部怎么实现，看你的 Agent Card 就知道你能干什么、怎么连你。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


{
 "name": "ticket-agent",
 "description": "企业 IT 工单管理智能体",
 "url": "https://ticket.example.com/a2a",
 "capabilities": {
 "streaming": true,
 "pushNotifications": true
 },
 "skills": [
 {
 "name": "create_ticket",
 "description": "创建 IT 工单"
 },
 {
 "name": "query_tickets",
 "description": "查询工单状态"
 }
 ],
 "authentication": {
 "schemes": ["bearer"]
 }
}

v1.0 规范引入了签名 Agent Card——用密码学签名验证域名所有权。别人拿到你的 Agent Card 时，可以验证它确实是你签发的，不是被中间人篡改过的。这对企业级部署尤其重要：你不能让一个伪造的 Agent 冒充你的财务系统。

Agent Card 还有一个很聪明的细节：/.well-known/ 路径。这是 Web 标准的约定（类似 robots.txt），意味着任何 Agent 只要知道对方域名，就能用标准路径发现对方的能力。不需要中心化注册表，纯分布式发现。

Task——协作的基本单位

A2A 用 Task 来组织一次协作交互。Task 有明确的生命周期：

1
2
3


submitted → working → input-required → completed
 → failed
 → canceled

每个 Task 都有唯一 ID、状态历史和消息记录。调用方可以随时查询 Task 状态，不需要一直保持连接。

重点是三种执行模式：

模式	适用场景	特点
同步	简单查询、秒级响应	一问一答，立即返回
异步	数据分析、长耗时任务	提交后轮询或推送通知，支持运行数小时
流式	实时生成、代码编写	SSE 推送中间结果，边算边看

异步模式是生产环境的关键——一个数据清洗 Agent 处理百万行数据，可能跑 30 分钟，A2A 通过 push notification 机制让调用方不用傻等。调用方提交任务后去做别的事，等结果就绪了再回来处理。

还有一个容易忽略的设计：input-required 状态。当被调用的 Agent 需要额外信息才能继续时（比如「请提供数据库连接字符串」），它不会直接 fail，而是切到 input-required 等待调用方补充信息。这让多轮交互变得自然——就像两个人对话时的追问。

Transport——JSON-RPC 2.0 + SSE

传输层选了 JSON-RPC 2.0 over HTTPS，流式场景用 SSE（Server-Sent Events）。

为什么不选 gRPC 或 WebSocket？因为 JSON-RPC 2.0 够简单、够通用、HTTP 原生兼容。A2A 追求的是最大范围采纳，不是追求极致性能——这和 HTTP 当年的设计哲学一致。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


# 伪代码：一个 A2A 调用的基本流程
import requests

# 1. 获取对方的 Agent Card
card = requests.get("https://ticket.example.com/.well-known/agent.json").json()

# 2. 发送 Task 请求
response = requests.post(card["url"], json={
 "jsonrpc": "2.0",
 "method": "tasks/send",
 "params": {
 "task": {
 "id": "task-001",
 "message": {
 "role": "user",
 "parts": [{"text": "帮我查一下 REQ12312 的状态"}]
 }
 }
 },
 "id": 1
})

整个交互就三步：发现（拿 Agent Card）→ 发起（创建 Task）→ 跟进（获取结果或接收推送）。

一个容易忽略的优点：JSON-RPC 2.0 的 id 字段天然支持批量请求和响应关联。如果你需要同时向 5 个 Agent 发送任务，一个 HTTP 请求搞定，不需要 5 次连接。

第三章：A2A vs MCP——不是替代，是两条腿

一句话定义：

MCP 是 Agent 的 USB——连接工具（数据库、API、文件系统）
A2A 是 Agent 的 HTTP——连接其他 Agent

维度	MCP	A2A
定位	Agent ↔ 工具连接	Agent ↔ Agent 协作
通信对象	工具/资源/提示词	其他智能体
核心抽象	Tool / Resource / Prompt	Agent Card / Task
状态管理	无状态（调用即返回）	有状态（Task 生命周期）
安全模型	本地进程信任	网络级认证 + 签名
治理	Anthropic → 社区开放	Linux Foundation

三个常见误区必须澄清：

「A2A 会取代 MCP」→ 错。它们互补。一个 Agent 通过 MCP 调用数据库查询工具，同时通过 A2A 和另一个 Agent 协作完成跨部门流程。
「MCP 只能调工具」→ 不完全对。MCP 也能做简单通信，但它不管理 Task 生命周期，不适合长时间协作。
「A2A 更先进」→ 只是定位不同。MCP 解决「Agent 如何使用工具」，A2A 解决「Agent 之间如何协作」，都是基础设施层。

一个典型的企业级架构是这样的：

1
2
3
4
5
6
7
8
9


┌─────────────┐ A2A ┌─────────────┐
│ HR Agent │◄──────────►│ IT Agent │
│ (LangGraph)│ │ (Google ADK)│
└──────┬──────┘ └──────┬──────┘
 │ MCP │ MCP
 ▼ ▼
┌─────────────┐ ┌─────────────┐
│ HR 数据库 │ │ 工单系统 │
└─────────────┘ └─────────────┘

HR Agent 通过 MCP 访问 HR 数据库，通过 A2A 和 IT Agent 协作完成「新员工入职」这个跨部门任务。

第四章：生态版图

A2A 的采纳速度超出预期。从 2025 年 4 月发布到 2026 年 4 月 v1.0 稳定版，仅仅一年就完成了从实验性协议到生产级标准的跃迁。截止 2026 年 4 月：

24,000+ GitHub Stars（a2aproject/A2A），Apache 2.0 开源
6 种官方 SDK：Python、JavaScript、Go、Java、.NET、Rust
框架原生支持：Google ADK、LangGraph、CrewAI、LlamaIndex、Semantic Kernel、AutoGen、BeeAI
企业采纳：Salesforce Agentforce、SAP Joule、ServiceNow Now Assist 等已集成

DeepLearning.AI 也上线了官方 A2A 短课程，由 Google Cloud 和 IBM Research 联合出品。这说明 A2A 已经从「圈内人的玩具」变成了开发者必修课。

IBM 的 BeeAI 框架深度参与了 A2A 生态共建，不仅贡献了任务生命周期管理和多轮对话等多个核心参考实现，还推动了社区层面的协议融合讨论。ACP（Agent Communication Protocol）等同类协议也在探索与 A2A 的兼容路径——从竞争走向统一，是 Agent 生态的必然方向。

第五章：未来方向

A2A 规范仍在快速演进，几个值得关注的方向：

签名 Agent Card（已落地）： 密码学签名验证域名归属，解决企业级信任问题。这是生产部署的前置条件——在金融、医疗等受监管行业，没有签名验证的 Agent 通信根本无法通过合规审查。

Agent Directory（规划中）： 从「我知道你在哪」进化到「我能发现你」。类似 DNS 服务发现机制，让 Agent 能在一个注册中心里搜索和发现其他 Agent 的能力。目前发现依赖 /.well-known/ 约定（你需要知道对方域名），Directory 则支持模糊搜索和分类浏览。

跨域信任链（探索中）： 当 Agent A 委托 Agent B 执行任务，而 B 又需要调用 Agent C 时，如何建立端到端的信任链？目前的签名 Agent Card 解决了点对点信任，但多跳场景下的信任传递还在讨论中。这是企业级生产部署必须攻克的难题。

动态能力协商： 支持 Agent 在任务执行过程中动态添加新的交互方式（比如从文本切换到音视频）。

多租户隔离（规划中）： 企业 SaaS 场景下，同一个 Agent 服务需要为不同租户隔离数据和权限。规范路线图中已包含多租户支持的设计，预计在后续版本中落地。

Rust SDK 加入： 第六种官方 SDK，覆盖系统级高性能场景。

第六章：对我们意味着什么？

个人开发者： 现在可以构建跨框架的多 Agent 系统了。用 LangGraph 做编排 Agent，用 Google ADK 做执行 Agent，通过 A2A 通信，不再被单一框架锁定。入门门槛就是 pip install a2a-sdk。

企业： A2A 让不同部门、不同技术栈的 Agent 可以互操作。IT 部门用 Java 构建的运维 Agent 和业务部门用 Python 构建的分析 Agent，通过 A2A 标准协议就能协作。IT 采购不用再纠结选哪个框架。

趋势判断： A2A 在 2026-2027 年大概率会成为 Agent 互操作的事实标准。判断依据很简单——它是目前唯一同时具备大厂背书（Google/IBM/Salesforce）、开放治理（Linux Foundation）和活跃社区（24,000+ Stars）的方案。历史经验看，这种「三合一」组合在技术标准化中几乎没有失败的先例。

落地方案： 如果你已经在用 MCP（连接工具），那你已经走了一半。下一步是在需要多 Agent 协作的场景引入 A2A。从两个 Agent 的简单协作开始，验证流程跑通后再扩展。

一个务实的起步路径：先用 A2A Python SDK 跑通官方示例（两个本地 Agent 互发消息），然后把其中一个换成你自己的业务 Agent，逐步替换。不要一上来就搞 10 个 Agent 的复杂编排——先跑通两个，再逐步扩展。

什么时候该用 A2A？ 一个简单判断标准：如果你的系统里有 2 个以上 Agent 需要互相协作（不是简单的串行调用），而且它们可能用不同框架构建，那就是 A2A 的场景。如果只是单个 Agent 调用一堆工具，MCP 就够了。

结尾

Agent 世界的「巴别塔」正在被拆解。A2A 不是技术炫技，是基础设施——就像 HTTP 一样，你可能不会每天直接写 A2A 调用，但它会成为多 Agent 系统的默认通信层。

A2A + MCP 的组合，就是 Agent 时代的 HTTP + USB：一个管 Agent 间通信，一个管工具连接。两者互补，缺一不可。

你已经在用 MCP 了吗？准备试试 A2A 做多 Agent 协作吗？评论区聊聊你的场景。

A2A 协议深度解析：为什么说它是 AI Agent 时代的 HTTP

Fri, 12 Jun 2026 08:00:00 +0800

引子：Agent 世界的「巴别塔」

现在的 AI Agent 生态，像极了没有统一语言的巴别塔——LangGraph 说一种方言，CrewAI 说另一种，AutoGen 又是第三种。框架越来越多，Agent 之间却互不相通。

每对 Agent 想要协作，就得写定制胶水代码。5 个 Agent 需要 10 对集成，10 个 Agent 需要 45 对——N² 的复杂度，根本不靠谱。

Google 在 2025 年 4 月 Cloud Next 大会上发布了 A2A（Agent-to-Agent）协议，干的就是这件事：给 Agent 世界定一个统一通信标准。

先说结论：A2A 不是又一个炫技协议，它是 Agent 互联网的基础设施层。就像 HTTP 之于 Web——你不需要每天手写 HTTP 请求，但它无处不在。A2A + MCP 将成为所有多 Agent 系统的标准配置，一个管 Agent 间通信，一个管 Agent 与工具连接。

第一章：为什么需要 A2A？

N² 的集成噩梦只是表象，更深层的问题是：每个框架都在用自己的方式定义「Agent 是什么」「怎么找到另一个 Agent」「任务怎么流转」。

A2A 的核心主张很简洁：

Agent 之间不需要暴露内部实现（不共享 memory、不共享 tools）
只需要暴露能力描述和标准接口
任何框架构建的 Agent 都能发现彼此、协商交互方式、协作完成任务

这套思路被 Linux Foundation 采纳，现在以 Apache 2.0 开源在 a2aproject/A2A，GitHub 上已超过 24,000 Stars。

第二章：三个核心概念

A2A 只围绕三个原语构建，极简但够用。

Agent Card——Agent 的 DNS + 名片

每个 A2A Agent 在 /.well-known/agent.json 路径下暴露一个 JSON 文件，描述自己的能力、端点、认证方式。

这东西本质就是 Agent 的 DNS 记录 + 数字名片合体：别人不需要知道你内部怎么实现，看你的 Agent Card 就知道你能干什么、怎么连你。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


{
 "name": "ticket-agent",
 "description": "企业 IT 工单管理智能体",
 "url": "https://ticket.example.com/a2a",
 "capabilities": {
 "streaming": true,
 "pushNotifications": true
 },
 "skills": [
 {
 "name": "create_ticket",
 "description": "创建 IT 工单"
 },
 {
 "name": "query_tickets",
 "description": "查询工单状态"
 }
 ],
 "authentication": {
 "schemes": ["bearer"]
 }
}

v1.0 规范引入了签名 Agent Card——用密码学签名验证域名所有权。别人拿到你的 Agent Card 时，可以验证它确实是你签发的，不是被中间人篡改过的。

Task——协作的基本单位

A2A 用 Task 来组织一次协作交互。Task 有明确的生命周期：

1
2
3


submitted → working → input-required → completed
 → failed
 → canceled

重点是三种执行模式：

模式	适用场景	特点
同步	简单查询、秒级响应	一问一答，立即返回
异步	数据分析、长耗时任务	提交后轮询或推送通知，支持运行数小时
流式	实时生成、代码编写	SSE 推送中间结果，边算边看

异步模式是生产环境的关键——一个数据清洗 Agent 处理百万行数据，可能跑 30 分钟，A2A 通过 push notification 机制让调用方不用傻等。

Transport——JSON-RPC 2.0 + SSE

传输层选了 JSON-RPC 2.0 over HTTPS，流式场景用 SSE（Server-Sent Events）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


# 伪代码：一个 A2A 调用的基本流程
import requests

# 1. 获取对方的 Agent Card
card = requests.get("https://ticket.example.com/.well-known/agent.json").json()

# 2. 发送 Task 请求
response = requests.post(card["url"], json={
 "jsonrpc": "2.0",
 "method": "tasks/send",
 "params": {
 "task": {
 "id": "task-001",
 "message": {
 "role": "user",
 "parts": [{"text": "帮我查一下 REQ12312 的状态"}]
 }
 }
 },
 "id": 1
})

整个交互就三步：发现（拿 Agent Card）→ 发起（创建 Task）→ 跟进（获取结果或接收推送）。

第三章：A2A vs MCP——不是替代，是两条腿

一句话定义：

MCP 是 Agent 的 USB——连接工具（数据库、API、文件系统）
A2A 是 Agent 的 HTTP——连接其他 Agent

维度	MCP	A2A
定位	Agent ↔ 工具连接	Agent ↔ Agent 协作
通信对象	工具/资源/提示词	其他智能体
核心抽象	Tool / Resource / Prompt	Agent Card / Task
状态管理	无状态（调用即返回）	有状态（Task 生命周期）
安全模型	本地进程信任	网络级认证 + 签名
治理	Anthropic → 社区开放	Linux Foundation

三个常见误区必须澄清：

「A2A 会取代 MCP」→ 错。它们互补。一个 Agent 通过 MCP 调用数据库查询工具，同时通过 A2A 和另一个 Agent 协作完成跨部门流程。
「MCP 只能调工具」→ 不完全对。MCP 也能做简单通信，但它不管理 Task 生命周期，不适合长时间协作。
「A2A 更先进」→ 只是定位不同。MCP 解决「Agent 如何使用工具」，A2A 解决「Agent 之间如何协作」，都是基础设施层。

一个典型的企业级架构是这样的：

1
2
3
4
5
6
7
8
9


┌─────────────┐ A2A ┌─────────────┐
│ HR Agent │◄──────────►│ IT Agent │
│ (LangGraph)│ │ (Google ADK)│
└──────┬──────┘ └──────┬──────┘
 │ MCP │ MCP
 ▼ ▼
┌─────────────┐ ┌─────────────┐
│ HR 数据库 │ │ 工单系统 │
└─────────────┘ └─────────────┘

HR Agent 通过 MCP 访问 HR 数据库，通过 A2A 和 IT Agent 协作完成「新员工入职」这个跨部门任务。

第四章：生态版图

A2A 的采纳速度超出预期。截止 2026 年 4 月：

24,000+ GitHub Stars（a2aproject/A2A），Apache 2.0 开源
6 种官方 SDK：Python、JavaScript、Go、Java、.NET、Rust
框架原生支持：Google ADK、LangGraph、CrewAI、LlamaIndex、Semantic Kernel、AutoGen、BeeAI
企业采纳：Salesforce Agentforce、SAP Joule、ServiceNow Now Assist 等已集成

DeepLearning.AI 也上线了官方 A2A 短课程，由 Google Cloud 和 IBM Research 联合出品。

IBM 的 BeeAI 框架深度参与了 A2A 生态共建，社区层面的协议融合一直在推进——从竞争走向统一是 Agent 生态的必然方向。

第五章：未来方向

A2A 规范仍在快速演进，几个值得关注的方向：

签名 Agent Card（已落地）： 密码学签名验证域名归属，解决企业级信任问题。这是生产部署的前置条件。

Agent Directory（规划中）： 从「我知道你在哪」进化到「我能发现你」。类似 DNS 服务发现机制，让 Agent 能在一个注册中心里搜索和发现其他 Agent 的能力。

动态能力协商： 支持 Agent 在任务执行过程中动态添加新的交互方式（比如从文本切换到音视频）。

Rust SDK 加入： 第六种官方 SDK，覆盖系统级高性能场景。

第六章：对我们意味着什么？

结尾

A2A + MCP 的组合，就是 Agent 时代的 HTTP + USB：一个管 Agent 间通信，一个管工具连接。两者互补，缺一不可。

你已经在用 MCP 了吗？准备试试 A2A 做多 Agent 协作吗？评论区聊聊你的场景。

从零搭建 AI 开发环境：Terminal + MCP + Vibe Coding 全链路实战

Thu, 11 Jun 2026 08:30:00 +0800

上个月帮一个朋友从零搭建 AI 编程环境，花了三个小时把 Terminal、MCP、Vibe Coding 全串通。回头看，最难的不是单个工具的安装，而是让它们配合起来形成一条不卡顿的工作流。

这篇文章就是那次实战的整理。从裸机开始，每一步都有命令，每个坑都标出来。读完照着做，你也能在两小时内搭起一条完整的 AI 编程链路。

为什么你需要一条完整的链路

先说结论：工具碎片化是当前 AI 编程最大的效率杀手。

API key 在官网申请，MCP server 各自配置，终端工具和 IDE 各管一摊，文档分散在五六个不同站点。装完 Cursor 发现不会配 MCP，配好 MCP 发现 Claude Code 连不上，连上了又不知道怎么和工作流对接。

我看到的模式是三个层次：

层次	作用	对应工具
底层	终端环境	git, node, python, gh CLI
协议层	工具通信	MCP（Model Context Protocol）
工作方式	人机协作	Vibe Coding

不是选一个最好的工具，而是搭一条顺滑的链路。

打地基：终端环境准备

终端是 AI 编程工具的基础。Claude Code 是纯终端工具，Codex CLI 也在终端跑，MCP server 大部分是 Node 或 Python 进程。没有干净的终端环境，后面全白搭。

必装清单

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


# macOS
brew install git node python

# Ubuntu/Debian
sudo -S -p '' apt install -y git nodejs python3 python3-pip

# 包管理器（选一个）
curl -LsSf https://astral.sh/uv/install.sh | sh # Python（推荐）
npm install -g pnpm # Node

# GitHub CLI
brew install gh # macOS
sudo -S -p '' apt install gh # Ubuntu
gh auth login

Shell 提示符

装个 starship，路径 + git 分支 + 语言版本一目了然：

1
2


brew install starship
echo 'eval "$(starship init bash)"' >> ~/.bashrc # 或 ~/.zshrc

⚠️ 踩坑：PATH 混乱。uv 装的 Python 和系统 Python 冲突时，which python3 确认一下实际路径。建议把 ~/.local/bin 放在 PATH 最前面。

⚠️ 踩坑：Node 版本。部分 MCP server 要求 Node >= 18。node -v 检查，不够用 nvm install 18 升级。

AI 编程工具选型与安装

四句话定位：

工具	一句话定位	适合场景
Claude Code	终端原生，最强代码理解	深度重构、多文件联动
Cursor	IDE 集成，所见即所得	前端开发、日常补全
OpenCode	开源灵活，模型可选	定制需求、本地模型
Codex	OpenAI 生态，云端执行	快速原型、CI 集成

选型建议

你的情况	推荐主力
后端/系统开发	Claude Code
前端/全栈	Cursor + Claude Code 互补
想省钱/用本地模型	OpenCode
快速验证想法	Codex

安装实操

Claude Code（5 步跑通）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# 1. 安装
npm install -g @anthropic-ai/claude-code

# 2. 设置 API key
export ANTHROPIC_API_KEY=sk-ant-xxx...

# 3. 国内用户加中转（可选但推荐）
export ANTHROPIC_BASE_URL=https://your-proxy.example.com/anthropic

# 4. 进入项目目录启动
cd my-project
claude

# 5. 验证
claude "列出项目结构，告诉我这个项目用了什么技术栈"

Claude Code 启动后会自动扫描项目，理解代码结构。第一次运行建议先让它读一遍项目，建立上下文。

Cursor（3 步跑通）：

去 cursor.com 下载安装
打开后自动导入 VS Code 设置和插件
Settings → Models → 填入 API key

Cursor 的 Tab 补全是杀手级功能，打几个字母它就能预判你要写什么，整段代码一键接受。Cmd+K 做局部修改，Cmd+L 打开对话面板。

OpenCode（3 步跑通）：

1
2
3
4
5
6
7
8


# 1. Go 安装
go install github.com/opencode-ai/opencode@latest

# 2. 或直接下载二进制
curl -fsSL https://opencode.ai/install | bash

# 3. 配置模型（支持 OpenAI/Anthropic/本地模型）
opencode config set model anthropic/claude-sonnet-4

OpenCode 的优势是模型自由切换。用 OpenRouter 可以一次配置访问几十个模型，也可以连本地 Ollama 跑开源模型，完全离线。

Codex CLI（3 步跑通）：

1
2
3
4
5
6
7
8


# 1. 安装
npm install -g @openai/codex

# 2. 设置 key
export OPENAI_API_KEY=sk-xxx...

# 3. 运行
codex "给这个项目加单元测试"

Codex 的特点是云端沙箱执行。代码不在本地跑，而是 OpenAI 的安全环境里运行，适合处理不信任的代码或快速验证想法。

⚠️ 踩坑：国内网络。Claude Code 和 Codex 默认连海外端点。国内用需要配 API 中转，设置 ANTHROPIC_BASE_URL 或 OPENAI_BASE_URL 环境变量指向中转服务。中转服务国内有不少选择，选支持支付宝/微信的即可。

⚠️ 踩坑：API key 管理。不要把 key 硬编码在 .bashrc 里推到 GitHub。用 ~/.env 文件 + .gitignore，或者用系统 keychain。

MCP 协议：让 AI 工具长出手和脚

MCP（Model Context Protocol）是 Anthropic 提出的开放协议，让 AI 编程工具能调用外部能力。类比 USB-C：统一接口，不管什么设备都能插。

三个核心概念：

Server：能力提供者（文件读写、数据库查询、API 调用）
Client：AI 工具（Claude Code、Cursor 等）
Transport：通信方式（stdio 本地、SSE/Streamable HTTP 远程）

安装三个最实用的 MCP Server

1. filesystem（文件读写，必装）

1

npm install -g @modelcontextprotocol/server-filesystem

2. fetch（网络请求，必装）

1

uvx mcp-server-fetch

3. github（代码仓库操作）

1

npm install -g @modelcontextprotocol/server-github

配置方法

Claude Code 在项目根目录创建 .mcp.json：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


{
 "mcpServers": {
 "filesystem": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/project"],
 "env": {}
 },
 "fetch": {
 "command": "uvx",
 "args": ["mcp-server-fetch"]
 },
 "github": {
 "command": "npx",
 "args": ["-y", "@modelcontextprotocol/server-github"],
 "env": {
 "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_xxx"
 }
 }
 }
}

Cursor 在 Settings → MCP 里直接填同样的 JSON，或者放在 ~/.cursor/mcp.json 全局生效。

OpenCode 在项目根目录的 opencode.json 里配置，格式相同。

⚠️ 踩坑：stdio vs SSE。本地开发用 stdio（command + args），远程部署用 SSE（url）。不要混用。

⚠️ 踩坑：路径权限。filesystem server 的路径参数要写绝对路径，且确保运行用户有读写权限。

串联：从单个工具到完整工作流

这是重点。工具不是孤立的，串联起来才有效率。

完整工作流示例

假设要给一个 Node.js 项目加用户注册功能：

Step 1：需求分析

在 Claude Code 终端对话，描述清楚上下文：

1
2
3


我在做一个 Node.js + PostgreSQL 的 SaaS 项目，
ORM 用 Prisma，帮我实现用户注册，
要有邮箱验证，错误处理跟已有 middleware 风格一致。

Step 2：代码生成

Claude Code 通过 MCP filesystem server 读取项目结构，生成代码，通过 github server 直接创建分支和 commit。

Step 3：调试优化

多轮对话保持上下文，不切换工具。在同一个 session 里推进。

Step 4：代码审查

1
2
3
4
5


# 用 gh CLI 看 diff
gh pr diff

# 或让 Claude Code 自己 review
claude "review this PR for security issues and code quality"

Step 5：部署

1
2


gh pr merge --squash
gh release create v1.1.0

实战：30 分钟完成一个小项目

我上次用这个链路做了一个 URL 缩短服务，从零到部署大概 25 分钟：

Claude Code 终端描述需求：「用 FastAPI 做一个 URL 缩短服务，SQLite 存储，要有统计点击次数的功能」
Claude Code 通过 MCP filesystem 读取空目录，生成项目结构和所有代码文件
两轮对话修了 ORM 关系和错误处理
claude "写测试" 自动生成 pytest 测试，跑通
gh repo create && git push 上线

关键是整个过程没有切换工具。终端对话→代码生成→测试→部署，一条线到底。

心流保护

频繁切换工具是心流杀手。我的经验：

一个任务一个 session，不要在同一个 Claude Code 对话里跳话题
把项目上下文写成 CLAUDE.md，放在项目根目录，每次启动自动加载
小任务用 Cursor Tab 补全，大任务用 Claude Code，别反过来
关掉通知，手机静音，全屏终端模式。Vibe Coding 的效率来自心流不间断

CLAUDE.md 示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 项目背景
SaaS 项目，Node.js + PostgreSQL + Prisma

# 技术决策
- 认证用 JWT，不用 session
- 错误处理统一用 middleware/errorHandler.ts

# 代码规范
- TypeScript strict mode
- 测试用 vitest

进阶：打造你自己的 MCP Server

现有 server 覆盖不了所有需求。比如你想让 AI 直接查公司内部数据库、调内部 API、跑自定义脚本——就得自己写。

为什么不直接在对话里让 AI 生成 SQL？因为 MCP Server 是标准化的工具接口，任何支持 MCP 的客户端都能用。你在 Claude Code 里写的 server，Cursor 和 OpenCode 直接就能调，不用重复开发。

最小 MCP Server（Python，30 行）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


from mcp.server.fastmcp import FastMCP
 
mcp = FastMCP("my-tools")
 
@mcp.tool()
def query_database(sql: str) -> str:
 """执行 SQL 查询并返回结果"""
 import sqlite3
 conn = sqlite3.connect("myapp.db")
 result = conn.execute(sql).fetchall()
 conn.close()
 return str(result)
 
@mcp.tool()
def get_weather(city: str) -> str:
 """查询城市天气"""
 import urllib.request, json
 url = f"https://wttr.in/{city}?format=j1"
 resp = urllib.request.urlopen(url)
 data = json.loads(resp.read())
 return data["current_condition"][0]["weatherDesc"][0]["value"]
 
mcp.run()

@mcp.tool() 装饰器把普通 Python 函数变成 MCP 工具。函数的 docstring 会作为工具描述传给 AI，所以写清楚描述很重要。参数类型标注（sql: str）自动变成工具的参数 schema。

配置到 Claude Code：

1
2
3
4
5
6
7
8


{
 "mcpServers": {
 "my-tools": {
 "command": "uv",
 "args": ["run", "--with", "mcp", "python", "my_server.py"]
 }
 }
}

⚠️ 踩坑：SQL 注入。上面的 query_database 示例只适合本地开发。生产环境务必参数化查询，或者限制只读账号。

想把你的 MCP Server 发布给社区用？推到 npm 或 PyPI，然后在 mcp-json 里把包名和版本号写清楚。社区有人整理了 awesome-mcp-servers 列表，可以参考别人的写法。

常见问题与避坑

Q：Claude Code 和 Cursor 选哪个？

A：不冲突。Cursor 处理行级补全和小改动，Claude Code 处理模块重构和复杂任务。大多数深度用户两个都用。如果你只能选一个，先装 Claude Code——终端覆盖的场景更广。

Q：MCP 配置后不生效？

A：检查三件事：①JSON 格式是否合法（逗号、引号）②command 路径是否正确（which npx 确认）③重启 Claude Code / Cursor。还有一个常见原因是 args 里的包名写错了，比如把 @modelcontextprotocol/server-filesystem 写成旧版的 @anthropic-ai/mcp-filesystem，版本更新后包名会变。

Q：token 消耗太快？

A：四个办法：①用 CLAUDE.md 让 AI 理解项目上下文，不用每次重复解释 ②大文件用 .gitignore 排除，别让 AI 扫 node_modules ③Sonnet 做日常任务，Opus 只在复杂重构时用 ④Cursor 的 Tab 补全不计 API token，多用 Tab 少开对话。

Q：API key 怎么管？

A：统一放 ~/.env，.bashrc 里 source ~/.env。.gitignore 加上 .env。千万别推到 GitHub——我不止一次见过有人把 Anthropic key 推到公开仓库，几小时被刷掉几百美元。

Q：Vibe Coding 会让代码质量变差吗？

A：取决于你的使用方式。把 AI 当「有点强的初级开发者」来用：让它写初稿，你负责审查、提问题、要求改进。AI 生成的代码一样要 Code Review，只是速度快了很多。完全不看就提交才是灾难。

Q：遇到 Rate Limit 怎么办？

A：Anthropic 官方 API 的 RPM 限制在高强度使用时容易触发。解法：①用 API 中转服务，RPM 配额更宽松 ②复杂任务用 Opus（慢但准），简单任务用 Sonnet（快但可能需要多轮） ③任务描述越清楚，来回轮次越少，消耗越低。

Q：终端和 IDE 哪个更适合 Vibe Coding？

A：看你做什么。终端（Claude Code）适合后端、脚本、DevOps、跨文件重构——这些场景需要执行命令和批处理。IDE（Cursor）适合前端、UI 调试、小范围修改——所见即所得的优势大。我的习惯是终端为主力，IDE 做辅助。

推荐 MCP Server 列表：

Server	用途	安装
filesystem	文件读写	`@modelcontextprotocol/server-filesystem`
fetch	HTTP 请求	`uvx mcp-server-fetch`
github	仓库操作	`@modelcontextprotocol/server-github`
sqlite	数据库查询	`uvx mcp-server-sqlite`
brave-search	网页搜索	`@modelcontextprotocol/server-brave-search`

搭建一条完整的 AI 编程链路，核心是三层：终端打好底、MCP 通好讯、工作流串好节奏。工具链搭对了，Vibe Coding 的效率提升是实打实的。

再多说一句：不要追求「最完美的工具链」。先用 Claude Code + 三个 MCP Server 跑通一个真实项目，遇到瓶颈再加工具。工具是手段，代码才是目的。

剩下的，就是真正去写代码了。

作者：varkm

自己写一个 MCP Server：从协议到实战的完整指南

Mon, 08 Jun 2026 08:30:00 +0800

MCP Hub 上现成的 Server 有几百个，但真正落到自己手上——公司内部 API、私有数据源、定制化工具链——没有一个现成的能直接用。这篇文章带你用 Python FastMCP 3.x 从零写一个文件管理 MCP Server，跑通本地调试、远程部署的完整链路。

MCP 协议核心概念速览

三个角色

角色	职责	例子
Host	发起连接的 LLM 应用	Claude Desktop、Cursor、VS Code Copilot
Client	Host 内部与 Server 通信的组件	Claude 内置的 MCP Client
Server	提供工具、数据、提示词的服务	你写的那个

关系很简单：Host 包含 Client，Client 连接 Server。

三个核心能力

Tools：让 LLM 调用函数（计算、查数据库、操作文件）
Resources：让 LLM 读取数据（配置文件、数据库内容）
Prompts：预定义的提示词模板，复用对话模式

两种传输方式

方式	场景	协议
stdio	本地运行，Host 直接启动你的进程	JSON-RPC over stdin/stdout
Streamable HTTP	远程部署，Host 通过 HTTP 连接	HTTP POST + SSE

MCP ≠ Function Calling

这是最大的概念误区。Function Calling 是单个模型厂商的私有接口（比如 OpenAI 的 tool_use），而 MCP 是一个开放协议——任何 LLM、任何工具，只要遵循协议规范就能互通。你可以把它理解为「工具调用界的 USB 接口」。

实战：搭建文件管理 MCP Server

环境准备

1
2
3
4
5
6
7
8
9


# Python >= 3.10
python3 --version

# 创建虚拟环境
python3 -m venv mcp-env
source mcp-env/bin/activate

# 安装 FastMCP（当前最新 3.4.x，别装旧版）
pip install fastmcp

注意：网上大量教程还在用 FastMCP 2.x 的 API（@mcp.server.tool()、FastMCP.from_tools() 等），这些在 3.x 已经全部改了。如果你照抄旧代码，会直接报错。

完整代码

创建 file_server.py：

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104


import os
import json
from pathlib import Path
from fastmcp import FastMCP

mcp = FastMCP(name="FileManager")

@mcp.tool
def list_files(dir_path: str) -> str:
 """列出指定目录下的文件和子目录。
 
 Args:
 dir_path: 要列出的目录路径
 """
 path = Path(dir_path).resolve()
 if not path.exists():
 return json.dumps({"error": f"路径不存在: {dir_path}"}, ensure_ascii=False)
 if not path.is_dir():
 return json.dumps({"error": f"不是目录: {dir_path}"}, ensure_ascii=False)
 
 entries = []
 for item in sorted(path.iterdir()):
 entry = {
 "name": item.name,
 "type": "dir" if item.is_dir() else "file",
 "size": item.stat().st_size if item.is_file() else None,
 }
 entries.append(entry)
 
 return json.dumps({
 "path": str(path),
 "count": len(entries),
 "entries": entries,
 }, ensure_ascii=False, indent=2)


@mcp.tool
def read_file(file_path: str) -> str:
 """读取文件内容（文本文件，限制 10MB）。
 
 Args:
 file_path: 文件路径
 """
 path = Path(file_path).resolve()
 if not path.exists():
 return json.dumps({"error": f"文件不存在: {file_path}"}, ensure_ascii=False)
 if not path.is_file():
 return json.dumps({"error": f"不是文件: {file_path}"}, ensure_ascii=False)
 if path.stat().st_size > 10 * 1024 * 1024:
 return json.dumps({"error": "文件超过 10MB 限制"}, ensure_ascii=False)
 
 try:
 content = path.read_text(encoding="utf-8")
 return json.dumps({
 "path": str(path),
 "size": path.stat().st_size,
 "content": content,
 }, ensure_ascii=False)
 except UnicodeDecodeError:
 return json.dumps({"error": "不是文本文件或编码不支持"}, ensure_ascii=False)


@mcp.tool
def search_files(pattern: str, directory: str = ".") -> str:
 """在指定目录下按文件名模式搜索文件。
 
 Args:
 pattern: 搜索模式，支持通配符（如 *.py、test_*）
 directory: 搜索的根目录，默认为当前目录
 """
 path = Path(directory).resolve()
 if not path.exists():
 return json.dumps({"error": f"目录不存在: {directory}"}, ensure_ascii=False)
 
 matches = list(path.glob(f"**/{pattern}"))
 results = [
 {
 "path": str(m.relative_to(path)),
 "type": "dir" if m.is_dir() else "file",
 "size": m.stat().st_size if m.is_file() else None,
 }
 for m in sorted(matches)[:100] # 限制最多 100 条
 ]
 
 return json.dumps({
 "pattern": pattern,
 "directory": str(path),
 "count": len(results),
 "results": results,
 }, ensure_ascii=False, indent=2)


@mcp.resource("resource://cwd")
def get_cwd() -> str:
 """返回当前工作目录信息。"""
 return json.dumps({
 "cwd": os.getcwd(),
 "user": os.environ.get("USER", "unknown"),
 "home": str(Path.home()),
 }, ensure_ascii=False, indent=2)


if __name__ == "__main__":
 mcp.run()

代码要点

@mcp.tool 装饰器把普通函数变成 MCP Tool，函数名就是工具名，docstring 自动变成工具描述
参数用 Python type hints（str、int），FastMCP 自动生成 JSON Schema
@mcp.resource("resource://cwd") 暴露一个只读数据源，Client 可以按 URI 请求
所有返回值统一用 JSON 字符串，LLM 解析起来更可靠
路径用 Path.resolve() 处理，避免相对路径歧义

测试运行

1
2
3
4
5


# 启动 Server（stdio 模式，等待 JSON-RPC 输入）
python file_server.py

# 用 MCP Inspector 调试（需要 Node.js）
npx @modelcontextprotocol/inspector python file_server.py

MCP Inspector 会打开一个 Web 界面，你可以可视化地调用每个 Tool、查看 Schema、检查返回值。

集成到 Claude Desktop

编辑 ~/Library/Application Support/Claude/claude_desktop_config.json（macOS）或对应路径：

1
2
3
4
5
6
7
8
9


{
 "mcpServers": {
 "file-manager": {
 "command": "python",
 "args": ["/绝对路径/file_server.py"],
 "cwd": "/你的工作目录"
 }
 }
}

重启 Claude Desktop，你的文件管理工具就出现在工具列表里了。

从本地到远程：部署你的 MCP Server

stdio → Streamable HTTP

本地开发用 stdio（简单直接），生产环境需要暴露 HTTP 接口。FastMCP 3.x 内置支持：

1
2
3


# 只改最后一行
if __name__ == "__main__":
 mcp.run(transport="streamable-http", host="0.0.0.0", port=8080)

或者用命令行直接启动：

1

fastmcp run file_server.py --transport streamable-http --port 8080

认证

远程部署必须加认证。MCP 规范推荐 OAuth 2.1（2025 年 6 月 spec 确定）。不要用裸 API Key——明文传输不安全。

FastMCP 3.x 支持通过中间件集成 OAuth：

1
2
3
4


from fastmcp import FastMCP

mcp = FastMCP(name="FileManager", auth_config=...)
# 具体配置参见 FastMCP 官方文档的 Authentication 章节

Docker 容器化

1
2
3
4
5
6
7
8
9


FROM python:3.12-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY file_server.py .

EXPOSE 8080
CMD ["fastmcp", "run", "file_server.py", "--transport", "streamable-http", "--host", "0.0.0.0", "--port", "8080"]

1
2


docker build -t file-mcp-server .
docker run -p 8080:8080 file-mcp-server

踩坑实录：我开发 MCP Server 时遇到的 5 个坑

坑 1：FastMCP 版本陷阱

FastMCP 从 1.x → 2.x → 3.x 快速迭代，网上 90% 的教程用的都是过时 API。典型的坑：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# ❌ FastMCP 2.x 写法（3.x 报错）
from fastmcp import FastMCP, Context

@mcp.tool()
async def my_tool(ctx: Context) -> str:
 ...

# ✅ FastMCP 3.x 写法
@mcp.tool
def my_tool() -> str:
 ...

教训：写代码前先 pip show fastmcp 确认版本，再去查对应版本文档。

坑 2：把 MCP 当 Function Calling 写

MCP 不只是「换个方式调用函数」。Function Calling 是单次请求-响应，MCP 是持久化的能力暴露——你的 Server 一直活着，Client 随时可以调用任何 Tool、读取任何 Resource。设计思路应该是「我这个 Server 能提供什么能力」，而不是「我这个函数怎么被调用」。

坑 3：Schema 不精确，LLM 瞎调

参数的 type hints 和 docstring 直接决定 LLM 理解你工具的准确度。下面是反面教材：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


# ❌ LLM 不知道 limit 是什么范围、offset 从 0 还是 1 开始
def query(page, size):
 """查询数据"""
 ...

# ✅ 类型、范围、含义都写清楚
def query_users(
 page: int = 1, 
 size: int = 20,
) -> str:
 """分页查询用户列表。

 Args:
 page: 页码，从 1 开始
 size: 每页条数，最大 100
 """
 ...

坑 4：调试困难

MCP 用 JSON-RPC over stdio，不像 REST API 可以直接 curl 测试。你没法手动构造 JSON-RPC 消息发到 stdin。

解决方案：用 MCP Inspector（npx @modelcontextprotocol/inspector），它提供完整的可视化调试界面。或者用 FastMCP Client 写测试脚本：

1
2
3
4
5
6
7
8
9


from fastmcp import Client

async def test():
 async with Client("file_server.py") as client:
 result = await client.call_tool("list_files", {"dir_path": "/tmp"})
 print(result)

import asyncio
asyncio.run(test())

坑 5：Node 版本不兼容

如果你用 TypeScript SDK 开发 MCP Server，需要 Node >= 18。低版本会出现诡异的 ERR_MODULE_NOT_FOUND 或 SyntaxError。如果你用 npx @modelcontextprotocol/inspector 调试 Python Server，也需要确保 Node 版本够新。

1
2
3
4
5
6


# 检查版本
node --version # 需要 >= 18

# 推荐用 nvm 管理
nvm install 20
nvm use 20

总结：什么时候自己写 vs 用现成的

场景	建议
标准 API（GitHub、Slack、数据库）	用现成 Server（MCP Hub 上找）
内部工具、私有 API、定制逻辑	自己写
需要特定认证流程	自己写
简单的文件/数据操作	自己写（几十行代码搞定）

MCP Server 开发本身不难——FastMCP 一个装饰器搞定工具定义，type hints 自动生成 Schema。难的是理解协议设计理念（能力暴露 vs 函数调用）和避开版本陷阱。

推荐资源：

MCP 官方文档 — 协议规范和概念
FastMCP 官方文档 — 最新 API 参考
MCP Hub — 现成 Server 搜索

下一篇我会聊 MCP + Cursor 的进阶玩法——怎么让你的 MCP Server 真正融入日常开发工作流。

MCP 协议入门：让 AI 工具连接一切的万能接口

Sun, 07 Jun 2026 08:30:00 +0800

MCP 协议入门：让 AI 工具连接一切的万能接口

你用 Claude 查数据库、用 Cursor 调 API、用 VS Code 写代码——每个 AI 工具连外部能力的方式都不一样，开发者疲于适配。MCP 结束了这一切。

先说结论

MCP（Model Context Protocol）就是 AI 世界的"万能转接头"。

什么意思？以前你给 Claude 写个插件，只有 Claude 能用。给 Cursor 写个扩展，只有 Cursor 能用。现在你写一个 MCP Server，所有支持 MCP 的工具——Claude Desktop、ChatGPT、Cursor、VS Code Copilot、Windsurf——都能直接调用。

写一次，到处能用。这就是 MCP 的核心价值。

MCP 到底是什么

一句话定义：AI 应用连接外部系统的开放协议。

类比你就懂了。USB-C 统一了充电口——以前出门带五根线，现在一根搞定。MCP 做的是同样的事：统一 AI 调用外部工具的接口。

以前 Claude 想读文件，得用 Claude 自己的插件格式。Cursor 想查数据库，得用 Cursor 自己的扩展 API。每个 AI 工具都搞一套，开发者写一次适配要重复 N 遍。MCP 把这些全部标准化了。

谁做的？Anthropic（Claude 背后的公司），2024 年 11 月开源推出。不是闭源产品，是真正的开放协议——规范仓库 8300+ Star，官方 Server 参考实现仓库 86000+ Star，社区贡献活跃。

这里有个容易搞混的点：MCP 不是 Function Calling 的替代品。Function Calling 是"模型能调用函数"这个能力，MCP 是在它之上的一层标准化协议——定义了工具怎么描述、怎么发现、怎么调用。类比：Function Calling 是发动机，MCP 是传动轴。不是替代关系，是上下层关系。

协议的治理也很规范。MCP 有完整的 SEP（Specification Enhancement Proposal）流程，类似 Python 的 PEP。社区通过 SEP 提案来讨论和推进协议演进，目前已有 30+ 个 SEP。这意味着 MCP 不是一家公司说了算，而是有社区共识机制的开放标准。

为什么 2026 年必须懂 MCP

数据说话，不讲故事。

npm 包月下载量 1.55 亿次。 这是 TypeScript SDK 的数据，Python SDK 也已经迭代到 1.27.2 版本。一个协议相关的 SDK 能有这个量级，说明生态已经非常成熟。

协议本身也在快速演进：

时间	版本	关键更新
2025-03	2025-03-26	首个正式版本发布
2025-06	2025-06-18	tool annotations、structured output、elicitation
2025-09	Registry 上线	可搜索可发现的 Server 市场
2025-11	2025-11-25	最新稳定版
2026-05	2026-07-28-RC	下一个大版本候选，含 Tasks、MCP Apps

支持 MCP 的工具列表已经覆盖所有主流平台：Claude Desktop、ChatGPT、VS Code Copilot、Cursor、Windsurf、Zed、Replit、Continue、通义灵码……

注意 ChatGPT 和 VS Code 也在列表里。MCP 不是 Claude 专属，它正在成为全行业的事实标准。Anthropic 把它开源出来，OpenAI 接了，微软接了——这就不是一家公司的生态了，而是整个 AI 行业的基础设施。

一句话总结：2026 年不懂 MCP 的开发者，就像 2015 年不懂 REST API 的后端开发者。不是学不学的问题，是早晚要学的问题。

MCP 怎么工作：三层核心概念

别被架构图吓到，核心就三个角色，记住它们就行。

Host（宿主）：你用的 AI 应用。Claude Desktop、Cursor、VS Code，这些就是 Host。它负责管理所有 MCP 连接，决定什么时候调用什么工具。

Client（客户端）：Host 内部自动创建的通信组件。每连接一个 Server，Host 就自动创建一个对应的 Client。你作为用户不需要手动配置这个——它是透明的。

Server（服务端）：提供具体能力的独立程序。连接数据库、读写文件、搜索网页、调用第三方 API——都是 Server 的事。Server 可以跑在本地（stdio 传输），也可以跑在远程（Streamable HTTP 传输）。

一个简化示意：

1
2
3
4


Claude Desktop (Host)
 ├── Client 1 ←→ Filesystem Server（读写本地文件）
 ├── Client 2 ←→ Database Server（查数据库）
 └── Client 3 ←→ Web Search Server（搜索网页）

Host 想读文件？问 Client 1。想查数据库？问 Client 2。整个过程对用户来说就是正常聊天——AI 自己决定调哪个工具。

通信协议用的是 JSON-RPC 2.0，非常轻量。本地场景用 stdio（标准输入输出），远程场景用 Streamable HTTP。如果你熟悉 LSP（Language Server Protocol），会觉得这个架构很眼熟——确实，MCP 的设计灵感就来自 LSP。

Server 暴露三种能力，官方叫 Primitives（原语）：

Tools：可调用的函数。这是最常用的。 比如执行 SQL 查询、创建文件、发送邮件。可以理解为"动作"。每次 AI 说"我来帮你执行 XXX"，背后大概率就是调了一个 Tool。

Resources：可读取的数据或文件。比如数据库表结构、配置文件内容、API 文档。可以理解为"信息"。和 Tool 的区别是 Resource 是只读的，AI 只是"看"一眼，不会改变什么。

Prompts：预定义的提示模板。比如"用 XX 风格写代码"的标准提示词，或者"按 XX 格式输出报告"的模板。可以理解为"指令模板"。

实际开发中 90% 的场景只用 Tools。Resources 和 Prompts 是锦上添花，不用急着学。

亲测演示：5 分钟跑通你的第一个 MCP

不用写代码。现成的 Server 拿来就能用。这是 MCP 的设计哲学：先用起来，再理解原理。

以 Claude Desktop + 官方文件系统 Server 为例。

Step 1：安装 Claude Desktop

去 claude.ai/download 下载安装。macOS 和 Windows 都支持。

Step 2：确保有 Node.js

终端执行 node --version，能看到版本号就行。没有就去 nodejs.org 装 LTS 版。很多官方 Server 都是基于 Node.js 的。

Step 3：编辑配置文件

打开 Claude Desktop → 点击顶部菜单 Claude → Settings → Developer → Edit Config。

这会打开一个 JSON 配置文件，写入以下内容：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


{
 "mcpServers": {
 "filesystem": {
 "command": "npx",
 "args": [
 "-y",
 "@modelcontextprotocol/server-filesystem",
 "/Users/你的用户名/Desktop",
 "/Users/你的用户名/Downloads"
 ]
 }
 }
}

把路径换成你自己的实际路径。Windows 用户把 /Users/ 改成 C:\\Users\\。

这个配置告诉 Claude Desktop：启动时自动运行 filesystem 这个 Server，并授权它访问指定的目录。

Step 4：重启 Claude Desktop，开始对话

重启后在聊天框里试试这些：

“帮我看看桌面上有哪些文件”——Claude 会弹出权限请求，你确认后它就能读取文件列表了。

“把 Downloads 里最大的 5 个文件列出来”——它会扫描目录并排序。

“帮我创建一个 notes.txt，写上今天的待办事项”——它真的能创建文件。

全程不用写一行代码。现成的 Server 拿来就跑。

如果你用的是 Cursor，流程更简单：Settings → MCP → Add New Server → 粘贴配置 → 重启。VS Code Copilot 也类似，在 settings.json 里配置 mcp 字段即可。

想试试更多 Server？去官方 GitHub 仓库 modelcontextprotocol/servers，里面有几十个开箱即用的 Server——数据库、Git、Brave Search、Slack、Google Drive……复制配置就能用。

MCP vs Function Calling vs Agent：别再搞混了

这三个概念经常被混在一起说，其实完全不在一个层级。

概念	是什么	解决什么问题	类比
Function Calling	模型调用函数的能力	让 LLM 能触发动作	电灯开关
MCP	标准化的工具发现和调用协议	让所有工具对所有平台可用	家里的电路系统
Agent	利用工具链自主完成复杂任务的应用	替人干活	你本人

打个比方：Function Calling 是开关——让 AI “能"调用工具。MCP 是电路系统——规定所有电器用统一的接口。Agent 是你——决定开哪个灯、用哪个电器。

它们是三层关系，不是三选一。不存在"用 MCP 就不用 Function Calling"这种说法——Agent 内部用 Function Calling 来调工具，而这些工具通过 MCP 来暴露和发现。

写在最后

MCP 生态正在爆发式增长。官方 Registry 已上线，像 npm 一样可以搜索和安装 Server。社区贡献的 Server 数量每周都在增加，主流开发工具全面接入。

如果你还在为每个 AI 工具单独写适配代码——停下来，试试 MCP。

下一篇我会教你从零写一个自己的 MCP Server。从"用工具"到"造工具”。

关注 varkm，持续获取 AI 实战内容。