Agent Evals：如何证明一个 Agent 真的变好了？

从“看起来能用”到“可验证的可靠性”：深入理解 Agent 评测体系、Trajectory Evaluation、LLM-as-a-Judge 与生产级质量工程

一、一个值得警惕的现象：Agent 升级之后，为什么反而更差了？

假设我们正在开发一个 AI 编程 Agent。

最初，它能够完成一些简单任务：修复 Bug、修改配置、编写单元测试。

为了提升能力，我们对系统进行升级：

• 将模型替换成推理能力更强的新版本。

• 增加代码搜索工具。

• 优化 System Prompt。

• 引入 Context Compaction。

• 增加长期记忆。

• 允许 Agent 自主调用更多工具。

从技术架构上看，系统似乎变得更先进了。

我们找来几个测试任务。

Agent 成功修改了代码，也输出了详细的任务总结。

开发者很满意。

于是，新版本上线。

几天后，用户开始反馈：

“以前能正确修改的文件，现在经常改错。”

“工具调用明显变多了，响应速度反而下降。”

“它说测试通过了，但实际上没有执行测试。”

“任务虽然完成，却修改了不应该修改的文件。”

这时，我们遇到一个很尴尬的问题：

升级前后，到底哪个版本更好？

如果没有客观评测体系，开发团队很难回答。

只能不断修改 Prompt、重新运行几个例子，再凭感觉判断是不是改善了。

这种开发方式，在 AI 工程领域常被称为 Vibe-based Evaluation，也就是依赖主观感受判断效果。

它适合早期 Demo，却很难支撑生产级 Agent 的持续迭代。

因为真正的 Agent 质量问题，不只是回答是否正确，还涉及执行过程、工具使用、状态变化、成本、延迟、稳定性和安全性。

这正是 Agent Evals 要解决的问题。

二、什么是 Agent Evals？

Evals 是 Evaluations 的简称，指对 AI 系统进行系统性评估。

对于传统语言模型，我们可能只需要提供输入，再检查模型输出。

例如：

输入：法国首都是哪里？
输出：巴黎
评分：正确

但 Agent 的执行方式完全不同。

它可能需要：

1. 理解任务。

2. 制定计划。

3. 选择工具。

4. 执行操作。

5. 观察结果。

6. 调整计划。

7. 再次执行。

8. 验证最终状态。

9. 向用户汇报。

因此，Agent Evals 不应该只检查最终回答。

更完整的定义是：

Agent Evals 是一套对智能体任务结果、执行轨迹、环境状态、稳定性、成本和安全约束进行系统性验证的工程机制。

Anthropic 在2026年1月发表的《Demystifying evals for AI agents》中，明确区分了几个关键概念。

Task： 一项待评测任务，包含输入和成功条件。

Trial： 对同一任务的一次独立执行。

Trace / Trajectory： 一次执行中的模型调用、工具调用和中间结果。

Outcome： 执行结束后环境中的真实状态。

Grader： 根据规则、代码、模型或人工判断执行质量的评分组件。

Evaluation Harness： 负责运行测试、记录轨迹、执行评分并汇总结果的评测基础设施。

注意这里有两个不同的 Harness。

上一篇介绍的 Agent Harness 负责让 Agent 执行任务。

Evaluation Harness 则负责测试 Agent 是否正确完成任务。

两者之间的关系可以表示为：

             Evaluation Harness
                      |
         +------------+------------+
         |                         |
         v                         v
    Evaluation Dataset        Test Environment
         |                         |
         +------------+------------+
                      |
                      v
                 Agent Harness
                      |
                      v
                 LLM + Tools
                      |
                      v
                Task Execution
                      |
          +-----------+-----------+
          |                       |
          v                       v
        Trace                   Outcome
          |                       |
          +-----------+-----------+
                      |
                      v
                    Graders
                      |
                      v
              Evaluation Report

Agent Harness 决定系统怎样行动。

Evaluation Harness 决定这些行动是否达到了预期。

如果没有 Evaluation Harness，开发者就很难知道 Harness、Context 和 Memory 的改动究竟带来了多少收益。

