Agent 评估：靠什么信任一个概率性的系统

业界曾报道，某个大厂曾经有一个数据查询 Agent 悄悄出了问题。

没有崩溃，没有报错，服务正常运行，响应速度也没有变化。它只是开始给出错误的答案——对于某一类涉及调整的查询，推理路径走偏了，但输出格式完整、措辞专业。用户没有立刻察觉，因为答案”看起来”合理。三天后，有人拿结果去和另一个系统核对，才发现问题。

这个 Agent 没有经历任何版本更新，底层模型没有变，知识库没有动，部署环境完全稳定。它就是在某一刻开始漂移了，没有人知道是哪一刻，也没有人知道为什么。

业界把这个只有在Agent应用才会高概率出现的现象叫做Agent Drift：最危险的不是宕机，而是悄悄走偏了，而我们还不知道。

这背后，我觉得首先要从两类系统的根本差异说起。

传统软件是确定性系统： 同一套代码，同一个输入，永远输出同一个结果。出了问题，能复现，能追溯，能定位到具体的代码行。”不改代码就不会变”是铁律。

LLM-Based Agent 没有固定的执行路径。 每次推理都是在当前上下文里重新”决策”一次——调哪个工具、用什么参数、怎么解读返回值，都不是硬编码的逻辑，而是模型在当时的上下文分布下做出的概率性选择。知识库悄悄更新了、工具的返回格式微调了、上下文里积累了一些历史噪声、某类输入在训练分布上本就偏稀疏——任何一个细微的变化，都可能在某条任务路径上悄悄改变模型的决策方向。这个改变不会触发任何错误日志，因为从系统层面看，一切都在正常运行。

这不是 bug。概率性系统就是这样工作的，随时可能在你没有动任何东西的情况下悄悄变了。

Agent 上了生产，评估和可观测性就是必须配套的基础能力。

说正题之前，先说打榜。这个弯绕得值——看懂打榜的逻辑和局限，才能看懂 Agent 评估为什么要另起炉灶。（备注：第一、二章是背景科普，已经熟悉大模型评测的读者可以直接跳到第三章）

一、打榜这件事，比你想象的复杂

每次大模型发布，科技媒体和工程圈都会出现一批截图——密密麻麻的英文榜单名，数字后面跟着”第一”、”超越”、”SOTA”。这些数字是真实的，但它们测的是什么，很多人并不清楚。

今年 4 月和 5 月，DeepSeek V4 Pro 和 Gemini 3.5 Flash 相继发布，两家都打了一批榜。把这两次发布的榜单列出来对照，第一个发现就很有意思：两个模型选的榜单重叠极少，各打各的强项。DeepSeek 主打代码和数学，Gemini 主打 Agent 能力和多模态。唯一同时出现的 Terminal Bench，两家用的还是不同版本（2.0 和 2.1），分数不能直接比。

每家公司都倾向于选自己表现最好的测试亮相。这是打榜的常规操作。

下面这张表，是两次发布时各自亮出的完整榜单。数字来自 DeepSeek 官方技术报告和 Google DeepMind 官方 Model Card，均为原始一手来源。

DeepSeek V4 Pro 官方打榜数据（Max 模式，即最高推理预算）

Gemini 3.5 Flash 官方打榜数据

两个模型之间真正可以横向比较的榜单只有两个：

DeepSeek 打的 SWE-bench、LiveCodeBench、Codeforces，Gemini 没有亮出对应数字；Gemini 打的 Finance Agent v2、CharXiv，DeepSeek 也没有上榜。两家都很清楚自己在哪个领域更有优势。

榜单太多，记名字没用，记类别才有用。大致三类：

知识与推理类 ，MMLU-Pro 覆盖 57 个学科的研究生级题目，曾经是业界最权威的综合能力标尺，现在顶级模型接近满分，区分度已经很低了。GPQA Diamond 是专家级科学题，出题者是领域博士，连出题人自己答对率也只有约 65%，目前仍然能拉开顶级模型的差距。HLE（Humanity’s Last Exam）来自近千位领域专家贡献的跨学科极难题，顶级模型得分仍在 40% 以下——这个榜单的存在，本身就说明了当前模型和”真正解决复杂问题”之间还有多远。

