同样能完成任务的两个 Agent差距在哪里很多时候两个 Agent 都能交付正确答案但其中一个多调了 3 倍工具、多走了 5 轮无效步骤另一个在工具调用失败后要整段重开还有一个是遇到上游接口抖动就直接中止。如果只看“任务完成率”这三个 Agent 的分数可能完全一样但工程上的成本、稳定性和可维护性差了好几个量级。本文给出一套可直接落地的 Agent 评估方案按“结果层、轨迹层、系统层”三层拆指标。它不绑定具体框架适合多 Agent 选型、Agent 能力评审、版本升级回归、以及把 Agent 接入生产环境前的验收。看完之后你可以用它把“感觉某个 Agent 更好”变成一组可复现的量化结论。1. Agent 三层评估方案核心能力速览在拆指标之前先把整体框架放在一张表里。这个框架的核心不是堆指标而是让每一层回答不同的问题结果层回答“任务到底完成得怎么样”轨迹层回答“Agent 是怎么走完这个过程的”系统层回答“这套流程跑起来稳不稳、贵不贵”。能力项说明适用对象LLM Agent、智能体框架、工作流编排、客服/工具调用型 Agent结果层指标任务完成率、正确率、部分完成率、多步骤端到端成功率轨迹层指标工具调用有效率、步数效率、失败恢复率、重复尝试率、越界率系统层指标P50/P95 延迟、单任务 Token 消耗、单任务成本、超时率、并发稳定性评估数据核心路径用例 边界用例 异常工具场景用例落地方式离线评测集 轨迹日志 评分脚本配合线上抽样回归是否依赖特定框架不依赖支持任何能输出结构化日志的 Agent输出产物三层指标报告、对比基线、回归趋势、成本预算适合场景Agent 选型对比、版本升级回归、上线前验收、效果巡检需要说明的是这套方案给出的指标口径和计算方式比具体每一个数字更重要。不同团队实现能力不同只要把口径统一横向对比就有意义。2. 为什么“结果正确”本身不够量化 Agent很多团队评估 Agent 时只看一个指标任务完成率。它的优点是直观缺点是把 Agent 的“过程质量”完全抹掉了。举一个很常见的例子需求是“查询用户近 3 个月的订单并提取其中未发货的订单列表”。Agent A 用两次工具调用完成先查用户信息再传用户 ID 查订单一次过滤本地完成。Agent B 也完成了但先后查了订单、查用户、又查订单、再查售后、再查订单最后多轮兜底总算拼出了答案。两者最终结果一致完成率都是 100%。但 Agent B 的 Token 消耗可能是 A 的 4 倍响应时间可能接近超时上限而且如果上游订单接口偶尔抖动B 的整条链路会因为步骤冗余而更容易失败。另一个典型问题是“中途失败没人管”。有的 Agent 一旦某次工具调用异常就停止有的 Agent 会自动重试有的 Agent 会换一个路径继续。只看最终成功率团队无法知道异常场景下哪个设计更稳也无法判断是否要为恢复能力增加预算。还有一个被忽视的问题是安全越界。Agent 可能“完成任务”但没有遵守系统边界比如调用了超出权限的工具、访问了未授权数据、在外呼任务中做了未确认操作。这些行为不会体现在最终答案正确率里但放到生产环境就是事故。所以结果是必要不充分条件。要量化两个 Agent 的差距必须把“任务完成质量”“路径效率”“运行稳定性”这三个维度拆开评估。这就是结果层、轨迹层、系统层三层评估的基本动机。3. 结果层先量化“任务的交付质量”结果层是所有评估里最接近用户感知的一层。它回答的问题是Agent 最终输出能不能用是不是完全符合用户目标。这一层最容易做但要做好也不简单问题在于“正确”的标准必须提前定义。3.1 结果层推荐的指标指标定义计算方式任务完成率正常结束并产出最终结果的用例占比完成用例数 ÷ 总用例数完全正确率输出与标准答案完全一致占比完全正确用例数 ÷ 总用例数部分正确率输出包含标准答案的关键要素但存在遗漏部分正确用例数 ÷ 总用例数端到端成功率所有必需步骤严格完成且无违规的用例占比严格通过用例数 ÷ 总用例数关键要素覆盖率核心目标点被覆盖的比率命中关键要素数 ÷ 总关键要素数这里最容易踩的坑是只统计“完成率”而不管“怎么算完成”。建议每个评估用例都附一个结构化评审卡标注三个东西必须包含的关键信息、必须不能出现的错误结论、允许的模糊范围。比如“查询订单”用例关键要素包括订单数量正确、订单状态过滤正确、结果按时间排序允许的模糊范围是输出格式可以不同但不能缺少订单号。3.2 结果评分示例一条评估记录可以设计成 JSON 结构评分脚本按规则聚合成结果层指标{ task_id: tk_001, case_name: 查询未发货订单, expected: { must_include: [订单号, 未发货状态, 用户ID], must_not_contain: [已发货订单, 无关用户订单] }, agent_output: { order_ids: [A1001, A1002], status: [pending, pending], user_id: U_88 } }评分的规则可以简单设计关键要素命中一个给 1 分三个全中且没有错误项判为完全正确缺一个关键要素判为部分正确出现 must_not_contain 中的内容直接判错。这类用例建议准备 50 到 100 条覆盖典型主流程、权限边界、空结果、大列表、特殊格式输入等场景。评测越贴近真实输入结果层数据的参考价值越高。4. 轨迹层量化“Agent 的路径质量”轨迹层是整个评估框架里最容易被忽略、但又最影响生产可用性的一层。它衡量的是 Agent 做了什么而不是它最终输出了什么。对于一个需要接入生产环境的 Agent轨迹质量常常比最终答案更重要因为它直接决定成本、故障概率和后续维护难度。4.1 轨迹层推荐的指标指标定义计算方式工具调用有效率成功完成预期目的的工具调用次数 ÷ 工具调用总次数有效调用 / 总调用平均步数完成单任务平均执行步骤数总步数 ÷ 完成用例数步数效率实际步数与标准路径步数的比值标准步数 / 实际步数失败恢复率工具调用失败后继续完成任务的用例占比失败后恢复用例数 ÷ 失败用例总数重复尝试率同一工具、相同参数被重复调用的次数重复调用次数 ÷ 总调用次数越界率调用未授权工具或超出任务范围的次数越界次数 ÷ 总调用次数这里需要解释一下“步数效率”。它的目标是鼓励 Agent 用接近人工标准流程的路径完成任务而不是绕路。如果人工标准需要 3 步Agent 用了 5 步效率就是 0.6如果用了 2 步效率就是 1.5可以设一个上限避免无限压缩步数导致漏掉必要检查。4.2 为什么轨迹层能看出“天差地别”我举一个团队评估两个 Agent 的典型案例。底层工具相同一个是基于简单 ReAct 规则实现另一个是多步规划 工具选择。同样是“查询用户订单并计算退款总额”Agent A 先调“获取用户信息”拿到 user_id 后再调“查询订单”如果订单量大它会继续调“查询订单详情”最后在上下文里汇总退款金额。整体步数稳定在 3 到 4 步。Agent B 在每一轮都会反复调用“获取用户信息”原因是它没有把 user_id 作为已确认状态记住。最终结果也能算出退款总额但平均步数 7 步工具调用多了接近一倍。只看结果层两者正确率都高看轨迹层Agent B 的重复调用率、平均步数、Token 消耗全面落后。这个差距在后期接入大批量任务时会直接变成成本差距。另一个典型差距是失败恢复。给两个 Agent 中间塞一个不稳定的上游接口Agent 好的设计第一次调用失败后能根据报错信息判断是临时超时自动重试一次重试仍然失败会换用备选工具读取缓存数据。Agent 弱的设计调用失败后直接结束返回一个“请稍后再试”的兜底话术。从结果层看弱 Agent 在异常用例上的完成率为 0从轨迹层看弱点在于没有设计恢复路径。这个结论能直接指导下一轮开发。4.3 轨迹日志的记录格式轨迹层评估要能落地前提是每个 Agent 步骤都输出结构化日志。建议统一记录字段{ agent_id: agent_x, task_id: tk_001, step_index: 3, actor: agent, action_type: tool_call, tool_name: query_order, params: {user_id: U_88}, observation: { status: success, code: 200, message: ok, items_count: 32 }, latency_ms: 850, token_usage: {prompt_tokens: 4200, completion_tokens: 560} }有了这样的日志任何 Agent 框架都可以导出同一份轨迹数据评估脚本不再依赖内部实现。也就是说只要路径日志格式一致A 框架和 B 框架也可以做横向对比。5. 系统层把“运行成本与稳定性”量化出来系统层回答的是这个 Agent 在真实运行环境里能不能按时、稳定、低成本地跑完任务。如果结果层看“对不对”轨迹层看“怎么走”系统层看“跑得动吗”。5.1 系统层推荐的指标指标定义计算方式响应延迟 P50/P95单次请求完成时间的中位数和高位值从日志中取百分位步骤间延迟单步 Agent 决策与工具调用之间的耗时记录时间戳差值单任务 Token 消耗每个任务平均消耗的输入输出 Token 数总 Token ÷ 任务数单任务成本按 Token 单价折算的单任务费用输入 Token × 单价 输出 Token × 单价超时率超过预设任务时限的用例占比超时用例 ÷ 总用例重试率因临时错误自动重试的调用占比重试次数 ÷ 调用次数并发成功率叠加并发后任务的完成率并发场景完成用例 ÷ 并发总用例这些指标作用不同P50 反映正常体验P95 反映最差体验Token 消耗反映成本趋势重试率反映外部依赖的脆弱程度。5.2 如何观察系统层数据系统层评估不要求单独写一套复杂系统可以直接复用轨迹日志在每一条记录里加时间戳、Token 用量和重试标记。聚合时按用例分组算出汇总值。举一个计算 P95 延迟的例子import json import statistics def load_records(path: str) - list: records [] with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if line: records.append(json.loads(line)) return records def system_metrics(records: list): per_task_latency {} token_count {} for rec in records: task_id rec[task_id] latency rec.get(latency_ms, 0) tokens rec.get(token_usage, {}) per_task_latency.setdefault(task_id, []).append(latency) token_count[task_id] token_count.get( task_id, 0 ) tokens.get(prompt_tokens, 0) tokens.get(completion_tokens, 0) task_latencies [sum(v) for v in per_task_latency.values()] token_usage list(token_count.values()) task_latencies_sorted sorted(task_latencies) n len(task_latencies_sorted) p95_index min(n - 1, int(n * 0.95)) p95_latency task_latencies_sorted[p95_index] print(f总任务数: {n}) print(fP50 延迟: {statistics.median(task_latencies):.0f} ms) print(fP95 延迟: {p95_latency:.0f} ms) print(f平均 Token 消耗: {statistics.mean(token_usage):.0f} tokens/task) if __name__ __main__: system_metrics(load_records(agent_traces.jsonl))这样的脚本不需要特定框架任何能输出 JSONL 轨迹的 Agent 都能接入。后面如果要对比不同 Agent只要在同一批用例上分别跑一次输出两份聚合报告即可。5.3 并发与稳定性测试系统层还需要考虑并发。单任务跑得再快并发一上来就可能因为工具限流、LLM 超时或状态冲突导致大量失败。建议在评估环境里用小并发做一轮烟雾测试比如同时发 5 到 10 个任务观察失败率和 P95 的变化。并发测试中出现状态互相覆盖的问题往往是 Agent 内部缓存状态没有隔离这类问题在单任务评估中完全看不到。6. 落地一套 Agent 评估流水线三层指标讲完之后最关键的问题是怎么落地。我的建议是从小规模开始不要一上来就搭完整平台。先按下面四个步骤搭建最小评估流水线后续再逐步扩展。6.1 第一步确定评测集评测集建议分三类核心路径用例日常任务中最高频的 30 到 50 条要求每个用例有标准答案结构化字段。边界与异常用例包含空输入、长文本、超大订单列表、非法参数、外部工具超时、权限不足等场景20 到 30 条。回归样本从生产日志里抽样 20 条真实历史请求标注人工答案用于版本升级后的回归对比。评测集不要只追求数量要保证覆盖业务典型场景和极限场景。100 条高质量、结构清晰的评测用例价值远高于 500 条“只给一个最终答案”的用例。6.2 第二步设计轨迹日志所有 Agent 在评估环境跑任务时统一记录结果、轨迹、系统三个维度数据。具体格式可以按第 4 节里的 JSONL 设计。关键是要保证每个任务 ID 全局唯一同一个任务重跑时能通过重试标记区分首次与后续尝试。6.3 第三步编写评分脚本评分脚本按三层分别聚合结果层计算任务完成率、完全正确率、关键要素覆盖率。轨迹层计算平均步数、工具调用有效率、失败恢复率、重复尝试率。系统层计算 P50/P95 延迟、Token 消耗、成本估算、超时率。评分脚本只依赖 JSONL 轨迹文件不依赖具体 Agent 实现。这样后续替换模型、更换 Agent 框架时评估逻辑不用重写。6.4 第四步建立基线对比推荐先跑一次当前线上 Agent把三层指标存为基线。后续任何模型升级、提示词改动、框架迁移都在同一评测集上重跑并生成对比报告。如果结果层基本保持但轨迹层平均步数下降、重复调用率下降说明这次改动在路径效率上是正向的。下面给一个简单的结果层聚合脚本def evaluate_result_layer(records, cases): correct_count 0 partial_count 0 fail_count 0 for case in cases: # case 里包含每个任务的标准结果 expected_keys set(case[expected_keys]) output_keys set(case[agent_output_keys]) if expected_keys output_keys: correct_count 1 elif expected_keys output_keys: partial_count 1 else: fail_count 1 total len(cases) print(f完全正确率: {correct_count / total:.2%}) print(f部分正确率: {partial_count / total:.2%}) print(f失败率: {fail_count / total:.2%})这个脚本只是为了演示计算逻辑真实场景需要把“结构化标准答案”解析逻辑做细并对关键要素做自动或人工判定。6.5 什么样的评估结果算“通过”三层评估不是简单看总分而是看业务风险。建议按三层设定门槛层级推荐最低门槛说明结果层端到端成功率 ≥ 90%低于这个值直接堵塞上线轨迹层重复尝试率 ≤ 10%失败恢复率 ≥ 70%异常场景必须有恢复能力系统层P95 延迟在预算内单任务成本不超预算成本不可控时需优化路径不同业务可以调整但门槛必须在评估前定好否则会出现“结果不错但成本爆炸”的情况这类问题在生产环境很难被及时拦截。7. 常见评估问题与排查方法评估过程本身也会踩坑下面把最常见的问题整理成一张排查表。问题现象可能原因排查方式解决方案结果层两个 Agent 分数一样但轨迹层差异大评估用例过于简单区分度不足检查评测集里是否都是“一步能查完”的任务增加多步骤任务、异常恢复用例重复运行同一评测任务结果不一致外部工具有真实副作用或 LLM 采样不稳定查看轨迹日志中工具调用是否被污染评估环境使用 mock 或桩工具固定采样参数LLM-as-judge 打出来的分不稳定评分标准描述不具体样本顺序影响判断抽查几条被误判的样本把评分规则改成结构化关键要素匹配单任务跑得好并发跑就失败状态没有隔离、工具限流或上下文串号看延迟和错误码分布增加并发烟雾测试修复状态隔离评估后发现成本比预期高几倍轨迹层重复调用率高Agent 在无意义循环统计重复工具调用次数和 Token 消耗优化规划逻辑对重复调用设置熔断升级模型后结果正确但整体变慢模型推理延迟变大或 Token 输出变长对比系统层 P95 和 Token 消耗评估是否可接受或换用更快模型失败恢复率很低Agent 没有设计异常分支或重试机制检查工具报错后的实际动作加入重试和退避策略补充边界案例标准答案覆盖不到新场景评估失真评测集与现实需求漂移对比生产日志和评估用例分布定期抽样生产日志补充评测集这里要特别提醒一个误区评估用例不要直接复用生产环境真实用户数据除非已经完成脱敏并确认合规。尤其涉及个人订单、人脸、声音、证件信息等敏感内容时评估数据要走专门的脱敏流程避免把真实用户数据用于测试产生隐私风险。8. 工业级 Agent 评估的最佳实践最后写几条工程实践都是踩过不少坑后总结出来的。建议从 50 到 100 条用例起步而不是一开始追求 1000 条。先保证核心路径和边界用例覆盖把评估框架跑通后再扩充数据集。评测集不是一次性资产每两周抽样一次生产日志补充新的高频场景和失败样本避免评估集和实际业务逐渐脱节。轨迹日志是评估体系的命脉。每个 Agent 步骤都要记录 actor、动作类型、工具名、参数、观察结果、延迟、Token 用量并且每条日志带上任务 ID 和步骤序号。没有这份日志轨迹层指标就无从计算排查问题也会变成大海捞针。任何 Agent 改动无论是换模型、换提示词、换工具路由策略都要在同一评测集上跑一遍对比三层指标变化。即使结果层小幅波动只要轨迹层成本明显下降改动也是值得推荐的。上线之后还要做线上抽样回归。从生产环境抽样拉取真实轨迹按同样的三层口径定期计算线上效果与离线评测基线对比。如果线上结果偏移比较大说明评测集的分布和真实业务已经有偏差。还有一个很容易被忽略的点评估过程中如果使用 LLM-as-judge评分用的模型要固定版本、固定 prompt并且要定期抽样人工复核。自动评分和人工评分的一致性要控制在合理范围内否则评估指标本身就成了新噪音。最后强调合规边界。Agent 接入生产环境前如果涉及调用外部系统、读取业务数据、执行对外动作必须确认该动作在用户授权范围内并在评估用例中加入“禁止越权”“需要二次确认”等护栏检查。这类检查应该放在轨迹层的越界率里而不是靠事后抽查。9. 总结从三个动作开始整套三层评估方案看起来内容不少但如果现在就动手先做三件事先拿 20 条核心业务用例按第 6 节的方式标注标准答案这会产生第一版评估集。再给现有 Agent 加一个统一 JSONL 轨迹记录器确保每个步骤都有工具、参数、耗时、Token 四类信息。然后写一个最简的聚合脚本输出结果层完成率、轨迹层平均步数和重复调用率、系统层 P95 延迟和单任务 Token 消耗。这三个动作做完你就能看到第一个有价值的输出两份不同配置的 Agent在同一个评测集上展示出的差异曲线。后续再逐步扩大评测集、增加并发测试、引入成本预算和护栏检查这套评估体系就能支撑 Agent 从开发、上线到月度量化的完整闭环。Agent 开发本身还在快速迭代但“结果、轨迹、系统”三层评估的方法不会轻易过时。下一个版本升级来临之前先把这三层指标跑通你就能比大部分团队更早发现“看起来一样”背后的真实差距。