集会

问题背景

多 agent 并行听起来很诱人，但工程里最常见的失败不是「跑得慢」，而是静默合并损坏、N 个队友修同一个 bug 产出 N 份冲突补丁，以及 fan-in 后输出在能编译的前提下微妙偏离原始需求。Google Research 的多 agent 顺序链研究也指出：在无可并行段时硬上多 agent，顺序推理性能可能下降 39–70%。Rally 的定位是：只在真正独立且协调开销划算时，才拉起并行执行链。

如何工作

Rally 是 Claude Code Agent Teams 与 Codex CLI Subagents 的编排负责人，典型链路包括：Sherpa 经 SHERPA_TO_RALLY_HANDOFF 移交带 parallel_group 的任务；执行完成后经 RALLY_TO_NEXUS_HANDOFF、RALLY_TO_GUARDIAN_HANDOFF 等交回聚合结果或 PR 准备物。

核心流程为 ASSESS → DESIGN → SPAWN → ASSIGN → MONITOR → SYNTHESIZE → CLEANUP，会话后还有轻量 HARMONIZE。在 DESIGN 阶段必须完成 ownership_map：每个可写文件恰好一个 owner，exclusive_write 不可重叠。执行层靠 git worktree 隔离（物理目录分离）配合所有权图（逻辑约束）。协调原语包括 TaskCreate、SendMessage 与 worktree 隔离；推荐 hub-spoke，Rally 作枢纽，3–5 人团队为默认规模。

SYNTHESIZE 阶段强调闭环验证：对照原始任务规格检查队友输出，而非仅相互对齐。配方上默认 parallel；亦支持 teams、codex-subagents、coordinate，以及跨引擎的 engine-paradigm（COMPETE / COLLABORATE）。

边界与注意

适合：2+ 个无共享可写冲突的独立单元；Sherpa 标注安全并发；跨 4+ 模块文件的并行实现；估计串行时间明显大于协调成本（经验上 ≥3 个独立单元且并行加速能补偿 Agent Teams 约 3–4× token 开销）。

应改路由：单任务、全改同一文件、纯调查、总变更 <10 行、强顺序依赖或高风险安全需紧密检查点 → Nexus、Sherpa 或单一专家。切忌未声明所有权就 spawn、10+ 队友、全员同一阻塞点，或在 SYNTHESIZE 前信任「队友共识」而不对照源需求。