最初发表于andrew.ooo — 如需更新、过时的代码片段或后续帖子，请访问原文。

简而言之

Rmux是一个从头开始的Rust重写终端复用器概念，专为智能代理时代构建。它在2026年5月21日在Show HN上发布，由作者发布神盾系统 带有标语 "一个可编程的终端复用器，带有 Playwright 风格的 SDK" — 并且框架已经落地。一句话的推销：即插即用的 tmux 兼容性（90 个命令，你的快捷键有效），加上在同一个守护进程上的类型安全的异步 Rust SDK，让代理和脚本可以像 Playwright 驱动浏览器一样驱动任何 CLI 或 TUI 应用.

关键要点：

• v0.2.0 于2026年5月18日发布 (在Show HN之前3天)，采用MIT/Apache-2.0双许可
• 90个兼容tmux的CLI命令已实现 — new-session、split-window、send-keys、attach-session等
• 类型化的Rust SDKrmux-sdk在 crates.io 上使用稳定 pane ID、结构化快照、定位式等待)
• 原生支持Linux、macOS和Windows— 在 *nix 上使用 Unix PTYWindows 上的真实 ConPTY（无需 WSL）
• ratatui-rmux小工具用于嵌入实时窗格拉塔图伊TUI应用程序
• #![forbid(unsafe_code)] 在高层包中，操作系统边界代码隔离在运行时包中
• 单个守护进程 背后是两个界面——CLI能做的，SDK也能做，反之亦然
• 限制： 新的公共预览版，根据README的说明，"预计存在错误"，可脚本插件/脚本系统尚未分离，Lua/脚本与tmux配置没有对等

如果你曾经写过一个不可靠的tmux send-keys + tmux capture-pane | grep循环来从脚本中监控一个长时间运行的工具——或者经历过一个SSH会话中断并丢失一个Claude Code或Codex运行——Rmux是到2026年为止提供的最根本的解决方案。

Rmux到底是什么

作者是shideneyu在GitHub和HN上。在 Show HN 论坛中解释了其起源：：

"RMUX 起源于一个挫败感：我已经使用了多年的 tmux，并且厌倦了用 grep 和 sleep 来刮取输出以实现任何自动化。因此，我用 Rust 从头开始重建了多路复用器，并在其上添加了一个可编程层。"

那是核心见解。Tmux 对人类来说很棒，但对机器来说很脆弱。一旦你尝试自动化——等待构建完成、只在提示出现后发送输入、从 top 中抓取值——你最终都会写出 sleep 3 && capture-pane -p | tail -n 20 | grep ... 并祈祷。

Rmux 的解决方案是在一个守护进程之上提供两个并行接口：

1. 命令行接口rmux 二进制文件): 看起来和行为像 tmux。所有 90 个最常用的 tmux 命令都已实现，你的肌肉记忆仍然有效，你的 .tmux.conf 风格的快捷键也可以保留。你可以直接使用它。

2. SDK 界面 (rmux-sdk 库): 一个与同一守护进程通过本地套接字通信的异步 Rust API。会话和窗格是具有稳定 ID 的一流对象。你可以获得wait_for_text("ready") 而不是 sleep && grep。结构化 PaneSnapshot 对象（行、列、属性）而不是原始的转义序列汤。这是 "Playwright for terminals" 部分.

两个表面都与一个隐藏的守护进程通信，该守护进程拥有 PTYs、会话、布局、钩子和缓冲区。分离你的人类终端——你的 SDK 脚本仍然在驱动。杀死你的 SDK 脚本——你的人类会话仍然可连接.

安装

对急性子来说，在 macOS 或 Linux 上：

curl -fsSL https://rmux.io/install.sh | sh

Windows PowerShell:

irm https://rmux.io/install.ps1 | iex

来自 crates.io:

cargo install rmux --locked

核实rmux --version—应该报告0.2.0SHA256 校验和已发布在预构建二进制文件中。v0.2.0 GitHub 发布，这是正确的事情，但对于v0.2发布来说仍然是一种罕见情况。

第一次使用感觉和 tmux 完全一样：

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：它会创建一个名为work 水平分割，向右侧面板发送命令，然后附加您的终端，以便您可以并排查看两个面板。按下 Ctrl+B D（默认前缀，类似于 tmux）再次分离——会话保持运行，进程保持运行，您稍后可以从另一个终端或另一个 SSH 连接重新附加。

SDK 才是重点

CLI 是基本要求。SDK 才是您切换的原因。

将其添加到 Cargo 项目中：

[dependencies]
rmux-sdk = "0.2"
tokio = { version = "1", features = ["rt-multi-thread", "macros"] }

这是标准的"等待输出，然后捕获状态"模式，改编自 README：

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

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

    let session_name = SessionName::new("work").expect("valid session name");
    let session = rmux
        .ensure_session(
            EnsureSession::named(session_name)
                .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?;
    let snapshot = pane.snapshot().await?;
    println!("{}x{}", snapshot.cols, snapshot.rows);

    Ok(())
}

仔细阅读。有趣的行是：

