1. 从“一问一答”到“多步执行”评测对象变了方法论必须跟着变如果你最近半年在关注智能体Agent这个方向应该能明显感觉到一个变化以前大家聊的是“这个模型回答问题的准确率是多少”现在聊的是“这个智能体能不能自己把一件事从头到尾办完”。这个转变听起来只是任务变长了但真正做过评测的人都知道短程问答和长程任务之间的差距不是把题目加长那么简单而是整个评测范式都要推倒重来。我最初接触智能体评测的时候也是拿传统问答的那套思路去套——准备一批标准答案让智能体跑一遍对一对结果算个准确率就完事了。结果第一次跑长程任务就翻车了一个需要调用工具、分多步执行、中间还要根据反馈调整策略的任务智能体前面几步做得都对到第五步因为一个环境状态的细微变化走偏了最后输出完全不能用。但如果你只看最终结果它和“第一步就做错”得到的分数是一样的。这就暴露了短程评测方法论的根本局限它假设任务是一次性的、无状态的、结果可穷举的。而长程任务恰恰是有状态的、多步的、路径依赖的。所以这篇文章想聊的就是我在实际做智能体评测过程中从短程问答评测迁移到长程任务评测时踩过的坑、想明白的道理以及最后沉淀下来的一套可操作的方法。不管你是刚接触智能体评测的新手还是已经在做相关工作的从业者希望这些经验能帮你少走一些弯路。核心关键词就三个长程任务评测、过程评估、轨迹分析。这三个词贯穿全文也是理解评测方法变化的关键线索。2. 短程问答评测的底层假设在长程任务里为什么全部失效2.1 短程评测的“三根支柱”及其隐含前提传统的短程问答评测本质上建立在三根支柱上标准答案唯一性、任务边界封闭性、评估维度单一性。你出一道题“某地2024年常住人口是多少”标准答案就是一个数字对就是对错就是错。任务边界也很清楚模型只需要输出一个答案不需要和外部环境交互。评估维度就是准确率最多再加一个响应时间。这三根支柱在短程场景下非常稳固因为短程任务本身就满足这些前提。但一旦任务变长这三根支柱会同时断裂。标准答案不再唯一——一个“帮我规划三天出差行程”的任务可能有几十种合理方案你没法用字符串匹配来判断对错。任务边界不再封闭——智能体需要调用日历、查询航班、发送邮件每一步都在改变环境状态。评估维度不再单一——除了最终结果你还需要关心它有没有绕远路、有没有重复调用、有没有在中途产生不可逆的错误操作。我刚开始做长程评测的时候最不适应的就是“没有标准答案”这件事。后来想明白了长程任务的评测本质上不是判断“答案对不对”而是判断“过程合不合理、结果可不可接受”。这个思维转变非常关键它决定了你后面所有评测设计的方向。2.2 一个真实翻车案例为什么“结果对”不等于“过程对”举个我实际遇到的例子。有一个任务是让智能体“从一堆会议记录里提取所有待办事项按优先级排序然后写入任务管理工具”。最终输出看起来完全正确——待办事项提取全了优先级排序也合理任务管理工具里也确实写入了。按短程评测的思路这个任务应该得满分。但当我回放执行轨迹的时候发现智能体在提取待办事项时把整个会议记录原文都塞进了上下文导致后面每一步的推理都带着大量无关信息。它之所以最后能做对是因为这个任务本身不算太复杂上下文还没超出限制。但如果会议记录再长一倍或者待办事项再多一些它大概率会在中途丢失关键信息。更严重的是它在写入任务管理工具时没有做去重检查如果同样的会议记录被处理两次就会产生重复任务。这个案例让我意识到长程任务的评测必须把过程纳入评估范围。只看结果你会漏掉大量潜在风险。一个“侥幸做对”的智能体和一个“稳定做对”的智能体在短程评测里得分一样但在实际使用中表现天差地别。2.3 从“结果导向”到“过程导向”的评估思维迁移那怎么从结果导向迁移到过程导向我的经验是先把任务拆成“关键节点”然后对每个节点单独定义“通过标准”。还是上面那个会议记录的例子关键节点可以拆成信息提取是否完整、优先级判断是否有依据、写入前是否做了去重检查、异常情况是否有兜底处理。每个节点都可以独立评估最后再综合成一个总分。这样做的好处是即使最终结果不对你也能定位到是哪一步出了问题。反过来即使最终结果对了你也能看出过程中有没有隐患。这种评估方式比单纯看结果要费时费力但对于长程任务来说这是必须付出的成本。因为长程任务的失败模式太多了你不可能靠一个最终结果反推出所有问题。3. 长程任务评测的核心难题轨迹空间爆炸与评估粒度选择3.1 为什么长程任务的“可能路径”多到无法穷举短程任务的可能路径是有限的比如一道选择题可能路径就是四个选项。但长程任务的可能路径是指数级增长的。假设一个任务需要10步完成每一步有5种可能的操作那总路径数就是5的10次方接近一千万条。你不可能对每条路径都定义标准答案。更麻烦的是很多路径的差异并不体现在最终结果上。比如“先查天气再订机票”和“先订机票再查天气”如果天气不影响航班这两条路径的最终结果是一样的。但从评测角度看前者更合理因为如果天气不好后者可能需要退改签。这种“结果相同但过程质量不同”的情况在长程任务里非常普遍。我试过用“路径枚举”的方式来做评测就是提前把所有合理路径都列出来然后看智能体走的是不是其中一条。这个方法在小规模任务上还能用但任务一复杂就完全不可行。后来我放弃了枚举思路转向“关键节点检查异常路径惩罚”的方式。具体来说就是只检查那些必须经过的关键节点同时对明显不合理的操作比如重复调用、跳过必要步骤进行扣分。这样既保证了评估的可行性又不会漏掉主要问题。3.2 评估粒度太粗会漏判太细会过拟合评估粒度是长程任务评测里最让人纠结的问题。粒度太粗比如只看最终结果那前面说的那些问题都会漏掉。粒度太细比如每一步都要求完全符合预设路径那又会过拟合——智能体稍微换一种合理做法就被判错。我的经验是粒度应该定在“关键决策点”上而不是每一步操作上。什么是关键决策点就是那些“做错了会导致后续无法挽回”的步骤。比如在“订机票”任务里“选择航班”是关键决策点因为一旦选定后续的酒店、接送机都要跟着调整。而“打开订票页面”就不是关键决策点它只是必要操作不涉及决策。确定关键决策点的方法我通常用“反向追问法”假设这一步做错了后续能不能补救如果能补救那它就不是关键决策点如果不能补救或者补救成本很高那它就是关键决策点。这个方法在实际操作中很管用能帮你快速筛选出真正需要重点评估的环节。3.3 轨迹回放与人工评审的配合策略长程任务评测离不开轨迹回放。所谓轨迹回放就是把智能体执行任务的全过程记录下来包括每一步的输入、输出、调用的工具、环境状态的变化。有了轨迹你才能做过程评估。但轨迹回放有个问题数据量太大了。一个长程任务可能产生几百条轨迹记录人工逐条看根本不现实。我的做法是“自动筛选人工抽检”。先用自动规则筛出可疑轨迹比如“某一步耗时异常长”“某一步调用了未预期的工具”“某一步的输出和输入明显不相关”然后只对这些可疑轨迹进行人工评审。这样能把人工工作量降低80%以上同时又不漏掉主要问题。人工评审的时候我建议重点关注三类问题逻辑断裂前后步骤之间没有因果关系、资源浪费重复调用、无效操作、风险操作不可逆的删除、发送、支付等。这三类问题在自动筛选中很难完全覆盖需要人工判断。我一般会抽检10%到20%的轨迹如果发现某类问题频繁出现再扩大抽检比例。4. 构建可复现的长程评测集从任务设计到环境搭建4.1 任务设计的“三层次”原则基础、进阶、压力设计长程评测集的时候我习惯把任务分成三个层次基础层、进阶层、压力层。基础层任务步骤少、依赖少、环境稳定主要用来验证智能体的基本能力。进阶层任务步骤多、有分支、需要根据中间结果调整策略用来验证智能体的规划能力。压力层任务则加入异常情况比如工具调用失败、环境状态突变、输入信息不完整用来验证智能体的鲁棒性。这三个层次的任务比例我一般按3:5:2来分配。基础层太多评测就失去了区分度压力层太多又容易让智能体频繁失败看不出真实水平。进阶层是主体因为它最接近实际使用场景。任务设计还有一个容易忽略的点任务描述要足够明确但又不能太详细。太明确了智能体不需要规划就能执行测不出规划能力太模糊了智能体可能理解错任务目标测出来的失败不是能力问题而是理解问题。我的经验是任务描述里要包含“目标”和“约束”但不包含“步骤”。比如“帮我安排下周去某地的出差行程预算不超过某个数尽量选直飞航班”这就是一个合适的描述。它告诉了智能体要做什么、有什么限制但没告诉它先做什么后做什么。4.2 环境搭建让智能体“有东西可操作”长程任务评测离不开环境。短程问答评测只需要一个模型和一个问题但长程任务评测需要一个能让智能体“动手”的环境。这个环境可以是模拟的也可以是真实的但必须满足两个条件可重置和可观测。可重置是指每次评测前环境能恢复到初始状态。否则上一次评测的残留数据会影响下一次。可观测是指环境的状态变化能被记录下来方便后续做轨迹分析。我通常会用容器化技术来搭建评测环境每个任务跑在一个独立的容器里跑完就销毁下次重新创建。这样既能保证环境干净又能并行跑多个任务。环境里的工具也要精心设计。工具太多智能体可能不知道用哪个工具太少又可能完不成任务。我的做法是只提供任务必需的工具并且每个工具的功能要单一、明确。比如“查询航班”和“预订航班”要分成两个工具而不是一个“航班管理”工具。这样智能体在调用时更容易做对选择评测时也更容易定位问题。4.3 评测集的版本管理与防污染策略评测集是需要版本管理的。因为智能体的能力在不断提升今天能考倒它的任务明天可能就轻松通过了。如果不更新评测集评测结果就会失去区分度。我一般每季度更新一次评测集淘汰那些通过率超过90%的任务补充新的进阶层和压力层任务。防污染是另一个重要问题。所谓污染是指评测任务的内容泄露到了智能体的训练数据里。一旦污染智能体可能不是靠能力通过评测而是靠记忆。防污染的方法有几个一是任务内容定期更换不要长期使用同一套题目二是任务描述用模板生成避免固定句式三是环境状态随机化让每次评测的具体数据都不一样。我试过用随机种子来生成任务数据效果不错能有效降低污染风险。5. 评估指标的重构从准确率到任务完成度与过程健康度5.1 任务完成度不只是“做完没做完”短程评测的核心指标是准确率长程评测的核心指标是任务完成度。但任务完成度不是简单的“做完没做完”它应该是一个分级的指标。我通常把它分成五级完全完成、基本完成、部分完成、尝试但失败、未尝试。完全完成是指所有关键节点都通过最终结果可接受。基本完成是指最终结果可接受但过程中有非关键节点的失误。部分完成是指只完成了部分关键节点最终结果不完整。尝试但失败是指智能体确实在执行任务但因为能力不足或环境问题失败了。未尝试是指智能体根本没有理解任务或者直接放弃了。这个分级指标比二值化的“成功/失败”更有信息量。比如两个智能体都是“失败”但一个是“尝试但失败”一个是“未尝试”这说明它们的能力差距很大。在实际评测中我会统计每个级别的分布而不是只看成功率。5.2 过程健康度步数效率、工具调用合理性、错误恢复能力过程健康度是长程评测特有的指标用来衡量智能体在执行过程中的表现。我主要看三个维度步数效率、工具调用合理性、错误恢复能力。步数效率是指智能体用了多少步完成任务和最优步数的比值。比如最优步数是10步智能体用了15步那步数效率就是0.67。这个指标能反映智能体有没有绕远路。工具调用合理性是指智能体调用的工具是否都是必要的有没有重复调用、无效调用。错误恢复能力是指智能体在遇到工具调用失败、环境异常等情况时能不能自己调整策略继续执行。这三个维度我一般会合成一个“过程健康度”分数权重根据任务类型调整。比如对于效率敏感的任务步数效率权重高一些对于稳定性敏感的任务错误恢复能力权重高一些。这样能让评测更贴合实际需求。5.3 综合评分如何给“结果对但过程差”和“结果错但过程好”打分“结果对但过程差”和“结果错但过程好”是长程评测里最常见的两种纠结情况。我的处理方式是结果和过程分开打分最后加权合成。结果分占60%过程分占40%。这样既能保证结果的重要性又不会完全忽略过程。对于“结果对但过程差”的情况结果分满分过程分扣分综合分可能在70到80之间。对于“结果错但过程好”的情况结果分扣分过程分满分综合分可能在50到60之间。这样区分的好处是你能一眼看出智能体的问题出在结果上还是过程上。如果结果分普遍偏低说明智能体的能力还不够如果过程分普遍偏低说明智能体的策略有问题。我还会单独记录“结果对但过程差”的比例。这个比例越高说明智能体的“侥幸成功”越多实际使用中的风险越大。理想情况下这个比例应该低于10%。6. 实操中的坑与经验那些文档里不会写的细节6.1 评测环境的“状态泄漏”一个容易被忽略的致命问题状态泄漏是我踩过的最大的坑。所谓状态泄漏是指上一次评测的环境状态没有完全清理影响了下一次评测。比如上一次评测往数据库里写了一条记录下一次评测时这条记录还在导致智能体查到了不该查到的数据。这个问题在短程评测里不存在因为短程评测不涉及环境状态。但在长程评测里状态泄漏会导致评测结果完全不可信。我一开始没注意这个问题跑了几轮评测后发现有些任务的成功率异常高排查了很久才发现是状态泄漏。解决方法是每次评测前强制重置环境并且重置后要做一次“空跑”验证——让一个已知会失败的智能体跑一遍确认它确实失败了。如果它成功了说明环境没清理干净。这个验证步骤看起来很傻但非常有效能帮你提前发现状态泄漏问题。6.2 工具调用的“假成功”返回200不代表任务完成另一个坑是工具调用的“假成功”。很多工具在调用成功时会返回一个成功状态码但这不代表任务真的完成了。比如“发送邮件”工具返回200只代表邮件发送请求被接受了不代表邮件真的送达了。如果智能体把“返回200”当成“任务完成”那评测时就会误判。我的做法是在评测环境里给每个工具都加一个“验证接口”用来确认操作是否真的生效。比如发送邮件后通过验证接口去查发件箱确认邮件确实在里面。这个验证接口不暴露给智能体只在评测时使用。这样既能保证评测准确性又不会增加智能体的负担。6.3 长程任务的“超时”与“中断”处理长程任务很容易超时。一个任务跑几分钟甚至十几分钟是常事。如果评测时没有超时机制一个卡住的任务可能会占用大量资源。我一般会给每个任务设置一个超时时间超过时间就强制中断并记录为“超时失败”。但超时中断有个问题中断时环境可能处于不一致状态。比如智能体正在写数据库写到一半被中断了数据库里就是半条记录。所以中断后必须做环境清理不能直接跑下一个任务。我通常会在中断后执行一个“回滚脚本”把环境恢复到初始状态。这个脚本要覆盖所有可能被修改的资源包括数据库、文件系统、外部接口的模拟状态等。还有一个细节是超时时间要设置得合理。太短了正常任务也会被中断太长了卡住的任务会浪费太多时间。我的经验是先跑一批任务统计正常执行时间的分布然后取95分位数的1.5倍作为超时时间。这样既能覆盖绝大多数正常任务又能及时中断异常任务。6.4 人工评审的一致性如何让不同评审人打出相近的分数如果评测涉及人工评审一致性是个大问题。不同评审人对“过程合理”的理解可能不一样打出来的分数差异很大。我试过让两个评审人独立评同一批轨迹结果分数差异超过20%的情况很常见。解决方法是制定详细的评审标准并且做评审人校准。评审标准要具体到每个关键节点的通过条件不能有模糊表述。比如“信息提取完整”要定义清楚提取了哪些字段、每个字段的格式要求是什么、缺失多少算不完整。评审人校准则是让所有评审人先评同一批样本然后对比分数讨论差异原因直到大家的评分标准基本一致。这个过程很费时间但非常值得。因为如果评审标准不一致评测结果就没有可比性整个评测就失去了意义。我一般会在正式评测前做两轮校准第一轮统一标准第二轮验证一致性。两轮之后评审人之间的分数差异能控制在5%以内。7. 从评测结果到能力改进怎么让评测真正产生价值7.1 失败归因区分“能力不足”和“策略不当”评测的最终目的是改进。如果评测做完只得到一个分数那价值就太低了。我习惯在评测后做失败归因把失败案例分成“能力不足”和“策略不当”两类。能力不足是指智能体本身不具备完成任务所需的能力比如不会调用某个工具、不理解某个概念。策略不当是指智能体有能力但用错了地方比如该用A工具的时候用了B工具、该先做X的时候先做了Y。这两类问题的改进方向完全不同能力不足需要补充训练或增加工具策略不当需要调整提示词或优化规划逻辑。区分这两类问题的方法我通常用“替换测试”把失败案例中的某个环节替换成人工操作看后续能不能顺利完成。如果能说明问题出在这个环节再进一步判断是能力问题还是策略问题。这个方法虽然原始但很有效。7.2 评测驱动的迭代闭环从发现问题到验证修复评测不是一次性的而是一个闭环。发现问题、修复问题、重新评测、验证修复效果这个循环要持续跑。我一般会维护一个“问题清单”每次评测后把新发现的问题加进去修复后再跑一轮评测确认问题是否解决。这个闭环里最容易忽略的是“回归验证”。修复了一个问题可能会引入新的问题。所以每次修复后不仅要跑针对性的测试还要跑全量评测确保没有引入回归。我吃过这个亏修复了一个工具调用的问题结果导致另一个任务的步数效率大幅下降。后来每次修复都跑全量评测虽然费时间但能避免很多意外。7.3 评测集与智能体的协同演进评测集和智能体是协同演进的。智能体能力提升了评测集要跟着升级评测集升级了又会推动智能体继续提升。这个循环是好事但要注意节奏。评测集升级太快智能体一直失败会打击信心升级太慢智能体一直满分会失去区分度。我的节奏是当某个任务的通过率连续三次评测都超过90%时就把它移到“已掌握”列表不再作为主要评测项同时补充新的任务。这样评测集始终保持在“跳一跳够得着”的难度水平。这个节奏不是固定的要根据智能体的实际进步速度调整。进步快的时候评测集更新也要快进步慢的时候可以适当放慢更新节奏先把现有任务做扎实。8. 我个人的几条实操建议做了这么长时间的长程任务评测有几个心得是我想特别分享的。第一不要追求完美的评测方案。长程任务评测没有完美方案只有够用的方案。你永远不可能覆盖所有路径、所有异常情况。与其追求完美不如先把基本框架搭起来然后在实践中不断迭代。我见过太多人因为想设计一个“完美评测集”而迟迟不动手最后什么都没做出来。第二评测的自动化程度要逐步提升。一开始可以人工多一些把流程跑通。然后逐步把重复性的工作自动化比如轨迹筛选、指标计算、报告生成。但不要一开始就追求全自动因为很多评测逻辑需要人工判断过早自动化反而会引入错误。第三评测结果要可解释。一个分数如果没有解释就没有改进价值。我每次出评测报告都会附上失败案例的详细分析说明失败在哪里、可能的原因是什么、建议怎么改进。这样评测才能真正驱动迭代。第四保持评测环境的独立性。评测环境和开发环境要分开不要混用。开发环境里可能有很多临时改动会影响评测结果的稳定性。我一般会维护一个专门的评测环境只用于跑评测不做其他用途。这样能保证评测结果的可比性。最后一点定期回顾评测方法本身。评测方法不是一成不变的。智能体在进化评测方法也要跟着进化。我每半年会回顾一次评测流程看看哪些环节可以优化、哪些指标已经失去区分度、哪些新的评估维度需要加入。这个回顾习惯帮我避免了很多“用旧方法评新问题”的尴尬。 
长河君 · 2026/10/22 15:39:01 · 阅读 1.2k 智能体长程任务评测：从结果导向到过程评估的范式迁移
1. 从“一问一答”到“多步执行”评测对象变了方法论必须跟着变如果你最近半年在关注智能体Agent这个方向应该能明显感觉到一个变化以前大家聊的是“这个模型回答问题的准确率是多少”现在聊的是“这个智能体能不能自己把一件事从头到尾办完”。这个转变听起来只是任务变长了但真正做过评测的人都知道短程问答和长程任务之间的差距不是把题目加长那么简单而是整个评测范式都要推倒重来。我最初接触智能体评测的时候也是拿传统问答的那套思路去套——准备一批标准答案让智能体跑一遍对一对结果算个准确率就完事了。结果第一次跑长程任务就翻车了一个需要调用工具、分多步执行、中间还要根据反馈调整策略的任务智能体前面几步做得都对到第五步因为一个环境状态的细微变化走偏了最后输出完全不能用。但如果你只看最终结果它和“第一步就做错”得到的分数是一样的。这就暴露了短程评测方法论的根本局限它假设任务是一次性的、无状态的、结果可穷举的。而长程任务恰恰是有状态的、多步的、路径依赖的。所以这篇文章想聊的就是我在实际做智能体评测过程中从短程问答评测迁移到长程任务评测时踩过的坑、想明白的道理以及最后沉淀下来的一套可操作的方法。不管你是刚接触智能体评测的新手还是已经在做相关工作的从业者希望这些经验能帮你少走一些弯路。核心关键词就三个长程任务评测、过程评估、轨迹分析。这三个词贯穿全文也是理解评测方法变化的关键线索。2. 短程问答评测的底层假设在长程任务里为什么全部失效2.1 短程评测的“三根支柱”及其隐含前提传统的短程问答评测本质上建立在三根支柱上标准答案唯一性、任务边界封闭性、评估维度单一性。你出一道题“某地2024年常住人口是多少”标准答案就是一个数字对就是对错就是错。任务边界也很清楚模型只需要输出一个答案不需要和外部环境交互。评估维度就是准确率最多再加一个响应时间。这三根支柱在短程场景下非常稳固因为短程任务本身就满足这些前提。但一旦任务变长这三根支柱会同时断裂。标准答案不再唯一——一个“帮我规划三天出差行程”的任务可能有几十种合理方案你没法用字符串匹配来判断对错。任务边界不再封闭——智能体需要调用日历、查询航班、发送邮件每一步都在改变环境状态。评估维度不再单一——除了最终结果你还需要关心它有没有绕远路、有没有重复调用、有没有在中途产生不可逆的错误操作。我刚开始做长程评测的时候最不适应的就是“没有标准答案”这件事。后来想明白了长程任务的评测本质上不是判断“答案对不对”而是判断“过程合不合理、结果可不可接受”。这个思维转变非常关键它决定了你后面所有评测设计的方向。2.2 一个真实翻车案例为什么“结果对”不等于“过程对”举个我实际遇到的例子。有一个任务是让智能体“从一堆会议记录里提取所有待办事项按优先级排序然后写入任务管理工具”。最终输出看起来完全正确——待办事项提取全了优先级排序也合理任务管理工具里也确实写入了。按短程评测的思路这个任务应该得满分。但当我回放执行轨迹的时候发现智能体在提取待办事项时把整个会议记录原文都塞进了上下文导致后面每一步的推理都带着大量无关信息。它之所以最后能做对是因为这个任务本身不算太复杂上下文还没超出限制。但如果会议记录再长一倍或者待办事项再多一些它大概率会在中途丢失关键信息。更严重的是它在写入任务管理工具时没有做去重检查如果同样的会议记录被处理两次就会产生重复任务。这个案例让我意识到长程任务的评测必须把过程纳入评估范围。只看结果你会漏掉大量潜在风险。一个“侥幸做对”的智能体和一个“稳定做对”的智能体在短程评测里得分一样但在实际使用中表现天差地别。2.3 从“结果导向”到“过程导向”的评估思维迁移那怎么从结果导向迁移到过程导向我的经验是先把任务拆成“关键节点”然后对每个节点单独定义“通过标准”。还是上面那个会议记录的例子关键节点可以拆成信息提取是否完整、优先级判断是否有依据、写入前是否做了去重检查、异常情况是否有兜底处理。每个节点都可以独立评估最后再综合成一个总分。这样做的好处是即使最终结果不对你也能定位到是哪一步出了问题。反过来即使最终结果对了你也能看出过程中有没有隐患。这种评估方式比单纯看结果要费时费力但对于长程任务来说这是必须付出的成本。因为长程任务的失败模式太多了你不可能靠一个最终结果反推出所有问题。3. 长程任务评测的核心难题轨迹空间爆炸与评估粒度选择3.1 为什么长程任务的“可能路径”多到无法穷举短程任务的可能路径是有限的比如一道选择题可能路径就是四个选项。但长程任务的可能路径是指数级增长的。假设一个任务需要10步完成每一步有5种可能的操作那总路径数就是5的10次方接近一千万条。你不可能对每条路径都定义标准答案。更麻烦的是很多路径的差异并不体现在最终结果上。比如“先查天气再订机票”和“先订机票再查天气”如果天气不影响航班这两条路径的最终结果是一样的。但从评测角度看前者更合理因为如果天气不好后者可能需要退改签。这种“结果相同但过程质量不同”的情况在长程任务里非常普遍。我试过用“路径枚举”的方式来做评测就是提前把所有合理路径都列出来然后看智能体走的是不是其中一条。这个方法在小规模任务上还能用但任务一复杂就完全不可行。后来我放弃了枚举思路转向“关键节点检查异常路径惩罚”的方式。具体来说就是只检查那些必须经过的关键节点同时对明显不合理的操作比如重复调用、跳过必要步骤进行扣分。这样既保证了评估的可行性又不会漏掉主要问题。3.2 评估粒度太粗会漏判太细会过拟合评估粒度是长程任务评测里最让人纠结的问题。粒度太粗比如只看最终结果那前面说的那些问题都会漏掉。粒度太细比如每一步都要求完全符合预设路径那又会过拟合——智能体稍微换一种合理做法就被判错。我的经验是粒度应该定在“关键决策点”上而不是每一步操作上。什么是关键决策点就是那些“做错了会导致后续无法挽回”的步骤。比如在“订机票”任务里“选择航班”是关键决策点因为一旦选定后续的酒店、接送机都要跟着调整。而“打开订票页面”就不是关键决策点它只是必要操作不涉及决策。确定关键决策点的方法我通常用“反向追问法”假设这一步做错了后续能不能补救如果能补救那它就不是关键决策点如果不能补救或者补救成本很高那它就是关键决策点。这个方法在实际操作中很管用能帮你快速筛选出真正需要重点评估的环节。3.3 轨迹回放与人工评审的配合策略长程任务评测离不开轨迹回放。所谓轨迹回放就是把智能体执行任务的全过程记录下来包括每一步的输入、输出、调用的工具、环境状态的变化。有了轨迹你才能做过程评估。但轨迹回放有个问题数据量太大了。一个长程任务可能产生几百条轨迹记录人工逐条看根本不现实。我的做法是“自动筛选人工抽检”。先用自动规则筛出可疑轨迹比如“某一步耗时异常长”“某一步调用了未预期的工具”“某一步的输出和输入明显不相关”然后只对这些可疑轨迹进行人工评审。这样能把人工工作量降低80%以上同时又不漏掉主要问题。人工评审的时候我建议重点关注三类问题逻辑断裂前后步骤之间没有因果关系、资源浪费重复调用、无效操作、风险操作不可逆的删除、发送、支付等。这三类问题在自动筛选中很难完全覆盖需要人工判断。我一般会抽检10%到20%的轨迹如果发现某类问题频繁出现再扩大抽检比例。4. 构建可复现的长程评测集从任务设计到环境搭建4.1 任务设计的“三层次”原则基础、进阶、压力设计长程评测集的时候我习惯把任务分成三个层次基础层、进阶层、压力层。基础层任务步骤少、依赖少、环境稳定主要用来验证智能体的基本能力。进阶层任务步骤多、有分支、需要根据中间结果调整策略用来验证智能体的规划能力。压力层任务则加入异常情况比如工具调用失败、环境状态突变、输入信息不完整用来验证智能体的鲁棒性。这三个层次的任务比例我一般按3:5:2来分配。基础层太多评测就失去了区分度压力层太多又容易让智能体频繁失败看不出真实水平。进阶层是主体因为它最接近实际使用场景。任务设计还有一个容易忽略的点任务描述要足够明确但又不能太详细。太明确了智能体不需要规划就能执行测不出规划能力太模糊了智能体可能理解错任务目标测出来的失败不是能力问题而是理解问题。我的经验是任务描述里要包含“目标”和“约束”但不包含“步骤”。比如“帮我安排下周去某地的出差行程预算不超过某个数尽量选直飞航班”这就是一个合适的描述。它告诉了智能体要做什么、有什么限制但没告诉它先做什么后做什么。4.2 环境搭建让智能体“有东西可操作”长程任务评测离不开环境。短程问答评测只需要一个模型和一个问题但长程任务评测需要一个能让智能体“动手”的环境。这个环境可以是模拟的也可以是真实的但必须满足两个条件可重置和可观测。可重置是指每次评测前环境能恢复到初始状态。否则上一次评测的残留数据会影响下一次。可观测是指环境的状态变化能被记录下来方便后续做轨迹分析。我通常会用容器化技术来搭建评测环境每个任务跑在一个独立的容器里跑完就销毁下次重新创建。这样既能保证环境干净又能并行跑多个任务。环境里的工具也要精心设计。工具太多智能体可能不知道用哪个工具太少又可能完不成任务。我的做法是只提供任务必需的工具并且每个工具的功能要单一、明确。比如“查询航班”和“预订航班”要分成两个工具而不是一个“航班管理”工具。这样智能体在调用时更容易做对选择评测时也更容易定位问题。4.3 评测集的版本管理与防污染策略评测集是需要版本管理的。因为智能体的能力在不断提升今天能考倒它的任务明天可能就轻松通过了。如果不更新评测集评测结果就会失去区分度。我一般每季度更新一次评测集淘汰那些通过率超过90%的任务补充新的进阶层和压力层任务。防污染是另一个重要问题。所谓污染是指评测任务的内容泄露到了智能体的训练数据里。一旦污染智能体可能不是靠能力通过评测而是靠记忆。防污染的方法有几个一是任务内容定期更换不要长期使用同一套题目二是任务描述用模板生成避免固定句式三是环境状态随机化让每次评测的具体数据都不一样。我试过用随机种子来生成任务数据效果不错能有效降低污染风险。5. 评估指标的重构从准确率到任务完成度与过程健康度5.1 任务完成度不只是“做完没做完”短程评测的核心指标是准确率长程评测的核心指标是任务完成度。但任务完成度不是简单的“做完没做完”它应该是一个分级的指标。我通常把它分成五级完全完成、基本完成、部分完成、尝试但失败、未尝试。完全完成是指所有关键节点都通过最终结果可接受。基本完成是指最终结果可接受但过程中有非关键节点的失误。部分完成是指只完成了部分关键节点最终结果不完整。尝试但失败是指智能体确实在执行任务但因为能力不足或环境问题失败了。未尝试是指智能体根本没有理解任务或者直接放弃了。这个分级指标比二值化的“成功/失败”更有信息量。比如两个智能体都是“失败”但一个是“尝试但失败”一个是“未尝试”这说明它们的能力差距很大。在实际评测中我会统计每个级别的分布而不是只看成功率。5.2 过程健康度步数效率、工具调用合理性、错误恢复能力过程健康度是长程评测特有的指标用来衡量智能体在执行过程中的表现。我主要看三个维度步数效率、工具调用合理性、错误恢复能力。步数效率是指智能体用了多少步完成任务和最优步数的比值。比如最优步数是10步智能体用了15步那步数效率就是0.67。这个指标能反映智能体有没有绕远路。工具调用合理性是指智能体调用的工具是否都是必要的有没有重复调用、无效调用。错误恢复能力是指智能体在遇到工具调用失败、环境异常等情况时能不能自己调整策略继续执行。这三个维度我一般会合成一个“过程健康度”分数权重根据任务类型调整。比如对于效率敏感的任务步数效率权重高一些对于稳定性敏感的任务错误恢复能力权重高一些。这样能让评测更贴合实际需求。5.3 综合评分如何给“结果对但过程差”和“结果错但过程好”打分“结果对但过程差”和“结果错但过程好”是长程评测里最常见的两种纠结情况。我的处理方式是结果和过程分开打分最后加权合成。结果分占60%过程分占40%。这样既能保证结果的重要性又不会完全忽略过程。对于“结果对但过程差”的情况结果分满分过程分扣分综合分可能在70到80之间。对于“结果错但过程好”的情况结果分扣分过程分满分综合分可能在50到60之间。这样区分的好处是你能一眼看出智能体的问题出在结果上还是过程上。如果结果分普遍偏低说明智能体的能力还不够如果过程分普遍偏低说明智能体的策略有问题。我还会单独记录“结果对但过程差”的比例。这个比例越高说明智能体的“侥幸成功”越多实际使用中的风险越大。理想情况下这个比例应该低于10%。6. 实操中的坑与经验那些文档里不会写的细节6.1 评测环境的“状态泄漏”一个容易被忽略的致命问题状态泄漏是我踩过的最大的坑。所谓状态泄漏是指上一次评测的环境状态没有完全清理影响了下一次评测。比如上一次评测往数据库里写了一条记录下一次评测时这条记录还在导致智能体查到了不该查到的数据。这个问题在短程评测里不存在因为短程评测不涉及环境状态。但在长程评测里状态泄漏会导致评测结果完全不可信。我一开始没注意这个问题跑了几轮评测后发现有些任务的成功率异常高排查了很久才发现是状态泄漏。解决方法是每次评测前强制重置环境并且重置后要做一次“空跑”验证——让一个已知会失败的智能体跑一遍确认它确实失败了。如果它成功了说明环境没清理干净。这个验证步骤看起来很傻但非常有效能帮你提前发现状态泄漏问题。6.2 工具调用的“假成功”返回200不代表任务完成另一个坑是工具调用的“假成功”。很多工具在调用成功时会返回一个成功状态码但这不代表任务真的完成了。比如“发送邮件”工具返回200只代表邮件发送请求被接受了不代表邮件真的送达了。如果智能体把“返回200”当成“任务完成”那评测时就会误判。我的做法是在评测环境里给每个工具都加一个“验证接口”用来确认操作是否真的生效。比如发送邮件后通过验证接口去查发件箱确认邮件确实在里面。这个验证接口不暴露给智能体只在评测时使用。这样既能保证评测准确性又不会增加智能体的负担。6.3 长程任务的“超时”与“中断”处理长程任务很容易超时。一个任务跑几分钟甚至十几分钟是常事。如果评测时没有超时机制一个卡住的任务可能会占用大量资源。我一般会给每个任务设置一个超时时间超过时间就强制中断并记录为“超时失败”。但超时中断有个问题中断时环境可能处于不一致状态。比如智能体正在写数据库写到一半被中断了数据库里就是半条记录。所以中断后必须做环境清理不能直接跑下一个任务。我通常会在中断后执行一个“回滚脚本”把环境恢复到初始状态。这个脚本要覆盖所有可能被修改的资源包括数据库、文件系统、外部接口的模拟状态等。还有一个细节是超时时间要设置得合理。太短了正常任务也会被中断太长了卡住的任务会浪费太多时间。我的经验是先跑一批任务统计正常执行时间的分布然后取95分位数的1.5倍作为超时时间。这样既能覆盖绝大多数正常任务又能及时中断异常任务。6.4 人工评审的一致性如何让不同评审人打出相近的分数如果评测涉及人工评审一致性是个大问题。不同评审人对“过程合理”的理解可能不一样打出来的分数差异很大。我试过让两个评审人独立评同一批轨迹结果分数差异超过20%的情况很常见。解决方法是制定详细的评审标准并且做评审人校准。评审标准要具体到每个关键节点的通过条件不能有模糊表述。比如“信息提取完整”要定义清楚提取了哪些字段、每个字段的格式要求是什么、缺失多少算不完整。评审人校准则是让所有评审人先评同一批样本然后对比分数讨论差异原因直到大家的评分标准基本一致。这个过程很费时间但非常值得。因为如果评审标准不一致评测结果就没有可比性整个评测就失去了意义。我一般会在正式评测前做两轮校准第一轮统一标准第二轮验证一致性。两轮之后评审人之间的分数差异能控制在5%以内。7. 从评测结果到能力改进怎么让评测真正产生价值7.1 失败归因区分“能力不足”和“策略不当”评测的最终目的是改进。如果评测做完只得到一个分数那价值就太低了。我习惯在评测后做失败归因把失败案例分成“能力不足”和“策略不当”两类。能力不足是指智能体本身不具备完成任务所需的能力比如不会调用某个工具、不理解某个概念。策略不当是指智能体有能力但用错了地方比如该用A工具的时候用了B工具、该先做X的时候先做了Y。这两类问题的改进方向完全不同能力不足需要补充训练或增加工具策略不当需要调整提示词或优化规划逻辑。区分这两类问题的方法我通常用“替换测试”把失败案例中的某个环节替换成人工操作看后续能不能顺利完成。如果能说明问题出在这个环节再进一步判断是能力问题还是策略问题。这个方法虽然原始但很有效。7.2 评测驱动的迭代闭环从发现问题到验证修复评测不是一次性的而是一个闭环。发现问题、修复问题、重新评测、验证修复效果这个循环要持续跑。我一般会维护一个“问题清单”每次评测后把新发现的问题加进去修复后再跑一轮评测确认问题是否解决。这个闭环里最容易忽略的是“回归验证”。修复了一个问题可能会引入新的问题。所以每次修复后不仅要跑针对性的测试还要跑全量评测确保没有引入回归。我吃过这个亏修复了一个工具调用的问题结果导致另一个任务的步数效率大幅下降。后来每次修复都跑全量评测虽然费时间但能避免很多意外。7.3 评测集与智能体的协同演进评测集和智能体是协同演进的。智能体能力提升了评测集要跟着升级评测集升级了又会推动智能体继续提升。这个循环是好事但要注意节奏。评测集升级太快智能体一直失败会打击信心升级太慢智能体一直满分会失去区分度。我的节奏是当某个任务的通过率连续三次评测都超过90%时就把它移到“已掌握”列表不再作为主要评测项同时补充新的任务。这样评测集始终保持在“跳一跳够得着”的难度水平。这个节奏不是固定的要根据智能体的实际进步速度调整。进步快的时候评测集更新也要快进步慢的时候可以适当放慢更新节奏先把现有任务做扎实。8. 我个人的几条实操建议做了这么长时间的长程任务评测有几个心得是我想特别分享的。第一不要追求完美的评测方案。长程任务评测没有完美方案只有够用的方案。你永远不可能覆盖所有路径、所有异常情况。与其追求完美不如先把基本框架搭起来然后在实践中不断迭代。我见过太多人因为想设计一个“完美评测集”而迟迟不动手最后什么都没做出来。第二评测的自动化程度要逐步提升。一开始可以人工多一些把流程跑通。然后逐步把重复性的工作自动化比如轨迹筛选、指标计算、报告生成。但不要一开始就追求全自动因为很多评测逻辑需要人工判断过早自动化反而会引入错误。第三评测结果要可解释。一个分数如果没有解释就没有改进价值。我每次出评测报告都会附上失败案例的详细分析说明失败在哪里、可能的原因是什么、建议怎么改进。这样评测才能真正驱动迭代。第四保持评测环境的独立性。评测环境和开发环境要分开不要混用。开发环境里可能有很多临时改动会影响评测结果的稳定性。我一般会维护一个专门的评测环境只用于跑评测不做其他用途。这样能保证评测结果的可比性。最后一点定期回顾评测方法本身。评测方法不是一成不变的。智能体在进化评测方法也要跟着进化。我每半年会回顾一次评测流程看看哪些环节可以优化、哪些指标已经失去区分度、哪些新的评估维度需要加入。这个回顾习惯帮我避免了很多“用旧方法评新问题”的尴尬。