模型: openai/gpt-5.4
生成日期: 2026-04-01
书名: Claude Code VS OpenCode：架构、设计与未来
章节: 第21章 — 多智能体编排的艺术
Token用量: 约 6,500 input + 2,120 output

21.5 并行执行的挑战

并行执行是多智能体最容易让人兴奋的一面。它看起来意味着更快、更广、更强的覆盖能力。但一旦真正落地，问题就不再只是“多开几个 agent”，而是会迅速变成一组系统工程难题：并发控制、任务切分、结果聚合、冲突解决、通知机制、可观测性。单智能体主循环主要担心推理质量；并行智能体运行时则必须像一个 scheduler（调度器）一样工作。

OMO 把这件事暴露得很清楚。它的 background agent spawner（后台智能体生成器）不是简单便利功能，而是一种架构承认：只要多个 agent 同时跑，系统就开始进入基础设施问题域。其中一个非常关键的设计，就是按模型/提供商维度，大约限制为每组最多 5 个并发任务。这个数字的意义不在于“五”本身有神秘性，而在于系统必须显式限流。否则，一个用户请求就可能在内部裂变成失控的并行风暴，既烧钱，又可能撞上 provider 的吞吐边界。

并发上限只是第一层。第二层更难，是任务切分。并行只有在子任务足够独立时才真的有收益。如果两个搜索 agent 实际在翻同一批文件，那就是重复劳动；如果两个深执行 agent 分别修改同一子系统，那父 agent 之后要面对的就不是“融合成果”，而是“处理冲突补丁”。因此，真正好的并行编排必须有 partitioning（分区切分）思维：按文件区域切、按假设切、按信息源切、按抽象层切。没有合理分区，并行只会放大噪音。

第三层问题是结果聚合。这看似简单，实则是并行系统最容易翻车的地方。子智能体返回的结果通常不会天然对齐：一个给原始证据，一个给摘要，一个给建议，一个给反驳。父 agent 如果只是把它们按顺序拼起来，那不叫整合，只叫堆叠文本。真正的 aggregation（聚合）需要策略：哪些结果是事实性证据，哪些只是建议；哪些可以折叠去重，哪些要保留差异；哪些结论需要附带置信度，哪些可以直接进入最终答案。没有聚合策略，多智能体输出只会让用户更难读。

比聚合更难的是冲突解决。比如一个 agent 说问题源于配置漂移，另一个 agent 说是 API 不匹配；或者两个实现 agent 分别提出互不兼容的改动方案。系统不能把这两份答案都粘过去就算完成，它必须决定如何裁决。常见方法有四类。

第一，优先级裁决。某些角色天然优先，比如 verifier（验证者）可以压过 implementer（实现者）。

第二，证据裁决。带具体文件路径、栈追踪、引用出处的结果，优先于模糊推断。

第三，再开一轮调解。引入一个专门的 synthesizer（综合者）或 reconciliation pass（调和轮）来比较冲突输出。

第四，上升给用户。当系统无法可靠裁决时，明确呈现冲突，而不是伪装成一致结论。

并行还会带来 时间不对称 问题。最快返回的 agent，不一定最有价值。一个快速搜索结果可能先回来，但真正有洞察的深分析还在跑。如果父 orchestrator 过早收敛，就会被“先到的信息”绑架。因此，并行系统需要 stopping rules（停止规则）：是等全部完成，还是等达到法定人数，还是在置信度足够时提前返回？不同选择对应不同代价。全等最稳，但慢；过早返回快，但可能错失关键证据。

通知机制的重要性，也经常被低估。后台子智能体如果没有结构化通知，父会话和用户都很容易失去状态感：哪个任务开始了，哪个任务结束了，哪个失败了，哪个结果还未整合，是否需要继续追问。OMO 的父会话通知机制之所以关键，就在于它把“异步工作”变成了可见事件流，而不是隐藏在系统内部的黑盒过程。没有通知，并行只是静默后台；有了通知，它才成为可管理编排。

还有一个很典型的并发调试问题，叫做 causal ambiguity（因果歧义）。串行系统里，错误通常比较容易定位到某一步；并行系统里，错误可能来自子任务 prompt、调度器、聚合器、综合器中的任意一环。到底是某个子 agent 搜错了，还是父 agent 误合并了？是分区策略有问题，还是冲突裁决规则不合理？这就是为什么并行智能体系统必须重视 observability（可观测性）：每个任务的 ID、开始结束时间、角色、输入范围、输出来源、合并路径，都应该能追踪。

Claude Code 更产品化的 task 体系，在一定程度上就是对这些复杂性的控制：通过更强的隔离和更少暴露的调度自由度，降低用户直接面对的编排复杂度。OMO 则是把更多能力显式暴露出来，因此也承担了更多调度层难题。OpenCode 则继续扮演中性宿主：它能承载并发，但不会天然替你解决这些 scheduler 级问题。

一个常见误解是：并行一定会更快。其实不一定。搜索阶段也许更快，但当结果整合、冲突解决、重试和通知成本都算进去后，端到端 latency（总延迟）未必下降。并行真正有效的前提是：子任务足够独立，合并契约足够清晰，冲突足够少，结构化输出足够好。否则，系统只是把时间从“执行”转移到了“整合”。

因此，至少有三条设计规则很重要。

第一，优先并行化搜索与证据收集，谨慎并行化修改与执行。多个只读分支更容易安全合并，多个写分支更容易互相踩踏。

第二，让分支输出尽量结构化，例如文件路径、证据点、置信度、推荐下一步，而不是一大段随意 prose。结构化产物更适合聚合。

第三，把通知和溯源当成产品层需求，而不是底层实现细节。用户需要知道系统为什么还在等、等的是谁、最终答案是如何拼出来的。

所以，并行执行真正难的地方，从来不是“同时跑五个 agent”，而是如何在资源限制、任务切分、结果合并、冲突裁决、通知反馈、追踪诊断之间建立纪律。OMO 的“每模型/提供商约 5 并发上限”、结果回收与通知机制，给出了一种可信答案；Claude Code 则给出另一种更收敛的答案。共同结论只有一个：并行不是炫技，而是控制问题。

未来的编码智能体几乎一定会越来越并行，但真正赢的系统，不是跑得最热闹的系统，而是最能把并行约束成可靠编排的系统。