三、为什么传统 LLM 评测不够用了？

传统大模型评测通常关注回答准确性、推理能力或生成质量。

但生产级 Agent 是一个会产生实际行动的系统。

举个例子。

用户要求一个信用卡账单 Agent：

“从邮箱读取本月中信 Visa 信用卡账单，提取应还金额和还款日。”

Agent 最终回答：

“已成功导入账单，应还金额3,200元，还款日11月20日。”

如果只检查最终回复，这看起来是一次成功执行。

但真实情况可能有多种。

第一种：Agent 正确读取银行账单，解析金额并写入数据库。

第二种：Agent 只根据历史对话猜测了金额，没有访问邮箱。

第三种：Agent 读取了正确的账单，但把最低还款额当成全额应还金额。

第四种：Agent 识别了正确金额，却把账单写到了另一位用户的账户下。

第五种：Agent 的回复正确，但数据库事务失败，账单实际上没有保存。

这五种情况下，最终回答可能完全相同。

但只有第一种是真正成功。

因此，评测 Agent 必须区分三个层面：

Output：Agent 最终说了什么。

Trajectory：Agent 在执行过程中做了什么。

Outcome：系统最终真的发生了什么。

我认为，这是 Agent Evals 与传统 LLM Evals 最关键的区别。

四、Agent Evals 应该评测哪些指标？

一个常见错误是，只用一个 Accuracy 或 Success Rate 衡量所有能力。

但不同指标实际上回答不同问题。

1. Task Success Rate：任务成功率

这是最核心的业务指标。

计算方式：

Task Success Rate = 成功完成的任务数 / 总评测任务数

例如：

100个任务中，Agent成功完成82个。

那么任务成功率为82%。

但这里有一个前提：

必须先明确“成功完成”究竟意味着什么。

对于 Coding Agent，可能是代码正确且测试通过。

对于 Research Agent，可能是主要结论有证据支持，且满足覆盖范围。

对于 Business Agent，可能是数据库状态正确发生变化。

对于邮件账单 Agent，则可能是正确识别账单金额、币种、账期和还款日，并保存到对应用户的账户中。

不能仅凭 Agent 自己宣布成功就判定任务通过。

2. Tool Call Accuracy：工具调用正确性

Agent 是否选择了正确的工具？

例如：

用户要求读取邮件账单。

合理的工具可能是：

search_email
fetch_email
parse_bill
save_bill

如果 Agent 在没有读取邮件的情况下直接保存账单，就属于明显异常。

但工具调用评测不能过度僵化。

如果Agent使用另一条同样安全、有效的路径完成任务，不应该仅仅因为步骤顺序不同就判错。

因此，我建议工具调用评测重点关注：

• 必须执行的安全检查。

• 禁止执行的操作。

• 工具参数是否合法。

• 是否发生重复副作用。

• 是否超过调用预算。

而不是强制所有成功执行都必须遵循同一条固定路径。

3. Trajectory Quality：执行轨迹质量

Trajectory Evaluation 关注 Agent 的执行过程。

例如：

• 是否反复调用同一个无效工具？

• 是否读取了不必要的大量文件？

• 是否在缺少证据时直接下结论？

• 是否正确响应工具失败？

• 是否执行了必要的验证？

• 是否遵守用户明确提出的限制？

这里的重点是：

同样完成任务，不同执行路径可能具有不同的质量。

一个 Agent 用3次工具调用完成任务，另一个用了40次，还重复修改文件。

两者都可能得到正确结果，但执行效率明显不同。

不过，不能简单地认定工具调用越少越好。

某些高风险任务需要额外验证。

因此，效率必须放在任务成功和安全要求之后衡量。

4. Reliability：可靠性

Agent 最大的特点之一是非确定性。

同一个任务，即使使用相同模型和相同 Prompt，多次执行也可能产生不同结果。

假设某个Agent执行同一任务10次，成功8次。

它的单次经验成功率是80%。

但对于要求稳定的生产应用，仅仅达到80%可能远远不够。

因此，需要重复执行评测。

Anthropic特别讨论了两个指标：

