Agent Mentor Learn
验证与质量保证：别让「看起来对」蒙混过关 · 第 4 / 6 节

第 4 课：LLM 当裁判：量表、格式与不该让它裁的事

学习目标：

  • 给自由文本产出写一张多维量表，说清每维在问什么，并知道一条成功标准往往要拆成好几张量表才评得全
  • 把裁判输出收紧成程序能处理的形状：先推理后给分、0.0–1.0 加通过/不通过，并说清为什么单次调用常比多裁判分项评更稳
  • 认出裁判的三种失效方式——自己评自己、被要求找茬就一定找出茬、只信 Agent 的自述——并对每种给出能落地的缓解办法

前置要求：读完第 1–3 课，理解「终态优先」的判定思路和确定性验证器的排序原则 | 上一课 第 3 课 << | 下一课 第 5 课 >>

第 3 课的天花板，和 LLM 裁判的位置

你给调研 Agent 派了活：整理近三年国内充电桩补贴政策的变化，输出两页简报。它跑了十几分钟，调搜索、抓 PDF、写出 1800 字，读着挺像回事。

现在你想验一下。第 3 课那套确定性检查这里一件都用不上：没有测试套件可跑，没有构建退出码可读，output == golden_answer 里的 golden_answer 你根本写不出来——找两个真人分析师写同一份简报，也不会写出同一篇。

这不是你没想到办法，是这类产出本来就长这样。Anthropic 复盘他们的多 Agent 研究系统时说得很直：研究类产出是自由文本、很少有唯一正确答案，所以很难用程序评判，而 LLM 天然适合给这类输出打分1。

不过在你顺手把简报丢给另一个模型「帮我看看写得怎么样」之前，先看清 LLM 裁判在官方那份排序里的位置。选判分方式的原则是「最快、最可靠、最可扩展」2：代码判分最快最可靠、极易扩展，但碰上不那么讲死规矩的复杂判断就不够用2；LLM 判分快、灵活、可扩展、适合复杂判断——官方在同一条里跟了个前提：先测出它可靠，再放量2；人工判分最灵活、质量最高，但慢且贵，能免则免2。

把中间那条的前提当硬条件，别当免责声明。LLM 裁判不是「更聪明的检查」，它就是一次模型调用：会犯错、有成本、同一份输入两次给分可能不一样。它值钱的地方只有一个——确定性检查够不着的东西，它够得着。

所以这一课不讲「怎么让模型给你的产出打个分」，那太容易了，随便写句提示词就有分数出来。它讲的是怎么让这个分数值得你信：量表怎么拆、输出怎么收、谁来当这个裁判、它会以哪几种方式坏掉、以及什么时候你根本不该请它。

量表：把「好」拆成几个能分别回答的问题

量表（rubric）听着正式，白话说就是一张评分表：把笼统的「写得好不好」拆成几个具体问题，每个单独回答、单独给分。

为什么必须拆？「这份简报好吗」，模型只能回你一段模糊褒贬；「简报里每条论断，在它引的来源里找得到吗」，模型可以一条条对着看。多数用例本来就需要沿几条成功标准做多维评估2。

Anthropic 给研究 Agent 用的量表是五维1，每维背后都是一类真实的失败：

  • 事实准确性——论断和来源对得上吗？ 模型说「2023 年退坡 30%」，它引的文件里真有这个数吗。这一维抓凭空生成。
  • 引用准确性——引的来源和论断对得上吗？ 方向和上一维相反，很多人当成一件事。上一维问「这句话有依据吗」，这一维问「挂在这句后面的链接，讲的是这件事吗」。Agent 常见错法是论断没问题，却挂了一篇只是标题看着像的来源。分开评，你才知道该修检索还是该修写作。
  • 完整性——要求的方面都覆盖了吗？ 说了「近三年」它只写去年，说了「变化」它只写现状。对着任务要求逐条打勾，不看写得漂不漂亮。
  • 来源质量——用的是一手来源，还是低质二手？ 这一维抓到的问题最阴。Anthropic 的人工测试发现过：早期 Agent 一贯偏爱 SEO 优化过的内容农场，而不是学术 PDF、个人博客这类权威但排名靠后的来源1。产出读着完全正常，来源却是一层烂地基。
  • 工具效率——用对工具了吗，次数合理吗？ 同一个答案，搜三次和搜三十次拿到，成本差一个量级。这一维评过程的经济性，不是「有没有按我预设的步骤走」——后者行不通，第 2 课已经说过。

