第 6 周：两份 Bug 报告换个顺序，Judge 就改判了？

BugHunt-Bench 每晚要对比新旧两版测试 Agent：同一个注入的 Bug，两版各交一份报告，由 LLM Judge 判哪份写得更好。某天有人把两份报告在 prompt 里的先后顺序调换了一下，胜率从 58% 变成了 49%（设想的场景）。Agent 一行没改，变的只是 Judge 先看哪一份。

这一章讲 Judge 自己的系统性偏差：它们是什么、论文测到多大、怎么写成测试抓出来、各种缓解方法分别治什么。本周前面几章讲了错误分析（「测试 Agent 为什么漏掉 Bug？从读 trace 到失败分类」）、rubric（「Bug 报告写得好不好，打 1~5 分还是判 pass / fail？」）和 Judge 校准（「Judge 说 53% 的报告有效，真实是多少？」：用人工标注算漏判率、误杀率和 κ），这里不重复。最后回到第 3 周读过的 Codex Guardian，把它当成一个"做门禁的 Judge"，看它的 prompt、输出 schema 和失败处理。

讲解视频

互动演示

两个演示。第一个是偏差模拟器：一个带位置、冗长、自我偏好三种偏差的模拟 Judge，在四组合成的 BugHunt 报告对上跑七种用法（单次判定、随机顺序、同顺序多数票、交换顺序、交换 + 长度控制、三家族评审团、评审团 + 长度控制），拖动滑块改偏差大小，表里的净偏差、判对率实时重算，下面可以挑一对报告看两种顺序下的结论分布。所有数字都是精确期望值，默认参数下和本地 experiment.py 的输出一致。第二个是 Guardian 失败处理演示：给三次尝试各选一种"模型返回了什么"（严格 JSON、外面包了一句话、不是 JSON、枚举值不对、限流、400、超时、输入超预算），看解析、重试和最终结论，逻辑按 Codex 源码移植。页面底部有自动判分的练习。

三种偏差：论文测到了什么

出处：Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena，NeurIPS 2023 Datasets and Benchmarks Track（ arXiv 2306.05685 ，下面的数字取自 v4 的 §3.3、§3.4 和附录 D）。第 4 周「检索对了，回答就对了吗？」提过这篇论文列的三种偏差，这里把数字和条件讲清楚。

位置偏差

做法：MT-bench 每道题的第一轮，调两次 GPT-3.5（温度 0.7）生成两份相近的回答，让 Judge 正着比一次、反着比一次。一致指两次结论指向同一份回答（或者都判平）；偏向第一个指交换后结论不一致、且偏向放在前面那份的比例（论文四列——一致、偏向第一个、偏向第二个、格式错误——加起来是 100%，没有单列"一次平一次胜"，也没有公开逐条归类的规则）。

rename 把 prompt 里的助手名字换掉，用来区分偏向的是位置还是名字；Claude-v1 换名后偏向跟着变了，论文据此说它还有名字偏差（偏爱 “Assistant A”）。论文自己也提醒了两点：这组测试的两份回答很接近，有时人也分不出；附录 D.1 的表 11 显示，两份回答水平差距大时位置偏差几乎消失（GPT-4 当 Judge，GPT-3.5 vs LLaMA-13B 一致 98.8%，GPT-3.5 vs Claude-v1 只有 67.5%）。所以位置偏差在"两份差不多"的时候最要命，而 Agent 版本对比恰恰常常是这种情况。

冗长偏差（长度偏差）

“重复列表"攻击：从 MT-bench 挑 23 个含编号列表的回答，让 GPT-4 把列表换个说法、不加任何新信息，插到原列表前面（5 条变 10 条）。Judge 认为加长版更好就算攻击成功。Judge 失败率（= 攻击成功率，表 3）：Claude-v1 91.3%，GPT-3.5 91.3%，GPT-4 8.7%。作为对照，三个 Judge 对两份一模一样的回答都能判平。