• connect_or_start() — 如果存在正在运行的守护进程则连接到它，不存在则启动一个。不再有“我tmux start-server了吗？”的竞态条件。
• EnsureSessionPolicy::CreateOrReuse — 线性会话启动。重新运行脚本，得到相同的会话。
• pane.wait_for_text("ready").await? — 这是杀手级功能。无需睡眠。无需轮询循环。一个真正的异步等待，一旦文本出现在面板缓冲区中（以default_timeout作为绑定）就会立即解析。
• pane.snapshot().await? — 输入 PaneSnapshot 并使用 cols、rows 以及结构化单元格数据。您不会解析字符串；您读取字段。

这种心智模型几乎与 Playwright 一致：一个对长生命周期的环境的类型化句柄、定位器风格的等待、对状态的结构化内省。

Ratatui 集成：在 TUI 应用中嵌入实时窗格

这是让我坐直了的事情。ratatui-rmux伴侣包暴露了一个PaneWidget，它直接在Ratatui TUI应用内部渲染一个实时面板快照：

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仪表板（一个构建日志、一个服务器日志、一个代理终端会话），并将其作为小部件显示在你自己的控件旁边，而无需在应用程序中包含子进程管理或PTY分配代码。该仪表板是多路复用器的另一面。对于任何构建代理可观察性工具或实时操作员UI的人来说，这大大减少了大量样板代码。

为何“面向自主智能时代”在此处意义重大

许多2026年的工具在README中标注“面向AI代理”却未对设计进行任何改动。Rmux之所以获得此标签，源于其三个具体特性：

1. 可分离执行 + 重新连接。 当一个 Claude Code、Codex 或 aider 运行持续 45 分钟，而你的 SSH 连接中断时，普通的 shell 会失去该进程。使用 rmux（或 tmux）时，守护进程拥有 PTY — 代理仍然运行，新的 SSH 连接可以附加并恢复人类视角。对于在不可靠连接上的长时间编码代理会话来说，这不是锦上添花的功能，而是区分“成功发布”和“不得不从头重新开始”的关键。

2. 结构化快照，而非字节流. 当代理监督者需要知道“我的子进程是否已经打印出成功信息了？”时，字节流管道迫使其编写一个解析器。而类型的PaneSnapshot则允许它在行和单元格上匹配模式。监督代理可以很小很笨，因为数据格式正确.

3. Windows上的真实ConPTY，没有WSL。 这是大多数项目会跳过的一点。WezTerm、Alacritty，甚至一些所谓的"跨平台" Rust shell 都建议在 Windows 上"使用 WSL"。Rmux 使用真实的 ConPTY (Windows 的伪控制台 API) 和每个用户的命名管道进行 IPC。如果你正在构建需要在开发者的实际 Windows 机器上运行——或者需要在 CI 中的 Windows Server 虚拟机中运行——的代理工具，那么这比基准测试更重要。

社区反响（前24小时）

Show HN板块尚年轻（撰写时得分为39，评论29条——起步但已置顶），作者正积极回复。代表性帖子：

• "为什么不用script-wrap tmux?" — tmux的自动化界面与rmux的动机相同，都是基于字节流和正则表达式。将其封装并不能解决不匹配的问题。
• "守护进程协议稳定性？" — rmux-proto (the IPC DTO crate) 是公开发布的，以便其他语言的 SDK 可以基于它进行构建。Python 和 Node 绑定并未提供，但网络格式有文档说明。
• "屏幕 / zellij 呢？" — screen 早于 结构化自动化成为一个问题。Zellij 采取以 WASM 插件为中心的理念；rmux 则押注于进程外 SDK 客户端。形态不同，并非严格竞争。

r/rust 线程 偏向于实现好奇：ConPTY 集成、工作区拆分，以及 #![forbid(unsafe_code)] 在上层 crate 中的姿态。v0.2 的构建卫生异常细致：cargo clippy --all-targets --locked -D warnings，scripts/no-network-in-runtime.sh 断言，以及一个平台无关性检查器.

诚实的局限性

这是一个全新的预览。要现实.

• "会有bug。" README里说了。不要在第三天就把rmux放在关键的CI路径上 — 先为发布周期或两个周期运行它用于个人使用和原型.
• tmux配置没有Lua/脚本兼容性。快捷键和核心选项会保留；一个400行的.tmux.conf使用自定义钩子和插件则不这样。
• 目前还没有官方的 Python / Node SDK。要么花钱用命令行界面，要么自己动手用公共资源rmux-proto二进制格式。社区端口可能很快就会推出。
• Daemon 协议设计上是仅限于本地的。 Unix 套接字或命名管道。要驱动远程 rmux，你需要 SSH 登录并在那里运行 SDK —— 这通常是你要做的事情。
• 守护进程空闲时的内存占用没有文档记录。 在开发机上无关紧要；如果你每次 CI 构建都会生成数百个，那么你可能需要测量。

与其他相比

设计理念上最接近的竞争对手是诚实地 Playwright for terminals，这目前还不是个真正的类别。Rmux 正在将其变成一个类别.

