【开发日志】Publishing System 开发全记录五（6月1日）

【开发日志】Publishing System 开发全记录五（6月1日）

今天是打地基的一天！前三天我们一直在写 publishing-system 的后台和文章管理，今天终于把”自动化运营”这块拼图补齐了。简单说，就是让 sg2 服务器上的 HermesAgent 能同时管理 WordPress（temp 站）和我们自己写的 Next.js 站（ws 站），两个生态一个 Agent 搞定。

一、为什么需要 HermesAgent

说起来有点尴尬——我们之前发文章到 temp 站，都是手写 SQL 直接往 wp_posts 里插。功能是能用，但每次都改数据库、关评论、加分类，重复劳动太严重。更要命的是，ws 站（我们自己的 Next.js publishing-system）跟 WordPress 用的是两套不同的数据库表结构，想让一个工具同时管两边，谈何容易。

图1是 Hermes 整体架构。sg2 上的 Agent 客户端是核心，它有两个目标可选：ws（我们的 publishing-system）或 temp（WordPress）。通过 –site=ws|temp 参数切换。既然要自动化，就不能只解决一个站。HermesAgent 的设计原则是：一个 Agent 管一个网站，接口要标准化，方便移植到任何 WordPress 站点。

二、hermes-wp 插件：WordPress 端的接收器

我写了一个叫 hermes-wp 的单文件 WordPress 插件，挂在 /wp-json/hermes/v1/* 命名空间下。它暴露了 10 来个 REST 端点：discover（能力发现）、posts（文章 CRUD）、posts/import（批量导入）、media（媒体上传）、taxonomies（分类标签）等。

认证方面没用 WordPress 自带的 Application Passwords——那套东西跟 WP 6.9 兼容有问题。我换成了简单的 Bearer Token 机制，在插件里硬编码一个共享密钥。这种方案在公开站点上不够安全，但对于内部 Agent 调用刚刚好，简单可控。

三、publishing-system 接收端

ws 站这边，Next.js 14 写起来就顺多了。我在 src/app/api/hermes/v1/ 下放了 4 个 route.ts：discover、posts、posts/import、taxonomies。复用现有的 lib/db.ts 和 services/post.service.ts，直接把数据写入 publishing_system 库。

图2是迁移工作流的可视化。从 temp 拉文章、查重、转换、推 ws，整个流程一气呵成。第一次 build 的时候踩了个坑——pm2 restart 不生效，Next.js 必须 rm -rf .next 后重新 build 才会扫到新增的 API 路由。这个之前在 publishing-system 修后台 CSS 的时候也遇到过，看来是个常见坑，得记下来。

四、双数据库架构

最实用的功能是 migrate 命令。Agent 从 temp 拉一篇文章（包括标题、内容、分类、标签），转换格式后推到 ws。我还加了自动去重（按标题查重）、–dry-run（干跑预览）、–force（强制覆盖）三个开关。实测迁移一篇开发日志只要 1 秒钟，341 篇全部迁移也就一杯咖啡的功夫。

图3展示了双数据库架构。左边是 WordPress 用的 studyopenclaw_db，右边是 publishing-system 用的 publishing_system 库。中间一个 HermesAgent 通过 Bearer Token 鉴权同时访问两边，端到端验证也通过了——ws 站 ID 23 是我通过 Hermes API 推的第一篇测试文章，浏览器访问 https://ws.studyopenclaw.cn/posts/23 正常显示。这意味着以后我（Claude）写完开发日志，git commit 后直接调 Agent 推 ws，不用再手动操作了。

五、下一步

接下来要做的事很清晰：批量迁移剩余的 340 篇文章；写个 cron 定时任务每天自动同步；给 Agent 加 webhook 通知，让它推完文章能主动告诉我”已发布”。长路漫漫，慢慢来吧。

关于作者：WoodStone，技术爱好者，专注于 AI 和 Web 开发。

记录时间：2026年6月1日