第一步：Linux 上不用 brew，从源码把 gogcli 编出来#

因为这台机器不想装 Homebrew，所以我最后走的是源码构建。

大致流程就是：

1
git clone https://github.com/steipete/gogcli.git
2
cd gogcli
3
make
4
install -Dm755 ./bin/gog ~/.local/bin/gog

这一步本身不算难，Go 和 make 都在，编译完之后 gog --help 也正常起来了。

所以安装阶段的问题不大。

第二步：真正的问题出在 keyring#

装完之后，我第一次试着查 Google Calendar，结果不是 API 报错，而是：

1
Cannot get secret of a locked object

这说明旧 token 是存在的，但它被存在了系统 keyring 里，而当前服务器环境取不出来。

这时候我才意识到：

在纯 Linux 服务器 / 非图形会话下，依赖桌面 keyring 这件事并不稳。

于是我后面把 gog 的 keyring backend 从默认的 auto，改成了 file。

1
gog auth keyring file

这个选择的核心逻辑其实很简单：

• 服务器环境要的是可预测、可非交互调用
• 不是“桌面体验好不好”

第三步：切到 file backend 之后，还得重新登录一次#

backend 改完，不等于旧 token 自动跟着迁过去。

因为旧 token 本来就在锁着的 keyring 里，既然拿不出来，就不可能无损迁移。所以后面还是得重新登录一次 gog，把 refresh token 存到新的 file backend 里。

而且 file backend 还多了一个要求：

1
set GOG_KEYRING_PASSWORD

也就是说，非交互环境下要想让 gog 能自由调用，就得给它提供一个 keyring password。

最后这条链路的稳定方案就变成了：

• gog 使用 file backend
• 设置 GOG_KEYRING_PASSWORD
• 在 OpenClaw / shell 环境里把它导入

这一套通了之后，后面我已经能用它做两件实际事情：

1. 查 Google Calendar
2. 把文件直接上传到 Google Drive

对我来说，这时候 gog 才算真的从“装好了”变成“可用了”。

真正的症结：.bashrc 只在 interactive shell 里加了 PATH#

我后来去看了 ~/.bashrc，发现里面确实有：

1
export PATH=/home/geneden/.opencode/bin:$PATH

但问题是，这行写在了只对 interactive shell 生效的逻辑后面。

前面有这一段：

1
case $- in
2
    *i*) ;;
3
      *) return;;
4
esac

这就意味着：

• 你自己开交互式 shell 时，opencode 在 PATH 里
• OpenClaw 的非交互检查命令，不会走到后面的 PATH 导出

所以会出现一个很迷惑的现象：

• 你在自己终端里敲，觉得 opencode 明明在
• OpenClaw 面板里看，coding-agent 还是 blocked

先修 shell，不够；真正要修的是 gateway service 的 PATH#

我最开始也差点被这个问题带偏，以为只要把 PATH 加进环境文件就结束了。

后来继续查 openclaw gateway status 和 systemd service 文件，才发现真正重要的是：

面板看的不是你当前交互 shell 的 PATH，而是 gateway service 进程自己的 PATH。

我最后看到的 service 文件里，PATH 本来是：

• ~/.local/share/pnpm
• ~/.local/bin
• 以及一串常规目录

但就是没有：

• /home/geneden/.opencode/bin

后面真正把问题彻底修掉的动作，是把它补进 openclaw-gateway.service 的 PATH 里，然后重载 / 重启服务。

修完后再看：

1
openclaw skills info coding-agent

它终于从 Missing requirements 变成了：

1
✓ Ready

这次踩坑给我的最大提醒是：

对 systemd 托管的服务来说，你在终端里“能跑”的命令，不等于服务进程也“能看见”。

1. skill 体系干净了#

• 清掉了和官方内置重复的 skill
• 常用 skill 都回到了更清晰的来源结构

2. gog 真的能用了#

• 能查 Google Calendar
• 能传文件到 Google Drive
• 不再依赖不稳定的桌面 keyring

3. coding-agent 不再只是“命令行里看着像正常”#

• 而是 gateway service 也真的认到了 opencode
• 面板状态和实际环境终于一致了

4. 终端工作流也更符合自己的习惯了#

• 不再死磕 tmux
• 改成了更想用的 zellij

这四件事加在一起，OpenClaw 才从“能跑”变成了“顺手”。

第一，先分清“已安装”和“可用”#

clawhub list、skill 目录、SKILL.md 这些都只能证明它“在”，不能证明它“现在真的能工作”。

真正决定可用性的，是：

• 二进制
• API key
• 授权状态
• 服务运行上下文

第二，服务问题优先看 systemd 环境，而不是只看当前 shell#

如果一个命令你在终端里明明能跑，但 OpenClaw 面板里还是 blocked，那优先怀疑：

• gateway service 的 PATH
• EnvironmentFile
• systemd 实际注入了什么环境变量

这比盯着 .bashrc 自己脑补要有效得多。

第三，服务器场景下，越“桌面味”的密钥方案越容易不稳定#

像 gog 这种需要长期非交互调用的工具，如果把关键 token 建在桌面 keyring 的体验假设上，放到服务器里就很容易出问题。

在这种场景下，能清楚控制的 file backend 和环境变量，反而更靠谱。

如果你现在也在折腾 OpenClaw，尤其是已经开始用 skills、gog、coding-agent 这几条线了，那我觉得最值得先做的不是拼命加新功能，而是先把这几件事理顺：

• skill 来源别重复
• eligibility 别只看 enabled
• PATH 别只修 shell，不修 service
• 能走稳定后端的授权，就尽量别赌桌面 keyring

把这些打通之后，后面的体验会顺很多。