Skip to content
LLM Agent 评估体系：任务成功率、轨迹分析与质量评估
概述
评估（Evaluation）是量化 Agent 行为表现的系统化方法。与单次测试不同，评估体系需要同时覆盖三个层次：
- 任务结果：任务是否完成、完成到什么程度。
- 运行轨迹：Agent 如何完成任务，中间是否出现错误、冗余或危险操作。
- 质量属性：输出是否正确、相关、安全，以及面对扰动是否稳定。
这三个层次回答的问题不同。任务成功率回答“任务做到了没有”，轨迹分析回答“过程是否合理”，质量评估回答“结果是否可用”。一个完整的评估体系需要将三者组合起来，才能定位 Agent 的薄弱环节。
Agent 评估与传统软件测试、传统 NLP 评估的侧重点不同。传统软件测试面对的是输入输出确定的程序，预期结果可以精确声明，判定规则以断言为核心；Agent 的输入和输出是开放的，同一个任务可能存在多条合法完成路径。传统 NLP 评估通常只看单轮文本输出，使用 BLEU、ROUGE 等静态指标；Agent 评估需要同时考察结果、过程与环境交互，必须引入轨迹数据。因此，Agent 评估体系在任务定义、数据采集和评分方法上都比传统评估多出一个过程维度。
基本概念
任务
任务（Task）是评估的最小单元。一个任务包含输入、预期结果和判定规则。在代码层面可以表示如下：
typescript
// 教学用简化定义
interface EvaluationTask {
id: string;
input: string;
expected: string;
checks?: Array<(result: AgentResult) => boolean>;
}input 是发给 Agent 的指令；expected 是期望输出；checks 是一组可编程的子目标谓词，用于判断任务是否完成。checks 不是必需字段，缺少时退化为输出精确匹配。
AgentResult 是 Agent 的完整执行结果，包含最终输出和轨迹，其接口定义见下一小节。Agent 的接口同样依赖 AgentResult：
typescript
interface Agent {
run(input: string): Promise<AgentResult>;
}任务边界由评估者划定。同一个 Agent 行为可以被拆成多个任务，也可以合并成一个多步骤任务。评估体系需要明确定义任务边界，否则“成功率”没有可比较的基础。
轨迹
轨迹（Trajectory）是 Agent 在执行任务过程中生成的结构化时序数据。它记录从接收用户指令开始的多轮交互中的思考、行动与观察[2]。轨迹与原始调用链（Trace）的区别在于：Trace 是包含工程噪音的日志，轨迹是清洗重构后的标准化语义序列[2]。
下面的 TypeScript 接口描述了一个简化后的轨迹模型。实际系统中的轨迹数据结构更复杂，例如扣子罗盘使用 root_step、agent_steps、steps 三级结构，并预聚合 Token 消耗、工具错误率、首字延迟等指标[2]。
typescript
// 教学用简化定义
type TrajectoryStepType = 'agent' | 'model' | 'tool' | 'graph';
interface TrajectoryStep {
id: string;
type: TrajectoryStepType;
name: string;
input?: unknown;
output?: unknown;
reasoningTokens?: string[];
toolErrors?: string[];
startedAt: number;
endedAt: number;
}
interface Trajectory {
rootStepId: string;
taskInput: string;
finalOutput: string;
steps: TrajectoryStep[];
}
interface AgentResult {
output: string;
trajectory: Trajectory;
}steps 是轨迹的主体。每一步都有类型、名称、输入输出和时间戳。toolErrors 记录工具调用异常，reasoningTokens 记录推理文本。
评估对象
评估对象包括：
- 最终输出：Agent 返回给用户的文本、结构化数据或操作结果。
- 轨迹：中间步骤的时序结构。
- 工具调用：哪些工具被调用、参数是否正确、是否失败。
- 资源消耗：Token 数、调用次数、耗时。
对于一个评估报告，最终输出决定成功率；轨迹决定过程质量；工具调用和资源消耗用于成本与稳定性分析。
Agent 评估与传统评估的差异
Agent 评估体系与传统软件测试和传统 NLP 评估的差异主要体现在以下方面：
- 判定规则。传统测试使用确定性断言；Agent 任务需要使用子目标谓词、部分完成分数和加权评分来度量“完成程度”。
- 数据来源。传统测试用例由人工编写；Agent 评估数据来自人工编写、真实日志采样、合成生成和错误回流。
- 执行环境。传统测试在受控环境中运行；Agent 评估需要沙箱、托管浏览器等隔离环境，避免对真实系统造成影响[1]。
- 评分方式。传统评估可以完全自动判分；Agent 评估需要结合规则判定、LLM-as-Judge 和人工评估。
这些差异决定了 Agent 评估体系不能直接复用传统测试框架，需要独立设计任务模型、轨迹采集和评分协议。
任务成功率的判定与计算
二值完成、部分完成与加权评分
最直观的成功率口径是二值完成：任务达到预期结果记为 1，否则记为 0。
typescript
function scoreTask(task: EvaluationTask, result: AgentResult): number {
if (task.checks && task.checks.length > 0) {
const passed = task.checks.filter(check => check(result)).length;
return passed / task.checks.length;
}
return result.output === task.expected ? 1 : 0;
}scoreTask 的行为分两种情况：当 task.checks 存在且非空时，分数等于通过的谓词数量除以谓词总数；否则比较 result.output 与 task.expected 是否相等，相等得 1 分，不相等得 0 分。checks 为空数组时 length > 0 为 false，同样退化为精确匹配。
当任务包含多个子目标时，二值判定会丢失信息。例如“查询天气并提醒带伞”有两个子目标：查询天气、生成提醒。只调用天气工具但忘记提醒，二值判定为失败，但部分完成度是 0.5。checks 数组提供了一种部分完成（partial completion）的度量：每个谓词等价于一个子目标，通过比例作为分数。
部分完成分数也被称为 credit assignment 的一种简化形式。它把最终结果的成功信号分解到各个子目标上，使评估结果能够区分“完全没做”和“做了一半”。
加权评分是部分完成的推广。不同子目标可以有不同的权重，而不是简单平均：
typescript
interface WeightedScore {
weight: number;
value: number;
}
function weightedScore(items: WeightedScore[]): number {
const totalWeight = items.reduce((sum, item) => sum + item.weight, 0);
if (totalWeight === 0) return 0;
return items.reduce((sum, item) => sum + item.weight * item.value, 0) / totalWeight;
}
const metrics = [
{ weight: 0.5, value: 1.0 },
{ weight: 0.25, value: 1.0 },
{ weight: 0.25, value: 0.0 },
];
const overall = weightedScore(metrics); // 0.75weightedScore 先累加所有权重得到 totalWeight。当所有权重为 0 时返回 0，避免除零错误。该函数的计算过程是：将每个子项的权重乘以分值，求和后除以总权重。上面示例中，三个子项加权平均后得到 0.75。
注意点：部分完成分数能区分完成程度，但不会自动说明失败原因。两个同为 0.5 分的任务，可能分别失败在工具调用和推理过程。完整评估体系需要同时记录子目标通过情况和失败归因。
开放式任务的判定标准转化
开放式任务没有唯一正确输出。比如“为这款咖啡写一段促销文案”，不同文案都可能被接受。此时需要将抽象的判定标准转化为可检查的评分标准（rubric），例如：
- 正确性：文案包含产品名和促销信息。
- 相关性：文案针对目标用户。
- 格式：不超过 5 句话。
评分标准可以由人工执行，也可以由 LLM 执行（见后文“LLM-as-Judge”）。对于需要多步推理的任务，还可以采用过程奖励（process reward），对关键中间步骤单独打分，而不只看最终结果。过程信号有助于区分“最终结果碰巧正确”和“推理过程可靠”。
轨迹数据采集与分析
轨迹事件模型与过程指标
轨迹的标准化是过程评估的前提。实际产品中的轨迹通常以 root_step 为全局概览，记录任务输入输出与预聚合的 metrics_info（如 Token 消耗、工具错误率、首字延迟）；agent_steps 记录 Agent 逻辑执行流；steps 为原子步骤，统一分类为 agent、model、tool、graph 节点[2]。前面的 Trajectory 接口就是基于这类模型简化而来。
基于轨迹可以计算一组过程指标：
- 步骤数：总步骤数越多，任务通常越复杂或越绕路。
- 工具调用次数与工具错误率：高频工具失败可能说明工具选择或参数构造有问题。
- 推理 Token 数：反映推理开销。
- 重试与死循环：同一类型步骤反复出现，可能进入死循环。
- 首字延迟：从用户指令到首次有效输出的耗时。
这些指标可以聚合到评估报告中，用于成本分析和效率对比。
错误分类与失败归因
轨迹评估用于定位 Agent 表现不佳时的具体问题环节[2]。一种常用的方式是对错误进行分类：
typescript
type ErrorCategory =
| 'tool_error'
| 'reasoning_error'
| 'planning_error'
| 'format_error'
| 'missing_step';
function classifyError(trajectory: Trajectory, score: number): ErrorCategory[] {
const categories: ErrorCategory[] = [];
const hasToolError = trajectory.steps.some(
step => (step.toolErrors?.length ?? 0) > 0
);
if (hasToolError) categories.push('tool_error');
if (score < 0.5) categories.push('reasoning_error');
return categories;
}classifyError 是教学用的简化实现。它先扫描 trajectory.steps，若任一步骤的 toolErrors 非空则记录 tool_error；若最终得分低于 0.5，则追加 reasoning_error。完整体系通常会结合“轨迹匹配”和“模型评估”两种手段：
- 轨迹匹配：用代码或预置评估器检查轨迹中是否包含特定模式，适用于明确预期场景，例如“是否调用了搜索工具”“工具调用是否成功”[2]。
- 模型评估：用 LLM 评估逻辑连贯性、进展过程和目标达成情况，适用于需要审计决策过程的复杂任务[3]。
失败归因的结果应当写回数据集管理。每个失败样本可以携带 errorCategories 标签，作为后续回归测试的输入。这样，在线运行中发现的失败模式可以反哺离线评估集。
注意点：错误分类的粒度会影响回归测试的有效性。分类过粗（如只有
tool_error和reasoning_error）难以区分具体失败环节；分类过细则标签体系不稳定，需要定期维护。
质量评估维度
正确性、相关性、安全性与鲁棒性
任务成功率回答的是“任务是否完成”，质量维度回答的是“完成得如何”。两者有重叠，但不应互相替代。举例：一个 Agent 最终返回了正确的 URL，但过程中调用了 8 次不相关的工具；任务成功率是 1.0，轨迹质量却很低。反过来，Agent 最终答案错误，但推理步骤清晰、工具调用合理；失败原因不在过程。评估报告应分开统计结果分和过程分，不要把质量分数直接混入成功率，否则会模糊失败原因。
质量评估通常包含以下维度：
- 正确性：输出内容在事实上是否准确。适用于事实性任务。
- 相关性：输出是否响应用户指令。答非所问的文本即使句子通顺，相关性也低。
- 安全性：输出是否包含有害内容，工具调用是否有高风险操作。
- 鲁棒性：输入扰动、歧义或异常参数下，Agent 是否能保持一致表现。
轨迹质量评估器是过程维度的典型实现。华为云智果的轨迹质量评估器输入 trajectory（Agent 的内部轨迹数据），输出 score（0.0/0.25/0.5/0.75/1.0）与 reason（评分理由说明）[3]。评分档位如下：
- 1.0：轨迹逻辑严密，步骤清晰。
- 0.75：个别步骤轻微冗余或顺序可优化。
- 0.5：存在明显问题，但最终完成。
- 0.25：轨迹混乱，严重偏离目标，勉强完成。
- 0.0：完全偏离目标，逻辑断裂。
评估数据集的构建：标注、一致性与基准
数据来源与标注一致性
评估数据集的质量决定了评估结果是否可信。数据来源通常有：
- 人工编写：针对特定场景构造任务，覆盖边界情况。
- 真实日志采样：从 Agent 实际交互中采样任务，能反映真实分布，但需要脱敏。
- 合成生成：用 LLM 根据模板批量生成任务，效率高，但需要人工抽样验证。
- 错误回流：将在线运行中的失败样本加入数据集，防止回归。
人工标注是评估数据集构建的重要环节。对于开放式任务，需要标注者判断“完成”的定义。此时需要度量标注一致性（Inter-Annotator Agreement, IAA）。常用指标是 Cohen's kappa，它衡量两名标注者在剔除随机一致后的真实一致程度。低于约定阈值时，需要修订标注指南，而不是直接使用数据。
基准与污染
基准（Benchmark）是固定数据集和固定评估协议的组合。除 AgentBench 外，常见的学术基准还有 GAIA、SWE-bench、WebArena 等。以 AgentBench 为例，它是一个托管式 Web 基准测试平台，评估的 Agent 拥有自己的浏览器；平台负责运行创建、基准网站、会话状态、遥测和评分[1]。
基准面临的核心问题是污染（contamination）：如果评估样本出现在 Agent 的预训练数据、上下文示例或开发日志中，评估分数会虚高。缓解手段包括：
- 数据集版本隔离：评估集与训练集分库管理。
- 定期扩展：不断加入新任务。
- 留出未公开的 holdout 集：只在评分时暴露。
自动化评估方法
规则判定
规则判定是最可控的评估方式。它包括字符串匹配、断言、JSON Schema 校验、工具调用检查等。规则判定的优点是确定性高、成本低；缺点是只能覆盖可形式化的预期。
轨迹匹配是规则判定在过程维度的扩展。例如：
typescript
function hasCalledTool(trajectory: Trajectory, toolName: string): boolean {
return trajectory.steps.some(
step => step.type === 'tool' && step.name === toolName
);
}
function hasAnyToolError(trajectory: Trajectory): boolean {
return trajectory.steps.some(step => (step.toolErrors?.length ?? 0) > 0);
}hasCalledTool 遍历 trajectory.steps，当存在 type === 'tool' 且 name === toolName 的步骤时返回 true。hasAnyToolError 检查是否存在 toolErrors 非空的步骤。这类检查适合用于失败归因和回归测试。
LLM-as-Judge 校准
LLM-as-Judge 使用大语言模型作为评估器。它适合开放任务和轨迹质量判断[2][3]。调用方式可以封装为一个函数：
typescript
interface JudgeResult {
score: number;
reason: string;
}
async function judgeTrajectory(
trajectory: Trajectory,
rubric: string,
callLLM: (prompt: string) => Promise<string>
): Promise<JudgeResult> {
const prompt = [
'你是Agent轨迹评估器。请根据评分标准对轨迹打分，并给出理由。',
`评分标准：\n${rubric}`,
`轨迹JSON：\n${JSON.stringify(trajectory, null, 2)}`,
'只输出JSON对象，格式：{"score": 0.0~1.0, "reason": "..."}',
].join('\n\n');
const response = await callLLM(prompt);
return JSON.parse(response) as JudgeResult;
}judgeTrajectory 将评分标准 rubric 和轨迹 JSON 组装成提示词，交给调用方注入的 callLLM 函数。callLLM 抽象了底层模型服务，使评估逻辑与具体模型解耦。返回的文本被解析为 JudgeResult。实际工程中需要对 JSON.parse 做异常保护，并在解析失败时重试或降级。
LLM-as-Judge 需要校准。校准的基本流程是：
- 选取一组已有人工标注的样本。
- 用 LLM 对同一组样本打分。
- 计算 LLM 与人工标注的一致率。
- 一致率低于预期时，调整评分标准描述，或改变评估提示词。
LLM-as-Judge 存在系统性的偏差，常见包括：位置偏差（先出现的论据影响更大）、长度偏差（较长答案得分偏高）、自利偏差（与模型自身观点一致时给高分）。这些偏差难以完全消除，因此需要持续抽样比对。
注意点：LLM-as-Judge 的提示词中如果包含“只输出 JSON”等硬性约束，个别模型会返回多余说明或格式错误。建议在评估管线中增加格式校验和重试机制。
主流评估体系对比
Agent 评估体系的生态中有不同定位的工具。AgentBench、扣子罗盘和华为云智果分别覆盖了结果、轨迹和过程质量三个侧面。
AgentBench 是一个托管式 Web 基准测试平台。它评估拥有自己浏览器的 Agent，平台负责运行创建、基准网站、会话状态、遥测和评分[1]。架构上，AgentBench 包含 apps/web 与 apps/hosted-sites 两个组件。hosted-sites 在进程边界无状态，Redis 作为跨副本的共享运行时缓存[1]。AgentBench 适合对 Web 型 Agent 做综合能力基准测试，但不直接提供细粒度的轨迹质量评分。
扣子罗盘提供轨迹评估能力。它定义了标准化的轨迹数据结构，包括 root_step、agent_steps 和 steps 三级组织[2]。在评估方法上，它同时支持 LLM-as-Judge 和轨迹匹配两种自动化方式[2]。扣子罗盘适合在 Agent 开发框架内部做轨迹质量监控和失败归因。
华为云智果提供轨迹质量评估器。它以 LLM 评估方式分析 Agent 的内部轨迹，评估逻辑连贯性、清晰的进展过程和目标达成情况[3]。输出为 0.0 至 1.0 的五档分数并附评分理由[3]。它适合需要审计 Agent 决策过程的复杂问题求解、多步推理任务和工具链调用追踪。
这三个体系的侧重点可以归纳为下表：
| 评估体系 | 评估重点 | 评估方式 | 适用场景 |
|---|---|---|---|
| AgentBench | Web 任务结果 | 托管浏览器 + 平台评分 | Web 型 Agent 综合能力基准 |
| 扣子罗盘轨迹评估 | 轨迹过程 | 轨迹匹配 + LLM-as-Judge | 轨迹质量监控与失败归因 |
| 华为云智果轨迹质量评估器 | 轨迹逻辑与目标达成 | LLM 评估 | 复杂推理、多步任务、工具链调用追踪 |
注意点：三个体系并不是互斥关系。一个完整的评估体系可以同时使用 AgentBench 做外部基准测试、扣子罗盘做轨迹采集与匹配、华为云智果做轨迹质量评分。选择时应当依据评估目的：横向对比用基准平台，问题定位用轨迹评估。
评估系统架构与工程落地
系统组件
一个可扩展的评估系统至少包含以下组件：
- 任务数据集管理：存储任务版本、标签和错误分类。
- 执行环境：运行 Agent 的沙箱。对于 Web 型 Agent，需要托管的浏览器[1]。
- 评估器：规则检查器、轨迹匹配器、LLM-as-Judge 或人工评估界面。
- 聚合与报告：计算成功率、平均分、过程指标，生成失败样例列表。
- 结果存储：保存原始轨迹、评估分数和版本信息。
评估管线可以用一个函数表达：
typescript
interface Scorer {
score(task: EvaluationTask, result: AgentResult): number;
}
interface TaskResult {
taskId: string;
score: number;
}
interface EvaluationReport {
totalTasks: number;
successRate: number;
averageScore: number;
results: TaskResult[];
}
function aggregate(results: TaskResult[], successThreshold = 1): EvaluationReport {
const totalTasks = results.length;
if (totalTasks === 0) {
return { totalTasks: 0, successRate: 0, averageScore: 0, results: [] };
}
const successRate = results.filter(r => r.score >= successThreshold).length / totalTasks;
const averageScore = results.reduce((sum, r) => sum + r.score, 0) / totalTasks;
return { totalTasks, successRate, averageScore, results };
}
async function runEvaluation(
tasks: EvaluationTask[],
agent: Agent,
scorer: Scorer,
successThreshold = 1
): Promise<EvaluationReport> {
const results: TaskResult[] = [];
for (const task of tasks) {
const result = await agent.run(task.input);
const score = scorer.score(task, result);
results.push({ taskId: task.id, score });
}
return aggregate(results, successThreshold);
}aggregate 在 results 为空时返回全零报告。successRate 是分数不低于 successThreshold 的任务比例；averageScore 是所有任务的分数均值。runEvaluation 按顺序执行每个任务，使用注入的 scorer 计算分数，最后聚合报告。
部署形态
评估系统可以按部署形态分为三类：
- 脚本级。通过命令行工具运行任务集合并输出报告，适合开发阶段快速验证单组任务。
- 服务级。将评估器封装为常驻服务，支持多团队共享，适合与持续集成流水线集成。
- 平台级。提供任务管理、数据集版本管理、评估报告展示和结果查询接口，适合组织级统一评估。AgentBench 属于平台级，外部提交 Agent 接入信息后，由平台完成环境创建、运行和评分[1]。
结果存储与数据集管理
结果存储需要满足三个维度的查询：任务 ID、Agent 版本、评估时间。推荐使用文档型数据库保存原始轨迹 JSON，用关系型数据库保存聚合指标。数据集文件可以通过对象存储或版本管理工具维护，每次变更产生新版本号。评估结果按 agentVersion、taskId、evaluationTime 三个维度组织，离线评估与在线监控共用同一种存储格式，才能进行跨环境对比。
在线监控与持续回归
离线评估无法覆盖所有在线输入分布。因此，运行中的 Agent 需要持续监控。运行时遥测（Trace）被采集后，清洗为轨迹，然后通过流式或批式评估器打分。
一个简单的滑动窗口成功率计算器：
typescript
class SlidingWindowSuccessRate {
private events: Array<{ time: number; ok: boolean }> = [];
constructor(private readonly windowMs: number) {}
add(ok: boolean): void {
this.events.push({ time: Date.now(), ok });
this.events = this.events.filter(e => Date.now() - e.time <= this.windowMs);
}
get rate(): number {
if (this.events.length === 0) return 0;
return this.events.filter(e => e.ok).length / this.events.length;
}
}add 记录一次任务是否成功，并移除超出时间窗口的旧事件。rate 返回当前时间窗口内的成功率。窗口长度由构造参数 windowMs 决定，可以根据任务耗时动态调整。
一条典型的评估流水线包含以下环节：数据集更新（新增任务或失败回流样本）→ 执行评估（分配沙箱、运行 Agent、采集轨迹）→ 评分（规则、LLM 或人工）→ 结果写入（原始轨迹和聚合指标）→ 报告生成。离线评估由数据集变更或版本更新触发；在线监控由运行时流量持续触发。失败样本被自动标记并回流到数据集管理服务，成为后续回归用例。
多版本对比
评估系统还应支持多版本对比。同一个任务集，分别运行旧版和新版 Agent，可以生成差异报告：
- 哪些任务从失败变为成功。
- 哪些任务从成功变为失败。
- 哪些任务的轨迹质量明显下降。
这要求评估结果按 agentVersion、taskId、evaluationTime 三个维度存储。离线评估与在线监控共用同一种结果存储格式，才能进行跨环境对比。差异报告可以用任务维度的分数变化表和轨迹质量变化列表来呈现。
生态趋势与开放问题
评估体系正在从“只看最终结果”转向“结果 + 过程”的双轨模式。AgentBench 这类平台提供浏览器环境，使 Web 型 Agent 可以在真实网页上被评估[1]。扣子罗盘轨迹评估和华为云智果轨迹质量评估器则把过程评估做成了可嵌入的评估组件[2][3]。
在学术与工程社区，以下几个方向值得关注：
- 过程监督（Process Supervision）：对轨迹中的每一步提供过程奖励，而不是只在最终结果给分。这需要细粒度的标注协议。
- 可扩展监督（Scalable Oversight）：当任务难度超过人工直接评估能力时，用模型辅助人类监督。
- 标准化与互操作：不同 Agent 框架产生的 Trace 能否统一成标准轨迹格式，仍是开放问题。
- 基准寿命：静态基准会被快速过拟合，需要通过动态生成和定期更新来延缓失效。
开放问题包括：多 Agent 协作任务的评估单位如何划分；过程奖励与结果奖励如何组合；LLM-as-Judge 的一致性能否在多种任务类型上持续保持。