Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Rubric judge未获得被评 agent 的执行轨迹——与论文不一致,且「是否使用了某文件」类 rubric 恒被判通过

未关闭
#12 4 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
3/5
预计耗时
1-2 天
新手友好度
65/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
冷清
技术栈
python
领域
ai, testing-qa

调研方向

从 evaluation/src/agent_as_a_judge.py 开始，重点查看 _build_judge_prompt 和 _prepare_judge_view，并将 judge payload 与 dep_graph_recognition._trace_summary 中的执行跟踪处理进行比较。跟踪执行数据的可用方式，并确保 rubric 评判能够接收输出文件、输入文件、rubrics 和执行跟踪，从而不会仅仅因为输入可见就通过基于过程的 rubrics。

由索引模型根据 Issue 内容生成。

描述

您好，感谢发布 Workspace-Bench。

我们最近在使用 Workspace-Bench 评测多个 Agent 系统。整体上非常认可这个 benchmark 的方向，尤其是大规模 noisy workspace、cross-file dependency reasoning 和 workspace-level grounding。这些设计比传统“小文件包 QA benchmark”更接近真实 Agent 场景。

但是我发现论文明确 Agent-as-a-Judge 评 rubric 时会把被评 agent 的执行轨迹一并给裁判;当前代码(evaluation/src/agent_as_a_judge.py)没给，裁判只能看原始输入 + 候选输出。后果:(1) rubric 通过率无法与论文对标；(2)「agent 是否使用/整合/追溯了某输入文件」这类过程型 rubric 被恒判通过（因为input本质上是模型应该用到哪些文件的gt），抬高分数。

论文规定 — 裁判应拿到 4 样:输出文件 + 输入文件 + rubrics + 执行轨迹。

代码现状 — _build_judge_prompt 的 payload = task/steps/rubrics/data/judgeView{cwd, inputsPath, originalTaskMetadataPath, candidateOutputPath};_prepare_judge_view 只暴露 inputs/ + candidate_output/。无 executionTrace。 max_trace_items 对 rubric 评分是无效参数(轨迹只在 dep_graph_recognition._trace_summary 依赖图那步用)。

影响 — (1) 与论文口径不一致;(2) 只有 inputs/ 可见、目标文件本就在其中 → 「是否用了 X」几乎恒判通过。

主要语言
Python
星标
72
派生
7
平均合并
7 分钟
30 天内合并 PR
6

贡献指南

这个仓库没有索引到贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

OpenDataBox/Workspace-Bench 的其他 Issue

查看 OpenDataBox/Workspace-Bench 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。