LLM Systems
From Model Scores to Reliable Systems: LLM Evaluation Engineering
A practical guide to turning evaluation from a benchmark score into an engineering gate.
The full English text is not available yet
This article is currently using its Chinese source. Add a matching file under content_en/writing/posts/ to enable the English version.
从“模型有多强”到“系统能否放心运行”：一篇完整的 LLM Eval 博客
本文以 Stanford CS336 Lecture 12《Evaluation》为主线，结合 Hanako 的《Eval Engineering》六步方法，以及 Xiangyi Li 整理的 eval 资源库，逐步解释大模型评估究竟在测什么、为什么经常测错，以及如何把一个分数变成真正能保护系统的工程闸门。
先从一个看似简单的问题开始：模型到底好不好
假设我们训练出了一个语言模型。它会写代码，会回答问题，也能调用工具。接下来最自然的问题是：这个模型到底好不好？
初看之下，评估似乎只是一个很机械的流程：准备一些题目，把题目交给模型，拿回答案，最后计算准确率。但真正困难的地方不在于运行模型，而在于定义“好”这个词。一个模型可以更聪明，但更贵；可以更便宜，但更容易产生幻觉；可以在考试题上得分很高，却无法处理真实用户的不完整请求；也可以回答得很有文采，却没有完成任务。
因此，评估不是训练完成后的仪式，也不是一张排行榜。评估实际上是在回答四个问题：
- 我们想让模型具备什么能力？
- 什么证据可以说明它具备了这种能力？
- 这个证据是否真的来自目标能力，而不是数据污染、评委偏好或测试漏洞？
- 得到评估结果后，系统会做出什么不同的动作？
如果前三个问题没有回答清楚，分数可能没有意义；如果第四个问题没有回答，评估就只是一个报表。Lecture 12 讨论的是评估的思想和方法，而 Hanako 的文章把这条思想推进到 Agent 工程：一个有用的 eval，最终应该能够改变系统下一步允许做什么。
一、评估不是“给模型打分”，而是把目标变成可观察的证据
1.1 从抽象目标到具体指标
“这个模型要有推理能力”是一句目标，但它不是一个可直接运行的测试。我们需要把它拆成可观察的行为。例如：
- 能否在没有见过原题的情况下完成新问题？
- 能否给出正确答案，并且中间步骤没有依赖错误前提？
- 能否在工具返回空结果时承认不知道，而不是编造答案？
- 能否在多步任务中持续推进，而不是调用工具几十次后碰巧得到一个结果？
这就是评估设计的第一步：把抽象构造（construct）转换成具体任务、评分规则和外部证据。每一次转换都会带来损失。我们可能只测到了“会做选择题”，却把它叫作“智力”；也可能只测到了“回答很像人”，却把它叫作“事实正确”。
所以一套 eval 的名称不能代替它的定义。看到“推理评估”“安全评估”“Agent 评估”这些词时，应该继续追问：输入是什么，模型要做什么，什么结果算成功，谁来判断，判断依据来自哪里？
1.2 评估会反过来塑造模型的发展
模型开发者会围绕可见的指标优化。当某个排行榜成为行业目标，训练数据、提示词、推理策略和系统架构都会向这个指标倾斜。一个指标如果只奖励答案长度，模型就可能学会写更长；如果只奖励关键词，模型就会围绕关键词组织表面文本；如果公开了全部测试题，模型甚至可能直接记住题目。
这就是评估的双重作用：它既是测量工具，也是优化目标。一个不严谨的指标不是中性的，它会把模型和团队带向错误的方向。
二、第一层评估：困惑度与语言模型本身的概率
2.1 困惑度测量的是什么
语言模型可以被看成一个在 token 序列上定义概率分布的模型。给定前面的 token，它为下一个 token 分配概率。对一段长度为 的测试文本，常见的平均负对数似然可以写成：
困惑度是它的指数形式：
直觉上，困惑度越低，说明模型给真实文本分配的概率越高。它是语言建模最自然的指标，也是训练语言模型时经常直接优化的目标。
2.2 分布内评估与分布外评估
早期语言建模研究通常在同一个数据集上划分训练集和测试集：模型在训练部分学习，再在同分布的测试部分计算困惑度。这种方式适合回答“模型是否学会了这个数据分布”，但不一定能回答“模型能否处理开放世界中的新文本”。
GPT-2 带来了另一种常见范式：模型在 WebText 上训练，然后在其他标准数据集上进行 zero-shot 评估。这是分布外评估。它试图测量模型是否学到了一些可以迁移到新数据的语言规律，而不仅是记住训练集的统计结构。
两种评估没有谁绝对更好。分布内测试更稳定、更容易解释；分布外测试更接近泛化问题，但更容易受到数据重叠和隐性污染影响。重要的是在报告结果时说清楚：模型在哪里训练，测试数据从哪里来，训练集和测试集之间是否可能存在重叠。
2.3 困惑度不是“智能”的总分
困惑度会惩罚序列中每个 token 的预测误差。对于“Stanford University was founded in 1885”这样的句子，模型能否预测出 1885 可能很有意义，但句子中一些功能词的概率变化未必对应我们真正关心的能力。困惑度把所有位置都当成同等重要，这有时会掩盖目标能力。
一种改进是条件困惑度：给模型一个提示词，只计算后续目标答案的概率。这样可以把评估重点放在我们真正想测的回答部分，而不是提示词中偶然出现的 token。
还有一类任务表面上是准确率，实际上仍然是困惑度的变体。LAMBADA 通过长上下文预测最后一个词，HellaSwag 通过多项选择完成句子；模型需要为候选答案分配概率，最后选择概率最高的选项。它们比直接在测试集上计算 PPL 更接近任务形式，但仍然主要在测试语言模型的 next-token probability。
困惑度适合回答“模型对这类文本的概率建模是否准确”，却不能独立回答“模型是否能完成开放式工作”“答案是否安全”“Agent 是否真的完成了任务”。因此，完整 eval 必须向下游行为扩展。
三、第二层评估：考试题为什么有用，又为什么不够
3.1 考试式 benchmark 的优点
多项选择题很受欢迎，是因为它有三个工程优点：题目和选项可以固定，正确答案通常明确，评分成本很低。MMLU 将这种形式扩展到多个学科，GPQA 试图使用专家设计的高难度问题，Humanity's Last Exam（HLE）则进一步增加跨学科、多模态和高难度任务。
这类 benchmark 能提供一个相对清晰的进步曲线。当模型在旧题库上接近饱和时，研究者会移除有问题的题目、增加选项数量，或设计更困难的新题。它们适合测试知识覆盖、基本推理和不同学科的任务差异。
3.2 多项选择不等于简单
有人会说多项选择题太简单，因为模型只需要选 A、B、C 或 D。但问题的难度并不由答案格式单独决定。一个选项明确、知识简单的问题确实容易；一个需要多步推理、选项都很接近的问题可能非常难。
真正的问题是，多项选择限制了我们能提出的任务类型。现实中的用户很少把需求写成四个选项。真实请求往往不完整、目标隐含、没有唯一答案，还可能需要模型调用工具并修改外部状态。
因此，考试式 benchmark 是能力地图的一部分，而不是现实使用的替代品。它可以告诉我们模型在某些结构化题目上是否进步，却不能直接告诉我们模型能否成为可靠助手。
四、第三层评估：开放式回答不能只看“像不像好答案”
4.1 Chatbot Arena 与成对比较
开放式回答没有固定字符串答案。一个用户问“我想做一份加奶酪的甜菜沙拉，哪些香草适合”，两个回答可能都合理，但表达风格不同。此时不能简单地用 exact match 评分。
Chatbot Arena 的核心做法是成对比较：让用户同时看到两个匿名模型的回答，然后选择 A 更好、B 更好、两者相近或都不好。大量成对比较可以用 ELO 等方法估计模型之间的相对排名。
成对比较的优点是它不要求人类为每个答案写出绝对分数，也不需要所有模型回答完全相同的问题。缺点也很明显：评估者是谁，提示词从哪里来，人类偏好的是事实正确、表达风格、礼貌程度，还是更像自己想听的话？成对比较可能把正确性与讨喜程度混在一起。
人类评估者提出问题时，通常知道自己想解决什么；但他们也可能因为不知道答案，无法判断哪个回答事实正确。一个更自信、更长、更会迎合用户的回答，可能比诚实但保守的回答更受欢迎。
4.2 LLM-as-a-Judge：把评委也当作被测系统
AlpacaEval、WildBench 等工作使用另一个大语言模型作为评委，判断候选回答是否更好。它比人工评估便宜、快速、容易批量运行，因此被广泛采用。
但 LLM-as-a-Judge 不是一个透明的测量仪器。评委模型有自己的偏好，可能偏爱更长的回答，也可能偏爱与自己训练分布相似的表达方式。Hanako 的文章强调了一个实用原则：候选模型和评委模型最好来自不同模型家族。同一家族可能共享相同的盲点；高风险场景还应该使用来自不同供应商的评委面板，而不是相信一个单独的分数。
文章还给出了一个更重要的边界：凡是能够客观检查的事情，就交给代码，不要交给评委模型。测试是否通过、文件是否存在、数据库状态是否发生变化、工具参数是否符合 schema，这些都有外部事实，应该优先使用确定性检查。
一个由偏置评委驱动的自动闸门，可能比没有闸门更危险，因为它会把猜测洗成数字，再依据这个数字执行动作。
五、第四层评估：从“回答正确”到“Agent 完成任务”
5.1 Agent 不只是一个更长的回答
Agent 通常由语言模型、工具、记忆、环境和控制逻辑组成。它可能先搜索资料，再读取文件，调用 API，执行代码，检查结果，最后提交一个变更。最终回答只是这条过程的最后一个节点。
因此，Agent eval 至少有三个层级：
| 层级 | 要回答的问题 | 典型证据 |
|---|---|---|
| 端到端 | 用户的任务是否真的完成 | 文件 diff、测试结果、数据库状态、业务结果 |
| 轨迹级 | Agent 采取的路径是否可靠 | 工具调用序列、重复调用、循环、失败恢复、成本 |
| 组件级 | 哪个局部组件导致失败 | 检索器、工具参数、子 Agent、规划器、验证器 |
只看最后答案，会漏掉“偶然答对”的错误路径。一个 Agent 可能先调用了错误工具，拿到空结果后编造内容，最后碰巧生成了看似合理的答案。如果只看最终文本，它可能得分很高；如果看轨迹，就能发现它根本没有可靠完成任务。
5.2 三个适合起步的 Agent 指标
Hanako 建议从三个指标开始：
- Faithfulness，忠实性：回答是否建立在工具实际返回的证据上，而不是工具返回空结果后由模型自行补全。
- Tool parameter accuracy，工具参数准确性：是否选对工具，并传入正确参数。
- Task completion，任务完成度：是否根据真实外部信号完成任务，而不是接受 Agent 自己说“我完成了”。
这三个指标分别对应内容、动作和结果。它们不能替代所有复杂评估，但能帮助我们快速区分“回答写得像”与“系统确实做成了”。
5.3 常见 Agent benchmark 的区别
SWE-bench 把代码仓库和 GitHub issue 交给 Agent，最终通过单元测试判断补丁是否有效。Terminal-Bench 把环境放进终端，要求 Agent 执行一连串命令完成任务。网络安全 benchmark 让 Agent 在隔离环境中完成夺旗或渗透测试任务。MLE-bench 则围绕数据处理、模型训练和提交结果来评估机器学习工程能力。
这些 benchmark 的共同点是：输出不是一段文本，而是环境中的状态变化。Agent 必须与真实工具和环境交互，评估器再检查任务是否完成。
但这些测试也有一个隐藏变量：Agent scaffold。相同的底层模型，配合不同的规划、记忆、重试、工具选择和上下文管理逻辑，可能得到完全不同的分数。因此报告 Agent 结果时，不能只写“使用某某模型”，还要记录 scaffold、系统提示词、工具版本、采样参数和预算。
六、评估的核心转变：从温度计到恒温器
很多团队会把评估结果放进 dashboard，然后继续运行系统。分数变化了，系统行为却没有变化。这种评估更像温度计：它告诉你现在是多少度，但不负责调节温度。
Hanako 提出的关键转变是把 eval 放进 Agent 的运行环路中，让 verdict 直接改变接下来允许做什么：
- grounding 分数不足，拒绝把结果交给下游；
- schema 校验失败，阻断这条执行边；
- 怀疑存在幻觉，把这个分支隔离，而不是让它合并进主流程；
- 只有外部验证确认完成，才能结束 Agent 运行；
- Agent 停止调用工具，只能说明它结束了当前回合，不能证明任务完成。
这就是从 thermometer 到 thermostat 的差别。评估不再是运行结束后的总结，而是系统状态机的一部分。
flowchart LR
A["Agent 产生动作"] --> B["工具与环境执行"]
B --> C["采集结果与轨迹"]
C --> D["确定性检查"]
D --> E["模型评委 / 规则评估"]
E --> F{ "verdict" }
F -->|"通过"| G["允许下一步或完成"]
F -->|"证据不足"| H["拒绝交接 / 要求补证据"]
F -->|"结构错误"| I["阻断当前执行边"]
F -->|"疑似幻觉"| J["隔离分支并升级"]
这里最重要的不是“使用了一个分数”，而是分数与动作之间存在明确映射。一个 eval 如果无法改变系统的任何决定，就应该诚实地把它称为报告，而不是安全闸门。
七、最好的测试往往已经藏在日志里
从零设计 benchmark 很有吸引力，但团队最应该先看的地方通常是已有的运行日志。因为线上失败不是抽象的想象，而是已经发生过的行为，并且带着时间、输入、工具调用和环境反馈。
可以先抽取一小组完整轨迹，让成功与失败相邻出现：
- 一次顺利完成的请求，作为“正常工作”的基线；
- 一次用户重新措辞或纠正的请求，因为用户纠正本身就是免费的错误标签；
- 一次工具返回空结果，或者同一个工具用相同参数被调用两次；
- 一次外部服务超时，用来测试 Agent 在环境拒绝服务时的行为。
对每条轨迹写四行记录：Agent 做了什么；什么成功、什么失败；原因来自 Agent 还是外部依赖；这个失败应该转化为哪项长期能力测试。
这里尤其要注意归因。相同查询被重复调用两次，是 Agent 的循环；服务返回 429，则是外部依赖的问题，除非系统的职责本来就包括限流恢复。不能把所有失败都归到模型头上，也不能把模型错误藏在基础设施问题后面。
验证器本身也必须被测试。给它一个明确正确的结果，再给它一个看起来合理但实际错误的结果。如果验证器把两者判反，坏的是 rubric 或 verifier，而不是 Agent。
每一个被转化为永久测试的失败，都会让系统少一次“第一次见到这种问题”。这比不断添加漂亮但脱离真实流量的测试集更有效。
八、评委、rubric 和版本必须固定
评委其实也是软件。评委模型、系统提示词、rubric、采样温度和解析器都会影响最终分数。如果评委悄悄升级，升级前后的数字就不再可直接比较。
因此，每次评估至少要记录：
- 评委模型及其版本；
- 系统提示词和完整 rubric；
- temperature、top-p、最大输出长度等采样参数；
- 被评估模型、工具和 scaffold 的版本；
- 测试集版本、随机种子和运行时间；
- 原始输入、输出、轨迹和 verifier 结果。
Rubric 应尽量写成可观察结果，而不是一篮子模糊的代理分数。例如，不要写“回答看起来专业、详细、可信”；更好的写法是“只有当外部记录中存在该字段，并且答案与记录一致时才通过”。
也不要奖励答案的形状：长度、关键词出现次数、引用数量、与参考答案的表面相似度，都可能被模型优化成空壳。只要针对评委优化得足够用力，Agent 就会学会“看起来正确”，而不是“实际上正确”。这就是 Goodhart 定律在模型评估中的表现。
同样要谨慎对待 self-review。让模型在没有外部证据的情况下检查并修改自己的回答，并不能稳定地提高质量，有时还会把原本正确的回答改坏。可靠的校验信号必须来自模型之外：代码、数据库、测试、记录、环境状态，或者明确授权的人类。
九、按爆炸半径设闸门，而不是按模型自信度放行
很多系统会先计算一个 confidence score，然后设定阈值：分数高就自动通过，分数低就交给人。这个设计的问题是，confidence 通常是最容易被模型影响的变量；真正重要的是，如果这次变更错了，代价有多大。
可以按照“错误的爆炸半径”分成三条通道：
| 通道 | 例子 | 适合的闸门 |
|---|---|---|
| 可逆且影响范围小 | 文案修改、单个测试、带覆盖率的孤立函数 | 先通过确定性检查，再逐步开放自动合并 |
| 可逆但影响范围广 | 共享工具、schema 增加、多个调用方依赖的公共函数 | 确定性检查 + 干净的轨迹 + 历史回滚记录 |
| 难以逆转 | 数据迁移、删除操作、写生产数据、资金流转 | 不论模型信心多高，都不应直接自动放行 |
在允许自动放行的通道内，证据优先级可以是：确定性测试、类型和 schema 检查、沙箱执行；然后是当前 Agent 版本的轨迹评估；再然后是该 Agent 在同一业务表面上的历史回滚率。Agent 自己的“我认为已经完成”应该是权重最低的输入，因为这是它最容易影响的一项。
上线时先运行 shadow mode：评估器对每次变更进行打分，但不真正合并。观察足够多的真实流量后，再比较评估器与人工审核的分歧率。如果分歧仍然明显，闸门应继续保持关闭。
需要特别警惕“全绿”假象。测试可能逐渐收敛到测试本身，而不是产品规范。全绿是证据，不是证明。
十、纯推理、安全与现实世界有效性
10.1 纯推理 benchmark 的边界
ARC-AGI 等 benchmark 试图把推理能力与世界知识分开。任务往往要求模型从图形或新环境中发现规则，而不是回忆训练语料中的事实。它们有助于思考“模型到底是在记忆，还是在推理”。
但完全把知识和推理解耦并不容易。现实问题通常同时依赖事实、语言理解、规划和行动。只要某个 benchmark 被反复研究，它也可能变成新的训练目标。因此“纯推理”应该被理解为一种实验设计，而不是一个已经彻底解决的概念。
10.2 安全不是一个单一标签
HarmBench 等工作会测试模型是否拒绝有害请求；AIR-Bench 则从政策和监管框架出发，尝试建立更全面的风险分类。安全问题包括幻觉、网络攻击、犯罪协助、阿谀奉承、隐私泄露、偏见和批判性思维退化等。
安全还高度依赖上下文。在隔离沙箱里执行安全研究的 Agent，可能是防御工具；同样的能力用于真实系统，就可能变成攻击工具。因此安全 eval 不能只问“模型是否拒答”，还要问：它在什么环境中获得了什么工具，动作会影响谁，失败是否可逆，是否有人工升级路径。
10.3 生态有效性：测试是否像真实工作
考试题容易评分，却离现实使用很远。Chatbot Arena 有真实用户，但用户分布未必代表产品目标人群。GDPVal 一类工作让不同职业的专业人士设计任务，临床评估让医生提供真实医疗工作场景；这类方法试图从单个问题进一步走向“一个职业或一个用例中的完整任务”。
现实性和隐私之间也有冲突。最有价值的测试可能来自真实查询流，但真实查询包含个人信息、商业秘密和敏感数据。使用真实日志时，应先做最小化、脱敏、权限控制和审计；不能因为 eval 的名义就把用户数据直接搬进测试集。
十一、污染、数据泄漏与 benchmark 的有效期
基础模型通常在互联网数据上训练，而公开 benchmark 也可能出现在互联网上。此时我们很难确定模型是否“做过这道题”。污染不一定是题目原文直接出现在训练集里：题目可能来自另一个网页、答案可能出现在讲解中、数据也可能被改写后重复传播。
常见的应对策略包括：
- 报告训练数据与测试数据的重叠检查，而不是只报告最终分数。
- 使用模型训练截止日期之后新产生的网页、代码仓库或论文建立 fresh eval。
- 使用企业内部代码、个人未公开写作或其他不在互联网公开传播的数据建立 private eval。
- 对 benchmark 本身做审计：检查题目是否有歧义、答案是否真的唯一、单元测试是否覆盖完整。
- 用不同时间、不同来源的测试集复验，避免把一次排行榜结果当成稳定能力。
新鲜数据也不是万能的。GitHub 上今天发布的代码可能是从旧仓库派生的；时间戳只能提供线索，不能自动证明模型没见过。最可靠的做法，是把新鲜数据、私有数据、外部验证和行为轨迹结合起来。
十二、从“报告分数”到“工程闸门”的完整流程
把前面的内容压缩成一个实际工作流，可以按下面顺序做：
第一步：写清楚目标和失败代价
先决定你是在做模型选择、研究比较、产品上线、政策审计，还是 Agent 运行时保护。不同目标需要不同评估。再把错误按爆炸半径分类，决定哪些动作可以自动放行，哪些必须人工确认。
第二步：选择多层信号
不要只选一个总分。至少同时收集：端到端结果、轨迹、组件状态、确定性测试、成本、延迟、失败恢复和人工反馈。能用代码判断的，就不要先交给 LLM 评委。
第三步：从真实轨迹挖出第一版测试集
同时挑选成功样本、用户纠正样本、工具空结果、重复调用、超时和权限失败。每条样本记录预期行为、可观察证据、失败归因和对应保护能力。
第四步：固定版本并验证评估器
固定模型、评委、prompt、rubric、数据集、工具和随机种子。给 verifier 投喂明确正确和明显错误的样本，确认它不会把两者判反。对于开放式回答，使用不同模型家族的评委面板，并报告分歧，而不是只给平均数。
第五步：让 verdict 驱动状态机
低 grounding 不能只是分数下降，而应拒绝交接；schema 错误不能只是记录日志，而应阻断执行边；疑似幻觉不能只是标红，而应隔离分支；没有外部完成信号，Agent 不能自行宣称任务完成。
第六步：shadow、回放、逐步放开
先在 shadow mode 中运行，比较评估器与人工判断的分歧。再从低爆炸半径通道开始自动放行，持续记录回滚、投诉和漏检。任何一次线上失败，只要能复现，就应该转化成长期回归测试。
十三、如何判断一个 eval 真的有用
一个评估系统至少应该满足以下标准：
- 目标相关：分数变化确实对应你想优化的能力，而不是容易替代的表面特征。
- 证据外部化：答案、轨迹和状态有来自模型外部的可核验依据。
- 可重复：固定版本和参数后，重复运行不会产生无法解释的巨大波动。
- 可诊断：失败后能指出是模型、工具、检索、规划、环境还是评委出了问题。
- 可行动：评估结果会改变下一步动作、工具权限、人工升级或发布决策。
- 抗优化：模型很难仅靠变长、复述关键词、伪造引用或迎合评委提高分数。
- 有生命周期：测试集会更新，评估器会版本化，旧分数不会被假装成永恒真理。
如果一个指标不能告诉你下一步怎么改，也不能改变系统应该做什么，那么它仍然可能有研究价值，但不应该被包装成生产闸门。
十四、X 上两份材料给出的统一方法论
Hanako 的六步文章可以浓缩成三句话：
- 评估路径，不只评估答案。 Agent 是否通过了正确、短、可解释的路径，比最后一次偶然得到正确字符串更重要。
- 评估必须改变运行。 verdict 如果不会拒绝交接、阻断动作、隔离分支或升级人工，就只是报告。
- 把失败变成永久测试。 日志中的真实失败应该成为下一次发布不能再次犯的错误。
Xiangyi Li 整理的资源库则提醒我们，eval 不是一项孤立技术。它同时涉及评委偏差、Agent 基础设施、验证器设计、benchmark 构造、数据污染、成本、模型开发与应用开发的区别，以及 benchmark 在 Agent 时代为什么会失效。下面的资源可以作为进一步阅读路线：
这些材料不是一张“必做题库”，而是一张问题地图。阅读它们时，最好始终带着同一个问题：这个方法究竟提供了什么证据？它的 verifier 从哪里来？模型能否针对这个评分器进行优化？测试通过后，系统会获得什么权限？
结语：评估的终点不是信任模型，而是让“信任”不再是唯一问题
Lecture 12 从困惑度开始，逐步走向考试、聊天偏好、LLM-as-a-Judge、Agent、推理、安全、现实性和污染。它展示了一个清晰的事实：不存在一个能统治所有场景的唯一评估。
困惑度告诉我们模型如何建模文本分布；考试 benchmark 告诉我们模型能否在结构化题目上回答；聊天评估告诉我们人类如何偏好回答；Agent eval 告诉我们系统能否在环境中完成任务；安全 eval 告诉我们能力在不同上下文中会带来什么风险。它们测量的是不同对象，不能被一个总分替代。
而 X 上的 Eval Engineering 方法把问题推进了一步：真正可靠的 eval 不应停在分数上。它应该看证据、看路径、看爆炸半径，并把 verdict 接入系统的状态机。最后留下来的不是“模型看起来很自信”，而是一组约束：哪些结果可以自动合并，哪些动作必须隔离，哪些失败会升级给人，哪些错误一旦发生就会变成永久测试。
模型本身会变化，评委会变化，数据会变化，产品目标也会变化。唯一能长期保留下来的，不是某个排行榜上的数字，而是我们是否建立了一套能够发现错误、解释错误、阻止错误重复发生的评估系统。
来源与说明
- 课程主线：Stanford CS336 Lecture 12: Evaluation。本文对应的中文逐字稿和英文逐字稿。
- Eval Engineering：Hanako 的 X 帖子。文章内容是一套六步的 Agent 评估闸门方法；其中的具体 benchmark 数字和行业判断按原帖作为观点引用，未在本文中独立复核。
- Eval 资源库：Xiangyi Li 的 X 帖子。资源列表与推荐主题依据原帖配图整理，具体文章请以原作者页面为准。
本文的组织方式是：以课程逐字稿解释评估对象的扩展，再用两份 X 材料补充 Agent 评估工程。正文不是三份材料的逐句拼接，也不是对任何 benchmark 的排行榜复述。