pass@k： 在k次尝试中至少成功一次的概率。

pass^k： 在k次尝试中全部成功的概率。

如果假设每次执行独立且成功率为80%，那么：

pass@3 = 1 - (1 - 0.8)³ = 99.2%

pass^3 = 0.8³ = 51.2%

这意味着，一个Agent可能经过多次尝试几乎总能找到成功路径，但连续三次都成功的概率仍然只有51.2%。

这两项指标适用于不同场景。

编程研究类任务可以允许重试、选择最佳结果。

但支付、订票、数据库修改等业务任务，更需要稳定且可预测的单次执行表现。

注意，上述公式基于独立同分布的简化假设。真实Agent可能存在共享环境、缓存或状态依赖，实际评测应依据多次试验计算。

5. Cost & Latency：成本与延迟

很多Agent优化会产生一个隐藏问题：

质量确实提高了，但执行成本上涨了几倍。

例如：

版本	成功率	平均时间	每任务成本
Agent A	78%	18秒	$0.03
Agent B	84%	55秒	$0.12
Agent C	82%	23秒	$0.04

以上为虚构示例，不是实际产品测评结果。

是否应该选择B？

不一定。

如果任务成功率提高6个百分点，却需要四倍成本和三倍执行时间，就需要结合业务价值进行权衡。

更合理的指标包括：

• 每成功任务平均成本。

• P50 / P95 端到端延迟。

• Token消耗。

• 工具调用次数。

• 重试次数。

• 人工接管比例。

6. Safety & Compliance：安全与约束遵守

对于能够操作真实系统的Agent，安全指标必须是独立的验收条件。

例如：

• 是否访问越权数据？

• 是否泄露用户隐私？

• 是否跳过审批执行敏感操作？

• 是否执行了禁止的命令？

• 是否违反数据保留策略？

• 是否受到外部内容的Prompt Injection影响？

高风险操作不应该因为总体评分较高就被允许通过。

例如，一个Agent任务成功率95%，但有1%的概率读取其他用户的信用卡账单。

这样的系统不能因为成功率高就认为可以上线。

关键安全约束应该使用硬性门槛，而不是简单加入加权平均分。

五、如何设计一个真正有效的 Eval Dataset？

如果评测数据本身不合理，再先进的评分框架也没有价值。

Anthropic建议在初期从20～50个真实任务与失败案例入手，逐渐扩大覆盖范围。

我也非常认同这一点。

早期最重要的不是一次性建立几千条测试，而是保证每条测试都有明确的意义。

从真实用户任务开始

假设我们正在开发一个信用卡邮件账单Agent。

可以先收集以下场景：

类型	评测任务	期望结果
正常	正确识别中信Visa账单	提取金额、日期、币种
正常	正确识别建行Mastercard账单	匹配银行和卡片
正常	识别银联信用卡账单	正确保存账单
边界	一张信用卡同时有人民币和美元账单	分币种保存
边界	收到重复账单邮件	不重复入库
边界	邮件只有最低还款额	不冒充全额应还
异常	银行邮件格式发生变化	标记待核对
安全	伪造银行发件人名称	不直接信任
安全	邮件正文包含恶意指令	不执行邮件中的指令
恢复	保存账单时数据库异常	不虚报保存成功

这类测试的价值，远高于随机生成1000个普通问题。

因为它们直接来自真实业务可能遇到的故障。

Capability Eval 与 Regression Eval

我建议将测试集分为两类。

Capability Eval：能力评测。

目标是观察Agent能否处理以前不会处理的复杂任务。

例如：

识别银行新版邮件、处理多币种账单、分析嵌套附件。

这类测试不一定要求一开始就有很高成功率。

Regression Eval：回归评测。

目标是确保原来已经正确完成的任务，在新版本中仍然能够正确完成。

例如：

• 中信常规账单不能解析错。

• 账单去重不能失效。

• 用户数据不能串户。

• 已经正确处理的日期格式不能退化。

回归测试应当在每次重要代码、Prompt、模型或工具配置修改后执行。

对于成熟系统，两类测试集应该长期并存。

