MCP 加入 Linux 基金会：这对构建下一代 AI 工具和代理的开发者意味着什么
Source: GitHub Blog
在过去的一年里，AI 开发呈爆炸式增长。现在已有超过 110 万个公开的 GitHub 仓库引入了 LLM SDK（同比增长 178 %），开发者创建了近 70 万个全新的 AI 仓库，根据今年的 Octoverse 报告（链接）。像 vllm、ollama、continue、aider、ragflow 和 cline 这样的代理工具正迅速成为现代开发者栈的一部分。
随着生态系统的扩展，我们看到对模型与外部工具和系统的连接需求日益增长——需要安全、统一且跨平台的方式。这正是 Model Context Protocol（MCP）迅速填补的空白。
MCP 最初是 Anthropic 内部的一个开源想法，因从一开始就保持开放并面向社区进行扩展、采纳和共同塑造而快速成长。这种开放性是它成为业界增长最快的标准之一的核心原因，也让 GitHub 和 Microsoft 等公司能够加入进来，共同完善该标准。
现在，Anthropic 正将 MCP 捐赠给 Agentic AI Foundation，并由 Linux Foundation 管理（链接），协议正进入共享治理的新阶段。这将为开发者提供长期工具、生产代理和企业系统的基础。对我们这些一直参与 MCP 社区的人来说，这令人振奋；鉴于我们长期支持 Linux Foundation，我们对这一举措表示强烈支持。
过去一年，MCP 取得了令人难以置信的增长和变化。我认为有必要回顾一下 MCP 的发展历程，以及它转移到 Linux Foundation 对下一波 AI 开发意味着什么。
MCP 之前：碎片化的 API 与脆弱的集成
LLM 最初是孤立的系统。你向它们发送提示（prompt），得到响应。我们会使用检索增强生成（RAG）等模式来引入数据，为 LLM 提供更多上下文，但这有限。OpenAI 的 function calling（介绍链接）带来了巨大变化，因为首次可以调用任何外部函数。这正是我们在 GitHub Copilot 中最初构建的基础。
到 2023 年初，开发者通过一堆不兼容的 API 将 LLM 连接到外部系统：定制扩展、IDE 插件、平台特定的代理框架等。每个提供商都有自己的集成方式，且没有一种是完全相同的。
“所有平台都有自己的尝试，比如 function calling、插件 API、扩展，但它们都没有获得太大 traction。” – Nick Cooper，OpenAI 工程师、MCP 指导委员会成员
这不是工具问题，而是架构问题。
将模型连接到实时网页、数据库、工单系统、搜索索引或 CI 流水线需要定制代码，而这些代码往往在下一个模型更新时失效。开发者必须为每个平台单独编写深度集成的胶水代码。
“整个行业正头朝下冲向 n×m 的集成问题，客户端太多、系统太多，却没有共享的协议来连接它们。” – David Soria Parra，Anthropic 高级工程师、MCP 最初架构师
实际而言，n×m 集成问题描述的是这样一个世界：每个模型客户端（n）都必须分别与每个开发者依赖的工具、服务或系统（m）集成。五个 AI 客户端与十个内部系统的组合会产生五十个定制集成——每个都有不同的语义、认证流程和故障模式。MCP 通过定义一个单一、供应商中立的协议，让客户端和工具都能使用同一种语言，从而消除这种复杂性。
缺乏标准不仅低效，还拖慢了真实世界的采纳。在金融、医疗、安防等受监管行业，开发者需要安全、可审计、跨平台的方式让模型与系统通信。而他们得到的却是边界不清的专有插件生态。
MCP：为开发者工作方式而生的协议
在整个行业——包括 Anthropic、GitHub、Microsoft 等——工程师们不断碰到同一个难题：可靠地将模型连接到上下文和工具。Anthropic 内部，团队注意到他们的内部原型在请求数据、调用工具和处理长时间任务的模式上趋于一致。
Soria Parra 简单描述了 MCP 的起源：它是对 Anthropic 工程师们不断重构的模式进行标准化的方式。MCP 将这些模式提炼为围绕通信的协议——模型与系统如何对话、请求上下文以及执行工具。
Anthropic 的 Jerome Swanwick 回忆起一次内部黑客马拉松，“每个参赛作品都基于 MCP … 在内部迅速走红”。
这种早期的开发者热度成为种子。一旦 Anthropic 公开发布 MCP（链接）并提供高质量的参考服务器，整个社区立刻认识到它的价值。MCP 为模型与外部系统的通信提供了一种共享方式，无论客户端、运行时或供应商如何。
为什么 MCP 能够成功：贴合真实开发者工作流
MCP 推出后，采纳速度之快前所未有。
“它就是这么顺理成章。我明白他们要解决的问题，也明白为什么必须有它。” – Den Delimarsky，Microsoft 首席工程师、负责安全和 OAuth 的核心 MCP 指导委员会成员
在数周内，来自 Anthropic、Microsoft、GitHub、OpenAI 以及独立开发者的贡献者开始扩展并强化该协议。接下来的九个月里，社区加入了：
- 用于安全远程服务器的 OAuth 流程
- 采样语义（确保在调用工具或请求上下文时模型行为一致）
- 精炼的工具模式（tool schemas）
- 一致的服务器发现模式
- 扩展的参考实现
- 改进的长时间任务支持
长时间任务 API 是关键特性。它们允许构建、索引、部署等多分钟作业能够可预测地被跟踪，而无需轮询 hack 或自定义回调通道。这对我们今天看到的长时间 AI 代理工作流至关重要。
Delimarsky 的 OAuth 工作也是一个拐点。在此之前，大多数 MCP 服务器都运行在本地，这限制了在企业环境中的使用并导致安装摩擦。OAuth 使远程 MCP 服务器成为可能，解锁了大规模安全、合规的集成。这一转变让 MCP 能够用于多机器编排、共享企业服务以及非本地基础设施。
同样重要的是，OAuth 为 MCP 提供了一套熟悉且经过验证的安全模型，而无需专有的 token。