dmux 工作流程
使用 dmux（AI 智能體的 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/ 的測試涵蓋率缺口」
# 將所有審查合併到單一報告中
最佳實務
- 僅處理獨立任務。 不要平行化相互依賴輸出結果的任務。
- 明確邊界。 每個窗格應處理不同的檔案或關注點。
- 策略性合併。 在合併前先檢視窗格輸出，以避免衝突。
- 使用 Git worktrees。 對於容易產生檔案衝突的工作，為每個窗格使用單獨的 worktree。
- 資源感知。 每個窗格都會消耗 API 權杖——將總窗格數控制在 5-6 個以下。
Git Worktree 整合
對於會觸碰重疊檔案的工作：
# 建立 worktrees 以隔離工作
git worktree add -b feat/auth ../feature-auth HEAD
git worktree add -b feat/billing ../feature-billing HEAD
# 在分開的 worktrees 中執行智能體
# 窗格 1：cd ../feature-auth && claude
# 窗格 2：cd ../feature-billing && claude
# 完成後合併分支
git merge feat/auth
git merge feat/billing
輔助工具
| 工具 | 功能 | 使用時機 |
|---|---|---|
| dmux | tmux 窗格管理（用於智能體） | 平行智能體會話 |
| Superset | 終端機 IDE（支援 10+ 平行智能體） | 大規模協調 |
| 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 並撰寫交接備註。" }
]
}
輔助工具會：
- 為每個工作者建立一個分支備份的 git worktree
- 可選擇性地將所選的
seedPaths從主檢出覆蓋到每個工作者的 worktree - 在
.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）安裝。