什么是Tmux
Tmux 在这里不是被当成传统意义上的“终端分屏工具”来介绍，而是作为一种可被脚本化操控的交互式命令行会话容器来使用。它的基本思路很直接：先创建一个独立的 tmux 会话，再通过发送按键把命令输送进去，同时随时抓取窗格里的输出内容。这样一来，原本必须有人盯着终端手动操作的 REPL、命令行程序或需要 TTY 的交互流程，就能被远程驱动和持续观察。
从证据包看，这套用法特别强调边界：只有在确实需要交互式 TTY 时才建议使用 tmux；如果任务只是长时间运行、但并不依赖交互输入，更适合走普通 shell 的后台模式。也就是说，tmux 的价值不在于“所有任务都塞进去”，而在于为那些必须保留终端状态、提示符、上下文和输入节奏的流程提供稳定承载，比如 Python REPL、带提示符的命令行代理，或需要根据输出继续喂入下一步指令的会话。
它的操作模型也比较清晰。会话通过 socket 隔离，便于把当前这一组交互任务和系统里其他 tmux 实例区分开；目标对象采用 session:window.pane 这样的格式定位，默认常见目标就是 :0.0。围绕这一模型，可以列出会话、查看所有窗格、抓取最近若干行历史、等待指定文本出现，必要时还可以直接 attach 进去人工接管，再用快捷键脱离。对于 macOS 和 Linux，它可直接使用；在 Windows 环境下，则需要通过 WSL 安装并运行 tmux。
核心功能特点
- 通过 send-keys 与 capture-pane 组合，远程驱动并读取交互式 CLI 会话状态
- 使用独立 socket 管理会话，便于隔离任务、查找现有 session，并统一清理整组实例
- 支持精确定位到 session:window.pane，可按窗格发送普通文本或控制键如 Ctrl+C
- 可抓取最近历史输出，也能轮询等待特定提示文本出现，适合做半自动监控
- 适合并行拉起多个代理或命令行任务，在不同工作目录中分别运行并检查是否完成
适用场景
最典型的场景，是需要“保留交互上下文”的命令行任务自动化。比如启动一个 Python REPL 后，外部流程继续向它逐步发送输入，再通过抓取窗格内容判断结果是否符合预期。证据包还特别提到，运行 Python REPL 时最好设置 PYTHON_BASIC_REPL=1，因为某些非基础 REPL 会破坏 send-keys 驱动流程。这说明 tmux 在这类场景里承担的并不是简单执行命令，而是维持一个持续存在、可反复对话的终端环境。
第二类场景，是需要监看输出并根据提示符推进流程的半自动控制。工具链里既可以直接抓取最近 200 行或更多历史，也可以借助等待脚本轮询某个正则或固定字符串，直到超时或命中为止。这对那些“必须等命令行出现某个文本，才能决定下一步”的流程尤其有用。与一次性执行命令相比，这种方式更适合处理交互安装、命令行问答、带阶段性输出的脚本，或者需要确认 shell 提示符是否返回来判断任务结束的过程。
再往前一步，tmux 也适合并行编排多个编码代理或命令行代理。证据包给出的例子就是在同一个 socket 下创建多个 session，让不同 agent 分别进入不同工作目录执行任务，再通过抓取窗格末尾内容判断它们是“仍在运行”还是已经回到提示符。对于要同时推进多个修复、实验不同方案、或分拆若干独立命令行任务的团队来说，这种做法能把每个代理的终端状态单独保留下来，既方便轮询，也方便随时 attach 进某个会话人工查看。不过，如果任务本身并不需要交互终端，只是普通的长时运行脚本，那么按照证据包的建议，仍应优先选择非交互后台模式，而不是为了统一而一律放进 tmux。