dmux-workflows

dmux 工作流

使用 dmux（一种面向代理工具链的 tmux 窗格管理器）编排并行 AI 代理会话。

何时激活

• 并行运行多个代理会话
• 协调跨 Claude Code、Codex 及其他工具链的工作
• 复杂任务受益于分而治之的并行处理
• 用户提到“并行运行”、“拆分工作”、“使用 dmux”或“多代理”

什么是 dmux

dmux 是一个基于 tmux 的编排工具，用于管理 AI 代理窗格：

• 按 n 创建新窗格并输入提示
• 按 m 将窗格输出合并回主会话
• 支持：Claude Code、Codex、OpenCode、Cline、Gemini、Qwen

安装： 在审查包后从其仓库安装 dmux。参见 github.com/standardagents/dmux

快速开始

# 启动 dmux 会话
dmux

# 创建代理窗格（在 dmux 中按 'n'，然后输入提示）
# 窗格 1：“在 src/auth/ 中实现认证中间件”
# 窗格 2：“为用户服务编写测试”
# 窗格 3：“更新 API 文档”

# 每个窗格运行自己的代理会话
# 按 'm' 合并结果

工作流模式

模式 1：研究 + 实现

将研究和实现拆分为并行轨道：

窗格 1（研究）：“研究 Node.js 中速率限制的最佳实践。
  检查当前库，比较方法，并将结果写入
  /tmp/rate-limit-research.md”

窗格 2（实现）：“为我们的 Express API 实现速率限制中间件。
  从基本的令牌桶开始，研究完成后进行优化。”

# 窗格 1 完成后，将结果合并到窗格 2 的上下文中

模式 2：多文件功能

跨独立文件并行工作：

窗格 1：“为计费功能创建数据库模式和迁移”
窗格 2：“在 src/api/billing/ 中构建计费 API 端点”
窗格 3：“创建计费仪表盘 UI 组件”

# 全部合并后，在主窗格中进行集成

模式 3：测试 + 修复循环

在一个窗格中运行测试，在另一个窗格中修复：

窗格 1（监视器）：“以监视模式运行测试套件。当测试失败时，
  总结失败信息。”

窗格 2（修复器）：“根据窗格 1 的错误输出修复失败的测试”

模式 4：跨工具链

对不同任务使用不同的 AI 工具：

窗格 1（Claude Code）：“审查认证模块的安全性”
窗格 2（Codex）：“重构工具函数以提升性能”
窗格 3（Claude Code）：“为结账流程编写端到端测试”

模式 5：代码审查流水线

并行审查视角：

窗格 1：“审查 src/api/ 的安全漏洞”
窗格 2：“审查 src/api/ 的性能问题”
窗格 3：“审查 src/api/ 的测试覆盖率缺口”

# 将所有审查合并为一份报告

最佳实践

1. 仅限独立任务。 不要并行化相互依赖的任务。
2. 明确边界。 每个窗格应处理不同的文件或关注点。
3. 策略性合并。 在合并前审查窗格输出，避免冲突。
4. 使用 git worktrees。 对于容易产生文件冲突的工作，为每个窗格使用独立的工作树。
5. 资源意识。 每个窗格消耗 API 令牌——保持总窗格数不超过 5-6 个。

Git Worktree 集成

对于涉及重叠文件的任务：

# 创建工作树以实现隔离
git worktree add -b feat/auth ../feature-auth HEAD
git worktree add -b feat/billing ../feature-billing HEAD

# 在独立工作树中运行代理
# 窗格 1：cd ../feature-auth && claude
# 窗格 2：cd ../feature-billing && claude

# 完成后合并分支
git merge feat/auth
git merge feat/billing

补充工具

工具	功能	使用场景
dmux	面向代理的 tmux 窗格管理	并行代理会话
Superset	支持 10+ 并行代理的终端 IDE	大规模编排
Claude Code Task 工具	进程内子代理生成	会话内的程序化并行
Codex 多代理	内置代理角色	Codex 特定的并行工作

ECC 辅助工具

ECC 现在包含一个用于外部 tmux 窗格编排（配合独立 git worktrees）的辅助工具：

node scripts/orchestrate-worktrees.js plan.json --execute

示例 plan.json：

{
  "sessionName": "skill-audit",
  "baseRef": "HEAD",
  "launcherCommand": "codex exec --cwd {worktree_path} --task-file {task_file}",
  "workers": [
    { "name": "docs-a", "task": "修复技能 1-4 并编写交接笔记。" },
    { "name": "docs-b", "task": "修复技能 5-8 并编写交接笔记。" }
  ]
}

该辅助工具：

• 为每个 worker 创建一个基于分支的 git worktree
• 可选地将主检出中的选定 seedPaths 覆盖到每个 worker 的工作树中
• 在每个 worker 的工作树下写入 task.md、handoff.md 和 status.md 文件，位于 .orchestration/<session>/ 目录
• 启动一个 tmux 会话，每个 worker 对应一个窗格
• 在每个窗格中启动 worker 命令
• 主窗格留给编排器使用

当 worker 需要访问尚未包含在 HEAD 中的脏文件或未跟踪的本地文件（如本地编排脚本、草稿计划或文档）时，使用 seedPaths：

{
  "sessionName": "workflow-e2e",
  "seedPaths": [
    "scripts/orchestrate-worktrees.js",
    "scripts/lib/tmux-worktree-orchestrator.js",
    ".claude/plan/workflow-e2e-test.json"
  ],
  "launcherCommand": "bash {repo_root}/scripts/orchestrate-codex-worker.sh {task_file} {handoff_file} {status_file}",
  "workers": [
    { "name": "seed-check", "task": "在开始工作前验证种子文件是否存在。" }
  ]
}

故障排除

• 窗格无响应： 直接切换到该窗格，或使用 tmux capture-pane -pt <session>:0.<pane-index> 检查。
• 合并冲突： 使用 git worktrees 隔离每个窗格的文件更改。
• 令牌使用量过高： 减少并行窗格数量。每个窗格都是一个完整的代理会话。
• tmux 未找到： 使用 brew install tmux（macOS）或 apt install tmux（Linux）安装。