多轮流程
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/Final verifier 都运行当前 glm_ccbench_0612_v2 每题原始 verifier 的全部规则化检查，并导出单一
reward；不是 SWE-bench 的 F2P/P2P 拆分，也没有单独的 all 子项。Round1 verifier 例如 0.54，表示该模型在所有 task 第一轮交付上的 verifier reward 平均值为 0.54；Final verifier 是最终累计 patch 再跑同一 verifier 的平均值。二者会影响 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 机制
如何配置才能保证公平一致性：同一题目对比不同模型时，需要固定 task、max_rounds、behaviors 列表、seed、profile、context_policy、simulated user 的 model/api_base/temperature/max_context_chars，并开启 shared_followups=true 且使用同一个 shared_followup_cache_path。在这组参数一致时，Harbor 生成 follow-up 的 cache key 不包含被测模型输出，后续用户问题可以在不同模型之间复用，从而保证“同题同用户追问”。
哪些参数变化会影响一致性：改变 seed 会改变 behavior 排序；改变 profile 会改变 simulated user 画像和追问风格；改变 behaviors 会改变每轮追问目标；改变 context_policy/max_context_chars 会改变 simulator 看到的上下文；改变 model/api_base/temperature 会改变 simulated user 的生成分布；关闭 shared_followups 或不共享 cache 会让追问依赖各模型自己的 trajectory。上述变动都不能与原配置做严格同配置公平比较。
参数含义：seed 固定 Harbor 选择 follow-up behavior 的确定性顺序；profile 定义 simulated user 的用户画像；behaviors 定义每轮追问类型，例如 debug、补测试、需求纠正、失败反馈、安全维护审查和最终清理；anchor_followups 是人工脚本化追问，配置后可直接固定某轮用户问题；shared_followups 控制是否使用模型无关的共享追问缓存；context_policy 控制传给 simulated user 的 trajectory、patch 和测试输出摘要范围。
一致性的边界：这些参数可以保证用户问题和评测流程尽量一致，但不能保证被测 agent、LLM judge、外部 API 或 sandbox 运行完全确定。因此同配置重复测评仍可能有分数波动；需要重复实验时，应固定上述参数并复用同一 shared follow-up cache。
原始题目 loading...
测试 + LLM-as-judge 分数
Round1 verifier恢复 round 1 patch 后运行原始 task verifier，衡量第一轮是否解决原始问题。当前数据集不是 F2P/P2P 拆分，而是运行该 task 的全部规则化检查并读取单一
reward。Final verifier恢复最终 cumulative patch 后运行同一个原始 verifier，用来检查多轮交互后是否引入回归；同样读取单一
reward 字段。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 是第一轮功能通过信号，例如跨任务平均 0.54 表示该模型在所有 task 的第一轮 patch 上，原始 deterministic verifier 的 reward 平均值为 0.54；Final verifier 是最终累计代码的回归信号，表示 Round 5 累计 patch 再跑同一 verifier 的 reward 平均值。当前 glm_ccbench_0612_v2 verifier 会运行每题 testcase_spec.json / tests/test.sh 中的全部 smoke check、输出文件检查、静态需求信号检查、语义/运行时检查，结果汇总为单一 reward，不是 SWE-bench 的 F2P、P2P 或 all 三类拆分。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。