admin/vps-management-bot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
5c1e9adb6fe86f6db270e6f77f7bd39abfffa5aa
vps-management-bot/memory/2026-03-11.md
mango 8f1171fe99 Rename to hkt.sh
2026-03-21 01:10:53 +08:00

8.2 KiB
Raw Blame History

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 操作，不应作为网页表单自动化的第一选择。
Reference in New Issue View Git Blame Copy Permalink