memory/2026-03-11.md

# 2026-03-11

- 清理 Mac mini 主实例 `/models` 展示：目标只保留有用模型组。
- 检查 live config 确认 `models.mode = "replace"`，provider 仅有 `newcli / gptclub / cliproxy / baiduqianfancodingplan`。
- 为常用模型补充 `agents.defaults.models` alias：千帆、Opus、Sonnet、GPT-5.4、NewCli Opus、NewCli Sonnet、GPTClub Sonnet 等。
- 应用配置并重启 OpenClaw 后，用户反馈"好了"。
- 经验：`/models` 想只显示有用"模型组"，核心先看 `models.providers` + `models.mode=replace`；`agents.defaults.models` 主要用于 alias/展示精简，不是决定 provider 组数量的第一开关。
- 火山方舟：用户登录并购买了 Coding Plan Pro（49.9 元/月）；套餐页显示可用/推荐模型含 Doubao-Seed-2.0-pro、Doubao-Seed-2.0-lite、Doubao-Seed-Code、Kimi-K2.5、GLM-4.7、DeepSeek-V3.2 等。
- 已为 Mac mini 主实例接入火山方舟 provider `volcengine`，baseUrl 为 `https://ark.cn-beijing.volces.com/api/v3`，API 类型按 OpenAI 兼容方式配置。
- 用户最终只要豆包 `Seed 2.0 Pro`；已确认其真实 model id 为 `doubao-seed-2-0-pro-260215`，并把火山 provider 收口为仅保留这一项，alias 为"豆包 Seed 2.0 Pro"。
- 火山方舟 56 个模型一键开通成功（通过控制台"一键开通所有模型"按钮）
- 购买 Coding Plan Lite 套餐（首月 8.9 元，续费 40 元/月，到期 2026-04-11），同时有 Pro 权益
- Coding Plan 可用模型: Seed 2.0 Code(已启用) / Seed 2.0 Pro / Lite / Seed Code / MiniMax-M2.5 / Kimi-K2.5 / GLM-4.7 / DeepSeek-V3.2
- 新增 6 个模型接入 OpenClaw volcengine provider（共 7 个）:
  - doubao-seed-2-0-lite-260215 (豆包 Seed 2.0 Lite)
  - doubao-seed-2-0-mini-260215 (豆包 Seed 2.0 Mini)
  - doubao-seed-2-0-code-preview-260215 (豆包 Code)
  - deepseek-v3-2-251201 (DeepSeek V3.2)
  - glm-4-7-251222 (GLM-4.7)
  - kimi-k2-250905 (Kimi K2)