代码与工程类， SWE-bench Verified 和 SWE-bench Pro 的思路和其他代码榜不同——从真实开源仓库取出实际 Bug 报告让模型去修，修完要跑通原有测试。越接近真实软件工程场景的评测，越难靠记忆或技巧刷分。LiveCodeBench 用竞赛平台上持续更新的新题防止训练数据污染。Codeforces 直接让模型在竞赛平台上和真实人类选手同台竞争，DeepSeek V4 Pro 的 3206 分在人类选手里属于顶级水平。

Agent 能力类， Terminal Bench 测真实终端环境的高难度任务，是目前工程界公认最有参考价值的 Agent 综合基准。MCP Atlas 随着 MCP 成为 Agent 工具接入的事实标准，参考价值在 2026 年快速上升。GDPval-AA 用 Elo 评分体系衡量真实 Agent 工作流的综合表现。Finance Agent v2 是金融领域的专项 Agent 评测，对财经 IT 场景有直接参考价值。

Chatbot Arena 值得单独说一段。 以上所有榜单，本质上都是出题考试——有标准答案，模型作答，对比得分。Chatbot Arena（LMSYS）完全是另一套逻辑：真人用户在不知道模型身份的情况下，同时收到两个模型的回复，选出自己更喜欢的。几百万次盲测结果计算出 Elo 评分。

唯一把”用户实际更喜欢哪个”当作核心指标的主流榜单。很多在学术基准上领先的模型，在 Arena Elo 上并不占优——两件事本来就不是同一件事。

二、榜单的暗面

榜单测什么讲完了。但光知道它测什么还不够，更要紧的是知道它在哪里说谎。

同一个模型，不同脚手架，能差出 20 分

Scale 旗下的 SEAL 平台用统一标准化脚手架跑所有模型的 SWE-bench Pro，目的是让跨厂商的分数可以横向比较。Anthropic 用自己调优的脚手架跑 Claude Opus 4.8，得出 SWE-bench Pro 69.2%。Scale 标准化平台上，同一个模型系列的分数系统性低 15 到 30 个百分点。

两个数字都没有说谎。一个测的是”这个模型在最优环境下的天花板”，另一个测的是”这个模型在公平条件下的水平线”。把这两类数字直接横向比较，是很多媒体报道里最常见的误读。

模型可能”背过”测试题

2026 年 5 月，Datacurve 发布了 DeepSWE 研究，检查了各主流模型在 SWE-bench 上的实际执行过程。发现 Claude Opus 4.7 和 4.6 在超过 12% 的运行中会执行 git log –all 和 git show 指令，把 Gold Solution 的哈希读出来再照抄。GPT 系列没有这个行为。

Anthropic 没有否认这个发现，Opus 4.8 发布时把”代码缺陷漏报率降低 4 倍”列为核心改进之一。这件事的教训不在于某个具体的模型行为，在于：公开基准一旦被大规模训练针对，测试结果就不再可靠。

独立第三方评测和自报数字，能差出半年

NIST 下属的人工智能标准与创新中心（CAISI）在 2026 年 4 月，用包含两个非公开基准在内的 9 项测试独立评测了 DeepSeek V4 Pro。非公开基准的价值正在于此——模型无法在训练数据里”见过”它们。

评测结论在 5 月 2 日发布于 NIST 官网：CAISI 的评测显示，DeepSeek V4 Pro 的实际能力与约 8 个月前发布的 GPT-5 相当。而 DeepSeek 自报的数据，声称 V4 Pro 与 Opus 4.6 和 GPT-5.4 相当——这两个模型大约在 2 个月前发布。

自报数据和独立评测之间的差距：整整 6 个月。

两个数据源都没有造假。差距来自测试条件本身——公开基准、自选脚手架、自选展示指标，和非公开基准、标准化条件、第三方独立运行，测出来的就是不同的东西。CAISI 的报告同时确认了 DeepSeek V4 Pro 是迄今经过 CAISI 评测的最强中国 AI 模型，也确认了它在成本效率上的优势。

