标注预算花在哪，基本决定了这批数据能不能用。我的判断：主观评分是最贵也最没用的那一栏。给同一段回答打分，两个人对不齐是常态，训出来的不是能力，是标注员的脾气。该逐条标的是可判定的事实——工具选对没、参数填对没、有没有编造。主观那部分别扔，但压成一个二元问题：这东西能不能直接交付。
先算一致率，再决定主观分要不要标
「回答好不好」这类题不是不能标，是标完没法用。你可以自己验：从待标池里抽一批样本，让两个人独立标，然后看分歧率。分歧大的栏目，进训练集就是噪声。这个测试花不了半天，比事后清洗数据便宜得多。
还有个更底层的问题。这周有篇论文讲 LLM agent 可以轻易篡改自己的执行 trace（LLM Agents Can Easily Tamper With Their Own Traces）。如果标注的原料是 trace，而写 trace 的就是被标的那个 agent，那基于 trace 的主观印象分连根都不牢。同一批里还有一篇讲 agent 在普通任务压力下会绕开运行时监控（Instrumental Monitor Evasion Emerges Under Ordinary Task Pressure）。两篇合起来意思很清楚：别靠"看起来还行"判断行为对不对。
客观项其实能列成一张短清单
工具选择、参数正确性、有没有编造，这三类是标准的可判定项。工具选择看意图和调用的匹配；参数看时区、单位、ID 这类具体字段；编造看引用是否真实存在、数字是否能在原文里找到。
还有一类常被忽略：步骤有没有被执行、顺序对不对。HEXIS 把 agent skill 编译成扩展有限状态机，正好把"哪一步该来、哪一步被跳过"变成可检查的控制流。这类判断不需要品味，只需要查证，标注员培训成本比打主观分低得多，两人分歧也小。
只标客观项，会漏掉「全对但没用」
一个回答工具全调对、参数全正确、零幻觉，用户看完还是得自己再查一遍。这种失败在客观清单上是满分。纯客观派的最大盲区就在这。
补这块的不是主观打分，是更接近真实使用的评估环境。比如 Screen Before You Serve 那套给 CX agent 做的模拟，重点不是问"答得好不好"，而是让 agent 在接近生产的策略和工具约束下跑，看它到底有没有把用户的事办完。
主观项：只问能不能直接交付
我的做法是把主观项压成一个二元题——这份输出能不能直接交付？加一个自由文本框写一句理由。中间档不要，"一般般"是分歧的温床。
这个思路有现成结构可以借。Requirement-Bound Verified Commissioning 把候选生成和放行权拆开，外面套一层验收。标注员在这里的角色就是验收层：不做审美裁判，只做放行决定。理由栏是为了后面回溯，不是为了统计。
落到操作上
客观项逐条标，每项二元或枚举；主观项只标可否直接交付；抽样验一致率，客观项看分歧率，主观项看两人是否都点头。另外 trace 本身要防篡改，不然前面全白干。
按我现在看，这套的弱点在"可否直接交付"太粗。有些场景确实需要更细的失败分类，比如"信息对但格式进不了下游"。也许半年后回头，这个二元会被拆成三四个。但先别急着拆——先把主观分的五分制砍掉，那部分钱省下来，够标很多东西了。