用tmux统一管理终端AI工具：Claude Code等5个的macOS工作台实践

前阵子我清理了一轮终端窗口,发现一个挺尴尬的事实:Claude Code、Codex、OpenCode、pi、Grok 这几个命令行 AI 工具,我全都装上了,每个窗口里却各聊各的,东一句西一句,查同一个报错要在四个终端之间来回跳。标题里那句“四个终端对不上”就是我自己日常的真实写照——窗口太多,脑子跟不上。后来花了一个周末,我把它们统一收进一个 macOS 工作台,按任务而不是按工具来组织会话,总算有种“终于顺了”的感觉。这篇就把我的整合思路、每个工具的接入要点、tmux 布局脚本,以及踩过的坑都写出来。你哪怕只装了其中一两个,这套工作流也能直接用上。

1. 为什么要折腾一个统一工作台,而不是再多装一个工具

1.1 这五个工具不是五个竞品,是五种工作场景

先说结论:Claude Code、Codex、OpenCode、pi、Grok 虽然都长在终端里,但它们的定位差异比想象中大。把它们放一起不是为了凑数,而是因为它们在不同任务上各有顺手的地方,我按自己的使用习惯给它们分了工:

工具	我主要用它干的事	典型的接入方式
Claude Code	长链路重构、读老项目、让它先解释再动手	Anthropic 账号登录或 API Key
Codex	和 ChatGPT 账号体系联动,适合从聊天记录直接衔接到终端任务	官方 CLI 登录
OpenCode	开源可改,适合当“模型切换试验台”,一个终端换着模型跑	配置文件声明 provider
pi	轻量对话、临时翻译、取个变量名这种小任务,启动快	OpenAI 兼容接口或单一二进制
Grok	查实时资料、build 类命令,信息新鲜度是我最看重的	平台 API Key

所以问题的关键从来不是“哪个工具最强”,而是“这些工具的会话、登录态、配置分散在各处”。你很难记住 claude 的配置文件在~/.claude,codex 的登录态在~/.codex,opencode 的模型配置又去了~/.config/opencode。统一工作台要做的第一件事,是把它们的状态保管好、入口统一好,而不是把五个工具合并成一个。

1.2 为什么用 tmux 而不是“再装一个集成面板”

市面上其实有不少“聚合多个 AI CLI”的桌面工具,我也试过,但最后留下了 tmux。原因很实在:

• tmux 在 macOS 上已经足够稳定,会话挂在后台,关掉 Terminal 再重开,tmux attach就能恢复现场;
• 我平时还要连服务器干活,同一套 tmux 习惯可以直接平移过去,不需要在工作台里再学一套新概念;
• tmux 的窗口、窗格、命名、日志管道都是透明的,出了问题能一层层拆开排查,不会像黑盒面板那样无从下手。

换句话说,工作台的底座越朴素越好。把所有 AI 工具“收进”同一个 tmux 会话,它们共享的是同一个终端环境、同一份 PATH 和同一套密钥加载逻辑,但各自运行在独立窗口里,互不干扰。这也是我最推荐的 macOS 方案:轻、稳、可迁移。

2. 动工前的地基:先把 macOS 环境理成同一套标准

2.1 统一 Node 运行时,省掉一半“工具起不来”的报错

Claude Code、Codex、OpenCode 都是基于 Node 生态的 CLI,pi 和 Grok 在实现上不一定依赖 Node,但它们的安装脚本也经常会调用 npm 或 npx。所以我把本机的 Node 统一到了 20 LTS,这一步帮我解决了大量“莫名其妙的权限错、模块错”。

如果你还没有 Node,最简单的做法是:

brew install node@20 export PATH="/opt/homebrew/opt/node@20/bin:$PATH"

注意 Apple Silicon 上 Homebrew 安装目录是/opt/homebrew,Intel Mac 上是/usr/local,这个路径别搞混。如果你平时会切换 Node 版本,建议直接用 nvm 或 fnm,然后把默认版本钉在 20。不用追求最新版,很多 AI CLI 对新版 Node 的适配速度并没有你想象中快。

装完以后记得验证一下:

node -v npm -v

我见过很多“命令装好了但一跑就报错”的情况,最后查下来都是因为终端还在用旧版 Node 的 PATH。

2.2 密钥和配置文件不要散落在各处,用一个入口统一加载

每个工具都需要各自的 API Key 或登录态。把它们直接写进.zshrc会非常乱,尤其是当你同时维护多套 Key、时不时要切换环境时。我的做法是单独建一个环境文件,由 shell 启动时统一加载:

