当你同时跑 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 的并行能力在一定程度上已经超过了人类的注意力带宽。

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

AI Agent 能力飙升 --- Claude Code、Codex CLI 已经能自主完成完整功能开发，不再需要逐行指导
并行开发成为常态 --- 一个人同时跑 3-5 个 Agent 处理不同任务，生产力可以翻倍
终端仍是主战场 --- 主流 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 感知的管理界面。

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

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

这就像在自行车上装电机------底层还是那辆自行车（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 增强型	原生终端型	AI 编排型
你要做什么	手动创建 3 个 Agent，在 TUI 中切换查看	创建 3 个 Agent，等通知环亮了再去看	描述目标，AI 自动拆分并分配
注意力成本	中等（需要主动切换查看）	低（被动接收通知）	最低（只需审批）
可控性	高（每一步都能看到）	高	低（AI 自主决策）
安装门槛	低（一条命令）	中（下载桌面应用）	中-高（需要配置）
跨平台	✅	部分（cmux macOS only）	✅
代表工具	Claude Squad, dmux	cmux, Emdash	Agent Orchestrator
适合谁	想快速上手、已熟悉 tmux 的开发者	macOS 用户、重度多 Agent 场景	愿意让 AI 自主运作的场景

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

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

三、重点工具深度解析

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

3.1 Claude Squad --- 品类开创者

一句话定位 ：最简单直接的多代理终端管理器，brew install 一步到位。

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

安装：

bash 复制代码

brew install claude-squad

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

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 原生终端

一句话定位：不是 tmux 的包装，而是为 AI Agent 从零构建的终端应用。

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、分割面板、发送按键

安装：

bash 复制代码

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

或直接从 GitHub Releases 下载 DMG。

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

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

3.3 dmux --- Unix 极简派

一句话定位：Unix 哲学的多代理管理------组合 tmux 和 Git Worktree，不多加一层抽象。

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 --- 新面板智能分割布局

安装：

bash 复制代码

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

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

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

3.4 CCCC --- IM 风格的多代理协作

一句话定位：把多代理协作变成群聊------支持飞书、钉钉、Telegram 远程管理。

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 提供嵌入终端的管理界面
自动化策略 --- 空闲检测、定时触发、需要回复的跟进提醒

安装：

bash 复制代码

pip install -U cccc-pair

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

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

3.5 Emdash --- 23 个 CLI 的大一统

一句话定位：Provider 无关的多代理桌面应用，开箱支持 23 个 CLI Agent。

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	cmux	dmux	CCCC	Emdash
路线	tmux 增强	原生终端	tmux 增强	协作通信	原生桌面
安装	`brew install`	DMG / `brew cask`	`curl	bash`	`pip install`
隔离方式	tmux + worktree	原生 pane	tmux + worktree	daemon + ledger	独立 session
通知系统	❌	✅ 通知环	❌	✅ IM 桥接	✅
远程管理	❌	❌	❌	✅ Web + IM	✅ SSH
支持 Agent 数	6+	任意	11+	8+	23
平台	跨平台	macOS 为主	跨平台	跨平台	跨平台
License	AGPL-3.0	AGPL-3.0	---	Apache-2.0	---
GitHub Stars	5.6k	11.6k	1k+	732	2.4k

快速选择指引：

要最快上手 → 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 的手动切换完全可以接受------窗口不多，巡逻一圈也就几秒钟。

bash 复制代码

# 安装
brew install claude-squad

# 启动 TUI
cs

# 在 TUI 中按 n 创建新 Agent，选择 Claude Code / Codex / Aider 等
# 按 j/k 切换 Agent，Enter 进入交互，Esc 返回列表

典型工作流：

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

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

bash 复制代码

# 安装 dmux
curl -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（简单粗暴）

bash 复制代码

# -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 桥接（远程可控）

bash 复制代码

# 安装
pip install -U cccc-pair

# 启动 daemon
cccc 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 选型总结

场景	推荐工具	一句话理由
个人开发，2-3 个 Agent	Claude Squad	门槛最低，两分钟上手
tmux 重度用户	dmux	不包装 tmux，增强 tmux
macOS + 5 个以上 Agent	cmux	通知环解决注意力分配问题
无人值守（低风险）	Claude Squad `-y`	自动接受，完全自主运行
无人值守（需审查）	CCCC	手机 IM 远程审查
团队 + ticket 管理	Emdash	23 个 Agent + Linear/Jira 直连
团队 + 远程协作	CCCC	飞书/钉钉/Slack 群管理

对这个品类的走向，有三个值得关注的趋势：通知系统会成为标配 （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 月，请以各仓库实际数据为准。

工具	仓库	Stars	路线
Claude Squad	smtg-ai/claude-squad	5.6k	tmux 增强
cmux	manaflow-ai/cmux	11.6k	原生终端
dmux	standardagents/dmux	1k+	tmux 增强
CCCC	ChesterRa/cccc	732	协作通信
Emdash	generalaction/emdash	2.4k	原生桌面
Agent Orchestrator	ComposioHQ/agent-orchestrator	5.6k	AI 编排
Agent Deck	asheshgoplani/agent-deck	1.6k	tmux 增强
Coder Mux	coder/mux	1.5k	原生桌面
Overstory	jayminwest/overstory	1.1k	AI 编排
Collaborator	collaborator-ai/collab-public	2k	原生桌面
smux	ShawnPana/smux	683	tmux 增强

延伸阅读

列表	链接
awesome-agent-orchestrators	andyrewlee/awesome-agent-orchestrators
awesome-cli-coding-agents	bradAGI/awesome-cli-coding-agents
awesome-claude-code	hesreallyhim/awesome-claude-code