古法编程

多 Agent 并行编排的核心在于任务分发与隔离。在 Everything Claude Code 体系内，DevFleet 通过 plan_project API 实现任务 DAG 自动拆解与 worktree 隔离派发，适合自动化流水线；dmux-workflows 则基于 tmux 提供灵活的手动多 Pane 管理，适合交互式并行开发。两种模式均可与 team-builder 的交互式团队配置流程结合，组建跨领域 AI 协作团队。

多 Agent 并行编排实战：DevFleet 隔离 Worktree 与 tmux 多 Pane 协作

当单个 AI Agent 处理复杂项目时，效率瓶颈日益明显。将任务拆解并分配给多个并行工作的 Agent 是提升生产力的关键。Everything Claude Code 提供了两种截然不同的并行编排范式：DevFleet Skill 和 dmux-workflows Skill。本文将通过实战步骤，对比这两种模式的工作原理、配置方法和适用场景，并展示如何结合 team-builder 流程组建高效 AI 团队。

1. 并行模式对比：自动化编排与手动调度

选择哪种模式，取决于你的任务特性和对控制程度的需求。

特性 DevFleet Skill (DAG 编排) dmux-workflows Skill (tmux 管理)
核心机制 中央编排器自动拆解任务 DAG，在独立 git worktree 中派发并监控 Agent。 基于 tmux 终端复用，手动或通过脚本在多个 Pane 中启动不同 Agent 会话。
任务规划 自动化。通过 plan_project API 由 AI 生成依赖关系明确的计划。 手动/半自动。用户自行划分任务，并配置 plan.json 或直接在 Pane 中输入指令。
隔离性 强隔离。每个任务在独立的 git worktree 中运行，彻底避免文件冲突。 可选隔离。需用户手动为每个 Pane 创建 git worktree 或确保任务操作不同文件。
依赖管理 自动处理。系统按 DAG 依赖顺序派发任务，上游完成后自动触发下游。 手动管理。需用户自行安排任务顺序或通过脚本实现依赖逻辑。
监控与报告 内置。通过 get_dashboard() 和 get_report() 获取结构化状态与报告。 依赖外部。需用户切换 Pane 查看输出，或通过脚本收集日志。
适用场景 大型、模块化、依赖关系明确的项目；追求全自动化的 CI/CD 集成。 探索性开发、需要灵活交互的并行调试、跨多个不同 AI 工具链的协作。

2. DevFleet 实战：用 plan_project 实现自动化 DAG 编排

DevFleet 的核心是将一个模糊的项目目标，转化为一系列可并行或按序执行的任务。

步骤一：规划项目任务 DAG

向 AI 描述你的项目目标，它会返回一个包含任务依赖关系的 JSON 计划。

输入：

const { project_id, missions } = await plan_project({
  prompt: "为现有 Next.js 应用添加用户认证系统，包括注册、登录、JWT 签发、API 路由保护和对应的单元测试。"
});

输出示例：

{
  "project_id": "proj-7a9b2c",
  "missions": [
    {
      "mission_id": "m1",
      "title": "设计认证数据库 Schema 与 Prisma Migration",
      "depends_on": [],
      "auto_dispatch": true
    },
    {
      "mission_id": "m2",
      "title": "实现注册与登录 API 路由 (/api/auth/register, /api/auth/login)",
      "depends_on": ["m1"],
      "auto_dispatch": true
    },
    {
      "mission_id": "m3",
      "title": "实现 JWT 签发与验证中间件",
      "depends_on": ["m2"],
      "auto_dispatch": true
    },
    {
      "mission_id": "m4",
      "title": "创建受保护路由示例 (/api/protected) 并编写集成测试",
      "depends_on": ["m3"],
      "auto_dispatch": true
    }
  ]
}

步骤二：派发任务与并行监控

派发首个无依赖的任务，系统将自动管理后续派发。通过 Dashboard 查看全局状态。

派发与监控：

// 派发首个任务
await dispatch_mission({ mission_id: "m1" });

// 查询全局状态
const status = await get_dashboard();
console.log(`项目 ${project_id} 进度: ${status.completed}/${status.total}`);
console.log(`当前运行中任务: ${status.running_agents.join(', ')}`);

// 查询特定任务状态
const mission_status = await get_mission_status({ mission_id: "m2" });
console.log(`任务 m2 状态: ${mission_status.status}`); // 'pending', 'running', 'completed', 'failed'

步骤三：收集结构化报告

任务完成后，获取详细报告用于集成或人工审查。

const report = await get_report({ mission_id: "m2" });
/* 报告结构示例：
{
  files_changed: ["src/app/api/auth/register/route.ts", "src/app/api/auth/login/route.ts"],
  what_done: "实现了基于 Next.js App Router 的注册与登录 API 端点，使用 bcrypt 加密密码。",
  errors: [],
  next_steps: "可以开始实现 JWT 中间件 (m3)，或对当前端点进行测试。"
}
*/