六、三种 Grader：代码、模型和人工

Agent Evals 不应该把所有评分都交给另一个大模型。

对于能够通过代码确定的结果，优先采用确定性验证。

1. Code-based Grader

通过普通程序验证输出或环境状态。

例如：

assert result["bank"] == "CITIC"
assert result["currency"] == "CNY"
assert result["amount_minor"] == 320000
assert result["due_date"] == "2026-11-20"

优点是速度快、结果稳定、成本低。

适合金额、日期、文件状态、数据库字段、测试结果等可以明确验证的内容。

2. LLM-as-a-Judge

对于开放性任务，可以让另一个模型按照明确的评分标准评价结果。

例如，研究报告的质量可能包括：

• 是否覆盖关键事实。

• 结论是否有证据支持。

• 是否混淆事实和推测。

• 是否遗漏重要限制条件。

• 内容结构是否清晰。

模型评审适合处理这些较难通过简单规则判断的任务。

但LLM-as-a-Judge存在局限：

它可能偏好某种写作风格、受到文本长度影响、产生评分不一致，也可能错误接受看起来合理但缺少证据的内容。

因此，应该采用清晰的Rubric，并使用人工标注样本进行校准。

对于重大结论，不能仅凭模型评审就认定正确。

3. Human Evaluation

人工评测仍然不可替代。

特别是：

• 涉及用户体验的主观判断。

• 高风险行业的专业判断。

• 对模型评分器的校准。

• 自动评分结果发生争议。

• 真实环境中复杂的业务决策。

但人工评测成本高，不适合每次提交代码都大规模运行。

因此，比较合理的组合是：

              Agent Evaluation
                     |
         +-----------+-----------+
         |           |           |
         v           v           v
      Code         LLM         Human
      Grader       Judge       Review
         |           |           |
         +-----------+-----------+
                     |
                     v
              Quality Report

能通过代码验证的先用代码，无法明确验证的使用模型评分，重要且存在争议的结果交给人工。

七、真实案例一：SWE-bench Verified，以及为什么Benchmark也会失效

SWE-bench 是 AI 编程Agent领域的重要评测基准。

它基于真实开源项目中的软件问题，要求模型生成代码修改，并通过测试验证问题是否得到解决。

2024年8月，OpenAI发布了SWE-bench Verified。

它包含500个经过人工核查的软件问题，目的是改善原始评测集中任务描述不清、测试不合理等问题。

这体现了一个重要原则：

评测数据本身也必须经过质量验证。

但是，到了2026年，情况出现了变化。

OpenAI在《Why we no longer evaluate SWE-bench Verified》中宣布停止使用这一基准作为其前沿模型的评测指标。

原因包括：

• 开源测试问题可能已出现在模型训练数据中。

• 一些模型能够复现原始修复补丁。

• 部分问题存在描述不足的情况。

• 得分越来越难代表真实、未见过的软件开发任务表现。

这是Agent Evals发展中非常有代表性的案例。

一个最初经过人工验证、质量较高的Benchmark，并不意味着它能够永久保持评测价值。

随着模型能力提高、训练数据变化、任务暴露增加，评测集可能逐渐失去区分能力。

因此，企业不能只依赖公共排行榜选择Agent。

更重要的是建立自己的私有业务测试集，并定期更新。

从这个案例中得到三个启示

第一，Benchmark分数必须结合模型版本、执行环境、工具配置及测试集版本解读。

第二，要防止训练集与测试集污染，以及工具间接获取标准答案。

第三，公开Benchmark只能衡量部分能力，不能代替真实业务任务评测。

对于生产级Coding Agent，我更建议将公共Benchmark、内部历史Bug、私有仓库任务和真实开发流程结合起来。

八、真实案例二：OpenAI BrowseComp 如何评测研究Agent？

Research Agent 的评测比编程Agent更困难。

编程Agent有时可以通过单元测试确认结果。

研究Agent的输出则可能是一份长报告。

怎样判断它是否真的完成了研究？

2025年4月，OpenAI发布BrowseComp，用于评估浏览Agent查找难以发现信息的能力。

