4、任务级评估：针对具体任务（如问答、工具调用、多步推理）设计评估指标

任务级评估是AI Agent性能评估体系中最贴近用户实际体验的层次。与模型级评估关注“回答质量”不同，任务级评估关注的是“任务是否被成功完成”，以及完成过程中的效率与资源代价。一个Agent可能在单轮对话中表现优异，但在需要调用多个工具、进行多步推理的真实任务中却频繁失败。因此，任务级评估需要围绕任务成功率、完成时间、资源消耗三个核心维度，建立一套可量化、可复现、可对比的指标体系。本章将系统讲解这三类指标的设计方法、计算口径、采集手段与典型应用场景，并结合一个多步工具调用案例进行完整拆解。

4.1 任务成功率：从“完成”到“完成得好”

任务成功率是任务级评估中最核心的指标，它直接回答“Agent是否完成了用户期望的任务”。但“成功”的定义并不简单——一个任务可能部分完成、完成但质量不达标、或完成方式不符合约束条件。因此，设计成功率指标时，首先需要明确任务的粒度与成功判定标准。

任务粒度划分是成功率设计的第一步。通常将任务分为三个层级：原子任务（如“查询天气”）、复合任务（如“预订机票并安排酒店”）、流程任务（如“完成一次客户投诉处理全流程”）。不同粒度的任务，其成功率计算方式不同。原子任务可以直接判定成功或失败；复合任务需要拆解为多个子任务，分别评估后汇总；流程任务则需要考虑步骤间的依赖关系与状态流转。

成功判定标准需要从三个维度定义：结果正确性（输出是否与预期一致）、过程合规性（是否按规定的步骤和工具执行）、约束满足性（是否满足时间、格式、权限等约束条件）。例如，一个“查询并汇总三个城市天气”的任务，即使Agent返回了结果，但如果只查询了两个城市，或使用了错误的日期，都应判定为部分成功或失败。

在实际评估中，建议采用“三级判定法”：完全成功（所有标准满足）、部分成功（核心目标达成但存在瑕疵）、失败（核心目标未达成）。部分成功的场景需要记录失败原因，如“工具调用错误”“信息缺失”“格式错误”等，便于后续优化定位。

4.2 完成时间：端到端延迟与阶段耗时拆解

完成时间衡量的是Agent从接收任务到产出最终结果所消耗的时间。这个指标直接影响用户体验——过长的等待时间会导致用户流失，尤其是实时性要求高的场景（如在线客服、智能助手）。完成时间需要从端到端延迟和阶段耗时两个层面进行拆解分析。

端到端延迟是指从用户提交请求到收到最终响应的总时间。这个指标直观反映用户体验，但无法定位性能瓶颈。因此，需要进一步拆解为四个阶段：意图理解耗时（解析用户输入、识别任务类型）、规划决策耗时（生成执行计划、选择工具）、工具调用耗时（外部API请求、数据获取）、结果生成耗时（整合信息、生成最终回复）。

阶段耗时的采集需要借助埋点日志。在Agent的执行链路中，每个关键节点都应有时间戳记录。例如，在工具调用前后分别记录时间，即可计算出单次工具调用的耗时；在规划模块入口和出口记录时间，即可得到规划耗时。通过分析各阶段耗时占比，可以快速定位瓶颈——如果工具调用耗时占比超过70%，说明外部服务是主要瓶颈；如果规划耗时过长，则可能是模型推理效率问题。

// 阶段耗时埋点示例（伪代码）
const startTime = Date.now();
// 阶段1: 意图理解
const intentStart = Date.now();
const intent = await understandIntent(userInput);
const intentTime = Date.now() - intentStart;

// 阶段2: 规划决策
const planStart = Date.now();
const plan = await generatePlan(intent);
const planTime = Date.now() - planStart;

// 阶段3: 工具调用
const toolStart = Date.now();
const toolResult = await callTool(plan.toolName, plan.params);
const toolTime = Date.now() - toolStart;

// 阶段4: 结果生成
const genStart = Date.now();
const response = await generateResponse(toolResult);
const genTime = Date.now() - genStart;

const totalTime = Date.now() - startTime;
console.log({ totalTime, intentTime, planTime, toolTime, genTime });

完成时间的评估还需要考虑并发场景。在单任务测试中，Agent可能表现良好；但在多用户并发请求下，由于资源竞争和排队，延迟会显著增加。因此，建议在评估中加入不同并发度（如1、5、10、20并发）的压力测试，记录P50、P95、P99延迟，以全面评估Agent在真实负载下的性能表现。

4.3 资源消耗：、API调用与成本核算

资源消耗是任务级评估中容易被忽视但至关重要的指标。它直接关系到Agent的运营成本、可扩展性和可持续性。资源消耗的评估需要从计算资源、API资源和成本三个维度展开。

消耗是最基础的资源指标。每次LLM调用都会消耗输入和输出，而Agent的多步推理和工具调用会显著增加消耗量。评估时需分别统计输入（提示词、上下文、工具返回结果）和输出（模型生成的推理和回复），并计算效率（完成任务所需的总量）。效率低通常意味着Agent的提示词设计不够精简，或推理过程存在冗余。

