终端复用器的新老交替：Zellij vs Tmux 深度评测与 AI 时代选型指南

在终端复用器（Terminal Multiplexer）领域，tmux 长期以来是开发者的默认选择和行业标杆。而近年来用 Rust 编写的挑战者 Zellij，正凭借开箱即用的体验、现代化的 UI 和基于 WebAssembly 的插件系统在极客圈迅速崛起。

这场新老交替的本质，是**「极简与高度自定义」和「开箱即用与现代化架构」**之间的路线之争。本文从底层架构、配置生态、会话保持等维度展开，并在最后回答一个近期被反复问到的问题：AI 时代的新工具 herdr，到底该和它们怎么搭。

本文所有快捷键与行为均对照 Zellij v0.45.1（2026-08-28 发布）的 default.kdl、tmux 3.2+ 以及 herdr v0.4.0 的官方文档核对。终端工具迭代很快，读到本文时请以你本机 zellij --version 的实际版本为准。

1. 架构与性能：C 语言老将 vs Rust 新星

tmux（C）：坚如磐石的极简主义

tmux 采用经典的**客户端-服务器（Client-Server）**架构。即使终端模拟器崩溃或 SSH 意外断开，后台的 server 进程依然持有会话。经过近二十年打磨，tmux 的资源占用极低，在老旧服务器、1 核 1G 的小机器或高延迟网络下都非常稳健。

Zellij（Rust）：沙箱化的现代架构

Zellij 同样是客户端-服务器架构，所以「会话不丢」这一点上两者并无高下之分——这是终端复用器的基本功，不是谁的卖点。

Zellij 真正的架构差异在插件隔离：插件不是以子进程形式跑 shell 脚本，而是编译成 WebAssembly，在带独立内存空间和显式权限系统的沙箱里执行。一个行为异常的第三方插件因此很难把整个会话拖垮。

这套沙箱还带来一个 tmux 做不到的分发方式：插件可以直接从一个 URL 加载，不需要先克隆仓库、装插件管理器、再重载配置。

代价也要说清楚：Zellij 的二进制体积和常驻内存都明显高于 tmux。tmux 在资源极度受限的机器上依然是更省心的那个。但 Zellij 是单个静态二进制，没有外部依赖——在一台你没有 root 权限的机器上，scp 一个二进制过去往往比装包更快。

2. 交互体验与学习曲线

tmux（陡峭）：设计哲学是「默认什么都不提供」。新用户面对一个黑框，必须记住 Ctrl+b（默认 prefix）配合各种字母来完成分屏和切换。上限极高，劝退率也高。
Zellij（平缓）：默认在底部提供交互式状态栏，直接显示当前模式和可用快捷键，新手不查手册也能上手。鼠标操作（点击切换、拖拽缩放）默认开启，而 tmux 需要手动 set -g mouse on。

两者的差异不只是「有没有提示条」，而是交互模型本身不同。tmux 是 prefix 模型：每个动作都要先按一次 Ctrl+b 再按动作键，按完即回到常态。Zellij 是模式模型（类似 Vim）：Ctrl+p 进入 Pane 模式后就停在那里，可以连续按 n、d、r 连开三个窗格，Esc 或 Ctrl+p 再退出。

调整布局这类连续操作，模式模型明显更省手指；但它也意味着你必须时刻知道「我现在在哪个模式」——状态栏之所以默认常驻，正是为了消化这个认知负担。反过来说，tmux 的 prefix 模型虽然啰嗦，却几乎不会产生模式错觉，这也是很多老用户不愿迁移的真实理由。

关于「隐藏 UI」的一个常见误传

网上流传「Zellij 按 Ctrl+Z 可以隐藏 UI 回归纯净终端」——这是错的，Ctrl+Z 在 Zellij 默认配置里并没有绑定，它在终端里的传统含义是 SIGTSTP（挂起前台进程）。

对照 default.kdl，正确的做法是：

目的	实际操作
切换窗格边框	`Ctrl+p` 然后 `z`（`TogglePaneFrames`）
无 UI 全屏当前窗格	`Ctrl+p` 然后 `Shift+f`
永久精简 UI	配置 `pane_frames false` / `simplified_ui true`，或用内置 `compact` 布局

给 tmux 老用户的两个关键事实

第一，Zellij 的 normal 模式里 Ctrl+b 被绑定为 Tmux 模式——官方内置了一套 tmux 兼容键位，迁移时肌肉记忆不必完全清零。

第二，Zellij 默认键位大量占用 Ctrl 组合键，和 Vim、Emacs、以及各类 TUI 的快捷键冲突严重。这是真实存在的痛点，官方为此在 0.41 提供了 Unlock-First 预设：平时界面处于锁定态，按键直接透传给应用，需要操作 Zellij 时先「解锁」。重度 TUI 用户建议一上来就切到这个预设，或至少记住 Ctrl+g 进入 Locked 模式。