- API 测试全部通过（Seed 2.0 Code / DeepSeek V3.2 / GLM-4.7）
- 配置已更新并重启 OpenClaw
- Bero(45.82.120.52) 承接 netcup 的 `mjjtop.com` / `substore.mjjtop.com` 迁移时，最初只起了新的 Gitea 容器和 HTTPS，遗漏了原 Gitea 数据卷，导致 `mjjtop.com` 实际显示 Gitea 安装页。
- 排查确认：netcup 上原 Gitea 数据仍完好，位于 Docker volume `gitea_gitea-data`（`/var/lib/docker/volumes/gitea_gitea-data/_data`），`INSTALL_LOCK=true`，仓库页正常。
- 修复：停止 Bero 上空的 Gitea，清空其空 volume，把 netcup 的 `gitea_gitea-data` 原样流式同步到 Bero，再重启容器。
- 修复后验收：`https://mjjtop.com/` 正常进入 Gitea 首页，`https://mjjtop.com/admin/sub-bot` 可正常打开仓库页；问题根因是“域名/证书通了，但 Gitea 数据卷没迁”。
- 补充提醒：Gitea 仓库除服务端数据卷外，Mac 本地还有脚本备份目录 `~/.openclaw/workspace/scripts/gitea-backup/`；按既有约定，改脚本后应保持 Gitea + GitHub + Mac备份 三处同步。这次恢复优先用了 netcup 的在线 Gitea 数据卷，后续仍应把 Mac 本地备份作为额外兜底来源一起核对。
- 随后本机核查发现：`/Users/jianzhang/.openclaw/workspace/scripts/gitea-backup/` 当前为空或没有现成仓库内容，说明“Mac 本地 Gitea 备份”这条规则目前未真正落地，后续需要从现有 Gitea/GitHub 重新补齐本地镜像备份。
- 已重新从 `https://mjjtop.com/admin/*.git` 补齐 Mac 本地 `scripts/gitea-backup/` 的 7 个仓库：`oc-monitor / dd-reinstall / ss-rust / tcp-bbr / tg-user-monitor / sub-bot / vps-snapshot`。
- 长期记忆已同步更新：Gitea 主位置改为 Bero `45.82.120.52`；脚本同步规则明确为 **Bero Gitea + GitHub + Mac备份**。
- 收尾检查：Bero 上 `sub-bot / news-bot / vps-reminder` 均为 enabled+active；`mjjtop.com`、仓库页和短链 `/oc /dd /ss /bbr /bk` 均正常。
- 收尾检查：netcup 上旧 `sub-bot / news-bot / vps-reminder` 已 disabled+inactive，旧 `gitea` 容器也已手动停止，避免双活。
- `substore.mjjtop.com` 的 Bero nginx 真实上游为 `http://127.0.0.1:18888`，不是先前误查的 5001/5002/5003；当前根路径返回 404 更像应用自身路由行为，不是反代未通。
- 进一步实测确认：`substore` 正常订阅地址必须带 secret，形如 `https://substore.mjjtop.com/{default_secret}/download?target=ClashMeta`；Bero 本机 `127.0.0.1:18888/{secret}/download?target=ClashMeta` 与公网 HTTPS 均返回 `200` 和有效 YAML，根路径 `/` 的 `404` 属正常行为。
- `news-bot` 的 36氪异常不是迁移问题，而是 Bero 出口 IP 被 36kr 整站风控：`https://36kr.com/api/newsflash?per_page=20` 返回 `200 text/html` 验证码页，`https://36kr.com/feed` 在 Bero 上也返回验证码页而不是 RSS。
- 已临时修改 Bero `news-bot` 的 `fetch_kr36()`：先试 API，失败再试 RSS；若 RSS 也被风控，则记录 warning 并静默跳过 36氪源，避免持续抛解析错误影响整体日志，其它新闻源继续正常工作。
- 再次单独复核 Bero Gitea：容器 `gitea/gitea:latest` 正常运行，`127.0.0.1:3001/`、`https://mjjtop.com/`、仓库页、raw 文件、`git ls-remote` 及 SSH 端口 `2222` 均正常；`app.ini` 关键项为 `ROOT_URL = https://mjjtop.com/`、`DOMAIN = mjjtop.com`、`SSH_PORT = 2222`。
- N100（通过 `157.254.53.55:22288`）晚间实查：OpenClaw 实际安装/运行一度存在双路径冲突，`/usr/lib/node_modules/openclaw` 已是 `2026.3.8`，但 `/usr/local/lib/node_modules/openclaw` 仍是 `2026.3.7`，导致 PATH 命中旧版、出现“配置写入版本新于运行版本”的提示。
- 已对 N100 做版本收口：统一让 `/usr/bin/openclaw` 与 `/usr/local/bin/openclaw` 都指向 `2026.3.8`，systemd user service 实际运行版本确认已切到 `OpenClaw 2026.3.8 (3caab92)`。
- N100 稳定性加固：补了 `~/.config/systemd/user/openclaw-gateway.service.d/override.conf`，加入 `PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin`、`NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache`、`OPENCLAW_NO_RESPAWN=1`；同时收紧 `/root/.openclaw` 为 `700`、`/root/.openclaw/openclaw.json` 为 `600`。
- N100 当前核心状态：gateway/heartbeat/Telegram provider 均能正常启动，`@aibot444_bot` 可正常收发消息；但日志仍可见 `Polling stall detected` 与 `sendChatAction failed: Network request ... failed`，后续若再抽风，应优先查 Telegram 网络链路/出口/DNS，而不是 OpenClaw 版本本体。
- N100 中文 Telegram 菜单已通过 `/root/.openclaw/workspace/scripts/fix-telegram-menu.sh` + `/root/.openclaw/workspace/HEARTBEAT.md` 固化，按默认 heartbeat 周期约每 30 分钟自动补一次菜单。
- Mac mini 上 `peekaboo` 已最终打通：`peekaboo permissions` 显示 Screen Recording / Accessibility 均为 `Granted`，`peekaboo list apps --json` 成功，`peekaboo see --annotate --path /tmp/peekaboo-see.png` 成功生成截图与标注图。
- 这次排查确认：brew 安装的 `peekaboo` 公式只装 CLI，不自带 `Peekaboo.app`；本机无 `Peekaboo.app` / `Claude.app` / `Clawdis.app` bridge host，`peekaboo bridge status` 走的是 `selected.source = "local"`。
- Mac mini 主实例当前承载 `peekaboo` 调用的宿主链是 `launchd -> ai.openclaw.gateway -> /opt/homebrew/opt/node@22/bin/node -> /opt/homebrew/lib/node_modules/openclaw/dist/index.js`，不是 Terminal 直接前台运行。
- 经验/教训：以后排 Peekaboo 权限不要先入为主逼用户找错对象；应先查 `peekaboo bridge status` 和实际进程宿主，再判断该授权哪个主体。对这台 Mac，已确认现在 Peekaboo 可用，后续可直接用于 macOS GUI 自动化。
- Safari / 火山登录这次实战结论：对 Safari，单纯用 Peekaboo 做键鼠模拟不稳，容易卡在焦点、菜单栏或页面前端未真正吃值；更稳的方法是 `AppleScript + Safari do JavaScript`，直接控制标签页、读 DOM、给输入框赋值并触发真实前端事件。
- 浏览器控制经验：若是 Chrome 且已接 OpenClaw Browser Relay，首选内置 browser 工具（最稳、结构化、可读状态）；若目标明确要求 Safari 或系统原生浏览器页面，优先用 Safari 的 AppleScript+JS 方案；Peekaboo 更适合兜底的 macOS 原生 GUI 操作，不应作为网页表单自动化的第一选择。
-												Rename to hkt.sh

											
										
										
											2026-03-21 01:10:53 +08:00
