mcpField
A
arena

arena

github.com/q-qp-pAgent 工作流144 次安装2 周前更新
代码仓库

关于 arena

Arena 是用于协调多个模型候选方案并综合验证成果的技能，规定了任务设定、并行产出、交叉评审、选择、整合与验证等阶段。

主要功能

  1. 01设定统一任务与评分标准
  2. 02并行运行候选方案并隔离输出
  3. 03交叉评审候选结果
  4. 04选择基础方案并综合成果
  5. 05验证综合后的产物

适用场景

  1. 01比较不同实现或设计方案
  2. 02将同一任务分配给多个模型候选
  3. 03整合候选成果并验证交付物

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/q-qp-p/pstack --skill arena

安装后在 Claude Code 中输入/arena确认已加载。

详细介绍

Arena

在启动任何操作之前，先创建一个待办列表，为每个阶段列出一个条目（Frame、Fan out、Cross-judge、Pick、Graft、Verify）。

Phase A：Frame

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

  1. 说明每个候选方案要产出的成果。
  2. 制定评分标准，列出 3-6 条具体且可评分的标准，说明在当前任务中怎样才算成功。这是 Phase D 中挑选者的工具。候选方案只能看到任务。
  3. 选择运行者。使用 pstack 设置文件中的 arena runners 行（Cursor 中为 ~/.cursor/rules/pstack-models.mdc，其他运行环境中为 ~/.agents/pstack-models.md）。如果文件或该行不存在，则默认各选一个 claude-opus-5-5-xhigh 和 grok-4.7-xhigh-fast。如果该行或交叉评审行中有 auto 或 inherit-parent 条目，表示使用父模型，因此省略 model。如果子代理工具拒绝某个已配置条目，则让该席位使用其所属系列的默认模型，并说明这一点。系列按前缀划分：claude-*，以及 grok-*（包括 cursor-grok-* 和 composer-*）。如果 composer-* 条目被拒绝，则改用 grok-4.7-xhigh-fast。如果没有匹配的系列，则使用 claude-opus-5-5-xhigh。如果默认模型也被拒绝，则根据错误信息或运行环境的模型列表，使用同一系列中最接近的有效标识。若 Arena 涵盖多个设计方向，则增加运行者数量。如果任务侧重生成而非判断，则重复使用同一模型 N 次。根据 poteto-mode 技能的 Subagents 部分，为任务选择每个子代理的推理级别以及快速或标准速度。
  4. 为每个候选方案指定各自的输出位置（尽可能使用 git worktree，否则使用 /tmp/arena-<slug>/candidate-<n>/），遵循 separate-before-serializing-shared-state 原则技能。

Phase B：Fan out

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

如果某个候选方案没有产出，则继续使用 N-1 个，并记录这一退出情况。

Phase C：Cross-judge

等 Phase B 的所有候选方案完成后，从 pstack 设置文件的 arena cross-judge pool 行中选择一个模型。如果文件或该行不存在，则从 claude-opus-5-5-xhigh 和 grok-4.7-xhigh-fast 中选择。优先选择与父模型不同系列的模型。启动一个只读评审子代理，使用该模型。它会看到评分标准和按路径标签标识的候选方案，为每项标准打分，并说明理由、推荐一个基础方案。它将在 Phase D 与你并行工作。在候选方案仍在写入时，不要启动它。

Phase D：Pick a base

挑选前，通读每个候选方案。逐项依据评分标准打分，而不是凭整体感觉，并与交叉评审结果进行比较。如果对基础方案意见一致，则确认选择。如果意见不一致，说明其中一方存在偏见，或评分标准含糊不清。做决定前，先阅读双方的理由。

选择最便于未来维护者扩展、又不会破坏不变量的基础方案。如果两个方案难分高下，则遵循 Laziness Protocol，优先选择边界更清晰或 API 更小的方案。

Phase E：Graft

再逐一检查每个落选方案，看看哪些内容值得移植到基础方案中；通常每个方案只取一两项，而不是大部分内容。根据 redesign-from-first-principles 原则技能，手动融入每项移植内容，让最终结果围绕同一套思维模型保持连贯。不要机械地复制粘贴。

如果候选方案最终趋于同一种形态，这说明意见高度一致。请记录这一点，并交付共识方案。无需移植。如果候选方案之间差异很大，说明 Phase A 的描述不够明确。应重新梳理并重新运行，而不是把这些分歧折中平均。

阶段 F：验证

按照 prove-it-works 原则技能的要求，像验证其他输出一样验证综合产物。如果验证发现了评审环节遗漏的问题，那么要么是阶段 A 出错了（重新界定问题并重新运行），要么是某个候选方案发现了问题，而你漏掉了合并的改进（返回阶段 E）。不要掩盖问题。

输出

一个综合产物，并附上一条简短的综合说明，说明所选基准及其原因、交叉评审的结论、每项合并改进及其来源候选方案、被拒绝的内容及原因、任何收敛或退出情况，以及验证结果。

评论

支持 Markdown