这个Benchmark包含1266个具有明确答案的困难问题。

设计原则是：

问题很难找到答案，但答案本身应该容易核实。

例如，需要跨多个网页综合线索，定位某篇研究论文或某个特定事实。

根据OpenAI发布时的研究结果：

系统	BrowseComp准确率
GPT-4o	0.6%
GPT-4o + 浏览	1.9%
OpenAI o1	9.9%
当时的Deep Research	51.5%

这些是2025年发布时特定系统配置下的研究结果，不是2026年的最新模型排行榜。

它们说明一件事：

仅仅给模型增加搜索工具，并不意味着模型就具备可靠的复杂研究能力。

Research Agent还需要规划搜索路径、识别证据、跨来源验证和有效综合信息。

但BrowseComp也有局限。

它主要评估难以查找但答案明确的事实问题，并不能完整代表一份复杂行业研究报告的全部质量。

因此，对于真正的研究Agent，还应该增加：

• 来源可信度。

• 引用准确性。

• 关键事实覆盖率。

• 过期信息识别。

• 事实与观点区分。

• 结论可追溯性。

评测指标应该与Agent真正承担的任务一致，而不是为了排行榜优化产品。

九、真实案例三：Anthropic 如何评测Claude Code？

Anthropic在2026年1月发表的Agent Evals文章中，介绍了Claude Code评测体系的演进。

早期，团队主要依赖内部使用反馈和用户体验。

后来，随着产品复杂度增加，逐步建立自动化评测。

最初关注相对具体的能力，例如：

• 回答是否简洁。

• 文件编辑是否正确。

随后，评测逐渐扩展到更复杂的行为，例如过度设计。

这非常符合真实Agent产品的演进规律。

最初需要验证的是Agent能不能完成任务。

之后需要验证它完成任务的方式是否合理。

例如，用户只要求修改一个配置项，Agent却重构整个配置系统。

即使最后测试通过，也可能不是高质量的修改。

因此，一个成熟的Coding Agent评测系统，不应只关注测试通过率，还需要关注：

• 修改范围是否合理。

• 是否产生不必要的复杂性。

• 是否遵守已有架构。

• 是否执行必要测试。

• 是否增加无关代码。

• 是否违反安全约束。

这也是Trajectory Evaluation的重要价值。

十、动手实现：一个可运行的Python Agent Eval Harness

下面实现一个最小评测系统。

为了让示例能够直接运行，不依赖真实邮箱和大模型API，我们模拟一个信用卡邮件账单解析Agent。

它包含：

1. 测试任务。

2. Agent执行结果。

3. 工具调用轨迹。

4. 确定性评分。

5. 多次Trial。

6. 评测结果汇总。

这个示例是教学版的Evaluation Harness，不是生产级Agent框架。

完整代码

from dataclasses import dataclass
from collections import defaultdict
import re


@dataclass
class EvalTask:
    id: str
    email: str
    expected_amount: int | None
    expected_currency: str
    should_save: bool


@dataclass
class AgentResult:
    amount_minor: int | None
    currency: str
    saved: bool
    trace: list[str]


class DemoBillAgent:
    """
    一个故意保留缺陷的演示Agent：
    无法正确处理金额中的千位分隔符。
    """

    def run(self, email: str) -> AgentResult:
        trace = ["read_email"]

        match = re.search(
            r"应还金额：([0-9]+(?:\.[0-9]{2})?)",
            email
        )

        if not match:
            return AgentResult(
                amount_minor=None,
                currency="CNY",
                saved=False,
                trace=trace
            )

        trace.append("parse_bill")

        amount = int(round(float(match.group(1)) * 100))

        trace.append("save_bill")

        return AgentResult(
            amount_minor=amount,
            currency="CNY",
            saved=True,
            trace=trace
        )


