当你并行跑 5 个 Claude Code：AI Coding 多袋里终端工具全景

一、前言

打开终端，启动 Claude Code，给它一个任务——重构支付模块。趁它干活的间隙，再开一个终端标签页，启动第二个 Claude Code 写单元测试。再开一个跑 Codex CLI 更新 API 文档。三个 AI Agent 同时推进，效率拉满。

然后问题来了。

切到标签页 1——Claude Code 在等你确认一个文件删除操作，不知道等了多久。切到标签页 2——测试跑完了，一屏绿色，但你没第一时间看到。切到标签页 3——Codex 报了个错，卡住了，你刚才在处理标签页 1 的时候它就已经停了。

在终端窗口间反复切换，本质上是一种低效的轮询——你不停地巡逻，只为了看看「谁需要你」。 当只跑一个 Agent 时，一个终端窗口就够了。但当并行运行 3-5 个实例时，AI 的并行能力在一定程度上已经超过了人类的注意力带宽。

为什么这个问题突然变得重要？因为三个变化同时发生：

1. AI Agent 能力飙升 — Claude Code、Codex CLI 已经能自主完成完整功能开发，不再需要逐行指导
2. 并行开发成为常态 — 一个人同时跑 3-5 个 Agent 处理不同任务，生产力可以翻倍
3. 终端仍是主战场 — 主流 AI 编码袋里（Claude Code 84.5k⭐、Codex CLI 68.4k⭐、Gemini CLI 99.5k⭐）都以终端为主要界面

2025 年底，GitHub 上开始出现一批专门解决这个问题的工具：Claude Squad、cmux、dmux、CCCC……到 2026 年 3 月，这个品类已经爆发到 25+ 工具，两家 YC 公司（cmux 和 Emdash）入局，GitHub 上有专门的 awesome list 追踪这个赛道。

本文基于对这 25+ 工具的系统调研，从三个维度展开：架构路线有什么本质区别、重点工具怎么选、不同场景的最佳工作流是什么——为正在或即将面对多 Agent 开发使用管理问题的开发者提供一份选型参考。

二、三条路线：25+ 工具的本质区别

面对 25+ 工具，第一反应可能是眼花缭乱。但仔细看架构，它们其实只走了三条路线。理解这三条路线，比逐个了解每个工具的功能清单重要得多——因为路线决定了工具的能力上限和适用边界。

这三条路线分别是：在 tmux 上做增强、从零构建原生终端、让 AI 编排 AI。它们的自动化程度递增，可控性递减。下面分别来看看它们各自的设计思路和适用边界。

2.1 路线一：tmux 增强型 — 在自行车上装电机

代表工具：Claude Squad（5.6k⭐）、dmux（1k+⭐）、smux（683⭐）

tmux 是 Unix 世界最成熟的终端复用器，已经有 20 多年历史。这条路线的思路很直接：不重新发明轮子，在 tmux 之上加一层 AI 感知的管理界面。

具体来说，这类工具做三件事：

1. 自动创建 tmux session + Git Worktree — 每启动一个 Agent，自动分配独立的 tmux 会话，并通过 Git Worktree 检出独立分支到单独目录，Agent 之间的代码修改互不干扰
2. 提供 TUI（终端用户界面） — 用一个统一界面查看所有 Agent 的状态、切换焦点
3. 管理生命周期 — 启动、暂停、恢复、合并代码

这就像在自行车上装电机——底层还是那辆自行车（tmux），但骑起来省力多了。

优势：轻量（通常只是一个二进制文件）、跨平台（tmux 在哪里都能跑）、学习成本低（熟悉 tmux 的开发者零门槛）。还有一个容易被忽视的优势：退出成本为零——即使管理工具本身停止维护，底层的 tmux 和 Git Worktree 仍然可用，你的工作流不会因此中断。

局限：受限于 tmux 的能力边界。tmux 没有原生的通知系统，不知道"哪个 Agent 在等你"——你还是得自己去看。

2.2 路线二：原生终端型 — 造一辆电动车

代表工具：cmux（11.6k⭐）、Emdash（2.4k⭐）、Collaborator（2k⭐）

这条路线的判断是：tmux 本身不是为 AI Agent 设计的，在它上面打补丁永远有天花板。不如从底层重新构建一个终端，把"管理 AI Agent"作为核心设计目标。

