需要并行覆盖、竞速或混合探索时，用 Swarm 扇出 N…

把任务拆成并行切片或同题竞速，启动多个云端子代理，等待收敛后输出统一报告。

适用场景

解决思路

1. 启动前先打开一个 todolist，每个阶段一条：Frame、Fan out、Aggregate、Report。
2. Phase A Frame：明确 done predicate，以及 swarm 必须返回的 artifact 或 report。
3. 选择形态：把任务分片成 slices、让 N 个 worker 对相同 brief 竞速（race），或混合两者；若是 race 或混合，必须在 spawn 前声明选择规则：`first pass`、`rank all` 或 `best-of`。
4. 设定 N：由用户指定或根据形态推导；N 是 worker 总数，不是云端并发上限。
5. 选择 worker 模型：若存在 `~/.cursor/rules/pstack-models.mdc`，从其中的 `swarm workers` 选择；否则用 `grok-4.7-xhigh-fast`；若做模型竞速，提前为每个 arm 命名其模型。
6. 如果 worker 会写入，给每个 worker 自己的可写输出位置。
7. 如果 worker 要验证或测量 commits，每个 brief 写明确切的 SHAs；测量 brief 还要写明方法（样本数、一个样本是什么、顺序）。worker 在结果中记录二者。
8. Phase B Fan out：在一条消息中 spawn 全部 N 个 worker，使用 `subagent_type: generalPurpose`、`environment: "cloud"`、`run_in_background: true` 和已配置模型。
9. 仅当 worker 需要访问用户电脑上的东西时，才用 `environment: "local"`。
10. 当 worker 必须从非默认的已推送分支开始时，传入 `cloud_base_branch`。
11. 每个 brief 必须独立自足，包含目标、范围、确切 slice 或 race arm、如何验证、要报告什么。
12. 报告使用 `PASS`、`ISSUES` 或 `BLOCKED`，并附证据。
13. 能证明缺陷的 worker 报告 `ISSUES`，并列出它能证明的所有 issue，而不只是第一个。
14. 如果某个 worker 掉线，继续用 N-1 并在结果中注明。
15. Phase C Aggregate：读取终态结果。
16. 丢弃未记录其 brief 指定 SHAs 和 method 的结果，并重跑该 worker 一次。
17. 第二次仍未满足时，记录 gap；gap 不算 pass。
18. 对 coverage，每个必需 slice 都需要结果。
19. 对 race，应用 spawn 前声明的选择规则：`first pass`、`rank all` 或 `best-of`。
20. 不要粘贴原始 worker dump。
21. 保留紧凑结果表、一行一条有证据的 issue、明确 gaps 或 dropouts。
22. Phase D Report：返回一份合并的 in-chat report，包含结果表、issue 一行摘要、gaps/dropouts，以及使用 race 时的 race 规则。

适用边界 · 注意事项

• 任务无法拆成独立 slice 或竞速 arms，且并行不会提升覆盖或速度时。
• 没有可用的云端 worker/subagent 运行环境或相应模型配置时（依赖特定工具）。
• 需要访问用户本地电脑资源但又不允许使用 `environment: "local"`，或多个 worker 会写入同一输出导致冲突时。