跳到主要内容

MCP加入Linux基金会：成为AI工具与平台的“新骨干”

· 阅读需 13 分钟

Model Context Protocol（MCP）正式加入 Linux 基金会，成为全新 Agentic AI Foundation（智能体 AI 基金会）的首批开源项目之一。表面上看，这像是一条典型的“开源项目捐赠”资讯，但对于在做 AI 工具、智能体（Agent）、AI 低代码平台、企业开发平台和内部开发者平台的人来说，它更像是平台工程层面的一次“架构升级信号”。

这篇文章会用尽量通俗、但又对平台工程友好的方式，拆解三个问题：MCP 到底解决了什么痛点？加入 Linux 基金会改变了什么？如果你在做 AI 原生平台、集成平台或企业级智能体，这件事和你有什么直接关系？

Loading...

一、先弄清楚：MCP 是什么，为什么突然这么重要？​

在 MCP 出现之前，AI 集成基本是一团乱麻：

  • 每家大模型平台都有自己的插件/工具调用方式

  • 每个团队都在重复造轮子，去写一大堆“只服务某一个平台”的 SDK 和连接器

  • 集成逻辑分散在各种项目里，难以复用、难以治理、安全策略也难统一

换句话说，AI 工具和智能体虽然很火，但底层的“接系统”这件事一直是土法上马。

MCP（Model Context Protocol）做的事情，很简单也很关键：为“模型如何调用外部工具和系统”这件事，定义一个统一的开放协议。

从平台工程视角看，MCP 主要带来三件事：

  • 一个统一的方式，把 API、数据库、内部微服务、SaaS 等封装成 MCP 服务端（Server）

  • 一个统一的方式，让各种 AI 客户端（Client）——比如智能体、Copilot、AI 平台——去发现这些工具、查看能力并进行调用

  • 在协议层预留 配置、权限、上下文 等能力，而不是每个厂商自己搞一套不兼容的格式

过去一年里，MCP 的生态增长非常快：官方披露的数据里，SDK 每月下载量已经达到数以千万计，活跃的 MCP 服务器也达到上万级别，且已经被多家主流 AI 平台和工具原生支持。

站在 SEO 和技术决策视角，可以简单理解为：

“如果说 HTTP 是服务之间说话的协议，那 MCP 正在成为 ‘模型和工具之间’ 说话的协议。”

二、MCP 加入 Linux 基金会，到底改变了什么？​

MCP 是由 Anthropic 率先提出并开源的，现在正式捐赠给 Linux 基金会名下的新组织——Agentic AI Foundation（智能体 AI 基金会，简称 AAIF）。

这件事带来的影响，至少有三个层面。

2.1 中立、长期的治理架构​

在 Linux 基金会旗下，MCP 获得了类似 Kubernetes、Node.js、PyTorch 那样的 中立开源治理模式：

  • 有清晰的治理结构和指导委员会，负责战略方向和资源分配

  • 协议本身由技术维护者和社区共同演进，透明决策

  • 不再受单一商业公司的产品路线左右

对于需要给“平台标准”做多年规划的企业来说，这一点非常关键——你可以更有信心地把 MCP 写进技术路线图，而不是当成一个“厂商扩展点”。

2.2 为“智能体 AI 时代”铺出一条公共底座​

Agentic AI Foundation 的使命非常明确：推动 以智能体为中心（Agentic）的 AI 系统 的标准化和基础设施建设。MCP 成为首批核心项目之一，与其他项目一起，承担类似“AI 工具时代的基础协议”的角色。

这类项目正在合力定义：

  • 工具接口和智能体能力的标准描述方式

  • 通用的编排模式、安全与治理模式

  • 不同平台之间的互通互操作

从行业视角看，这是把原本各自为战的“插件生态”，往互联网早期那种 “通用协议 + 多样实现” 的方向拉。

2.3 让企业路线图更容易“押注 MCP”​

有了 Linux 基金会的背书和更大的生态参与度，企业在做中长期规划时，就更容易：

  • 把 MCP 当作企业级集成标准的一部分

  • 让内部的命名、认证、可观测性等规范与 MCP 对齐

  • 在引入新的 AI 平台和工具时，把“是否支持 MCP”当成一条重要评估标准

对于 CTO、平台负责人和安全团队来说，这都是降低风险、减少锁定的重要信号。

三、从平台工程角度看：为什么 MCP 这么关键？​

从行业数据看，AI 已经不再是“尝鲜项目”：

  • 多项调研显示，超过八成的大型企业已经在落地 AI 解决方案，平均每年在 AI 上的投入达到数百万美元级别

  • 同时，业内普遍预测，到 2025 年左右，约 70% 的新企业应用会采用低代码或无代码技术交付

这两股趋势叠加，直接带来了一个现实：

