PROJECT 02 / SESSION-EVAL · 真实场景研究
DeepSeek Harness 真实 Session 评测
在这条真实 Session 中，Agent 偏离了原定目标，经过用户提醒后才回到任务主线。Judge 找到了这个问题，但最终仍然给出 9 分。
这个项目把用户目标、完整 Trace、Judge Check 和 Evidence 放在同一个评测流程中。本页继续使用这套工作台评测 DeepSeek Harness。
01 / 研究动机
把 DeepSeek Harness 直接接入 Session-Eval
Session-Eval 在设计时考虑的是通用的 Agent Session。它把用户目标、完整 Trace、Judge Check 和 Evidence 放在同一个评测流程中，并不依赖某一种 Agent 的页面或任务形式。
我想进一步确认，这套评测方法能否处理 coding-agent 更长、更复杂的任务。因此，我把 DeepSeek Harness 作为被测 Agent，直接接入现有工作台。
02 / 数据接入
50 条合成 Session 的数据检查
我先准备了 50 条合成多轮 Session，用来检查 DeepSeek Harness 的对话、工具调用和执行结果能否完整导入，Judge 结果与 Evidence 能否在现有页面中正常查看。这套评测工作本身就在 DeepSeek Harness 的真实开发中完成：Harness 既是被测对象，也是完成评测的工具。
这组数据只用于检查系统，不代表真实用户的任务分布，也不能证明现有 Rubric 已经适合长程 coding-agent。
03 / 真实案例
一条真实 Session 发生了目标漂移
这条 Session 包含持续开发、验证和纠偏。Agent 完成了很多具体操作，也交付了看起来完整的结果，但其中一段工作已经偏离原定目标。
开始评测
让 DeepSeek Harness 成为被测 Agent，采集真实的多轮 Trace 并完成评测。
明确数据要求
用户再次强调，需要的是接近真实使用方式的高质量 Session，不能只追求数量或分数分布。
改用无关数据
Agent 随后导入了一组与 DeepSeek Harness 无关的 Hub 人工校准数据。
把错误结果当作交付
Agent 根据这组数据得到完整的分数分布，并把它作为本轮工作的主要结果。
用户指出偏移
用户明确指出，这组数据与原定目标无关，当前工作已经偏离计划。
回到原任务
Agent 承认偏移，之后才重新采集和评测真实的 DeepSeek Harness 多轮 Session。
“真实多轮数据带来了完整分数分布……Rubric 区分度问题彻底闭环。”
Agent 把与原目标无关的数据结果作为主要交付。
“这不是完全偏移了计划吗？……你还记得项目初衷是什么吗？”
用户明确指出目标已经发生偏移，Agent 此前没有主动发现。
04 / 评分结果
Judge 命中了目标漂移，但最终仍然给出 9 分
Judge 命中 C4.4 偷换目标，Evidence 也准确指向 Agent 的错误交付和用户的后续纠偏。现有规则把 C4.4 固定为 minor，所以只有“意图达成”扣了 1 分，其余四个维度仍然是满分。
05 / 评分偏差
9 分低估了目标漂移的实际影响
Evidence 本身没有问题，它已经说明目标漂移发生在哪里。偏差来自现有 Rubric 对问题类型、严重度和总分的处理方式。
原有 Check 面向创作任务
C4.4 原本描述“交付结果相近，但没有满足实际用途”的情况。在创作任务中，这通常是局部偏差；在 coding-agent 中，被替换的可能是整项工程目标。
严重度不会随影响变化
C4.4 固定对应 minor。现有规则没有考虑目标层级、偏移持续时间、已经投入的工作量，以及是否需要用户亲自纠正。
总分没有任务失败门槛
一次 minor 只让一个维度扣 1 分。其他四个维度仍然是满分，所以总分回到 9 分，即使 Agent 已经偏离主要任务。
用户纠正被当成正常收敛
Agent 在用户提醒后回到原任务，因此“多轮收敛”和“未解决风险”没有扣分。现有评分没有区分 Agent 主动修正和用户介入后的修正。
工具执行成功不能说明目标正确
这条 Session 包含 716 次工具调用。很多调用在技术上成功，却服务于错误目标；现有工具维度没有记录这种偏差。
06 / 评测复盘
评分偏差出现在严重度和总分规则中
复盘这条 Session 时，我把一次评分拆成五个部分。它们分别回答“发生了什么”“系统如何判断”“判断依据在哪里”以及“分数如何计算”。这样可以确认，Judge 和 Evidence 都正常工作，偏差出现在严重度和总分规则中。
- Trace
- 记录实际过程
- 54 个用户轮次记录了原始目标、错误数据的导入、Agent 的交付和用户纠偏。这些内容是后续判断的事实基础。
- Judge Run
- 执行一次评测
- Judge 读取这条 Trace，并命中 C4.4。这个结果说明系统发现了目标漂移。
- Check
- 说明问题类型
- C4.4 把这次行为归为“偷换目标”。分类基本准确，但它附带的固定严重度不适合这条长程任务。
- Evidence
- 指出判断依据
- Evidence 同时引用 Agent 的错误交付和用户的纠偏。它能够证明目标漂移发生过，但不能单独决定严重度。
- Score
- 按照规则计算
- 总分来自五个维度的汇总。由于只有“意图达成”扣了 1 分，系统最终得到 9 分。
后续 Rubric 需要记录目标在长程任务中的变化，区分 Agent 主动修正和用户介入，计算目标漂移持续的时间与成本，并为主要任务失败设置单独门槛。这次复盘只确认了需要调整的部分，还没有形成新的 Rubric 或修正分数。