MCP vs REST API：AI Agent 真正需要什么？

当 AI Agent 需要调用外部服务时，开发者面临一个核心问题：是继续沿用传统的 REST API，还是转向 MCP（Model Context Protocol）？一位技术 UP 主在视频中通过代码演示和类比分析，给出了清晰的答案：MCP 不替代 REST，而是让 AI 自己发现和调用服务的那一层。

一句话理解本质区别

视频中给出了一行精炼对比：REST API 是程序员编写的代码与某个服务对话的方式；MCP 是让 AI 模型自行发现并使用服务的方式。

这个区别看似简单，但背后的含义很深。REST 时代，人类开发者需要阅读文档、理解接口、编写调用代码。而 MCP 时代，AI 模型可以直接询问服务器“你能做什么”，然后根据返回的工具描述自动决定调用哪个接口。

正如视频中的餐厅类比：REST 就像你必须提前知道菜单、按编号点菜的餐厅；MCP 则像一位服务员，递给 AI 一份带有描述的菜单，AI 根据需求自主选择。UP 主将 MCP 描述为“AI 与 REST API 之间的通信通道”，这个定位相当准确。

MCP 的工作流程拆解

视频用多张流程图详细展示了 MCP 的调用链路，核心角色包括：

AI 客户端（如 LLM） 接收用户 query，通过 MCP 协议与 MCP Server 通信。MCP Server 内部包含几个关键模块——工具注册表（Tool Registry）、上下文分析（Context Analysis）、工具 Schema 暴露、以及安全代理层（Secure Proxy Layer）。

工具调用链路 是这样的：AI 向 MCP Server 询问可用工具，Server 返回工具名称、描述和参数 Schema，AI 根据这些信息判断该调用哪个工具，然后通过 MCP Server 间接调用底层的 REST API，最终将结果返回给用户。

视频中用一个具体例子说明了这个流程：AI 识别到“查询员工基本信息”这个工具，根据其描述中的 employee id 参数发起调用，MCP Server 将请求转发给对应的 REST API 方法，拿到数据后回传给 AI，AI 再展示给用户。

工具 Schema（Tool Schema） 是 MCP 工具注册表中的核心数据结构，通常以 JSON Schema 格式描述一个工具的名称、用途说明（description）和输入参数。例如天气工具的 Schema 会声明 city 为必填字符串参数。AI 模型并不执行工具本身，而是读取这份 Schema 后推理出「用户问 Lucknow 是否需要带伞」应映射到 city=Lucknow 的调用。Schema 的质量直接决定了 AI 的调用准确率——描述越清晰、参数约束越明确，模型误调用和参数错填的概率就越低。这也是 MCP Server 开发者最需要打磨的部分。

安全上下文如何传递

在企业级场景中，API 调用往往涉及租户隔离和权限控制。视频展示了一个关键细节：REST API 的 Controller 层会从请求头中提取 tenant ID、user ID、department ID 等安全上下文信息。

Agent 在执行任务时，需要将这些安全上下文一并传递给底层服务。视频中的代码演示显示了一个 agent.ask() 方法，它接收 prompt、advisor 和 question，同时构建了 filter expression 来确保安全策略生效。

AI 不能直接访问 REST API，而是必须通过 MCP Server 的安全代理层。UP 主强调：“直接我们无法将 REST API 的访问权限交给 AI”——这句话点出了 MCP 在安全层面的核心价值。

安全代理层（Secure Proxy Layer） 是 MCP Server 内部隔离 AI 与后端服务的中间组件。AI 模型只持有与 MCP Server 通信的凭证，看不到也不持有底层 REST API 的 token 或数据库地址。当请求经过代理层时，它会校验调用方身份、注入或透传租户与用户上下文，再向下游 REST API 发起请求。这种设计的价值在于：即便模型被提示注入攻击诱导去调用未授权的工具，代理层仍可基于策略拒绝，从而把「AI 不可信」这一前提纳入架构假设，而不是依赖模型自觉遵守权限边界。

真实场景：天气查询与任务创建

视频用两个贴近日常的场景说明了 MCP 的工作方式：

天气查询场景：AI 先询问 Server 有哪些工具，Server 返回工具列表（名称、描述、参数 Schema），用户问“Lucknow 需要带伞吗”，AI 判断应该调用天气工具，传入 city=Lucknow，返回“晴天，30°C”，AI 回复“不需要带伞”。整个过程中，没有任何硬编码的判断逻辑——AI 完全基于工具描述自主决策。

任务创建场景：用户说“提醒我买牛奶”，AI 调用 create_task 工具，自动填入 title=买牛奶和 due date。对比 REST API 的方式，开发者需要显式调用并传入结构化参数；而 MCP 方式下，用户只需自然语言表达，AI 负责完成参数映射。

这两个例子展示的是同一个核心能力：AI 从工具描述中理解用途，在运行时自主决定调用什么。

逐项对比：开发者 vs AI，谁来决定

视频给出了一组清晰的对比维度：

• 谁来写调用代码：REST 由开发者编写；MCP 由 AI 模型和 Agent 在运行时决定
• 如何发现能力：REST 需要阅读 API 文档和 OpenAPI 规范；MCP 直接向 Server 询问工具列表
• 调用者：REST 由程序员控制；MCP 由 AI 模型在运行时选择
• 接口一致性：每个 REST API 的错误处理、分页方式各不相同；MCP 提供统一的 Server 接口
• 状态管理：MCP 支持会话保持和进度更新，因为 AI 与 MCP Server 之间维持了长连接
• 传输方式：REST 基于 HTTP；MCP 支持 stdio（本地）和 HTTP（远程）

这些差异指向一个关键结论：MCP 为 AI 提供了标准化、自描述的服务发现机制，而 REST 是为人类开发者设计的。

它们如何协同工作

视频反复强调一个观点：MCP 不替代 REST API。 大多数 MCP Server 实际上是现有 REST API 的轻量封装（thin wrapper）。

典型架构是：用户发出自然语言请求 → AI 连接 MCP Server → MCP Server 将请求翻译为 REST 调用 → 底层服务（如 GitHub API）处理并返回结果。AI 与 MCP 通信，MCP 与 REST 通信，各司其职。

thin wrapper（轻量封装） 指的是 MCP Server 自身不承载业务逻辑，只做协议转换与路由。它把 MCP 的工具调用请求翻译成对应的 REST 端点调用，再把 HTTP 响应包装成 MCP 的结果格式返回。这意味着企业已有的鉴权、限流、审计、监控等 REST 侧能力可以被完整复用，无需在 MCP 层重复实现。代价是 MCP Server 必须随 REST API 的变更同步维护工具 Schema，否则会出现 AI 按旧参数调用新接口的失配问题，因此版本对齐是这类封装架构的长期运维重点。

何时用哪个？

视频给出的选择建议很务实：

• 用 REST：Web 应用、移动应用、服务间通信
• 用 MCP：当你希望 AI 助手或 Agent 使用你的服务或数据时
• 两者都用：已有 REST API，想接入 AI——在 REST 之上构建 MCP Server 即可

核心结论

回到视频标题的问题——AI Agent 真正需要什么？答案是：AI 需要一种能自主发现、理解并调用服务的标准化协议。REST API 是服务能力的基石，MCP 是让 AI 触达这些基石的桥梁。两者是分层关系，而非替代关系。对于正在构建 AI Agent 应用的开发者来说，理解这一点至关重要——你不需要推倒现有的 REST API 架构，只需要在上面加一层 MCP Server，就能让 AI 用自然语言驱动你的服务。