MCP从0到1：AI如何安全对接现有服务生态

MCP 的起点：从 Function Calling 说起

要理解 MCP（Model Context Protocol），得先回到它的前世——Function Calling。在 AI 早期，模型主要处理文字和对话，远没有今天这般工业化。当时开发者已经习惯了 Web2 生态中确定的服务接口：微信支付通过 HTTP API 提供退款、付款能力，GitHub 通过 HTTP API 提供查询仓库列表的能力。这类基于 HTTP 的 CRUD 操作，统称为 API 调用。

问题随之而来：既然人可以调用 API，AI 是不是也应该能调用？让 AI 去对接各类服务生态的能力，就是 Function Calling。但大模型的交互是 Completion 对话形态，而微信这类服务只认 HTTP API。两者之间必须架一个「适配器模块」，负责把 AI 的对话转换成真正的 HTTP 调用。

Function Calling 时代开发者的适配困境

群雄割据：每家 AI 厂商都造自己的轮子

适配器概念一出，各家 AI 厂商立刻推出了各自的对接规范，谁都不让谁。UP 主举了两个典型例子：OpenAI 走的是 Plugin + Actions 路线，需要开发者提供海量配置文件；Anthropic 的 Claude 则是自建 agent，要你自己写 if-else 逻辑代码。再加上 Google 等厂商入场，规范五花八门。

最终受累的是开发者。假设你是微信支付的官方开发者，想让支付能力接入 AI，就得同时为 OpenAI 写一套 Action 适配器、为 Claude 写一套自建适配器。上游厂商越多，你要写的适配代码就越多——十几套代码只为了同一个退款能力。

各家规范参差不齐，开发者被迫写多套适配代码

Function Calling 本质上是一种「结构化输出」机制：模型在生成回复时，不再只输出自然语言，而是输出一段格式化的「调用意图」（通常是 JSON），描述它想调用哪个函数、传入什么参数。宿主应用程序解析这段 JSON，执行真正的函数调用，再把结果返回给模型，模型据此生成最终答复。由于各家厂商对这段 JSON 的字段命名、嵌套结构、错误处理方式各有主张，导致同一个「退款」意图在 OpenAI 和 Claude 眼中是两种完全不同的数据格式，开发者必须为每家厂商分别编写解析和转换逻辑。

统一标准诞生：Anthropic 牵头的 MCP 雏形

面对乱局，Anthropic 在 2024 年底牵头提出了一套统一的 Function Calling 规范，并被其他厂商共同遵守。这套规范内容繁多，但最核心的是两条，都是针对适配器提出的：

Tools List API：适配器必须提供，用于告诉 AI App 自己具备哪些能力（例如「退款能力」）。
Tools Call API：适配器必须实现，模型会在合适的时机要求 AI App 调用它来执行具体能力。

有了这套规范，链路变得清晰：模型接入时先调用 Tools List 发现已有能力；用户发起退款请求后，AI 调用 Tools Call 执行；适配器收到调用后，再去请求背后真正的退款 HTTP API。

对开发者来说，这意味着彻底解放。你不再需要管上游是 DeepSeek^广告、Google、Kimi、Claude 还是 OpenAI，只需声明自己的 Tools List、实现自己的 Tools Call。一套适配器可以对接成百上千个上游厂商。而这个适配器，就是 MCP 服务，这套规范就是 MCP 最早的版本——可以理解为 MCP 的「前世」。

沉寂与质疑：「MCP 已死」的那段时间

有意思的是，MCP 诞生后并没有立刻走红。随着大模型算力越来越强，模型强大到不需要 MCP 也能直接推断出如何调用微信的 HTTP API 来完成退款。一时间，外网铺天盖地都是「MCP 已死」的言论，认为它只是昙花一现。

然而 UP 主强调，到了今天 MCP 已经成为 AI 领域的中流砥柱。转折点在于：模型越强大，暴露出的问题反而越多。

「模型直接推断如何调用 API」的思路，在业内通常被称为 ReAct（Reasoning + Acting）或 Zero-shot Tool Use：让模型仅凭 API 文档说明，在推理过程中自行拼装 HTTP 请求。这一方式在简单场景下可行，但存在明显局限：模型可能幻构不存在的参数、忽略鉴权细节、对分页或错误重试逻辑处理不当。更关键的是，它要求把完整的 API 文档塞入上下文，随着接入服务数量增加，上下文长度会急剧膨胀，既增加推理成本，也降低准确率。这正是 MCP 规范化 Tools List 的价值所在——用结构化的能力声明代替非结构化的文档，让模型以最小的上下文代价准确理解可用工具。

