摘要：rmux 是一款用 Rust 从零重写的现代终端复用器，兼容 tmux 90+ 条命令，原生支持 Linux / macOS / Windows，并提供 typed Rust SDK、Ratatui TUI 集成和端到端加密的浏览器 Web Share 功能。它不只是 tmux 的替代品，而是为 AI Agent 工作流重新定义了"终端控制"应该是什么样子。

你有没有想过，tmux 这个 2007 年诞生的工具，今天还在被几乎所有后端开发者使用——它的设计，本质上是为"人类用键盘操作终端"而生的。

但 AI Agent 时代来了。

当你的 Agent 需要在 SSH 上运行一个长达几小时的任务，或者你要用代码同时编排三个 Claude 实例分别处理不同子任务时，tmux 的那套逻辑开始显得力不从心。你能 send-keys，但你得自己解析 escape sequence；你能 capture-pane，但输出是原始文本，没有结构；你等一个进程跑完，只能靠 sleep && grep，没有更好的办法。

rmux 就是在这个背景下诞生的。

---

它是什么？

一句话：rmux 是用 Rust 从零重写的终端复用器，兼容 tmux 命令，同时提供一套 typed Rust SDK，让代码能像 Playwright 驱动浏览器一样驱动终端。

GitHub：https://github.com/Helvesec/rmux
官网：https://rmux.io
当前版本：v0.5.0
开源协议：MIT / Apache-2.0
平台：Linux / macOS / Windows（原生，无需 WSL）

项目在 2026 年 5 月登上 Hacker News Show HN，作者用的标题是"A programmable terminal multiplexer with a Playwright-style SDK"，反响不错，目前 GitHub Star 已超过 1900。

---

为什么要重写 tmux？

作者在 README 里写得很直接：

"我的出发点很简单——我想在 SSH 上运行长时间运行的 Agent，同时不丢失终端，还能检查、脚本化和编排整个流程。"

tmux 本身是 C 写的，诞生于 2007 年，设计目标是让人类能在终端里管理多个 session。它很好，但它没有提供一个给代码用的 API。你要从程序里控制 tmux，只能通过命令行调用，拿到的是原始文本输出，等待某个输出出现只能靠 sleep。

rmux 的选择是：同时面向人类和代码，两个接口共享同一个 daemon，不是非此即彼。

---

三个公开接口，共享同一个 daemon

rmux 的架构很清晰，有三个对外暴露的接口：

1. CLI（rmux 命令行）

完全兼容 tmux 的使用习惯。90+ 条命令实现，肌肉记忆可以直接迁移：

rmux new-session -d -s work
rmux split-window -h -t work
rmux send-keys -t work 'echo "hello from rmux"' Enter
rmux attach-session -t work

你的 .tmux.conf 配置也支持作为迁移 fallback 导入，不需要从头配。

2. Rust SDK（rmux-sdk crate）

这是 rmux 最有意思的部分。Session、Pane 都是有稳定 ID 的 Rust 对象，可以直接 await，可以等特定文本出现，可以拿结构化快照：

use rmux_sdk::{EnsureSession, EnsureSessionPolicy, Rmux, SessionName, TerminalSizeSpec};

#[tokio::main]
asyncfn main() -> rmux_sdk::Result<()> {
    let rmux = Rmux::builder()
        .default_timeout(Duration::from_secs(5))
        .connect_or_start()
        .await?;

    let session = rmux.ensure_session(
        EnsureSession::named(SessionName::new("work").unwrap())
            .policy(EnsureSessionPolicy::CreateOrReuse)
            .detached(true)
            .size(TerminalSizeSpec::new(120, 32)),
    ).await?;

    let pane = session.pane(0, 0);
    pane.send_text("printf 'ready\n' && sleep 1\n").await?;
    pane.wait_for_text("ready").await?;   // 不用 sleep，等到它出现
    let snapshot = pane.snapshot().await?;
    println!("{}x{}", snapshot.cols, snapshot.rows);
    Ok(())
}

wait_for_text("ready") 这个 API 设计很有意思——你不再需要猜测进程跑了多久，直接声明等什么，SDK 帮你处理。

3. Ratatui Widget（ratatui-rmux）

如果你在写 Rust TUI 应用，可以直接把 rmux pane 的快照渲染成 Ratatui 组件：

use ratatui::{buffer::Buffer, layout::Rect, widgets::Widget};
use ratatui_rmux::{PaneState, PaneWidget};
use rmux_sdk::PaneSnapshot;

