深色模式
把 WordPress 博客接到 AI：MCP 安装、只读授权与文章检索实录
我一直把折腾软路由、服务器和软件的过程记在博客里。文章越来越多之后，新的问题出现了：我记得自己写过，却不一定想得起标题；想让 AI 帮忙复盘，还要先找文章、复制正文，再解释背景。
于是，我尝试给 WordPress 接上 MCP，让博客继续负责保存原始资料，AI 软件在需要时自己去找文章、读全文，再带着来源链接回答。这篇记录的是 2026 年 11 月 3 日至 4 日的一次真实配置：从官方 MCP Adapter，到补充文章读取能力，再切换到 Agent Abilities for MCP，最后验证客户端确实读到了文章。
先弄清楚：我需要的是一个能查资料的入口
用图书馆来理解最容易：WordPress 是书库，文章是书，MCP 是服务窗口，AI 是来查资料的读者。窗口能不能找书、拿出全文，取决于窗口后面有没有这些服务。接通窗口，不等于 AI 已经读完并永久记住了全部藏书。
我没有在网站上放一个面向访客的聊天框。实际流程是：我在 AI 软件里提问，AI 通过 MCP 搜索博客，读取相关原文，然后整理答案。负责思考的大模型运行在 AI 软件那一端，因此，单纯提供这些读取工具的 WordPress 不需要再配置大模型 API Key。连接网站仍然需要身份认证，AI 软件本身也仍有自己的账号、套餐或模型费用。
还有一个容易混淆的名字：最初本机 Codex 配置中的 sirenyan_blog，只是我给这条 MCP 连接起的名字。它不是技能，也不是另外一个大模型。后来通过插件方式接入时，客户端显示的连接名称可以不同，真正决定访问哪里的是 Endpoint 和授权。
为什么装好了 MCP Adapter，还不能查询文章？
我最初已经安装了官方 MCP Adapter。实际检查时，网站运行的是 WordPress 7.1.4、MCP Adapter 0.7.1，有 122 篇已发布文章，但当时注册的主要是站点、用户、环境信息，以及能力发现和执行工具，没有搜索文章、读取全文的能力。
WordPress 的 Abilities API 用来描述“这个网站能做什么”，Adapter 把这些能力接到 MCP 客户端。它是连接层，不会凭空补齐每一种业务功能。官方开发介绍也说明了这套关系：WordPress MCP Adapter 的工作方式。
为了先验证方向，我增加过一个独立 MU 插件，提供文章搜索、全文读取、分类标签查询。MU 插件是 WordPress 自动加载的站点扩展，并不天然等于临时脚本。这次扩展直接查询现有文章，没有建知识库表，也没有复制或修改文章。官方 Adapter 的源码没有被修改。
不过，“没有改文章”不等于“数据库完全没有写入”：为 AI 创建专用用户、设置权限、生成应用密码，都会在 WordPress 现有账户相关表里留下数据。这个区别值得说清楚。
接下来，我换成了有后台管理的现成插件
基础读取跑通之后，我想要完整文章列表、分页、权限开关和调用日志，而不是长期只靠三个自定义工具。于是选择了 Agent Abilities for MCP 做实际测试，作者是 Unaib Amir。记录时安装的版本为 1.10.0。
它建立在 WordPress Abilities API 和官方 MCP Adapter 之上，并提供自己的受控接口。插件自带 Adapter，不能简单认为“再装一个功能包，原来的 Endpoint 就自动变成新插件的接口”。工具和权限都需要在新接口下重新验收。安装时也应核对它与已有 Adapter 的兼容说明，不要直接删除仍在使用的连接。
我的博客结构还有一个特殊点：
wp.sirenyan.cn是 WordPress 后台、内容源和 MCP 服务所在。sirenyan.cn是 Cloudflare 与 GitHub 构建链路提供的静态阅读前台。
因此 MCP 连接的是 WordPress 域名，回答里给读者的文章链接则应该是静态前台地址。普通 WordPress 网站如果后台与前台使用同一域名，不必照搬这一步。
第一步：安装，并先把范围限制为读取
- 在 WordPress 插件目录搜索 Agent Abilities for MCP，核对作者后安装、启用。安装前先检查 WordPress/PHP 要求，并保留可恢复的备份。
- 打开插件的快速连接向导，在第一步选择需要的认证方式。我后续测试了 OAuth；本机原有连接也使用过独立用户的应用密码。
- 第二步保留 Read content，关闭 Create and edit content。完成后确认后台显示 Read-only。
- 检查新连接的默认范围，以及 Abilities 页实际开启的项目。只开放这次任务要用的内容查询工具。
- 完成向导，再查看 Connection 和 Activity Log。后台出现 Endpoint live 只说明入口启用，还需要客户端发起真实调用。
我这次的新接口是：
txt
https://wp.sirenyan.cn/wp-json/agent-abilities-for-mcp/mcp读写开关、连接范围和 WordPress 用户权限需要一起看。长期使用，我倾向于专用低权限账户，而不是把管理员账户交给日常检索任务。此次本机专用账户是订阅者角色，不能编辑文章或管理插件。后续 OAuth 连接则要单独核对授权所使用的账户，不能把一个连接的权限结论套到所有连接上。
这里说的“我的知识库”，描述的是用途。此次验证覆盖的是已发布内容，不代表已经开放 WordPress 的 private 状态文章。原有只读账户请求草稿列表时，被插件拒绝了。
第二步：把 AI 客户端接到新 Endpoint
本机 Codex 先使用专用账户的应用密码连接，凭据通过 Windows 当前用户加密保存。切换插件时，我备份了配置，更新 Endpoint，并实际测试了初始化、工具清单和正文读取。配置文件能被解析，不等于正在运行的旧聊天立刻刷新工具；我还需要在客户端重新加载后确认工具是否出现。
后来在 PC 客户端又完成了 OAuth 接入。对支持自定义远程 MCP 与 OAuth 的客户端，操作思路是：添加自定义连接，填写上面的 Endpoint，选择 OAuth，跳转到 WordPress 登录授权，再回到 AI 软件确认工具可用。入口名称与可用范围会随软件版本、账号和工作空间变化，不能把一张截图当成所有平台通用的界面教程。
OAuth 可以理解为给某个客户端发放可撤销的通行证。我不需要把管理员登录密码抄进连接配置，也不应该把一个客户端的 token 复制给另一个客户端。多个 AI 软件可以访问同一个网站入口，但应分别完成授权。
本机 Codex 的 MCP 配置与托管网页聊天的插件连接，也要分开理解。网页端不会因为电脑上有一份本地配置，就自动获得同样的工具。相关配置方式可以参考 官方 MCP 文档。
第三步：用真实调用验收，别只看绿色状态
我的验收从一个很具体的问题开始：
通过博客 MCP 搜索 R4S 旁路由的相关文章，读取原文后整理配置方法，并附上来源链接。不要修改网站数据。
服务器与本机独立客户端都测试过文章搜索和全文读取。新插件搜索 R4S 返回 6 篇文章；单篇读取成功返回《Q3000 + R4S 方案 B 快速上手》的原始正文。
我还专门测试了全站文章列表：按每批 50 篇分页，三批分别返回 50、50、22 篇，合计 122 篇，去重后的文章 ID 也是 122 个，与当时接口报告的总数一致。这个结果证明文章清单可以完整遍历，不能进一步推导成“122 篇全文已经全部分析过”。这是两项不同的验收。
批量读取的初次测试曾出现超时，后续复测通过。我没有为了让测试看起来顺利而略去它。真正做全站分析时，应该保存进度、记录失败、使用较小批次，并检查重试后的覆盖情况。
随后，我又对照了从后台导出的原始 Activity Log。里面能找到 OAuth 注册、授权、令牌签发成功，以及 aafm/get-posts、aafm/search-content、aafm/get-post 的成功记录。PC 客户端确实发起过文章查询，而不只是 AI 在回答中声称“我已经查了”。搜索还出现过零结果记录，这同样是正常且有用的证据。
日志里的配置写入事件也不能混同为文章被改动。日志用于逐项核对操作，不宜仅凭出现一个 write 字样就判断 AI 改了正文。本文不公开原始日志、账户标识或授权截图，避免把排查材料变成凭据和个人信息的泄露入口。
静态博客的额外一步：让引用链接真正能打开
新插件起初通过 WordPress 获取文章永久链接，返回的是 wp.sirenyan.cn 下的地址。但我的读者实际访问的是：
txt
https://sirenyan.cn/posts/文章ID我增加了一个很小的站点适配 MU 文件，使用 WordPress 的 post_link 标准过滤器，仅在新 MCP 请求路径下转换文章引用地址。它不承担搜索，也没有修改第三方插件源码。复测确认文章工具已经返回正确的公开链接。
这也是采用现成插件后仍可能需要少量站点适配的原因：插件负责通用查询，网站自己的 Headless 路由需要自己对齐。我暂时保留了旧接口及配套文件用于回滚，日常连接已切换到新插件。
为什么 PC 能用，网页却没有显示？
这次实际遇到了这种情况：PC 已经能查文章，另一个网页会话里却没有看到对应连接。排查过程中，我发现 PC 与网页可能登录了不同的 ChatGPT 账号，这是一个合理的疑点，但当时没有把两端身份和全部平台状态核验到足以认定唯一原因的程度。
我现在会按顺序检查：登录账号是否一致、工作空间是否一致、连接是否在当前平台可用、是否需要重新授权，以及当前聊天能否完成一次真实文章读取。同一个账号也不等于任何平台、任何执行环境都必然同步。
如果需要在另一个账号或客户端添加连接，通常是让它再次连接同一个 MCP 服务，而不是在 WordPress 重复安装插件。每一端都应独立授权，再用后台日志核对调用。
想接 WorkBuddy，可以沿用入口，但我还没完成实测
腾讯的 WorkBuddy MCP 文档提供了可视化配置入口，也介绍了用户级和项目级配置；英文 MCP 指南说明支持标准 OAuth。
所以后续可以在实际版本的自定义 MCP/连接器界面中，尝试添加同一个远程 Endpoint，再独立完成 OAuth 授权。但我尚未验证它与这套 WordPress 插件的完整兼容性，不会把一段猜测的 JSON 当作已经跑通的配置教程。验收仍然要落到工具发现、文章搜索、全文读取和后台日志上。
能查到相关文章，离全站研究还差什么？
关键词搜索适合快速找资料，但“旁路由”可能漏掉只写“网络分流”的内容。语义检索可以帮助找意思相近的资料，也不能保证找全。需要全量检查时，我会让 AI 先取完整清单，再逐篇或分批阅读，并保存中间结论。
比如，我可以这样交代任务：
列出全部已发布文章，核对总数与唯一 ID 数量。分批读取网络教程，整理主题、重复内容和可能过时的配置。记录每批进度与失败文章，最终说明实际读取了多少篇，并为结论附上原文链接。
对于有数百个产品的公司网站，也可以沿用“结构化数据提供给 AI”的方向，但产品查询要另做验收：型号、材质、克重、幅宽、用途究竟存在独立字段里，还是散落在描述中？插件能否读取并按这些字段筛选？此次个人博客跑通，不代表公司产品系统已经完成接入。
文章可以继续按熟悉的方式写在 WordPress 里。此次真正增加的，是一个经过认证、能追溯调用、能够取回原文的访问入口。以后我问 AI 一个旧问题，不必先自己把所有资料找齐；但“找到了哪些、读了多少、结论来自哪里”，仍然应该能够核对。