3. 配置与扩展性：KDL 与 Wasm 插件的真实代价

维度	tmux	Zellij
配置文件	专有 `.tmux.conf` 语法（3.x 起也读 `~/.config/tmux/tmux.conf`）	结构化的 KDL
布局预设	需借助外部工具（如 `tmuxinator`）	原生 layout 文件，一行命令拉起复杂工作区
快捷键逻辑	prefix 键 + 动作键	基于模式切换（类似 Vim）
插件形态	Shell 脚本（TPM 管理）	WebAssembly / WASI 沙箱
插件生态规模	大而成熟	小而年轻

布局即代码：KDL 实际长什么样

这张表里对开发者日常影响最大的其实是「布局预设」。Zellij 的 layout 是一个可以提交进仓库的 KDL 文件：

layout {
    tab name="web" focus=true {
        pane split_direction="vertical" {
            pane command="npm" {
                args "run" "dev"
            }
            pane split_direction="horizontal" {
                pane command="npm" {
                    args "run" "test:watch"
                }
                pane
            }
        }
    }
    tab name="logs" {
        pane command="docker" {
            args "compose" "logs" "-f" "mysql"
        }
    }
}

之后 zellij --layout ./dev.kdl 一行命令，前端、测试、空闲 shell 和数据库日志同时就位。把这个文件提交进项目仓库，新同事 clone 下来就能得到和你一模一样的工作区。

tmux 要达到同样的效果，通常得手写一段 new-session / split-window / send-keys 脚本，或者引入 tmuxinator 的 YAML——前者在窗格顺序上很脆弱，后者多引入一个 Ruby 依赖。这是 Zellij 最实打实的体验优势，和「UI 好看」无关。

Wasm 插件：收益在沙箱，不在速度

Zellij 的 Wasm 插件系统确实是它最有辨识度的设计：插件可以用任何能编译到 WASI 的语言编写（Rust 有一等公民地位和官方 zellij-tile SDK），通过 Protocol Buffers 与宿主通信，运行在带显式权限授予的沙箱中。

但必须纠正一个流传很广的说法：Wasm 插件并不等于「高性能」。

Zellij 的插件运行时其实换过两次：0.41 从 wasmer 换到 wasmtime，0.44 又换到了 wasmi——一个解释器。官方发布说明对此写得很直白：这么做是为了让插件不再需要显式编译步骤、不必缓存，代价是「可能带来轻微的性能损失」，并建议插件作者在 Cargo.toml 里用 lto = true、strip = true、codegen-units = 1 来抵消。

所以 Wasm 的真实收益是沙箱隔离、权限模型、语言自由、免编译分发，而不是原始速度。反过来，tmux 的插件虽然是「老旧」的 shell 脚本，但 TPM 生态的体量和成熟度在今天依然是 Zellij 不能比的——需要某个冷门功能时，tmux 更可能已经有人写好了。

4. 会话保持：断连、重启与「复活」

这是开发者最关心的场景，也是原始评测里最容易被一句「两者都能胜任」糊弄过去的地方。事实上两者的能力边界并不相同。

SSH 断连：平手

两者都是客户端-服务器架构，SSH 断线后 tmux attach / zellij attach 都能接回去。这一局没有赢家。

机器重启：Zellij 原生胜出

Zellij 自 0.39 起内置了 Session Resurrection（会话复活）：会话默认被序列化到缓存目录，无论是主动退出还是崩溃，重新 attach 一个已退出的会话就会把它重建出来。

几个值得注意的设计细节：

序列化产物是人类可读的 Zellij layout，可以直接分享给同事或搬到另一台机器；
默认恢复窗格/标签布局和每个窗格里运行的命令，可配置为连 viewport 和 scrollback 一起恢复；
复活的命令不会自动执行，而是停在「Press ENTER to run...」的提示后面——这道防线是为了避免把 rm -rf 之类的东西在重启后自动重放一遍。

tmux 要达到同等效果，需要通过 TPM 安装 tmux-resurrect + tmux-continuum 两个第三方插件：

# ~/.tmux.conf
set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
set -g @continuum-save-interval '15'   # 每 15 分钟自动存档
set -g @continuum-restore 'on'         # tmux 启动时自动恢复

装好后按 prefix + I 拉取插件，存档会落在 ~/.tmux/resurrect/。方案成熟可靠，也确实好用，但它终究是需要你自己搭起来的外部件，而不是开箱即有的能力——差别在于，一台新机器上 Zellij 装完就具备这个行为，tmux 则要先把这套配置同步过去。

还有一个容易被忽略的边界：两者默认恢复的都是布局和命令，而不是进程的内存状态。一个跑到一半的编译、一个未保存的 REPL 会话，重启后都不会回来。会话复活解决的是「重建工作区」，不是「冻结进程」——别把它当 CRIU 用。

浮动窗格：不是 Zellij 独占

常见的说法是「浮动窗口是 Zellij 的杀手锏」，这同样不准确——tmux 自 3.2 起就有 display-popup。

