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）：“为结账流程编写 E2E 测试”
模式 5：代码审查管道
并行审查视角：
窗格 1：“审查 src/api/ 的安全漏洞”
窗格 2：“审查 src/api/ 的性能问题”
窗格 3：“审查 src/api/ 的测试覆盖率缺口”
# 将所有审查合并到一个报告中
最佳实践
- 仅限独立任务。 不要并行化彼此输出依赖的任务。
- 明确边界。 每个窗格应处理不同的文件或关注点。
- 有策略地合并。 在合并前审查窗格输出以避免冲突。
- 使用 git worktrees。 对于易产生文件冲突的工作，为每个窗格使用独立的工作树。
- 资源意识。 每个窗格使用 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 multi-agent | 内建代理角色 | 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 并编写交接说明。" }
]
}
该辅助工具：
- 为每个工作进程创建一个基于分支的 git worktree
- 可选择性地将主检出目录中的选定
seedPaths覆盖到每个工作进程的工作树中 - 在每个工作进程的工作树下的
.orchestration/<session>/中写入每个工作进程的task.md、handoff.md和status.md文件 - 启动一个 tmux 会话，每个工作进程一个窗格
- 在每个窗格中启动相应的工作进程命令
- 保持主窗格空闲供编排者使用
当工作进程需要访问尚未属于 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) 安装。