tmux 到底怎么隔离 shell？Mario 用它替代了什么 Harness 机制？

原始问题

“看不懂什么叫 tmux 隔离” “我还是不懂什么叫暴露出能力” “不同的 shell 页面是天然隔离了，但既然隔离了为啥模型能在同一个终端里重试我也不懂”

tmux = terminal multiplexer（终端多路复用器）。把它理解成”浏览器开启了多个标签页，每个标签页里是一个独立的网页”。每个 tmux 窗口就是一个独立的 shell，关掉一个不影响别的。

核心能力：开多个独立窗口、断线不丢（关终端进程还活着）、随时切换。

操作系统的进程隔离是天生的——不同进程天然互不干扰，像楼里的每户有独立的墙和水电表。

但你只有一个终端窗口（一把钥匙），每次只能进一间房。

tmux 给了你一个钥匙盘——上面挂着所有房间的钥匙，你随时可以开任意一扇门，甚至同时看几间的状态。

tmux 没有创造隔离——隔离是操作系统本来就有的。tmux 让隔离变得可操作。这就是”暴露”。

本来需要 Harness 实现的功能	tmux 怎么替代	为什么能替代
Background Tasks（s13）：长进程管理	`tmux new-window "npm run dev"`——进程在独立窗口里永不停	操作系统的进程天然不需要”等它结束才能干别的事”
Subagent（s06）的进程隔离	不同 tmux 窗口 = 不同进程空间，互不干扰	进程隔离是 OS 原生能力
Worktree Isolation（s18）的进程层	每个 Agent 一个 tmux 窗口	同上

Mario 不在 Harness 代码里造后台线程管理、进程隔离、子进程通信——因为操作系统已经给了最好的实现。Harness 不应该重新发明 OS 已经提供的能力。

原笔记 S11（Error Recovery）中曾有一段把 tmux 和错误重试关联起来的文字，但经讨论确认：对于”看到报错 → 重试”这个动作，tmux 和 Claude Code 的做法效果几乎一样。 模型都能看到错误输出，都能重新执行修正命令。

tmux 的真正价值在：

不在”让重试更方便”。该段已在笔记中修正。

“Harness 不应该重新发明操作系统已经提供的能力。”

“tmux 没有创造隔离——隔离是操作系统本来就有的。tmux 让隔离变得可操作。”