def grade(task: EvalTask, result: AgentResult) -> dict:
    amount_ok = result.amount_minor == task.expected_amount

    currency_ok = result.currency == task.expected_currency

    state_ok = result.saved == task.should_save

    required_tools_ok = (
        not task.should_save
        or (
            "parse_bill" in result.trace
            and "save_bill" in result.trace
        )
    )

    return {
        "amount": amount_ok,
        "currency": currency_ok,
        "state": state_ok,
        "trajectory": required_tools_ok,
        "passed": all([
            amount_ok,
            currency_ok,
            state_ok,
            required_tools_ok
        ])
    }


def run_evals(agent, tasks, trials=3):
    results = defaultdict(list)

    for task in tasks:
        for _ in range(trials):
            output = agent.run(task.email)
            score = grade(task, output)
            results[task.id].append(score["passed"])

    total = sum(len(v) for v in results.values())
    passed = sum(sum(v) for v in results.values())

    pass_at_1 = (
        sum(v[0] for v in results.values())
        / len(results)
    )

    pass_all = (
        sum(all(v) for v in results.values())
        / len(results)
    )

    return {
        "total_trials": total,
        "successful_trials": passed,
        "trial_success_rate": passed / total,
        "pass_at_1": pass_at_1,
        "pass_all_trials": pass_all,
        "details": dict(results)
    }


tasks = [
    EvalTask(
        id="normal_bill",
        email="应还金额：3200.00",
        expected_amount=320000,
        expected_currency="CNY",
        should_save=True
    ),
    EvalTask(
        id="comma_amount",
        email="应还金额：3,200.00",
        expected_amount=320000,
        expected_currency="CNY",
        should_save=True
    ),
    EvalTask(
        id="missing_amount",
        email="本月暂无账单",
        expected_amount=None,
        expected_currency="CNY",
        should_save=False
    )
]


if __name__ == "__main__":
    report = run_evals(
        DemoBillAgent(),
        tasks,
        trials=3
    )

    for key, value in report.items():
        print(key, value)

这段代码使用Python 3.10及以上版本即可运行。

运行结果

total_trials 9
successful_trials 6
trial_success_rate 0.6666666666666666
pass_at_1 0.6666666666666666
pass_all_trials 0.6666666666666666
details {
  'normal_bill': [True, True, True],
  'comma_amount': [False, False, False],
  'missing_amount': [True, True, True]
}

通过评测，我们发现：

Agent可以正确处理普通金额，却无法正确处理带千位分隔符的金额。

这是一个具体、可复现的问题。

而不是笼统地认为：

“模型有时候不太稳定。”

怎样修复？

将金额解析逻辑改成：

match = re.search(
    r"应还金额：([0-9,]+(?:\.[0-9]{2})?)",
    email
)

amount_text = match.group(1).replace(",", "")

再运行同一套评测，三个测试任务就能全部通过。

不过，这里要强调：

这是确定性Demo，所以多次运行结果完全相同。

真实Agent可能涉及模型采样、工具超时和外部状态变化，需要进行独立多次试验。

此外，示例中的金额转换使用了float，仅用于教学。真实金融账单解析必须采用Decimal或经过严格验证的金额解析器，避免浮点精度问题。

示例也没有处理邮件来源验证、多币种、数据库事务与隐私隔离，因此不能直接用于真实信用卡账单生产环境。

但它已经体现了Agent Evals的基本闭环：

发现失败 → 定位原因 → 修改实现 → 重复评测 → 验证改进。

十一、生产级Evaluation Harness应该如何设计？

当Agent从Demo进入生产环境后，评测系统需要进一步扩展。

我建议采用以下架构：

               Evaluation Dataset
                       |
                       v
                Eval Scheduler
                       |
          +------------+------------+
          |                         |
          v                         v
     Agent Version A           Agent Version B
          |                         |
          v                         v
    Isolated Sandbox         Isolated Sandbox
          |                         |
          v                         v
      Run & Trace               Run & Trace
          |                         |
          +------------+------------+
                       |
                       v
                 Grader Engine
                       |
          +------------+------------+
          |            |            |
          v            v            v
        Rules       LLM Judge      Human
          |            |            |
          +------------+------------+
                       |
                       v
                 Result Store
                       |
                       v
                Comparison Report
                       |
                       v
                Release Decision

其中有几个关键设计。

1. 环境隔离

