1. 项目概述五个 AI 终端乱的根源不是模型而是工作流如果你和我一样最近大半时间都泡在终端里写代码那你大概率也经历了一个阶段先装了 Claude Code后来发现 Codex 在某些场景确实更顺手再后来为了试第三方模型又装 OpenCode紧接着被 Grok 的响应速度吸引工作群还有人丢来一句“pi 你们要不要也接一下”。装的时候都很兴奋真正用起来才发现问题工具越多越对不上。Claude Code、Codex、OpenCode、pi、Grok 各有各的命令各有各的登录方式各有各的上下文记忆文件。我在 Claude Code 窗口里交代过一遍的仓库背景切到 Codex 还要从头再讲Codex 里确认过的技术方案OpenCode 完全不知道更别说每个工具读的规则文件还不一样有的认 CLAUDE.md有的认 AGENTS.md。这种感觉就像同时请了五个水平不错的远程同事但每个人只听自己的小群消息互相之间不说话最后没有一个统一的工作台能告诉我现在整个仓库处在什么状态、谁改过什么、下一步该交给谁。这篇文章要解决的就是标题里那个“对不上”的问题。我会用一套可落地的 macOS 工作台方案把 Claude Code、Codex、OpenCode、pi、Grok 收进同一个 tmux 会话统一它们的密钥来源、项目上下文、规则文件和日志位置。不是要你只留一个工具而是让五个工具各干各最擅长的事同时共享同一份项目状态。适合正在同时使用多个 AI 编程终端、每天在不同 CLI 之间反复横跳的开发者参考。1.1 这几个工具在终端里到底各自扮演什么角色先把我当前的使用定位摆出来不然后面讲分工矩阵时你会觉得抽象工具维护方我在工作流里的角色主要记忆/配置载体Claude CodeAnthropic长任务主力负责具体功能实现、跨文件重构CLAUDE.md、项目级 .claude 配置CodexOpenAI代码库全局探索、审查 diff、找调用链AGENTS.md、~/.codex 配置OpenCode开源社区快速试模型、跑一次性验证任务opencode.json、AGENTS.mdGrok CLI / Grok BuildxAI低成本快速问答、写测试数据、生成脚本轻量上下文文件、环境变量pi团队内部工具只在本地/内网处理敏感小任务不追求前沿模型独立 token走环境变量注入这不是一份严格的工具性能对比而是我实际使用半年后的职责分配。Claude Code 的上下文维护能力最强适合让它从头到尾啃一个模块Codex 对“全仓库找问题”的执行路径清晰审查代码时提的问题往往很切中要害OpenCode 最大的价值是模型无关今天想试这个模型明天想试那个不用为了切换模型再装一套新工具Grok 胜在轻问个语法、写个临时脚本它响应快而且不占用主力 Agent 的额度pi 则是我这边为了满足“代码不出内网”这条要求而保留的独立节点。1.2 “对不上”到底卡在什么地方我把实际操作中遇到的断层总结成四类配置断层每个工具登录方式不同有的用 OAuth有的用 API Key有的要单独维护 provider 配置。我一开始把密钥散落在 .zshrc、.bashrc、各自的 config 文件里换台机器基本等于重来。上下文断层项目背景、技术选型、约束条件分散在多个 Agent 各自的记忆文件里A 知道的不代表 B 知道。最典型的就是给某个 Agent 讲了一堆业务背景切到另一个工具时它照样问出“这个模块是干什么的”。规则断层代码风格、commit 规范、禁止事项没有统一入口。Claude Code 认 CLAUDE.mdCodex 优先读 AGENTS.mdOpenCode 又看自己的 opencode.json。一个仓库需要维护三份规则改一处漏三处。成果断层每个 Agent 跑完后的输出散落在不同窗口没有统一日志。最后想复盘“这个需求一共花了多少 token、每个工具分别干了什么”只能靠记忆。后来我理清楚了一个思路与其把五个工具训练成同一个工具不如给它们搭一个共享的“工作台”让它们虽然跑在不同的终端窗口里但读同一份规则、加载同一套环境变量、操作同一个 Git 分支、把活动记录写到同一个日志目录。这就是这篇文章方案的核心。2. 环境准备与工具安装先把五路 Agent 都跑通聊收敛之前先保证每个工具单拎出来都能正常工作。很多“对不上”的问题其实是从安装阶段就埋下的版本不对、Node 环境不对、登录凭据没配全。后面工作台做得再漂亮单个 Agent 跑不起来也白搭。2.1 当前几个主流 CLI 的安装渠道我先说明一下AI CLI 的安装方式迭代非常快我这边写的是当前阶段实测能跑通的路径你复现时最好以各工具官方 README 和 GitHub Releases 为准。macOS 上第一步是先确认基础运行时Claude Code 和 Codex 目前主要走 npm 分发所以 Node.js 版本别太老建议直接用 nvm 装 LTS。# 先装 nvm 并切到 LTS如果你还没装 nvm install --lts nvm use --lts # Claude Codenpm 全局安装 npm install -g anthropic-ai/claude-code # Codexnpm 全局安装 npm install -g openai/codex # OpenCode官方脚本安装或 brew tap 安装 # brew install sst/tap/opencode curl -fsSL https://opencode.ai/install | bash # Grok CLI以官方文档提供的 install 脚本为准 # 不同版本可能存在渠道差异优先从官方 Release 页拿命令安装完随手验证一遍版本能省掉后面很多莫名其妙的“command not found”问题claude --version codex --version opencode --version grok --versionpi 的安装我没有放进来因为它是团队内部分发的小工具不存在公开统一渠道。但它的接入方式和其他几个没有本质区别只要最终能在一个终端里跑起来并且通过环境变量读取 token就满足收进工作台的条件。2.2 登录与密钥管理环境变量是唯一的公约数用久了你会发现这几个工具虽然登录方式五花八门但到了自动化和统一管理层面最终都认环境变量。Claude Code 认 ANTHROPIC_API_KEYCodex 既可以走 ChatGPT 账号登录也可以走 OPENAI_API_KEYOpenCode 是按 provider 读取密钥Grok 支持 XAI_API_KEYpi 则是读取自定义的 P I_API_TOKEN。所以我在工作台方案里立了一条规矩所有密钥只放进项目或用户目录下的 .env 文件各工具一律通过环境变量读取绝不在各自的 config 文件里硬编码。有人会问Codex 的 ChatGPT 账号登录不也挺方便吗方便是真方便但有个问题一旦切到自动化脚本或需要换账号时OAuth 登录态往往在背后维护着一堆配置文件出了问题很难排查。API Key 的方式更直白你随时知道自己在用什么身份。代价是要自己管理好密钥安全别把 .env 提交进 Git也别随手贴到聊天工具里。这里插一条经验我在 .gitignore 里永远保留这行.env .env.* !.env.example同时仓库里维护一份 .env.example字段写清楚但不填真实值。新人克隆项目后复制一份 .env.example 到 .env 再填自己的密钥每个 Agent 就都能正常工作。2.3 为什么不用五个终端标签页而要搞一个工作台有同事问我这些工具都装在终端里我开五个 iTerm 标签页不就行了吗为什么非要搞成 tmux 会话我的回答是标签页解决的是“视觉上分开”工作台解决的是“逻辑上收拢”。五个标签页不会自动共享同一个项目目录的上下文也不会帮你把每个 Agent 的活动记录到同一份日志。而用 tmux 搭工作台我可以做到一条命令进入某个项目的完整 AI 工作区每个 Agent 分配一个独立窗口所有窗口都在同一个 session 下session 可以随时 detach 再 attach远程开发时也不会因为笔记本合盖就断掉所有 Agent 的进度。3. 配置收敛让每个仓库只维护一套 AI 上下文工具装好、密钥能加载之后下一步是处理最让我头疼的“规则断层”。这一节是整个工作台的灵魂让五个 Agent 在同一个项目里读到的是同一套背景信息、同一份代码规范。3.1 使用 direnv 自动加载项目级环境变量macOS 上我推荐用 direnv 做环境注入。它的原理很简单当你 cd 进入某个目录时direnv 会自动执行该目录下的 .envrc 文件把环境变量加载进当前 shell离开目录时自动卸载。这样就不需要为了某个项目手动 export 一堆变量。brew install direnv然后在 .zshrc 里加上 hookeval $(direnv hook zsh)项目根目录里放一个 .envrc内容可以非常简单dotenv这一行的意思就是让 direnv 读取同目录下的 .env 文件并加载里面的变量。首次进入目录时direnv 会提示你确认是否信任当前目录执行direnv allow即可。这套方案的好处是Claude Code、Codex、OpenCode、Grok、pi 全都是在同一个 shell 环境里启动的它们天然继承这些环境变量。项目里新增一个第三方服务的 API Key只需要往 .env 加一行所有 Agent 下次启动时都能读到。3.2 用一份共享规则文件统一所有 Agent 的项目记忆接着处理最关键的规则文件问题。不同 Agent 默认读取的文件名不一样Claude Code 读 CLAUDE.mdCodex 和 OpenCode 这类更认同 AGENTS.mdGrok 的官方文档里也越来越多地出现对通用 agent 规则的引用。与其在每个文件里写一遍规则不如指定一份权威文件再用符号链接把各工具要读的文件指过去。mkdir -p docs # 先写一份共享规则文件 cat docs/agent-rules.md EOF # 共享 Agent 规则 ## 项目背景 - 这是一个订单批处理系统核心模块在 src/batch 下 ## 常用命令 - 测试pnpm test - 单模块测试pnpm vitest src/batch/worker.test.ts - 类型检查pnpm typecheck ## 代码约束 - 禁止在事务提交前执行外部请求 - 所有外部接口调用必须有超时和重试 - commit message 使用 conventional commits 风格 EOF # 链接到各 Agent 默认读取的位置 ln -sfn docs/agent-rules.md CLAUDE.md ln -sfn docs/agent-rules.md AGENTS.md这里有一个很容易踩的坑符号链接如果放在 Git 仓库里Windows 同事 clone 下来可能会失效。但既然讲的是 macOS 工作台这个方案在 macOS 和 Linux 上都没问题。如果团队里有 Windows 环境建议改成 CI 脚本在 clone 后自动执行链接命令。另外注意AGENTS.md 的机制是支持子目录分层的。对于大型仓库我倾向于在根目录放全局规则在复杂模块的子目录里再放局部 AGENTS.md只描述该模块自己的上下文。共享规则文件不要写太长否则每个 Agent 启动时都要读一大堆背景反而稀释了注意力。3.3 MCP 配置与忽略文件也有必要做一次收敛如果你们团队已经用上了 MCPModel Context Protocol你会发现 Claude Code、Codex、OpenCode 对 MCP server 的配置格式并不完全相同。想省事的话不要把同一批 MCP server 在三个工具里各配一遍而是维护一份 docs/mcp.md把当前项目需要的 MCP server 列表、用途、需要暴露的工具名称写清楚然后从这份文档生成各工具所需的配置片段。这里分享一个我自己写的极简同步思路先用文档记录“我们有哪些 MCP server”再在启动工作台的脚本里做一次检查如果某一路 Agent 的配置里缺失了关键 server就提示我手动补齐。自动生成配置太容易因为格式差异翻车人工确认一次反而更稳。忽略文件同样要统一。默认情况下这些 Agent 会扫描项目文件来建立理解但 node_modules、dist、.venv、大型日志这些内容扫进去纯粹是浪费上下文窗口。我在每个项目根目录的 AGENTS.md 里都会写一段提示让 Agent 不要读取这些目录同时在 .gitignore 里保证它们不会被提交。双保险的意义在于规则文件负责给 Agent 看.gitignore 负责给 Git 看两者覆盖不同场景。3.4 给五个 Agent 定义一个清晰的分工矩阵配置收敛之后还要回答一个更重要的问题同一个需求到底应该让哪个 Agent 干没有分工矩阵的话就会出现两个 Agent 同时改同一个文件、互相覆盖的惨剧。我目前的分工原则是功能实现、跨模块重构这种需要长上下文的任务优先交给 Claude Code它在持续跟踪项目规则方面表现最好。全仓库代码排查、调用链梳理、提交前代码审查这种需要宏观视角的任务交给 Codex让它基于 git diff 审查比让它直接上手改代码更可靠。需要快速验证某个新模型、或者临时跑一个一次性脚本的任务交给 OpenCode因为它模型无关切换成本最低。琐碎的语法问题、测试数据生成、正则表达式编写这类短任务交给 Grok响应快、额度省。涉及内部敏感代码且不能出内网的片段只交给 pi 处理其他 Agent 不接触这部分内容。这套矩阵不是死的。核心原则是同一时刻同一个文件只允许一个 Agent 拥有写权限。在 tmux 工作台里我会按窗口把任务隔离在不同分支或不同 worktree 上避免两个 Agent 的修改互相踩踏。4. 工作台搭建用 tmux 脚本把 Agent 装进一个会话配置说完来到落地环节。这里我会给出一个可以直接用的 tmux 启动脚本加上配套的日志目录和常用命令封装。4.1 一条命令创建“项目 AI 工作台”我习惯把脚本放在 ~/.ai/ 目录下这样它和项目代码是解耦的任何项目都能调用。下面是核心启动脚本 new-workbench.sh#!/usr/bin/env bash set -euo pipefail PROJECT_DIR$(cd ${1:-$(pwd)} pwd) PROJECT_NAME$(basename $PROJECT_DIR) SESSIONai-${PROJECT_NAME//[^a-zA-Z0-9-]/_} # 已存在该会话则直接切过去 if tmux has-session -t $SESSION 2/dev/null; then tmux switch-client -t $SESSION exit 0 fi LOG_DIR$HOME/.ai/logs/$SESSION mkdir -p $LOG_DIR # 主窗口Claude Code tmux new-session -d -s $SESSION -c $PROJECT_DIR -n claude claude 21 | tee -a $LOG_DIR/claude.log # Codex tmux new-window -t $SESSION -c $PROJECT_DIR -n codex codex 21 | tee -a $LOG_DIR/codex.log # OpenCode tmux new-window -t $SESSION -c $PROJECT_DIR -n opencode opencode 21 | tee -a $LOG_DIR/opencode.log # Grok tmux new-window -t $SESSION -c $PROJECT_DIR -n grok grok 21 | tee -a $LOG_DIR/grok.log # pi可选只有团队内使用时保留 tmux new-window -t $SESSION -c $PROJECT_DIR -n pi pi 21 | tee -a $LOG_DIR/pi.log # 回到第一个窗口 tmux select-window -t $SESSION:claude tmux switch-client -t $SESSION保存后加执行权限chmod x ~/.ai/new-workbench.sh以后进入任何一个项目执行~/.ai/new-workbench.sh ~/work/order-batch脚本启动后终端底部会看到五个窗口每个窗口一个 Agent。所有窗口都在同一个 tmux session 里共享当前工作目录同时各自的输入输出都会被 tee 到 ~/.ai/logs/ 下。这样就算某个终端不小心关掉重新 tmux attach 一下就能恢复现场。4.2 快速向指定窗口发送指令开了工作台之后最常用的操作其实是“把这个任务交给某个 Agent”。手动切到对应窗口再粘贴指令当然可以但次数多了很烦。我在 ~/.zshrc 里加了一个简单函数ai() { if [ $# -lt 3 ]; then echo 用法: ai 项目目录|会话名 claude|codex|opencode|grok|pi 任务描述 return 1 fi local session$1 local agent$2 shift 2 tmux send-keys -t $session:$agent $* Enter }用法就变成ai order-batch claude 修复 orderId 为空的校验逻辑 ai order-batch codex review 一下当前分支的 diff这条命令的本质是把文本发送到指定窗口并模拟回车相当于替你完成了窗口切换和输入粘贴的操作。刚开始可能觉得没必要但它最大的价值是让“派发任务”这个动作和“当前在哪个窗口”解耦你可以舒服地切换窗口摸鱼……不对是舒服地专注其他工作任务派发不打断当前思路。4.3 日志目录就是整个工作台的“黑匣子”很多多 Agent 协作方案失败的根源是缺乏记录。每个 Agent 在对话里做了什么、输出过什么指令如果没有日志复盘时只能靠猜。所以我专门为工作台设计了日志目录~/.ai/logs/ └── ai-order-batch/ ├── claude.log ├── codex.log ├── opencode.log ├── grok.log ├── pi.log └── cost.log前五个文件来自各个 Agent 的 tee 输出cost.log 则是手动或脚本写入的额度记录。我一般每周末做一次简单统计五个 Agent 各自花在哪个项目上的时间比例、费用是否在预算内。不用做得多精细一个粗略的文本汇总就够用了。这里给你一个排查小技巧当某个 Agent 执行了一个奇怪的操作而你想知道它是怎么“想”出来的时候直接去对应的 log 文件里搜当时的指令通常能看到它输出的完整思考链。这个能力在普通聊天式用法里很容易被忽略但在工作台模式里非常救急。5. 实操记录从需求到合并五个工具怎么协同纸上谈兵没有意义我拿一个最近真实处理过的需求来讲讲工作台的实际运转流程。5.1 需求背景批处理任务出现重复推送需求本身不复杂订单批处理模块偶尔会对同一张订单推送两次通知需要改成幂等推送并且给外部接口调用加上重试和退避。代码在 src/batch 目录里整个模块大概 2000 多行。按照以前的方式我会手动读代码定位问题然后选一个 Agent 改完自己再复查。现在的工作台流程是这样的第一步我先用 Codex 做代码库全局排查让它找出所有可能触发重复推送的路径。在执行之前我给它指定的规则很明确“只分析不修改代码重点找出推送动作的触发条件以及状态更新的时间点。”Codex 在 diff 审查和代码追踪方面确实很强它很快定位出根因代码先执行了外部 HTTP 推送然后才更新数据库里的订单推送状态。如果推送成功但数据库更新失败下一次扫描就会把同一订单再次捞出来产生重复推送。第二步把修复任务派给 Claude Code。因为我需要它保持长上下文一边理解现有架构一边做多处修改。此时它已经能读到共享的 AGENTS.md知道该项目有“禁止在事务提交前执行外部请求”的约束所以给出的修复方案天然符合团队规范先更新订单推送状态并提交事务再发起外部推送请求同时增加一个带指数的重试逻辑。这样做的方案从架构上避免了推送到一半进程崩溃导致状态不一致的问题。第三步让 Claude Code 改完代码后我没有直接合入而是切到 Codex 窗口让它以审查者视角看 diff。Codex 会对每次 git diff 做逐行检查提示我修改后的代码里有一个边界没有覆盖正好是我在第一步发现的那个订单状态的边界场景。这种“一个人写、另一个人审”的流程虽然听起来传统但在 AI Agent 时代反而更重要因为每个模型都可能有自己的盲区。第四步让 Grok 生成批量测试数据。Grok 处理这种一次性任务又快又省钱我用 ai 指令给它派发了模拟订单 JSON 生成任务它返回的测试数据覆盖了正常订单、已推送订单、待重试订单等多个状态省了我不少手工构造的时间。pi 在这次任务中没有参与因为不涉及内网敏感数据。5.2 这次协同里真正起作用的三个环节回头复盘这次实操真正帮上忙的不是某一个 Agent 的强大而是三个设计环节第一所有 Agent 读的是同一份 AGENTS.md所以 Codex 不需要我重新交代项目命令和约束它自己就能理解“为什么 Claude Code 采用了事务内状态更新的写法”。上下文一致是所有协作的基础。第二每个 Agent 的工作被隔离在不同窗口都基于同一个项目目录但同一时间只有窗口对应的一个 Agent 在改文件。避免冲突不是靠自觉而是靠工作台的使用规则谁负责写、谁负责审在派发任务时就已经明确。第三每个窗口的输出都被记录到了日志目录。审查结束后我只需要扫一眼 cost.log 和各个 Agent 的日志就能写出一份简单的复盘Codex 定位多久、Claude Code 修改多少文件、Grok 生成多少测试用例。这个能力在协作效率复盘时特别有用。6. 常见问题与排查技巧实录把 Claude Code、Codex、OpenCode、pi、Grok 收进同一个工作台之后一定会遇到一些问题。这里把我踩过的坑整理成一张速查表方便你遇到时快速定位。现象大概率原因排查方法进入项目后 Agent 读不到 API Keydirenv 没有执行或 .env 格式有问题在项目目录执行direnv allow然后用 envClaude Code 读不到规则文件CLAUDE.md 符号链接失效或路径不对检查ls -l CLAUDE.md确认链接指向 docs/agent-rules.mdCodex 或 OpenCode 忽略了 AGENTS.md启动目录不在项目根目录确保启动 Agent 前先 cd 到项目根目录tmux 新窗口用 -c 参数指定工作目录某个 Agent 扫描了 node_modules 导致上下文爆掉忽略规则没写全或没有同时配置 .gitignore在共享规则文件里补充“禁止读取”目录列表确认 .gitignore 生效两个 Agent 同时改一个文件导致覆盖派发任务时没有隔离写权限严格要求同一时刻只有一个 Agent 可写必要时用git worktree分目录操作日志文件越来越大长时间运行没有做轮转macOS 上可以用newsyslog按天切分日志或写 cron 清理超过 30 天的日志某一窗口卡死但其他窗口正常该 Agent 的网络请求或本地命令挂起tmux 里按 Ctrl-b x 关闭对应窗格重开一个同名窗口即可不影响其他 Agent排查时我的心法是先看环境变量对不对再看工作目录对不对最后看规则文件读没读对。绝大多数问题都出在这三层的某一层。再分享一个规避冲突的进阶技巧如果同一个仓库需要多个 Agent 并行工作不要让他们在同一个目录里改文件而是给每个 Agent 创建一个独立的 git worktreegit worktree add ../order-batch-claude fix/order-push-idempotent git worktree add ../order-batch-review review/order-push-idempotent这样两个 Agent 的代码逻辑完全隔离最后通过 Git 分支合并从物理层面杜绝了互相覆盖的可能。代价是目录变多了但换来的是并行度值回票价。最后想多说一句关于共享规则文件的内容长度。我见过有人把 AGENTS.md 写成了 5000 字的团队手册结果每个 Agent 启动时都要把大量规则塞进上下文反而挤占了真正有用的代码信息。我自己的经验是共享规则文件最好控制在 200 行以内只写“换一个人也能立刻上手”的必要信息其他细节放到对应模块的子目录文件里。规则不是越多越好而是越准确越好。工作台搭建初期宁可少写等发现某些约束反复被 Agent 触犯时再把对应的规则补进去效果会好很多。