用途：Arena 用于在同一任务上并行生成多个候选方案，再选出一个基线，并把落选方案中最有价值的部分手工嫁接进去，最终得到一个连贯、便于未来维护者扩展的产物。适用于 /arena、“arena this”等调用场景。
主要能力与流程：流程分六个阶段。A（Frame）：先建工作清单，每个候选拿到相同提示词，提示词即契约；明确产物形态，推导 3-6 条可评分的成功标准作为评分表，并选定运行器。B（Fan out）：用 run_in_background: true 在一条消息里并行派生全部 N 个子代理，各自有独立输出路径，产出产物与简短理由。C（Cross-judge）：候选全部完成后，选一个交叉评审角色，用只读评审子代理按评分表逐项打分并推荐基线。D（Pick）：先读完所有候选理由，再逐标准评分，选出未来维护者最易扩展、边界更清晰或 API 更小的基线。E（Graft）：从落选方案中挑少量最值得移植的部分，逐一手工折叠进基线，保持单一心智模型，避免机械粘贴。F（Verify）：像验证其他产物一样验证合成结果；若发现问题，判断是重新定框架重跑还是回到嫁接阶段。
使用方式与限制：需要为每个候选提供独立输出位置，优先使用 git worktree，否则使用新建的 mktemp 临时目录；不要复用此前运行的目录，运行结束或重跑前要清理 worktree、分支与临时目录。评分表必须放在候选可读目录之外，只交给交叉评审。若任务明确要求某个模型或分支，该要求是必须履行的义务；若无法返回结果，可保留有用输出，但须把该对比报告为不完整，并披露替换与实际运行的模型。同一模型上的多个运行只算一种意见。若候选趋同则直接采用共识形态；若严重分歧，说明框架设定不足，应重新定框架重跑而非取平均。共享状态在序列化前需先分离。
本介绍未提供具体价格、收费、支持平台或可用模型清单等信息。