多轮流程
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 为 3 题平均。
测试 + LLM-as-judge先在每个 task 内计算 deterministic verifier 与 Claude UX judge 分数，再按模型跨 task 取平均。主排序使用平均 UX reward。
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 分数（3题平均）
Claude 模拟用户 Elo（3题平均）
真人投票 Elo（全站 + 本地）
正在读取投票数据...
你的本地投票 Elo
完成每轮投票后在本浏览器计算。
关键参数与 simulated user 机制
max_rounds：控制一次 multi-turn evaluation 的总轮数。Round 1 永远是原始题目，Round 2 到 Round 5 才由 simulated user 继续追问、纠错、要求验证或做维护性审查。
seed：固定 behavior sequence 的随机性。Harbor 会用 seed、task name、profile、behavior id 计算稳定顺序，这个过程不包含被测模型信息，因此 Qwen 和 GLM 在同一个 task 中会遇到同类型、同轮次的用户追问。
profile：控制 simulated user 的画像和语气。本 demo 使用 balanced-maintainer-bugfix，含义是平衡型 maintainer + bugfix 场景：追问会偏向证据、最小修复、聚焦测试、维护风险和上下文一致性。Harbor 还保留 expert-maintainer-bugfix、security-reviewer-refactor 等 profile，用于更强专家审查或安全维护场景。
behavior：每个 follow-up 轮次会先选一个行为类型，例如 debug-followup、add-tests、correct-requirement、failure-report、rejection-rollback、repo-understanding、security-maintainability-review、final-cleanup。behavior 决定用户本轮要模拟“怀疑有 bug”“要求测试”“纠正需求”“报告失败”还是“最终清理”。
anchor_followups：这是 benchmark 校准用的固定追问机制。如果某个 round_id 配置了 anchor follow-up，该轮不会调用 LLM simulator，而是直接使用人工写好的 instruction、intent 和 expected_agent_behavior。它适合把关键用户场景固定住，例如必须出现一次需求纠正、一次 rollback 或一次特定测试要求，从而保证不同模型、不同 run 的对比更可复现。
用户追问如何生成：非 anchor 轮次中，Harbor 会构造一个 structured context，包含原始题目、当前 behavior、前序每轮用户指令、agent trajectory 摘要、工具/命令摘要、patch excerpt、测试输出摘要、verifier 结果和异常信号。然后把这些证据交给 claude-opus-4-6，要求它只生成“下一条用户消息”，不能替 agent 解题，也不能泄漏隐藏评测指令。
simulator / judge LLM 参数：model 指定 simulated user 或 UX judge 的模型；api_base 指定 OpenAI-compatible endpoint；temperature 控制追问发散程度，本 demo 的 UX judge 使用低温度保持稳定；max_context_chars 控制送入 simulator / judge 的上下文长度，避免 trajectory 和 patch 过长导致上下文污染或截断。
原始题目
测试 + 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 分别衡量任务成功、最新需求遵循、纠错能力和测试验证质量。
真人用户投票 / 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。