parallel-execution

name	parallel-execution
description	并行执行方法论 —— 独立任务识别、并行策略、结果合并与冲突避免
category	orchestration
loading	on-demand
triggers	{"keywords":["并行","同时执行","并发","多任务","parallel"]}

这是什么

并行执行是将可以同时进行的任务并发处理以缩短总耗时的方法论。在多 Agent 系统、大型构建流程、数据处理管道中，合理运用并行可显著提升效率。

何时使用

• 多个 Agent 需要同时执行不同的独立任务
• 数据处理管道中无依赖关系的阶段
• CI/CD 中多个测试套件可以同时运行
• 代码审查中需要从多个维度同时评估
• 构建系统中独立模块可并行编译

核心规则

1. 无依赖才并行：两个任务之间存在依赖关系（B 需要 A 的输出），就不能并行。必须先完成 A 再开始 B。
2. 并行上限有界：无限并行会导致资源竞争、上下文切换开销碾压收益。并行数不超过可用资源数。
3. 独立上下文：并行任务各自拥有独立的工作空间、数据副本。共享状态必须通过显式同步机制。
4. 失败隔离：一个并行任务的失败不应该导致其他任务中断。收集所有结果后统一判断。
5. 结果幂等合并：合并逻辑应该能够处理部分成功和全部成功的不同情况。重新执行合并不应产生不同结果。

工作流程

1. 任务分解

   • 列出所有待完成的任务
   • 绘制任务依赖图：节点是任务，边是依赖关系（A → B 表示 B 依赖 A）
   • 识别完全独立的任务组（图中没有边连接的节点）
   • 将独立任务标记为可并行执行

2. 资源评估

   • 评估可用资源数量：CPU 核心数、内存、API 并发限制、Agent 实例数
   • 评估每个任务所需资源
   • 计算最大并行数 = min（独立任务数，可用资源数 / 单任务资源）
   • 设置安全余量：实际并行数 = 最大并行数 × 0.8

3. 并行调度

   • 启动第一批并行任务，数量不超过上限
   • 使用任务队列，完成一个即启动下一个
   • 对于有依赖的任务，在所有前置任务完成后自动触发
   • 监控每个任务的进度和状态

4. 结果收集

   • 为每个任务定义结果格式（统一接口）
   • 收集所有任务的结果（成功或失败）
   • 对结果进行分类：成功、部分成功、失败、超时
   • 记录失败原因和上下文

5. 结果合并

   • 定义合并策略：拼接、聚合、投票、取最优
   • 处理冲突：当多个结果相互矛盾时的裁决规则
   • 生成统一报告：汇总所有任务的输出
   • 验证合并结果的完整性和一致性

常见并行模式

扇出-扇入

所有并行任务独立执行，最后汇总。适用于批量处理独立数据。

• 扇出：将任务分发到多个 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 模型的并发理念