把编码智能体接进 WorkBuddy Bench 后，最先要定的不是提示词怎么写，而是任务准备、运行、评分这三段责任分别由谁承担：任务集只描述输入是什么、什么算通过；评分侧只依据可验证的产物打分；智能体只负责把补丁写到约定位置，不修改判定结果。这三段一旦混在一起，一个失败记录就既可能是任务描述写得含糊，也可能是补丁没落到正确位置，还可能是评分脚本读错了目录，翻日志时看不出该找谁。可行的切入方式是先把任务集和评分口径固定下来，再放开智能体的产出方式；下面的目录约定、字段和命令都需要替换成你所在团队的实际结构后再用。
判断方向是：先用固定的任务集和固定的评分口径把基准固定住，再放开智能体的产出。适用场景是多人和多个智能体共用同一套基准；操作动作是按任务ID对齐目录、先跑通单条任务、再用失败记录回溯扣分点。验证方式是检查运行日志中的任务ID、补丁文件名、评分记录三项能否一一对应。风险边界也要说清：这套分工只能保证问题可定位，不能证明任务集本身合理，任务描述与判定条件仍然需要人工评审。
在任务目录里确认每个任务只描述输入和判定条件
任务侧要做的事，就是把「考什么」和「怎么判」写成可读的文本，而不是把判分脚本的细节塞进任务描述里。检查方式是打开每个任务文件，确认它至少包含三块内容：输入（初始代码、仓库快照或问题描述）、期望行为（智能体应该改出什么效果）、判定说明（哪条命令通过、哪些文件允许变更）。如果任务描述里出现了「如果测试失败扣几分」「跳过某规则加几分」这类内容，就说明评分逻辑漏到了任务侧，建议搬到评分侧的规则文件里，否则改一条任务就可能悄悄改掉打分口径。
下面是一份通用的任务文件骨架，字段名可按你团队的约定替换；关键不是格式，而是三块内容的边界清楚。
# tasks/T-014/task.yaml
task_id: T-014
input:
repo: fixtures/T-014/base
statement: 修复 parse_date 在空字符串下的异常
retry_limit: 1判定说明建议单独放在 tasks/T-014/checks.yaml，由评分侧读取；任务目录里只保留「引用哪份判定说明」，不内联具体扣分细则。
| 环节 | 负责内容 | 不该做的事 | 核对位置 |
|---|---|---|---|
| 任务侧 | 输入、期望行为、判定说明的引用 | 写扣分规则、写死运行命令的输出解析 | tasks/<task_id>/task.yaml |
| 智能体执行侧 | 只产出补丁文件与自身运行日志 | 修改任务文件、写评分记录、改判定脚本 | output/<task_id>/patches/、logs/agent/ |
| 评分侧 | 按判定说明读取补丁并给出记录 | 读智能体自然语言结论当作通过依据 | results/、scoring/ |
让智能体只输出补丁文件，不直接改评分记录
执行侧越界最常见的表现，是智能体顺手改动了判定脚本或直接写 results 目录，事后谁都说不清通过状态是谁写进去的。收窄方式是给智能体的输出定死两处：补丁文件落到 output/<task_id>/patches/ 下，文件名带任务ID，例如 T-014-r001.patch；智能体自己的过程日志单独放在 logs/agent/T-014.log，不写进评分目录。给智能体的指令里只保留「产出补丁路径」这一项交付物，并明确禁止编辑 tasks/、scoring/ 下的文件。
runs/
output/T-014/patches/T-014-r001.patch
logs/agent/T-014.log
results/T-014.json # 只由评分侧写入
scoring/checks_runner.py # 执行侧只读核对方式很直接：跑完之后看 output 目录里是否有与任务ID同名的补丁，看 scoring/ 与 results/ 的最近修改时间是否只出现在评分阶段。如果智能体报告「已完成」但 output 目录为空，先怀疑它把改动写在了临时工作区而没有导出补丁，而不是先去怀疑评分脚本。
运行单条任务，检查补丁文件与任务ID的对应关系
不要一上来就跑全量任务集。先挑一条任务单独跑，把三项信息记下来：任务ID、补丁文件名、本次运行日志路径。这三项是后面所有定位工作的基础，缺一项，评分记录里的失败就无法回溯。
- 确认任务文件里的 task_id 与目录名一致，例如 tasks/T-014 里的 task_id 就是 T-014。
- 单独运行一条任务，输出目录指向本次的 run 目录，避免历史产物混进来。
- 执行结束后列出 output/<task_id>/patches/，确认补丁文件名包含同一个任务ID。
- 打开 logs/agent/<task_id>.log，确认日志里的任务ID与补丁文件名一致，没有跨任务写入。
- 把任务ID、补丁文件名、日志路径三项记录到本次运行的单据里，再去触发评分。
bench run `--task` T-014 `--run-id` r001 `--out` runs/r001
ls runs/r001/output/T-014/patches/
tail -n 40 runs/r001/logs/agent/T-014.log如果发现补丁文件名里的任务ID与目录对不上，或者补丁落到了别的任务目录，先查输出目录的拼接逻辑（通常是 run 目录、task_id、patches 三段的拼接顺序），再去看智能体的输出路径参数，不要先去改评分脚本。
在评分记录里核对扣分点是否能回溯到补丁行为
评分侧只应依据可验证的产物打分：补丁内容、判定命令的返回码、判定说明要求的文件是否存在。核对时挑一条失败记录，把每一条扣分原因对应到具体的补丁差异或缺失文件；对应不上的字段单独标出来，例如标成 needs_trace，然后回到任务侧确认是真的没改，还是判定说明写得没法验证。
- 能回溯的例子：扣分原因是「parse_date 对空字符串仍抛异常」，对应补丁 diff 里没有该方法的相关改动。
- 不能回溯的例子：扣分原因是「实现不优雅」这类只存在于评审文字里的判断，这类字段需要从自动评分里移除，或者改成可执行检查。
- 疑似越界的例子：评分记录里出现补丁文件之外的改动（如 scoring/ 下文件被修改），说明执行侧越界，需要先收紧智能体的写入权限。
这一步的目的不是提高通过率，而是确认每条扣分都有据可查。回溯不出来的记录越多，说明任务侧的判定说明越需要重写。
用两条任务对比，确认任务集变更不影响评分脚本
任务集和评分脚本通常由不同的人维护，改一条任务时误伤评分逻辑的情况并不少见。对比方法是选两条任务，只修改其中一条的输入（例如换一份初始代码），另一条保持原样，各跑一次，再比较两份评分记录中的 task_id、补丁文件名和通过状态是否与上次一致。预期结果是：被改动的任务通过状态可能变化，未改动的任务在两次记录中保持稳定；如果未改动的任务也出现了状态翻转，就应优先检查评分脚本是否把任务输入路径写死、或是否按目录顺序读取任务。
bench run `--task` T-014 `--run-id` r002 `--out` runs/r002
bench run `--task` T-015 `--run-id` r002 `--out` runs/r002
diff runs/r001/results/T-015.json runs/r002/results/T-015.json对比时以 results 目录里的结构化记录为准，不要用智能体的自述文本作比较。若两次记录中的字段顺序、时间戳不同而判定内容一致，属于正常差异；只有通过状态或扣分条目变化才需要追查。改完任务后建议把这次对比的记录一并留档，方便下次判断问题出在任务侧还是评分侧。