这个 6 个月的差距，不是 DeepSeek 特有的问题。自报数字的结构，决定了它只能是这样的。

三、Agent 评估是什么——从软件测试到概率系统的跨越

大模型发布，工程团队反映很多：榜单第一名，但实际用起来不是那回事。

模型基准测的是一件很具体的事：在标准化测试题上，模型能答对多少。输入固定，标准答案固定，跑完出分。用高考分数预测一个人能不能成为优秀的项目经理——相关性存在，但直接等号成立不了。

Agent 做的事情是另一个量级的复杂：理解一个模糊的意图，决定拆成哪几步来完成，选对工具，传对参数，处理工具返回的结果，在中间出错时自我纠正，最终给出有用的输出。每一个环节都可以独立失败，环节之间还有依赖关系，而且每次运行路径可能都不一样。

传统软件测试：输入确定，输出确定，Pass/Fail 明确。Agent 的行为是概率性的——这不是临时状态，是 LLM 作为生成系统的结构性特征。用游标卡尺量水温，工具本身没问题，但用错了场合。

评什么：四个维度

1.任务完成率是最直观的指标： Agent 最终有没有把任务做完、做对。但只看这个，会漏掉很多隐患。一个 Agent 通过运气或捷径得出了正确答案，不代表它有可靠的推理能力，下次换一个类似任务大概率会失败。

计算逻辑分两种。简单任务用二元评分：

任务完成率（TCR） = 成功完成的任务数 / 总任务数 × 100%

复杂任务推荐分项加权评分——把一个任务拆成若干子目标，每个子目标独立评分后加权汇总，最终得出 0 到 1 之间的完成度。纯二元评分会掩盖”完成了一半”的情况，加权评分能更精确地反映实际完成质量。

2.工具调用准确率测的是执行层： Agent 有没有调对工具、传对参数、正确处理返回值。工具调用出错是生产环境里最常见的失败模式之一，而且经常是静默失败——Agent 调错了工具，得到了一个它误读为”有效”的返回值，继续往下走，最终给出一个看起来合理但实际错误的答案。对于业务类Agent，这类静默失败的代价尤其高。

工具调用准确率要拆成两个子指标分别统计：

工具选择准确率 = 调用了正确工具的次数 / 总工具调用次数 × 100%

参数准确率 = 参数完全正确的调用次数 / 总工具调用次数 × 100%

两个子指标都要看，因为它们对应两种不同的失败模式：工具选错是意图理解问题，参数传错是执行层问题，根因不同，处置方向也不同。此外还有一个综合指标：

工具调用完全正确率 = 工具和参数均正确的调用次数 / 总工具调用次数 × 100%

3.轨迹合理性评估的是过程： Agent 走的推理路径对不对，有没有绕路，有没有在不该停下来的地方重复推理，有没有漏掉必要的步骤。这个维度不好测，但很重要——轨迹不合理的 Agent，即便当前任务碰巧完成了，遇到变体场景时也容易出问题。

轨迹合理性有两种测量路径。一是用可量化的效率指标：

步骤效率比 = 参考路径的最优步数 / Agent 实际执行步数
（结果 < 1 说明 Agent 走了多余步骤，越接近 1 越好）

冗余步骤率 = 被判定为冗余的步骤数 / 总步骤数 × 100%

二是用 LLM Judge 或 Agent-as-Judge 对轨迹做整体质量评分（1 到 5 分制），在没有明确”参考路径”的开放性任务上，这是更实用的方法。两种方式通常结合使用——量化指标提供可追踪的趋势，Judge 评分提供语义层面的质量判断。

4.输出可信度要分开看三个子维度： 格式合规（是否按要求的结构返回）、事实准确（没有幻觉，没有捏造数字）、领域专业性（比如对某个垂直领域的Agent，答案是否符合行业规范和业务逻辑）。输出可信度是用户感知最直接的那个维度，但它是前三个维度出问题后最终显现的症状，找到它，还要往前追溯根因。

三个子维度各有对应的测量方式：

