同为现代终端复用工具，它们在远程访问、可编程性和自动化能力上有何不同？一文读懂如何选择。

引言

在终端复用工具的世界里，tmux 长期占据统治地位。但随着技术的发展，新一代工具开始崭露头角，其中最受关注的两个是 Zellij 和 rmux。

两者都号称是 tmux 的现代化替代品，但它们的核心设计哲学和适用场景截然不同。特别是当涉及到远程访问和可编程自动化这两个关键能力时，二者的取舍和实现路径呈现出明显的分野。

本文将带你深入对比这两款工具，帮助你在实际场景中做出最适合的选择。

一、核心定位：为"人"设计 vs. 为"机器"设计

Zellij：为"人"设计的现代化工作区

Zellij 的核心目标是提供开箱即用、用户体验极佳的终端环境。它通过直观的模态界面、易学的快捷键和内置的会话管理，极大地降低了终端复用工具的使用门槛。

• 易用性：被誉为"对初学者比 tmux 友好得多"
• 可发现性：界面底部有快捷键提示，无需死记硬背
• 内置功能：自带会话管理、布局、浮动面板、插件系统等

rmux：为"机器"（AI Agent）设计的可编程引擎

rmux 的核心目标是解决终端自动化的难题，让程序（尤其是 AI Agent）能像控制浏览器一样精确、稳定地驱动终端。

• 可编程性：提供 Rust、Python、TypeScript 的类型化 SDK
• 确定性：提供 wait_for_text 等精确等待机制，告别不稳定的 sleep 和 grep
• 为自动化而生：定位是"专为 Agent 打造的终端复用工具"

这一根本差异，决定了两者在远程控制和可编程性上的不同实现路径。

二、远程访问能力对比

两者都提供了强大的远程访问能力，但实现路径和侧重点完全不同。

Zellij：Web 服务器 + 终端直连

Zellij 从 0.43.0 版本开始引入 Web 客户端，0.44.0 版本更进一步，支持直接从终端通过 HTTPS 连接到远程会话：

1zellij attach https://example.com/my-cool-session

核心特性：

• 浏览器访问：一键将现有会话分享到浏览器，支持多人协作，每个客户端拥有独立光标
• 终端直连：无需浏览器，直接从另一个终端附加到远程会话
• 只读模式：支持 zellij watch <session-name> 进行只读观看，适合教学和演示
• 安全机制：基于 Token 认证，强制 HTTPS
• 会话复活：URL 可书签化，会话退出后可通过同一 URL 复活

rmux：Web Share + 加密分享

rmux 提供了 web-share 命令，将终端会话加密分享到浏览器：

1rmux web-share

核心特性：

• 端到端加密：采用混合后量子端到端加密
• 本地执行：画面分享出去，但命令实际执行仍在本地机器
• 角色控制：支持操作员（operator）和观众（spectator）角色，可配置 PIN
• 灵活部署：支持自定义域名、隧道提供商或自建入口

远程能力对比一览

三、可编程性与自动化能力对比

这是两者差异最显著的领域，也是选择的关键依据。

Zellij：CLI 驱动的程序化控制

Zellij 通过 zellij action 子命令和 zellij subscribe 命令暴露完整的控制面。所有交互都通过子进程调用完成，结构化数据以 JSON 格式输出到 stdout。

控制面分为四类：

自动化示例（Shell 脚本方式）：

1# 创建新窗格并等待命令成功
2zellij run --block-until-exit-success -- cargo test && \
3zellij run --blocking -- cargo build --release
4
5# 通过管道传输数据到插件
6echo "Hello" | zellij pipe -p my-plugin

Zellij 的独特优势：

• WASM 插件系统：可以用 Rust 编写插件，在 Zellij 内部运行，拥有完整的终端复用器能力
• Pipes 机制：通过 zellij pipe 将数据从命令行管道传输到插件
• 事件驱动：插件可以被特定事件唤醒（文件访问、按键、命令结束等）

rmux：原生 SDK 驱动

rmux 提供了 Rust、Python 和 TypeScript 三种语言的类型化 SDK。SDK 直接连接到本地 rmux 守护进程，暴露会话、窗格、流、等待和快照等自动化原语。

核心设计理念：将终端输出视为类似 Playwright 处理 DOM 的方式——没有 TTY 文本 scraping，没有字符串格式化的命令。

Python SDK 示例：

 1from rmux import RMUX
 2
 3rmux = RMUX.connect()
 4session = rmux.new_session("my_automation")
 5pane = session.split_window()
 6pane.send_keys("echo 'Hello from Python!'")
 7
 8# 精确等待特定文本出现，而不是 sleep(2)
 9pane.wait_for_text("Hello from Python!")
10snapshot = pane.capture_pane()
11print(snapshot.text)

rmux 的独特优势：