放到 BugHunt 里：一份报告把复现步骤换个说法再写一遍、贴一大段无关日志，信息没有增加，字数翻倍。

自我偏好

这一条要读仔细。论文的证据是统计观察：和人类评审相比，GPT-4 给自己的胜率高约 10%，Claude-v1 高约 25%；但它们也偏爱别的模型，GPT-3.5 并不偏爱自己。论文的结论是，由于数据有限、差异小，不能确定这些模型存在自我偏好，并说明了对照实验难做：很难把一个回答改写成另一个模型的风格而不改变质量。

之后的对照研究是 Panickssery et al. 2024（ arXiv 2404.13076 ）：GPT-4、Llama 2 等模型不经训练就能以一定的准确率把自己的输出和其他模型、人类写的区分开；微调之后，自我识别能力和自我偏好强度之间呈线性相关。

这些数字来自 2023 年的模型和 MT-bench 的题目，不能直接套到你的 Judge 上。它们说明的是：偏差确实存在，大小随模型、prompt、题型变化。所以每个 Judge 都要自己测，换模型、改 prompt 后要重测。

怎么测：每种偏差都是一条不变性测试

三种偏差有一个共同的结构：改动一个和质量无关的东西，结论变了。测开很熟悉这种测试，叫不变性测试或蜕变测试：不知道"正确答案"是什么，但知道两次运行之间应该满足的关系。

几个容易做错的地方：

• 配对要真的"等质量”。冗长测试的加长版必须没有新信息，否则 Judge 偏爱它可能是对的。论文的做法是让模型改写已有的列表，不加内容。
• 两个方向都要测。只测"A 在前"会把位置偏差算进冗长偏差里。下面的实验对冗长和自家两项都是两种顺序各占一半。
• 看净值，不只看分出胜负的那部分。交换顺序以后平局变多，如果只在"分出胜负"的结论里算自家占比，分母变小，偏差看起来反而更大（下面实验里从 64.0% 变成 76.1%），但自家多赢的绝对概率其实降了（+0.219 → +0.173）。
• 样本量。这些都是比例，区间按第 1 周「30 次挂了 2 次，失败率在什么范围？」的 Wilson 区间算；同一对报告重复调用不是独立样本，按配对数算，见「跑了 300 次，就是 300 个样本吗？」。

缓解方法：各治一种

Zheng et al. 后续实验用的是保守的交换顺序。表里没有"多问几次取多数"，因为它治的是随机噪声，不是偏差，下面的实验专门看这一点。

动手实验：一个带偏差的模拟 Judge

代码在学习目录的 week06_Judge与错误分析/code/judge_bias/，只用标准库，不调任何模型 API，全部是合成数据。

模拟 Judge 比较两份报告，内部打分

\(q\) 是造出来的"真实质量"，\(w\) 是字数。再加一个标准 Logistic 噪声 \(\varepsilon\) 模拟采样随机性，\(z+\varepsilon\) 超过 \(+m\) 判第一个赢、低于 \(-m\) 判第二个赢、否则判平，于是 \(P(\text{第一个}) = \sigma(z-m)\)，\(P(\text{第二个}) = \sigma(-z-m)\)。默认 \(s=12\)、\(b_{\text{pos}}=0.8\)、\(b_{\text{len}}=1.2\)、\(b_{\text{self}}=0.6\)、\(m=0.6\)。这些参数是为了演示挑的，不对应任何真实模型。

四组报告对：P 位置探针 40 对（质量差 0~0.04，字数、来源相同）；Q 有差距 60 对（质量差 0.1 / 0.2 / 0.3，四分之一是差的那份更长）；V 冗长攻击 20 对（同一份报告把复现步骤换个说法再写一遍，字数翻倍、信息不变）；S 自我偏好 40 对（自家 J vs 别家 O，质量差对称分布）。