以 cmux 为例，它基于 Ghostty 的 libghostty（一个可嵌入的终端渲染库）用 Swift 从零构建了 macOS 原生应用。最关键的设计是通知环系统——当某个 Agent 需要你的注意时，对应的标签页会亮起蓝色圆环，你不需要逐个窗口巡逻，一眼就知道"谁需要你"。

这就像造一辆电动车——不是在燃油车上改装，而是底层架构就为电驱设计。

优势：UI/UX 体验远超 tmux 方案，通知系统从根本上解决了"注意力分配"问题，可以做更深度的集成（如 cmux 的内置浏览器）。

局限：平台受限（cmux 目前主要支持 macOS），项目成熟度相对较低（cmux 2 个月涨到 11k star，但仍是 beta 阶段），部分工具使用 AGPL 许可证，企业使用需注意合规。

2.3 路线三：AI 编排型 — 请一个 AI 调度员

代表工具：Agent Orchestrator（5.6k⭐）、Ruflo（28.5k⭐）

前两条路线都需要人来管理 Agent。这条路线更进一步：让 AI 自己管理 AI，人只在关键节点做审批。

以 Agent Orchestrator 为例，它本身就是一个 AI Agent——你给它一个目标（比如"重构支付模块"），它会自动拆分成子任务、分配给不同的 AI 编码袋里、监控执行进度、处理 CI 失败和 merge 冲突、最后提交 PR 等待你审查。

这就像请了一个 AI 项目经理——不只是帮你管终端窗口，而是帮你管整个开发流程。

优势：自动化程度最高，理论上你只需要定义目标和审批结果。

局限：可控性最低——当 AI 调度员做出错误决策时，排查链路比人工管理复杂得多。这类工具目前还处于早期阶段，适合特定场景而非通用替代。

2.4 三条路线总结

同一个任务——"重构一个 API 模块并更新对应的前端和测试"，三条路线的处理方式完全不同：

选择建议：如果你是 tmux 用户、追求简单可控，选路线一；如果你在 macOS 上重度使用多 Agent、最在意"谁需要你"的效率，选路线二；如果你愿意把管理权交给 AI、只做审批，尝试路线三。

需要说明的是，三条路线是对当前工具的简化归纳，实际情况更复杂。部分工具天然跨越路线边界——比如 CCCC 的核心能力是 IM 桥接和远程协作，很难被归入上述任何一条路线；Emdash 兼具原生桌面和工作流编排的特征。这个品类还在快速演化，分类方式也会随之调整。

三、重点工具深度解析

上一章讲了三条路线的本质区别。这一章从每条路线中选出最有代表性的工具，逐个拆解它的核心差异化、安装方式和适用边界。

3.1 Claude Squad — 品类开创者

Claude Squad（5.6k⭐）是这个品类最早出现、也是最广为人知的工具。用 Go 编写，基于 Bubble Tea 框架构建 TUI。

核心机制：每创建一个 Agent 实例，Claude Squad 自动做两件事——创建一个独立的 tmux session 和一个 Git Worktree 分支。Agent 在隔离环境中工作，完成后通过 TUI Review 差异并合并。

关键特性：

• Profile 系统 — 预定义多套 Agent 配置（Claude Code、Codex、Aider 等），一键切换
• Auto-accept 模式 — cs -y 启动后，Agent 遇到确认提示时自动通过，实现无人值守运行
• 支持 6+ Agent — Claude Code、Codex CLI、Aider、OpenCode、Amp、Gemini CLI

安装：

brew install claude-squad

安装后运行 cs 即可启动 TUI。配置文件位于 ~/.claude-squad/config.json：

{"default_program": "claude","profiles": [{ "name": "claude", "program": "claude" },{ "name": "codex", "program": "codex" },{ "name": "aider", "program": "aider --model ollama_chat/gemma3:1b" }]}

适合：想快速上手多袋里开发、已经熟悉 tmux、需要跨平台支持的开发者。这是入门多袋里工作流门槛最低的选择。

不适合：需要通知系统（Claude Squad 没有"谁需要你"的提醒机制）、需要远程/手机管理的场景。

3.2 cmux — AI 原生终端

cmux（11.6k⭐）是这个品类 star 数最高的项目，由 YC 支持的 Manaflow 团队开发，2 个月内从 0 涨到 11k star。Ghostty 创始人 Mitchell Hashimoto 公开推荐过这个项目。

