Zellij 很容易被先塞进 tmux 那个抽屉里。这个比较并没有错，只是太小。更合适的理解方式，是把它看成一套终端工作区运行时，它内部至少有三层彼此分开的控制表面：一层是声明式布局，一层是建立在 WebAssembly 之上的插件系统，还有一层是如今已经能经由内建 web client 离开本地终端的会话共享能力。[1][2][3][6] 这三层一旦同时进入视野，Zellij 看起来就不再只是“更自然手的分屏器”，而更像一套把终端工作区当作可编排状态来处理的系统。
放在 2026 年看，这个区分更值得认真对待，因为项目显然处在持续运转之中，而并非靠旧印象维持热度。截至 2026-04-17T07:04:10Z UTC，GitHub API 显示 zellij-org/zellij 有 31,643 个 stars、1,116 个 forks、1,637 个 open issues，最近一次 push 时间是 2026-04-16T14:00:05Z。[7] 发布通道也在持续前进：v0.44.1 发布于 2026-04-07，此前是 2026-03-23 的 v0.44.0，再往前是 2025-08-08 的 v0.43.1。[8] 这些数字本身无法证明架构质量，它们说明的是另一件事：这个设计正在被足够大的用户面持续施压，因此这些边界值得被认真拆开。
配图说明：题图改为沉浸式的真实终端工作场景，而并非头像或分析图。这个选择合适，因为本文关心的并非主题外观，也并非窗格边框。真正的问题在于，Zellij 是否真的把一套足够自洽的工作区模型搭了出来，足以让人在 shell 之外再接受一层新抽象。
真正的控制平面落在布局文件，而并非眼前的窗格树
Zellij 最能暴露项目思路的文档，是它的 layouts 指南。文档写得很直接：布局是定义窗格与标签页排列方式的文本文件，可以在启动时应用，也可以在正在运行的会话里应用，配置语言使用 KDL。[2] 这件事表面上很平常，往里看就能看出方向差异。传统终端复用器往往让“当前窗格树”显得更像第一对象，配置只是事后附着上去。Zellij 则把重点倒了过来。布局文件才是耐久对象，运行中的窗格排列只是这个对象的一次执行。
这个选择会带来很实际的后果。布局可以命名、保存、重复调用，也可以在运行时被覆盖，而且允许保留那些放不进新拓扑中的既有窗格。[2] 顺着这个层面看，工作区结构就不再只是“刚才按了哪些键”的副产品。它可以像别的工程资产一样被版本化。README 里把 layouts 描述为个人自动化的一条路径，而并非单纯的窗口预设，讲的也是同一件事。[1]
远程布局这一点又把边界写得更清楚。Zellij 允许从远程 URL 加载布局，但出于安全原因，布局里的命令不会直接执行，而是先被挂起，显示一条提示横幅，等用户逐个确认是否运行。[2] 这是很强的架构信号。项目愿意让工作区拓扑变得可移植、可分享，却没有把跨信任边界流动的声明式工作区文件假定成无害对象。布局导入可以顺滑，命令执行则故意保留摩擦，这个判断很稳。
因此，Zellij 更像一套工作区操作模型，而并非一串宏录制。团队可以把一个 layout 当作可重复的环境骨架：编辑器在这里，日志在另一边，测试跑在第三个窗格，辅助插件固定在该出现的位置。终端于是慢慢脱离了临时草稿纸的形态，开始接近一种被声明出来的环境结构。[1][2]
插件是第一等窗格，但它们并非没有边界的 shell 扩展
第二层架构是插件系统，这也是 Zellij 与旧式 multiplexer 习惯拉开距离最明显的地方。插件文档写明，Zellij 提供的是 WebAssembly / WASI 插件系统；Zellij 自己的 UI 就由插件构成；插件在工作区里与终端窗格一样，属于第一等公民，可以渲染界面、响应应用状态变化，也可以通过插件 API 控制 Zellij 的行为。[3] 这已经并非“给状态栏写点脚本”那种扩展，而是一条带着明确 host/guest 边界的正式延展面。
插件加载模型又把这种思路继续推实。插件可以通过布局、快捷键、命令行或者内建 plugin manager 加载，插件本身则通过 URL 表达：可以是本地 file: 路径，可以是内建 zellij: 插件，可以是 http(s) 地址，也可以是别名。[5] 这意味着 Zellij 把插件看作可寻址组件，而并非夹在配置文件里的零散补丁。工作区不仅能配置，还能被组合。
真正把这层能力收住的，是权限模型。Zellij 把事件与命令背后的能力拆成显式权限类别，例如 OpenFiles、RunCommand、OpenTerminalsOrPlugins、FullHdAccess、InterceptInput、ReadPaneContents 与 StartWebServer。[4] 插件并不会在加载之后自动拿到这些能力，而是需要主动请求。[4][5] 对终端工具来说，这是正确边界，因为终端本来就是最容易把过大权限包进便利感里的一类软件。Zellij 没有消除风险，它做的是让能力请求变得可见。
这对操作者与谨慎的开发者都有实际价值。很多终端定制系统一旦能力上升，理解难度也会迅速上升，因为 shell 启动脚本、编辑器钩子、本地脚本会慢慢混成一团。Zellij 的插件模型则更清楚：代码是独立的，加载路径是被命名的，高风险行为有权限标签。[3][4][5] 对一件工作区工具来说，这种可读性本身就是功能。
会话共享这一层，让项目不再只是本地 multiplexer
第三层边界是最新的一层，也是架构上最有野心的一层。Zellij 的 web client 教程写得很清楚：从 0.43.0 开始，项目内建了一个可选开启的 web server，可以把同一台机器上的 Zellij 会话直接服务给浏览器，带有内建认证、可书签化的持久会话，以及真正的多人能力。[6] 这件事一旦成立，项目的角色就已经不只是帮助一个人在本地终端里整理窗格，它是在把会话状态暴露成一项服务。
细节很重要。默认情况下，这个服务监听在 http://127.0.0.1:8082；URL 结构本身就是会话模型的一部分：访问 /my-amazing-session 这样的路径时，如果会话不存在就创建，存在就附着，已经退出就复原。[6] 登录需要 token，token 只显示一次，另外还有只读 token，用于演示、教学或旁观式观看。[6] 权限文档也反过来印证了这层扩展，因为它把 StartWebServer 单独列成了一种显式能力。[4]
这里发生的是一跳真正的架构跃迁。旧式 multiplexer 语境里的协作，往往意味着几个人 SSH 进同一台机器，然后默认每个人的习惯都能彼此兼容。Zellij 则把协作原语往上抬了一层。会话可以是持久的、具名的、浏览器可访问的，也可以是只读的，并且通过明确的认证 token 加以保护。[6] 终端开始只是工作区的一个客户端，而并非唯一客户端。
也正是在这一层，项目 README 里的“batteries included” 才最容易被认真评估。若需求只是分屏与快捷键，这一层当然会显得额外。若需求是一个能在终端与浏览器之间移动、能长期保存具名会话、能在演示或结对排障里直接共享的工作区，那么 web client 就并非噱头，而是这个项目最重要的方向之一。[1][6]
它最适合的地方，与它更显得额外的地方
Zellij 最强的时候，往往出现在用户希望把终端工作做成“可重复的工作区”，而并非只做成“更高效的键盘习惯”。Layouts 适合那些窗格几何、启动命令与工作区骨架应当一次声明、反复复用的场景。[1][2] 插件适合那些需要自定义界面或控制点、又不想一路滑进 shell 脚本堆里的工作区。[3][4][5] Web 层则适合那些需要让会话保留下来、流动起来、被多人观察或进入的团队与个人。[6]
它更显得额外的边界也同样清楚。若你的需求只是通过 SSH 使用一件足够轻、尽量少一层抽象的 multiplexer，Zellij 就会显得“架构多于需求”。布局、插件、web 会话都是要学习、要理解、要信任的新表面。项目之所以还站得住，是因为这些表面各自都有清楚边界。但额外复杂度本身依旧存在。一套设计得再干净的工作区运行时，终究仍然是一套运行时。
所以，理解 2026 年的 Zellij，最好的方式并非“终端复用器做得更友好”。它真正的架构命题是：终端工作区值得拥有第一等对象，值得拥有声明出来的布局、可寻址的插件，以及带着显式权限边界的具名共享会话。[1][2][3][4][5][6] 一旦这样去看，项目的很多选择都会变得顺理成章。它并不打算只靠窗格管理取胜，它要做的是把终端状态变成一种足够有结构、因此能够组合、共享、保存下来的东西。
来源
- Zellij README：项目定义、通过 layouts 做个人自动化、协作能力、内建 web client，以及整体产品形态。
- Zellij 用户指南《Layouts》：KDL 布局文件、启动与运行期应用、远程布局行为，以及运行期覆盖机制。
- Zellij 用户指南《Plugins》：WebAssembly/WASI 插件模型、插件作为第一等工作区对象，以及 UI 本身的插件化结构。
- Zellij 用户指南《Permissions》：显式插件权限模型，包括
RunCommand、FullHdAccess、InterceptInput、ReadPaneContents与StartWebServer。 - Zellij 用户指南《Loading Plugins》：通过布局、快捷键、CLI、plugin manager 加载插件，以及插件 URL schema。
- Zellij 教程《The Zellij Web Client - Share Sessions in the Browser》：从 0.43.0 开始的内建 web server、token 模型、只读 token 与会话 URL 行为。
zellij-org/zellij的 GitHub API 快照：文章写作时的 stars、forks、open issues 与最近一次 push 时间。zellij-org/zellij的 GitHub API release 列表：最近几个发布标签与发布时间。