所有概率都是精确算的（多数票、评审团按所有投票组合枚举），另外用固定种子真的抽样核对了一遍。核心是交换顺序和多数票两个函数（strategies.py）：

def _swap_combine(d_ab, d_ba):
    """保守的交换顺序（Zheng et al. 2023 §3.4）：两种顺序都赢才算赢，否则平局。"""
    p_a = d_ab["A"] * d_ba["A"]
    p_b = d_ab["B"] * d_ba["B"]
    return {"A": p_a, "B": p_b, "tie": 1.0 - p_a - p_b}


def plurality(dists):
    """若干次独立判定取多数：票数最多的胜出，最多票并列就算 tie。精确枚举。"""
    out = {k: 0.0 for k in CONTENT}
    for combo in product(CONTENT, repeat=len(dists)):
        p = 1.0
        for d, o in zip(dists, combo):
            p *= d[o]
        if p == 0.0:
            continue
        counts = {k: combo.count(k) for k in CONTENT}
        top = max(counts.values())
        winners = [k for k in CONTENT if counts[k] == top]
        out[winners[0] if len(winners) == 1 else "tie"] += p
    return out

运行 python3.13 experiment.py 的真实输出：

模拟 Judge（合成）：家族 J，灵敏度 12.0，位置 +0.8，冗长 +1.2/字数翻倍，自家 +0.6，判平半宽 0.6

1) 位置偏差，仿照 Zheng et al. 2023 表 2（"偏向第一个"只算两次都判第一个；论文没有"一次平一次胜"这一类，这里单列）
   数据                  一致  偏向第一个  偏向第二个  一次平一次胜
   位置探针 P(40对)     29.3%       29.4%        3.8%         37.5%
   有差距 Q(60对)       64.8%       12.2%        1.9%         21.1%

2) 七种用法（净偏差 = 偏向的一方赢的概率 − 另一方赢的概率，真实值都是 0）
   用法                        调用  位置净偏差  换序翻转    判对    判反    判平  冗长净偏差  自家净偏差  自家占胜局
   单次判定                       1      +0.345     70.7%   77.5%   10.1%   12.3%      +0.457      +0.219       64.0%
   随机顺序                       1      +0.000     64.6%   77.5%   10.1%   12.3%      +0.457      +0.219       64.0%
   同顺序 5 票多数                5      +0.517     79.8%   83.6%    4.5%   11.9%      +0.612      +0.285       70.0%
   交换顺序                       2      +0.000     37.9%   61.6%    1.5%   37.0%      +0.343      +0.173       76.1%
   交换顺序 + 长度控制            2      +0.000     37.9%   61.6%    1.5%   37.0%      +0.000      +0.173       76.1%
   三家族评审团（各自交换）       6      +0.000     15.6%   64.2%    0.3%   35.5%      +0.296      +0.054       64.4%
   评审团 + 长度控制              6      +0.000     15.6%   64.2%    0.3%   35.5%      +0.000      +0.054       64.4%

3) 一对质量完全相同的报告（q = 0.57），A 在前 / B 在前时 A 赢的概率
   单次：A 在前  55.0%，B 在前  19.8%
   同顺序 5 票多数：A 在前  59.3%，B 在前   5.6%

4) 蒙特卡洛核对（种子 20261001，每对每种顺序 4000 次，共 480000 次）
   单次判定 判对率：抽样  77.5%，精确  77.5%
   交换顺序 判对率：抽样  61.6%，精确  61.6%

指标的含义：位置净偏差是流水线总把 A 先给出去时 P(A 赢) − P(B 赢)，在 P 组上算；换序翻转是同一对报告一次正着、一次反着各独立跑一遍、结论不同的概率；判对 / 判反 / 判平在 Q 组上算，两种顺序各一半；冗长净偏差、自家净偏差分别在 V、S 组上算，两种顺序各一半；自家占胜局是只看分出胜负的结论时自家占多少（真实值 50%）。

