一句话

N 个子代理对同一份简报各出一个候选，一个只读 judge 按 rubric 打分，主代理通读后选一个基底再把落选者的优点嫁接进来。

何时用

• 适合：一次尝试就会锁死形状的非平凡产物（设计草图、算法、命名、格式）；想要第二意见。
• 不适合：覆盖矩阵或切片分工（那是 pstack-swarm）；生成量大但判断不敏感时可以同模型跑 N 个。

怎么用

/arena 把我的原话带进竞技场，我想比较各家方案和你的方案

1. Frame：写清产物和 3-6 条可打分的 rubric；rubric 只给 picker 看，候选只见任务。runner 取自 pstack-models.mdc 的 arena runners 行。
2. Fan out：一条消息后台起全部子代理，各自有独立输出位置（worktree 或 /tmp/arena-<slug>/）。
3. Cross-judge：从 arena cross-judge pool 选一个不同家族的模型做只读评分。
4. Pick：自己把每个候选读完再按 rubric 逐条打分，和 judge 对照；分歧说明有人有偏或 rubric 含糊。
5. Graft：每个落选候选一般只移植一两处，手工融合保持同一心智模型。
6. Verify：按 pstack-原则集 验证合成产物。

产出

• 一份合成产物加一段 synthesis note：基底与理由、judge 结论、每处嫁接的来源、被弃方案与原因、候选收敛或缺席情况、验证结果。

要点与坑

• 候选收敛于同一形状是强信号，直接 ship 共识形状； wildly diverge 说明 Phase A 欠定，重出题而不是取平均。
• 平手时选边界更干净、API 更小的（Laziness Protocol）。
• 依赖 Cursor Task 子代理与多模型；在 Devin CLI 可借鉴「多候选加裁判加嫁接」的流程。

关联

• 上游：pstack-architect、pstack-poteto-mode · 同类：pstack-swarm · 验证：pstack-原则集
• 所属：00-pstack-概览