平台工程和集成团队，正在同时面对 “大量 AI 应用 / 智能体 + 跨系统集成 + 多云环境 + 多角色（开发者和业务人员）” 的组合挑战。

如果没有类似 MCP 的开放协议，这种复杂性很快会失控。

3.1 从“API 意大利面”到“统一协议层”​

在很多公司里，现在的 AI 集成状态大概是这样的：

  • 每个项目都有自己的 API 封装、函数调用、工具描述方式

  • 每接一个新系统，就多出一批只服务某个项目的连接器

  • 权限控制和审计分散在各个仓库，难以统一治理

MCP 的价值就是在这里切入：

  • 平台团队 可以把内部系统（CRM、ERP、数据仓库、工单系统等）统一封装成 MCP Server

  • 各种 AI 工具和智能体 通过 MCP Client 来发现和调用这些能力

  • 安全、合规、访问控制可以在协议层统一收口，而不是到处打补丁

对做集成平台、iPaaS 或内部开发者平台的人来说，可以简单理解为：

MCP 正在成为“AI 原生集成层”的候选标准。

3.2 为什么传统 iPaaS 难以完全覆盖智能体场景？​

传统 iPaaS 更偏向 系统对系统 的“事件驱动 + API 调用”：

“当系统 A 发生事件 X 时，去调用系统 B 的某个接口。”

而智能体 AI 带来了几项新的要求：

  • 智能体需要在运行时动态发现、选择和组合工具

  • 大模型需要结构化的工具描述和示例，才能稳定调用

  • 安全控制不仅针对“人”，还要考虑“模型可能做什么”

这些都不是传统集成标准天然考虑的问题。MCP 则是从一开始就为智能体和 AI 工具设计的协议：

  • 把“工具的能力、结构化参数、调用方式”明确定义出来

  • 为“多个工具的组合调用”提供更清晰的语义基础

  • 和 AI 平台、智能体运行环境天然兼容

因此，无论你是在做 AI 原生集成平台，还是在构建企业级 Copilot / 多步智能体，MCP 都更像是下一代集成底座。

四、对 AI 原生开发平台来说，MCP + Linux 基金会意味着什么？​

如果你正在使用像 JitAI 这样的 AI 原生开发平台，这次 MCP 加入 Linux 基金会，对你的架构和产品设计其实是非常直接的利好。

4.1 从一开始就选择“开放集成”，而不是私有协议​

在很多项目里，一开始为了快速落地，团队会直接：

  • 把内部系统硬连到某一个大模型供应商的专有协议上

  • 或者为某个特定的智能体框架写一堆专用适配器

短期看可以跑起来，长期看就会发现：一旦要换模型、换平台、上多云，集成层几乎得重写一遍。

如果从现在开始，将 MCP 作为首选协议：

  • 内部系统对外暴露的“AI 可用能力”，通过 MCP 统一封装

  • AI 原生平台（比如 JitAI）负责编排、开发体验和可视化，站在 MCP 之上

  • 将来要换模型、换智能体运行时，集成层尽量不动

这对做平台工程和企业架构规划的人来说，是一个非常现实的“反锁定”策略。

4.2 把企业系统变成以 MCP 为先的一组服务​

在一个典型企业里，你可以这样设计：

  1. 把 CRM、ERP、数据仓库等系统封装成一组 MCP Server

  2. 把“查供应商”“取预算”“创建采购单”“生成合规摘要”等能力定义为 MCP 工具

  3. 在 AI 原生平台里，将这些工具编排成面向业务的智能体或 Copilot

在这之上，如果你使用的是像 JitAI 这样的平台：

  • 可以在可视化界面里，把 MCP 工具当作乐高积木式的组件

  • 外围加上 AI 逻辑、审批流程、监控和观测

  • 让业务团队通过“拖拽 + 少量代码”，快捷地组合出新的 AI 工具和智能体

当你准备把这些实践真正落地到项目中，可以先 try JitAI，在一个 AI 原生的平台环境下，把 MCP 思路变成可以复用的模板和资产。

4.3 让平台工程、集成团队和产品团队在同一协议上对齐​

在比较成熟的组织里，可以用 MCP 把三类团队“串”起来：

  • 平台工程团队：确定 MCP 作为企业级标准，建设统一的运行和治理环境

  • 集成 / 数据团队：负责把系统和数据源封装成 MCP Server

  • 应用 / 产品团队：在 AI 平台里调用这些能力，搭建具体的智能体、应用和流程

MCP 加入 Linux 基金会之后，这样的“跨团队协议协作”会更有说服力，也更容易写进公司级标准。

五、实操视角：企业如何循序渐进落地 MCP？​

你不需要一口气把所有集成全部重写成 MCP。对大部分企业来说，一个更现实的路线是：从有业务价值的 MVP 场景开始，小步快跑、逐步标准化。