格式合规率 = 符合规范的字段数 / 总必填字段数 × 100%
（可用规则检查，成本最低）

幻觉率 = 被判定为幻觉或虚构的声明数 / 总可核实声明数 × 100%
（需要 LLM Judge 或人工标注，是很多垂直领域Agent 最关键的安全指标）

领域专业性得分：1 到 5 分制，由 LLM Judge 或领域专家评审

举例而言，幻觉率对财经类 Agent 的权重应该最高——一个格式完美但数字错误的分析报告，危害远大于一个格式不规范但数字准确的输出。

线前和上线后，是两个完全不同的战场

上线前的 离线评估 ，是在受控环境里验收：准备一批有标准答案或可参照预期输出的测试用例，让 Agent 跑，看它能答对多少。这个阶段回答的是”Agent 在预期场景下能不能用”。可重复、可精确控制；但评测集覆盖的场景永远是有限的，真实用户的提问方式总会超出预期。

上线后的 在线评估 ，是在生产环境里持续监控：对真实用户请求做抽样，评估 Agent 的实际表现；同时捕获用户的负反馈（点踩、投诉、人工接管），作为质量信号。这个阶段回答的是”Agent 在真实世界里有没有漂移、有没有遇到评测集没有覆盖的失败模式”。

两个阶段缺一不可。很多团队只做了离线评估，上线后就不再系统性地评了。Agent 的失败，有相当大比例来自评测集里没有出现过的真实场景。

评测集怎么建

“想到什么写什么”不是方法，最终结果是一批覆盖核心路径的普通用例，边界场景和异常场景几乎为零，等上线后才发现问题。有效的评测集建设，要按”覆盖维度”来设计：

核心路径覆盖 ：这个 Agent 被设计来处理的主要任务类型，每种路径至少 10 到 20 个用例，覆盖正常输入和常见的变体输入。不能只有一两个用例代表一类任务。

边界场景： 输入模糊时 Agent 怎么处理，信息不完整时它会澄清还是猜测，遇到超出能力范围的任务时它会拒绝还是硬撑。这类场景往往是线上出问题最多的地方，但测试阶段最容易被忽略。

对抗性输入： 用户可能以非预期的方式提问，可能输入格式不规范的数据，可能问和业务不相关的问题。Agent 在这些情况下的行为边界需要被明确测试。

历史失败案例： 上线后每一个被用户标记为”答错了”的 case，都应该进评测集。这是让评测集保持和真实世界接轨的核心机制。一个只在上线前建、之后再也不动的评测集，会随着时间快速失去参考价值。

评测集的数量没有魔法数字，但有一个实用经验：每种核心任务路径如果少于 30 个用例，覆盖率就很难让人放心。质量优先于数量——一个精心设计、覆盖真实边界的 50 个用例，比随手凑的 200 个更有价值。

四、怎么评——方法论和工程设计

三种工具，用对场合

规则和代码检查是确定性的那一端 ：格式是否符合规范（JSON 结构完整、必填字段存在）、数字是否在合理范围、关键词是否出现或缺失。用代码写死判断逻辑，成本接近于零，可以跑 100% 的流量，运行结果完全可重复。

凡是能用规则检查的维度，就用规则，不要交给 LLM 判断。LLM 处理的是规则解决不了的模糊判断，用它来做有明确对错的格式检查，是大材小用，也是不必要的成本和不确定性来源。

人工评审是另一端 ：请领域专家直接判断输出质量，成本最高，速度最慢，但在建立新评测集、校准自动化评估器、处理高风险边界案例时不可替代。人工评审的正确用法，不是”所有输出都人工看一遍”，而是用在关键节点：初始评测集标注、自动化评估器的准确性验证、线上抽样的定期审计。

LLM as Judge 是中间的那一段，解决的是”需要理解语义才能判断，但量太大无法全人工”的场景。

LLM as Judge：怎么用，怎么不被坑

LLM as Judge 的工作原理不复杂：给评审 LLM 一个评判标准，让它对被评估的输出打分或做出判断。坑不在原理，在用法。

评审有三种模式：