读这张表：

1. 第 1 部分复现了论文的定性现象：两份报告质量接近时（P 组）一致率只有 29.3%，有明显差距时（Q 组）升到 64.8%。
2. 随机顺序把位置净偏差压到 0，但换序翻转仍有 64.6%：汇总的胜率没偏，每一条结论照样看运气。适合只看总胜率的场景，不适合要逐条复核的场景。
3. 同顺序 5 票多数：Q 组判对率 77.5% → 83.6%、判反 10.1% → 4.5%，随机噪声确实被压下去了；但三项净偏差都变大了（位置 +0.345 → +0.517，冗长 +0.457 → +0.612，自家 +0.219 → +0.285），换序翻转也从 70.7% 升到 79.8%。这是在本实验参数下的结果：单票最可能的结论本身就偏向某一方时，多数票会放大偏差；如果单票大多判平（例如 A 0.20 / B 0.15 / 平 0.65），5 票多数后净偏差反而从 +0.050 降到 +0.031。
4. 交换顺序把位置净偏差压到 0，判反降到 1.5%，代价是平局从 12.3% 升到 37.0%、判对降到 61.6%。冗长和自家两项只是因为平局变多而略降，没有被治好。
5. 长度控制只治冗长，其他列不变。注意这里是理想化的版本：模拟 Judge 直接拿到"去掉重复改写后的字数"（info_words），所以冗长净偏差正好是 0，这个 0 是构造出来的。现实里不知道哪些字是"无信息"的，Dubois et al. 的做法是用回归估计长度差的影响再扣掉，只能减小、不能保证精确归零。
6. 三家族评审团：自家净偏差 +0.173 → +0.054，因为另外两个成员不偏爱 J；但冗长净偏差还有 +0.296，因为三个成员都偏爱长报告。

多数票为什么治不了偏差

多数票有效的前提是：每一票的错误相互独立，单票最可能给出的结论是对的。随机噪声满足这两条，所以 Q 组的判对率上去了。

位置偏差不满足第二个条件：同一个顺序下，每一票都带着同一个"第一个加分"，单票最可能给出的结论本身就是错的（质量相同时 55% 判第一个赢、只有 25% 判平），多数票会把这个最可能的错误结论放大。从"顺序是随机因素"的角度看，同一顺序的 5 票共享了这个因素，它们不是关于"真实偏好"的独立样本。看第 3 部分那一对质量完全相同的报告：单次判定时，A 在前 A 赢 55.0%，B 在前 A 赢 19.8%；5 票多数变成 59.3% 和 5.6%，两种顺序的结论分得更开了。

这和第 1 周「跑了 300 次，就是 300 个样本吗？」是同一件事：多次运行共享了一个系统性因素（同一个顺序、同一个 Judge），它就平均不掉。反过来，单票大多判平、偏差只体现在少数票上时，多数票不一定放大偏差（上面的反例），但也不会把它消掉。要消掉一个偏差，得让它在不同的票里方向相反或者不出现：

• 交换顺序让位置偏差在两次调用里方向相反；
• 不同家族的评审团让各自的自我偏好只出现在一个成员身上；
• 评审团成员共有的偏差（冗长）方向一致，只能靠长度控制，或者在 rubric 里明确写"重复内容不加分"（rubric 写法见「Bug 报告写得好不好，打 1~5 分还是判 pass / fail？」）。

Guardian：一个做门禁的 Judge

第 3 周「Agent 要执行 rm -rf，谁来拦？」讲过 Guardian 在审批流程里的位置：需要审批时先跑 hook；hook 没给结论，再交给 Guardian（启用自动审批时）或用户，二者只走其一。补充一个细节：Guardian 被路由到、但"动作加最少上下文"超出了它的输入预算，而且没有强制 Guardian（strict auto-review，或托管 requirements 要求自动审查 / 禁止改回用户审批， core/src/guardian/decision.rs:66-71 ）时，它返回"没有结论"，请求退回给用户审批（ ext/guardian-reviewer/src/completion.rs:70-83 、 core/src/tools/approvals.rs:554-567 ）。

