今天把 Hermes 路由和审计的问题彻底打通了。事情起因是昨天用户测试 ps-publisher skill 发布文章成功了,但 `/admin/hermes/audit` 页面里找不到任何记录,审计表里 6-12 之后就没新数据了。根因是 ps-publisher skill 调的是普通 `/api/posts`(cookie 认证),而 hermes 审计 hook 只挂在 `/api/hermes/v1/*` 路由上(HMAC 认证中间件里调 auditLog 函数),所以走普通 API 的调用从来不会进审计。

修法:不改后端代码,而是让 skill 改调带 HMAC 签名的 `/api/hermes/v1/posts` 端点。HMAC 签名机制在 server 端 `src/lib/hermes-auth.ts` 早就实现了,3 个协议头 + SHA256 签名,但 2 个 skill(ps-publisher 的 OpenClaw + Hermes 版本)从来没把签名算法写进文档。今天加了完整的 §四.六(OpenClaw)/§6.6(Hermes)章节:协议头、签名算法(Python + bash 完整代码示例)、字段差异对照表(普通 /api/posts vs hermes /api/hermes/v1/posts)、时间窗 ±300 秒防重放、字段映射规则(普通 category_id → hermes categories[]字符串数组等)。

同时把 2 个 skill 的”默认作者”统一成 WoodStone,OpenClaw skill 的 §四.5 和 Hermes skill 的 §6.5 示例都改了,agent 调 skill 发文章时 author_name 默认值就是 WoodStone(可改任意名字)。在测试时发现 sg1 服务器当前 IP `43.160.231.105` 不在 server 端 `.env.local` 的 `HERMES_ALLOWED_IPS` 白名单里,而且指纹 `day14-sg1-final` 也没在 `HERMES_CLIENT_KEYS` 列表里,这两个配置都加进去(用 LEGACY_TOKEN `hermes-shared-secret-2026` 当 key 做 SHA256 哈希),从 sg1 端调了一次 `POST /api/hermes/v1/posts` 用完整 HMAC 签名 + IP 白名单通过,返回 201 Created(post id=150),审计表里写入了新 record `id=447`, `result=success`, `client_ip=43.160.231.105`, `fingerprint=day14-sg1-final`,前台 `/posts/150` 显示 “by WoodStone”。整个改动已经在 hk 服务器上稳定运行,明天用户会测试 QClaw 本地 skill(OpenClaw 调普通 API 路径)做更广的端到端测试。
OpenClaw—AI研究