arena

Arena

启动任何操作之前，先打开一份工作清单，为每个阶段各列一项（Frame、Fan out、Cross-judge、Pick、Graft、Verify）。

Phase A：Frame

每个候选项都会收到相同的提示词，因此提示词就是契约。

1. 说明每个候选项要产出的成果。
2. 推导评分标准，列出 3-6 项具体且可评分的标准，说明在此任务中什么样的成果才算成功。对于主观标准，请使用 Eval 的标准与校准指南。这是 Phase D 中挑选者使用的工具。候选项只能看到任务。
3. 选定运行器。使用 arena runners 角色，每个条目对应一个分支。默认情况下，分别在 fable、opus、sonnet 上运行一个。被拒绝的条目也必须遵守下方的必需分支规则。当竞技场涵盖多个设计方向时，应启动更多运行器。如果工作侧重生成而非判断，则使用同一模型运行 N 次。使用 pstack-harness 技能启动。该技能的 Spawn a role 部分会解析角色并构建此 CLI 的启动调用。
4. 为每个候选项分配独立的输出位置（尽可能使用 git 工作树，否则就在本次运行新建的 mktemp -d "${TMPDIR:-/tmp}/arena-<slug>.XXXXXX" 目录中使用 candidate-<n>/），遵循 separate-before-serializing-shared-state 原则技能。绝不复用之前运行的目录。只有在原生隔离选项会创建 git 工作树，且运行 git -C <its path> rev-parse --path-format=absolute --git-common-dir 时输出项目的路径，才算符合要求。Grok Build 的 isolation: worktree 可能会创建独立克隆，因此应在该处使用 isolation: none 启动。如果省略此字段，Grok 角色或 persona 的默认设置仍可能启用隔离。对于其他候选项，应自行逐一创建工作树，使用 git worktree add --detach <run dir>/candidate-<n>，其中 <run dir> 是新建的 mktemp -d 目录，并在候选项的任务说明中注明路径。如果添加失败，则移除已创建的工作树，并在该目录中为所有候选项改用普通目录，确保所有候选项以相同方式开始。pstack-harness 技能中的后备方案说明了如何初始化普通目录并编写任务说明。运行结束后，应在保存其输出（按照 Outputs 的要求）之后、重新制定任务框架并再次运行之前清理本次运行；无论是 Phase E 还是 Phase F 让你返回，都要如此。清理时，使用 git worktree remove --force <path> 移除每个候选项的工作树，使用 git branch -D 删除为其创建的任何分支，并删除临时目录。返回 Phase E 进行 graft 时保留这些目录。将评分标准放在所有候选项都无法读取的目录之外，并在提示词中提供给交叉评审者。

Phase B：Fan out

在一条消息中启动全部 N 个子 Agent，并设置 run_in_background: true。每个子 Agent 都应收到任务、共享依据的路径、自身的输出路径，以及产出成果并简要说明其考虑过哪些替代方案及拒绝理由的指示。

必需分支

为此任务指定的分支或确切模型始终是必须满足的要求。如果无法返回结果，应保留有用的输出，但报告所要求的比较未完成。说明替换情况以及实际运行的模型。替代项不能满足对确切模型的要求。配置的默认值和角色别名仍按常规通过 harness 解析。默认或可酌情选择的候选项可以退出，但须记录其限制。

Phase C：Cross-judge

在 Phase B 的所有候选项完成后，从 arena cross-judge pool 角色中选择一个分支。使用 pstack-harness 技能的 Spawn a role 部分解析该角色。其默认池为 fable、opus、sonnet。优先选择与父级不同的模型系列或能力层级。在该模型上启动一个只读评审子 Agent。它会看到评分标准和按路径标签列出的候选项，为每项标准打分，并给出有理由的基础方案建议。它会与你在 Phase D 中的阅读并行运行。候选项仍在编写时，不要启动它。

阶段 D：选择基础方案

选择之前，通读每个候选方案的理由。只有当某个候选方案被选为基础方案，或你与交叉评审者对某项标准意见不一致时，才通读该候选方案的完整产物。交叉评审者会通读每份产物。

根据候选方案的理由以及交叉评审者针对该项标准提供的证据，逐项按照评分标准评估每个候选方案，不要凭整体印象打分。如果这些信息不足以判定某项标准，就阅读产物中的相关部分。与交叉评审者进行比较。双方同意选择某个基础方案，即可确认该选择。在称任何共识或趋同为已确认之前，先说清你、各运行者和交叉评审者使用的模型，因为使用同一模型的多个分支只算一种意见。意见不一致意味着其中一方存在偏见，或评分标准含糊不清。做决定前，先阅读双方的理由。

选择未来维护者最容易扩展且不会破坏不变量的基础方案。如果两个方案难分高下，就按照惰性协议，优先选择边界更清晰或 API 更小的方案。

阶段 E：移植

再次检查每个落选候选方案的理由和交叉评审者的评分，找出值得移植到基础方案中的内容。通常每个候选方案移植一两点，而不是大部分内容。只阅读你要移植的落选产物中的相关部分。按照从第一性原理重新设计原则技能，手动整合每项移植内容，确保结果在同一套思维模型下保持连贯。不要机械地复制粘贴。

如果候选方案趋同于同一种形态，在遵守阶段 D 对实际模型的披露要求及单模型限制的前提下，记录这一趋同，并交付该共识方案。无需移植内容。如果候选方案大相径庭，说明阶段 A 的要求不够明确。重新梳理要求并重新运行，而不是将这些差异折中平均。重新运行前，移除本轮候选方案的工作树及其分支，并删除本轮的临时目录。

阶段 F：验证

按照验证其有效性原则技能，像验证其他产物一样验证合成产物。如果验证发现了评审流程遗漏的问题，要么是阶段 A 有误（重新梳理要求并重新运行），要么是某个候选方案发现了问题而你漏掉了对应移植内容（返回阶段 E）。不要掩盖问题。重新梳理要求并重新运行前，移除本轮候选方案的工作树及其分支，并删除本轮的临时目录。返回阶段 E 时则保留这些内容。验证通过后，保存产物，然后以同样的方式清理。

输出

一份合成产物，保存到调用任务指定的位置。调用任务要交付的代码应放到当前工作的分支上。等待调用方签字确认的草案还不属于任务要交付的代码，因此在签字确认前应保留在项目之外。对于其他未指定存放位置的产物，应在项目之外使用新建的 mktemp -d 目录保存。在回复中简短说明合成情况，不要将说明写入文件；说明基础方案及其选择理由、交叉评审者的结论、每项移植内容及其来源候选方案、拒绝的内容及原因、任何趋同或退出情况，以及验证结果。