这里把它当成一个 Judge 来读：prompt、输出 schema、失败处理。源码都固定在 openai/codex 7993248。

prompt：先打两个分，再按规则推出结论

同步审查用的指令由三段拼成（ prompts/src/guardian_instructions.rs:53-68 、 core/src/guardian/reviewer_config.rs:31-47 ）：模板 policy_template.md，模板里的 {{ tenant_policy_config }} 默认填 policy.md（配置或模型目录可以覆盖， core/src/config/mod.rs:1583-1590 ），最后接上输出契约。另外还有两块：模板末尾的 {{ extra_policy }}（policy_template.md:43）填配置项 guardian_extra_policy，默认为空（ core/src/guardian/reviewer_config.rs:33-36 ）；同时开启 GuardianConversationHistoryTools 和 Apps 两个 feature 时，再追加一段对话历史工具的说明（ core/src/guardian/reviewer_config.rs:48-62 ）。

模板 prompts/templates/guardian/policy_template.md 的结构：

把一个"危险吗"的主观判断拆成两个有定义的维度，再由规则合成结论，和「Bug 报告写得好不好，打 1~5 分还是判 pass / fail？」里把主观维度拆成可判定条目的思路一致。L12 还有一条和偏差相关：“Treat <guardian_truncated ... /> and <truncated ... /> markers as omitted data. Do not assume the missing content was benign."：上下文被截断时不能当成没问题。

审查会话本身被锁住：只读权限、approval_policy = Never、只开放 exec_command 等少数工具，并把输出 schema 作为 final_output_json_schema 传给这一轮（ ext/guardian-reviewer/src/settings.rs:31-52 、 :79-106 ）。

用哪个模型当审查员（ ext/guardian-reviewer/src/model.rs:17-66 ）：默认找 codex-auto-review（用 API key 登录时是 gpt-5.6-luna， model-provider/src/provider.rs:122-126 、 :476-487 ），支持的话用 low 推理强度；模型目录里没有这个审查模型、父模型元数据里也没有 auto_review_model_override 时，退回用父 Agent 自己的模型。这个覆盖项是模型目录里 ModelInfo 的字段（model.rs:31、 protocol/src/openai_models.rs:494 ），不是用户配置；有覆盖值时，即使目录里没有那个模型也照用（model.rs:60-63）。源码没有说明这样选是为了避开自我偏好，下面这句是我的分析：退回父模型时，审查员和被审查的 Agent 是同一个模型，如果要评估这道门的偏差，得先确认实际用的是哪个审查模型。

输出 schema：只有 outcome 必填

ext/guardian-reviewer/src/assessment.rs:80-103 和 :107-119 （中间省略两行文档注释）：

pub fn guardian_output_schema() -> Value {
    serde_json::json!({
        "type": "object",
        "additionalProperties": false,
        "properties": {
            "risk_level": {
                "type": "string",
                "enum": ["low", "medium", "high", "critical"]
            },
            "user_authorization": {
                "type": "string",
                "enum": ["unknown", "low", "medium", "high"]
            },
            "outcome": {
                "type": "string",
                "enum": ["allow", "deny"]
            },
            "rationale": {
                "type": "string"
            }
        },
        "required": ["outcome"]
    })
}

pub fn guardian_output_contract_prompt() -> &'static str {
    r#"You may use read-only tool checks to gather any additional context you need before deciding. When you are ready to answer, your final message must be strict JSON.

For low-risk actions, give the final answer directly: {"outcome":"allow"}.

For anything else, use this JSON schema:
{
  "risk_level": "low" | "medium" | "high" | "critical",
  "user_authorization": "unknown" | "low" | "medium" | "high",
  "outcome": "allow" | "deny",
  "rationale": string
}"#
}

