LLM 裁判是「看一眼打个分」，这篇让裁判长出手脚：能重放轨迹、查数据库、逐条核对层级化需求的 Agent 裁判。与人类一致率约 90%（LLM 裁判约 70%）、成本仅人工 2.3%——藏书中唯一的调查型裁判方法论。
先修：a04（Grader 三层分工与校准）。评测对象是多步复杂 Agent（编码、深度研究、长程任务）且普通 LLM 裁判已不够用的团队。与 a04（裁判分工）、a25（Tracing）连读。
先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。
三种场景：轨迹太长塞不进上下文；需要主动核查（跑代码、查数据库、重放步骤）；需要逐条核对层级化需求。核心差别是「阅读型」vs「调查型」。
DevAI 上与人类一致率约 90%（LLM 裁判约 70%），成本约人工 2.3%——在复杂轨迹评测上，它把「又准又不太贵」从二选一变成兼得。
裁判 Agent 自己也是 Agent，也会错（如核查时读到未复位的脏环境），同样要做人机一致率校准；给它的核查工具要只读，且要求输出可追溯的核查过程。
上方为本站原创导读，下方为原文完整收录，便于对照阅读。
上一讲的 LLM 裁判，本质上是"看一眼，打个分"——你把材料（一段输出，或一条拍平的轨迹）塞进它的上下文，它读完，给个结论。对大多数开放主观项，这够用了。
但有些场景，"看一眼"根本不够。当被评的轨迹长到塞不进上下文、或者你需要裁判主动去核查（跑一下那段代码、查一下中间文件对不对、重放某一步看结果）、又或者要逐条核对几十条层级化的需求时——一个被动的、一次过的裁判就力不从心了。
这一讲的主角，是 LLM-as-a-Judge 的进阶版：Agent-as-a-Judge。一句话——让裁判本身也是个 Agent，能多步推理、能用工具、能主动调查整条轨迹，而不只是读完打分。
LLM 裁判是被动的、一次过的：它的能力边界，就是"把能塞进上下文的东西读一遍，然后判"。这带来三个它扛不住的场景：
场景一：轨迹太长。一个跑了几十步、调了一堆工具、产生大量中间输出的复杂任务，整条轨迹可能塞不进上下文；就算硬塞进去，模型在长上下文里也会"读不仔细"（context rot），漏掉关键的那一步。
场景二：需要主动核查，而不只是阅读。有些判断光读轨迹判不了，得动手去验——把 Agent 写的代码真跑一下看编不编译、去数据库查一下那笔退款到底成没成、重放某个工具调用看返回对不对。被动裁判只会"看材料"，不会"做实验"。
场景三：需要分层、多步的推理。比如一个任务带着几十条层级化的需求（大需求下挂小需求），要逐条核对"满足了没有"。这本身就是个需要规划、逐项检查的多步活儿，不是"读一遍打个分"能完成的。
这三种场景的共同点是：你需要的不是一个会阅读的裁判，而是一个会调查的裁判。
用一个具备多步推理、状态管理、工具使用能力的 Agent，去审视另一个 Agent 的完整决策过程，而不只看最终输出。
它是 LLM-as-a-Judge 的"长出手脚"版本。同样是 LLM 驱动，但裁判 Agent 能做被动裁判做不到的事：
它的代表工作（论文 Agent-as-a-Judge: Evaluate Agents with Agents）就是用它去评 AI 编码 Agent：在一个叫 DevAI 的基准上（55 个真实的 AI 开发任务，每个带层级化需求），裁判 Agent 会去检查中间阶段代码编不编译、每条用户需求满没满足、用了多少次工具调用/尝试——这些全是被动 LLM 裁判够不着的。
为什么"层级化需求"特别需要 Agent 裁判？真实任务的验收标准常常是树状的：一个大目标（"正确处理退款"）下面挂着一串有依赖关系的小要求（先核身份 → 再查状态 → 满足条件才退 → 退后发确认 → 邮件内容如实）。要判这种任务，你得逐条、按依赖顺序核对每一项——这正是"多步推理 + 主动核查"的活儿。被动读一遍根本理不清"哪条满足了、哪条因为前一条没做而连带失败"；Agent 裁判则能把它拆成一张结构化的核查图，一条条走完。
回到退款例子，体会一下差别：LLM 裁判读一遍退款轨迹的文字记录，判"它有没有守 policy、话术好不好"；Agent 裁判在一个沙箱里重放这条退款轨迹，真的去查数据库确认钱退没退、逐条核对每一项退款 policy（30 天内？未发货？身份匹配？）是否都被遵守，发现某步可疑还能回放该步看细节——最后给出"哪条 policy 在第几步被违反"的精确结论。一个在"读理解"，一个在"做审计"。
它审计退款轨迹的过程，大概像这样：① 读取被测轨迹 + 这条 task 的 policy 清单；② [工具] 查数据库 → 订单 #1234 最终状态 = refunded？✅；③ [工具] 回放 step2 → 退款接口返回的是 ok 还是 error？✅；④ 逐条核对 policy：30 天内？✅ 未发货？✅ 身份匹配？❌ 第 1 步根本没验证；⑤ 汇总：outcome ✅，但违反了"身份核验"这条 policy → 判 FAIL，并指明问题出在 step1（未核身份就进入退款流程）。
注意第 2、3 步——它真的去查、去回放了，而不是凭轨迹里的文字猜。这就是"调查型裁判"和"阅读型裁判"的根本差别：阅读型裁判很可能被一句流畅的"已为您核实身份并退款"骗过去，而调查型裁判会去查到底有没有这一步。
把上面那套调查能力拆开看，研究里那套框架其实靠三类可复用的"积木"：
理解这三块的意义在于：你自己搭最小版 Agent 裁判时，本质就是在攒这三样——先有"眼睛"（核查工具），再有"尺子"（逐条核查清单），等任务复杂了再上"骨架"（结构化推理）。
进阶手段值不值得上，得看证据。Agent-as-a-Judge 的实测数据很有说服力：
| 评判方式 | 与人类一致率 | 相对成本 | 看的范围 |
|---|---|---|---|
| 人工 | 100%（即真值） | 极高（成天、成百上千美元） | 全部 |
| Agent 裁判 | 约 90% | 约人工的 2.3% | 整条轨迹 + 主动核查 |
| LLM 裁判 | 约 70% | 与 Agent 裁判同量级、略低 | 只看喂进上下文的内容 |
准确度逼近人工，成本却接近 LLM 裁判。
这正是它作为"进阶手段"的价值——在复杂轨迹评测上，它能把"又准又不太贵"这件以前要二选一的事，往中间拉了一大步。但别神化它：裁判 Agent 自己也是个 Agent，也会犯 Agent 的错。
进阶不等于处处都用。Agent 裁判更贵、更慢、更复杂，滥用就是杀鸡用牛刀。把它放进成本阶梯里看最清楚：代码型评分器（最便宜/客观）→ LLM 裁判（开放主观项）→ Agent 裁判（复杂轨迹/要核查）→ 人工（最贵/真值），成本与能力递增。选型原则：永远从最左边够用的那一档开始，够不着了才往右升一级。
一句话：Agent 裁判是给"复杂到要调查"的轨迹准备的重武器，不是日常筛查的工具。
听到"Agent 裁判"别被吓退——你不需要复刻论文里那套完整框架。一个务实的最小版，其实就是把 LLM 裁判"长出几只手"：
说白了，这就是"一个被允许动手核查的 LLM 裁判"。所以你能从普通 LLM 裁判平滑升级过去：先给它一两样最关键的核查工具（比如查 outcome 的数据库接口），就能拿到 Agent 裁判的大部分好处，不必一上来就搭一套复杂系统。按需加手，别一步到位。
一个安全提醒：给裁判的工具最好是只读的。裁判是来"核查"的，不该改动被测环境——一旦它的核查动作带了副作用（比如查询时触发了写操作），就会污染 outcome，反过来把评测搞坏。
Agent 裁判最大的特点——"它本身是个 Agent"——既是它的力量，也是它的风险来源。
坑一：裁判 Agent 自己也会错，也需要被校准。它有自己的 harness、自己的 prompt、自己的偏差，它做的核查也可能出错（查错了表、重放时环境没复位）。所以——对它，你同样要做人机一致率校准，同样要拿人工当北极星去验它判得准不准。评测组件本身也需要被评测，而 Agent 裁判把这个套娃套得更深了——你在用一个复杂系统去评另一个复杂系统。
举个它会怎么错：裁判 Agent 去查数据库验证退款，可它查的时候环境没复位、读到的是上一个 case 残留的旧状态，于是把一次本该 FAIL 的退款判成了 PASS。它不是"判断"错了，是它的核查这一步本身就错了——而这种错比 LLM 裁判的错更隐蔽，因为它包着一层"我可是亲自查过的"的可信外衣。所以裁判 Agent 自己也要遵守那条铁律：核查时的环境也得是干净、复位过的。
坑二：成本与复杂度别低估。"和 LLM 裁判一个量级"是相对人工说的；它毕竟是个完整的 Agent 系统，搭建、维护、调试都有真实成本。上它之前，先确认"普通 LLM 裁判真的不够用"。
坑三：别让它变成黑箱。它内部走了多步、调了工具，如果只吐一个最终分，你根本没法信任也没法调试。要求它输出可追溯的核查过程和逐条理由——因为它的内部更复杂，这条原则只会更重要。