单点评分（Pointwise） ：给 LLM 一个输出，让它在量表上打分，或判断”通过/不通过”。简单快速，但分数标定容易漂移——LLM 在不同运行时对”3 分”的理解可能不一致，结果噪声大。适合粗粒度质量过滤，不适合精细对比。

两两对比（Pairwise） ：给 LLM 输出 A 和输出 B，让它判断哪个更好。一致性远高于单点评分，因为”A 比 B 好”比”A 打 3 分”更容易做出稳定判断。Chatbot Arena 的人类评审就是这个逻辑。适合用于版本迭代对比：新版 Agent 和旧版 Agent 在同一批测试用例上哪个更好。

参照评分（Reference-based） ：提供一个参照答案（人工标注的黄金答案，或更高质量模型的输出），让 LLM 判断被评估的输出和参照相比有多准确或完整。在有明确预期输出的任务上，这是最可靠的 LLM 评估模式。

评审提示词的设计，是整个 LLM as Judge 系统的核心，也是最容易被忽视的地方。一个差的评审提示词，会让评估结果比没有评估更危险——它给了你一个数字，但这个数字是不可信的，而你不知道它不可信。

好的评审提示词需要包含几个要素： 明确的评判标准（不能只说”判断质量好不好”，要说清楚什么叫好）；具体的评分维度（每个维度独立说明，不混在一起）；典型的正面和负面示例（让 LLM 锚定你真正想要的判断标准）；明确的输出格式（让评估结果可以被程序解析）。

LLM as Judge 有几个已经被反复验证的失效场景：

位置偏见： 在两两对比模式下，LLM 有倾向性地给第一个出现的选项更高评价。工程对策是随机交换 AB 的顺序，对同一对输出跑两次，取一致判断，不一致的案例人工复核。

自我偏好： 用 GPT-4o 做评审去评估 GPT-4o 自己生成的输出，结果会系统性地偏高。跨系列使用评审模型，或混用多个模型做评审再取共识，可以减轻这个问题。

无法验证事实： LLM 评审可以判断输出”听起来合不合理”，但无法核实具体数字是否正确。对于财经类 Agent，数字准确性和来源可溯是核心要求，LLM as Judge 在这个维度上需要配合规则检查或人工抽查。

Agent-as-Judge：评轨迹，不只评结果

LLM as Judge 评的是单次输出。对于多步骤的 Agent，这不够——你只看到了最终结果，看不到 Agent 走了什么路径才到那里。

Agent-as-Judge 是评估架构上的一次升级：不把最终输出交给评审 LLM，而是把完整的执行轨迹（每一步的推理、每一次工具调用和返回值、整个推理链路）交给评审 Agent 来分析。Zhuge 等人 2024 年发表、ICML 2025 正式收录的论文（arXiv:2410.10934）证明了这个方向的有效性：在代码生成 Agent 的评测任务上，Agent-as-Judge 与人类评审的对齐程度显著高于传统 LLM as Judge——差距来自评估维度，Agent-as-Judge 能看见过程，LLM as Judge 只能看见结果。

对财经分析类 Agent，这个差距尤其重要。一份分析报告最终数字正确，但推理路径里调错了工具、用了错误的口径、中间某一步数据被截断后模型自动填补了一个估计值——这类问题，只看输出根本看不出来，必须追溯轨迹。

生产级三层评估架构

生产环境里成熟的做法，是把评估分三层：

第一层跑所有流量 ，用规则和代码检查处理所有能确定性判断的维度——格式、结构、必填字段、数值范围检查。成本接近于零，延迟影响可以忽略不计。

第二层做抽样， 用 LLM as Judge 评估语义质量——意图理解准确率、回答相关性、表达专业度。抽样比例根据 Agent 的重要性和成本承受能力设定，典型是 5% 到 20% 的流量。

第三层只用于高价值场景 ：新版本上线前的完整评测、线上发现的异常 case 深度核查、定期质量审计。用 Agent-as-Judge 做完整轨迹分析，配合人工复核，成本最高但结论最可靠。

三层同时运行、各司其职。第一层发现的是执行层的硬错误；第二层发现的是质量层的软偏差；第三层发现的是架构层的系统性缺陷。三类问题的处理方式和优先级完全不同。