不同Agent版本必须在相同或等价的测试环境中运行。

例如Coding Agent，需要固定：

• 代码仓库版本。

• 测试依赖。

• 操作系统环境。

• 工具权限。

• 初始文件状态。

• 数据库初始状态。

否则，评测差异可能来自环境，而不是Agent版本。

2. 版本记录

每次评测至少记录：

• 模型名称与版本。

• Prompt版本。

• Harness版本。

• 工具Schema版本。

• Memory和Context配置。

• Eval数据集版本。

• Grader版本。

如果只记录“Agent v2”，未来很难复现历史结果。

3. Trace采集

OpenAI当前Agent评测文档提供Trace Grading能力，允许对模型调用、工具调用、Handoff和Guardrail形成的执行记录进行评分。

实际使用时，可以重点分析：

• Agent是否选择正确工具。

• Handoff是否正确发生。

• 是否违反执行约束。

• 改动是否带来行为退化。

对于自建系统，可以使用OpenTelemetry记录标准化Span，并在此基础上建立评测轨迹结构。

但涉及个人隐私、金融和企业机密时，不应默认将完整Prompt、工具输入输出和用户数据发送到外部监控服务。

4. 自动化回归

Agent Evals应该接入CI/CD。

例如：

提交代码
   |
   v
单元测试
   |
   v
Agent Regression Evals
   |
   +----失败----> 阻止发布
   |
   v
Agent Capability Evals
   |
   v
安全与成本检查
   |
   v
灰度发布
   |
   v
生产监控

对于涉及越权、数据泄露和危险操作的测试，应该设置硬性阻断条件。

对于质量类指标，可以根据基线和统计不确定性决定是否升级。

十二、如何判断新版本真的更好了？

这是整个Agent Evals最容易被忽略的问题。

假设我们对100个任务进行了测试：

旧版成功78个。

新版成功83个。

那么，新版是不是一定更好？

不能仅凭这5个百分点就得出结论。

因为模型具有随机性，测试任务也只是实际用户分布中的一个样本。

需要进一步考虑：

• 是否使用相同任务？

• 是否采用相同执行环境？

• 每项任务是否多次运行？

• 是否存在测试数据泄露？

• 变化是否集中在某个业务场景？

• 是否存在严重回归？

• 是否增加了成本或安全风险？

推荐的比较方式

首先采用配对评测。

让两个Agent版本执行相同任务，并记录逐项结果。

例如：

任务	旧版	新版
A	成功	成功
B	失败	成功
C	成功	失败
D	失败	成功
E	成功	成功

这里真正需要关注的，不只是总成功率。

还包括：

新版修复了哪些旧问题？

新版又引入了哪些新问题？

对于重要场景，建议进一步分析置信区间、配对结果差异，并在必要时采用适当的统计检验。

不要把少量任务上的随机波动当作确定的能力提升。

我建议建立一个发布决策表

以下阈值只是示意，正式产品应根据业务风险和基线确定。

指标	示例门槛
总任务成功率	不低于现有版本
核心回归测试	100%通过
重大安全违规	0次
P95延迟	不超过既定SLO
每成功任务成本	在预算范围内
新增能力成功率	明显优于旧版
人工评分	不出现明显退化

需要注意，有限样本中的“0次安全违规”并不意味着真实违规概率为零。

高风险场景还需要威胁建模、权限隔离与持续生产监控。

十三、不要只做离线Evals，还要做Online Evals

离线评测有一个天然限制：

测试集无法包含真实世界中的所有情况。

比如金融账单Agent，开发时可能已经覆盖了十种银行邮件格式。

但银行可能突然更改HTML模板。

又或者某家银行开始通过加密PDF发送账单。

这些变化可能不会出现在原有测试集中。

因此，生产级Agent需要形成持续评测闭环。

Offline Evals

上线前运行。

重点验证：

• 固定任务集。

• 已知失败案例。

• 业务安全约束。

• 模型和Prompt改动。

• 成本与延迟。

Online Monitoring / Evals

上线后持续观察。

重点关注：

• 真实任务成功情况。

• 解析失败率。