核心机制：基于 Ghostty 的 libghostty（一个高性能终端渲染库）用 Swift/AppKit 构建原生 macOS 应用。这意味着 cmux 不依赖 tmux，它本身就是一个完整的终端模拟器。

杀手级功能 — 通知环系统：

这是 cmux 最核心的差异化。当 Agent 需要你注意时（比如等待确认、遇到错误），对应标签页会亮起蓝色通知环。按 ⌘I 打开通知面板，⌘⇧U 跳转到最新未读——再也不需要逐个窗口巡逻。

其他关键特性：

• 内置浏览器 — WebKit 浏览器面板与终端并排显示，支持脚本化 API，Agent 可以直接操作浏览器
• 垂直标签栏 — 显示 Git 分支、PR 状态、工作目录、端口、最新通知
• Ghostty 兼容 — 读取现有 ~/.config/ghostty/config，无缝迁移主题和字体配置
• CLI + Socket API — 支持脚本化创建 workspace、分割面板、发送按键

安装：

brew tap manaflow-ai/cmuxbrew install --cask cmux

或直接从 GitHub Releases 下载 DMG。

适合：macOS 用户、同时管理 3 个以上 Agent 的重度场景。通知环系统从根本上解决了"注意力分配"问题，这是 tmux 方案无法实现的。

不适合：非 macOS 用户（Linux/Windows 支持仍为次要）；需要 Session 进程恢复的场景（cmux 能恢复布局和元数据，但不会恢复正在运行的 Claude Code 进程）。

3.3 dmux — Unix 极简派

dmux（1k+⭐，dmux.ai）由 FormKit 团队开发，和 Claude Squad 同属 tmux 增强路线，但设计哲学更极简。

与 Claude Squad 的区别：Claude Squad 提供完整的 TUI 管理界面；dmux 更像一个快捷命令——按 n 弹出 Agent 选择器（支持多选），自动创建 worktree + tmux pane，然后让 tmux 本身来管理。不包装 tmux，而是让 tmux 做它擅长的事。

关键特性：

• 多选 Agent — 一次选择多个 Agent，同时启动到不同面板
• AI 生成分支名 — 根据任务描述自动生成语义化的分支名称
• 11+ Agent 支持 — 覆盖主流终端 AI Agent
• 自动 tiling — 新面板智能分割布局

安装：

curl -fsSL https://dmux.ai/install.sh | bash

适合：已经深度使用 tmux、不想要额外 TUI 层、偏好 Unix 风格"做好一件事"的开发者。

不适合：不熟悉 tmux 的新手（dmux 不会替你学 tmux）；需要状态通知或 Web UI 的场景。

3.4 CCCC — IM 风格的多袋里协作

CCCC（Coordinate Coding Collaboration Control，732⭐）走了一条完全不同的路：它不关注终端 UI，而是把通信和远程管理做到极致。

核心机制：CCCC 运行一个后台 daemon，所有状态存储在 append-only ledger（追加写入的日志）中。Agent 通过 MCP 协议连接到 daemon，Web UI（xterm.js）和 IM 桥接共享同一份状态。

杀手级功能 — IM 桥接：

CCCC 可以桥接到飞书、钉钉、Telegram、Slack、Discord。这意味着你可以在手机上通过飞书消息查看 Agent 进度、发送指令、接收通知。对于需要"挂机跑 Agent，有事手机看"的场景，这是独一无二的能力。

其他关键特性：

• IM 级消息语义 — @mention、已读回执、回复线程、注意力确认
• 8+ 运行时支持 — Claude Code、Codex CLI、Gemini CLI 等，支持自定义运行时
• Web UI — http://127.0.0.1:8848 提供嵌入终端的管理界面
• 自动化策略 — 空闲检测、定时触发、需要回复的跟进提醒

安装：

pip install -U cccc-pair

适合：需要远程管理（出门在外用手机看 Agent 进度）、国内团队（飞书/钉钉原生集成）、需要多人协作管理 Agent 的场景。

不适合：单人本地开发（杀鸡用牛刀）；不需要远程访问的场景（直接用 Claude Squad 更简单）。

3.5 Emdash — 23 个 CLI 的大一统

Emdash（2.4k⭐）由 YC W26 支持的 General Action 团队开发，定位是"Agentic Development Environment"。

