验收一个导出功能时，我们通常会检查：文件能否生成，字段和数据是否正确，格式是否符合要求。
把任务换成“让Agent整理会议纪要”，验收就多了一些判断。决定有没有遗漏，原话有没有被误解，待办能否看清动作和负责人，都需要核对。两份措辞不同的纪要，也可能同样合格。
熟悉软件交付的人，其实已经有了理解Agent评测的基础。难点在于，任务中的一部分内容和决策开始由模型生成。系统可能选择不同的动作，也可能给出不同的合理答案，验收需要覆盖这些变化。
Eval，也就是Evaluation，指的便是这套依据标准和证据、评价Agent实际表现的工作。从软件测试、日志排查和回归验证这些熟悉的事情出发，可以更容易地理解它。
从软件测试理解Eval
软件测试与Agent评测有共同的目标：检查系统表现是否符合要求，为验收、发布和改进提供依据。
功能测试、接口测试、权限测试、性能测试，在Agent系统中都继续需要。工具接口返回错误、文件写入失败、权限配置不正确，这些问题仍然可以用已有的工程方法检查。
Agent增加了一层任务表现的评价。
例如，整理纪要涉及理解内容、识别决定、提取待办和组织表达。即使每个工具都调用成功，纪要也可能漏掉一项关键决定。相反，两次执行使用了不同的表达或步骤，也不一定意味着其中一次有问题。
因此，评价范围需要从局部功能，扩展到整个任务的完成情况。
| 熟悉的测试工作 | 在Agent任务中继续展开 |
|---|---|
| 定义业务验收条件 | 明确任务成功、交付质量和必须遵守的约束 |
| 检查流程及异常分支 | 评价Agent选择的动作、工具和停止时机 |
| 对照预期结果 | 核验事实与业务状态，允许多种合理答案 |
| 回归与可靠性验证 | 使用代表性样本和必要的重复运行观察稳定性 |
这个区别也不能绝对化。传统软件测试同样会处理不确定性，也包含人工探索和业务判断；Agent评测同样有明确、可自动检查的条件。两类工作有大量交集。
一次完整的Eval，至少需要说明评价对象、判断标准和证据。它可以给出通过与否、分项评分、问题分布，也可以说明证据不足、暂时无法判断。
评分是表达结论的一种方式，评测的用途还包括质量验收、版本比较和改进定位。只有一个总分，通常不足以解释改动发生在哪些方面。
一次演示成功，也只能说明那次执行的表现。要了解系统的能力范围，还需要观察不同输入、约束和环境中的任务表现。
评价对象扩大到了整个任务系统
传统机器学习模型常关注分类、预测等任务的表现。到了大模型，还需要评价理解、推理、生成和指令遵循等能力。
Agent进一步把模型放入一个可以执行动作的系统：接收目标，使用上下文，选择工具，与外部环境交互，处理返回结果，直到完成交付或停止执行。
这里评价的对象已经包含模型、指令、工具、上下文和执行环境。模型能力较强，但工具返回错误、规则之间存在冲突，或者上下文丢失关键条件，最终任务仍可能失败。
模型评测帮助选择基础能力，Agent评测则验证这些能力在任务系统中的发挥。两者都需要，不能用前者的成绩直接替代后者的交付结论。
对完整任务，可以从四个角度检查。
结果关注实际交付。目标有没有达成，内容是否正确，产物是否可用，都需要结合任务标准判断。Agent回复“工单已创建”，还需要核实业务系统中确实存在这张工单，并检查其字段和关联对象。
过程关注执行行为。工具选择、参数、动作顺序和必要校验，会影响结果与可重复性。过程评价并不要求所有任务走同一条路径，不同路径可以同样合理。
效率关注完成任务的代价。耗时、执行步数、Token消耗，以及单次成功任务成本，都可以成为指标。比较时需要保留相同的质量要求；提前失败虽然耗时更短，却不能据此判为更高效。
风险关注必须遵守的约束。权限、用户授权和业务规则，会限定系统可以执行的动作。少走几步、少花一些成本，不能抵消越权或误操作。
这四个角度相互关联。同一个参数错误，可能同时影响结果、过程和效率，也不适合简单平均后得出一个看似漂亮的分数。
最终回复、实际交付物和环境状态，需要分别核实。工具调用成功，也不能直接算作整项任务成功。报告成功率时，应说明分母是任务、执行次数还是工具调用次数。
日志、告警、质量判断和归因各有职责
在常见的软件排查中，日志记录调用细节，告警提示运行异常，验收检查功能表现，排查继续验证问题原因。理解Agent的观测、监控、评测和归因，也可以从这些职责入手。
观测负责记录和呈现执行证据。例如模型输入输出、工具参数与返回、耗时、中间产物和最终状态。
Trace可以理解为一份关联起来的执行记录。它将一次任务中的步骤与调用联系起来，方便还原发生过的活动。但记录能支持到什么程度，取决于实际采集范围，它不会天然包含全部业务事实或模型内部思维。
监控负责持续跟踪运行变化。失败率、超时、延迟、Token消耗异常，都可以成为需要关注的信号。
评测负责依据标准判断质量。调用正常、没有触发告警，只能说明相应的运行指标没有异常。任务内容是否正确、交付是否可用，还需要检查。
归因负责进一步分析并验证原因。Trace中某个工具节点耗时较长，可以帮助定位等待发生的位置；要认定工具端故障，还需要结合相关记录验证，不能从一个耗时现象直接跳到原因结论。
这几项工作会共享数据，但不会相互替代。有日志不等于已经形成质量判断，有失败样本也不等于已经查明原因。
当记录缺失、内容截断或业务状态尚未核实时，应保留结论的限制。证据不足既不能默认通过，也不适合直接认定根因。
从业务要求写出可以执行的标准
有了证据，还需要一把合适的“尺子”。这把尺子首先取决于业务目标。
如果引入Agent是为了缩短材料整理时间，单看生成速度就容易偏离目标。交付可用率、遗漏情况和人工返工时间，也会影响一项工作最终花了多久。
可以把指标联系分成三个层次：业务层明确预期价值，Agent任务层检查交付表现，模型层检查基础能力。
模型分数提高、任务质量提高和业务收益提高，是需要分别验证的事情。任务层指标承担连接作用，使团队能够解释基础能力的变化怎样影响实际工作。
接下来，要把要求细化到可以执行的程度。
Metric通常用来描述需要衡量的属性或结果，例如事实正确性、完整性或任务成功率。Rubric进一步说明具体检查条件与判定方法，可以类比测试中的检查项和验收细则。不同团队对两者的颗粒度划分可能不同，使用时要先对齐含义。
“纪要写得好”就很难直接执行。把它拆开，可以得到几项更明确的条件：
- 决定与待办区分清楚。
- 每条待办包含可以辨识的动作。
- 原文已经明确的负责人被准确保留。
- 原文没有明确的负责人标记为“待确认”，不自行编造姓名。
最后一项尤其容易在验收中被误解。如果标准要求所有待办都必须有一个具体负责人，评判者就可能奖励看似完整、实际编造的内容。写清条件时，需要同时检查它与真实业务要求是否一致。
判断依据与执行方式要分开
客观评测侧重明确规则、可核对的事实或参考结果，例如格式、数值和权限约束。主观评测侧重需要业务判断和质量权衡的内容，例如解释是否清楚、论证是否充分、建议是否适用。
主观判断同样需要准则和证据。它与“凭感觉”不能混为一谈。
人工、规则和模型判分，描述的则是由谁执行判断。客观条件可以由人工检查，主观质量也可以由模型辅助评价，这与前面的分类是两个维度。
明确、可编码的条件可以交给规则。复杂质量通常需要业务人员先定义标准、处理分歧，再把经过验证的部分逐步自动化。
让大模型按准则评价回答或执行记录，通常称为LLM-as-a-Judge，也就是让模型担任辅助评判者。它可以帮助扩大覆盖，但自动化程度不代表可靠程度，仍需要校准。
标准需要在人与人、人与机器之间校准
人人对齐，可以从同一批样本的独立评价开始。先让不同评判者分别判断，再复核分歧，明确规则中的模糊表述和边界条件。修订后重新检查，才能验证标准是否更容易一致执行。
人机对齐，则使用人工复核过的样本，检查自动判分的误判、漏判和适用范围。修改规则或模型评判提示后，同样需要重新验证。
适合明确判定的条件，可以采用“通过、不通过、无法判断”。无法判断应注明缺少的证据或存在的歧义。需要权衡的质量，也可以使用有清晰分档说明的评分，不必把所有项目强行二元化。
一致性与有效性需要分别检查。所有人都给出相同结论，只说明判断较一致；如果验收标准偏离了实际目标，大家仍可能一致地判断错误。
离线评测验证变更，在线反馈补充真实情况
标准和样本准备好之后，评测需要进入具体的研发与使用过程。
离线评测常用于版本比较与回归：固定任务样本、评价标准，并尽可能保持执行环境一致，让版本变化具有可解释的对照。
模型、提示词、Skill、知识库或流程发生变化时，都可以检查是否改善了目标能力，以及是否影响原来已经做好的部分。
执行环境也属于对比条件。工具版本、权限、数据、预置文件和上下文变化，都可能改变结果。如果新版本运行在另一套条件中，分数差异就不能简单归到版本变更上。
对随机性较强的任务，还可以通过重复运行观察结果分布，避免仅凭一次成功判断系统已经稳定。任务范围与执行次数的统计口径也需要保持一致。
离线评测能减少已覆盖场景的退化风险，但评测集总有边界。真实使用会出现新的任务、表达和环境变化，因此还需要在线反馈。
常见的在线评测手段有三种，各自承担不同工作。
A/B实验在可比的真实用户或流量中比较版本，观察质量和业务效果，通常通过随机分组减少其他差异的影响。
影子模式让新版本使用真实输入并行执行，但不直接替代用户正在使用的结果。涉及外部写入时，需要隔离其副作用，避免一次真实任务被重复执行。
巡检对代表性任务或执行记录进行周期性检查，持续观察核心能力的质量。
在线监控则持续关注失败、超时、延迟、消耗及任务类型分布。它们有助于发现运行异常和使用结构变化，但其中很多指标仍只是质量线索。
巡检会同时具有评测和监控属性：按成功标准检查任务，属于质量判断；持续记录变化、发出异常信号，则具有监控属性。两项工作可以共享结果，不必强行划成互斥类别。
“离线”和“在线”主要体现使用背景与决策用途，不以是否联网、是否即时计算分数作为区别。离线评测可以调用在线服务，线上记录也可以在稍后评价。
用户的点赞、复制或重试，可以帮助筛选值得检查的样本，但不能直接当作质量标签。复制可能是为了继续修改，重试也可能只是想换一种表达，仍要回到任务和证据中核实。
一次问题分析，可以带来两种改进
评测结果最终需要回到具体工作中。发现任务失败后，一条路径是改进Agent，另一条路径是改进评价它的体系。
Agent迭代包括修改指令、工具、Skill、模型选择或上下文处理。修改后先回归，再结合真实运行验证效果，同时关注改善和退化。
评测体系迭代则检查漏测与误判：补充代表性样本，修订Metric和Rubric，重新验证判断是否符合实际目标。
可以类比一次测试失败。排查时既需要检查程序，也需要核对测试预期。如果测试用例把业务允许的情况判成错误，就应该修正验收规则，而不是让程序迎合错误预期。
同一次分析可能同时发现执行缺陷和标准缺口，两条改进路径并不互斥。
它们共享的长期资产，是可以反复使用的评测任务与判断标准。一个任务通常需要保留输入、约束、执行前提，以及参考结果或预期行为。多步骤任务还可能涉及必要动作、交付物和最终环境状态，不能只留一份参考答案。
| 样本集合 | 主要用途 |
|---|---|
| 黄金集 | 明确团队认可的交付水平，提供基准 |
| 错题集 | 保留已发现的问题，检查修复并防止复发 |
| 挑战集 | 探索复杂情况和能力边界 |
端到端评测关注整项任务的交付，过程评测关注特定步骤或模块。两者都可以维护不同用途的样本集合，不能把黄金集等用途分类，与端到端、过程等评价范围混为一谈。
这两条改进路径也称为迭代循环（Loop）。一次任务内反复进行的判断、调用、观察与继续或停止，则属于执行循环，两者含义不同。
从核心任务开始，让评测参与实际改进
把前面的工作放在一起，可以得到四个相互配合的职责模块：离线评测检查变更，在线评测与监控提供真实反馈，样本挖掘与归因连接问题和改进，观测基建为这些工作提供证据。
这是一种组织职责的框架，不是必须顺序完成的四道工序。平台的栏目名称可能不同，团队需要核对的是相应工作有没有人承担、产出能否连接起来。
只有看板、评分字段和评测集，还不足以证明闭环已经运转。线上出现的新问题，需要有人分析，再进入修复或样本更新，随后通过回归和线上反馈验证。
起步时可以选择高频核心任务，先写清少量关键标准，保留必要记录，收集正向和负向样本。正向样本帮助明确做到什么程度算合格，负向样本帮助识别缺陷与能力边界。
样本可以来自用户反馈、异常信号和规则筛选，也需要通过真实运行的采样，检查尚未被已有规则想到的问题。
一个基本工作过程包括采集任务和证据、整理上下文、按标准评价、质检判断结果，再分析原因并安排改进。
质检检查的是评测本身：抽查判定依据、复核人员或模型之间的分歧，确认标准得到一致执行、结论有证据支持。证据暂时不足的地方，保留待验证假设，继续补充信息。
业务与产品明确成功标准，运营提供真实反馈，测试组织判断与回归，研发补齐记录并实施修复。相关角色共同维护标准和样本，评测才会成为交付工作的一部分。
美团的评测文章中有一段判断，适合作为建设节奏的提醒：
Agent评测是一门实践科学，起步阶段“让数据飞轮高效运转起来”的意义，远大于“设计一个复杂精妙的评测体系”。
对于刚开始建设评测的团队，可以先把一项核心任务的成功条件写清楚，收集一批带有上下文的样本，完成一次判断、修复和回归。等到真实问题暴露新的缺口，再扩充指标、样本和自动化能力。