最近发现龙蜥、欧拉社区都在卷 SkillHub，我也想着试一下免得领导问起来我到时不知道。由于手头只有一台统信服务器操作系统 V20 1070e 版本的服务器，于是决定先在这台服务器上安装并配置 Codex、OpenCode，再测试 SkillHub 的一些用例。

需要注意的是，Codex、OpenCode 等 Agent 都依赖较高版本的 Node.js，而系统自带的 Node.js 版本偏低，无法满足要求。因此需要前往 Node.js 官网自行下载高版本，我这里选用的是 node-v24.0.0。

1. 安装 Node.js（需要注意对应架构）
#wget https://nodejs.org/dist/v24.0.0/node-v24.0.0-linux-x64.tar.gz

将压缩包解压到 /usr/local 目录下：
#tar zxvf node-v24.0.0-linux-x64.tar.gz -C /usr/local/

创建全局 Node.js 环境路径，方便系统直接调用：
#ln -s /usr/local/node-v24.0.0-linux-x64/bin/node /usr/bin/node
#ln -s /usr/local/node-v24.0.0-linux-x64/bin/npm /usr/bin/npm

Node.js 安装完成后，就可以开始安装 AI Agent 了。

2. 安装 Codex
这里选择 npm 快速安装方式
#npm install -g @openai/codex

安装完成后，Codex 的默认安装目录位于 /usr/local/node-v24.0.0-linux-x64/bin/codex。

为了全句可以访问 Codex，需要设置一下环境变量，在 ~/.bashrc 最后添加：
export PATH=“/usr/local/node-v24.0.0-linux-x64/bin:$PATH”
#vi ~/.bashrc

保存退出后，让配置立即生效：
#source ~/.bashrc

运行codex

为了测试，我这里用自己私有的 API key，选择 3。

另外我这里只有 glm-5.3-flash 提供的是 Chat Completions API，但是新版 Codex 使用的是 OpenAI 的 Responses API，两者不兼容，所以需要 CC Switch 做代理，参考下面的链接：
https://github.com/farion1231/cc-switch/releases/download/v3.20.2/CC-Switch-v3.20.2-Linux-x86_64.rpm
在安装的过程中我发现缺少 libayatana-appindicator 和 libwebkit2gtk-4.1 这两个库，但因为单位服务器环境不能安装 GTK 等窗口，所以只能在我的 Windows 这里就不展示了。
正常配置完成，需要在~/.codex/config.toml中的base_url填写代理地址

完成后就可以运行codex了

到这里codex已经开始运行，我们到时看下codex本次用了多少token，写的脚本是什么

经过一段时间的等待codex完成了，本次编写，在/root/system_monitor.sh

我们来看一下/root/system_monitor.sh并执行一下看看效果

另外用vim 看了一下这个sh，共计 337行

运行一下这个脚本看下运行情况

我们先把这个sh保存起来，然后等其他AI Agent都是使用相同的模型跑完后看看是否是否生成的sh都是一样的
最后看下本次共花费了多少token

其中缓存命中了 96%，不过单纯的“帮我写一个监控系统性能的脚本”使用了15,561 tokens不知道值不值

3.安装opencode
这里选择npm快速安装方式
#npm install -g opencode-ai

安装完成后执行#opencode就可直接访问

为了和codex保持模型统一，我也修改成本地glm模型
配置完成后重新运行opencode，一样输入“帮我写一个监控系统性能的脚本”看下效果

opencode会提示我需要用什么语言来编写，为了统一还是shell方式，感觉opencode的互动性比codex要强，经过一段时间opencode生成完成，叫/root/monitor.sh

另外用vim 看了一下这个sh，共计 157行

运行一下这个脚本看下运行情况

最后看下本次共花费了多少token，虽然opencode自己cli显示的是12,353token，但是我在代理端看到token要多些

通过综合对比一下opencode和codex生成的sh脚本

最后仔细看了一些内部代码，例如网络流量分析都是基于/proc/net/dev，但是实现细节还是有些不一样的

好了，准备下下班了，最后稍微总结一下整体在统信服务器操作系统 V20 1070e 上安装 Codex 和 OpenCode 的过程整体比较顺利，但也有一些值得注意的坑。两者都依赖较高版本的 Node.js，系统自带的版本偏低，需要手动下载并配置环境变量。Codex 的安装相对简单，通过 npm 全局安装即可，但新版 Codex 使用的是 OpenAI 的 Responses API，与 glm-5.3-flash 提供的 Chat Completions API 不兼容，需要借助 CC Switch 做代理转发，这算是一个不小的门槛。而 OpenCode 的安装同样通过 npm 完成，配置本地 glm 模型后即可直接使用，整体上手更轻量。另外从两者生成的脚本都基于 /proc/net/dev 做网络流量分析，说明底层思路一致，但实现细节差异不小。Codex 生成的 system_monitor.sh 共 337 行，功能覆盖更全面，脚本结构也更完整；OpenCode 生成的 monitor.sh 只有 157 行，代码更精简，但功能覆盖相对少一些。从 token 消耗来看，Codex 使用了 15,561 tokens（缓存命中 96%），OpenCode 的 CLI 显示 12,353 tokens，但代理端实际消耗更多。综合来看，Codex 在生成脚本的完整度和细节处理上更胜一筹，而 OpenCode 在交互体验和代码精简度上更有优势。最后就可以测试 龙蜥、欧拉社区中的SkillHub了。