第一步：盘点你现有的 AI + 集成版图​

先做一个简单但完整的清单：

  • 现在公司里有哪些场景在用 AI（对内 Copilot、对外客服、报表助手等）？

  • 这些 AI 触达了哪些系统（CRM、ERP、工单、知识库、数据湖等）？

  • 其中用了多少种“自研连接器 / 插件 / SDK”？

这个过程会让你看到两件事：
一是“AI 已经渗透到了多少业务线”，二是“集成复杂度已经到什么程度”。

第二步：选 1–2 个高价值的跨系统流程​

优先选这样的候选场景：

  • 涉及多个系统（比如采购审批、客户问题闭环、异常订单处理）

  • 使用频率高、业务影响大

  • 目前维护成本高、改动稍微多一点就容易出问题

这些流程，通常非常适合做为你的首批 MCP 服务器和智能体落地场景。

第三步：为这些流程搭建第一批 MCP Server​

对每个选中的流程，可以这样拆：

  1. 把流程中最关键的动作抽象为 MCP 工具，如：lookup_supplier、fetch_budget、create_ticket 等

  2. 用 MCP Server 把现有 API 或服务稍作封装

  3. 在 AI 平台或智能体框架中，通过 MCP Client 接入这些工具

在这一阶段，建议重点关注：

  • 工具的参数设计和描述是否清晰，模型能否稳定调用

  • 认证和授权策略是否和现有安全体系对齐

  • 日志、链路追踪、监控指标是否完善，便于后续优化

第四步：和 AI 原生开发平台深度结合​

接下来，把 MCP 真正“长在”你的 AI 平台里：

  • 在平台里把 MCP 工具以组件形式暴露，方便拖拽和复用

  • 在组件外一层包上 Prompt、策略、人工确认节点等

  • 为常见场景做成模板，让其他团队可以“一键复制 + 少量改造”使用

在 JitAI 这样的 AI 原生开发平台上，团队无需理解 MCP 的细节，只需要面对：

“我可以调用哪些业务能力？”
“它们如何组合成一个稳定可靠的智能体？”

MCP 则负责在背后保证：这些能力是被标准化描述、可治理、可迁移的。

第五步：把 MCP 写入你的平台标准和架构文档​

当首批场景跑通，并且在业务上拿到正反馈之后，就可以开始“固化成果”：

  • 在内部参考架构、最佳实践文档中增加 MCP 的章节

  • 为 MCP Server 的设计、代码规范、安全审查等建立模板

  • 在采购和评估新的 AI 平台、工具时，明确要求“需要支持 MCP 或可兼容接入”

随着更多项目采用 MCP，你的 AI 生态会从“一个个零散的项目”，逐渐变成一套有共同协议和标准的企业级 AI 平台。

六、常见问题：MCP、Linux 基金会与 AI 工具和智能体的未来​

Q1：MCP 只适合“大厂”和云平台吗？​

不是。MCP 从一开始就是一个面向社区的开放协议。任何组织——无论是创业公司、传统企业，还是内部平台团队——都可以在自己的系统中实现 MCP Server 和 Client。

Linux 基金会的加入，主要是保证治理的中立性和开放性，让更多参与方更安心地投入。

Q2：MCP 和我们已经在用的 API / Webhook 有什么区别？​

API 和 Webhook 更关注“请求怎么发、事件怎么推”。

而 MCP 关注的是：“在 AI 场景下，模型如何发现、理解并稳定调用这些能力？”

因此，MCP 在 API 之上额外做了几层标准化工作：

  • 统一的工具元数据和参数描述，让模型更容易理解

  • 标准的工具列表和选择机制，支持运行时动态发现

  • 为智能体的多步调用、自主决策留出了更清晰的语义空间

你可以把 MCP 理解为：“专门为 AI 工具和智能体设计的一层协议语义标准”。

Q3：采用 MCP 会不会被锁定在某一家 AI 供应商上？​

恰恰相反。MCP 加入 Linux 基金会、由 Agentic AI Foundation 管理，目的之一就是避免被某一家厂商控制协议演进。

只要更多 AI 平台和工具支持 MCP，你就可以在不改动集成层的前提下，自由选择或切换模型、编排框架和运行环境。

Q4：我们已经有低代码平台和集成平台了，还需要 MCP 吗？​

有现成平台反而是优势。一个比较现实的做法是：

  • 从现在起，把新上的 AI 集成尽量统一到 MCP 上

  • 让已有的低代码或集成平台可以调用 MCP Server 提供的能力

  • 逐步把原先项目里的“定制连接器”在迭代中迁移到 MCP

关键不是“一夜之间全部重写”，而是让 MCP 成为“未来所有 AI 相关集成的默认选项”。

标签：
  • MCP
  • 平台工程
  • 集成平台
  • AI 智能体
编辑此页