这个赛道已经分出三条路了
2026 年，"同时跑多个 Coding Agent"已经不是一个新问题了。但解决方案分成了三个完全不同的方向：
第一条路：桌面 IDE 化。Superset（12K Star）和 Emdash（5K Star，YC W26）走的是这条路。它们是 Electron/Tauri 桌面应用，有完整的 GUI——拖拽管理任务、内置 diff 查看器、一键打开编辑器、甚至能接 Linear 和 Jira 自动派活。Superset 号称能同时跑 10+ 个 agent，Emdash 还支持 SSH 远程机器。这类工具的目标用户是"想要一个好看的控制面板"的人。
第二条路：CLI 桥接器。claude_codex_bridge（3K Star）、agent-of-empires（2.7K Star）走的是这条路。本质是把多个 agent 的输出汇总到一个终端界面，有些还加了 Web UI 支持手机监控。它们更轻量，但功能也更有限——主要是"看"而不是"管"。
第三条路：终端原生。Claude Squad（8K Star）走的就是这条路。没有 GUI，没有 Electron，就是一个 Go 二进制，跑在你的终端里。它的全部魔法来自两个 Unix 老工具：tmux 和 git worktree。
分类到这里，问题来了：为什么一个"只是包装了 tmux 和 git worktree"的工具有 8K Star？答案不在于它用了什么技术，而在于它做对了什么取舍。
Claude Squad 到底做了什么
先说结论：Claude Squad 做的事情可以总结成三句话。
第一，每个 Agent 一个 tmux session。你按 n 创建新任务，它在后台起一个 tmux session，把 Claude Code（或者 Codex、Aider、Gemini）跑在里面。你在 TUI 界面上看到所有 session 的状态——Running、Ready、Paused、Loading。按 Enter 进去跟 agent 对话，按 Ctrl-Q 退出来继续看别的。
第二，每个任务一个 git worktree。这是关键设计。每个 session 不是在同一个目录里改代码，而是创建了一个独立的 git worktree——有自己的分支、自己的工作目录。Agent A 在 worktree-A 里改代码，Agent B 在 worktree-B 里改代码，互不干扰。改完了你 review diff，满意了再 merge 回主分支。
第三，Auto-Yes 模式。加 -y 参数启动，所有 agent 的确认提示自动按 Enter。这就是"后台批量跑任务"的基础——你不用盯着每个 agent，让它们自己跑，跑完了你再去 review。
听起来很简单对吧？确实简单。但简单的东西做到位了就不简单。
架构拆解：为什么是 tmux + git worktree
读了源码（Go，总共大概 5000 行），核心架构很清晰：
Claude Squad 架构
├── app/ — TUI 界面（Bubble Tea 框架）
├── session/
│ ├── instance.go — 实例管理（状态机：Loading→Running→Ready→Paused）
│ ├── tmux/ — tmux 会话管理（创建、销毁、捕获输出、检测 trust prompt）
│ └── git/ — worktree 管理（创建、diff 统计、cleanup）
├── config/ — 配置持久化（~/.claude-squad/config.json）
└── daemon/ — 后台进程管理（Unix/Windows 适配）tmux 的选择很聪明。Claude Code、Codex 这些工具本身就是终端应用，它们需要一个真实的 terminal 来运行。tmux 提供了：
- 独立的 terminal session——每个 agent 有自己的 stdin/stdout
- detach/reattach——你可以退出来看别的，agent 继续跑
- pane capture——TUI 界面可以读取每个 session 的当前输出来显示预览
git worktree 的选择更聪明。它解决了一个具体问题：多个 agent 同时改同一个代码库不会冲突。每个 worktree 是一个独立的工作目录，有自己的分支。Claude Squad 在 ~/.claude-squad/worktrees/ 下面创建这些 worktree，命名规则是 {branch}_{timestamp}。
这两个工具加在一起，Claude Squad 实际上构建了一个隔离的、可并行的、可暂停恢复的 agent 执行环境，而且几乎零依赖——tmux 和 git 是大多数开发机器上已经装好的东西。
跟 Superset 和 Emdash 比：各取所需
这三个工具解决的是同一个问题——"如何管理多个 coding agent"——但方式完全不同。与其列一个笼统的对比表，不如直接说清楚各自的取舍。
Claude Squad vs Superset
Superset 是桌面应用，TypeScript 写的，需要 Bun 运行时。它有完整的 GUI：可视化的任务列表、内置 diff 编辑器、一键在 VS Code 里打开 worktree、preset 系统（可以预配置每个 agent 的环境）。如果你喜欢用鼠标操作、喜欢可视化的 diff 界面、想要在编辑器和终端之间无缝切换，Superset 的体验确实更好。
但 Superset 的代价是重。它需要 Bun、需要 Caddy（开发时）、macOS only（Windows/Linux untested）。安装配置比 Claude Squad 复杂得多。而且它本质上是一个 Electron 风格的桌面应用，资源占用不是一个 Go 二进制能比的。
Claude Squad 的优势是轻。一个 curl | bash 装完，跑 cs 就开干。它跑在终端里，不需要 GUI，不需要额外的运行时。如果你是 tmux 用户、习惯全键盘操作、在远程服务器上工作，Claude Squad 就是更自然的选择。
Claude Squad vs Emdash
Emdash 是三者中最有野心的。YC W26 出品，支持 SSH 远程机器、接 Linear/Jira/GitLab 自动派活、有完整的 PR review 流程。它不只是"管理多个 agent"，它是想做一个"AI 原生的开发平台"。
但野心大意味着复杂度也大。Emdash 的功能最多，学习曲线也最陡。如果你只是想"同时跑 3 个 Claude Code 帮我修 bug"，Emdash 有点杀鸡用牛刀。
Claude Squad 的哲学完全不同——它只做一件事：让你在一个终端窗口里管理多个 agent session。不接 issue tracker，不做 PR review，不做远程机器管理。但这件事它做得很干净。
一个真实的使用场景
我手头有一个 Go 后端项目，积了 5 个 issue。其中 3 个是独立的 bug fix，2 个是小 feature。我决定用 Claude Squad 批量处理。
先装好：
curl -fsSL https://raw.githubusercontent.com/smtg-ai/claude-squad/main/install.sh | bash
# 装完后 cs 在 ~/.local/bin/cs
# 前提：tmux 和 gh 已经装好进入项目目录，跑 cs。TUI 界面出来了，底部有快捷键提示。我按 n 创建第一个 session，命名为 "fix-auth-bug"，然后 Enter 进去给 Claude Code 下指令：
请修复 issue #42：当 JWT token 过期时，refresh 接口返回 500 而不是 401。看一下 auth/middleware.go 和 auth/refresh.go。然后 Ctrl-Q 退出来，按 n 创建第二个 session，命名为 "fix-timeout"，进去下指令：
请修复 issue #58：数据库连接池在高并发时超时。看一下 db/pool.go 的连接复用逻辑。同样退出来，创建第三个、第四个。5 个任务分配完，我按 tab 切到 diff 预览视图，看着它们各自在自己的 worktree 里干活。
实际结果
大概 15 分钟后，我逐个检查。情况是这样的：
- fix-auth-bug：修得不错。Claude Code 正确找到了 refresh token 逻辑的问题，加了过期检测和正确的 401 返回。测试也过了。✅
- fix-timeout：改了连接池的超时配置，但没找到根因——根因是连接没有正确释放回池里，它只改了超时时间。需要我自己再改。⚠️
- feature-export：CSV 导出功能基本可用，但表头用的是数据库字段名而不是用户友好的名称。能用但不体面。⚠️
- fix-race-condition：这个比较复杂，Claude Code 改了半天没改对，session 状态卡在 Running。我进去看了一眼，它在两个方案之间反复横跳。我手动给了提示才搞定。❌
- feature-metrics：加了 Prometheus metrics，写得很规范。唯一的问题是忘了加到 Dockerfile 里暴露端口。✅（差一点）
5 个任务，2 个完全 OK，2 个需要小幅修改，1 个需要我介入。大概 60 分的水平——跟单独跑 Claude Code 的质量差不多，但关键是我只花了 15 分钟就分配完了所有任务，然后 15 分钟 review。如果一个一个跑，至少要一个小时。
踩过的坑
用了一周，几个真实的问题：
① tmux pane capture 经常报错。这是 issues 里最高频的 bug（#51，18 条评论）。TUI 界面在刷新预览时偶尔会报 "Error capturing pane content: exit status 1"。不影响 agent 运行，但看着烦。原因是 tmux 的 capture-pane 命令在某些时序下会失败。目前没有彻底修复。
② session 创建超时。issue #132 里很多人遇到：fresh install 后创建 session 直接报 "tim out waiting for tmux session"。官方 FAQ 说"更新 Claude Code 到最新版"，但这不是总能解决的。我自己在一台 VPS 上也遇到过，原因是 tmux 版本太老（2.6），升到 3.3a 就好了。
③ Auto-Yes 模式太激进。-y 模式下所有确认都自动通过，包括 Claude Code 的 trust prompt。这意味着 agent 可以执行任何命令，包括 rm -rf。在本地开发机上我勉强能接受，但在服务器上我绝对不敢开。没有细粒度的权限控制——要么全开，要么全关。
④ worktree 清理要手动。session 结束后 worktree 不会自动删除。跑了一周，~/.claude-squad/worktrees/ 下面积了一堆目录。虽然 git worktree 本身不占太多空间（只是文件的引用），但看着乱。issue #121 有人提了配置 worktree 路径的 PR，但还没合并。
⑤ 没有 MCP server 配置。issue #143 里有人发现，通过 Claude Squad 启动的 Claude Code 没有加载 MCP server。原因是 tmux session 里的环境变量跟你的交互式 shell 不一样。需要手动在 Claude Squad 的 config 里配置环境变量，但文档几乎没提。
谁应该用，谁不应该
适合：
- 终端重度用户——已经在用 tmux，不想装桌面应用
- 需要在远程服务器上跑 agent——SSH 进去直接
cs - 同时有 3-5 个独立的编码任务想并行处理
- 想要最轻量的方案——一个 Go 二进制，零配置
不适合：
- 不熟悉 tmux——Claude Squad 的底层就是 tmux，遇到问题你得会排查
- 想要 GUI 体验——去看 Superset 或 Emdash
- 需要接 issue tracker 自动派活——Emdash 做得更好
- 需要细粒度的权限控制——Claude Squad 没有
- Windows 用户——虽然有 Windows 支持，但 tmux 在 Windows 上体验很差
取舍的本质
Claude Squad 的核心取舍是：用终端的限制换来了极致的轻量。
它不给你 GUI，所以你得会用 tmux。它不给你远程机器管理，所以你得自己 SSH。它不给你权限控制，所以你得信任你的 agent。它不给你 issue tracker 集成，所以你得自己分配任务。
但换来的是：一个 Go 二进制，curl | bash 安装，3 秒启动，几乎零资源占用，在任何有 tmux 的机器上都能跑。
对于"我就是想在终端里同时跑几个 agent 帮我改代码"这个需求，Claude Squad 是目前最干净的方案。Superset 和 Emdash 更强大，但它们解决的问题更多、引入的复杂度也更高。
选谁取决于一个简单的问题：你想活在终端里，还是想活在桌面应用里？