这五维是给研究类任务的，换个任务就得换一套。能搬走的是拆法：从「这个产出如果坏了会怎么坏」倒推维度，一种坏法一维。另外别漏了：一个用例、甚至它底下的某一条成功标准，可能需要好几张量表才评得全面2。别指望一张表包打天下。

输出格式：一次调用、一个分数、一个通过与否

先说结论形状。 Anthropic 试过多裁判分项评——每个组件派一个裁判。结果是：单次 LLM 调用、单个提示词、输出 0.0–1.0 分数外加一个通过/不通过的判定，反而最一致、也最贴近人类判断1。

说句公道话：把评测拆成多个 LLM 调用、每个调用评一个方面，本身也是官方写过的自动化评测形态3，两种都不算歪路。区别在于「单次更好」这条结论是 Anthropic 在自己的真实系统上比出来的1。建议做法：从单次调用起步，等你有证据说明拆开更准，再拆。

再说输出收多紧。 官方对裁判提示词的要求是「实证或具体」：比如让它只输出 correct 或 incorrect，或按 1–5 打分；纯定性的评价难以快速、大规模判读2。翻成人话：裁判要是回你「整体质量尚可，但部分细节处理略显粗糙」，你拿它没办法——没法对 200 条这样的评语求平均，没法判断今天比昨天好了还是坏了，最后还得自己一条条读。那你请裁判干嘛。

最关键的技巧：先推理，再给分，然后把推理丢掉。 官方明确写了这条：让 LLM 先推理再产出评分、之后丢弃推理，能提升评判表现，对需要复杂判断的任务尤其明显2。「丢掉」不是删掉不看。推理是给裁判自己搭的脚手架——它得先写出「摘要第 3 段这句对应转录哪一段」，才判得准；但这段文字不该进你的下游统计。报表要分数和 pass/fail，推理留在日志里，等分数可疑时你回头翻。

主观维度怎么办？ 有些维度天生没法二元判定，比如「这份简报的语气适合发给客户吗」。官方给了个工具：基于 LLM 的 Likert 量表，用它来判主观态度或观感2——Likert 量表就是问卷里那种「非常不同意／不同意／中立／同意／非常同意」式的固定刻度（几档是问卷设计的惯例，不是官方规定）。要点还是那句：给它固定刻度，别让它自由发挥。

拼起来，裁判的输出大概长这样（示例只展开了前三维，source_quality 和 tool_efficiency 形状相同，从略）。程序读 score 和 verdict 就够了，reasoning 落盘留档：

干活的那个，不能自己当裁判

到这一步，一个省事的念头会冒出来：让 Agent 自己在收尾时评一下不就行了？它最清楚自己刚才干了什么。

这个念头要按下去，理由有两条。一是官方的经验：让一个模型实例处理请求、另一个实例负责筛查，往往比让同一个 LLM 调用同时承担把关和主体应答表现更好3——那条经验原本讲的是内容护栏的分工（一个实例应答、一个筛查不当内容），但「同一个调用别身兼两职」这层道理是通的。注意它说的是「同一个调用」——问题出在共享上下文，不是模型不够聪明。二是原因：Claude Code 官方文档描述过一个做法，在全新子 agent 上下文里跑的评审者，只看得到 diff 和你给它的标准，看不到产生这个改动的推理过程，因此它按结果本身评判4。

反过来读就知道自评错在哪：产出它的那一长串理由还挂在上下文里。模型刚刚才说服过自己「这里这样写是对的」，你紧接着问它「这里对吗」，多半会重复一遍刚才的理由。你拿到的不是独立判断，是自我复述。

如果你担心裁判太松或太严，官方还给了个旋钮：用多个提示词分别评不同方面，或要求不同的投票阈值，以此在假阳性和假阴性之间取平衡3。放到验收场景里，假阳性是「把没问题的判成有问题」，你会被假警报烦死；假阴性是「把有问题的放过去」，坏东西就这么发出去了。三个裁判里两个说 fail 才算 fail，比一个说 fail 就算 fail 要宽——拧到哪一档，看你这个场景里哪种错更贵。

裁判会怎么坏

换了人来判、量表也写了，裁判还是会坏，而且坏得很有规律。

一、被要求找茬的评审者，总能找出茬。 这条最反直觉，也最费钱。官方文档写得很清楚：被要求去找缺口的评审者，通常总会报出一些来，哪怕这份工作本身是扎实的——因为那就是你要求它做的事4。后果不止「多了几条无用建议」：同一处还写着，逐条追着这些发现去修会导致过度工程——多余的抽象层、防御性代码、以及为根本不可能出现的情况写的测试4。你的 Agent 于是进入自我加码的循环，评审提三条、修完再评又提三条，代码越修越厚，实际问题一个没解决。

