做 WordPress 自动化时，很多开发者会同时接触到这三套工具，但容易把它们当成互相竞争的关系——选了 WP-CLI 就好像必须放弃 REST API。其实这是错误的理解方式。
正确思路是把它们想象成三层不同距离的接口，每层对应不同类型的调用者。WP-CLI 运行在服务器端，REST API 基于 HTTP 协议，而 Abilities API 则位于更上层，专门解决 AI 代理的权限感知问题。一旦理解了这个分层逻辑，"该用哪个"的问题就自然有了答案。
三套接口一览
| 维度 | WP-CLI | REST API | Abilities API |
|---|---|---|---|
| 运行位置 | 服务器端 | HTTP 协议层 | AI 代理层 |
| 调用方式 | 命令行/SSH | HTTP 请求 | 结构化能力描述 |
| 认证方式 | 服务器访问权限 | 应用密码/Cookie/OAuth | 插件注册的权限回调 |
WP-CLI：服务器端的命令行工具
WP-CLI 直接在服务器上运行 PHP 命令，常见操作包括 、 、 、 等。由于不需要 HTTP 请求往返，也不涉及 Token 管理，对于拥有服务器 Shell 访问权限的用户来说，这是操作自有站点最快的方式。
wp post createwp plugin updatewp search-replacewp db exportwp post create`、`wp plugin update`、`wp search-replace`、`wp db export` 等wp plugin update`、`wp search-replace`、`wp db export` 等wp search-replace`、`wp db export` 等wp db export` 等典型适用场景包括：批量迁移一千篇文章、跨域名数据库替换、计划维护任务、部署脚本编写等。论纯执行速度，没有任何其他方式能与之相比。
但代价也很明显：必须具备服务器 Shell 访问权限。WP-CLI 不是浏览器、手机 App 或远程服务访问站点的途径，以后也不会是。这是一套"你亲自坐在驾驶座"时使用的工具。
许多开发者已经完全在终端 + 无头前端的环境下完成日常工作，WP-CLI 正是让这种工作流变得舒适的基础。
REST API：基于 HTTP 的标准接口
REST API 将 WordPress 站点转化为任何 HTTP 客户端都可以读写的数据源。接口端点位于 /wp-json/wp/v2/ 下，支持应用密码、Cookie + Nonce、OAuth 等多种认证方式。无论浏览器、移动端 App 还是外部服务，都可以从互联网上任何位置获取和更新站点内容。
目前主流的无头 WordPress 架构都基于 REST API：Astro、Next.js 等前端框架通过 REST 获取内容，手机 App 通过 REST 提交数据，第三方服务通过 REST 进行数据同步。只要调用者不在服务器本地，REST 几乎始终是首选接入方式。
不过 REST 存在一个值得注意的局限：它暴露的是"资源"（文章、用户、分类、设置），而不是"操作意图"。调用方需要自己了解有哪些端点可用、如何组装正确的请求。对于人类开发者来说这不是问题，但对于 AI 代理，这意味着需要大量的前置学习和上下文理解。
Abilities API：面向 AI 代理的能力层
Abilities API 是三者中最新的一个。它随 WordPress 6.9 进入 WordPress 核心，早期版本可通过插件使用。这套接口恰好填补了 REST API 留下的空白：AI 代理如何知道自己可以在站点上做什么？
Abilities API 的核心思路是：不再暴露原始资源，而是让插件或主题注册"具名能力"。每个能力都是一个独立、有描述、ID 稳定、操作语义明确的单元，包含人类可读的标签、描述、输入输出 Schema 和权限校验。注册流程先在 wpabilitiesapicategoriesinit 钩子上注册分类，再在 wpabilitiesapi_init 钩子上注册具体能力：