• 类型安全：编译时捕获错误，IDE 有完整代码提示
• 异步非阻塞：基于 Rust 的 async/await
• 定位器风格等待：wait_for_text 等精确等待机制，类似 Playwright
• 结构化快照：直接获取结构化数据对象，无需手动解析 JSON

可编程性对比一览

四、远程控制自动化：谁更适合你的场景？

回到核心问题：如果你想远程控制一个终端会话，或者编写自动化程序来控制它，Zellij 和 rmux 谁更合适？

场景选择指南

核心差异一句话总结

• Zellij 的 CLI + WASM 插件：适合脚本化和内部扩展，让人类用户更方便地编写自动化脚本
• rmux 的 SDK：适合程序化控制，让代码可以像人一样稳定地操作终端

五、Zellij 远程控制实践

如果你选择 Zellij，下面是两种远程控制方式的具体操作：

方式一：浏览器访问

1# 分享当前会话到浏览器
2zellij action share-session --url-prefix https://your-domain.com
3
4# 或使用默认配置
5zellij action share-session

方式二：终端直连

1# 从另一个终端连接远程会话
2zellij attach https://example.com/my-cool-session

方式三：脚本化控制

1# 创建新会话并在其中运行命令
2zellij -s my-session \
3  --layout <(echo '{"tabs":[{"name":"dev","panes":[{"command":"cargo","args":["run"]}]}]}')
4
5# 通过 action 命令控制
6zellij action new-pane --direction right
7zellij action write 10 # 发送字符 '10' 到当前窗格

方式四：只读观看

1# 观看会话而不干扰操作
2zellij watch my-session

六、rmux 远程控制实践

rmux 的远程控制需要一些组合方案，因为 SDK 本身是为本地通信设计的：

方式一：SSH 远程执行（最通用）

1# 在远程服务器上执行脚本
2ssh user@remote-server "python3 /path/to/control_rmux.py"

远程脚本示例：

1from rmux import RMUX
2
3rmux = RMUX.connect()
4session = rmux.new_session("remote_task")
5pane = session.split_window()
6pane.send_keys("deploy.sh")
7pane.wait_for_text("Deployment complete!")

方式二：web-share 分享

1# 在远程机器上启动分享
2rmux web-share --spectator-only

方式三：指定 Socket 路径（有限支持）

1// TypeScript SDK
2const rmux = new RMUX({ socketPath: "/tmp/rmux.sock" });

注意：此方式仅适用于本地，跨网络需配合 SSH 端口转发等复杂配置。

七、综合建议：如何选择？

选择 Zellij 的场景

• ✅ 你是人类用户，需要一个开箱即用的终端体验
• ✅ 你需要远程访问、演示、协作
• ✅ 你希望用 Shell 脚本快速自动化日常任务
• ✅ 你偏爱可视化界面和快捷键提示

选择 rmux 的场景

• ✅ 你正在构建 AI Agent 或自动化程序
• ✅ 你需要精确、可靠地控制终端（非 sleep/grep）
• ✅ 你希望用 Python/TypeScript/Rust 编写控制程序
• ✅ 你需要类型安全和 IDE 智能提示

两者兼顾的场景

某些场景下，两个工具可以组合使用。有项目（如 Remux）正试图将两者结合——使用 Zellij 作为强大的会话后端，同时在其上构建 rmux 式的 Web 访问和远程控制功能。这说明了两者的能力可以互补，而非简单的二选一。

八、未来展望

Zellij 的路线图

• 持续完善 Web 客户端和协作功能
• 扩展 WASM 插件生态
• 增强 Pipes 和事件系统

rmux 的路线图

• 完善插件系统（可脚本化）
• 增加更多语言的 SDK 支持
• 增强远程控制能力的原生支持
• 优化 Web Share 功能

结语

Zellij 和 rmux 并非简单的替代关系，而是针对不同场景的优化选择。

• Zellij 是"为人类设计的现代化工作区"——远程访问、协作、演示，一切为提升人类用户的生产力而生。
• rmux 是"为机器（AI Agent）设计的可编程引擎"——类型化 SDK、精确等待、结构化控制，让代码可以像操作浏览器 DOM 一样稳定地驱动终端。

选择哪一个，取决于你的核心需求：是让你自己更高效地工作，还是让你的代码更可靠地控制终端。无论选择哪个，你都比继续使用 tmux 迈进了一大步——这两款工具都代表了终端复用技术的新方向。

延伸阅读：

• Zellij 官方文档
• rmux 官方文档
• Zellij 程序化控制指南
• rmux GitHub 仓库

本文基于截至 2025 年 12 月的最新版本信息撰写。工具在持续演进，请参考官方文档获取最新功能。

相关文章

• 终端三件套：Zellij + Herdr + cmux 打造 AI 编码终极工作流
• 现代终端效率工具全家桶：Yazi、Zellij、Starship 与 Ghostty 深度指南
• 终端利器 tmux 不止完美替换 nohup & screen 等进程守护命令
• 从 Loop 到 Graph：AI Agent 架构的下一站