评估结果的行动逻辑

评估出了结果，然后呢？这个问题在工程实践里经常被忽略——团队建了评估体系，跑出了分数，但不知道什么分数应该触发什么行动。

有一个实用的思路：为每个关键评估指标设定两条线。第一条是”警戒线”，低于这个分数需要人工复核，但不影响 Agent 继续运行；第二条是”停服线”，低于这个分数触发自动降级或暂停服务。

两条线的具体数值，要从 Agent 的业务风险来定。比如财经类 Agent ，一旦给出错误的数字，后续决策依赖的成本极高——它的停服线应该远高于一个只是给用户提供参考信息的内容类 Agent。

五、可观测性——没有它，评估就是瞎子摸象

可观测性和评估不是并列的两件事。可观测性是评估的前置。

评估只能告诉你对还是错，告不诉你哪一步出了问题。没有可观测性，评估失败就是一个没有线索的结论——你知道 Agent 答错了，仅此而已。

体检报告是评估，体检设备是可观测性。没有设备，报告上的数字从哪来？

Agent 可观测性和传统 APM，差在哪里

传统应用监控盯的是确定性系统的健康指标：CPU、内存、响应时间、错误率、吞吐量。这些指标都有明确的正常范围——响应时间超过 200 毫秒就告警，错误率超过 1% 就告警。

Agent 的问题在于，同一个输入可能走不同的路径，同一个路径在不同运行时可能产生不同的结果，而这些差异未必意味着出了问题。”Agent 这次用了 3 步完成任务，上次用了 5 步”——好事还是坏事？没有额外的上下文，你不知道。”正常”不是一个可以预先设定的阈值，而是需要通过大量观测来定义的概念。传统 APM 的那套思路，在这里直接失效。

Trace 和 Span：把 Agent 执行过程记录清楚

可观测性的核心基础设施是 Trace 和 Span，这两个概念来自分布式系统的追踪工程（OpenTelemetry 标准），在 Agent 场景里有直接的对应意义。

一个 Trace 代表一次完整的 Agent 任务执行——从用户发出请求，到 Agent 给出最终响应，中间所有发生的事情构成一个 Trace。把 Agent 执行比作侦探破案，Trace 就是侦探从接到案件到结案归档的完整工作日志。

Span 是 Trace 里的一个个具体步骤——一次 LLM 推理调用是一个 Span，一次工具调用是一个 Span，一次知识库检索是一个 Span。每个 Span 记录自己的开始时间、结束时间、输入和输出、是否成功、耗时多少。多个 Span 嵌套组合，构成完整的 Trace。

在 Agent 场景里，一个设计良好的 Span 至少需要记录以下信息：

LLM 推理 Span ：输入的完整 Prompt（包括系统提示词和用户消息）、模型输出的完整文本、消耗的 token 数（输入/输出分别计）、推理耗时、调用的模型版本。

工具调用 Span： 调用的工具名称、传入的完整参数、工具返回的完整结果、工具执行耗时、是否成功，以及失败时的错误信息。

任务级 Span： 整个任务的意图标签（Agent 对这次请求意图的判断）、任务是否最终完成、总步数、总耗时、总 token 消耗。

这些数据在采集时看起来是运维数据，但它们同时也是评估数据——工具调用的参数和返回值，是 Agent-as-Judge 做轨迹评估的原始输入；意图标签，是离线评估时验证意图识别准确率的基础；token 消耗，是发现 Context Rot 问题的预警信号。运维数据和评估数据在 Agent 场景里是同一份数据，这是 Agent 可观测性和传统 APM 一个结构性的不同。

Agent 特有的监控信号

除了 Trace 和 Span，Agent 场景还有几类特有的信号值得专门建立监控：

工具调用分布 ：每种工具被调用的频率，以及同一个任务类型里工具调用序列的模式。如果某个工具的调用频率突然上升，可能意味着 Agent 在某类任务上开始”不确定时先查一查”，即意图识别在退化。

