多智能体协作时如何拆解任务、设计依赖图并平衡负载

把复杂任务拆成可并行单元、设计依赖关系、写清任务描述并监控团队工作量的可复用方法。

适用场景

解决思路

1. 按架构层拆解任务：前端组件、后端 API 端点、数据库迁移/模型、测试套件；适合全栈功能与纵向切片。
2. 按功能组件拆解任务：认证模块、用户资料模块、通知模块；适合微服务与模块化架构。
3. 按关注点拆解任务：安全审查、性能审查、架构审查；适合代码审查与审计。
4. 按文件归属拆解任务：如 src/components/ 给 Implementer 1、src/api/ 给 Implementer 2、src/utils/ 给 Implementer 3；适合并行实现与避免冲突。
5. 依赖图设计原则：尽量减少链深度，优先宽而浅的图而非深链。
6. 依赖图设计原则：识别关键路径，最长链决定最短完成时间。
7. 依赖图设计原则：谨慎使用 blockedBy，只添加真正必需的依赖。
8. 依赖图设计原则：避免循环依赖，A 阻塞 B、B 阻塞 A 会造成死锁。
9. 使用独立模式（最佳并行）：Task A、B、C 各自独立，最后汇聚到 Integration。
10. 使用顺序模式（必要依赖）：Task A → Task B → Task C。
11. 使用菱形模式（混合）：Task A 分出 Task B 和 Task C，二者再汇聚到 Task D。
12. 用 blockedBy/blocks 表达依赖：先 TaskCreate 创建任务（如 #1 Build API endpoints、#2 Build frontend components、#3 Integration testing），再用 TaskUpdate: { taskId: "3", addBlockedBy: ["1", "2"] } 让 #3 等待 #1 和 #2。
13. 任务描述必须包含 Objective：用 1-2 句话说明要完成什么。
14. 任务描述必须包含 Owned Files：明确列出该成员可修改的文件/目录。
15. 任务描述必须包含 Requirements：具体交付物或期望行为。
16. 任务描述必须包含 Interface Contracts：说明本工作如何与其他成员的工作衔接。
17. 任务描述必须包含 Acceptance Criteria：如何验证任务已正确完成。
18. 任务描述必须包含 Scope Boundaries：明确哪些内容不在范围内。
19. 使用任务描述模板：Objective、Owned Files（含 shared — read only, do not modify 标注）、Requirements、Interface Contract、Acceptance Criteria、Out of Scope 各段落。
20. 监控负载失衡信号：某成员空闲而其他人忙碌 → 分配不均 → 重新分配待处理任务。
21. 监控负载失衡信号：某成员卡在单个任务上 → 可能有阻塞 → 主动询问并提供帮助。
22. 监控负载失衡信号：所有任务都被阻塞 → 依赖问题 → 优先解决关键路径。
23. 监控负载失衡信号：某成员任务量是他人 3 倍 → 过载 → 拆分任务或重新分配。
24. 再平衡步骤：调用 TaskList 评估当前状态。
25. 再平衡步骤：识别空闲或过载的成员。
26. 再平衡步骤：用 TaskUpdate 重新分配任务。
27. 再平衡步骤：用 SendMessage 通知受影响的成员。
28. 再平衡步骤：持续监控吞吐量是否改善。