工业级 Agent 评估最让人头疼的不是跑不通而是看起来都能用实际投入生产后差距巨大。同样是调用同一个模型同一个任务有的 Agent 一次就能稳定完成有的第三次就卡在工具返回上有的输出质量不错但为了一个简单问题翻了十几个工具有的单条跑得很顺并发一上来就超时、丢日志、状态错乱。单独测任何一次你都觉得它能用真正的问题是用什么指标、按什么流程才能把这种差距量化出来。我最近在给内部 Agent 做评估时采用了一套三层指标结果层、轨迹层、系统层。结果层关注任务到底做成没有轨迹层关注执行过程是否合理系统层关注放到生产环境里是否稳定、可运维。这套方案适合正在做 Agent 开发、需要对比不同 Agent 方案、或者准备把 Agent 从 Demo 推向生产环境的团队。下面按实际落地顺序拆一遍。1. 为什么同样能完成任务Agent 的实际差距会这么大1.1 只看最终结果容易漏掉三个关键信息一个 Agent 能不能用最终自然是看“任务有没有完成”。但工业环境里“完成”和“稳定完成”之间隔着很多东西。结果层只能告诉你这条任务做完了没有输出长什么样。它回答不了三个问题这个结果是靠合理的规划路径得到的还是靠反复试错、随机运气撞出来的如果换一个输入顺序、换一个时间点、换一批并发请求结果还能一样吗出问题的时候日志里能不能看出是哪一步失败的系统能不能自动恢复这三个问题分别对应轨迹层和系统层。只看结果你会高估一个偶然跑通的 Agent也会低估一个还没有被调好的 Agent。1.2 三层评估各回答什么问题可以这样理解结果层Agent 做完了什么。轨迹层Agent 是怎么做完的。系统层Agent 在真实环境里能不能稳定、安全、可运维地完成。这三个层级不是并列关系而是递进关系。结果层是“面”轨迹层是“线”系统层是“体”。层级核心问题典型使用场景主要使用者结果层任务是否完成、产出质量如何快速对比两种方案产品、算法轨迹层执行路径是否合理、错误是否可恢复优化 Prompt 和工具调用开发、算法系统层并发和稳定性是否达标生产上线评估运维、技术负责人比如在选型阶段你可以先只看结果层快速过滤掉明显跑不通的方案。但进入优化阶段必须引入轨迹层否则你连 Agent 为什么失败都说不清楚。如果目标是上线系统层也必须有完整数据。1.3 先定评估单元再谈指标有些团队评估 Agent 时连“一次评估”是什么都没定义清楚。我建议把评估单元固定为一条输入任务对应的完整执行记录。这条记录至少应该包含任务 ID 和时间戳输入内容Agent 完整轨迹包括每一步思考、工具调用、返回、重试最终输出token 消耗、耗时、错误信息运行环境版本后面所有指标都是从这条记录里算出来的。没有这个基础前面讨论的任何指标都会变成口径之争。比如两个团队都说“成功率 90%”一个把输出格式错误算作失败另一个只把程序崩溃算作失败这两个数字根本不能比。2. 结果层最直观也最容易做出漂亮数字2.1 任务成功率不能只看“有没有报错”很多 Agent 系统里“成功”被定义为“没有抛异常”。这远远不够。同样是成功的任务可能是输出完整、格式正确、内容可用输出了几句无关内容但代码没报错自己编了一个合理的结果但根本没真正执行任务。第三种最危险我把它叫“幻觉成功”。Agent 没有实际完成任务却给出了一个看起来正确的答复。所以结果层的第一步是定义成功的标准尤其是最终输出校验。对于不同任务类型校验方式不同需要生成代码跑编译或单元测试需要提取信息比对结构化字段是否完整、是否匹配预期需要操作文件检查文件是否存在、大小、内容是否正确需要回答问题用规则或另一个模型做相关性判断。这里最重要的一点是校验必须独立于 Agent 本身不要让同一个 Agent 自己判断自己成功。2.2 结果层建议至少记录六类数据我通常会在结果层保留以下指标指标含义判断标准任务成功率通过校验的任务数 / 总任务数越高越好但要看合格线完成质量分对输出进行规则或模型打分满分 10 分结合实际场景平均耗时完成任务的总时长包含思考、调用工具、输出总成本token 消耗折算或直接费用每千次任务成本输出完整性必填字段或文件是否齐全缺项即扣分人工修正次数输出需要人工改几轮工业落地核心指标最后一项特别容易忽略。一个 Agent 能自动完成 90% 的工作但剩下 10% 每次都需要人工改格式它就不算真正可用。人工修正次数能反映真实生产代价。2.3 结果层的评估流程第一步准备一组覆盖正常、边界、异常输入的任务集。第二步用同一套任务集跑全部候选 Agent。第三步用独立校验逻辑检查所有输出。第四步汇总成结果层报告。实际落地时建议先跑小样本。我一般会先用 20 到 30 条任务做一轮快速验证确认校验规则没有歧义再扩大到几百条。不要一开始就把测试集拉大因为校验规则本身往往需要两三轮调整。先小规模把规则跑顺比后面发现口径不一致再返工要快得多。3. 轨迹层把过程拆开才看得见差距3.1 轨迹记录是评估的“黑匣子”结果层只有输入输出出了问题很难查。轨迹层解决的问题是当某个任务失败或表现差时你知道它到底在哪一步开始偏离。轨迹至少要有以下几类信息规划与思考每一步 Agent 自己输出的计划或理由工具调用调用了哪个工具、传了什么参数、返回了什么结果循环与重试同一个操作执行了几次状态变化上下文里新增了什么关键信息错误日志每一步的报错信息。缺少这些信息你看到的就只有“任务失败”四个字连失败原因都猜不出来。轨迹层的数据本质上是为了让评估从“能得分”变成“能定位”。3.2 规划质量好的路径是短且有效规划质量很难量化但有一些可观察信号工具调用次数少且每次调用都产生有效信息没有重复调用同一个工具没有来回震荡遇到失败时能快速切换到备选方案对简单任务不会做过多无关分析。反过来不好的路径通常表现为第一步还没有收集信息就先编一个结论反复调用同一个失败工具不换参数也不换方案一条简单的查询任务中途绕了五六个无关步骤上下文越来越长但关键信息没有沉淀。我评估时会看一个“无效步骤率”完整轨迹中对最终输出没有贡献的步骤占总步骤的比例。这个指标不追求绝对值为零但超过 30% 时基本可以判定规划能力偏弱。注意这里的“无效”需要人工或规则判断不能只按工具调用次数来算。3.3 工具调用成功率与错误恢复工具调用是 Agent 最容易出错的地方。常见失败类型包括参数格式错误缺少必填字段返回内容超长或解析失败工具本身不可用、超时权限不足。这些错误本身不一定致命关键是 Agent 能不能恢复。三个场景值得对比工具返回错误Agent 能读懂错误信息并修正参数重试Agent 连续失败三次仍然重复同一个参数Agent 在经历错误后直接把错误信息当作用户回答夸出去。第三个是最危险的。评估时应该专门构造一批“工具会报错”的任务看 Agent 在错误发生后是否还能给出正确输出。如果只跑正常任务工具调用层的问题基本是看不到的。3.4 token 消耗、上下文长度与效率轨迹层的另一个价值是成本归因。单纯的结果层只能统计总 token但无法知道 token 花在了哪里。建议按以下维度拆分思考 token每一步推理消耗工具调用 token工具描述和返回内容消耗系统 token系统提示词和固定上下文重试 token由失败重试浪费的部分无效步骤 token规划偏差导致的浪费。一般我会看一个“有效利用率”有效步骤 token / 总 token。如果任务成功了但 token 利用率很低说明方案能跑通不等于方案高效。生产环境里这种浪费直接变成成本。3.5 轨迹记录怎么存轨迹需要结构化存储不能只在终端打印。一个简化示例{ task_id: task-0042, status: success, steps: [ { type: plan, content: 先查询订单状态再确认退款金额, tokens: 180 }, { type: tool_call, tool: query_order, input: {order_id: A2301}, output_summary: order found, statuspaid, status: ok }, { type: tool_call, tool: query_order, input: {}, error: missing required field order_id, retry_count: 2 } ], total_tokens: 2300, duration_s: 42.3 }每条任务执行完后把这种 JSON 写入统一目录评估脚本再批量统计。这里有一个经验轨迹文件命名一定要带任务 ID 和时间戳否则并发执行时很容易互相覆盖。丢一次轨迹整条任务的评估就白做了。4. 系统层单条跑通不代表能上线4.1 稳定性同一个任务跑十次结果一致吗Agent 有随机性。即便同一个模型、同一个输入两次输出也可能不同。系统层首先要看稳定性重复执行同一批任务成功率波动大不大结果质量分的标准差高不高运行时间忽快忽慢偶发报错有没有规律稳定性评估不能只看平均值。一个 Agent 平均成功率 95%但某类任务经常失败平均值也会被拉得像模像样。所以评估时应该给任务集分组按任务类型单独看成功率。例如任务类型样本数成功率平均耗时文本分类20097%3s代码生成20088%18s文件处理10075%65s能看到哪类任务最弱才能有针对性地改进。4.2 并发、延迟与超时Agent 从 Demo 到服务必须评估两个指标并发能力和端到端延迟。并发测试时需要注意Agent 不是一次请求返回结果而是多轮内部循环。高并发下模型服务可能限流需要重试机制。并发数一上来日志和轨迹文件可能互相覆盖要提前规划好文件命名。超时是另一个高频问题。很多 Agent 服务会遇到类似“Agent execution terminated due to error”或“execution provider did not respond in time”的报错。出现这类问题时第一反应不是调大超时而是先确认是哪一个环节超时模型推理超时工具调用超时重试次数过多累积超时把环节拆开才能决定是调大超时、增加重试还是换更快的模型。笼统地调大超时只会让一个坏任务拖得更久还会占用并发资源。4.3 安全与权限Agent 评估不能漏的一块Agent 能调用工具、操作文件、访问系统权限边界直接决定生产安全。系统层至少要有四类检查最小权限Agent 有没有使用超出任务范围的账号或密钥输入校验用户输入里包含不该执行的指令时Agent 是否会识别并拒绝敏感信息日志和轨迹记录里有没有明文密码、手机号、身份证号操作审计Agent 对文件、数据库、系统做了什么能不能在日志里完整还原这些不是安全团队单独的事。做 Agent 评估时至少要跑一组“异常指令”测试在任务输入里放一段不应该被执行的命令看 Agent 是否拒绝。写这种测试时应该使用完全无害的示例指向本地测试目录避免任何真实系统操作风险。4.4 可观测性没有日志评估就无法定位Agent 评估的最终产品不是一组分数而是一套能定位问题的日志体系。我建议每次执行至少输出三个文件概览 JSON任务 ID、状态、耗时、token、结果摘要轨迹 JSON完整步骤、工具调用、错误信息资源日志内存、CPU、文件句柄等按任务 ID 关联。这样三层数据就齐了。接下来要解决一个关键问题这些指标如何合成分数。没有合成规则评估就只是数据陈列不是可执行的决策依据。5. 结果层、轨迹层、系统层如何合成分数5.1 不同场景权重不一样三层指标不能直接平均。一个客服问答类 Agent结果正确性和响应稳定性最重要轨迹是否漂亮反而是次要的一个自动写代码、操作仓库的 Agent轨迹质量和错误恢复能力很关键一个调度类 Agent系统层稳定性几乎排第一。因此评估方案必须允许按场景配权重。下面是一个示例配置应用场景结果层轨迹层系统层客服问答50%20%30%代码生成40%40%20%流程调度30%20%50%通用对比40%30%30%这个权重不是标准答案而是提醒你评估一定要回到业务目标上。不同目标对应不同权重不要一套权重走天下。5.2 分数怎么算每一层内部先归一化到 0 到 100 分再加权得到总分。归一化方式要提前定好。举个例子结果层成功率达到 95% 以上记满分每下降 5 个百分点扣 10 分质量分低于 6 分直接扣 20 分平均耗时高于阈值每超过 30% 扣 5 分。轨迹层无效步骤率 0 到 10% 记满分每增加 10% 扣 10 分工具调用失败后恢复率低于 90% 扣 15 分有效 token 利用率低于 50% 扣 10 分。系统层同组任务重复执行成功率波动不超过 5% 记满分超过 10% 扣 15 分超时任务占比高于 5% 扣 10 分出现访问越权或敏感信息泄漏直接 0 分。这些阈值是示例不同团队可以根据自己的容错度调整。关键是提前定义并固化避免每次评估临时改口径。口径不稳定历史结果就没法对比。5.3 评估报告怎么出一份可用的评估报告至少包含三块总体结论总分、达标线、是否适合上线分层明细三层各自得分和关键指标失败样本列表每一条失败任务的 ID、失败环节、错误信息、对应轨迹文件路径。报告里最不能省的是失败样本。没有失败样本的评估报告只能证明“测过”不能证明“能用”。后续排查和改进几乎全靠这些失败样本定位问题。6. 实战落地从测试集到持续回归6.1 测试集怎么建测试集质量决定评估可信度。比较好的测试集应该包含正常任务覆盖主要业务场景边界任务空输入、超长输入、格式不规范、字段缺失异常任务工具报错、数据库无数据、文件不存在对抗任务输入中包含明显的越权指令或虚假信息。我一般会先建一个最小集几十条专门用来调通评估流程。等流程稳定了再扩充到几百甚至上千条。测试集不要一次做得太大因为标注和校验规则往往需要迭代。6.2 测试集污染最隐蔽的坑如果测试集里的样本已经被 Agent 在开发过程中看过评估结果就不可信。常见污染源调试时把测试样本贴进过 Prompt测试样本来自线上日志而 Agent 的 few-shot 示例也来自同一批日志校验规则里写了预期答案但 Agent 的训练数据已经包含过这个答案。避免污染的常见做法测试集只从评估环境读取不参与任何 Prompt 或示例构建。每次评估前可以抽查几条任务确认 Agent 在本次运行中没有用到测试集里的示例内容。6.3 随机性怎么处理Agent 每次输出不完全一样。为了得到稳定结论通常需要同一个样本至少跑 3 到 5 次成功率、质量分取平均值记录每次运行的完整轨迹便于复查差异。但也不是所有任务都值得重复跑。对于耗时很长的复杂任务可以先用一次结果做筛选把差异较大的样本挑出来再做多轮复测。这样既控制了成本也不会丢失关键信息。6.4 环境差异框架、工具和模型版本都要固定很多人对比 Agent 时只关注模型和 Prompt忽略了框架差异。从实际经验看不同框架对工具返回格式、错误处理、上下文管理的默认行为差别很大最终结果也会明显受影响。所以做对比评估时必须明确固定框架只对比 Agent 策略固定模型版本记录到报告里固定工具版本和 API 地址所有候选 Agent 在同一环境、同一轮完成评估。如果发现结果异常先检查环境差异再怀疑 Agent 能力。很多时候 Agent 变差不是因为策略改了而是模型版本或工具版本变了。7. Agent 表现差时按什么顺序排查7.1 先把现象归类遇到 Agent 表现差先不要急着改 Prompt。先把现象归到三层中现象最可能归属任务完成但结果质量差结果层任务失败、中途卡住、重复调用轨迹层并发一高就报错、超时、日志丢失系统层偶发失败、换环境就失败系统层加环境现象归类对了排查方向才不会偏。7.2 逐层排查顺序排查链路建议从结果层开始逐层往下先看失败样本的最终输出是完全没有输出还是输出了但校验不通过再看轨迹在哪个步骤开始偏离是工具调用报错、规划错误还是模型自己绕晕了最后看系统当时的并发、延迟、限流、资源占用有没有异常按这个顺序走大多数问题都能找到证据。反过来很多人第一步就去改 Prompt结果改完还是失败因为没有定位到底层原因。7.3 回归基线怎么维护持续优化时每次改动都重新跑同一套测试集并保留历史轨迹。具体做法是评估输出按版本号命名例如v1.1.0-results.jsonl每次完成后生成对比报告本次和上次差异在哪只有三层指标都没有明显回退才允许提交改动。能做到这一步Agent 优化就从一个“感觉变好了”的过程变成一个“有数据能证明变好了”的过程。遇到线上问题也能快速回溯到具体改动。三层评估方案不是一次性的项目是需要长期维护的工程能力。我第一次搭建时花了比较多时间在测试集和轨迹存储上后来发现这些投入非常值。真正决定 Agent 能不能上生产的不是某一次 Demo 跑得多顺而是当任务批量来了、工具报错时、并发抬高时你手里有没有数据能说清楚它到底行不行。建议先做小再做大把第一份评估报告跑出来后面迭代就有依据了。