API、MCP、Connector 与 Workflow

一句话理解：API 是系统之间的通用接口；MCP 是让 AI 应用以统一方式发现和调用能力的协议；Connector 是 AI 产品里“装好就能用”的集成形态，如今多数建立在远程 MCP 之上；Workflow 是把固定步骤写死的自动化流程。它们不是替代关系，而是不同层次、不同用途。

“我们要不要做 MCP？”“做个 Connector 是不是就够了？”“这事用 n8n 这类工作流工具拉一下不就行了？”这些讨论常常各说各话，因为大家对这四个词的理解不在同一个层面上。

这一课先把四个概念放在同一张图里，再给出一个选择方法，最后用电商公司的例子走一遍完整的接入规划。

四个概念在哪一层

四个概念各自所在的层次如下：

图 1 · 四个概念不在同一层：Connector 建在 MCP 上，MCP 建在 API 上，Workflow 横跨各层

	API	MCP	Connector	Workflow
本质	系统对外提供的编程接口	面向 AI 应用的开放协议	AI 产品中的集成包 / 目录条目	预先定义好的步骤序列
给谁用	开发者写的程序	任何支持 MCP 的 Host	该 AI 产品的终端用户	触发器或调度器
谁决定调用什么	调用方代码	模型（工具）、应用（资源）、用户（提示模板）	同 MCP，由所在产品控制	流程定义，路径固定
复用范围	所有能写代码的系统	所有 MCP Host	通常限于一个产品生态	限于这条流程
接入成本	每个 AI 产品各写一次适配	Server 写一次，Host 配置即可	用户点几下，提供方需满足平台要求	搭建流程，维护每个节点
典型例子	订单系统的 `GET /orders/{id}`	内部订单 MCP Server	Claude 或 ChatGPT 里的某个 SaaS 连接器	每晚自动对账并生成异常报表

逐个说清楚

API：这是一切的底座。MCP Server 和 Connector 内部通常还是调用 API。对于只在一个自研 Agent 里使用的能力，直接把 API 包装成 Function Calling 工具最简单，不需要多一层协议，基础见 HTTP 与 API。

MCP：当同一个能力需要被 多个 AI 产品 使用，或者你想让用户在自己选择的 AI 工具里接入你的系统时，MCP 的价值就出现了。它统一了发现、调用、授权和传输，详见前面几课。

Connector：这是产品层面的叫法，不同平台含义略有差异，要看具体文档：

Claude 的自定义连接器（custom connectors）文档写明，构建连接器就是构建远程 MCP Server；用户可以在 Claude 的设置里添加，提供方还可以申请收录到连接器目录。
OpenAI 的 Responses API 中，远程 MCP Server 通过 type: "mcp" 加 server_url 接入；此外还有一组由 OpenAI 维护的连接器（如 Gmail、Google Drive、SharePoint 等），通过 connector_id 使用。

所以 Connector 可以理解为“MCP Server + 平台的分发、授权与管理体验”。你要做的，往往是先把远程 MCP Server 做好，再按目标平台的要求适配。需要注意，平台支持的规范版本和能力并不完全一致：比如 Claude 连接器文档目前列出支持的授权规范版本为 2025-03-26、2025-06-18 与 2025-11-25，资源订阅与 Sampling 尚不支持。

Workflow：路径固定、每一步都能提前写清楚的流程，用确定性编排更快、更便宜、更可控。Workflow 的节点里可以调用 API、调用 MCP 工具，也可以调用一次模型做分类或摘要。Workflow 和 Agent 的分界，见 Workflow 与 Agent。

怎么选：五个问题

按顺序回答五个问题：

图 2 · 五个问题：前三个决定接入方式，后两个决定部署与是否自建

电商公司的接入规划

一家电商公司要让 AI 参与订单售后，涉及订单、支付、CRM、工单四个系统。按上面的方法，他们得到这样一份规划：

需求	选择	理由
每晚 2 点拉取前一天所有售后申请，按原因分类，生成日报发到群里	Workflow，分类节点调用一次模型	步骤固定、按时触发；只有分类需要模型
自研客服 Agent 在对话中诊断单个订单	API + Function Calling（初期）	只有一个 Agent 使用，工具数量少，迭代快
工程师在 Claude Code、Cursor 里排查线上问题时查订单与支付	订单 MCP Server（内网 Streamable HTTP，公司统一登录）	多个 Host 复用同一套只读工具，集中审计
客服主管希望在 Claude 或 ChatGPT 里直接问“今天有哪些退款超时的订单”	把同一个 MCP Server 按平台要求接入，作为 Connector 提供给员工	业务人员不会配置本地 Server；需要 OAuth 与管理员统一启用
查询公司邮箱与日历	使用平台现成的 Connector	无需自建，重点评估授权范围与数据合规

注意第二行和第三行：当自研客服 Agent 的工具越来越多、别的团队也想复用时，把工具迁移到 MCP Server，让客服 Agent 也作为 Host 去连接它，就能“一处维护、多处使用”。这种演进很常见，不必一开始就追求一步到位。

组合使用，而不是四选一

真实系统里四者经常嵌套出现：

Workflow 里嵌 Agent：日报流程发现某类售后激增时，调用诊断 Agent 深入分析。
Agent 调用 Workflow：Agent 判断需要退款时，不自己一步步操作，而是触发一条带审批的确定性退款流程。
MCP 工具背后是 Workflow：create_aftersale_ticket 这个 MCP 工具内部走的是工单系统里固定的建单、分派、通知流程。

这类组合的设计方法，见混合架构。

常见误区

“有了 MCP，就不需要 API 了。” MCP Server 内部依然调用 API。API 设计得差，MCP 只是把问题包装了一层。
“Connector 和 MCP 是竞争关系。” 在主流平台上，Connector 大多就是远程 MCP Server 加上平台的分发与授权体验。
“能用 Agent 的地方就别用 Workflow。” 恰恰相反，能写死的流程优先用 Workflow，只在需要判断的地方用 Agent。
“平台上有现成 Connector，接上就行。” 现成 Connector 省去了开发，但它能读哪些数据、以谁的身份操作、数据会流向哪里，都需要评估。

产品经理检查清单

这个需求的路径能否提前写死？能的话，为什么还要用 Agent？
这个能力现在和未来会被几个 AI 产品使用？
目标用户是谁？他们在哪个产品里使用？需要怎样的安装与授权体验？
目标平台支持哪些 MCP 能力、传输方式与授权规范版本？
有没有现成的官方 Connector？它的权限范围是否可以接受？
当工具从“某个 Agent 专用”变成“多处复用”时，迁移到 MCP 的计划是什么？

练习

用本课的五个问题，为销售分析场景做一份接入规划（30–45 分钟）：

列出 5 个需求，例如：每周自动生成销售周报；销售在对话中追问“华东为什么下滑”；分析师在 Cursor 里写查询脚本时查看指标口径；管理层在 Claude 里查询关键指标；读取公司日历安排复盘会。
为每个需求选择 API、MCP、Connector 或 Workflow（可以组合），并写出理由。
找出一个“今天用 API、半年后应该迁移到 MCP”的能力，写出触发迁移的信号。

下一步

理论讲完了。下一课「实操：写一个 MCP Server」用官方 SDK 把订单查询工具做成 MCP Server，并在 Claude Code 里调用它。

API、MCP、Connector 与 Workflow