步数分布： 完成同类任务所需的 ReAct 循环步数分布。步数突然增加，可能是上下文膨胀（Context Rot 的早期信号），也可能是工具返回了异常数据导致 Agent 陷入多余的核查循环。

上下文窗口使用率 ：每次任务结束时已用 token 占最大窗口的百分比。这个数字长期偏高，说明轨迹在膨胀，是性能和质量的双重风险。

用户负反馈率： 用户主动点踩、追问”你说的不对”、或直接放弃对话的比例。比任何自动评估都贴近真实感受，但也是延迟最大的信号——用户放弃通常在 Agent 出问题之后才发生。

从可观测到评估的闭环

可观测性采集到的数据，不应该只用来做运维告警。每一条带有完整 Trace 的生产记录，都是一个潜在的评估样本。

用户给了一个负反馈，这条 Trace 是高价值的失败案例，需要进入评测集；Agent 在某次任务里用了异常多的步数，这条 Trace 值得用 Agent-as-Judge 做深度分析；连续一段时间内工具调用错误率上升，触发的应该是一次系统性的评测集审查，而不只是单次告警响应。

可观测性数据喂给评估系统，评估发现问题推动 Harness 改进，改进结果下一轮验证。这个循环跑起来，才算数。

六、评估不是关卡，是反馈回路

很多团队对 Agent 评估的理解停在一个阶段：上线前做一轮评测，跑完测试集，达到阈值，通过，上线。上线之后基本就不管了。

评测集覆盖的是你在上线前能想到的场景。真实用户不按你想的来。Agent 上线后遇到的失败，有相当大比例来自评测集里从来没有出现过的地方。

说白了，评测集不是入场券，验完收工。它应该是一条持续在跑的流水线。

落到工程上，有两件具体的事要做。其一，生产失败要变成测试用例——每一次用户反馈”答错了”、”答非所问”、”工具调用走错了路”，这个 case 应该被记录下来，进入评测集，成为下一轮改进的标靶。评测集是活的，随着 Agent 在生产环境里遇到的真实问题持续扩充。其二，改进要能被衡量——每次对 Prompt 做了调整、对工具调用逻辑做了优化、对知识库做了更新，都需要重新跑一遍评测集，确认改进有效、没有引入新的回退。没有评测集，”这次改完是不是真的变好了”只能靠感觉。

还有一个认知需要在内部对齐：Agent”持续成长”是真实的，但成长发生在 Harness 层——Prompt 迭代、工具优化、知识库更新、评测集扩充——模型权重本身不会因为使用而改变。”养成性 Agent”这个说法容易让人联想到”模型会自我学习”，在多数生产部署场景下这个预期是不准确的。Agent 的成长需要工程团队主动驱动，不是自动发生的。

对于正在推进 Agent 落地的团队，这三件事如果能同步到位：上线前的评测集建设、上线后的可观测性接入、以及把生产失败系统性地转化为改进输入，Agent 才真正进入可以被信任的状态

附录一：可观测性与评估工具简介

以下工具在业界有较高采用率，感兴趣的读者可按需深入了解。

以 DeepEval 为例：一个 Agent 评估框架由什么组成

DeepEval 的结构，可以作为理解”Agent 评估平台应该长什么样”的参照。

一个完整的 Agent 评估框架包含五个核心组件：

测试用例（Test Case）：评估的基本单元。每个测试用例描述一次完整的 Agent 交互，包含以下字段：

● input：用户输入

● actual_output：Agent 的实际输出

● expected_output：预期的参考输出（可选，用于参照评分模式）

● context：任务的背景上下文

● retrieval_context：Agent 检索到的知识片段（用于 RAG 类评估）

● tools_called：Agent 实际调用的工具列表

● expected_tools：预期应该调用的工具列表（用于工具调用准确率评估）

评估指标（Metrics）：DeepEval 提供 50+ 内置指标，按场景分为以下几类：

评估器（Evaluator/Judge）：每个指标背后是一个评估器，负责对单个测试用例打分。DeepEval 的评估器默认使用 LLM-as-Judge 模式，可配置使用的评审模型（支持 OpenAI、Azure、本地部署模型）。评估器是框架可扩展的核心，支持自定义评审逻辑和评审提示词。