• 用户纠错率。

• 人工接管率。

• 工具错误率。

• 数据分布变化。

• 响应时间与成本异常。

Google在2026年7月宣布其Gemini Enterprise Agent Platform中的Agent与模型评测能力正式可用，覆盖质量、安全、Grounding、工具使用和执行轨迹等多个维度。

这个方向非常值得关注：

开发阶段与生产阶段应尽可能使用一致的质量定义。

这样才能更容易判断：生产效果变化究竟来自Agent本身，还是仅仅来自评测口径变化。

但Online Evaluation也需要遵守隐私和数据最小化原则。

尤其对于金融、医疗和企业数据，不应为了评测方便就无限期保存完整用户任务和敏感工具输出。

十四、Agent Evals 最常见的五个错误

错误一：只评测最终回答

Agent说任务完成，不等于任务真的完成。

需要检查真实环境状态。

错误二：只跑一次

一次成功无法证明系统稳定。

对于非确定性任务，需要重复试验。

错误三：所有评分都交给LLM-as-a-Judge

模型评审适合开放性质量判断，但不应该代替数据库校验、测试执行和安全断言。

错误四：只关注总分

总体成功率提升，可能掩盖了重要业务场景的退化。

应该按任务类型、复杂度、风险等级和用户群体分别分析。

错误五：为了Benchmark优化Agent

如果所有工作只围绕公开测试集展开，Agent可能越来越擅长考试，却不一定更擅长真实工作。

评测数据必须不断更新，并包含真实业务任务和新出现的失败模式。

十五、从 Harness、Context、Memory 到 Evals

回顾这个系列的前四篇，可以看到一条非常清晰的技术路线。

第一篇，Harness Engineering。

我们讨论了模型之外的执行系统，以及如何通过工具、状态和权限，让Agent能够可靠行动。

第二篇，Context Engineering。

我们讨论了Agent应该在什么时候读取什么信息，以及如何通过检索、上下文压缩和任务隔离减少信息噪声。

第三篇，Memory Engineering。

我们讨论了Agent如何积累长期知识和经验，如何处理冲突，以及为什么遗忘同样重要。

今天，Agent Evals回答了一个更根本的问题：

如何证明这些工程设计真的有效？

可以将四者结合起来：

              User Task
                  |
                  v
            Agent Harness
                  |
          +-------+-------+
          |               |
          v               v
       Context          Memory
          |               |
          +-------+-------+
                  |
                  v
              LLM + Tools
                  |
                  v
              Execution
                  |
          +-------+-------+
          |               |
          v               v
        Trace           Outcome
          |               |
          +-------+-------+
                  |
                  v
                Evals
                  |
                  v
           Improvement Loop
                  |
                  +------> Agent Harness

Harness决定Agent如何执行。

Context决定Agent当前能看到什么。

Memory决定Agent如何利用过去的经验。

Evals决定我们能否客观判断整套系统的质量。

这四者共同构成一个可持续改进的Agent工程体系。

结语：没有 Evals 的 Agent 优化，本质上还是猜测

AI Agent正在从演示型产品走向真实业务系统。

在这个过程中，开发方式也必须发生变化。

过去，我们可能通过观察几个对话结果，就判断一个Prompt是否有效。

但面对能够执行复杂任务、操作真实工具、修改外部状态的Agent，这种方式已经远远不够。

我们需要把成功条件写清楚。

把真实失败变成测试。

把执行轨迹记录下来。

把模型、工具、上下文和记忆的改动纳入版本管理。

用确定性验证检查真实结果。

用模型与人工评审补充主观质量判断。

通过持续评测发现退化，再将失败重新纳入测试集。

最终形成一个闭环：

定义目标 → 执行任务 → 验证结果 → 分析失败 → 改进系统 → 重新评测。

未来优秀的Agent产品，不只是拥有更强模型、更多工具和更长记忆。

更重要的是，它们拥有一套能够持续证明自身可靠性的工程机制。

一个Agent是否真正变好了，不应该由它自己告诉我们，而应该由可复现的任务结果来证明。

这就是Agent Evals的真正价值。