tmux 这个东西,几乎每个长期在终端里干活的人都用过。但它是给「人」设计的——这两天有人把这个思路为 agent 从头重写了一遍,叫 rmux。
rmux 是用 Rust 写的终端复用器,目前 v0.2.0,作者自己讲明了还是个 fresh public preview,会有 bug。先说它想解决什么:你大概也用过 tmux——一个窗口里开多个会话、断开还能重连。问题在于,tmux 这套是为「人坐在屏幕前操作」打磨了十几年的;当终端的使用者从人变成 agent,旧的那套就开始不够用了。下面这几条,是 rmux 和 tmux 真正拉开差距的地方。
· 给谁用。tmux 的核心交互是键盘快捷键,为一个人坐在屏幕前敲而设计。rmux 一上来就假设调用方可能是代码,配了一套带类型的 SDK——创建会话、拆分窗口、发送文本、等某个输出模式出现,都能用程序直接调。
· 怎么读屏。agent 得知道终端里此刻是什么状态——上一条命令跑完没、输出到哪了、有没有报错。靠截一段字符串、用正则去抠,一直都很脆:一个进度条、一段颜色码、一次刷新,都可能让匹配失效。rmux 给的是「结构化快照」——终端状态是一个能被程序直接读取的结构,而不是一坨要你猜的文本。
· 底层架构。rmux 由一个常驻 daemon 撑着,会话能长期挂着不丢。作者最初的动机,就是想让长跑的 agent 在 SSH 上别一断线就丢掉整个终端。daemon 待在中间,也顺带带来一件事:你可以从外部去观察、脚本化地编排这些会话——它甚至给了一个原生的 Ratatui 组件,能把一个 rmux 终端直接嵌进你自己写的 TUI 里。
值得说一句:它没让你从零学。rmux 带一个 tmux 兼容的 CLI,把 tmux 的 90 个命令都实现了——你原来的肌肉记忆还在,只是底下多了一层「能被程序驱动、被程序读取」的能力。
那到底谁该用谁?如果你只是自己开几个窗口跑跑命令,tmux 完全够,没有任何理由换。rmux 的价值在另一个场景:你在写那种会去操作 CLI、TUI 程序的 agent——多 agent 编排、终端自动化测试这一类。它仓库里直接放了 5 个 demo,从多 agent 编排到 Playwright 式的终端测试,代码量从 500 多行到 2000 多行不等,基本是把「agent 该怎么用终端」摊开演示给你看。但也别高估它现在的成熟度:266 个 star、刚发出来没几天,作者自己都说 bug 在所难免。现在适合做的是去读它的 demo、把这个方向想清楚,而不是把它塞进生产环境。
终端复用器是 2010 年代就成熟的东西,本来不会再有人重造一个。现在有人重写了,信号其实挺清楚:agent 正在变成终端的一类新「用户」,而那些给人用的老工具,不一定为它们准备好了。rmux 是一个很早、也很粗糙的回答,但方向对——这种东西值得先记一笔,过几个月再回头看它走到了哪。
转给在写 agent 的朋友——尤其是那种要让 agent 自己去操作命令行的。
完整链接 · 评论区取 ↓
关注 @svtransit1 · 写给真在用 AI 的人
#AI #AIagent #tmux #开发工具 #开源
原始来源：https://github.com/helvesec/rmux
关注 @svtransit1 · 每 3 小时一篇 AI 前线 · RSS