AI 智能体的 Tmux 技能：为什么我们不需要 Tmux 包装器

"远程控制 tmux 会话来管理交互式 CLI。"这是 steipete/clawdis@tmux 的卖点——skills.sh 上安装量最高的 tmux 技能（2.8K 安装量）。它是一个干净、精心编写的技能——170 行，清晰的何时使用/何时不使用部分，交互式 TUI 的安全发送模式。但你的 AI 智能体真的需要它吗？

答案取决于你的智能体架构。对于通过 SSH 断开会话运行的 Claude Code 和 OpenClaw 用户，tmux 是必不可少的基础设施。对于 Hermes 用户，它是不必要的抽象层。理解原因揭示了一个关于智能体工具设计的深层真理。

Tmux 技能做什么

该技能为四个操作提供了结构化接口：

列出会话     → tmux list-sessions
捕获输出     → tmux capture-pane -t shared -p | tail -20
发送按键     → tmux send-keys -t shared "y" Enter
管理窗口     → tmux select-window -t shared:0

主要用例是监视和控制后台 tmux 窗格中运行的 Claude Code 会话。检查会话是否需要输入，发送批准按键，抓取输出用于决策。

架构问题

该技能提出了一个根本问题：AI 智能体应该控制外部终端复用器，还是应该在工具层内置复用能力？

Claude Code 的架构使 tmux 成为自然的。Claude Code 会话在单独的终端中运行，通常跨 SSH 连接。监视需要从外部访问这些会话。Tmux 是桥梁。

Hermes 的架构使 tmux 显得冗余。terminal 工具直接处理每种执行模式：

前台命令     → terminal("npm run build", timeout=300)
后台服务器   → terminal("npm run dev", background=true)
交互式 CLI   → terminal("python repl.py", pty=true)
长时间任务   → terminal("pytest", background=true, notify_on_complete=true)
进程监控     → process(action="poll", session_id=...)
进程输入     → process(action="submit", data="y", session_id=...)

三种执行路径覆盖了每个 tmux 用例，无需外部复用器。一个工具，一个抽象层。

权衡

维度	Tmux 技能	Hermes Terminal
依赖	需要安装 tmux	内置
会话持久性	跨 SSH 断开	智能体会话内
监控粒度	capture-pane（完整回滚）	进程输出流
输入安全	手动 sleep + 字面模式	原生 stdin 处理
错误处理	必须解析 tmux 输出	退出码 + 结构化输出
多会话	窗口/窗格管理	多个后台进程

更深层的原理

偏好集成到智能体执行模型中的工具，而不是要求智能体适应外部执行模型的工具。

理解进程生命周期、stdin/stdout/stderr、退出码和后台管理的终端工具自然集成。向外部窗格发送按键的 tmux 包装器总是通过玻璃墙操作——将输出视为文本而非结构化结果，将输入作为按键而非编程调用。

当 Tmux 技能有意义时

你在 tmux 会话中运行 Claude Code 或 Codex CLI — 这是主要用例。该技能管理 AI 智能体会话，而非任意进程。
你的智能体跨 SSH 断开操作 — tmux 的会话持久性是其远程开发的关键特性。
你需要会话恢复 — 如果长时间运行的 Claude Code 会话在断开后需要关注，tmux 技能是唯一访问它的方式。

但对于直接在智能体工具层执行任务的 Hermes 用户——构建、测试、部署——终端工具是正确的抽象。不是因为 tmux 技能不好。而是因为它们解决的问题 Hermes 架构已经用不同方式解决了。