WordPress AI 团队推动 MCP 成为内核默认能力，目标版本 7.3
随着越来越多站点所有者开始借助 AI 代理来管理网站，WordPress AI 团队正在推动把 MCP（Model Context Protocol）变成 WordPress 的默认组成部分。
由 Automattic 赞助的 AI 团队代表 Jason Adams 周二宣布，他已获得 WordPress 联合创始人 Matt Mullenweg 的批准，"把 MCP 建进内核"。
官方定调：MCP 正成为"入场门槛"
Adams 在 WordPress Slack 的 #core-ai 频道写道："我们正迅速看到 MCP 成为现代代理世界的入场门槛。"他表示，MCP 正在成为 AI 代理的事实标准解决方案，在市场生态中尤其明显。"我们内部大量使用，客户很喜欢，而 WP Vibe 也显示出更进一步的需求。"他提到的 WP Vibe 是 Awesome Motive 的 MCP 插件。
Adams 称 Mullenweg 只提了一个要求："把所有我们手上的东西都扔进去，尽量避免新的漏洞。" 这一定调是在 AI 团队周会之前公布的。据会议纪要显示，Adams 在会上告诉贡献者，Mullenweg 已批准把 MCP 打造为 WordPress 体验中"事实上的组成部分"，理由是 AI 代理的采用度持续增长，以及让 WordPress 能被代理驱动的工作流访问变得重要。
实现路径尚未确定：打包、启用还是原生开发
把 MCP 引入 WordPress，并不一定意味着把现有的 MCP Adapter 插件合入内核。目前摆在桌面上的选项包括：
- 随 WordPress 一起打包分发该插件；
- 通过内核现有的接口启用它；
- 直接在核心里开发对应的具体能力。
会议记录显示，AI 贡献者在"让 MCP 成为 WordPress 默认体验的一部分"这一点上达成了共识，但具体技术实现方式仍留待进一步讨论。
距 canonical 插件发布仅两周，态度近乎反转
WordPress MCP Adapter 作为 canonical 插件在 WordPress.org 上发布才两周，该适配器目前已突破 50,000 次活跃安装。它把 WordPress 的 Abilities API 与 MCP 打通，使 Claude、ChatGPT 这类 AI 助手能够调用站点所开放的能力。
这一转向几乎是 180 度反转。就在宣布插件方案时，GoDaddy 的 Nik McLaughlin（AI 团队贡献者）曾表示 MCP 规范"仍在剧烈变动"，且近期刚刚发布过一次重大破坏性更新。
"这种波动性让 MCP 目前不适合被纳入 WordPress 核心包，"他写道，理由是核心拥有广泛的自动化分发渠道、自身的发布节奏，以及 WordPress 对向后兼容的承诺。McLaughlin 认为，把适配器留在核心之外，可以让贡献者快速迭代以跟上规范的步伐。
面对 Adams 的宣布，Automattic 的 Applied AI Code Wrangler Ovidiu Galatan 在 Slack 中回应——他与 Elementor 赞助的 AI 团队贡献者 David Levine 共同维护该适配器——他想知道到底什么变了。
"我们两周前才宣布 canonical 插件方案，明确以 MCP 的变动速度、以及 WordPress 的发布周期和兼容性承诺作为将其留在核心之外的理由，"他写道，"我认为我们需要清楚地说明究竟是什么发生了变化，以及插件方案解决不了哪些问题。"同时他也补充，如果适配器最终合入核心，"会让我非常自豪"。
版本目标：7.2 变 7.3，且只是"可能"
把 MCP 塞进 WordPress 7.2 曾被短暂讨论过，Automattic 赞助的贡献者 Anne McCarthy 曾在 7.2 发布负责人频道中支持设置例外。但在 Levine 提出时机方面的顾虑后，Adams 转向了 WordPress 7.3，并写道团队眼下需要"对安全问题保持高度谨慎，而赶进度恰恰无法做到这一点"。
会议记录将 7.3 描述为"一个可能的目标"，尚未做出发布承诺。
社区分歧：反对声与产品视角的反击
在 #core-ai 线程中，并非所有人都认可 MCP 应该进入 WordPress。ExtendStudio 的全栈开发者 Andrei Lupu 表示，一些并不想要 AI 工具的用户"根本没有选择（政府、银行等场景）"。
核心提交者 Tammie Lister 则从产品视角重构了这场争论：WordPress 已经发布了大量并非人人都会用到的功能，"而这正是套件式 CMS 的意义所在。用什么、或者不用什么，由你自己决定。MCP 只是其中之一。" Miles 创始人 Andy Peatling 表示，MCP 会默认关闭，并且在没有已认证会话的情况下不会暴露任何东西。他同时担忧，要求用户先安装插件代理才能帮忙处理站点，是"很大的阻力，很可能太多了"。
据会议记录，Woo 开发者布道师 Brian Coords 指出，导入器和连接器（importers/connectors）这类地方，WordPress 本来就会在后台静默安装插件；Automattic 赞助的核心提交者 Jorge Costa 则表示，打包分发可以绕开部分主机上限制插件安装的文件系统权限限制。
认证问题悬而未决
贡献者之间也讨论了认证方式，但未达成结论。Costa 认为 OAuth 应成为默认体验的一部分；Galatan 提出，在缺乏足够审查的情况下引入安全敏感功能存在隐患；Levine 则认为认证是更宏观的 WordPress 架构问题。在 Slack 公告中，Adams 暂时排除了通过 WordPress.org 提供 OAuth 的可能，称把它"放到 Dotorg 上会是过重的安全负担，需要严肃的思考和充分的探索时间"。
现实短板：适配器目前还帮不上什么忙
无论最终是打包还是原生开发，官方适配器本身目前都帮不了站点所有者太多。本月早些时候，Peatling 的 WordPress Agent Benchmarks 项目发现，AI 代理无法通过适配器完成哪怕一项站点所有者的日常请求——因为适配器尚未包含处理日常任务所需的能力。
在 #core-ai 中，他呼吁贡献者务必牢记用户今天实际体验到的"0% 得分"。上周，他甚至请求 AI 贡献者优先处理这项工作："如果这听起来有些危言耸听，我会暂停其他所有 AI 工作（核心 abilities 相关的除外），专注在这件事上。"
后续动作与第三方生态
Adams 目前正在起草一篇说明 MCP 在 WordPress 中拟议方向的文章，涵盖可能的实现方式和待解问题。他还与 Peatling 合作，准备一份覆盖更广的提案，涉及托管环境和"以代理为先"的建站方式。
与此同时，面向 WordPress 的第三方 MCP 工具已经快速兴起。
WordPress MCP 插件生态半年记：从 WPVibe 破圈到主机厂商集体入场
自今年 4 月上线以来，WPVibe 在 WordPress.org 上的活跃安装量已突破 9 万。评论者对这款插件的评价相当直接——称其为"必备"、"颠覆性"以及"WordPress 的一大步进步"。这个数字也说明，模型上下文协议（MCP）已经从开发者圈层的实验性话题，变成了 WordPress 站点运营者真正愿意安装的东西。
WPVibe 成为 MCP 生态的引爆点
WPVibe 的增长轨迹是这一轮 MCP 落地热潮里最醒目的案例。发布仅数月即拿下 9 万活跃安装，意味着大量站点在没有额外配置的情况下，就把 AI 能力接入了内容创作和管理流程。对插件生态而言，这样的安装量级足以改变开发者对"MCP 值不值得做"的基本判断。
插件厂商密集跟进：从独立插件到框架内置
在 WPVibe 之外，今年陆续上线的 MCP 相关插件还包括 Novamira、Royal MCP 和 Easy MCP AI。AI Engine 也把 MCP 纳入了自身功能范围。
这意味着 MCP 正在从"某个插件的附加特性"变成"插件的标准配置项"。目前至少有两种路径：一是独立插件专门承接 MCP 能力，二是原有插件把 MCP 整合进既有工作流。前者进入门槛低、见效快；后者则依托已有用户基础，迁移成本更低。
主机厂商开始提供自有 MCP 服务
更值得注意的是主机侧的动向。Pressable、Hostinger、Cloudways 和 Rocket.net 都已推出面向各自站点的 MCP 服务器。对用户来说，这意味着 MCP 不再只存在于插件层——可以直接接入主机环境，从服务器/主机层面调用站点数据和管理能力。
插件与主机两条路线同时推进，MCP 的接入点正在从"插件作者自行适配"转向"平台原生提供"。
对站点运营者的实际影响
- 想要尝鲜：WPVibe 安装量最大、生态反馈最充分，是目前风险最低的起点。
- 已有内容体系：可以优先考察 AI Engine 这类把 MCP 融入既有流程的插件，避免同时维护多个工具。
- 有主机迁移或续费计划：不妨在询价时直接确认该主机是否提供 MCP 服务器，这可能成为新的选型权重项。
对插件开发者而言，这轮窗口期已经打开：新增的 MCP 相关插件数量说明同类需求正在被分散消化，接下来比拼的是与 WordPress 核心能力的贴合度，以及和主机侧 MCP 服务的差异化定位。
