⚡

多代理工作力规划器 multi-agent-workforce-planner

多代理工作力规划器技能用于设计并行代理工作流，通过分析任务依赖、分配专业代理类型（如探索、计划、Bash、编辑），最大化工作并行化，并创建包含进度跟踪和故障恢复的执行计划。适用于大型软件功能的分解和并行开发，提高开发效率和可靠性。关键词：多代理系统、并行工作流、任务分解、AI代理、软件开发规划。

AI智能体 0 次安装 0 次浏览 更新于 3/7/2026

name: 多代理工作力规划器 description: 通过分析依赖、分配专业代理类型（探索、计划、Bash、编辑），最大化并行化，并创建带有进度跟踪和故障恢复的执行计划，为大型功能集设计并行代理工作流。在将大型功能分解为并行代理工作时使用。 license: MIT complexity: 高级 time_to_learn: 1小时 prerequisites: [产品需求设计师] tags: [多代理, 并行, 规划, 工作流, 任务分解]

多代理工作力规划器

通过分析依赖、分配专业代理，并最大化并行化，为大型功能实现设计并行代理工作流。

使用时机

  • 将大型功能分解为并行工作
  • 规划多文件实现
  • 协调专业代理类型
  • 最大化开发吞吐量
  • 管理复杂依赖链

核心框架

功能规范 → 需求 → 依赖图 → 并行流 → 代理分配
     ↓        ↓         ↓          ↓          ↓
   输入文档   分解为任务  识别阻塞项  分组为工作流  匹配到代理类型

任务粒度

级别 描述 典型范围
史诗 大型功能区域 几天到几周
工作流 可并行化的轨道 小时到天
任务 单个工作单元 30分钟 - 2小时
子任务 原子操作 5-30分钟

代理类型目录

代理 专长 最适合
探索 只读分析 查找文件、理解模式、代码库研究
计划 架构设计 系统设计、依赖分析、实现规划
Bash 命令执行 测试、构建、git操作、文件系统命令
编辑 文件修改 实现、重构、代码更改

代理选择规则

需要理解代码？ → 探索
需要设计解决方案？ → 计划
需要运行命令？ → Bash
需要修改文件？ → 编辑

规划过程

步骤1：分解需求

将功能分解为离散任务：

feature: "用户认证系统"
tasks:
  - id: T1
    name: "研究现有认证模式"
    type: research
    agent: 探索

  - id: T2
    name: "设计认证架构"
    type: design
    agent: 计划
    depends_on: [T1]

  - id: T3
    name: "实现用户模型"
    type: implementation
    agent: 编辑
    depends_on: [T2]

  - id: T4
    name: "实现认证中间件"
    type: implementation
    agent: 编辑
    depends_on: [T2]

  - id: T5
    name: "编写认证测试"
    type: testing
    agent: 编辑
    depends_on: [T3, T4]

  - id: T6
    name: "运行测试套件"
    type: verification
    agent: Bash
    depends_on: [T5]

步骤2：构建依赖图

graph TD
    T1[研究模式] --> T2[设计架构]
    T2 --> T3[实现用户模型]
    T2 --> T4[实现中间件]
    T3 --> T5[编写测试]
    T4 --> T5
    T5 --> T6[运行测试]

步骤3：识别并行机会

没有依赖关系的任务可以并行运行：

阶段1: T1 (单独 - 必须先完成)
阶段2: T2 (单独 - 设计阶段)
阶段3: T3, T4 (并行 - 独立实现)
阶段4: T5 (单独 - 需要两个实现)
阶段5: T6 (单独 - 验证)

步骤4：创建工作流

将相关任务分组到工作流：

workstreams:
  - name: "核心认证"
    tasks: [T3, T5的部分]
    owner: agent-1

  - name: "中间件"
    tasks: [T4, T5的部分]
    owner: agent-2

并行化策略

水平并行化

多个独立功能同时进行：

功能A ─────────────────────>
功能B ─────────────────────>
功能C ─────────────────────>

垂直并行化

同一功能的不同层：

前端  ─────────────>
后端   ─────────────>
数据库  ─────────────>
测试     ─────────────>

接口优先并行化

定义合同，并行实现：

1. 定义接口/类型 (阻塞)
2. 并行实现生产者和消费者

phase1:
  - task: "定义API合同"
    agent: 计划
    blocking: true

phase2_parallel:
  - task: "实现API服务器"
    agent: 编辑
  - task: "实现API客户端"
    agent: 编辑

推测性并行化

提前开始可能需要的工 ā作：

main_path:
  - task: "实现功能"
    agent: 编辑

