先看结论：30 秒选出适合你的方案

这五种工具看起来都与多 Agent 开发有关，但它们解决的问题并不相同。

最关键的区别：谁来关注会话状态。

• cmux： 把通知和状态显示给你，由你决定怎么处理。
• Claude Squad： 帮你把任务放进不同的代码工作区，方便检查和管理改动。
• 子 Agent： 帮你把一个任务拆成更小的任务。
• tmux： 提供管理终端和编写自动化脚本的基础能力。
• Polter： 尝试让另一个 AI 会话协助查看和操作其他终端。

它们并非完全互相替代。选择时，先找出自己最费时间的环节，比比较功能数量更有用。

五种方案对比：它们到底差在哪里？

看完这张表，可以先把选择缩小到一个问题：

你现在最缺的是会话提醒、代码隔离、任务拆分，还是 AI 协助管理？

下面按原来的思路，逐一看每种方案的优势、限制和适用场景。

cmux：和 Polter 最接近，但控制方式不同

cmux 值得优先比较，因为它和 Polter 都基于 Ghostty。两者都关注 AI 编码时的多会话体验，但设计思路不同。

cmux 擅长什么？

cmux 是一款面向 AI 编码 Agent 的 macOS 终端。它在终端界面中增加了工作区侧栏、竖排标签和通知功能。

它能显示的信息包括：

• Git 分支和关联的 PR 状态
• 当前工作目录和监听端口
• 每个工作区的最新通知

当 Agent 需要你处理时，对应窗格会显示通知提示，标签页也会高亮。cmux 支持终端 OSC 9/99/777 通知序列，也提供 cmux notify 命令，可以接入 Claude Code 等工具的 hook。

除此之外，cmux 还提供：

cmux 使用 Swift 和 AppKit 开发，也能读取现有的 Ghostty 配置。

它的设计理念可以简单理解为：提供一套可组合的工具，由你决定怎么组织 Agent 工作流。 它不会替你决定每个 Agent 应该做什么。

Polter 和 cmux 有什么不同？

Polter 的工作方式是：指定一个 Claude Code 会话充当“总管”，由它读取其他标签页的屏幕文字、向终端输入内容、打开新标签页，并协助组织任务。任务面板会在重启后保留状态。各终端的输出会逐行存盘，第二天可以用 grep 搜索；“角色”能保存启动参数（技能、提示词、模型），“项目”能保存全部标签页、目录和历史并一键恢复；总管也能自己截图。

由角色启动的 Claude Code 会在一轮结束时主动告诉 Polter，总管直接收到通知，不必等屏幕静止；这目前仅限 Claude Code，其他工具仍靠监听屏幕活动。

不过，有一个重要限制：Polter 不会直接判断某个 Agent 是“卡住了”还是“正在思考”。 它提供屏幕静止了多久等信息，具体判断交给总管会话。

这也意味着额外成本。总管本身需要运行模型，会消耗 token；实际花费取决于它需要介入多少次，而不只是任务运行了多久。

cmux 也提供 CLI 和 socket API，因此开发者可以尝试在它上面搭建自己的自动化流程。但 cmux 文档是否支持读取其他窗格的完整屏幕文字，本文未能核实。Polter 的相关能力是现成实现，不过目前也只在 Claude Code 上经过测试。

什么时候选 cmux？

适合你，如果：

• 你使用 macOS，希望自己掌握会话状态。
• 你主要需要清楚的通知和界面，不希望另一个 AI 替你判断。
• 你需要终端旁边的浏览器窗格，让 Agent 访问本地开发服务。

可以考虑 Polter，如果：

• 你不想总是手动切换窗口检查状态。
• 你希望另一个 AI 会话协助查看终端并执行操作。
• 你能接受额外的模型调用成本，以及目前只在 Claude Code 上测试过的限制。

Claude Code 子 Agent：它解决的是任务拆分

Claude Code 子 Agent 和 Polter 容易被放在一起比较，但它们处理的不是同一个问题。

子 Agent 擅长什么？

当主会话被搜索结果、日志或文件内容塞满，而这些内容后续又不需要反复引用时，可以把辅助任务交给子 Agent。

子 Agent 有自己的上下文窗口、系统提示词和工具权限。任务完成后，它会把摘要返回给父会话。

对于适合较小模型完成的任务，也可以通过模型配置控制成本。

Polter 和子 Agent 的核心区别

简单说，子 Agent 解决的是“怎么把一项工作拆开”；Polter 解决的是“怎么照看多个已经运行的会话”。

两者并不冲突。你可以先用子 Agent 完成代码调查，也可以在不同终端启动多个 Claude Code 会话，再选择合适的方式管理它们。

别忽略 Claude Code 自带的多会话功能

如果只拿子 Agent 和 Polter 比较，会遗漏 Claude Code 自身正在发展的多会话功能。