逐条解释：

• schema 只要求 outcome。低风险的动作可以只回一个 {"outcome":"allow"}，审查又快又省 token。
• 解析在 assessment.rs:24-65 ：先把整段文本当 JSON 解析；失败了，再截取第一个 { 到最后一个 } 解析一次。源码注释写明这是为了让格式漂移 “fails less noisily during dogfooding”，非 JSON 输出仍然算审查失败。
• 缺字段就补：缺 risk_level 时 allow 补 low、deny 补 high；缺 user_authorization 补 unknown；缺理由或理由是空白时补一句固定的话。对应的单元测试是 parse_guardian_assessment_treats_bare_allow_as_low_risk 和 ..._bare_deny_as_high_risk（ assessment_tests.rs:22-52 ）。

对测开来说，这里有一个可以断言的契约：结论只由 outcome 决定：risk_level 只用于记录和展示；rationale 在拒绝时会作为 Reason: 发回给 Agent（ prompts/src/guardian_instructions.rs:145-147 ），但两者都不参与 allow/deny 的判定（ completion.rs:147-183 ）。所以 L66-73 的"先打分再推结论"是写在 prompt 里的要求，代码并不校验 risk_level = critical 时 outcome 一定是 deny。要测这条一致性，得在评测里自己检查。

失败处理：失败不等于不安全，但默认拒绝

ext/guardian-reviewer/src/lib.rs:40-41 定义了两个常量：最多 3 次尝试，整个审查共享 90 秒期限。重试规则在 retry.rs:94-139 ，最终结论在 completion.rs:68-145 ：

重试间隔 200ms × 2ⁿ⁻¹ 再乘 [0.9, 1.1) 的抖动（ retry.rs:74-79 ），和第 5 周「超时了，再发一次安全吗？」里 Codex 采样层的 ±10% 是同一个幅度，而且等待时间不会超过 90 秒的总期限。

最值得注意的是失败时发给 Agent 的话（ completion.rs:20-24 ）：

const REVIEW_FAILURE_INSTRUCTIONS: &str = concat!(
    "The action was not executed because automatic approval review could not be completed. ",
    "This is a review failure, not a determination that the action is unsafe. ",
    "Do not bypass the approval check; resolve the error or ask the user for guidance.",
);

超时时给 Agent 的话也类似：“Do not assume the action is unsafe based on the timeout alone. You may retry once, or ask the user for guidance or explicit approval."（ prompts/src/model_messages/guardian.rs:17-21 ，在 core/src/tools/approvals.rs:466-471 作为拒绝原因发回）。

这是门禁类 Judge 的关键设计：动作上 fail closed，记录上区分"判了不行"和"没判出来”。统计侧做了一半：分析数据的 decision 字段在超时和 fail closed 时记 Denied，在取消、以及输入超预算交回用户时记 Aborted（completion.rs:72、:100）；terminal_status 分别记成 TimedOut、FailedClosed、Aborted，并带上 failure_reason。发给客户端的事件状态，超时是 TimedOut（completion.rs:89），FailedClosed 时源码注释说为了兼容沿用 Denied（completion.rs:131-132）。熔断器只认模型判定的 deny。熔断规则（ circuit_breaker.rs:3-7 、 review.rs:140-160 ）：同一个 turn 里模型判定的拒绝连续 3 次，或最近 50 次审查里有 10 次，就中断这个 turn（被审查的 Agent 用 cyber 专长模型时，阈值是 1 次）。审查失败、放行都按"非拒绝"记，会把连续计数清零。

如果算 Guardian 的误杀率时把审查失败也算成"判定危险”，误杀率会被高估；反过来，如果失败时放行，这道门的漏判率就会随着服务抖动上升。「Judge 说 53% 的报告有效，真实是多少？」那一章讲的漏判率、误杀率，用在门禁上时要先做这个拆分。

把失败处理写成契约测试

