| name | dmux-workflows |
| description | 使用 dmux(AI agent 的 tmux 窗格管理器)进行多代理编排。跨 Claude Code、Codex、OpenCode 和其他 harness 的并行代理工作流模式。当并行运行多个代理会话或协调多代理开发工作流时使用。 |
dmux 工作流
使用 dmux 编排并行 AI agent 会话,这是一个用于 agent harness 的 tmux 窗格管理器。
何时激活
- 并行运行多个代理会话
- 跨 Claude Code、Codex 和其他 harness 协调工作
- 从分而治之并行性中受益的复杂任务
- 用户说"并行运行"、"拆分这项工作"、"使用 dmux"或"多代理"
dmux 是什么
dmux 是一个基于 tmux 的编排工具,管理 AI agent 窗格:
- 按
n 创建带有提示的新窗格
- 按
m 将窗格输出合并回主会话
- 支持:Claude Code、Codex、OpenCode、Cline、Gemini、Qwen
安装: npm install -g dmux 或参见 github.com/standardagents/dmux
快速开始
dmux
工作流模式
模式 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:跨 Harness
为不同的任务使用不同的 AI 工具:
窗格 1(Claude Code):"审查身份验证模块的安全性"
窗格 2(Codex):"重构工具函数以提高性能"
窗格 3(Claude Code):"为结账流程编写 E2E 测试"
模式 5:代码审查管道
并行审查视角:
窗格 1:"审查 src/api/ 的安全漏洞"
窗格 2:"审查 src/api/ 的性能问题"
窗格 3:"审查 src/api/ 的测试覆盖率缺口"
# 将所有审查合并为单个报告
最佳实践
- 仅限独立任务。 不要并行化依赖彼此输出的任务。
- 清晰的边界。 每个窗格应该处理不同的文件或关注点。
- 战略性合并。 在合并之前审查窗格输出以避免冲突。
- 使用 git worktree。 对于容易发生文件冲突的工作,每个窗格使用单独的 worktree。
- 资源意识。 每个窗格使用 API 令牌 — 保持总窗格数在 5-6 以下。
Git Worktree 集成
对于涉及重叠文件的任务:
git worktree add ../feature-auth feat/auth
git worktree add ../feature-billing feat/billing
git merge feat/auth
git merge feat/billing
互补工具
| 工具 | 功能 | 何时使用 |
|---|
| dmux | 用于代理的 tmux 窗格管理 | 并行代理会话 |
| Superset | 用于 10+ 个并行代理的终端 IDE | 大规模编排 |
| Claude Code Task 工具 | 进程内子代理生成 | 会话内的程序化并行性 |
| Codex 多代理 | 内置代理角色 | Codex 特定的并行工作 |
故障排除
- 窗格无响应: 检查代理会话是否正在等待输入。使用
m 读取输出。
- 合并冲突: 使用 git worktree 按窗格隔离文件更改。
- 高令牌使用: 减少并行窗格数量。每个窗格都是一个完整的代理会话。
- 未找到 tmux: 使用
brew install tmux(macOS)或 apt install tmux(Linux)安装。