cmux：给 AI 编码 agent 造一个原生终端，而不是又一个 Electron 壳

项目：manaflow-ai/cmux · Swift · macOS

当你同时开 8 个 Claude Code 会话

你同时开着 6 个 Claude Code 会话：一个在重构认证模块，一个在写测试，一个在调 bug，两个在跑长任务等结果。macOS 的通知中心每隔几分钟弹一条"Claude is waiting for your input"——但哪一个是哪个？你切到 Ghostty，6 个标签页挤在一行，标题被截断成"Claude | auth | my-pro..."。你挨个点开看，第三个才是在等你的那个。

这就是 manaflow 的创始人遇到的问题。他的解决方案不是又一个 agent 编排器——那些东西把你锁进它的工作流里。他做的是一个终端：原生 macOS app，Swift/AppKit 写的，用 libghostty 渲染，加了 AI agent 需要的东西。

三个核心设计

1. 通知环：不是弹窗，是视觉信号

cmux 不靠 macOS 通知中心。每个 pane 有一个蓝色环——agent 在等你时亮起来，你回应后熄灭。标签页在侧边栏也会高亮。

这个设计的关键不是"通知"，是**"定位"**。你不需要读通知内容，不需要切标签页找，蓝色环直接告诉你"这个 pane 需要你"。Cmd+Shift+U 跳到最近一个未读的 pane。

通知系统还支持 cmux notify CLI 命令，可以接进 Claude Code 的 hooks——agent 完成任务时自动触发，不需要 agent 知道 cmux 的存在。

2. 内置浏览器：不是标签页，是分屏

cmux 内置了一个浏览器 pane，可以和终端并排分屏。这不是一个简单的 webview——它有从 agent-browser 项目移植过来的脚本 API：

- snapshot accessibility tree
- get element refs
- click / fill / evaluate JS

这意味着 Claude Code 可以直接在浏览器 pane 里操作你的开发服务器。你让 agent "看看登录页面有没有对齐"，agent 自己截图、自己分析、自己改代码。终端和浏览器在同一个窗口里，agent 可以同时操作两者。

3. 垂直标签页 + 元数据

侧边栏不是简单的标签列表。每个标签显示：

• Git 分支
• 关联的 PR 状态和编号
• 当前工作目录
• 监听的端口
• 最新通知文本

这些信息不是装饰。当你开 8 个会话时，你需要一眼看出"这个在跑 auth-service 的 3000 端口，PR #234 还在 review"。水平标签页一行挤不下，垂直标签页可以显示完整元数据。

"Primitive, not solution" 哲学

README 里有一段值得完整引用：

cmux is a primitive, not a solution. It gives you a terminal, a browser, notifications, workspaces, splits, tabs, and a CLI to control all of it. cmux doesn't force you into an opinionated way to use coding agents.

这和大多数 agent 编排器的设计哲学完全相反。大多数编排器（Devin、Factory、Cline）的思路是："我们设计好了工作流，你照着来"。cmux 的思路是："我给你零件，你自己搭"。

理由也很直接：

The best developers have always built their own tools. Nobody has figured out the best way to work with agents yet, and the teams building closed products definitely haven't either.

这是一个赌注：agent 工作流的最佳实践还没被发明出来，所以不应该把它硬编码进产品。给开发者可组合的原语（终端 + 浏览器 + 通知 + CLI），让一百万个开发者各自找到最优解，比一个产品团队自上而下设计更快。

这个赌注对不对？不知道。但它至少不会像编排器那样，在 agent 工作流范式变化时变成技术债。

为什么不用 Electron

cmux 用 Swift + AppKit 写的，不是 Electron。README 里的理由：

I tried a few coding orchestrators but most of them were Electron/Tauri apps and the performance bugged me.

Electron 的问题不是"慢"——现代电脑跑 Electron 应用够快了。问题是内存占用和启动速度。当你开 8 个终端 pane + 浏览器 pane + 通知系统时，Electron 的内存开销会叠加。一个 Electron 应用占 500MB 内存不稀奇，8 个 pane 就是 4GB。

cmux 用 libghostty 做 GPU 加速渲染，读取现有的 ~/.config/ghostty/config（主题、字体、颜色），所以 Ghostty 用户切换过来零配置成本。原生 macOS app 的启动时间在毫秒级，内存占用在几十 MB 级别。

SSH：远程开发的原生支持

cmux ssh user@remote 创建一个远程工作区。关键设计：

• --command 'omp "investigate auth"' 在第一个远程终端里自动执行命令
• 浏览器 pane 通过远程网络路由——localhost 在远程机器上可达
• 拖图片到远程会话自动 scp 上传

这解决了 agent 远程开发的一个核心痛点：agent 需要访问远程的 localhost 服务。传统 SSH 终端里，你要么在远程跑 agent（需要远程装环境），要么在本地跑 agent（但 agent 看不到远程的 localhost）。cmux 的浏览器 pane 路由通过远程网络，agent 在本地跑但能看到远程的 localhost:3000。

Claude Code Teams 集成

cmux claude-teams 一条命令启动 Claude Code 的 teammate 模式。Teammates 作为原生 split 启动，侧边栏显示元数据，通知系统接入。不需要 tmux。

这是一个有意思的设计选择：cmux 不自己实现 agent 编排，而是给 Claude Code 的 teammate 模式提供更好的 UI 壳。编排逻辑交给 Claude Code，cmux 只管窗口管理和通知。

限制

• macOS only。没有 Linux/Windows 版本，也没计划做。
• 需要 Ghostty 配置。虽然零配置切换，但如果你不用 Ghostty，主题和字体需要手动配。
• Swift/AppKit。这意味着社区贡献门槛比 TypeScript 项目高——能写 Swift 的开发者比能写 TypeScript 的少一个数量级。
• GPL 协议。不是 MIT/Apache。商业使用需要注意 GPL 的传染性。

和 Warp、Wave、Ghostty 的区别

cmux 的独特位置是：比 Ghostty 多了 agent 支持，比 Wave 少了 opinionated 工作流。它假设你已经有了 agent（Claude Code、Codex、Copilot），只需要一个更好的终端来管理多个 agent 会话。

cmux 不适合所有人。如果你只用一个 agent 会话，Ghostty 够了。如果你想要 agent 帮你做一切，Wave 更合适。cmux 适合那些同时跑多个 agent、需要精确控制每个会话、不想被编排器锁住工作流的开发者。这是一个小众但正在增长的市场——当 agent 从"一个助手"变成"一个团队"时，终端需要进化成团队管理工具。