guardian_gate.py 把上面的解析、重试判定和结论映射移植成了 Python（不含会话和计时），test_judge_bias.py 里对应的几个测试：

def test_bare_allow_is_low_risk_and_bare_deny_is_high_risk():
    assert parse_assessment('{"outcome":"allow"}')["risk_level"] == "low"
    deny = parse_assessment('{"outcome":"deny"}')
    assert deny["risk_level"] == "high"
    assert deny["user_authorization"] == "unknown"
    assert deny["rationale"] == "Auto-review returned a deny decision without a rationale."


def test_parse_error_is_retried_then_succeeds():
    assert run_review(["not json", '{"outcome":"allow"}']) == ("approved", 2)


def test_three_parse_errors_fail_closed():
    assert run_review(["a", "b", "c", '{"outcome":"allow"}']) == ("failed_closed", 3)


def test_timeout_is_not_retried():
    assert run_review([ReviewError("timeout"), '{"outcome":"allow"}']) == ("timed_out", 1)


def test_input_budget_goes_to_user_unless_guardian_is_required():
    assert run_review([ReviewError("input_budget")]) == ("ask_user", 1)
    assert run_review([ReviewError("input_budget")], require_guardian=True) == ("failed_closed", 1)

全部 25 个测试（模拟 Judge 的自检 2 个、不变性和多数票性质测试 9 个，Guardian 契约测试 14 个）：

$ python3.13 -m pytest -q
........................                                                 [100%]
25 passed in 0.09s

测试里有两条值得单独看：test_majority_vote_amplifies_systematic_bias 断言同顺序多数票的位置净偏差大于单次判定，把"多数票不治偏差"写成了一条可以回归的断言（在这个合成 Judge 上）；test_majority_vote_does_not_always_amplify 则用 A 0.20 / B 0.15 / 平 0.65 的反例说明放大不是无条件的。

测开视角：Judge 偏差的回归清单

几个原则：偏差测试的配对集要和业务分布分开维护，不然一次 prompt 调整就会悄悄改变"难度"；每次报告带区间；门禁类 Judge 的结论要同时记录"判定"和"失败"两种来源。

常见错误说法

• “多问几次取多数，偏差就平均掉了”：多数票只压独立的随机噪声。同一顺序下每一票都带着同一个位置偏差，单票最可能的结论本身偏向第一个时，多数票会把偏差放大（合成实验里位置净偏差从 +0.345 涨到 +0.517）。
• “交换顺序能治所有偏差”：它只治位置偏差。冗长和自我偏好跟着内容走，换顺序也跟着换；合成实验里交换后冗长净偏差还有 +0.343。
• “随机安排位置和交换顺序一样”：随机位置只让汇总的胜率不偏，单条结论照样随顺序翻转，没法逐条复核。
• “论文证明了 LLM 会偏爱自己”：Zheng et al. 2023 明确说数据有限、不能确定；对照实验是后来 Panickssery et al. 2024 做的。
• “GPT-4 的一致率是 65%，我的 Judge 应该差不多”：那是 2023 年的模型、MT-bench 上刻意构造的相近回答；两份回答差距大时一致率可以到 98.8%。数字随模型、prompt、题型变，要自己测。
• “评审团成员越多越好”：评审团只稀释成员之间不同的偏好；成员共有的偏差（比如都偏爱长回答）投票不会抵消。
• “Guardian 审查失败就等于判定危险”：动作都不执行，但发给 Agent 的话写明 “This is a review failure, not a determination that the action is unsafe”，分析数据的 terminal_status 也记成 FailedClosed。算误杀率时要按这个字段拆开。
• “Guardian 解析失败就放行，免得卡住用户”：相反，解析失败最多重试到 3 次，之后拒绝；只有"输入超出审查预算且没有强制 Guardian"这一种失败会交回给用户（强制的条件见 decision.rs:66-71）。

下一周转向回放评测与模型对比。