如果你的 agent 已经能连续工作二十分钟，只看最终答案很难判断它做得对不对。它可能拿错了资料、调错了工具，或者在绕了很多弯路之后碰巧给出了看起来合理的结果。
Josh Rosen 在 LLM-as-Judge Architectures: Putting Evals Into Your Agent Runtime 里指出，LLM judge 正在从离线评测工具走进 agent 运行时，开始参与控制流：决定继续、重试、换模型、补证据，还是转人工。
judge 从评分器变成决策组件
传统软件有很多确定性检查方式：schema 校验、类型检查、断言、精确比较。AI 应用产出的工作很难全部用这些方式检查：
- 工作是否足够完整，可以进入下一步？
- 回答是否真的有用？
- 研究结论是否有材料支撑？
- 生成的产物能不能进入公司知识库？
当人类原本需要看一眼再判断时，LLM judge 可以让应用自己完成一部分判断。离线评测关心「昨天那个版本是否更好」，运行时 judge 关心「现在这一步要不要继续」。位置变了，它承担的责任也变了。
七种常见模式
| 模式 | 核心做法 | 适用信号 |
|---|---|---|
| 换一个模型来判 | 一个模型做事，另一个模型根据原始请求、结果、评分标准、参考材料和期望答案，输出分数、标签或解释 | 需要稳定的离线评测或运行时质量门槛 |
| 把判断拆开 | 把「这个结果好不好」拆成是否回应请求、结论是否有证据、任务是否完成等小判断 | 单一总分会掩盖具体失败原因 |
| 成对比较代替打分 | 给 judge 两个同输入的结果，让它选更好的；随机交换顺序可以减少位置偏差 | 回归测试、方案选择、两个 agent 的结果对比 |
| 判断工作过程 | 检查检索相关性、工具选择、工具调用和工具返回，不只看最终答案 | agent 执行时间长，过程决定结果 |
| 使用多个 judge | 用不同维度、人格或投票的 judge，重点关注分歧 | 错误代价高，需要触发重试、补证据或转人工 |
| 评测 judge 本身 | 用基准测试或人类标注，定期比较 judge 与人的判断 | judge 影响关键决策，偏见或漂移会变成应用故障 |
| 用确定性逻辑包住 judge | 能确定性检查的用测试、schema、数据库或策略引擎；judge 只判断难以确定的部分 | 需要把模糊判断与硬约束分开 |
这张表概括的是架构方向。真正决定成败的，是每个判断放在哪个位置，以及错误判断会造成什么后果。
先拆分判断，再考虑多 judge
让一个 judge 回答「这个输出好不好」，信息量通常太低。一个答案可能正确但不完整，可能写得很顺但没有材料支撑，也可能 agent 绕过了不该绕过的步骤才碰巧得到正确结果。
更实用的做法是把判断拆成几个小问题：
- 回答是否回应了原始请求？
- 结论是否有提供的证据支撑？
- agent 是否完成了必须完成的工作？
- 产物是否满足下一步操作的前置条件？
G-Eval 让模型先根据评价标准生成评估步骤，再给出分数。DeepEval 的 DAG 评测把单个 LLM 判断放进更大的确定性决策图里。两者都在处理同一个问题：减少一次性模糊判断带来的不稳定性。
当需要比较两个结果时，打分往往不如成对比较。模型可能说不清 7 分和 8 分的区别，却更容易判断两个输出哪个更好。LangSmith 和 DeepEval 都支持成对评测，LangSmith 还提供随机交换输出顺序的选项，用来减少位置偏差。这个模式很适合回归测试，也适合让 agent 在多个方案之间做选择。
对于执行时间较长的 agent，只检查最终答案还不够。Phoenix 提供针对检索相关性、工具选择、工具调用、工具返回和整体 agent 表现的 evaluator；LangSmith 可以把 evaluator 用在单次 run、完整 trace 或更大的 thread 上。实际实施时可以把判断放在关键决策点：研究 agent 在综合之前先检查来源选择，编码 agent 在实现之前先检查方案，操作型 agent 在执行之前先检查证据。
不要一开始就上多个 judge 互相辩论。先从一个或两个窄判断开始，把日志、分歧和人工复核做起来，再根据错误代价决定是否增加更多 judge。
judge 也会犯错
judge 仍然是 LLM，会犯和做事模型类似的错误。它可能受答案顺序影响，可能偏爱某种写作风格，可能区分不出两个质量接近的结果，也可能更偏好像自己产出的答案。
模型评测领域已经有一些专门测试这些问题的基准：LLMBar 检查 judge 在困难条件下能否识别指令遵循，JudgeBench 提供带有客观偏好的困难回答对，RewardBench 评估奖励模型在偏好任务上的表现。Anthropic 的 Bloom 会先用人类标注的 transcript 比较多个候选 judge，再选择适合的 judge 模型，并在评测流程里加入 meta-judge 做整体分析。
应用开发者可以从更简单的版本开始：定期把 judge 的判断和人的判断放在一起比较。如果某个判断会影响重要动作，就收集这些决策样本，让人独立标注，测量 judge 在哪些地方与人分歧，再调整评分标准、模型、上下文或决策边界。
多个 judge 的价值也在这里。MAJ-EVAL 会创建代表不同评价维度的 evaluator agent，让它们讨论结果。原文对这类做法保持谨慎：目前还缺少足够证据说明应用已经在生产环境中大量采用。即使不关心三个 judge 投票 2 比 1 的结果，也应该关心它们是否出现分歧。一致可以提高信心，分歧可以触发重试、换更强模型、补充证据或转人工。
确定性逻辑仍然不可替代
一个常见的诱惑是把所有应用决策都交给 LLM judge，再让更多 agent 去监督更多 agent。这会放弃应用层最大的优势：模型之外的那套系统由我们自己控制。
如果某件事可以用代码确定性地检查，就用代码检查。格式、类型、schema、权限、预算、速率限制、状态迁移、精确匹配和必填字段，都应该由确定性逻辑处理。LLM judge 更适合判断证据是否足够、建议是否有支撑、任务是否完成、开放文本质量是否达标。
原文提到，OpenAI 的 grader 架构同时支持模型判断和确定性 grader，例如字符串检查和 Python 代码，并允许把多个 grader 组合成更大的评测。这个思路在应用内部同样适用：LLM 判断模糊部分，确定性代码决定这些判断和其他事实如何组合，再决定工作流是否继续。
| 交给 LLM judge | 交给确定性代码 |
|---|---|
| 证据是否足够 | 格式和 schema 是否合法 |
| 建议是否有支撑 | 权限和预算是否允许 |
| 任务是否完成 | 状态迁移是否有效 |
| 开放文本质量是否达标 | 精确匹配和必填字段是否满足 |
边界画得越清楚，judge 带来的收益越稳定，风险也越容易定位。
judge 进入关键路径之后
许多现有 LLM judge 位于应用执行路径之外，负责事后评分。新的架构会把 judge 放进 agent loop，甚至放进关键路径。判断结果会影响应用下一步做什么：继续、重试、路由到另一个模型、收集更多信息，或者升级给人工。
这会带来更大的价值，也会让 judge 的错误变成应用故障。一个在离线评测里稍微有点噪声的 judge，可能只是让报告不够稳定；同一个 judge 站在每个重要动作前面，可能制造循环、拦下正常的工作、放行错误的结果，还会给每次执行增加延迟。
原文的结论很直接：在把 LLM judge 放到生产关键路径之前，需要继续投入这些架构，把模式做成熟。机会很大，风险也真实存在。
一个务实的实施顺序
- 先在离线数据集上校准 judge。用人工标注比较它的判断，记录分歧最大的样本。
- 只选一个高价值判断进入运行时，例如「证据是否足够，可以进入综合或执行」。
- 在 judge 前后放确定性门槛，处理格式、权限、预算和状态。
- 记录每次判断的输入、输出、模型版本、评分标准和后续结果，方便复盘。
- 把不确定或出现分歧的情况路由到更强模型、补证据流程或人工。
- 当错误代价高且分歧频繁时，再考虑多 judge、投票或辩论。
- 定期重跑 judge 评测，防止模型更新或数据分布变化带来漂移。
LLM judge 进入运行时，真正需要设计的是判断放在哪里、谁有权决定下一步、错误会怎样被发现。Prompt 只是其中一小部分。先从一个人工愿意检查的结果开始，把 judge 放在它前面，再用确定性规则和日志把风险围住。
Aide Hub 会继续整理 agent 架构、评测和工程实践中可以复用的模式。