多 Agent 并行：什么时候真能提速，什么时候只是添乱

并行是这两年 agent 产品的主打能力，Claude Code 单次运行并发上限提到了 256，默认能跑 20 个并发子 agent；MiMo Desktop 走多会话协同路线。但并行不是银弹，用错场景反而更慢。 先说适合并行的场景，判断标准是任务之间没有依赖。 一，批量同质任务。给二十个文件各写一批测试，彼此独立，并行收益接近线性。 二，多方案探索。同时让几个 agent 用不同思路解决同一个问题，最后挑最好的。这是"用算力换质量"。 三，读多写少的调研。多个 agent 分头查资料、读不同模块，最后汇总。 四，构建校验类的扇出。编译、测试、静态检查各自独立跑。 不适合并行的场景： 一，有严格顺序依赖的任务。拆开并行只会产生大量冲突。 二，写同一个文件的任务。并行改同一处代码，后写的覆盖先写的，这是最常见的故障。 三，需要全局一致判断的活。比如整体架构调整，视角要统一。 四，下游有瓶颈的活。如果数据库连接池或者外部 API 有限流，开更多 agent 只会推高失败率。 工程上的防护措施，三条最实用： 一，文件写入边界。每个 agent 只负责自己的文件范围，用 git worktree 给每条并行线一个独立工作目录，合并时人工过一遍。 二，幂等设计。同一个任务重复执行不应该产生副作用，这能大幅降低重试的复杂度。 三，成本上限。并行会成倍放大 token 消耗，跑之前估算一下，设个上限。 我的实际用法是：串行做设计和决策，并行做执行和验证。设计阶段需要连贯的上下文，不适合拆；执行阶段任务边界清楚，拆开收益明显。