Rust 终端复用器 rmux 开源：带类型 SDK，可编程驱动终端与 AI Agent

这是一个或许对你有用的开源项目。

国产 Star 破 10w 的开源项目，前端包括管理后台、微信小程序，后端支持单体、微服务架构。RBAC权限、数据权限、SaaS多租户、商城、支付、审批工作流、大屏报表、ERP、CRM、WMS、MES、HRM、EAM、OA、FMS、PMS、AI大模型、AI工作流、AI Agent、IoT物联网、IM实时聊天等功能：

• 多模块：https://gitee.com/zhijiantianya/ruoyi-vue-pro
• 微服务：https://gitee.com/zhijiantianya/yudao-cloud
• 视频教程：https://doc.iocoder.cn

【国内首批】支持 JDK25 + SpringBoot4、JDK17/21+SpringBoot3、JDK8/11+Spring Boot2 三版本。

终端里的长任务，也该有一套能被程序驱动的接口。

作者在 HN 上发布这个项目时说得非常直白：他在 SSH 上同时跑着几个长期存活的 AI Agent，不想丢掉它们的终端窗口，想随时切回去查看状态，最好还能写脚本编排它们的行为。tmux 做不到这件事。

它把终端变成了可以被程序驱动的东西

— 终端里的会话与 pane 排布

想从程序里控制 tmux，路子基本只有一条：exec 命令行，再解析吐出来的原始文本。想等待某段输出出现？sleep 一会儿再 grep。作者忍不了这条路，干脆用 Rust 把整个想法重写了一遍。

结果就是 rmux。一句话概括，带 API 的 tmux。它是一个用 Rust 从零编写的终端复用器，兼容 90 多条 tmux 命令，同时提供 Rust、Python、TypeScript 三套带类型的 SDK。代码可以像 Playwright 驱动浏览器那样驱动终端。

它开源在 Helvesec 组织下，双协议 MIT 与 Apache-2.0，目前已经拿到两千六百多 Star。Linux、macOS、Windows 都原生支持，Windows 上不需要 WSL。既能当独立命令行工具用，也能嵌入 Rust 终端应用，还可以通过 SDK 来驱动。

如果你对 Agent 开发本身感兴趣，不妨先了解下 Agent 开发 的基础链路，再回头看终端驱动会更清楚它在自动化流程里的位置。

老命令照用，新能力是 SDK

— 项目 Logo

它没有另造一套命令，而是把 tmux 最常用的那 90 多条直接搬了过来。new-session、split-window、send-keys、attach-session 这些都能直接用，肌肉记忆不会浪费。作者还专门写了兼容测试覆盖，不是随便抄几个命令就完事。

— 功能与命令对照表

配置方面也考虑到了迁移成本。找不到 rmux 专属配置时，它会回退去解析你现有的 tmux.conf，遇到不支持的插件会报出来，但不会崩。

真正拉开差距的是脚本化这一层。三套 SDK 全部带类型，包名分别是 Rust 的 rmux-sdk、Python 的 librmux、TypeScript 的 @rmux/sdk。

— 三套 SDK 的代码面板

SDK 连接本地的 rmux daemon，开放 session、pane、stream、wait、snapshot 这几类接口。你可以写代码创建 session，往 pane 里发文本，等某段输出出现，然后抓一张屏幕快照。整个过程不用 sleep，也不用解析字符串。

仓库里还带了几个能直接跑的 demo：多 Agent 编排、Agent 广播竞技场、Mini-Zellij，以及终端自动化混搭 Playwright。

既然项目本身就是以 Rust 实现，了解 Rust 的异步模型和 SDK 设计思路，对理解 rmux 的内部机制会有不少帮助。

四套接口挂在一个本地守护进程上

— 桌面上的多窗口布局

把 CLI、三套 SDK、TUI 渲染和浏览器分享串在一起的是同一个 daemon，这也是它设计上最一致的地方。