Agent teams 的拆分窗格模式需要 tmux 或 iTerm2。

Agent view 与 Polter 在多会话管理上有一定重叠，但操作方式不同：Agent view 提供官方会话面板；Polter 则尝试把其他终端的屏幕和键盘操作交给另一个 AI 会话。

什么时候选子 Agent 或官方功能？

• 只是想把一个会话里的辅助任务拆出去： 先用子 Agent，不必额外安装工具。
• 想查看和管理多个 Claude Code 会话： 可以先试 Agent view，同时留意它的研究预览状态。
• 已经有多个独立终端，希望减少手动检查和操作： 再考虑 Polter。

Claude Squad：当代码隔离比自动管理更重要

Claude Squad 的重点不是让 AI 自动照看其他终端，而是让多个 Agent 在不同的代码工作区中执行任务。

Claude Squad 擅长什么？

Claude Squad 是一个终端界面工具，可以管理 Claude Code、Codex、Gemini 和 Aider 等本地 Agent。

根据项目 README，每个任务会使用独立的 Git worktree，并在自己的分支上工作。这可以降低多个 Agent 同时修改同一仓库时互相影响的风险。

它还支持：

• 应用改动前预览 diff
• 使用快捷键提交并推送到 GitHub
• 提交改动后暂停会话

使用前需要安装 tmux 和 GitHub CLI（gh）。项目采用 AGPL-3.0 许可证。

Polter 和 Claude Squad 的核心区别

什么时候选 Claude Squad？

更适合以下情况：

• 多个 Agent 可能同时修改同一个仓库。
• 你希望每个任务都在独立分支和工作区里运行。
• 你需要先检查 diff，再决定是否采用改动。

如果代码隔离是主要需求，Claude Squad 更直接。Polter 目前没有独立 worktree 隔离（0.10 的计划里有，但还没做，不要当成已有），因此不能把它当作 Claude Squad 的替代品。

反过来，如果代码隔离不是当前瓶颈，你更在意会话状态和减少手动操作，Polter 才可能更符合需求。

tmux：已有成熟脚本，就不必为了多 Agent 而迁移

tmux 是终端复用器，并不是专门为 AI 编码 Agent 设计的工具。但它的终端管理和脚本能力，已经能支持很多多会话工作流。

tmux 擅长什么？

tmux 可以在一个终端界面中创建和控制多个终端。你也可以先脱离会话，让任务继续运行，之后再重新连接。

它还提供一些有用的监测和控制命令：

这些功能让你可以通过脚本组织多个终端、读取输出，并按预先设定的规则执行操作。

Polter 和 tmux 的核心区别

tmux 提供终端管理、持续运行和脚本控制的基础能力。至于谁来查看输出、判断会话状态、决定下一步怎么做，通常需要你自己处理，或另外编写脚本。

Polter 则把这部分工作组织成一个 AI 管理流程：它提供屏幕静止时长等信息，再由总管会话进一步判断和操作。

两者不是简单的替代关系。Polter 更偏向现成的 AI 管理流程；tmux 更灵活，也更适合已经搭好自动化工作流的人。另外，Polter 能一键恢复标签页、目录和历史，但不等于 tmux 那样让进程留在后台继续跑。

什么时候选 tmux？

• 已有成熟的 tmux 脚本： 如果现在的工作流运行稳定，没有必要仅仅因为开始使用多个 Agent 就迁移。
• 需要远程运行和重新连接： tmux 明确支持脱离会话后重新连接。
• 需要在更多类 Unix 系统中使用： tmux README 列出了 OpenBSD、FreeBSD、NetBSD、Linux、macOS 和 Solaris。

Polter 目前没有 Linux 安装包，需要自行编译。其他系统的支持情况，应以项目最新发布说明为准。

最后怎么选？先看自己最费时间的环节

如果你还在犹豫，可以直接按下面的清单选择：

Polter 的特别之处，不是它能取代所有工具，而是它尝试改变多会话工作的管理方式：不再要求开发者持续切换每个终端，而是让一个 AI 会话协助观察其他会话，并在需要时采取行动。

但它并不适合所有人。使用前需要接受三个现实限制：

1. 额外的模型调用： 总管会话会消耗 token。
2. 代码工作区目前不隔离： 多个任务共享当前代码库；worktree 在 0.10 的计划里，但还没做，不要当成已有。
3. 测试范围有限： 目前只在 Claude Code 上经过测试；Linux 暂无安装包。

分屏层叠、其他 CLI 的 hooks 和 worktree 也都在 0.10 的计划里，目前都没有实现。

如果你的主要需求是通知、代码隔离或任务拆分，其他工具可能已经足够。先找出自己最耗时的管理环节，再选择工具，比单纯追求同时运行更多 Agent 更有效。