从 API、SDK 到 MCP：大模型时代的语义协议演进

2026年6月20日·0xPM

AIAgentMCP

系列AI 初探3 / 3

1AI初探：从传统开发者视角理解 AI
2Agent 到底是什么？智能体八问
3从 API、SDK 到 MCP：大模型时代的语义协议演进
查看系列 →

前言

刚接触 MCP（Model Context Protocol） 时，作为产品经理和前开发者，我最大的困惑大概率是这几个问题：

MCP 到底是什么？
它和API、SDK 有什么区别？
什么是 MCP Client？什么又是 MCP Server？
最现实的问题——我的产品现在到底需不需要上 MCP？

撕掉所有复杂的协议规范和技术黑话，本文将从技术演进视角，层层剥离概念，带你理清MCP的底层逻辑。

一、从传统世界看起，API 和 SDK 解决了什么？

在探讨 AI 新世界之前，我们先回到最熟悉的互联网研发底层底座。

一个业务系统（比如支付系统 AgentPay）要对外开放能力，通常有两步演进：

API（Application Programming Interface）：核心能力的“裸露”
- 本质： 它是系统暴露出的底层业务网络接口（如 POST /api/payment/create）。
- 受众： 跨系统的网络交互。它规定了 URL、Header 鉴权和 Body 传参格式。
SDK（Software Development Kit）：研发体验的“包装”
- 本质： 它是对 API 的代码级封装。
- 受众： 人类程序员。程序员不想每次都手写复杂的 HTTP 请求，所以你把 API 封装成了工具包，让他们直接调用 client.createPayment()。

【传统研发链路】 ──> 人类程序员 ──> 调用 SDK ──> 触发 API ──> 执行底层业务

二、为什么有了 API/SDK，AI 时代还要 MCP？

既然传统世界的底座已经如此完善，为什么 AI Agent 出现后，这套机制玩不转了？

我们来看一段最现实的场景对比：

假设你的项目（如 AgentPay）有一个用于创建支付的接口：POST /api/payment/create

人类程序员： 看完你的 API 文档，清晰地知道 URL 是什么、Header 怎么鉴权、Body 传什么 JSON 字段、返回的 status 是什么含义。因为人类具备结构化阅读和强逻辑对接能力。
AI 大模型： 哪怕你把文档喂给它，Claude 或 GPT 也无法百分之百保证每次拼凑出的 HTTP 请求都是绝对精准、格式无误的。

传统的 API 是给机器提供，让人类程序员读的代码协议。AI 时代，需要一种全新的让 AI 能直接读懂、并直接操作的“语义协议”。

这就是MCP的本质，把“给人类程序员看的 API”，翻译成“给 AI 听的 Tool 声明”。

// 经过 MCP 包装后的标准 Tool 声明（AI 极其擅长阅读这种格式）
{
  "name": "create_payment",
  "description": "Create a secure payment order with specific fiat or crypto amount.",
  "input_schema": {
    "type": "object",
    "properties": {
      "amount": { "type": "number", "description": "The amount to charge" }
    }
  }
}

AI 读完这段 JSON 声明瞬间心领神会，它就能像人类程序员调用 SDK 一样，在最恰当的时机，自主、标准地调用外部能力。

三、解构 MCP 架构，什么是 Client 与 Server？

理解了为什么需要 MCP，我们再来看看它是如何在架构中落地的。很多文章会说：“MCP 是 AI 时代的 USB-C 接口。”

在 MCP 出现之前，生态集成是一场灾难。5 个 AI 客户端要接入 10 个 SaaS 工具，需要做 5 * 10 = 50 次定制化集成。而有了 MCP 这一统一标准后，网状结构瞬间变成了“插拔式”的星状结构，只需要 5 + 10 = 15 个标准组件。

在这个标准体系中，存在两个最核心的角色：

┌────────────────────────────────────────────────────────┐
│                        MCP 生态                         │
├────────────────────────────┬───────────────────────────┤
│ MCP Client (前厅服务员/发起方)│ MCP Server (后厨大厨/能力方)│
└────────────────────────────┴───────────────────────────┘

1. MCP Client（需求发起者）

Client 是连接大模型、并负责发起外部请求的主体客户端。

常见代表： Claude Desktop、Cursor、Windsurf、Cherry Studio、自定义的 AI Agent。
它的职责： 面对用户/AI，发现工具 > 编排逻辑 > 调度工具 > 接收结果 > 喂回给 AI。

2. MCP Server（能力供给者）

Server 是具体功能、数据或业务逻辑的承载端。

常见代表： GitHub MCP、Notion MCP、Stripe MCP、AgentPay MCP。
它的职责： 声明自身能力 > 接收 Client 调度 > 执行具体动作 > 返回结构化结果。

💡 黄金分水岭决策：

做 MCP Server： 为了让别人家的 AI，顺畅地消费你的能力。

做 MCP Client： 为了让自己家的 AI，顺畅地调用别人的能力。

四、深入微观，MCP 内部的“三驾马车”与代码结构

作为一个产品经理，你不需要手写代码，但你必须理解 MCP 能够向 AI 交付哪些维度的能力。完整的 MCP 协议规范包含了相互补充的三大核心：

1. Tools（执行动作）

定位： 改变外部世界状态的“写”操作（会产生副作用）。
示例： create_wallet、refund_payment。
结果： 导致数据库变更、上链发交易、发送真实邮件等。

2. Resources（提供数据）

定位： 供 AI 静态读取、补充上下文的“读”操作（只读，无副作用）。
示例： 类似自定义协议的 URI，如 payment://order_123 或 wallet://balance。
结果： AI 可以读取这些原始日志或上下文，但无法通过它改变任何系统状态。

3. Prompts（提示词/工作流模板）

定位： 封装了特定业务专家的标准操作流程（SOP）。
示例： generate_growth_report（生成增长报告模板）。
逻辑： 触发后，Server 会把一段预设好、带参数的优质提示词模板丢给 AI，让 AI 自己在前端进行推理和输出，Server 本身并不执行任何计算逻辑。

🛠️ 现实主义哲学：MCP Server 内部复杂吗？

不要被这三大能力吓退。在现实的生产环境里，90% 的 MCP Server 都只有 Tool。

从代码结构上看，MCP Server 并不是什么高深莫测的 AI 框架，它只是一个 AI 适配层（AI Adapter）。它不生产能力，只是把 AI 丢过来的 Tool 意图，映射到你现有的 API 或 Service 上：

agentpay-mcp/
│
├── src/
│   ├── index.ts              # 入口：启动 MCP 服务，注册工具
│   │
│   ├── tools/                # 【MCP 语义层】声明 Tool 并解析 AI 输入
│   │   ├── createPayment.ts
│   │   ├── getPayment.ts
│   │   └── getBalance.ts
│   │
│   ├── services/             # 【业务胶水层】处理 MCP 与内部系统的逻辑桥接
│   │   └── paymentService.ts
│   │
│   └── api/                  # 【底座通信层】真正去请求你现有的后端 API
│       └── agentpayApi.ts

五、终局演进全景图：

全景图

API 是发动机； SDK 是给人类程序员量身定制的方向盘； MCP 是给 AI 驾驶员量身定制的方向盘。

先造好发动机，再配好常规方向盘。当外部 AI 流量滚滚而来时，及时奉上 MCP Server 这套 AI 专属方向盘。 这才是最符合商业增长与技术演进的最佳产品路径。

加载中…

前言