Agent评测中“超时算失败吗”？关键看分母口径与终态设计-北京尧图网络

1. 做Agent评测久了你会发现“超时算不算失败”是个假问题做Agent效果评估这几年我遇到最能引发争论的一句话就是“Agent 超时算失败吗”直接回答“算”或“不算”都太轻了因为真正的问题不在分子而在分母一次评测任务里超时的那个样本到底该不该留在分母里同一个数据集、同一个Agent把“超时”当作失败成功率可能只有68%把“超时”从分母里剔除成功率立刻能到82%。这个差距足够改变“能不能上线”的决策。所以与其站在会议室里吵“超时算不算失败”不如先把评估的分母说清楚分母里的每一类样本是怎么来的、超时样本有没有资格留在分母里、分子分母是不是同一套口径。这篇文章就围绕这三件事展开。1.1 一次让我重新看分母的评测现场之前接了一个电商客服Agent的项目。任务设计得很简单用户说“收到商品破损需要退货”Agent需要先确认订单号再调用退货申请接口最后向用户返回退款结果。评测环境里放了几十条模拟对话基本覆盖正常退货、商品已停售、退款金额计算错误等场景。有一类任务让我印象特别深Agent已经准确地理解了用户意图也找到了订单号但在调用退款接口那一步接口服务端迟迟没有响应。Agent按预设逻辑重试了三次每次都是5秒无响应最后整个任务运行时间打到了120秒上限执行器强制终止。任务状态被系统记成了“超时未完成”。问题来了。这个任务不是“推理错了”不是“生成了虚假信息”也不是“调用了错误的接口”它只是在规定时间内没有跑完。如果用经典的成功/失败二元判定它很自然地被算成失败。但一些同事觉得不合理外部接口抖动不是Agent的错任务本身应该算“无效样本”要从分母里去掉。另一拨同事则认为用户等了120秒没等到结果在真实产品里这就是失败凭什么从分母里删掉我当时没有急着表态而是先把所有“超时未完成”的trace抓了出来。结果发现里面既有“外部接口抖动导致整任务超时”的样本也有“Agent陷入相同动作死循环直到超时”的样本还有“Agent单步推理花了80秒”的样本。如果把这三类混在一起直接决定“算不算失败”后续任何分析都站不住脚。那个项目之后我养成了一个习惯在讨论指标前先把分母里的每一种案例都摊开看一遍。1.2 “失败”和“未完成”是两种不一样的问题很多人会把“失败”和“超时”放在同一个桶里本质上是把两类不同的问题混为一谈。“失败”通常指Agent给出了一个错误的、有害的、不可用的结果。比如用户问退货政策Agent编造了一个不存在的补贴规则或者用户要求取消订单Agent反而调用了确认收货接口。这类问题直接影响产品安全必须拦截也必须算进负向指标。“超时”则是指Agent没有在预算时间内给出结果它更多是一种“未完成”状态。未完成可能是Agent策略缺陷比如反复调用同一个工具、上下文越滚越长、思考链不收敛也可能是环境问题比如外部API慢、评测机器负载高、单个LLM调用超时。从用户视角看超时和失败都是“没办成事”。但从归因视角看超时是不是Agent的锅必须看trace。这个区分直接决定了一个评估体系该怎么写不能只保存一个布尔值“任务是否成功”而要把终态设计成多值把超时单独标记出来再根据评估目的决定它进不进入分母。2. 为什么分母才是Agent评估里真正的主线2.1 同一个Agent三种不同写法能算出三个成绩我们先用一个最简单的场景说明分母的威力。假设评测集一共20条任务Agent成功完成14条另外有2条因为用户信息缺失导致无法操作有1条Agent给出错误结论有3条因超时未完成。不同口径下成功率可以这样写口径分母定义成功率口径A全部20条任务14 / 20 70%口径B剔除2条不可执行任务后分母18条14 / 18 77.8%口径C再剔除3条超时任务分母15条14 / 15 93.3%同一个Agent同一个评测结果只因分母不一样从“勉强及格”变成“接近满分”。这不是夸大其词而是实际评估中天天发生的事情。更麻烦的是很多报告里只写了“任务成功率93.3%”没有写分母口径。读者会默认这个成绩来自全部任务然后误判Agent能力。等到线上部署时真实世界不会替你把超时任务“剔除”掉该慢的还是慢该失败的还是失败。所以我把分母称作“评估里的隐藏主线”分子代表Agent做到的部分分母代表“我们要求Agent处理什么”。分母如果被悄悄缩掉整个指标就失去了对真实场景的代表性。2.2 分母的每一项都代表一种“评估期望”分母不是简单的“任务总数”它更准确的定义应该是所有“被要求执行且具备执行条件”的任务数量。这里面有两层含义。第一层是“被要求执行”。如果一条任务放进评测集就代表我们期望Agent去完成它。那么这条任务就必须留在分母里直到任务被正式判定为不适用否则不能因为结果难看就悄悄删掉。第二层是“具备执行条件”。比如用户根本没有提供订单号而Agent无论如何都无法通过对话获取这个信息那这条任务就不具备完整执行条件。如果把它留在分母里会导致Agent明明已经礼貌地追问“请提供订单号”但依然被算成失败。问题是很多人会在跑完评测之后看到结果不好才想起来剔除样本这就很危险。事后的“剔除”很容易变成“删掉坏样本”让指标失去意义。我的建议是评测集建立时就要写一份《样本纳入与剔除规则》内容包括什么样的任务算可执行、什么情况下允许标记为“不适用/不可执行”、剔除一条任务需要经过几人确认。规则前置比事后再吵有用得多。2.3 分母不稳定版本对比就是自欺欺人Agent评测最常见的一个用途是版本对比这周迭代后成功率比上周提升了5个点是不是说明新策略更好这时候如果分母不稳定结论基本无效。举个例子上周评估A版本时某类“查询订单”任务超时了3条被算成失败这周评估B版本时评测集更新删掉了那3条超时严重的任务。你会发现B版本成功率涨了6个点但这不是B版本变强了而是分母被人为收缩了。更严格一点的做法是维护一份“锁定版本”的评估集。每次发布新Agent版本都要在同一个锁定评估集上跑回归测试如果确实要修改评测集必须走变更记录比如“新增5条多轮对话任务”“剔除2条不具备执行条件的任务”并保留上一版结果以便对齐。我把这种稳定分母称为“评估的锚”。有锚才能谈版本好坏没有锚所有百分比都是浮动的数字谁也说不过谁。3. 超时至少要拆成五类再谈要不要进分母3.1 五种常见超时的归因把超时统一当成一个状态是很偷懒的做法。实际评测中我至少会把超时拆成五类。归因不同处理方式就不同是否计入分母的标准也不同。超时类型典型触发原因主要责任方Agent策略是否背锅LLM推理超时模型服务响应慢、Token生成过长模型服务、提示词设计如果固定模型下仍超时Agent的上下文设计有责任工具调用超时外部API无响应、网络抖动外部依赖不一定是Agent策略问题但需要通过测试环境隔离来确认动作死循环Agent反复调用同一工具或发起同一请求Agent策略是属于明显的策略缺陷长思考不收敛推理链越来越长直到达到最大步数Agent策略是说明有触发钩子静默丢失评测批次超时评测环境资源不足被外部杀掉评测基础设施不是Agent任务本身的失败但需要单独披露以“动作死循环”为例。我看过一条traceAgent在判断“用户是否已经申请过退款”时连续12次调用同一个订单查询接口每次都返回同样的结果但Agent就是不进入下一步。这种情况下即使外部接口稳定任务也会超时。它显然是Agent策略的问题不能算“环境不可控”必须进失败分母。而“工具调用超时”则需要谨慎。如果评测环境使用真实外部服务服务抖动可能随机出现此时直接把超时计为Agent失败会高估Agent的缺陷也会让版本对比失去稳定性。更好的做法是在归因评估里先用mock服务或录制回放代替外部依赖只测Agent本身的决策质量在端到端评估里保留真实服务但把“外部依赖超时”单独记录不与策略超时混在一起。3.2 单步超时、任务超时和评测超时要分清很多人讨论“Agent超时”时其实说的是三种不同层级的东西。“单步超时”是指Agent在某一次LLM调用或某一次工具调用中等待时间超过了预设阈值。单步超时发生后系统可能选择重试也可能直接终止任务。单步超时属于过程指标它不直接决定任务成败但会积累成任务超时。“任务超时”是指从任务开始到结束整体运行时长超过了任务级预算。任务超时会产生真正的终态TIMEOUT。如果产品要求“5秒内必须给出回答”那任务超时就是产品意义上的失败如果产品允许异步处理那任务超时只能说明“这一轮没有完成”不能和“永久失败”画等号。“评测超时”则更上一层。它可能是指整个评测批次跑到某个时间点评测框架把所有还没结束的任务全部强杀。这种情况多是因为评测资源有限或某个任务异常导致排队堆积。评测超时并不一定代表Agent任务真的超时它可能是基础设施问题。所以评测框架应该在任务外面设置批次保护同时把“被评测框架强杀”和“Agent自身达到任务上限”分别记录。3.3 哪些场景下超时可以直接算失败我现在的判断标准是端到端产品评估里超时一般算失败纯策略归因评估里超时不直接算失败而是先标记再分析。具体来说有三条准则。第一如果产品对用户承诺“必须在规定时间内返回结果”那么规定时间内没有返回无论原因是策略还是环境从真实体验角度都算失败。这时候就不要纠结“是不是Agent的锅”先把它当作负向样本保留在主指标里。第二如果Agent允许在超时后继续异步处理并最终成功那么“超时”和“失败”要分开统计分别给出“按时完成率”和“最终完成率”不能只报告一个数字。第三如果评测目的是定位Agent策略问题那么超时要先归因只有策略相关超时才进失败分母外部依赖超时单独披露避免误导优化方向。说到底超时算不算失败取决于“你在评估什么”。4. 可落地的评估协议先定终态再定分母4.1 用多值终态替代二元成败在真正落地时我强烈建议不要用bool型字段存“是否成功”而是用一个枚举字段存任务的终态。以下是我常用的一套终态集合SUCCESS任务按预期完成结果可用。FAILED任务完成但产生了错误或不符预期的结果。TIMEOUT任务超时未完成。BLOCKED任务因外部依赖不可用而停滞且无法通过重试解决。NOT_EXECUTABLE任务在评测前就被判定为不具备执行条件。SKIPPED任务因为评测策略原因被跳过例如重复样本、数据缺失。PENDING任务尚未结束或结果尚未判定。这套终态的好处是它把“超时”和“失败”分开了。后续在计算指标时你可以根据指标的含义自由组合而不是在原始数据层面把信息合并掉。每条任务在记录终态时还要附带一个“判定依据”。比如SUCCESS要关联到最终动作和结果摘要TIMEOUT要关联到最后一步动作和原因分类NOT_EXECUTABLE要关联到“为什么不能执行”。这样任何人在复看指标时都能沿着trace走一遍而不是面对一堆不可追溯的数字。4.2 主指标和辅助指标的推荐写法基于多值终态我推荐在主报告中同时给出几个互补指标而不是只丢一个成功率。首先是核心成功率strict_success_rate SUCCESS / (SUCCESS FAILED TIMEOUT BLOCKED)这个公式里超时和阻塞都算进分母但并没有把TIMEOUT直接翻译成“失败”而是在整体成功率的框架里把未完成任务视为“未成功”。它适合用于端到端决策评估。然后是超时率timeout_rate TIMEOUT / (SUCCESS FAILED TIMEOUT BLOCKED)这个指标用来衡量Agent在时间约束下的稳健性即使核心成功率达标如果超时率超过5%还是要慎重上线。还可以加上adjusted_success_rate SUCCESS / (SUCCESS FAILED TIMEOUT BLOCKED NOT_EXECUTABLE)不过这个指标适合作为“参考口径”展示不推荐作为主指标因为把不适用任务包含进来会让分母失去针对性。在报告里我会固定写成两张表第一张是“原始结果分布”把各类终态数量列出来第二张是“指标层”给出核心成功率、超时率、重试率、平均任务时长等。任何人看到报告都能从原始分布反推指标是否合理而不是只看到一个被处理过的百分比。4.3 人工抽检时最容易犯的错自动状态判定并不能替人做所有判断。即使有了终态标签我依然坚持对评测结果做人工抽检。抽检比例至少覆盖全部TIMEOUT样本、30%的FAILED样本、10%的SUCCESS样本并且NOT_EXECUTABLE全部复核。人工抽检最常见的一个错误是看到“超时未完成”就直接把它标成“环境问题”认为可以剔除。正确的做法是先看trace里的最后几步动作。如果Agent连续三次调用同一个接口每次都拿到相同的报错但没有任何策略切换那这个超时更可能是Agent不会处理异常而不是环境问题。类似这种判断只有结合trace才能做不能凭印象。另一个容易犯的错是在人工复核时基于“这次结果看起来还行”来判定SUCCESS。比如Agent虽然完成了退货申请但申请金额算错了这应该是FAILED不是SUCCESS。人工复核一定要对照任务级评分卡逐项打分而不是通读一遍对话后拍脑袋。4.4 超时任务的trace记录规范为了让超时状态能在团队内对齐我会要求每个TIMEOUT任务至少记录以下字段字段说明task_id唯一的任务标识必须能关联到原始对话和动作序列timeout_type属于哪一类超时LLM、工具、死循环、长思考、批次last_action任务被终止前的最后一个动作timeout_point发生在哪个阶段比如“工具调用中”“生成回复中”retry_count任务内重试的总次数total_duration任务从开始到终止的总耗时token_usage任务累计消耗的Token数agent_version被测Agent的版本号避免版本混乱evaluation_version评测集和评估协议的版本号labeler_note人工复核员对终态和归因的备注有了这份记录超时就不再是一串没有上下文的失败计数而是一批可以深入分析的观测样本。遇到“要不要把这个超时样本从分母里去掉”的争论直接把记录拉出来对齐比任何主观判断都管用。5. 大家最纠结的三个实战问题5.1 第一次超时、重试成功算成功吗这个问题在真实调度系统中经常出现。Agent第一次调用退款接口超时执行器捕获异常后重试第二次成功。最终用户收到了退款成功的结果业务上确实是成功了。我建议在主指标里按最终终态SUCCESS计算同时单独记录“首次尝试成功率”和“重试率”。原因是如果只按最终状态计算超时问题会被完全淹没如果只按首次状态计算又会忽略重试机制的真实价值。两个指标分开看才能回答“Agent最终能不能完成任务”和“Agent是否经常把冗余成本转嫁给重试机制”。需要特别留意的是重试不是无代价的。如果Agent在退款接口上重试第一次接口其实已经扣款成功只是响应超时第二次重试就会造成重复扣款。所以重试必须建立在接口幂等的前提上。如果接口不幂等那“重试成功”不能简单算成功要至少标记一次异常行为甚至按失败处理。5.2 任务本身不可执行能踢出分母吗能踢但必须有前置规则不能事后踢。比如一条任务要求Agent查询“最近一笔订单的物流状态”但对话里用户没有提供订单号Agent也没有任何渠道获得订单号。这种情况下任务确实不可执行。只要Agent给出了合理的追问“请先提供订单号”它就不应该因为“没查成物流状态”被惩罚。但实际操作中很多人是在评测结束、看到Agent结果很差之后才开始给样本贴“不可执行”标签。这种行为非常危险如果一名评审认为“Agent回答得不好所以这条任务无效”分母就会变成筛选后的幸存者指标失真。正确的方式是在评测前建立可执行性筛查规则例如“缺少必要参数且Agent无法通过自身能力获取时标记为NOT_EXECUTABLE”。如果评测过程中发现新类型的不可执行样本也要走“先复核再剔除并更新规则”的流程。另外NOT_EXECUTABLE这类任务即使不算分母也要在报告里保留数量。因为“有多少任务根本没法执行”本身就是一个重要信息能反映评测集设计质量也能反映Agent在真实场景中的求助路径设计。5.3 样本很少时超时为什么会直接改写结论Agent评测往往成本不低很多团队为了快速验证只跑三五十条任务。这时候一个任务的比例就是2%到3%如果一次评测里有5条超时成功率被拉低的幅度会很惊人。假设一条评测集有30条任务其中成功19条、失败5条、超时6条。如果把超时算失败成功率是63.3%如果把超时从分母剔除成功率变成76%。两个数字差了将近13个百分点但Agent本身没有变。样本量小的时候尤其要看置信区间。我习惯在报告中加上一个简单说明在30条样本下即使成功率是很高的80%95%置信区间也会横跨60%到93%左右。也就是说单凭这个小批量结果根本不足以判断“Agent到底强不强”。因此小批量只能用于内部冒烟做上线决策时最好还是准备三百到五百条可执行任务的评测集并配合分层抽样保证难例、超时例、正常例都有足够数量。6. 我现在的处理原则默认算失败但单独标记绝不悄悄剔除把前面这些经验收拢我目前的做法可以用一句话概括在端到端Agent上线评估里默认把超时算作“未成功”放进分母归因分析时把超时单独标记按类型分析不直接等同于Agent失败原始评估数据永远保留多个终态绝不在报告里只留一个百分比。我还会在每份评估报告的开头写清楚“分母口径”。如果某个版本因为特殊原因需要做“剔除超时”的敏感性分析我也只把它放在附录里不参与主指标对比。否则主管和产品看完一个漂亮数字就拍板上线等线上真实流量一进来超时问题全都会原形毕露。最后再分享一个小技巧给每次评测设置一个“分母清单字段”。每一行样本除了有终态标签还有一个布尔字段“是否计入主分母”。这个字段默认是true除非有前置规则明确说不计。这样所有人在看报告时都能一眼看到“哪个样本被排除在分母外为什么被排除”而不是让分母变成一个永远说不出明细的黑洞。事实上我踩过很多次坑最后发现Agent评测并不缺更好的算法缺的往往是这种笨拙但诚实的统计纪律。

Agent评测中“超时算失败吗”？关键看分母口径与终态设计

相关推荐

IDEA Generate All Setter加强版：批量生成Setter的实战与避坑指南

repo文件baseurl三种形式详解：绝对路径、变量模板与文件路径

从零构建轻量级数据读取与响应框架rea：设计、实现与避坑指南

更多资讯

专科生论文冲刺：千笔与Checkjie实测对比与组合使用指南

Formbook多波次钓鱼攻击的技术演化与纵深防御实践

ASM磁盘组不完整导致spfile创建失败：ORA-15040排查与恢复

STM32智能小车实战：PWM调速、循迹、避障、跟随与红外遥控设计

波形和文稿对不齐，播客剪辑台怎样让字幕跟着声音走

C#火车订票系统：WinForm+SQL Server全链路实战指南

今日更新

微信云开发旅游小程序实战：LBS打卡+UGC社交全栈方案

金融AI代理平台核心拆解：从多代理协作到财报分析实战

基于大数据的智慧旅游推荐与可视化平台架构实践

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？