mkdir -p ~/.config/ai-shell touch ~/.config/ai-shell/env.sh chmod 600 ~/.config/ai-shell/env.sh

然后在~/.zshrc里加一行:

source ~/.config/ai-shell/env.sh

env.sh 的内容大概长这样:

export ANTHROPIC_API_KEY="<你的Claude Key>" export OPENAI_API_KEY="<你的OpenAI Key，如果走 API 方式>" export XAI_API_KEY="<你的xAI Key>"

chmod 600是为了防止同机其他用户读到你的密钥。我自己的习惯是:凡是涉及密钥的文件一律不进 dotfiles 仓库,仓库里只放一个env.example.sh,里面用占位符标明该填什么。这样即使换新机器,我也能靠一套模板快速恢复环境。

2.3 给 tmux 写一份最小可用配置

macOS 自带的终端里直接跑 tmux 也能用,但体验偏差大。我会先安装:

brew install tmux

然后写~/.tmux.conf。最小配置我建议包含这三条:

set -g mouse on set -g default-terminal "screen-256color" set -wg mode-keys vi

开启鼠标是为了方便用鼠标滚动查看 AI 长输出;设置终端类型是为了让 Claude Code、Grok 这类带颜色和交互界面的工具显示正常;vi 模式键位则是我个人的习惯,方便在复制模式里翻页。这三条不是花活,每一项都能避免实际使用中的显示问题。

3. 逐个接入:五个命令的安装与第一次跑通

3.1 Claude Code:先登录,再确认目录授权

Claude Code 的官方安装方式在 npm 上,一条命令就能装:

npm install -g @anthropic-ai/claude-code

装完直接执行claude,首次运行会引导登录。我建议优先走官方登录流程,而不是自己塞 API Key,因为登录态方便管理和续期,而且在多个项目间切换时更自然。

第一次跑起来后,Claude Code 会对当前目录做权限确认——它会问你是不是允许它读文件、执行命令。这里我的经验是:先在一个临时测试目录里把流程跑通,不要一上来就在正式项目根目录授权,免得它在你不注意时改了一堆文件。它的配置会放在~/.claude下面,升级或重装 CLI 不会影响已保存的授权记录。

3.2 Codex:登录链路走通之后,记住 exec 模式

Codex 同样来自 npm:

npm install -g @openai/codex

安装后执行codex login,会拉起浏览器完成账号授权。这里有一个容易卡住的点:如果你的账号或组织还没开通对应权限,登录完会提示“没有可用模型”。第一次遇到别慌,先去后台确认账号状态,而不是反复重装。

Codex 还有个很适合脚本化的exec模式。比如我只想让它快速给某段代码写个测试,可以直接:

codex exec "给 src/utils.js 里的 parseConfig 写一组单元测试"

这种非交互模式在工作台里特别有用:我们可以让 Claude Code 干完一件事后,调用 Codex 再用另一个模型复核一遍。虽然听起来有点“套娃”,但在关键逻辑上让两个模型交叉验证,实测下来确实能抓到不少单模型漏掉的问题。

3.3 OpenCode:把模型列表和默认 provider 理顺

OpenCode 目前最吸引我的是它把多模型切换做成了很自然的配置。安装命令依然是 npm:

npm install -g opencode-ai

不过我要提醒一句:npm 上同名或相似包很多,安装前一定看清包名和发布组织,别装到第三方仿冒包。装完以后,执行opencode models看它能识别哪些模型;如果默认模型不是你想要的,它的配置文件一般落在~/.config/opencode,按官方 schema 改好默认 provider 就行。

我自己的经验是:OpenCode 适合当“比较器”。同一个问题,先用 Claude 系模型跑一遍,再切到 OpenAI 系跑一遍,输出差异一目了然。因为它在配置层面对 provider 的支持比较开放,所以不需要我手动去维护一堆环境变量。

3.4 pi:小而快的“随手问”入口

pi 在标题里是最容易被忽略的一个,但它其实是我日常使用频率最高的——因为它启动快、占用低,很多一句话就能解决的小事,我不会专门去开 Claude Code 那个重终端。它的安装方式要看具体发布版本:有的分发是单一二进制,下载后chmod +x放到/usr/local/bin就能用;有的版本走 Node,同样用 npm 全局安装。

这里我要单独讲一个“同名陷阱”的问题:pi 在很多语言生态里都有同名命令,装之前先执行which pi看现在系统里有没有同名程序,否则可能装了个 A 项目,敲命令却调起 B 项目。确认没有冲突后再装,装完跑一句简单对话测试,能正常返回就算通过。

3.5 Grok:装完先看版本,再摸清 build 子命令