API调用次数包括LLM调用次数和外部工具调用次数。LLM调用次数反映了Agent的推理深度——每多一次调用，就多一次延迟和成本。工具调用次数则反映了任务复杂度。评估时需要关注无效调用的比例，例如：工具调用失败后重试、重复调用相同工具获取相同数据、规划错误导致的冗余调用等。无效调用是优化资源消耗的重要切入点。

成本核算需要将资源消耗转化为经济成本。不同LLM提供商的定价不同，需要根据实际使用的模型和单价计算单任务成本。成本评估不仅要看单次任务的平均成本，还要关注成本分布——是否存在少数高成本任务拉高整体成本的情况。例如，一个需要多轮工具调用和长上下文的任务，其成本可能是简单任务的10倍以上。

4.4 案例拆解：多步工具调用任务的完整评估

下面通过一个完整的案例，展示如何对多步工具调用任务进行任务级评估。该案例涵盖了指标设计、数据采集、结果分析和优化决策的完整闭环。

案例背景：某电商平台的智能客服Agent需要处理“订单退款查询”任务。用户请求为：“我上周买的手机订单还没发货，我想退款，帮我查一下订单状态并提交退款申请。”该任务需要Agent完成以下步骤：①识别用户意图（退款查询）；②调用订单查询工具获取订单状态；③判断订单是否满足退款条件；④调用退款申请工具提交申请；⑤向用户反馈结果。

评估设计：我们设计了100个测试用例，覆盖正常订单、已发货订单、已取消订单、订单不存在等场景。评估指标包括：任务成功率（完全成功/部分成功/失败）、端到端完成时间、各阶段耗时、消耗、LLM调用次数、工具调用次数及失败率。

初始评估结果：

阶段耗时分析：通过埋点日志发现，工具调用阶段平均耗时4.6秒，占总耗时的56%。其中，退款申请工具的平均响应时间长达3.2秒，且失败后重试导致额外耗时。规划决策阶段平均耗时1.8秒，部分用例中Agent进行了多次无效规划（如先查询再判断再查询）。

失败原因归类：对13个失败用例进行人工复盘，发现：5个用例因订单查询工具返回空结果但Agent未做异常处理而失败；4个用例因退款申请参数错误（订单号格式不正确）导致失败；3个用例因Agent在“已发货”场景下错误地直接提交退款申请而未提示用户需先退货；1个用例因模型幻觉导致错误判断订单状态。

优化措施：基于评估结果，我们实施了以下优化：①在订单查询工具返回空结果时，增加“订单不存在”的兜底回复逻辑；②在退款申请前增加参数校验步骤，确保订单号格式正确；③在规划阶段增加“订单状态判断”分支，对“已发货”订单引导用户走退货流程；④将退款申请工具的超时时间从5秒调整为8秒，并增加失败重试机制（最多2次）。

优化后复测：经过优化，完全成功率提升至89%，部分成功率降至6%，失败率降至5%。平均端到端耗时降至5.8秒，P95降至9秒。消耗降至3,200 ，LLM调用次数降至3.6次。工具调用失败率降至9%。虽然退款申请工具的平均响应时间仍为3秒，但由于减少了无效重试，整体耗时显著下降。

复盘经验：本次优化最大的收益来自“失败原因归类”环节。通过将失败用例按原因分类，我们能够精准定位问题，而不是盲目调整模型参数。同时，阶段耗时分析帮助我们识别出工具调用是主要瓶颈，从而将优化重点放在工具层而非模型层。需要注意的是，优化过程中我们增加了参数校验和异常处理逻辑，这增加了少量消耗（约100 ），但换来了成功率的大幅提升，属于“以微小成本换取显著质量提升”的典型案例。

4.5 常见误区与总结复盘

在任务级评估的实践中，以下误区需要特别警惕：

• 误区一：只关注成功率，忽略完成时间和资源消耗。一个成功率95%但平均耗时30秒、单任务成本5元的Agent，在真实场景中可能不如一个成功率85%但耗时3秒、成本0.5元的Agent。评估必须综合三个维度，并根据业务场景设置权重。
• 误区二：成功判定标准过于宽松或过于严格。过于宽松（如“只要返回了结果就算成功”）会导致指标虚高；过于严格（如“必须与参考答案完全一致”）会低估Agent的实用价值。建议采用“核心目标达成+关键约束满足”的判定标准。
• 误区三：忽略部分成功场景。部分成功是Agent系统的常态，但很多团队只统计“成功/失败”二分类，丢失了大量有价值的信息。建议将部分成功场景单独归类，并记录失败原因。
• 误区四：测试集与真实分布不一致。如果测试用例的难度分布与真实用户请求差异较大，评估结果将失去参考价值。建议定期从真实日志中采样更新测试集。
• 误区五：只做单轮评估，不做回归对比。Agent系统迭代频繁，每次修改都可能引入新的问题。建议建立自动化回归测试机制，在每次版本更新后自动运行任务级评估，对比指标变化。