与其他工具的关键区别：Emdash 不绑定特定 Agent。它自动检测你本地安装的 Agent CLI，开箱就支持 23 个——从 Claude Code、Codex CLI 到 Aider、Continue、Tabby 等。同时直接集成 Linear、GitHub Issues、Jira 等 ticket 系统，可以把一张 ticket 直接分配给 Agent。

关键特性：

• 23 个 CLI Agent 开箱支持 — 自动检测已安装的 Agent
• Ticket 系统集成 — 直接从 Linear/GitHub/Jira 拉取任务分配给 Agent
• SSH/SFTP 远程支持 — 在远程服务器上运行 Agent
• 桌面应用 — 跨平台（macOS、Linux、Windows）

安装：从 GitHub Releases 下载桌面应用。

适合：同时使用多种不同 Agent（不只是 Claude Code）、需要 ticket 系统集成的团队、需要远程服务器运行 Agent 的场景。

不适合：只使用单一 Agent（如仅用 Claude Code）的个人开发者——功能过剩，Claude Squad 就够了。

四、横向对比：一张表看清差异

五个工具讲完，信息量不小。这张表把关键维度拉齐，方便快速定位。

快速选择指引：

• 要最快上手 → Claude Squad。brew install 一步到位，两分钟跑起来。
• macOS + 重度多 Agent → cmux。通知环系统是当前品类中解决「谁需要你」问题的最佳方案。
• tmux 重度用户、不想要额外 TUI → dmux。不包装 tmux，而是增强 tmux。
• 需要远程管理 / 国内团队 → CCCC。飞书、钉钉原生集成，出门在外手机看进度。
• 多种 Agent + ticket 集成 → Emdash。23 个 CLI 开箱即用，Linear/GitHub/Jira 直连。

值得注意的是，通知系统和远程管理是这张表中最关键的两个分水岭。如果你的场景只需要本地管理 2-3 个 Agent，Claude Squad 或 dmux 完全够用；一旦 Agent 数量上升到 5 个以上，或者需要离开电脑后仍能掌控进度，cmux 的通知环或 CCCC 的 IM 桥接就变成了刚需，而非锦上添花。

五、实战工作流：三个场景，三套方案

工具选好了，怎么用？不同场景差异很大。以下三个场景覆盖了大多数开发者的实际需求，每个场景给出明确推荐和可操作的配置。

5.1 场景 A：个人开发，同时跑 2-3 个 Agent

典型需求：一个人做项目，想让 Agent A 重构后端、Agent B 写前端、Agent C 补测试，同时推进。

推荐方案：Claude Squad

理由很简单：门槛最低、上手最快。一条命令安装，一条命令启动，不需要任何额外配置。对于 2-3 个 Agent 的场景，tmux 的手动切换完全可以接受——窗口不多，巡逻一圈也就几秒钟。

# 安装brew install claude-squad# 启动 TUIcs# 在 TUI 中按 n 创建新 Agent，选择 Claude Code / Codex / Aider 等# 按 j/k 切换 Agent，Enter 进入交互，Esc 返回列表

典型工作流：

1. cs 启动 → 按 n 创建 3 个 Agent，分别给出不同任务指令
2. 在 TUI 列表中切换查看进度，有需要确认的进入交互
3. Agent 完成后，在 TUI 中 Review diff，确认后 merge 回主分支

如果你是 tmux 重度用户、不喜欢额外的 TUI 层，dmux 是更轻量的替代：

# 安装 dmuxcurl -fsSL https://dmux.ai/install.sh | bash# 在 tmux 中按 n，选择 Agent（支持多选），自动创建 worktree + pane

5.2 场景 B：长时间无人值守

典型需求：晚上睡觉前给 Agent 分配任务，第二天早上看结果。或者出门办事，Agent 在后台跑着。

推荐方案：Claude Squad auto-accept 模式 + CCCC IM 桥接（按需选一）

关键问题在于：Agent 遇到确认提示时怎么办？如果你不在电脑前，Agent 会一直等着，任务就卡住了。

方案一：Claude Squad auto-accept（简单粗暴）

# -y 参数让 Agent 自动接受所有确认提示cs -y

cs -y 启动的 Agent 遇到任何确认提示都会自动通过。这意味着 Agent 可以完全自主运行，但也意味着放弃了人工审查。

哪些任务适合 auto-accept：代码格式化、lint 修复、更新文档、生成样板代码——这类任务即使出错，影响范围也很小，git diff 一眼就能发现问题。