Grok 的终端工具现在迭代很快,我机器上用的版本已经在grok build这条子命令上稳定下来了。安装方式以官方仓库 README 为准,不同版本可能提供安装脚本或二进制包。装完第一件事是验证:

grok --version grok build --help

Grok 对实时信息的掌握是它的强项,所以我通常让它承担“查最新文档、查某个依赖当前版本”这类任务。配置时同样需要 API Key,放进前面说的 env.sh 里统一加载。要注意的是它的模型命名和接口版本会变,如果某天突然报 404 或找不到模型,先检查--version是不是落后了,再检查 Key 有没有过期。

4. tmux 工作台实战:按任务而不是按工具组织会话

4.1 设定工作台布局:一个任务一个 session,一个工具一个窗口

我见过很多人把五个工具放进同一个窗口的五个分屏,表面上看很“全”,实际用起来非常挤。AI 终端的输出往往是长文本,分屏后根本没法舒服地阅读。我的方案是:一个任务建一个 tmux session,任务里的每个工具占一个独立窗口。

比如我在做“重构登录模块”这个任务时:

tmux new-session -s login-refactor -n claude tmux new-window -t login-refactor -n codex tmux new-window -t login-refactor -n opencode tmux new-window -t login-refactor -n grok

这样窗口列表看起来就是0:claude 1:codex 2:opencode 3:grok。在 Claude Code 窗口里让它读代码、出重构方案;切到 Codex 窗口让它写测试;再切到 Grok 窗口查某个依赖的最新 API 变化。每个窗口都是全屏宽度,AI 输出不会折行折得没法看。

4.2 一键拉起全家桶的启动脚本

每次都手动敲上面那几条命令还是太累,我把它们写成了一个脚本workbench.sh:

#!/usr/bin/env bash SESSION="${1:-ai}" tmux kill-session -t "$SESSION" 2>/dev/null tmux new-session -d -s "$SESSION" -n claude tmux new-window -t "$SESSION" -n codex tmux new-window -t "$SESSION" -n opencode tmux new-window -t "$SESSION" -n pi tmux new-window -t "$SESSION" -n grok tmux send-keys -t "$SESSION:claude" 'claude' Enter tmux send-keys -t "$SESSION:codex" 'codex' Enter tmux send-keys -t "$SESSION:opencode" 'opencode' Enter tmux send-keys -t "$SESSION:pi" 'pi' Enter tmux send-keys -t "$SESSION:grok" 'grok' Enter tmux select-window -t "$SESSION:claude" tmux attach -t "$SESSION"

脚本执行完,五个工具会自动在自己的窗口里启动。用完以后不要直接关终端,先按前缀键(默认Ctrl-b)然后按d脱离会话,让它留在后台。下次想继续,tmux attach -t ai就回来了。如果你经常同时开多个任务,给脚本传参改名会话,比如./workbench.sh login-refactor,就能做到任务间互不干扰。

4.3 给工作台加两个顺手的小工具:快捷别名和会话日志

光有脚本还不够,我在.zshrc里补了几个别名,把高频操作缩短:

alias wb="bash ~/scripts/workbench.sh" alias ta="tmux attach -t" alias tl="tmux ls"

另外还有一个习惯非常推荐:给每个 AI 终端窗口挂日志管道。tmux 可以把某个窗口的输出实时写到文件里,这样即使会话被误杀、或某个 AI 输出被滚动冲掉,我也能找回完整记录:

tmux pipe-pane -t ai:claude -o 'cat >> ~/ai-logs/claude-$(date +%F).log'

不过注意这个命令是瞬时生效的,脱离会话后管道可能中断。所以更稳的做法是把日志采集也写进工作台脚本,在启动每个工具窗口后顺手把pipe-pane挂上。AI 会话有时候跑出很有价值的结论,不落盘就太可惜了。

5. 实战中常踩的坑,以及排查技巧实录

5.1 命令装好了,敲下去却说 not found

这类问题九成出在 PATH 上。npm 全局包的安装目录不一定在当前 shell 的 PATH 里,尤其是用 nvm 或 fnm 管理 Node 版本时,不同 Node 版本的全局目录还不一样。

npm bin -g

先把这条命令的输出加到.zshrc的 PATH 里,然后重新开一个终端窗口验证。另一个隐蔽来源是:你用 Homebrew 装了一个同名命令,系统优先调用的是别处的旧版本,执行which claude、which codex就能看出实际指向。

5.2 登录成功,但请求还是 401、429