+								# 2026-03-11
 								- 清理 Mac mini 主实例 `/models` 展示：目标只保留有用模型组。
 								- 检查 live config 确认 `models.mode = "replace"`，provider 仅有 `newcli / gptclub / cliproxy / baiduqianfancodingplan`。
 								- 为常用模型补充 `agents.defaults.models` alias：千帆、Opus、Sonnet、GPT-5.4、NewCli Opus、NewCli Sonnet、GPTClub Sonnet 等。
 								- 应用配置并重启 OpenClaw 后，用户反馈"好了"。
 								- 经验：`/models` 想只显示有用"模型组"，核心先看 `models.providers` + `models.mode=replace`；`agents.defaults.models` 主要用于 alias/展示精简，不是决定 provider 组数量的第一开关。
 								- 火山方舟：用户登录并购买了 Coding Plan Pro（49.9 元/月）；套餐页显示可用/推荐模型含 Doubao-Seed-2.0-pro、Doubao-Seed-2.0-lite、Doubao-Seed-Code、Kimi-K2.5、GLM-4.7、DeepSeek-V3.2 等。
 								- 已为 Mac mini 主实例接入火山方舟 provider `volcengine`，baseUrl 为 `https://ark.cn-beijing.volces.com/api/v3`，API 类型按 OpenAI 兼容方式配置。
 								- 用户最终只要豆包 `Seed 2.0 Pro`；已确认其真实 model id 为 `doubao-seed-2-0-pro-260215`，并把火山 provider 收口为仅保留这一项，alias 为"豆包 Seed 2.0 Pro"。
 								- 火山方舟 56 个模型一键开通成功（通过控制台"一键开通所有模型"按钮）
 								- 购买 Coding Plan Lite 套餐（首月 8.9 元，续费 40 元/月，到期 2026-04-11），同时有 Pro 权益
 								- Coding Plan 可用模型: Seed 2.0 Code(已启用) / Seed 2.0 Pro / Lite / Seed Code / MiniMax-M2.5 / Kimi-K2.5 / GLM-4.7 / DeepSeek-V3.2
 								- 新增 6 个模型接入 OpenClaw volcengine provider（共 7 个）:
 								  - doubao-seed-2-0-lite-260215 (豆包 Seed 2.0 Lite)
 								  - doubao-seed-2-0-mini-260215 (豆包 Seed 2.0 Mini)
 								  - doubao-seed-2-0-code-preview-260215 (豆包 Code)
 								  - deepseek-v3-2-251201 (DeepSeek V3.2)
 								  - glm-4-7-251222 (GLM-4.7)
 								  - kimi-k2-250905 (Kimi K2)
 								- API 测试全部通过（Seed 2.0 Code / DeepSeek V3.2 / GLM-4.7）
 								- 配置已更新并重启 OpenClaw
 								- Bero(45.82.120.52) 承接 netcup 的 `mjjtop.com` / `substore.mjjtop.com` 迁移时，最初只起了新的 Gitea 容器和 HTTPS，遗漏了原 Gitea 数据卷，导致 `mjjtop.com` 实际显示 Gitea 安装页。
 								- 排查确认：netcup 上原 Gitea 数据仍完好，位于 Docker volume `gitea_gitea-data`（`/var/lib/docker/volumes/gitea_gitea-data/_data`），`INSTALL_LOCK=true`，仓库页正常。
 								- 修复：停止 Bero 上空的 Gitea，清空其空 volume，把 netcup 的 `gitea_gitea-data` 原样流式同步到 Bero，再重启容器。
 								- 修复后验收：`https://mjjtop.com/` 正常进入 Gitea 首页，`https://mjjtop.com/admin/sub-bot` 可正常打开仓库页；问题根因是“域名/证书通了，但 Gitea 数据卷没迁”。
 								- 补充提醒：Gitea 仓库除服务端数据卷外，Mac 本地还有脚本备份目录 `~/.openclaw/workspace/scripts/gitea-backup/`；按既有约定，改脚本后应保持 Gitea + GitHub + Mac备份 三处同步。这次恢复优先用了 netcup 的在线 Gitea 数据卷，后续仍应把 Mac 本地备份作为额外兜底来源一起核对。
 								- 随后本机核查发现：`/Users/jianzhang/.openclaw/workspace/scripts/gitea-backup/` 当前为空或没有现成仓库内容，说明“Mac 本地 Gitea 备份”这条规则目前未真正落地，后续需要从现有 Gitea/GitHub 重新补齐本地镜像备份。
 								- 已重新从 `https://mjjtop.com/admin/*.git` 补齐 Mac 本地 `scripts/gitea-backup/` 的 7 个仓库：`oc-monitor / dd-reinstall / ss-rust / tcp-bbr / tg-user-monitor / sub-bot / vps-snapshot`。
 								- 长期记忆已同步更新：Gitea 主位置改为 Bero `45.82.120.52`；脚本同步规则明确为 **Bero Gitea + GitHub + Mac备份**。
 								- 收尾检查：Bero 上 `sub-bot / news-bot / vps-reminder` 均为 enabled+active；`mjjtop.com`、仓库页和短链 `/oc /dd /ss /bbr /bk` 均正常。
 								- 收尾检查：netcup 上旧 `sub-bot / news-bot / vps-reminder` 已 disabled+inactive，旧 `gitea` 容器也已手动停止，避免双活。
 								- `substore.mjjtop.com` 的 Bero nginx 真实上游为 `http://127.0.0.1:18888`，不是先前误查的 5001/5002/5003；当前根路径返回 404 更像应用自身路由行为，不是反代未通。
 								- 进一步实测确认：`substore` 正常订阅地址必须带 secret，形如 `https://substore.mjjtop.com/{default_secret}/download?target=ClashMeta`；Bero 本机 `127.0.0.1:18888/{secret}/download?target=ClashMeta` 与公网 HTTPS 均返回 `200` 和有效 YAML，根路径 `/` 的 `404` 属正常行为。
 								- `news-bot` 的 36氪异常不是迁移问题，而是 Bero 出口 IP 被 36kr 整站风控：`https://36kr.com/api/newsflash?per_page=20` 返回 `200 text/html` 验证码页，`https://36kr.com/feed` 在 Bero 上也返回验证码页而不是 RSS。
 								- 已临时修改 Bero `news-bot` 的 `fetch_kr36()`：先试 API，失败再试 RSS；若 RSS 也被风控，则记录 warning 并静默跳过 36氪源，避免持续抛解析错误影响整体日志，其它新闻源继续正常工作。
 								- 再次单独复核 Bero Gitea：容器 `gitea/gitea:latest` 正常运行，`127.0.0.1:3001/`、`https://mjjtop.com/`、仓库页、raw 文件、`git ls-remote` 及 SSH 端口 `2222` 均正常；`app.ini` 关键项为 `ROOT_URL = https://mjjtop.com/`、`DOMAIN = mjjtop.com`、`SSH_PORT = 2222`。
 								- N100（通过 `157.254.53.55:22288`）晚间实查：OpenClaw 实际安装/运行一度存在双路径冲突，`/usr/lib/node_modules/openclaw` 已是 `2026.3.8`，但 `/usr/local/lib/node_modules/openclaw` 仍是 `2026.3.7`，导致 PATH 命中旧版、出现“配置写入版本新于运行版本”的提示。
 								- 已对 N100 做版本收口：统一让 `/usr/bin/openclaw` 与 `/usr/local/bin/openclaw` 都指向 `2026.3.8`，systemd user service 实际运行版本确认已切到 `OpenClaw 2026.3.8 (3caab92)`。
 								- N100 稳定性加固：补了 `~/.config/systemd/user/openclaw-gateway.service.d/override.conf`，加入 `PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin`、`NODE_COMPILE_CACHE=/var/tmp/openclaw-compile-cache`、`OPENCLAW_NO_RESPAWN=1`；同时收紧 `/root/.openclaw` 为 `700`、`/root/.openclaw/openclaw.json` 为 `600`。
 								- N100 当前核心状态：gateway/heartbeat/Telegram provider 均能正常启动，`@aibot444_bot` 可正常收发消息；但日志仍可见 `Polling stall detected` 与 `sendChatAction failed: Network request ... failed`，后续若再抽风，应优先查 Telegram 网络链路/出口/DNS，而不是 OpenClaw 版本本体。
 								- N100 中文 Telegram 菜单已通过 `/root/.openclaw/workspace/scripts/fix-telegram-menu.sh` + `/root/.openclaw/workspace/HEARTBEAT.md` 固化，按默认 heartbeat 周期约每 30 分钟自动补一次菜单。
 								- Mac mini 上 `peekaboo` 已最终打通：`peekaboo permissions` 显示 Screen Recording / Accessibility 均为 `Granted`，`peekaboo list apps --json` 成功，`peekaboo see --annotate --path /tmp/peekaboo-see.png` 成功生成截图与标注图。
 								- 这次排查确认：brew 安装的 `peekaboo` 公式只装 CLI，不自带 `Peekaboo.app`；本机无 `Peekaboo.app` / `Claude.app` / `Clawdis.app` bridge host，`peekaboo bridge status` 走的是 `selected.source = "local"`。
 								- Mac mini 主实例当前承载 `peekaboo` 调用的宿主链是 `launchd -> ai.openclaw.gateway -> /opt/homebrew/opt/node@22/bin/node -> /opt/homebrew/lib/node_modules/openclaw/dist/index.js`，不是 Terminal 直接前台运行。
 								- 经验/教训：以后排 Peekaboo 权限不要先入为主逼用户找错对象；应先查 `peekaboo bridge status` 和实际进程宿主，再判断该授权哪个主体。对这台 Mac，已确认现在 Peekaboo 可用，后续可直接用于 macOS GUI 自动化。
 								- Safari / 火山登录这次实战结论：对 Safari，单纯用 Peekaboo 做键鼠模拟不稳，容易卡在焦点、菜单栏或页面前端未真正吃值；更稳的方法是 `AppleScript + Safari do JavaScript`，直接控制标签页、读 DOM、给输入框赋值并触发真实前端事件。
 								- 浏览器控制经验：若是 Chrome 且已接 OpenClaw Browser Relay，首选内置 browser 工具（最稳、结构化、可读状态）；若目标明确要求 Safari 或系统原生浏览器页面，优先用 Safari 的 AppleScript+JS 方案；Peekaboo 更适合兜底的 macOS 原生 GUI 操作，不应作为网页表单自动化的第一选择。