| name | parallel-execution |
| description | 并行执行方法论 —— 独立任务识别、并行策略、结果合并与冲突避免 |
| category | orchestration |
| loading | on-demand |
| triggers | {"keywords":["并行","同时执行","并发","多任务","parallel"]} |
这是什么
并行执行是将可以同时进行的任务并发处理以缩短总耗时的方法论。在多 Agent 系统、大型构建流程、数据处理管道中，合理运用并行可显著提升效率。
何时使用
- 多个 Agent 需要同时执行不同的独立任务
- 数据处理管道中无依赖关系的阶段
- CI/CD 中多个测试套件可以同时运行
- 代码审查中需要从多个维度同时评估
- 构建系统中独立模块可并行编译
核心规则
- 无依赖才并行：两个任务之间存在依赖关系（B 需要 A 的输出），就不能并行。必须先完成 A 再开始 B。
- 并行上限有界：无限并行会导致资源竞争、上下文切换开销碾压收益。并行数不超过可用资源数。
- 独立上下文：并行任务各自拥有独立的工作空间、数据副本。共享状态必须通过显式同步机制。
- 失败隔离：一个并行任务的失败不应该导致其他任务中断。收集所有结果后统一判断。
- 结果幂等合并：合并逻辑应该能够处理部分成功和全部成功的不同情况。重新执行合并不应产生不同结果。
工作流程
-
任务分解
- 列出所有待完成的任务
- 绘制任务依赖图：节点是任务，边是依赖关系（A → B 表示 B 依赖 A）
- 识别完全独立的任务组（图中没有边连接的节点）
- 将独立任务标记为可并行执行
-
资源评估
- 评估可用资源数量：CPU 核心数、内存、API 并发限制、Agent 实例数
- 评估每个任务所需资源
- 计算最大并行数 = min（独立任务数，可用资源数 / 单任务资源）
- 设置安全余量：实际并行数 = 最大并行数 × 0.8
-
并行调度
- 启动第一批并行任务，数量不超过上限
- 使用任务队列，完成一个即启动下一个
- 对于有依赖的任务，在所有前置任务完成后自动触发
- 监控每个任务的进度和状态
-
结果收集
- 为每个任务定义结果格式（统一接口）
- 收集所有任务的结果（成功或失败）
- 对结果进行分类：成功、部分成功、失败、超时
- 记录失败原因和上下文
-
结果合并
- 定义合并策略：拼接、聚合、投票、取最优
- 处理冲突：当多个结果相互矛盾时的裁决规则
- 生成统一报告：汇总所有任务的输出
- 验证合并结果的完整性和一致性
常见并行模式
扇出-扇入
所有并行任务独立执行，最后汇总。适用于批量处理独立数据。
- 扇出：将任务分发到多个 worker
- 扇入：收集所有 worker 的结果
- 适用场景：批量代码审查、多维度分析、批量数据转换
竞速执行
同一任务由多个执行者同时处理，取最快返回的正确结果。
- 适用于有多个候选方案且不确定哪个最快
- 需要定义「正确结果」的验证标准
- 成本是单次的 N 倍，仅在速度优先于成本时使用
流水线并行
每个阶段处理不同任务，像工厂流水线。
- 阶段间通过缓冲区连接
- 瓶颈在速度最慢的阶段
- 适用场景：代码分析 → 修复 → 审查 → 测试
冲突避免策略
- 资源分区：每个并行任务分配互不重叠的资源范围
- 写时复制：共享数据默认只读，需要修改时创建私有副本
- 文件锁：必须写入同一文件时使用文件锁协调
- 版本向量：分布式场景下用版本向量检测和解决冲突
- 最终合并者：指定单一实体负责合并，避免多源写入冲突
并行度决策矩阵
| 场景 | 并行度 | 理由 |
|---|
| 独立 API 调用 | 高（5-10） | I/O 等待时间长，上下文开销小 |
| CPU 密集型计算 | 中（CPU 核心数） | 超过核心数无益 |
| 文件读写 | 低（2-4） | 磁盘 I/O 是瓶颈 |
| Agent 推理 | 低（3-5） | 每个 Agent 消耗大量上下文 |
参考标准
- Amdahl 定律：加速比受限于不可并行部分
- Gustafson 定律：问题规模增大时并行效率提升
- MapReduce 编程模型 —— 大规模数据并行处理范式
- Celery/Temporal 等任务调度系统的并发配置
- CSP（通信顺序进程）和 Actor 模型的并发理念