这种报告长什么样，你多半见过：「建议为 parseDate 增加对空字符串的防御」——可上游调用点已经保证非空了；「建议把这三个常量抽成配置」——可它们三年没改过；「建议补充网络超时的重试测试」——可这条路径压根没有网络调用。三条都不算错，三条都不值得做，但它们混在一份评审报告里，跟真问题长得一模一样。

缓解办法官方也给了：告诉评审者只标记那些影响正确性、或影响既定需求的问题，其余的当可选建议4。这句要原样写进裁判提示词，并给「其余建议」一个安放处——加一个 optional_notes 字段，明说它不参与打分。有处可写，它就不必把风格偏好硬塞进扣分理由。

二、Agent 的自述，不能当证据用。 很多人图省事，只把 Agent 最后那段总结丢给裁判：「我检索了三个权威来源，交叉核对后确认了补贴比例。」裁判读完觉得流程挺规范，给了高分。可这段话本身不算证据。官方在讲工具评测时点破过：Agent 在反馈和回复里省略的东西，往往比它写出来的更要紧——LLM 并不总是说到做到5。它说「交叉核对了三个来源」，实际可能只调了一次搜索；它没提的那次失败重试、那次拿到空结果就往下编的动作，恰恰是你最该看见的。做法也直接：去看原始记录，包括工具调用和工具响应，从中抓出那些没有在 Agent 的思维链里明说的行为5。落到方案上就一句——裁判的输入里要有原始记录，不能只有自述。「工具效率」那一维尤其如此，它评的是真实调了几次、调对没有，这信息只存在于记录里。

三、题目本身就是模糊的。 严格说这不是裁判坏了，是你给它的题坏了。官方在讲评测设计要避开什么时点名了一类：模糊的测试用例，连人类之间都很难达成一致判断2。这类题你在验证裁判时会一眼认出来：你和同事对同一份产出判出了相反结果。这时候别急着改裁判提示词——裁判判得「不准」，是因为这道题压根没有准的答案。要么把标准补细到人能达成一致，要么把这条用例拿掉。拿它去算裁判的一致率，只会得到一个骗自己的数字。

什么时候值得建「评审—修改」回路

裁判判完就结束，还是把意见回灌给 Agent 让它改一版、再判一次？这个回路很诱人，也容易变成烧 token 的永动机。

官方给了两个判断标志，说明这类工作流什么时候真的合适3：一是当一个人把反馈说清楚之后，LLM 的回复确实能被明显改进；二是 LLM 自己也能给出这种反馈。同一处还补了前提：这类工作流在评判标准清晰、且反复打磨能带来可测量的价值时最有效3。

拿这两条当准入测试，做法很朴素：你自己先当一次裁判，把意见写给 Agent，看它改完是不是真的变好了。如果人写的反馈都推不动它，换成 LLM 写的反馈只会更推不动，这时候该修的是提示词或工具，不是加一层评审。反过来，人工反馈明显有效，你再看第二条——让 LLM 对着量表写一次反馈，和你写的比一比。两条都过了，回路才值得建。

分寸：裁判也是一次模型调用

回到第 3 课那条排序。选判分方式的原则是最快、最可靠、最可扩展2，代码判分在这三项上都排在 LLM 判分前面2。所以裁判用在确定性检查够不着的地方，而不是替代它们。同一份简报，正确的分层长这样：

text
第一层（确定性，几毫秒，零成本）  合法 JSON / Markdown 吗？长度在要求区间吗？  引用链接抓得到吗（HTTP 状态码）？引用条数 >= 3 吗？  任意一条不过 → 直接 fail，不必请裁判
第二层（LLM 裁判，几秒，按 token 计费）  五维量表打分 + pass/fail  输入：任务要求 + 产出 + 原始记录（工具调用与响应）
第三层（人工，慢且贵，只抽查）  裁判判 fail 但你觉得可疑的  随机抽一小部分裁判判 pass 的，防止裁判整体偏松

第一层能拦掉的别拿到第二层花钱——格式就不合法的输出，不需要一次模型调用告诉你它不合格。第三层不能省：人工测试会发现自动评测漏掉的边缘情况1，前面那个「一贯偏爱内容农场」的偏差就是人工测出来的1。

本课的边界：评测集怎么组织、这套裁判该铺到多少条用例上，是第 5 课的事；把裁判接进一条能反复跑的评测跑道、跑完出报告，是第 6 课的事。这一课只解决单次判定怎么做才靠得住。