验证与错误处理

  • 验证：调用 get_dashboard() 应返回 running_agents 数量符合预期，各任务状态流转正常。
  • 错误：若任务失败，get_report 中的 errors 字段会包含错误信息。可修正依赖或代码后，重新派发该任务。

3. dmux 实战：用 plan.json 配置 tmux 多 Pane 流水线

dmux 提供更底层的控制，适合精细编排。其自动化脚本通过 plan.json 配置。

步骤一：定义 plan.json

创建一个配置文件，描述会话、工作节点和任务。

plan.json 示例：

{
  "sessionName": "auth-system-build",
  "baseRef": "HEAD",
  "launcherCommand": "claude exec --cwd {worktree_path} --task-file {task_file}",
  "workers": [
    {
      "name": "db-schema",
      "task": "为用户认证设计数据库 Schema。创建 Prisma 模型 User（含 email, hashedPassword 字段）并生成 migration。"
    },
    {
      "name": "api-routes",
      "task": "实现两个 Next.js API 路由：/api/auth/register 和 /api/auth/login。遵循 REST 最佳实践。"
    }
  ]
}

步骤二：执行编排脚本

运行脚本，它会自动为每个 worker 创建 git worktree，生成任务文件，并在 tmux 中启动对应的 Pane。

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

执行后，tmux 会话将启动两个 Pane：

  1. db-schema Pane：运行 claude，工作目录在 ../auth-system-build-db-schema worktree 中，执行数据库 Schema 设计任务。
  2. api-routes Pane：运行 claude，工作目录在 ../auth-system-build-api-routes worktree 中，执行 API 路由实现任务。

步骤三：手动交互与监控

在 tmux 会话中，你可以自由切换 Pane（Ctrl+b 然后按方向键），查看每个 Agent 的实时输出，并进行人工干预。

验证与错误处理

  • 验证：在每个 Pane 中，观察 Claude Code 的输出是否符合任务描述，检查 worktree 目录下的文件变更。
  • 错误：如果某个 Agent 进入错误循环或停滞，可以中断其会话（在 Pane 中发送中断信号），修正 plan.json 或任务描述后重新运行。

4. 组建团队：team-builder 交互式菜单流程

无论使用哪种并行模式，你都可以先通过 team-builder Skill 组建一个跨领域的 AI 专家团队，为并行任务选择最合适的 Agent。

  1. 启动 team-builder：在 Claude Code 中输入 team builder。
  2. 浏览领域菜单：Skill 会自动发现并分类所有可用 Agent，展示交互式菜单。
    Available agent domains:
1. Engineering (3) — Software Architect, Security Engineer, Database Optimizer
2. QA & Testing (2) — E2E Test Engineer, Performance Tester
3. DevOps (1) — CI/CD Specialist

Pick domains or name specific agents:
  3. 选择与确认：输入数字或关键词（如 1,3 或 architect + security）选择你需要的专家团队。确认后，描述本次团队需要共同完成的任务。
  4. 派发与综合：team-builder 会并行派发任务给选中的 Agent，并自动综合它们的输出，生成一份包含共识、冲突和建议的报告。

你可以将 team-builder 的输出作为 DevFleet 的 plan_project 的输入 prompt，或者将其分配给 dmux 的不同 Pane。

5. 选择建议与总结

  • 选 DevFleet 如果：你的任务能清晰地拆解为依赖链，追求“从目标到报告”的全自动化，尤其适合集成到 CI/CD 流程。
  • 选 dmux 如果：你需要更灵活的实时控制，任务间可能需要频繁交互，或者你正在同时使用 Claude Code、Codex 等多种工具。

两种模式并非互斥。你可以在 DevFleet 的某个复杂任务内部，使用 dmux 进行更精细的并行调试。核心是理解它们提供的不同层次的抽象：DevFleet 是面向项目的 DAG 编排器，dmux 是面向会话的 终端管理器。

FAQ

Q: DevFleet 和 dmux 可以一起使用吗？ A: 可以。例如，用 DevFleet 规划出“实现前端”和“实现后端”两个大任务，然后在派发“实现前端”这个任务时，其内部的 Agent 可以使用 dmux 来并行管理多个 UI 组件和页面的开发。

Q: 并行多个 Agent 会很快耗尽 API Token 吗？ A: 会。并行度越高，Token 消耗速度越快。DevFleet 通过 DEVFLEET_MAX_AGENTS 限制并发数。dmux 则依赖用户自觉控制 Pane 数量。建议在资源有限时，优先并行关键路径上的任务。

Q: 如果自动合并（DevFleet）或手动合并（dmux）时出现代码冲突怎么办？ A: 对于 DevFleet，冲突的变更会保留在各自的 worktree 分支中，需要人工介入解决后才能合并。对于 dmux，如果在主分支上并行编辑了相同文件，冲突概率很高，因此强烈建议为每个 dmux Pane 配合 git worktree 使用，从物理上隔离工作区。