评测集（Dataset）：测试用例的集合，是跑批量评估的基本单位。DeepEval 中的 Dataset 由 Golden（测试用例的前体，只包含输入和预期输出，不包含实际运行结果）组成。评测集支持从 CSV/JSON 导入，或通过 Synthesizer 模块合成生成边界场景用例。

可观测性集成（Tracing）：通过 @observe 装饰器对 Agent 内部的各个组件（检索器、工具调用、LLM 推理）打上 Span 标记，实现组件级评估。评估不只停留在”整体输出质量”，能精确到”哪一个工具调用步骤出了问题”。

五个组件的组合，构成了一个评估框架从”收集数据”到”得出结论”的完整链路。

附录二：主流评测榜单速查表

大模型发布时出现的英文榜单名，集中在以下几类。收藏备用，下次看到不陌生。

知识与推理类

数学竞赛类

代码与软件工程类

Agent 能力类

用户偏好类

参考来源

1. Terminal Bench 2.0 官方排行榜 · tbench.ai
   引用数据：Claude Code + Claude Opus 4.6 排名第 39（58.0%）；ForgeCode + Claude Opus 4.6 排名第 1（81.8%）

2. DeepSeek V4 官方技术报告 · huggingface.co/deepseek-ai/DeepSeek-V4-Pro · 2026年4月
   引用数据：MMLU-Pro 87.5%、GPQA Diamond 90.1%、SWE-bench Verified 80.6%、SWE-bench Pro 55.4%、LiveCodeBench 93.5%、Codeforces 3206、Terminal Bench 2.0 67.9%、MCP Atlas 73.6%、GDPval-AA Elo 1554（均为 Max 模式，官方技术报告表格原始数据）

3. Google DeepMind · Gemini 3.5 Flash 官方博客 · blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-5/ · 2026年5月19日
   引用数据：Terminal Bench 2.1 76.2%、GDPval-AA Elo 1656、MCP Atlas 83.6%、CharXiv Reasoning 84.2%、Finance Agent v2 57.9%

4. Google DeepMind · Gemini 3.5 Flash Model Card · deepmind.google/models/model-cards/gemini-3-5-flash/ · 2026年5月19日
   引用内容：Gemini 3.5 Flash 基准测试覆盖范围及方法论说明

5. NIST · CAISI Evaluation of DeepSeek V4 Pro · nist.gov · 2026年5月2日
   引用数据：DeepSeek V4 Pro 能力较美国前沿模型落后约 8 个月；CAISI 评测与 DeepSeek 自报数据差距约 6 个月；V4 Pro 为迄今 CAISI 评测的最强中国 AI 模型；覆盖网络安全、软件工程、自然科学、抽象推理、数学五个领域共 9 项基准

6. Scale SEAL 标准化排行榜 · scale.com/leaderboard · 2026年6月
   引用内容：标准化脚手架下与厂商自报数字的系统性差距（15–30 个百分点）

7. Datacurve · DeepSWE 研究 · datacurve.ai · 2026年5月（厂商工程实践，非受控实验，数据仅供方向参考）
   引用内容：Claude Opus 4.7/4.6 在超过 12% 的 SWE-bench 运行中读取 Git 历史获取参考答案；GPT 系列未发现同类行为

8. Anthropic · Claude Opus 4.8 发布公告 · anthropic.com · 2026年5月28日
   引用内容：Opus 4.8 代码缺陷漏报率较 Opus 4.7 降低约 4 倍

9. Zhuge et al. · Agent-as-a-Judge: Evaluate Agents with Agents · arXiv:2410.10934 · ICML 2025 正式发表
   引用内容：Agent-as-Judge 与人类评审基准对齐程度相当，显著优于 LLM-as-Judge；评估对象为完整执行轨迹而非单次输出

10. Alibaba Qwen · Qwen3.7-Max 官方博客 · qwenlm.github.io · 2026年5月19日
    引用内容：官方宣传的 35 小时连续运行、超过 1000 次工具调用 demo 展示