workmux:基于 Git Worktree 与 Tmux 的多 AI Agent 并行开发管理神器
你同时开着 Claude Code、Codex、Gemini,让它们分别改动登录、缓存和测试模块。半小时后,问题就出现了:一个 Agent 还卡在权限确认里,一个把 dev server 直接跑在同一个终端,还有一个改了一半文件,你不得不在不同分支间来回确认当前工作状态。更要命的是,几个任务共用同一个工作目录时,频繁地切换分支、暂存修改、恢复现场,很容易把开发节奏打得稀碎。
这次要聊的 workmux,正是为这种场景准备的。它选择把开发者已经熟悉的东西串联起来:用 git worktree 负责隔离工作目录,用 tmux 负责窗口和会话,用 Claude Code、Codex、Gemini 这类 CLI Agent 继续负责写代码。

目前该项目在 GitHub 上已获得 1.7k+ Star。

每个任务一个窗口
workmux 的做法很直接:给每一个任务创建一个独立的 git worktree,再对应配上一个 tmux 窗口。所以当你需要拆分两个任务时,不必在同一个目录里反复执行 git switch,也不用手动开一堆终端。直接用 workmux 起两个工作区,每个工作区都拥有自己的分支、目录、终端状态、编辑器 pane、dev server 和 AI Agent。
日常启动任务大概是这样:
workmux add refactor-user-model -p "Refactor the User model to use composition"
workmux add add-search-endpoint -p "Add a /search endpoint with pagination"
workmux dashboard
每个 Agent 在各自的 worktree 里干活。想看进度,只需要切一下 tmux 窗口,或者打开 workmux dashboard。这正是它适合多个 AI Agent 并行改代码的关键:目录、终端、提示词全都按任务隔离开,你不再需要反复琢磨“当前这个终端到底归属于哪个分支”。
这个思路和之前聊过的 Vibe Coding 实用技巧[1]中提到的 git worktree 隔离本质相同:一个 Agent 一个目录、一个分支、一项任务。区别在于,workmux 顺手把窗口、pane、提示词以及收尾命令一并管理了起来。

比手写 worktree 省事的地方
纯手写 git worktree add 当然也能实现隔离,但新 worktree 通常是一个干净目录,.env、依赖目录、缓存、开发服务都得重新处理一遍。workmux 在配置里支持 files.copy、files.symlink 和 post_create,可以在创建 worktree 时自动复制配置文件、软链依赖项、执行初始化命令。
比如可以这样配置:
post_create:
- mise use
files:
copy:
- .env
symlink:
- .next/cache
panes:
- command: <agent>
focus: true
- command: npm run dev
split: horizontal
它把这些准备动作收进一个入口:开分支、准备环境、启动 Agent、运行监听命令,一条命令就能全部搞定。
workmux 支持通过 --prompt、--prompt-file、--prompt-editor 把任务提示词注入到 Agent pane。内置 Agent 包括 Claude、Codex、OpenCode、Gemini、Kiro CLI、Vibe、Pi、Oh My Pi 等。如果你想用两个不同 Agent 尝试同一个方向,可以这样:
workmux add my-feature -a claude -a gemini -p "Implement the new search API integration"
如果只是想开两个同类 Agent 分头处理任务,也能这样用:
workmux add my-feature -n 2 -p "Implement task #{{ num }} in TASKS.md"
这比手动复制 prompt、开窗口、切换目录要省去大量零碎操作。它还提供了 /worktree 和 /coordinator 这类 Agent skill 工作流。前者适合在当前的 Agent 对话里,把某个子任务甩到新的 worktree;后者适合让一个协调 Agent 负责分配任务、启动多个 worktree Agent、等待结果并按顺序合并。这种用法契合常见的 Agent 分工方式:主 Agent 负责分工和调度,子 Agent 在隔离目录里干具体的活。
Anthropic 三智能体协同架构(受 GAN 启发)
AIGuide:AI 应用开发、AI 编程实战与面试指南[2] 的 Harness Engineering 文章,对 Agent = Model + Harness、多 Agent 分工和运行环境这些概念有详细介绍。
多个 Agent 并行时,最容易混乱的其实是后半段:谁做完了,谁还在等待输入,哪个分支需要合并,哪个 worktree 可以删除。workmux 提供了 workmux list、workmux dashboard、workmux sidebar 这些查看入口,还能把 Agent 状态显示到 tmux 的窗口名里。

这类状态面板非常关键。之前写 Claude Code Agent View[3] 时就说过,并行 Agent 真正消耗人的地方,往往不是同时启动的时刻,而是启动之后要持续判断哪个在跑、哪个在等权限确认、哪个可以验收。workmux 的 dashboard 和 sidebar 解决的正是这层管理成本。
任务完成后,本地合并可以走:
workmux merge
它会一并处理合并、删除 worktree、关闭 tmux 窗口、移除本地分支这条链路。如果走 PR 流程,也可以在 PR 合并后再用 workmux remove 清理。
下面是实际使用效果的视频演示:观看视频
怎么装
常用 Homebrew 一键安装:
brew install raine/workmux/workmux
Cargo 方式:
cargo install workmux
Nix 方式:
nix profile install github:raine/workmux
也支持脚本安装,不过生产机器上直接 curl | bash 之前最好先看一眼脚本内容。装完后,先确认自己在一个 git 仓库里,并且 tmux 已经运行。workmux 需要一个 terminal multiplexer,除了 tmux 之外,它还支持 WezTerm、Kitty、Zellij 作为替代后端,但很多高级体验还是围绕 tmux 展开的。
初始化配置可以运行:
workmux init
这会生成 .workmux.yaml。不配置也能用默认值,但如果打算长期用它跑 Agent,建议至少把 <agent> pane、常用 dev server、.env 的复制或依赖软链配好。
有什么限制
workmux 能把工作区隔开,但解决不了 Git 冲突。如果多个任务改到同一块代码,workmux 能做的是让 Agent 在隔离目录里工作,并提供 /merge、workmux rebase、workmux merge 这类收尾工具。冲突最终还是需要人来理解和处理。
更隐蔽的是“不冲突但语义已经变了”的情况。比如两个 Agent 分别修改同一个公共 DTO、路由表、配置文件,一个加字段,一个删字段,Git 也许能顺利合并,但接口行为已经不一样了。所以在并行之前,最好先把哪些目录可以改、哪些文件要避开、改完后跑哪些测试写清楚。
还有一个细节:workmux sidebar 只支持 tmux;Codex 状态跟踪也有限制,只能跟踪 working/done,没有 waiting 状态,并且需要在 ~/.codex/config.toml 中启用 hooks。换句话说,它更适合已经愿意把主要编码流放在终端里的开发者。
写在最后
如果只是偶尔让 AI 改一个小 bug,直接在当前项目里跑 Agent 就足够了,没必要额外引入一套工作流。但如果已经开始让多个 Agent 同时做事,比如一个写实现、一个补测试、一个做重构验证,那么 workmux 这种“一个任务一套 worktree + 窗口 + Agent”的方式,会让并行任务互不干扰。对于已经习惯在终端里跑 Claude Code、Codex、Gemini CLI 的开发者,workmux 会是一个很趁手的选择。
项目地址:https://github.com/raine/workmux
引用链接
[1]Vibe Coding 实用技巧: https://javaguide.cn/ai-coding/the-cool-tricks-for-vibe-coding.html[2]Harness Engineering: https://javaguide.cn/ai/agent/harness-engineering.html[3]Claude Code Agent View: https://javaguide.cn/ai-coding/claudecode-agentview.html