哪些任务不建议：涉及文件删除、数据库操作、依赖安装（npm install/pip install）、Git force-push、线上部署的任务。这些操作的副作用难以通过 diff 回溯。

进一步降低风险：如果需要长时间无人值守运行 auto-accept，建议在受限环境中执行——例如使用 Docker 容器或为 Agent 配置受限的文件系统权限，避免意外修改超出项目范围的内容。

方案二：CCCC IM 桥接（远程可控）

# 安装pip install -U cccc-pair# 启动 daemoncccc daemon start# 配置飞书/钉钉桥接（参考官方文档配置 Webhook）

配置完成后，Agent 的状态变更会推送到飞书/钉钉群。需要确认时，你可以在手机上直接回复。这比 auto-accept 更安全——你仍然保留了审查权，只是审查的界面从终端变成了手机 IM。

选择建议：低风险任务用 cs -y 自动跑；重要任务用 CCCC 保留远程审查能力。

5.3 场景 C：团队协作，多人 + 多 Agent

典型需求：3-5 个开发者，每人跑 2-3 个 Agent，需要协调分工、避免冲突、追踪进度。

推荐方案：Emdash（ticket 集成场景）或 CCCC（远程协作场景）

团队场景和个人场景有本质区别：不是「一个人管多个 Agent」，而是「多个人管多个 Agent」。核心需求变成了可见性——谁在做什么、哪个 Agent 负责哪张 ticket、进度如何。

Emdash 的优势在于 ticket 集成：

• 从 Linear / GitHub Issues / Jira 直接拉取 ticket
• 把 ticket 分配给特定 Agent
• Agent 完成后自动关联 PR 到 ticket
• 团队成员通过 Emdash 看到所有 Agent 的状态

CCCC 的优势在于远程协作：

• 所有 Agent 状态共享到同一个飞书/Slack 群
• 团队成员可以 @mention 特定 Agent 发送指令
• 已读回执和回复线程让协作有据可查
• 不需要每个人都装同一个管理工具——IM 就是界面

选择建议：如果团队已经用 Linear/Jira 管理项目，Emdash 的 ticket 集成是最自然的选择；如果团队分布式办公、需要手机随时介入，CCCC 的 IM 桥接更实用。

5.4 选型总结

对这个品类的走向，有三个值得关注的趋势：通知系统会成为标配（cmux 已经证明了这一点）；「Best of N」策略会被更多工具采用——同一个任务交给多个 Agent，取最好的结果（Coder Mux 已经在做）；远程/手机管理会从加分项变成必备项，因为 Agent 越来越能自主运行，人的角色正在从「操作者」变成「审批者」。

六、结语：从终端复用到 Agent 编排

回头看终端工具的进化，每一次跳跃都对应着开发范式的根本变化：

• screen（1987）→ SSH 远程开发时代。开发者第一次可以断开连接后恢复工作。
• tmux（2007）→ 多任务本地开发时代。一个终端窗口不够了，需要分屏、多 session。
• Claude Squad / cmux（2025-2026）→ AI Agent 并行开发时代。一个人不够了，需要管理一群 AI。

这不是简单的工具升级。screen 到 tmux 是「人做更多事」；tmux 到 Claude Squad/cmux 是「人管理 AI 做更多事」。角色从执行者变成了管理者——而管理多个 AI Agent 需要的工具，和管理多个终端窗口需要的工具，本质上不是一回事。

这就是为什么 25+ 工具在一年内涌现。开发者不是在寻找「更好的 tmux」，而是在寻找一种全新的工作界面——它需要知道「谁需要你」（通知系统），需要让你随时随地介入（远程管理），需要在你不在时自主运行（auto-accept）。

这个品类还在早期。今天的 Claude Squad 和 cmux 可能只是 1.0 版本，就像 2007 年的 tmux 还不知道自己会成为每个服务器的标配。但方向已经明确：终端的下一个形态，不是更好的窗口管理器，而是 AI Agent 的调度中心。

如果你还在用裸 tmux 管理多个 Claude Code，不妨今天就试试 brew install claude-squad。两分钟的安装时间，换来的是一种完全不同的工作方式。

附录：资源汇总

工具仓库

以下 Stars 数据截至 2026 年 3 月，请以各仓库实际数据为准。

延伸阅读