speculative:
  - task: "准备测试夹具"
    agent: 编辑
    confidence: high  # 绝对需要
  - task: "起草文档"
    agent: 编辑
    confidence: medium  # 可能需要修订

进度跟踪

状态格式

工作流A: [████████░░] 80% (8/10任务)
  └─ 阻塞: 等待B的API合同

工作流B: [██████████] 100% ✓

工作流C: [████░░░░░░] 40%
  └─ 风险: 任务7失败两次

任务状态

状态 符号 含义
待定 ○ 未开始
进行中 ◐ 当前执行
已完成 ● 成功完成
阻塞 ⊘ 等待依赖
失败 ✗ 需要干预
跳过 ⊖ 有意跳过

进度表

| 任务 | 代理 | 状态 | 阻塞于 | 备注 |
|------|-------|--------|------------|-------|
| T1   | 探索 | ● | - | 已完成 |
| T2   | 计划    | ● | - | 已完成 |
| T3   | 编辑    | ◐ | - | 进行中 |
| T4   | 编辑    | ◐ | - | 进行中 |
| T5   | 编辑    | ○ | T3, T4 | 等待 |
| T6   | Bash    | ○ | T5 | 等待 |

故障恢复

重试策略

retry_policy:
  max_attempts: 3
  backoff: exponential
  base_delay: 30s

on_failure:
  - log_error
  - notify_supervisor
  - attempt_recovery
  - escalate_if_exhausted

恢复模式

  1. 重试: 相同代理，相同任务
  2. 重新分配: 不同代理，相同任务
  3. 分解: 将任务分解为更小的子任务
  4. 跳过: 标记为跳过，继续下游
  5. 升级: 需要人工干预

检查点策略

checkpoints:
  - after: phase1
    save: ["合同", "接口"]

  - after: phase2
    save: ["实现"]
    validate: ["类型匹配", "测试通过"]

工作流模板

workstream:
  name: "功能名称"
  id: WS-001
  owner: 代理类型

  objectives:
    - "主要目标"
    - "次要目标"

  tasks:
    - id: T1
      name: "任务描述"
      agent: 探索
      estimated: 15分钟

    - id: T2
      name: "下一个任务"
      agent: 编辑
      depends_on: [T1]
      estimated: 30分钟

  success_criteria:
    - "所有测试通过"
    - "无类型错误"

  risks:
    - risk: "复杂集成"
      mitigation: "早期接口定义"

示例：完整功能分解

功能：添加用户资料编辑

epic:
  name: "用户资料编辑"

workstreams:
  - name: "后端API"
    tasks:
      - {id: B1, name: "研究当前用户模型", agent: 探索}
      - {id: B2, name: "设计资料更新端点", agent: 计划, depends_on: [B1]}
      - {id: B3, name: "实现 PUT /users/:id/profile", agent: 编辑, depends_on: [B2]}
      - {id: B4, name: "添加验证中间件", agent: 编辑, depends_on: [B2]}
      - {id: B5, name: "编写API测试", agent: 编辑, depends_on: [B3, B4]}

  - name: "前端UI"
    tasks:
      - {id: F1, name: "研究现有表单模式", agent: 探索}
      - {id: F2, name: "设计ProfileEdit组件", agent: 计划, depends_on: [F1]}
      - {id: F3, name: "实现表单组件", agent: 编辑, depends_on: [F2]}
      - {id: F4, name: "添加表单验证", agent: 编辑, depends_on: [F3]}
      - {id: F5, name: "编写组件测试", agent: 编辑, depends_on: [F4]}

  - name: "集成"
    tasks:
      - {id: I1, name: "连接前端到API", agent: 编辑, depends_on: [B3, F3]}
      - {id: I2, name: "编写E2E测试", agent: 编辑, depends_on: [I1]}
      - {id: I3, name: "运行完整测试套件", agent: Bash, depends_on: [B5, F5, I2]}

parallel_execution:
  phase1: [B1, F1]  # 研究并行
  phase2: [B2, F2]  # 设计并行
  phase3: [B3, B4, F3]  # 实现
  phase4: [F4, B5]  # 验证 + 测试
  phase5: [F5, I1]  # 更多测试 + 集成
  phase6: [I2]
  phase7: [I3]

参考

  • references/dependency-analysis.md — 识别任务依赖
  • references/parallelization-strategies.md — 最大化并行工作
  • references/agent-type-catalog.md — 代理能力参考
  • references/failure-recovery-patterns.md — 处理故障
  • references/workflow-integration.md — 生态系统集成

相关技能

  • 产品需求设计师: 用于创建功能规范
  • 验证循环: 用于验证已完成的工作
  • 部署CICD: 用于实现后的部署