多轮流程
Round 1 处理原始 issue；Round 2-5 由 simulated user 根据前序 trajectory、patch、测试输出和 behavior 类型继续追问、纠错、要求验证或做维护性审查。
评测系统说明
传统评分
保留 deterministic verifier 与 LLM-as-judge：前者判断代码是否通过测试，后者判断上下文保持、纠错、测试质量和用户负担。
Elo 评分
把每一轮看作一次 pairwise match。默认初始分 1000，K=32，胜/平/负分别为 1/0.5/0。
Leaderboard 与 Elo 计算方式
这里展示所有 task 的总分平均；任务数量由当前 demo 数据动态决定。
测试 + LLM-as-judgeUX reward 是 Claude 对完整多轮交互的整体评分：输入包含每轮用户请求、trajectory 摘要、patch/test evidence、异常信号、artifact 路径，以及 Round1 verifier 和 Final verifier。Round1 verifier 作为原始任务是否完成的功能证据，Final verifier 作为最终累计 patch 是否回归的证据；二者会影响 Claude 的判断，但不是固定加权公式。
Claude 模拟用户 Elo每个 task 的每一轮都是一次 pairwise match；claude-opus-4-6 在 A is better / B is better / Tied 三种结果中选择。总榜显示各 task 最终 Elo 的平均值。
真人投票 Elo公网投票写入 Cloudflare D1，并按 evaluation_id + task_id 隔离。总榜显示各 task 真人 Elo 的平均值；你的本地投票 Elo 也合并显示在同一栏内。
- 初始化：每个 task 内每个模型从 1000 分开始，K=32。
- 组成比赛：同一轮用户请求下，左侧模型作为 A，右侧模型作为 B。
- 计算期望胜率：如果 A 分数高于 B，A 的期望胜率更高；反之 B 更高。
- 录入结果：A is better 记 A=1/B=0，B is better 记 A=0/B=1，Tied 记双方 0.5。
- 更新分数：实际结果高于期望的一方加分，低于期望的一方扣分；所有轮次或所有真人投票按发生顺序重放。
- 跨题汇总：每个 task 单独计算分数和 Elo，然后对同一模型在所有 task 的结果取平均，避免某个 task 的投票数量或轮次显示方式污染其他 task。
E_A = 1 / (1 + 10^((R_B - R_A) / 400)) R_A' = R_A + K * (S_A - E_A), K = 32
测试 + LLM-as-judge 分数（跨任务平均）
Claude 模拟用户 Elo（跨任务平均）
真人投票 Elo（全站 + 本地）
正在读取投票数据...
你的本地投票 Elo
完成每轮投票后在本浏览器计算。
关键参数与 simulated user 机制
seed：用于固定 follow-up 行为序列；本 demo 使用 42，同一 task 下两个模型会遇到同类型、同轮次的用户追问。
profile：用于定义 simulated user 的用户画像；预设包含 balanced-maintainer-bugfix（平衡型维护者，关注证据、最小修复和测试）、expert-maintainer-bugfix（专家维护者，关注边界情况、回归风险和根因证据）、security-reviewer-refactor（安全/维护性审查者，关注不安全行为、隐藏耦合和回滚风险）。
behavior：用于定义每一轮追问的目标；预设包含 debug-followup（怀疑仍有失败模式）、add-tests（要求补充测试或验证）、correct-requirement（纠正或细化需求）、failure-report（报告实际失败现象）、rejection-rollback（拒绝上一轮方案或回滚部分改动）、repo-understanding（要求解释模块/数据流/风险点）、git-operation（要求总结 diff 或保持仓库卫生）、security-maintainability-review（要求安全与可维护性审查）、final-cleanup（要求最终确认、清理和总结）。
当前 demo 的 simulated user 方案：当前 9 个 task 的 anchor_followups 都是空数组，因此没有使用人工脚本化追问；Round 2-5 均由 claude-opus-4-6 根据当前 behavior、原始题目、前序用户请求、trajectory 摘要、工具/命令摘要、patch excerpt、测试输出摘要、verifier 结果和异常信号动态生成，并要求追问语言跟随初始题目。
anchor_followups 与追问生成：若某个 round_id 配置了 anchor follow-up，Harbor 会直接使用人工写好的 instruction、intent 和 expected_agent_behavior，例如在 Round 3 固定追问“我回滚了你加入的测试文件，只保留游戏本体；请确认最终交付不包含测试 HTML”，这样可以保证关键场景在不同模型间完全一致。若没有 anchor，Harbor 会构造 structured context，再让 simulated user 生成下一条与初始题目语种一致的用户消息。
原始题目 loading...
测试 + LLM-as-judge 分数
Round1 verifier恢复 round 1 patch 后运行原始 task verifier，衡量第一轮是否解决原始问题。
Final verifier恢复最终 cumulative patch 后运行同一个原始 verifier，用来检查多轮交互后是否引入回归。
UX reward不是只看最后一轮。Claude UX judge 读取完整多轮 context：每轮 user instruction、trajectory summary、patch/test evidence、round1/final verifier rewards、exception signal 和 artifact paths。
分项分数Task success、Final requirement、Correction、Testing 分别衡量任务成功、最新需求遵循、纠错能力和测试验证质量。
组合方式：这组分数把测试规则和 LLM-as-judge 放在同一张表中解释：Round1 verifier 是第一轮功能通过信号，Final verifier 是最终累计代码的回归信号，UX reward 是 Claude 对完整多轮体验的主评价。Claude 会综合所有轮次的用户请求、模型行为、patch、测试证据和异常信号，并把 Round1/Final verifier 当作重要证据；这里没有额外手写的固定权重公式。
真人用户投票 / Round-by-round Pairwise Review
A/B 设置：每轮投票卡片中，左侧模型是 A，右侧模型是 B。投票选项固定为 A is better、B is better、Tied；切换左侧 task 后，A/B 会跟随当前 task 的两个模型。
轨迹可视化：参考 OpenHands trajectory visualizer 的“运行列表 + 轨迹 timeline + artifact/diff 展开”思路，页面把每轮 agent 证据拆成行为摘要、工具/命令、最终回复和 patch artifact，而不是只展示一大段日志。
Patch 展示：Harbor 保存的是每轮截至当时的累计 patch snapshot。页面会标注本轮是否真的产生新代码改动；若与上一轮相同，会显示“本轮无新代码 patch”。如果累计 patch 发生变化，会展示更新后的完整 patch snapshot，并说明它是累计快照 fallback。