tmux 与 AI 编程
tmux 是一个终端复用工具，在普通开发场景中用来分屏、保持会话。但在 AI 编程时代，它的定位发生了质变——它变成了多 Agent 并行协作的基础设施。
为什么 AI 编程需要 tmux
单个 AI 会话有两个硬约束：
- 上下文窗口有限：任务越复杂，上下文越快耗尽，AI 输出质量随之下降
- 串行执行慢：一个 Agent 做完 A 才能做 B，无法并行
tmux 解决的是第二个问题，同时缓解第一个问题——把大任务拆成多个子任务，每个 Agent 在独立的 tmux pane 里运行，各自维护自己的上下文窗口，互不干扰。
核心价值
1. 并行任务隔离
把一个功能拆成多个子模块，每个 Agent 负责一块：
┌─────────────────┬─────────────────┐
│ pane 1 │ pane 2 │
│ Agent A │ Agent B │
│ 写后端 API │ 写前端组件 │
├─────────────────┼─────────────────┤
│ pane 3 │ pane 4 │
│ Agent C │ 主会话 │
│ 写测试 │ 协调 + 审查 │
└─────────────────┴─────────────────┘
Agent A、B、C 同时工作，主会话只负责分配任务和审查结果，整体速度是串行的 3 倍。
2. 实时监控与干预
分屏模式下可以同时看到所有 Agent 的实时输出。发现某个 Agent 跑偏了，可以人工切换到那个 pane，直接输入指令纠正，其他 pane 的 Agent 不受影响、继续运行。相比串行执行等到最后才发现问题，这种实时可见性大幅降低了返工成本。
3. 会话持久化
tmux 会话在终端关闭后仍然存活。长时间运行的 AI 任务（比如跑测试、重构大模块）不会因为断网或关闭终端而中断，重新连接后继续监控：
# 断开连接
tmux detach
# 随时重新接入
tmux attach -t my-project
4. ECC 的 tmux 依赖
ECC 的 Hooks 中有一条明确规则：禁止在 tmux 外启动开发服务器。
beforeShellExecution Hook：
检测到 npm run dev / python manage.py runserver 等命令
→ 如果不在 tmux 会话内 → 阻止执行，提示先开 tmux
原因是：开发服务器是长期运行的进程，必须在 tmux 里才能保持稳定，不会因为终端关闭而停掉，也不会和 AI 的其他操作混在一起。
基础使用
安装
# macOS
brew install tmux
# Ubuntu/Debian
sudo apt install tmux
最常用命令
# 新建命名会话
tmux new -s my-project
# 列出所有会话
tmux ls
# 接入已有会话
tmux attach -t my-project
# 在 tmux 内：
# Ctrl+b % 左右分屏
# Ctrl+b " 上下分屏
# Ctrl+b 方向键 切换 pane
# Ctrl+b d 断开（会话保留在后台）
# Ctrl+b [ 进入滚动模式（q 退出）
在 AI 编程中的标准工作流
启动项目
# 1. 创建项目会话
tmux new -s my-project
# 2. 开发服务器放一个 pane（满足 ECC Hook 要求）
npm run dev
# 3. Ctrl+b % 分屏，新 pane 启动 Claude Code / Codex
claude
多 Agent 并行（Claude Code Agent Teams）
Claude Code 原生支持 tmux 分屏模式启动多个 Agent：
# 在 settings.json 中开启
{
"teammateMode": "tmux"
}
# 或启动时指定
claude --teammate-mode tmux
开启后，Shift+Tab 进入代理模式，主会话只负责协调，子任务自动分配给各 pane 的 Agent。
任务分配建议：
- 每个 Agent 分配 5~6 个任务，太细协调成本高，太粗难以并行
- 不同 Agent 负责不同文件/模块，避免同时编辑同一文件产生冲突
- 给每个 Agent 提供完整的初始上下文（项目背景、相关文件、编码规范），因为 Agent 不继承主会话历史
配合 git worktrees 使用
tmux + git worktrees 是最强的并行开发组合：
# 为每个 Agent 创建独立的工作树
git worktree add ../feature-auth auth-branch
git worktree add ../feature-payment payment-branch
# 每个 pane 进入对应工作树
# pane 1：cd ../feature-auth && claude
# pane 2：cd ../feature-payment && claude
每个 Agent 在自己的分支和目录里工作，文件完全隔离，合并时才需要协调。
ECC 的 dmux-workflows Skill
ECC 提供了一个专门为 tmux 多 Agent 编排设计的 Skill：dmux-workflows。
它封装了常见的多 Agent 编排模式：
- 顺序管道：Agent A 完成后触发 Agent B
- 并行扇出：主 Agent 同时派发给多个 Worker Agent
- DAG 编排：有依赖关系的复杂任务图
在 Codex 会话中触发：
使用 dmux-workflows skill 帮我并行实现登录和注册模块
常见问题
Q: 不用 tmux 能用 Claude Code 的多 Agent 吗？
可以，但 ECC 的 Hooks 会在检测到开发服务器命令时报错（因为没有 tmux 环境），需要手动禁用对应 Hook：
export ECC_DISABLED_HOOKS="pre:bash:tmux-reminder"
Q: tmux 和 Agent Teams 有什么区别？
Agent Teams 是 Claude Code 的功能，负责任务分配和 Agent 间通信；tmux 是系统层的终端复用，提供运行环境。两者配合使用，Agent Teams 在 tmux 的各个 pane 里运行，各自保持独立的上下文。
Q: 会话里的 Agent 会互相看到对方的输出吗？
默认不会，每个 pane 是独立进程，上下文隔离。只有主会话显式把某个 Agent 的输出传给另一个时才会共享。