导语：WordPress 把 AI 的重心从"帮你写页面"挪到了"给 AI 发身份证、给凭证上锁"，但三条安全底座里只有一条真正落到了代码任务清单上——官方 MCP Adapter 插件的活跃安装已经到 6 万量级，比核心的权限模型跑得快。
变了什么：AI 撤出 Core，安全顶上来
2026 年 11 月 3 日，WordPress 7.2 Beta 4 发布，正式版定档 2026 年 12 月 8 日（来源：wordpress.org/news，查询日期 2026-11-10）。这一版最值得关注的不是区块编辑器，而是路线图里被拆成两半的野心。
第一半是 AI。官方在 7.2 路线图里明确写了：7.1 周期已经定调，AI 功能必须先证明"真实采用与实用价值"才考虑进 Core，因此 7.2 的所有 AI 工作都在官方 AI 插件中推进，不保证进入核心。细项包括：把 MCP Adapter 追到最新 MCP 规范（同时让 WordPress Ability 定义与协议版本解耦）、让管理员在 AI 插件里一键开启 MCP 并控制暴露哪些 ability、WebMCP 浏览器内 Agent 实验，以及最关键的 Agent identity and delegation——为 Agent 设计可审计的身份、独立于人类账号管理的权限模型。
第二半是安全，也是 7.2 真正想动地基的地方，三条线并行：
| 安全项 | 官方口径（2026-09-18 路线图） | 落地状态判断 |
|---|---|---|
| Application Passwords 加固 | 已列出具体任务：新增应用密码发邮件通知、非 HTTPS 站点误判"开发环境"修正、禁止 default_role 被设为危险值、支持 SameSite Cookie 属性、HTML 处理加固 | 已进入任务清单，7.2 周期内推进 |
| Secrets API | 2026-08-25 单独提案：加密存储凭证、网络根密钥经 sodium_crypto_kdf_derive_from_key() 派生每站点子密钥、wp_import_option_as_secret() 手动导入并标记轮换、值只写不可导出、外部密钥后端不可达时 fail closed、明文不进对象缓存 | 提案阶段，WP-CLI 先行，后台 UI 明确"留待后续版本" |
| Sudo mode | 原话是"Initial work is starting on the possible introduction"——用二次认证给高权限操作上锁 | 起步阶段，提案与协作文档官方称"稍后发布" |
此外，Beta 4 里已能看到开发侧的连带变化：Abilities API、DataViews 扩展性、REST API 行为与输入校验都在改。这些是 Agent 读写站点的地基，比"AI 一键建站"这种口号更实务。
为什么重要：凭证早就比人多了
现在跑在 WordPress 上的自动化，绝大多数拿的是 Application Password + REST API——包括定时采集、跨站同步、发布机器人、以及各类 MCP 客户端。这套凭证的问题很具体：它默认长期有效、权限等同账号、存放与轮换全靠人记。
Secrets API 提案里有句判断值得抄给所有站长："一个在 wp_options 里躺过的凭证，已经进了备份、副本和对象缓存，现在给它加密并不能改变这个事实——轮换才是真正的修复。" 所以提案给导入接口设计了"导入即标记待轮换"的语义，而不是导入成功就完事。
同时，生态那边已经不是"要不要接 Agent"的问题了，而是"接了多少套"：
| 插件（插件目录官方数据，查询日期 2026-11-10） | 活跃安装 | 最近更新 |
|---|---|---|
| Jetpack – AI Agents & MCP, Security, Backup & Analytics | 300 万+ | 2026-11-03 |
| WPVibe – MCP Server for WordPress | 10 万 | 2026-11-05 |
| AI Engine – MCP Server & AI Chatbot | 9 万 | 2026-11-06 |
| 官方 MCP Adapter（v0.7.1） | 6 万 | 2026-10-16 |
| 官方 AI 插件（v1.5.0） | 6 万 | 2026-10-30 |
| Uncanny Automator – MCP Server + Automation | 4 万 | 2026-11-06 |
| Easy MCP AI（Themeisle，v 未披露于查询结果） | 3 万 | 2026-11-05 |
| miniOrange MCP / Royal MCP | 各 1 万 | 2026-11-09 |
结论很直接：接口层已经铺满，权限与密钥层还是空的。谁都能给自己的站装一个 MCP Server，但没有任何一方能说清"这个 Agent 以什么身份、在什么审计下、持有多久的凭证"。这正是 sudo mode 与 Agent identity 要回答的问题，也是它们至今没定稿的原因——一旦写进 Core，改起来就是全生态的迁移成本。
对站长和开发者的动作项
清点 Application Passwords，今天就做。后台「用户 → 个人资料」逐账号核对，把"看不出用途"的全部吊销。7.2 之后新增应用密码会发邮件通知，但通知只解决"事后知道"，不解决存量。
把 API Key 从
wp_options里挪出来。在 Secrets API 落地前，至少不要写进主题文件或数据库明文字段；能改用环境变量（wp-config.php外置）的先改。审计"非 HTTPS 开发环境"的站点。7.2 要修的正是这条误判路径——如果你有站点靠这个开关在跑应用密码，升级前先确认自己的场景还能用。
别把 Beta 4 装进生产。官方明确 Beta 仅用于测试；正式版 12 月 8 日，留给主题/插件作者的时间只剩一个月。
盯 RC 而不是盯博客。AI 相关条目官方写明"不保证进 7.2"，Sudo mode 连提案链接都还没补；判断某功能是否真的到货，要看 RC 与 Trac，不看路线图。
版本与风险
| 项 | 内容 |
|---|---|
| 版本号 | WordPress 7.2 Beta 4（正式版目标 7.2） |
| 发布日期 | Beta 4：2026-11-03；正式版计划：2026-12-08 |
| 影响版本 | 面向 7.2 及以后；7.1.x 现有站点不受影响 |
| 风险等级 | 低（非安全通告，属架构预览）；但 Secrets API / Sudo mode 一旦落地会改变现有自动化脚本的认证方式，属行为破坏性变更，未披露具体等级 |
| 数据口径 | 插件安装量为 WordPress.org 插件目录 active_installs 区间值，查询日期 2026-11-10；路线图条目以 2026-09-18 官方发布为准 |
立场
WordPress 这次的选择是对的：在 Agent 大规模写入站点之前，先把身份和凭证管起来，比再发十个"AI 建站"功能更值钱。但节奏是落后的——第三方 MCP 插件已经在 600 万级安装量上跑（含 Jetpack 的 300 万），核心的策略却还有一条停在"possible introduction"。接口先行、治理补票，这是开源生态的常态，也是它最大的安全隐患：等到 Core 定稿那一天，得让几百万站点改认证方式。
对内容站运营者而言，最务实的判断是：7.2 不是"AI 功能升级包"，而是一次"自动化凭证的强制体检"。12 月 8 日之前把该吊销的吊销、该轮换的轮换，比追任何一个新功能都划算。