多轮流程
Round 1 处理原始 issue;Round 2-5 由 simulated user 根据前序 trajectory、patch、测试输出和 behavior 类型继续追问、纠错、要求验证或做维护性审查。
多个 CCBench 任务、同一 simulated user seed/profile、同一 Claude UX judge,对比两个推理模型在 5 轮真实开发交互中的体验表现。
Round 1 处理原始 issue;Round 2-5 由 simulated user 根据前序 trajectory、patch、测试输出和 behavior 类型继续追问、纠错、要求验证或做维护性审查。
保留 deterministic verifier 与 LLM-as-judge:前者判断代码是否通过测试,后者判断上下文保持、纠错、测试质量和用户负担。
把每一轮看作一次 pairwise match。默认初始分 1000,K=32,胜/平/负分别为 1/0.5/0。
这里展示所有 task 的总分平均;当前 demo 为 3 题平均。
E_A = 1 / (1 + 10^((R_B - R_A) / 400)) R_A' = R_A + K * (S_A - E_A), K = 32
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 过长导致上下文污染或截断。
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。