智能体处理多步骤任务时，经常面临一个选择：步骤是按顺序一个接一个做，还是同时铺开一起做。并行看起来更快，串行看起来更稳，但这两种直觉都可能误导人。真正决定选型的不是速度偏好，而是步骤之间的依赖关系。把依赖关系画清楚，选型往往自然浮现。

串行适用于存在依赖的步骤。后一步需要前一步的结果才能开始，或者前一步的输出会改变后一步的前提条件，这时强行并行只会得到错误或无意义的结果。涉及顺序副作用的步骤也应当串行：比如先校验再写入、先备份再覆盖，顺序本身就是正确性的一部分。串行还有一个好处是问题定位清晰，某一步失败，前面步骤的结果都已确定，排查范围小。

并行适用于彼此独立的步骤。各步骤不共享可变状态、不互相等待结果、最终结果可以按规则合并，这时并行能有效缩短整体耗时。典型情形是多路信息收集、多份材料的独立处理、多个互不影响的校验。但并行不是免费的：并发步骤如果读写同一份状态，容易互相覆盖；多个并行结果需要合并时，合并规则必须事先定好，否则合并环节会成为新的错误来源；某一路失败时，是整体放弃还是保留其他路的结果，也要提前约定。

更常见的是混合结构：先并行收集彼此独立的信息，再串行进入依赖后续判断的环节，最后又并行执行互不影响的收尾动作。混合结构的关键是分阶段：每一阶段内部的步骤关系要一致，阶段之间设置明确的检查点。检查点的作用是确认本阶段的成果是否完整、是否满足进入下一阶段的条件，避免带着残缺结果往下走。

选型时还可以问自己几个问题：步骤之间有没有数据依赖，有没有共享写操作，失败时能否单独重试某一路，合并结果的规则是否唯一且可验证。如果其中任何一项答案不确定，宁可先选串行，等依赖关系摸清楚后再考虑并行化。并行带来的提速只有在正确性有保障时才有意义，为了快而牺牲可排查性和可恢复性，是任务流设计里常见的赔本买卖。

另外，并行度也不是越高越好：并发路数增加后，资源争用、结果合并与失败排查的成本都会上升，实际收益会递减。先小规模验证并行效果，再逐步放开路数，是更稳妥的推进节奏。