WordPress 7.1新增Abilities API公开标志：统一支持REST API、MCP与AI代理-WordPress啦

WordPress 7.1 为 Abilities API 引入新的 meta.public 元数据标志，用于统一声明某项能力是否准备向外部客户端开放。REST API、MCP 适配器和 AI 代理等集成可以读取这个标志，判断相应能力是否适合被发现和调用。

这项变化主要面向插件开发者和集成服务开发者。它不会让网站现有功能自动公开，也不会代替用户身份验证和权限检查。

为什么要增加public标志？

此前，如果插件希望通过 REST API 公开某项能力，需要单独配置：

'meta' => array(
    'show_in_rest' => true,
),

随着 WordPress Abilities API 开始连接 REST API、MCP 和 AI 代理，仅依靠不同渠道各自设置公开状态，会产生重复配置。新加入的 public 提供了统一的默认值：

'meta' => array(
    'public' => true,
),

当 public 为 true 且没有单独设置 show_in_rest 时，这项能力默认可以通过 REST 能力端点被发现。未来其他客户端集成也可以读取相同标志，不必为每种渠道重新定义一套公开规则。

public 只是通用默认值，不会覆盖明确设置的渠道规则。REST API 的实际解析顺序为：

$show_in_rest = $meta['show_in_rest'] ?? $meta['public'] ?? false;

例如，某项能力通常面向外部客户端，但不希望通过 REST API 公开，可以这样设置：

'meta' => array(
    'public'       => true,
    'show_in_rest' => false,
),

反过来，一项通常不公开、但需要单独支持 REST API 的能力，也可以设置为：

'meta' => array(
    'public'       => false,
    'show_in_rest' => true,
),

只要设置了 show_in_rest，它就优先于 public。开发者因此可以先定义总体公开意图，再针对 REST、MCP 或其他渠道单独调整。

WordPress 特别强调，公开能力和执行权限是两件事。public 控制的是能力能否被客户端发现或公开展示，不是安全边界，也不会让未登录用户自动获得执行权限。

每项能力仍然需要配置适当的 permission_callback，例如：

'permission_callback' => function (): bool {
    return current_user_can( 'manage_options' );
},

即使某项能力设置了 public => true，客户端在真正调用时仍需通过身份认证和 WordPress 权限检查。插件不能使用 public 或 show_in_rest 代替授权逻辑。

这项变化保持向后兼容。原来使用 show_in_rest => true 的插件不需要立即修改，相关能力仍可按原方式通过 REST API 使用。

如果插件既没有设置 public，也没有设置 show_in_rest，其能力仍不会通过 REST API 对外提供。WordPress 7.1 只是会在解析后的元数据中补充布尔值：

'public' => false

当一项能力计划同时用于 REST API、MCP 和其他外部客户端时，可以考虑使用 public => true。如果能力只允许通过某个指定渠道公开，则继续使用该渠道的专用标志更合适。

WordPress 核心中的 core/get-site-info、core/get-user-info 和 core/get-environment-info 等能力已经改用 meta.public，但它们原有的 REST API 可用性不会改变。