差别在语义：tmux 的 popup 是由显示层渲染的临时浮层，命令结束或按 Esc 就消失；Zellij 的浮动窗格是一等公民窗格，可以在浮动与嵌入之间来回切换（Ctrl+p 然后 e）、整体显隐（Ctrl+p 然后 w），甚至钉住（Ctrl+p 然后 i）。此外 Zellij 还有 tmux 没有的堆叠窗格（Ctrl+p 然后 s）。

「tmux 是唯一解」？也不是

在陌生机器上，GNU Screen 的预装率其实比 tmux 更高，此外还有 dtach、abduco 可选。准确的说法是：tmux 是「装包成本最低、文档和经验最丰富」的那个，而不是唯一选择。

5. 番外篇：Zellij / tmux 能否与 herdr 配合使用？

在 AI 辅助编程爆发的当下，herdr（Rust 编写的 agent multiplexer）热度很高。它的层级比 tmux 多一层——session → workspace → tab → pane → agent——侧边栏会把每个 agent 归到 🔴 blocked、🟡 working、🔵 done、🟢 idle 四态之一，还提供 CLI 与 socket API 供脚本驱动，以及把服务端跑在远程机器上的 remote 模式。

比起「另一个分屏工具」，herdr 的价值在于它理解 agent 的生命周期：你不必再逐个窗格点进去确认哪个 agent 卡在等你回答、哪个已经跑完。它还能直接恢复 agent 的真实会话（例如借助 Claude Code 自身的 resume 能力），而不是只重开一个空白窗格——这正是普通复用器做不到的部分：tmux 能把 shell 留住，但留不住对话。

于是很多人问：能不能把 Zellij 和 herdr 一起用？

结论：可以，而且 herdr 官方把自己定位成互补而非替代。

这里要纠正一个在中文社区流传的说法——「两者是替代关系，嵌套会让 herdr 瞎掉」。herdr 的 README 对 tmux 的原话是「tmux 给你持久化和窗格，但它诞生在 agent 出现之前」，其对比表呈现的是能力叠加而非二选一；而 Zellij 在 v0.45.1 还专门修好了「SSH 下的嵌套会话检测」。嵌套是被正视和支持的场景。

真正需要理解的是方向——这也是「TTY 状态被拦截」那个说法失真的地方。herdr 的状态检测靠进程名匹配 + 终端输出启发式（官方集成的 agent 则通过 socket API 直接上报语义状态）：

herdr 跑在 Zellij／tmux 的窗格里（herdr 在内层）：完全正常。Zellij 并不处在 herdr 和 agent 之间，agent 的 PTY 依然由 herdr 直接持有，检测不受影响。唯一的实际成本是 prefix 键打架，用 Zellij 的 Ctrl+g 锁定模式 / Unlock-First 预设，或改掉 tmux 的 prefix 即可化解。
Zellij／tmux 跑在 herdr 的窗格里（herdr 在外层）：这才是会出问题的方向。此时内层复用器横在中间，herdr 看到的是它的重绘画面而不是 agent 的输出，输出启发式随之失准；进程名匹配看到的也是 zellij 而不是 claude。

AI 时代的选型策略

传统开发流（写代码、跑服务）：Zellij 或 tmux，按前四节的结论选。
AI 驱动开发流（并发管理多个 agent、需随时响应人工确认请求）：把 herdr 放在最外层最省事；若你已有重度定制的 Zellij／tmux 配置，把 herdr 嵌在里面同样可行。

最后两个务实提醒：herdr 目前是 v0.4.0，仍处于 pre-1.0，协议升级可能要求重启服务端；它采用 AGPL-3.0-or-later 加商业授权的双许可——在把它引入闭源工作流之前，这一条值得先让法务看一眼。

6. 选型结论

你的场景	推荐
频繁 SSH 进陌生／老旧服务器	tmux（装包成本最低，经验最丰富）
资源极度受限的小机器	tmux
重度 Vim／Emacs／TUI 用户	tmux，或 Zellij 的 Unlock-First 预设
本地主力机、固定云端开发机	Zellij（原生 layout + 会话复活）
微服务多进程工作区	Zellij（KDL layout 一键拉起）
需要重启后自动恢复工作区	Zellij 原生；tmux 需 resurrect + continuum
并发管理多个 AI coding agent	herdr（可独立使用，也可与前两者嵌套）

tmux 依然是那个在任何恶劣环境下都能拉你一把的可靠老将，Zellij 则是大幅降低心智负担的现代化工作站，而 herdr 补上了前两者诞生时还不存在的那一层：agent 的状态感知。

没有绝对的胜者，只有最适合你当前工作流的利器。如果你已经在 tmux 上建立了完整的肌肉记忆，没有必要为了「现代化」而迁移；但如果你正在配一台新的开发机，现在确实是试试 Zellij 的好时机。

SolanaLink