同样能完成任务的 Agent性能差距可能天差地别该怎么量化这是很多团队把 Agent 从 Demo 推向生产时卡得最久的问题。先说结论不要只用“任务完成率”一个数字去评价 Agent。同一个任务Agent A 可能一次工具调用就完成Agent B 要重试五次最后碰巧成功A 的每轮延迟 800msB 要 8 秒A 遇到报错能自己修正B 会直接卡死。从用户视角看两者“都完成了任务”但从工程化角度看稳定性、成本、可观测性完全是两个量级。这就是工业级 Agent 评估和实验室指标最大的区别。这篇文章直接给出三层评估框架结果层、轨迹层、系统层。每一层拆成可落地的指标定义、采集方式、计算方法和判定标准并附带一套可复用的 Python 评估原型和排查清单。如果你正在做 Agent 框架选型、Agent 性能优化、自动化回归测试或者要在团队里建立一套 Agent 评测规范这篇可以直接参考。先强调一个容易混淆的点这里的“量化”不是模型权重量化如 INT8、AWQ而是对 Agent 能力做可量化的指标评估。两者不在一个维度别搞混。1. 核心能力速览维度说明评估对象基于 LLM 的 Agent、Agent 框架、工具调用链路结果层指标任务完成率、成功分数、输出合规率、业务收益指标轨迹层指标工具调用准确率、无效调用率、重试率、轨迹长度、Token 消耗系统层指标端到端延迟、吞吐量、超时率、错误分布、稳定性、并发表现评估方式自动化测试集 轨迹日志采集 指标聚合计算可落地程度支持离线评测、线上灰度对比、回归测试所需环境Python 3.8需要能访问 Agent 的日志系统或拦截工具调用是否支持批量任务是评测集本身就是批量执行的是否支持 API不依赖特定 API可适配 OpenAI SDK、LangChain、自研框架这套方案不绑定任何特定 Agent 框架。你可以用它来对比 LangChain、AutoGPT、自研 Agent也可以评估不同基座模型在同一任务上的表现差异。2. 为什么单看 LLM 指标不够很多团队评估 Agent 时第一反应是把 LLM 的指标套过来用准确率、召回率、BLEU、ROUGE。这些指标在单轮问答场景有效但在 Agent 场景里会失真。Agent 的本质是一个多步骤决策系统。它需要理解任务、拆解计划、调用工具、读取结果、修正错误、最终产出。这个过程中每一步都可能出错而错误的影响会沿着轨迹向后传导。一个工具调用参数写错可能导致后续所有步骤全部失效一次上下文溢出可能导致 Agent 直接胡言乱语。单看最终文本的相似度根本捕捉不到这些中间失败。另一个问题是“任务完成”的标准很难定义。对于“帮我预订一家海底捞”这种任务Agent 可能订到了也可能只返回了餐厅列表但没完成预订。如果只看模型输出文本两者都可能被算作“成功”因为都提到了海底捞。工业级评估必须把目标拆成可验证的约束条件而不是靠人眼判断。还有一层是系统性能的差距。两个 Agent 都成功了但一个平均耗时 3 秒一个平均耗时 30 秒一个在 10 并发下稳定输出另一个到 3 并发就开始超时。如果只用正确率评估你会得出“两者差不多”的错误结论。这就是为什么必须引入系统层指标。3. 结果层指标任务是否真的完成了结果层回答的问题是Agent 这趟任务最终交付的结果对不对。3.1 任务完成率Task Success Rate最基础的指标定义也要最严格。一个任务只有当所有预设条件都满足时才算成功。以“查询上海明天天气并写入 notes.txt”为例完整条件是Agent 成功调用了天气查询工具。返回的城市是上海时间是明天。Agent 成功创建或写入了 notes.txt。文件内容包含正确的天气信息。四个条件任一不满足整个任务判失败。千万不要用“模型是否提到了上海”这种宽松标准。任务完成率的计算方式success_count sum(1 for result in eval_results if result.is_success) task_success_rate success_count / len(eval_results)这个指标是所有结果层指标里最核心的也是对外汇报最常用的。3.2 部分成功与成功分数实际业务里很多任务不是非黑即白。Agent 可能完成了 80% 的步骤但最后一步失败了。直接用 0 或 1 记录会丢失大量信息。推荐用部分成功分数Partial Success Score。做法是给每个子目标分配权重所有子目标加权重置为 1最终按完成度打分。# 子目标权重示例 subgoals { 查询天气: 0.4, 写入文件: 0.3, 格式正确: 0.2, 内容完整: 0.1 } def compute_partial_score(completed_subgoals): return sum(weight for name, weight in subgoals.items() if name in completed_subgoals)这个指标的好处是能看出 Agent 的失败模式。如果很多任务的“查询天气”都成功了但“写入文件”失败率高说明 Agent 的文件操作能力是瓶颈应该针对性优化工具调用逻辑或提示词。3.3 输出合规率Format Compliance RateAgent 的输出往往需要对接下游系统。比如返回 JSON、SQL 语句、特定格式的文件。输出不合规意味着下游任务无法处理等同于失败。合规率测试需要为每个任务预定义输出格式约束import json def validate_output_format(output_text, expected_schema): try: data json.loads(output_text) return all(key in data for key in expected_schema) except json.JSONDecodeError: return False # 测试用例 expected_schema [city, date, weather, temperature] is_compliant validate_output_format(agent_output, expected_schema)对于结构化输出建议在提示词里给出 JSON Schema 示例同时在代码侧做严格校验。不要相信模型“大概率会输出正确格式”。3.4 业务收益指标结果层最后要知道的是Agent 完成了任务然后呢不同业务场景有各自的收益指标场景业务指标说明客服 Agent问题一次性解决率用户是否还需要转人工数据分析 Agent报告可用率生成的分析报告是否可直接使用代码生成 Agent代码通过率生成的代码能否通过单元测试销售 Agent成单率对话是否最终促成了交易这类指标往往需要线上埋点或人工复核比较重适合在 Agent 上线后进行持续监测。3.5 结果层指标采集方法结果层指标依赖对 Agent 最终产出的自动化校验。推荐的做法是在每个测试用例中定义success_checker函数。框架执行完 Agent 后调用 checker 自动判定。同时保存原始输出方便人工抽检。def evaluate_task(agent, task, success_checker): output agent.run(task.input) is_success success_checker(output) return { task_id: task.id, is_success: is_success, output: output }对于无法自动判定的任务比如涉及主观判断需要接入人工标注系统或先用 LLM 做初筛再由人工确认。4. 轨迹层指标任务是怎么完成的结果层告诉你 Agent 做成了没有轨迹层告诉你 Agent 是怎么做成的。这一步会在两个同分 Agent 中拉开差距。4.1 工具调用准确率Tool Call AccuracyAgent 的核心能力是调用工具。工具调用的准确率包括两个维度工具选择是否正确该调用get_weather时有没有调成get_date。参数是否正确该传city上海时有没有传成city北京。在实际评测中要求每一轮工具调用都正确。即使后续步骤通过某种方式“纠正”了前面参数的错误那一轮调用仍然要记为错误。def compute_tool_accuracy(trajectory): correct_calls sum(1 for step in trajectory if step.tool_call.is_correct) total_calls len(trajectory) return correct_calls / total_calls if total_calls 0 else 04.2 无效调用率与重试率无效调用包括调用了不存在的工具、参数类型错误、调用后返回异常、重复调用同一工具且参数相同。无效调用率高说明 Agent 对工具接口的掌握不够或者对返回结果的解析能力弱。特别要注意的是重试模式Agent 在遇到错误后是调整参数重试还是原样重复同一个错误请求。后者是一个很典型的退化信号。在轨迹日志里可以这样识别def detect_repeated_retry(trajectory): tool_signatures [ (step.tool_call.name, tuple(sorted(step.tool_call.arguments.items()))) for step in trajectory if step.tool_call is not None ] for i in range(1, len(tool_signatures)): if tool_signatures[i] tool_signatures[i - 1]: return True return False如果相邻两轮工具调用完全一致说明 Agent 可能在原地打转。这类轨迹即使在最终结果上成功也不值得推荐。4.3 轨迹长度与 Token 消耗轨迹长度是 Agent 从任务开始到结束的总步数。Token 消耗包括输入 Token、输出 Token 和工具返回结果占用的 Token。这两个指标直接关联成本。在同一个任务上Agent A 用 12 步完成Agent B 用 25 步即使结果相同A 的成本也显著更低。def compute_cost_metrics(trajectory): total_steps len(trajectory) total_tokens sum( step.usage.prompt_tokens step.usage.completion_tokens for step in trajectory ) return { total_steps: total_steps, total_tokens: total_tokens }这里有一个经验判断正常任务如果步数超过预期 2 倍以上基本可以判定为轨迹异常。要么是 Agent 无效推理多要么是陷入局部循环。4.4 自恢复能力Self-Correction Rate错误一定会发生。工业级 Agent 的差距很大程度体现在错误发生后的恢复能力上。评测时记录两类事件轨迹中是否出现了错误工具报错、参数无效、模型拒绝响应。错误出现后Agent 是否在同一轮任务内自主修正并完成了任务。自恢复率的计算def compute_self_correction_rate(trajectory): error_steps [step for step in trajectory if step.has_error] recovered_tasks sum( 1 for step in error_steps if step.next_step is not None and step.next_step.is_success ) return recovered_tasks / len(error_steps) if error_steps else 1.0如果 Agent 遇到错误后直接返回失败或者反复用相同方式重试说明它的自恢复机制设计有缺陷。这个指标在评估工具型 Agent比如代码执行类、数据库操作类时格外重要因为这类场景出错是常态而不是例外。4.5 轨迹层指标采集方法轨迹数据的质量直接决定评估的可靠性。建议使用结构化日志而不是解析纯文本。{ task_id: task_0001, trajectory: [ { step: 1, action: tool_call, tool_name: search_web, arguments: {query: 上海明天天气}, result_status: success, result_summary: 找到 3 条结果, tokens: 1200 }, { step: 2, action: llm_response, content: 正在整理天气信息..., has_error: false, tokens: 350 } ] }采集时要注意不要只记录调用的工具名还要记录参数、返回状态、Token 消耗、时间戳。尽量用 SDK 回调或中间件方式自动采集避免在 Agent 业务代码里手工埋点否则维护成本太高。5. 系统层指标并发与稳定性很多 Agent 在单任务、单用户场景下表现不错一上生产就崩。原因在于缺少系统层指标。系统层指标回答的问题是这个 Agent 在真实生产环境里的延迟、吞吐和稳定性是什么水平。5.1 端到端延迟E2E Latency从用户提交任务到收到最终结果的完整时间。这里有两个关键点要区分 P50、P95、P99只看平均值没有意义。要区分首次响应时间和整体完成时间。有些 Agent 会先回复一段“好的我正在处理”这时首字延迟很低但整体任务要几分钟。latencies sorted([task.latency for task in tasks]) p50 latencies[int(len(latencies) * 0.5)] p95 latencies[int(len(latencies) * 0.95)] p99 latencies[int(len(latencies) * 0.99)]如果 P99 远高于 P50说明系统存在明显的长尾延迟可能是工具调用超时、模型推理排队或上下文过长导致的。5.2 超时率与错误分布对于线上服务超时率通常比平均延迟更重要。一次超过 60 秒的调用对用户体验的伤害远大于十次平均 2 秒的成功调用。建议统计以下指标指标说明超时率任务超过预设时间上限的比例错误率任务执行中产生异常的比例部分失败率任务成功但部分子过程失败的比例重试成功率系统自动重试后成功恢复的比例生产环境里Agent 由于上下文过长或循环调用经常会卡住不返回。这时需要设置硬性超时时间超时后自动终止并记录错误原因。可以参考类似 “agent terminated due to error you can prompt the model to try again or start” 这类系统提示的判定逻辑把“是否终止、是否提示重试”作为轨迹层的一个分类标签统计不同结局的比例。5.3 稳定性与波动性同一任务在不同时间、不同并发下执行结果可能差异很大。稳定性指标关注的是这种差异有多大。最简单的做法同一组任务连续跑多轮计算指标的标准差。import statistics def compute_stability(metrics): mean_value statistics.mean(metrics) std_value statistics.stdev(metrics) cv std_value / mean_value if mean_value else 0 return {mean: mean_value, std: std_value, cv: cv}变异系数CV越低越好。如果 CV 超过 0.3说明 Agent 行为波动很大这在生产环境里是危险的。用户可能上一秒得到完美回答下一秒就完全跑偏。5.4 可观测性与日志链路工业级评估离不开可观测性。每个任务都要有唯一的 trace_id能够串联完整链路{ trace_id: 8f3a2c1b7e9d4a6f, task_id: task_0001, llm_calls: [ {step: 1, model: gpt-4o, prompt_tokens: 800}, {step: 2, model: gpt-4o, prompt_tokens: 1500} ], tool_calls: [ {step: 1, tool: search_web, duration_ms: 350}, {step: 2, tool: write_file, duration_ms: 20} ], total_duration_ms: 6800, final_result: success }有了 trace_id评估系统才能做失败归因。否则你只知道“任务失败了”不知道是模型推理慢、工具超时、还是 Agent 自己逻辑混乱。5.5 系统层指标采集方法轻量级方案是直接在 Agent 运行入口和出口埋点记录时间戳和状态。生产级方案建议引入 APM 系统或至少使用 OpenTelemetry 等标准工具。import time import threading from dataclasses import dataclass dataclass class AgentRuntimeStats: start_time: float 0.0 end_time: float 0.0 status: str running def start(self): self.start_time time.time() def finish(self, status): self.end_time time.time() self.status status def duration_ms(self): return (self.end_time - self.start_time) * 1000对于并发压测至少需要跑 20 个样本以上取分布不要用 3 个样本就下结论。6. 评估实验设计与落地流程三层指标定义清楚了接下来是实操问题怎么在团队里把评估跑起来。6.1 定义任务集合评估任务集合要覆盖真实业务场景同时包含边界场景和失败场景。建议按以下维度划分维度示例简单任务单轮问答、单工具调用复杂任务多步推理、多工具协作异常输入空输入、超长输入、格式错误输入边界场景数据不存在、权限不足、工具调用超时对抗场景提示注入、恶意请求任务集合不需要一开始就很大。先准备 30 到 50 个覆盖典型场景的任务通过一轮评估跑通流程再逐步扩展。高质量的任务集合比数量更重要。6.2 确定基线与重复次数由于 LLM 的随机性单次运行结果不可信。同一个任务建议至少重复 3 到 5 次取结果分布。评估时同时跑基线和被测 Agent基线可以是上一版本 Agent。可以是不同的基座模型。可以是同一个 Agent 的不同提示词版本。对比实验时要保持任务集合、系统资源、超时设置完全一致否则结果不具备可比性。def run_evaluation(agent, task_set, repeat_count3): eval_results [] for task in task_set: for i in range(repeat_count): result evaluate_single_task(agent, task) eval_results.append(result) return compute_aggregated_metrics(eval_results)6.3 指标聚合与权重把三层指标合成为一个可比较的分数时不要简单求平均。不同业务对指标权重的要求不同。推荐方案先确定核心结果指标如任务完成率这是硬指标。设定最低门槛。例如任务完成率低于 60%直接拒绝上线不看其他指标。通过门槛后再看轨迹层指标做效率排名。系统层指标单独设 SLA不参与排行榜。def evaluate_release_readiness(metrics): if metrics[task_success_rate] 0.6: return rejected, task success rate below threshold if metrics[p95_latency_ms] 10000: return rejected, p95 latency exceeds 10s if metrics[tool_call_accuracy] 0.8: return warning, tool call accuracy needs review return approved, all checks passed这种方式的好处是团队里每个人都能快速理解一个 Agent 能不能上线而不是面对一堆数字无所适从。6.4 评估报告模板一份合格的 Agent 评估报告至少包含以下模块结论摘要是否通过上线标准。结果层指标对比表。轨迹层关键问题列表。系统层 SLA 表现。失败案例摘录。改进建议。失败案例摘录很重要。一个失败的轨迹配上工具调用记录和模型输出能让你快速定位问题出在规划、工具还是提示词。这也是评估体系对开发最有价值的部分。7. 评测工具与原型实现这里给出一套轻量级评测原型的核心代码可以按需改造成自己的评测框架。7.1 轨迹日志采集用装饰器方式自动记录 Agent 运行过程避免侵入业务逻辑import json import time from functools import wraps class TrajectoryCollector: def __init__(self): self.trajectory [] def record_tool_call(self, tool_name, arguments, result_status, duration_ms, tokens0): self.trajectory.append({ type: tool_call, tool_name: tool_name, arguments: arguments, result_status: result_status, duration_ms: duration_ms, tokens: tokens, timestamp: time.time() }) def record_llm_call(self, prompt_tokens, completion_tokens, duration_ms): self.trajectory.append({ type: llm_call, prompt_tokens: prompt_tokens, completion_tokens: completion_tokens, duration_ms: duration_ms, timestamp: time.time() }) def export(self): return json.dumps(self.trajectory, ensure_asciiFalse, indent2)7.2 三层指标计算class AgentEvaluator: def __init__(self): self.results [] def add_result(self, task_id, is_success, partial_score, trajectory, latency_ms): self.results.append({ task_id: task_id, is_success: is_success, partial_score: partial_score, trajectory: trajectory, latency_ms: latency_ms }) def compute_result_layer(self): total len(self.results) success sum(1 for r in self.results if r[is_success]) return { task_success_rate: success / total if total else 0, avg_partial_score: sum(r[partial_score] for r in self.results) / total if total else 0 } def compute_trajectory_layer(self): tool_calls [] retries 0 total_steps 0 total_tokens 0 for r in self.results: for step in r[trajectory]: total_steps 1 if step[type] tool_call: tool_calls.append(step) if step[result_status] error: retries 1 if step.get(tokens): total_tokens step[tokens] return { total_steps: total_steps, tool_call_count: len(tool_calls), error_retry_count: retries, total_tokens: total_tokens } def compute_system_layer(self): latencies [r[latency_ms] for r in self.results] latencies.sort() n len(latencies) return { p50_latency_ms: latencies[int(n * 0.5)] if n else 0, p95_latency_ms: latencies[int(n * 0.95)] if n else 0, p99_latency_ms: latencies[int(n * 0.99)] if n else 0 }7.3 批量评测执行评测集本身就是批量任务。建议用一个 runner 统一调度def run_batch_evaluation(agent, task_set, max_concurrency3): results [] for task in task_set: result run_with_timeout(agent.run, task.input, timeout_sec60) results.append(result) evaluator AgentEvaluator() for result in results: evaluator.add_result( task_idresult.task_id, is_successresult.is_success, partial_scoreresult.partial_score, trajectoryresult.trajectory, latency_msresult.latency_ms ) return { result_layer: evaluator.compute_result_layer(), trajectory_layer: evaluator.compute_trajectory_layer(), system_layer: evaluator.compute_system_layer() }并发数不要一开始就拉满先压单线程跑通流程。批量执行时要注意不同任务之间可能存在共享状态需要做好隔离避免一个任务的失败污染另一个任务的结果。8. 常见问题与排查方法问题现象可能原因排查方式解决方案任务完成率很低但单看输出文本正确成功判定条件过严检查 success_checker 的判定逻辑拆分判定条件人工抽检确认工具调用总是参数错误工具 Schema 定义不清晰查看轨迹日志中的参数快照完善工具描述和参数示例Agent 反复重试同一错误缺乏错误反馈机制统计轨迹中的重复工具调用在提示词中加入错误原因摘要限制最大重试次数任务在固定步骤后超时上下文过长导致推理变慢查看耗时分布和 Token 消耗压缩上下文、启用模型缓存、设置超时阈值并发升高后错误率暴涨系统资源不足或限流未生效压测并观察系统资源接入限流、增加重试退避策略Agent 偶尔成功偶尔失败模型随机性或提示词不稳定多次重复运行同一批任务降低采样温度优化提示词结构评测结果和线上表现不一致评测任务与真实场景有偏差对比线上日志与评测集分布定期从线上日志抽样补充评测集这里有一个常见的坑Agent 在单次评测中表现得很好但换成生产环境的真实输入后表现骤降。原因通常是评测集过拟合了特定提示词风格没有覆盖线上的长尾输入。工业级评估一定要保持评测集的持续更新从线上日志中定期补充新的任务样本。9. 工业级评估最佳实践评估体系和 Agent 本身一样需要迭代不是一次搭好就结束。第一把评估门槛嵌入到发布流程中。每次 Agent 修改无论是模型版本更新、提示词调整还是工具接口变更都必须跑一遍核心评测集通过门槛后才允许进入灰度。没有评测门槛保护任何优化都可能引入回归而不自知。第二建立失败案例库。每个失败轨迹都要分类记录是规划错误、工具调用错误、上下文丢失还是模型幻觉。积累到一定数量后你会发现大量失败集中在少数几个模式上修复这些模式就能显著提升整体表现。第三评估报告要可对比。不要只看单次评估的绝对值要看趋势。建议每次评估都记录 git commit、模型版本、评测集版本方便回溯性能变化。比如评估报告显示准确率从 85% 降到 70%如果拿不到历史版本信息就很难定位是哪个改动导致的。第四需要灰度对比时建议采用 AB 测试。将线上流量按一定比例分给新旧两个 Agent对比真实用户场景下的任务完成率、投诉率和用户满意度。这比任何离线评测都更能反映真实效果但需要更严格的配额管理和数据埋点。第五涉及代码执行、数据操作、文件读写类 Agent 时一定要在隔离环境中评测。不要让评测中的 Agent 真实操作生产数据库或未授权的文件系统。安全是第一位的任何 Agent 评测都必须设置权限边界。10. 总结与下一步工业级 Agent 评估的核心思路是结果层看“做得对不对”轨迹层看“做得顺不顺”系统层看“跑得稳不稳”。三层指标配合使用能帮你区分两个表面同样成功的 Agent 在实际工程价值上的真实差距。如果你想在团队里真正落地这套方案最先做两件事一是整理 30 到 50 个覆盖核心业务场景的评测任务集二是给现有 Agent 加上轨迹日志采集。有了这两样基础结果层和轨迹层的指标就能立刻算出来。系统层指标可以先从线上监控系统取数不必自己搭完整的压测平台。最容易踩的坑是过度依赖单一指标。你会发现某个 Agent 成功率很高但疯狂消费 Token或者延迟很低但遇到错误完全不会恢复。只有三层指标一起看才能看出真实水平和优化方向。后续可以在评估系统中加入 LLM 自动判定结果处理那些需要主观判断的任务也可以在评测集里加入多模态任务覆盖图表分析、截图识别类 Agent 场景。把这套框架跑通后Agent 的选型、优化回归和上线发布都会变得更有把握。