fn render(snapshot: PaneSnapshot, area: Rect, buffer: &mut Buffer) {
    let state = PaneState::from_snapshot(snapshot);
    PaneWidget::new(&state).render(area, buffer);
}

这意味着你可以在自己的 TUI 里内嵌一个真实的终端 pane，而不是模拟一个假的。

---

Web Share：把终端分享到浏览器

这是 v0.5.0 里的新功能，也是最差异化的一个亮点。

一行命令，把你的终端 session 暴露到浏览器里：

# 本地 loopback 访问
rmux web-share

# 分享指定 session
rmux new-session -d -s work
rmux web-share -t work

# 通过 tunnel 公开访问
rmux web-share --tunnel-provider localhost-run

加密方式是端到端加密的 WebSocket，文档里说用了"混合后量子加密"（hybrid post-quantum E2EE）。执行仍然在本机，浏览器只是一个查看和操作界面。

实际效果是：你可以在浏览器里看到终端输出、拖动分割线、新建 pane，就像一个远程桌面里的终端窗口一样，但不需要 VNC，不需要 X11 forwarding。

对于需要临时分享调试现场、远程演示、或者在没有 SSH 客户端的设备上临时访问服务器的场景，这个功能很实用。

---

跨平台：Windows 不靠 WSL

很多"跨平台"的终端工具，到了 Windows 上要么直接说"用 WSL"，要么功能大幅缩水。

rmux 选择了认真对待 Windows：用真正的 ConPTY（Windows 伪控制台 API）而不是模拟，IPC 用 Windows Named Pipes（Unix 上用 Unix Socket），两者都是 OS 原生支持的。

平台	PTY 后端	IPC 后端
Linux	Unix PTY	Unix Socket
macOS	Unix PTY	Unix Socket
Windows	ConPTY	Named Pipe

对于要在开发者 Windows 机器或 Windows Server CI 环境里部署 Agent 工具链的团队，这个细节很重要。

---

能做什么？Demo 场景一览

项目 README 里列了几个 demo，可以感受一下 rmux 的使用场景：

• 多 Agent 编排（约 514 行）：用 rmux 同时驱动多个 AI Agent 实例，每个实例在独立的 pane 里运行

• Agent 广播竞技场（约 2,171 行）：把同一个输入广播给多个 Agent，对比它们的输出

• Mini-Zellij（约 944 行）：用 rmux + Ratatui 自己实现一个 Zellij 风格的终端界面

• 终端自动化（约 1,495 行）：集成 Playwright 做 Web 测试，终端操作和浏览器操作混合编排

这些 demo 的源码都在仓库里，都是可以直接跑起来的。

---

安装方式

Linux / macOS：

# 一键安装脚本
curl -fsSL https://rmux.io/install.sh | sh

# Homebrew
brew install helvesec/rmux/rmux

# APT
sudo apt install rmux  # 需先添加 apt 源，见官方文档

# Cargo
cargo install rmux --locked

Windows：

# PowerShell 一键安装
irm https://rmux.io/install.ps1 | iex

# Scoop
scoop bucket add rmux https://github.com/Helvesec/scoop-rmux
scoop install rmux

# WinGet
winget install rmux

Rust 项目依赖：

cargo add rmux-sdk
cargo add ratatui-rmux

---

一些客观的局限

项目本身对现状写得比较坦诚：v0.5.0 仍然是"moving fast"的阶段，90 条命令覆盖了最常用的，但重度 tmux 插件用户（比如 TPM 插件生态、复杂 Lua 脚本）目前还不能完整迁移。

社区里的评测结论基本是："把它当作'碰巧也可以用代码控制的 tmux'，而不是'比 tmux 在所有方面都更好的 tmux'"。

如果你现在只是想换一个更快的日常 tmux，它能用，但还有 bug；如果你要构建需要代码驱动终端的 Agent 工具链，它是目前这个方向上设计最完整的选择。

---

总结

rmux 的核心判断是：终端控制应该是一个 API，而不只是一个命令行工具。

这不是一个新想法，但它是第一个把这件事做完整的开源项目——CLI、SDK、TUI 渲染、浏览器分享，四个接口共享同一个 daemon，设计上是一致的。

AI Agent 工作流对终端控制的需求，就像 Web 自动化对浏览器控制的需求——Playwright 解决了后者，rmux 在尝试解决前者。

项目还年轻，但方向是对的。

GitHub：https://github.com/Helvesec/rmux
官网文档：https://rmux.io/docs

我是顾北，关注我，获取更多好玩有趣的开源仓库！

谢谢你阅读我的文章~

我们下期再见！

 PS：本文部分内容由AI辅助创作