登录成功不代表万事大吉。我第一次接 Codex 时就遇到过登录后依然报权限错的情况,最后发现是账号组织里没有勾选对应模型权限。API Key 方式也一样,先确认 Key 的前缀和工具要求的平台一致,比如 Claude 用sk-ant-开头,而 Grok 的 Key 有自己的前缀体系。

还有一个容易被忽略的点:如果你在本地配置了自定义 API 接入地址——不管是为了内网调试还是实验某个网关——一定要先确认它是否真的在运行、接口路径是否与官方文档一致。我在排查一次/responses报错时,折腾了半天才发现是自定义接入服务自己挂了,和工具本身毫无关系。现在我的排查顺序永远是:先直连官方地址确认基线没问题,再逐层检查自定义配置。

5.3 macOS 专属问题:权限弹窗、中文输入法、字体显示

macOS 上第一次运行这些 AI CLI,经常会出现权限弹窗,要求终端 App“控制其他进程”或“访问某个文件夹”。这些权限不是 CLI 自己弹的,而是 macOS 在拦截终端的行为。遇到弹窗别急着点“不允许”,先看清是哪个终端程序在请求,再决定是否授权。

中文输入法和 AI 终端同时使用是我踩过的一个特殊坑:在 Claude Code 的交互输入框里打中文,偶尔会出现候选词上屏错位,或者按回车后命令没发出去。这不是工具本身的问题,而是终端对输入法事件的处理差异。我后来养成了在需要大量打中文时,先用系统备忘录把问题写清楚,再粘贴进 AI 窗口的习惯,反而让提问质量也提高了。

另外,如果某些 AI 工具输出里出现方框、问号或者颜色丢失,大概率是终端字体和TERM环境变量不匹配。建议给终端装一个支持图标和特殊字符的字体,并保持 tmux 配置里的default-terminal一致。

5.4 多个工具同时在一个项目目录里干活,互相踩脚

在一个 tmux 工作台里同时让 Claude Code 改文件、Codex 写测试,它们会在同一个 git 工作区里竞争。这个问题很现实:如果两个 agent 同时编辑同一个文件,后保存的一方会覆盖先保存的一方,而且不会报错。

我的解法是:在同一个任务 session 里,先明确分工,比如“Claude Code 只动src/目录,Codex 只新建tests/目录”。更激进一点的做法是给每个工具开独立分支,跑完以后人工合并。这个习惯虽然听起来很基础,但能避免掉九成以上的协作冲突。

5.5 macOS “系统数据”占用越来越大,其实是各种缓存的锅

装完这一堆 AI CLI 之后,~/.npm、~/.claude、~/.codex、~/.config/opencode这些目录会悄悄变大,尤其 AI 工具会缓存不少临时文件。系统设置里显示的“系统数据”占用大,很多时候就是这些藏在用户目录里的缓存。

du -sh ~/.npm ~/.claude ~/.codex ~/.config/opencode 2>/dev/null

先看哪些目录膨胀得厉害,再针对性清理。npm 缓存可以放心清,AI 工具的会话历史如果不需要保留,也可以删掉对应目录下的 sessions 子目录。我给自己定了一条规矩:每个大版本迭代结束后,清理一次旧会话缓存,顺手记录哪些会话还值得留,别让日志堆积成新的“系统数据黑洞”。

6. 长期用下来的几个收尾习惯

6.1 把配置纳入版本管理,但严格排除密钥

现在我能在一台新 Mac 上一小时恢复整个工作台,靠的就是一套 dotfiles 仓库。~/.tmux.conf、~/.zshrc、opencode 的模型配置文件都纳入 git,但 env.sh 这类含密钥的文件永远只留模板。

git init ~/dotfiles ln -s ~/dotfiles/tmux.conf ~/.tmux.conf

6.2 每周固定做一次“多工具交叉复盘”

工具装多了以后,很容易陷入“哪个窗口开着就用哪个”的随机状态。我现在的方法是:同一个技术问题,至少让两个不同模型的 agent 各看一遍。不是非要分高下,而是两个模型的盲区往往不重叠,交叉验证能提前发现一些“看起来对但实际有隐患”的答案。这套工作台实际上给了我一个很低的验证成本——切换窗口比切换网页、复制粘贴上下文要顺滑得多。

6.3 保留一份自己的安装清单笔记

最后分享一个很小的习惯:我在工作台根目录放了一个README.md,里面写着当前机器装了哪些版本、用了哪个 Key 的别名、上次踩坑的日期。版本迭代太快,记忆力最不可靠。等哪天 Grok 又出新子命令、OpenCode 改了配置结构,这份笔记就是我最快的现场参考。工具是不断变的,但“给自己留一份可循的记录”这个习惯,一直都不会过时。