设置配方

通过 SSH 照看一个编码代理

ssh build-server
rmux new-session -d -s coder
rmux send-keys -t coder 'cd ~/project && claude code' Enter
rmux attach-session -t coder
# do prompt work, then Ctrl+B D to detach
exit  # SSH disconnects, agent keeps running

使用 ssh build-server && rmux attach-session -t coder 从任何地方重新连接。代理的终端和你离开时一模一样，包括滚动历史记录。

从 CI 驱动 TUI 安装程序

pane.send_text("./installer.sh\n").await?;
pane.wait_for_text("License [y/N]").await?;
pane.send_text("y\n").await?;
pane.wait_for_text("Install directory:").await?;
pane.send_text("/opt/myapp\n").await?;
pane.wait_for_text("Installation complete").await?;

这是真正的新功能。你之前可以用 expect 来做，但 expect 是一种来自 1990 年的字符串汤语言。Rmux 使其成为一个带有适当错误处理的类型化 Rust 程序。

常见问题解答

rmux 是 tmux 的直接替代品吗？

日常使用：基本是。最常用的 90 个命令都能用，你的前缀键反射也能用。对于特殊配置（复杂的 Lua 脚本、自定义钩子、像 TPM 这样的插件生态系统）：还不行。把它当作“一个也能编程的 tmux”而不是“在所有 tmux 做的事情上都比 tmux 更好的 tmux”。

我能从 Python 或 Node.js 而不是 Rust 使用 rmux 吗？

目前还没有官方SDK。您现在可以选择：(1) 在脚本中调用rmux命令行工具，这可以工作但会失去类型SDK的易用性，或者(2) 直接针对公共rmux-proto协议格式编写代码。对于像这样的大型项目，通常在一个月内会出现社区Python绑定——请关注issues。

Windows 版本真的不需要 WSL 就能工作吗？

是的。它使用真实的 ConPTY（Windows 10 1809 中引入的伪控制台 API）进行 PTY 分配，并使用每个用户的命名管道进行 IPC。该项目的 scripts/check-platform-neutrality.sh 强制要求平台特定代码保持在边界 crates 内。如果你一直在等待一个不把 Windows 当作二等公民的终端复用器，那么这就是第一个可靠的选项。

它今天足够稳定可以使用吗？

对于个人自动化、原型和探索性代理工作：是的，但需注意 README 中关于 v0.2.0 版本可能出现问题的说明。对于关键路径上的生产持续集成：等待一两个发布周期，关注问题追踪器，并锁定版本。构建规范（clippy、fmt、锁定依赖项、forbid(unsafe_code)）令人放心；版本号是诚实的。

这种方式如何与 Claude Code 或 Codex 等编程代理配合使用？

两个互补的角色。首先，作为一个 主机：在 rmux 会话中运行代理的 CLI，以便它在 SSH 断开连接时继续运行，并且你可以随时附加/分离（对于在不可靠连接上进行长时间运行非常重要）。其次，作为一个 目标：一个代理监督者（一个 Rust 或 Python 协调器）使用 rmux SDK 来驱动 其他 终端工具——安装程序、REPL、TUI 调试器——这些是内部代理需要与之交互的。监督者模式更有趣，也是 rmux 相对于 tmux 独特擅长的。

它与 Forge 相比如何？

不同层级。Forge 是代理推理和工具调用循环的可靠性层级。Rmux 是代理的环境的可靠性层级——代理（或监督代理的人类）所处的终端会话。两者都针对同一个底层挫败感（小型模型/脆弱会话需要脚手架才能发挥作用），但它们并不重叠.

裁决

Rmux 是我在2026年见过的最干净的“为智能代理时代重建一个Unix工作horse”版本。决定在同一守护进程上发布一个与tmux兼容的CLI 以及一个带类型的SDK——而不是强迫用户选择——是让一个工具真正可采用的约束类型。

Windows原生的故事（真实的ConPTY，没有WSL）会让我对任何需要跨平台代理工具的项目从“有趣”转变为“我正在尝试这个”。Ratatui组件集成会让我对TUI构建器产生兴趣。wait_for_text定位API会让我对任何曾经写过sleep 3 && grep循环并知道它是错误的开发者产生兴趣。

警告是真实的，作者拥有它们：v0.2.0，预计有错误，还没有Python/Node SDK，与成熟的tmux配置脚本兼容性不佳。但基本框架是正确的，对于一个v0.2的发布，构建的整洁性非常严格，设计理念在遇到明显的替代方案时依然成立。

如果你通过 SSH 运行长期运行的进程，从代码中管理 CLI 工具，或构建封装其他终端应用的 TUI 仪表板——今天就安装它，移植一个烦人的自动化脚本，并在 30 天后反馈。这是对一个公开其协议的新工具的正确赌注，该工具在其上层 crate 中禁止不安全的代码。

仓库： github.com/helvesec/rmux·文档： rmux.io/docs · 显示HN： news.ycombinator.com/item?id=48219918 · 许可： MIT / Apache-2.0