API vs MCP：了解从开发者工具到 AI 代理的转变

Source: Dev.to

API 的优化目标

API 是预先定义好的契约。开发者阅读文档，了解端点，然后编写调用它们的代码。

典型的 API 驱动流程如下：

一切都是显式的。开发者已经知道该调用什么、何时调用。智能体存在于应用逻辑中，而不是 API 本身。

API 假设调用者已经理解系统。

为什么 API 在 AI 代理上表现不佳

现在设想调用者不是开发者，而是一个 AI 代理。

代理并不会自然知道：

• 哪些端点存在
• 哪些参数是必需的
• 应该先调用哪个系统

你可以把这些知识硬编码到提示词或胶水代码中，但这种做法很快就会变得脆弱。

• 每新增一次集成都需要自定义逻辑
• 每一次 API 变更都可能导致代理失效
• 每个工作流必须事先定义好

这就是 MCP 试图填补的空白。

MCP 能带来什么

MCP 代表 Model Context Protocol（模型上下文协议）。

MCP 不再直接暴露原始端点，而是以结构化、机器可读的方式暴露能力。AI 模型可以询问：

• 有哪些工具可用？
• 它们需要什么输入？
• 我会得到什么输出？

关键区别很简单。

• API 告诉你 如何 调用某个功能。
• MCP 告诉模型 可以 做什么。

这让 AI 系统能够对工具进行推理，而不是遵循僵硬的指令。

实际案例

假设你正在构建一个 AI 旅行助理。用户说：

我想下周出行，但要避免坏天气。

使用 API

工作流由开发者预先定义。

User Request
   ↓
Hardcoded Logic
   ↓
Weather API
   ↓
Flight API
   ↓
Hotel API
   ↓
Response

AI 只是在执行脚本。以后想加入新服务就必须重写整个流程。

使用 MCP

MCP 服务器公开的工具包括：

• 搜索航班
• 预订酒店
• 查询天气
• 创建日历事件

AI 可以动态决定调用顺序。

User Request
   ↓
AI Reasoning
   ↓
Tool Discovery
   ↓
Check Weather
   ↓
Search Flights
   ↓
Suggest Hotels
   ↓
Response

没有任何硬编码。AI 根据意图和上下文自行选择路径。

MCP 为什么重要

• API 假设确定性。
• AI 最擅长探索和决策。

MCP 充当 AI 推理与真实系统之间的桥梁。它 不 替代 API；而是让 API 能被 AI 使用。

把 API 想成构件块。
把 MCP 想成为机器编写的使用说明。

何时使用何种方式

适合使用 API 的场景

• 需要性能和可预测性
• 工作流固定不变
• 人类掌控业务逻辑

适合使用 MCP 的场景

• 正在构建 AI 代理
• 工作流需要动态适配
• 工具经常变更

结语

这不是 API 对抗 MCP，而是 API 与 MCP 的协同工作。

API 仍是基础设施。MCP 为 AI 提供了一层，使其能够智能地利用这层基础。

随着 AI 代理的普及，理解两者的区别将变得重要——不是因为 MCP 时髦，而是因为它符合 AI 的实际工作方式。