sync_cliproxy_config.sh

选择性合并,不是全量覆盖。远端的 GLM 兜底模型是最后的救命稻草,同步操作绝对不能碰它。

这个脚本把本地的 claude-api-keyopenai-compatibility 两个 provider 配置段合并到远端 config.yaml。用 Ruby 做 YAML merge,因为 shell 处理嵌套 YAML 就是灾难。

# 手动执行一次同步
./sync_cliproxy_config.sh

# 脚本内部做了什么(伪代码):
# 1. scp 远端 config.yaml 到 /tmp
# 2. Ruby merge: 只合并 providers.claude-api-key 和 providers.openai-compatibility
# 3. 远端 GLM 模型配置原样保留
# 4. scp 合并后的文件回远端
# 5. 重启 gateway

为什么用 Ruby 做 YAML merge

试过 yqsed、手写 Python,全翻车。YAML 的缩进和嵌套结构用正则处理就是自寻死路。Ruby 的 Psych 库 parse → merge → dump,三行代码解决,而且输出格式不炸

sync_cli_proxy_json.sh

同步 ~/.cli-proxy-api/ 目录下的 JSON 文件到远端。排除了 *gmail* 相关文件(Gmail token 在远端独立管理,本地的不对)。

# 基本用法
./sync_cli_proxy_json.sh

# 只同步最近 30 分钟内变更的文件(cron 用)
./sync_cli_proxy_json.sh --window 30

# rsync 排除规则
# --exclude '*gmail*'

Crontab 配置

5 分钟自动同步一次,两套脚本串行执行。

# crontab -e
*/5 * * * * /path/to/sync_cliproxy_config.sh && /path/to/sync_cli_proxy_json.sh --window 5 >> /var/log/openclaw-sync.log 2>&1

踩坑记录


同步脚本的最高境界:跑了等于没跑——远端该有的都有,不该动的没动。