架构上，shell、session、window、pane 和 PTY 进程全部留在本地 daemon 里，本地客户端通过 IPC 接入。Web Share 只把被选中的那个 pane 或者 session 通过端到端加密的 WebSocket 暴露出去，实际执行始终留在你的机器上。它支持 loopback 本地预览，也支持走 tunnel provider 或者自己的 ingress，用的是混合后量子端到端加密。

— 浏览器里的配对界面

这个能力对挂长任务的人很实用。服务器上跑着个几小时的任务，想从手机或者另一台电脑扫一眼进度，不用 SSH 登录，开个浏览器就行。

另外两块是给开发者准备的。如果你用 Rust 写 TUI，官方提供了 ratatui-rmux widget，可以把 rmux 的实时 pane 快照直接渲染进 Ratatui 的 buffer，等于在 TUI 里内嵌一个真正的终端，而不是自己模拟一套终端行为。

还有一条专门给 Claude Code 的命令，rmux claude。跑起来会自动附上 --teammate-mode tmux，并且会在 Claude 进程的 PATH 最前面塞一个私有的 tmux shim。这个 shim 严格限定在 Claude 进程内部，不会污染你系统里的 tmux。这个细节说明作者自己就在用 Claude Code，而且被兼容问题折腾过。

Windows 这次不用绕 WSL

tmux 在 Windows 上一直是个痛点。rmux 的底层 IPC 在 Linux 和 macOS 上走 Unix socket，在 Windows 上走 Named Pipe，全是原生实现。

没有 WSL 那层翻译，Windows 开发者拿到的终端复用体验和 Linux 一致。在这个圈子里，这是件少见的事。

装它有三类路子

— 终端里的实际操作

第一类是脚本。macOS 和 Linux 用这个：

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

Windows 那边对应的是 PowerShell 脚本，一条命令就能装好，不用另配运行时：

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

第二类是包管理器。常用的几条都在这里：

brew install rmux
cargo install rmux --locked

Windows 上还有 winget install rmux 和 choco install rmux，Linux 侧可以走 APT 或 DNF，也能装 Nix 版本。

装完先确认它认识哪些命令。顺手看一眼版本，再跑一次自检：

rmux list-commands
rmux new-session --help
rmux -V
rmux diagnose --human

然后跑个最小流程。建会话、分屏、发命令、再看结果：

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

第三类是写代码驱动。Rust 项目里加两个依赖：

cargo add rmux-sdk
cargo add ratatui-rmux

Python 和 TypeScript 的包名分别是 librmux 与 @rmux/sdk，装法一样。工作区还给了四条从源码自检的命令，跑格式化检查、clippy、测试与 unsafe 扫描。

它还不够稳，但方向值得跟

— Helvesec/rmux 仓库首页

先说前提。rmux 还在快速迭代，bug 肯定有，重度 tmux 插件用户暂时别想着完整迁移。它最近的提交停在八月，更新节奏不算密。

但方向上我是认同的。终端控制本来就应该是 API，而不只是命令行工具。Web 自动化有 Playwright，浏览器控制被解决了；终端自动化这边，把 CLI、SDK、TUI 渲染、浏览器分享这四件事串到同一个 daemon 下面，我确实没找到第二个。

作者自己就是目标用户，他写这个工具是为了解决自己每天遇到的问题。这类项目通常比「我觉得市场可能需要」的项目走得更远。来源作者在 macOS 上装了一个，试了 SDK 里的 wait_for_text，评价是比 tmux 的 expect 脚本舒服太多。

如果你也在 SSH 上挂着长期运行的 Agent，或者写过那种靠 sleep 加 grep 撑着的终端脚本，值得花十分钟装一个试试。反过来，如果你的 tmux 配置里塞满了插件、跑了几年没动过，那可以先观望。

对这类 开源实战 项目感兴趣的读者，仓库地址在这里：

https://github.com/Helvesec/rmux