重回王座：密钥安全成为关键推手

UP 主用一个真实场景说明问题。假设线上数据库查询效率变低，你直接找 AI 求助。但 AI 对数据库没有直接访问权限，它会要求你提供账户。有专业 DBA 的公司或许能分出只读账户，但很多中小公司做不到，结果就是直接把 root 账户密码交给 AI。

这相当于什么？UP 主打了个比方：这不亚于把你的银行卡支付密码告诉 AI，你愿意吗？事实上，无论是 Claude 还是 Cursor，都在自家文档里明确禁止用户向 AI 透露敏感数据和密钥。

向 AI 透露密钥的风险已被主流工具官方警告

更麻烦的是，密钥会随着工具扩散。你把数据库密码、Docker secret、SSH 凭证都交给了 Claude；某天同事用 Trae，又得给 Trae 一份；再有人用 Cursor，又得给 Cursor 一份。等于拿着大喇叭在大街上公开你的密钥。UP 主还提到近期一起争议事件：某上市 AI 编辑器不仅记录密钥，甚至把用户的 GitHub 提交记录打包上传到自家公有云服务器——敏感信息安全性面临前所未有的挑战。（该事件细节为 UP 主单方陈述，具体以官方为准。）

MCP 的解法：把密钥留在内网

过去不用 AI 时为什么没有泄露风险？因为密钥始终放在自己的服务器上，由后端程序持有，去和 MySQL、Docker、SSH 打交道，前端只调后端接口。而 AI 时代，这个后端 APP 没了，敏感 Key 直接落到了 AI 手里。

解决思路很自然：既然 MCP 天生就是连接 AI 和存量服务的桥梁，那就直接架一个 MCP 服务，把敏感密钥移到 MCP 上。AI 只通过 Tools Call 调用 MCP，MCP 负责适配背后的 MySQL、Docker、Shell。密钥又回到了你自己的内网。

MCP 服务作为中间层，让密钥重新回到内网

UP 主总结了 MCP 重登王座的三个因素：

控制敏感密钥信息——密钥不再直接暴露给 AI 厂商。
缓解 Context 爆炸问题——在一定程度上降低上下文负担（后续视频详解）。
权限控制——例如 MCP 可以拦截数据库请求中的 Delete 关键字并直接拒绝，而没有 MCP 时 AI 想执行 Delete 就执行 Delete，无人能拦。

其中权限控制和 Context 爆炸，都属于 MCP Gateway 的上游解决方案。

MCP Gateway 是在 MCP 服务之上再加一层企业级管控平面。单个 MCP 服务解决的是「某一类工具的适配」问题，而企业往往同时运行数十个 MCP 服务（数据库、代码仓库、监控系统……），Gateway 充当统一入口，负责身份认证、请求路由、审计日志、限流熔断以及跨服务的权限策略。类比 Web 生态，MCP 服务相当于各个微服务，MCP Gateway 相当于 API Gateway（如 Kong 或 Nginx）。有了 Gateway，企业可以在不改动任何单个 MCP 服务代码的情况下，统一追加「禁止 DELETE 操作」「只允许特定团队访问生产环境数据库 MCP」等策略，实现集中式安全治理。

概念厘清：MCP 与 MCP 服务

最后需要区分两个容易混淆的概念：

MCP：本质是一套规范，约束 AI 厂商与存量服务之间如何交互，即 Tools List、Tools Call 那一套。
MCP 服务：具体落地适配逻辑的适配器程序。

从 Function Calling 的混乱，到统一规范的诞生，再到「已死」质疑，最终因密钥安全、Context 与权限问题重回核心——MCP 走完了一段完整的循环。而 MCP Gateway，也顺理成章成为企业使用 MCP 的最佳实践。

UP 主也提醒，MCP 从 2024 年底推出至今不过一年半，文档和知识体系尚未成熟，本文（视频）为便于理解弱化了部分细节。下一步值得关注的，是 Tools List 与 Tools Call 的消息格式和传输方式究竟如何运作。