💻 练习

小结

  • 自由文本产出没有唯一正确答案、很难用程序判，LLM 天然适合给这类输出打分1；但 LLM 判分的官方定位是「快、灵活、可扩展、适合复杂判断，前提是先测出可靠再放量」，人工判分最灵活质量最高却慢且贵、能免则免2。
  • 量表就是把「好」拆成能分别回答的问题。研究类任务的现成拆法是五维：事实准确性、引用准确性、完整性、来源质量、工具效率1；一个用例、甚至其中一条成功标准，可能需要好几张量表才评得全2。
  • 输出形状上，单次 LLM 调用、单个提示词、0.0–1.0 分数加通过/不通过，是实测中最一致、最贴近人类判断的做法1；要让裁判输出 correct/incorrect 或 1–5 这类具体结果，纯定性评语没法快速大规模判读2。让它先推理再给分、之后丢掉推理，能提升评判表现，复杂判断尤其明显2；主观维度可用基于 LLM 的 Likert 量表2。
  • 干活的不能自己当裁判：一个实例处理请求、另一个筛查，往往比同一个调用身兼两职表现更好3；全新上下文的评审者只看得到 diff 和你给的标准、看不到产出过程的推理，所以按结果本身评判4。多提示词分项评加投票阈值，可在假阳性和假阴性之间调平衡3。
  • 被要求找缺口的评审者总会报出些什么，哪怕工作本身扎实，逐条追杀会导致过度工程；办法是让它只标记影响正确性或既定需求的问题，其余当可选建议4。
  • 别只把 Agent 的自述喂给裁判：它省略的往往比写出来的更要紧，LLM 并不总是说到做到5；要看原始记录（含工具调用与工具响应），抓出自述里没提的行为5。
  • 「评审—修改」回路值不值得建，看两个标志：人把反馈说清楚时 LLM 的回复确实能被明显改进，以及 LLM 自己也能给出这种反馈3。
  • 裁判本身也是一次模型调用，有成本也有噪声。选判分方式的原则是最快、最可靠、最可扩展，代码判分在这三项上都排在前面2——确定性检查能拦下的别送到裁判面前；自动评测之外仍要留人工抽查，人工测试会发现评测漏掉的边缘情况1。

>> 第 5 课：评测集：从 20 条真实任务开始

Footnotes

  1. How we built our multi-agent research system — Anthropic Engineering — https://www.anthropic.com/engineering/multi-agent-research-system ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11

  2. Define success criteria and build evaluations — Claude API 文档 — https://platform.claude.com/docs/en/test-and-evaluate/develop-tests ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18

  3. Building Effective AI Agents — Anthropic Engineering — https://www.anthropic.com/engineering/building-effective-agents ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  4. Best practices for Claude Code — Claude Code 官方文档 — https://code.claude.com/docs/en/best-practices ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  5. Writing effective tools for agents — with agents — Anthropic Engineering — https://www.anthropic.com/engineering/writing-tools-for-agents ↩ ↩2 ↩3 ↩4

练习

01

有人给他们的调研 Agent 加了段「自检」，提示词是这么写的：

Level 1：给一段坏掉的裁判提示词做诊断（不写代码）
text
你刚才写完了这份行业简报。现在请你评价一下自己的这份摘要：你觉得这个摘要好吗？请详细评价它的优点和不足，尽量说得全面一些，把能想到的改进建议都列出来。谢谢！

你的任务： ①列出这段提示词至少 4 处毛病，每处对应到本课讲过的一条规则（写清是哪条、为什么这里违反了）；②把它重写成合格版本，重写版要能直接拿去用，不是描述「应该怎么写」。

完成标准 · 本地勾选
02

场景：你们的 Agent 每天把会议转录压成一份纪要摘要，含结论和行动项。摘要是自由文本、没有标准答案，但错了很贵——行动项漏一条，就是一件事没人做。

Level 2：给「会议纪要摘要」设计一整套裁判方案

你的任务： ①设计三维量表（事实忠实、要点完整、行动项无遗漏），每维 0.0–1.0 加总体 pass/fail，写清每维在问什么、什么算扣分；②写出完整的裁判提示词，含先推理后给分的顺序要求和严格的输出格式约束；③设计「验证裁判本身」的步骤：准备一小组人工标注的好/坏样例，跑裁判、比对一致率，并写清一致率不达标时先修谁、后修谁。不需要真调 API，交付的是提示词、JSON 和步骤本身。

完成标准 · 本地勾选