企业官网建设流程全解析

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. 我个人的几条实操建议

做了这么长时间的长程任务评测，有几个心得是我想特别分享的。第一，不要追求完美的评测方案。长程任务评测没有完美方案，只有够用的方案。你永远不可能覆盖所有路径、所有异常情况。与其追求完美，不如先把基本框架搭起来，然后在实践中不断迭代。我见过太多人因为想设计一个“完美评测集”而迟迟不动手，最后什么都没做出来。

第二，评测的自动化程度要逐步提升。一开始可以人工多一些，把流程跑通。然后逐步把重复性的工作自动化，比如轨迹筛选、指标计算、报告生成。但不要一开始就追求全自动，因为很多评测逻辑需要人工判断，过早自动化反而会引入错误。

第三，评测结果要可解释。一个分数如果没有解释，就没有改进价值。我每次出评测报告，都会附上失败案例的详细分析，说明失败在哪里、可能的原因是什么、建议怎么改进。这样评测才能真正驱动迭代。

第四，保持评测环境的独立性。评测环境和开发环境要分开，不要混用。开发环境里可能有很多临时改动，会影响评测结果的稳定性。我一般会维护一个专门的评测环境，只用于跑评测，不做其他用途。这样能保证评测结果的可比性。

最后一点，定期回顾评测方法本身。评测方法不是一成不变的。智能体在进化，评测方法也要跟着进化。我每半年会回顾一次评测流程，看看哪些环节可以优化、哪些指标已经失去区分度、哪些新的评估维度需要加入。这个回顾习惯帮我避免了很多“用旧方法评新问题”的尴尬。