发布 2026-10-14 · 更新 2026-10-25

为什么 Agent 工作流里 MCP 比 REST 调用更好

REST 调用只能用一次。MCP 服务器会告诉 Agent 有什么、参数是什么、返回什么 —— 于是它能自己规划，而不用你把每个端点教一遍。什么时候用哪个。

本页目录

问题

第一篇教程展示了两条路：脚本里的 REST 调用，和 MCP 服务器。两条都能用。那为什么还要选？

差别不在能力，在「谁知道有什么存在」。

REST 调用，是一份你要随身带的契约

写一个 REST 调用时，端点的知识活在你的代码里 —— 或者在你给 Agent 的提示里。

r = httpx.get("https://api.ashareapi.com/v1/kline",
              params={"code": "sh600519", "period": "day", "count": 250})

这没问题，多数人也是从这开始的。但注意 Agent 知道什么：就一个 URL，而且只是因为你说过。 你问它另一个字段，它要么猜，要么反过来问你。

REST 调用的扩展性，等于「你记得教几件事」。

MCP 服务器，是一份 Agent 自己能读的契约

用 MCP 服务器，Agent 会拿到一份「有什么」的描述：

{
  "mcpServers": {
    "ashareapi": {
      "type": "http",
      "url": "https://api.ashareapi.com/mcp"
    }
  }
}

Claude Code 要带 type；Cursor 用同一个对象、去掉 type；Codex 用 TOML。

然后 Agent 可以：

它能 因为
发现有哪些工具 服务器列出了它们
读每个工具的参数 每个工具声明了自己的 schema
知道返回长什么样 schema 是写明的，不是猜的
规划一个多步问题 它能在选之前先看见有哪些零件

这就是差别：Agent 不再猜「有什么可能」，而是从「实际有什么」里挑。

为什么这对交易工作流重要

一个交易问题很少只是一次调用。「这几只票里谁上周成交量最高，当时板块在发生什么？」—— 这是一个计划，不是一次查询。

方式 Agent 会怎么做
REST，逐个端点教 只调你列过的，列完就停
MCP，工具可发现 挑问题需要的工具，串起来

第一种方式的失败是静默的：Agent 不会说「我只知道一个端点」。它用手头有的东西回答 —— 这就是薄数据集如何变成一个自信的错误答案。

什么时候 REST 仍然是对的选择

MCP 不总是更好。用普通 REST 调用，当：

  • 它就是一个固定请求，按计划跑 —— 不需要规划
  • 你在一个系统内部，那里本来就知道端点
  • 客户端不支持 MCP —— 脚本调用就是完整方案

规则：当 Agent 应该自己决定用哪些工具时，用 MCP。当你已经决定了，用 REST。

验证那条规矩仍然成立

无论选哪条路，定义页那条检查都成立：数字必须来自一次你能重跑的调用。

MCP 让工具变得可发现。它不让工具变得正确。你仍然需要：

  • 调用里写明窗口
  • 字段名精确
  • 同一个请求产生同一条序列

发现不等于验证。 它们是两个不同的步骤，而第二步是你的事。

试一下

# 同一条序列，任何时候 —— 请求完全决定了结果。
curl "https://api.ashareapi.com/v1/kline?code=sh600519&period=day&count=250"

然后把一个支持 MCP 的客户端指向服务器，问一个需要两步的问题。看它是去选工具，还是反过来问你该调什么。

下一步

出处