长周期评估鸿沟：为什么你的智能体通过了所有基准测试却仍在生产环境中失败

一个在 SWE-Bench Verified 上得分 75% 的模型，在处理需要人类工程师花费数小时才能完成的任务时，其得分会降至 25% 以下。同样一个能够稳定处理单轮问答的智能体（agent），在被要求协调十几个步骤以实现一个开放式目标时，可能会陷入语无伦次的循环、幻觉化工具输出，并忘记其最初的目标。基准测试数据与生产环境表现之间的差距并非噪声——它是结构性的。理解这一点，是交付有用产品与交付仅在演示（demo）中好看的产品之间的区别。

本篇文章讨论的就是这个差距：它为何存在，在长程（long-horizon）任务中会出现哪些静态评估中从未出现的特定失败模式，以及构建一个能够真正捕捉到这些模式的评估框架需要什么。

单轮错觉

大多数流行的基准测试只衡量一件事：给定一个提示词（prompt），模型是否产生了正确的输出？MMLU 测试知识召回。HumanEval 测试函数体是否通过单元测试。即使是在 2023 年和 2024 年开始流行的“智能体化（agentic）”评估，也很大程度上被设定为单次片段——智能体接收一个任务，执行一些操作，并根据最终状态是否匹配目标进行评分。

问题不在于这些基准测试是错误的，而在于它们测试的行为与生产环境中的智能体行为有着本质的不同。

在生产环境中，一个智能体可能需要调研代码库、提出修复方案、运行测试、解释失败原因、修改方法、处理工具超时，并生成一个干净的 diff——这往往涵盖 30 到 60 个步骤。在这种模式下，成功的概率并不是模型的一个固定属性。它是任务时长、错误恢复行为以及智能体如何管理累积上下文的函数。所有这些都不会体现在 pass@1 中。

数据使这种差距变得具体。最近一项涵盖多个模型、共计 23,392 个片段的可靠性研究发现，pass@1 在短任务中为 76.3%，但在极长任务中下降到 52.1%——这 24 个百分点的下降是超线性的（super-linear），这意味着它比假设错误相互独立时所预测的情况还要糟糕。专门针对软件工程任务，随着任务长度增加，Graceful Degradation Score 从 0.90 跌至 0.44。智能体并不是在每一步都犯了更多错误，而是错误以短程评估无法检测到的方式在复合成倍增加。

长程任务究竟暴露了什么

几种失败模式几乎只出现在多步骤、长时间的交互中。它们在单轮评估中是不可见的，因为它们需要随时间累积状态和上下文。

复合错误（Compounding errors）。记录最多的失败模式：轨迹早期的微小错误会扭曲随后的每一个推理步骤。如果智能体在第 3 步错误分类了一个函数签名，它就会构建一个不正确的心理模型，从而毒害第 10 到 20 步。专门针对编程智能体的研究将“微小、复合问题的组合”确定为一个独特的失败类别——不是一个单一的灾难性错误，而是许多连环发生的小错误。当每一步有 95% 的成功率时，一个 20 步的链条正确完成的概率仅为 36%。

状态偏移（State drift）。在延长的交互中，智能体通过研究人员所谓的“语义偏移（semantic drift）”偏离其原始目标。智能体并不是字面意义上忘记了任务——任务仍在上下文窗口中——但优先级逐渐转移，智能体开始针对局部连贯性进行优化，而不是针对原始目标。这与复合错误不同：每一步的推理在局部可能是有效的，但轨迹却偏离了目标。

崩溃行为（Meltdown behavior）。长程基准测试中记录的一个特别引人注目的失败模式是从“连贯但错误”向“语无伦次”的转变。智能体开始在失败的工具调用上循环，反驳自己早先的输出，或者开始幻觉工具响应而不是调用工具。针对 τ-bench (tau-bench)——一个模拟动态使用工具的多轮客户服务交互基准——的研究发现，GPT-4o 的任务成功率不到 50%，当评估八次运行的一致性时，该比例下降到 25% 以下——这揭示了智能体偶尔只是运气好，而不是可靠地理解了任务。

工具使用退化（Tool use degradation）。智能体通常在开始任务时能正确选择工具并提供格式良好的参数，但在执行过程中会退化。失败的情况包括工具调用中的 JSON 格式错误、语义正确但上下文错误的工具调用（在需要写入工具时调用了读取工具），以及在长时间累积上下文后输出失去结构。这种模式在智能体只进行一两次工具调用的评估中不会出现——它在十几次调用后才会显现。

不可逆操作风险（Irreversible action risk）。长程任务更有可能涉及无法撤销的操作：提交代码、发送消息、修改共享状态、删除记录。短程评估很少暴露这一点，因为在三步评估中错误操作的成本通常是可以轻易恢复的。在 40 步的智能体工作流中，第 15 步的不可逆错误可能会使随后的每一步失效，无论智能体恢复得有多好。

揭示差距的基准测试

一些基准测试专门设计用于压力测试长时程（long-horizon）能力，其结果始终令人保持清醒。

SWE-Bench Pro 为智能体分配软件工程问题，这些问题通常需要人类专业人员花费数小时到数天的时间来完成——包括跨越多个文件的补丁、架构变更和横切关注点。最先进的模型在 pass@1 上的得分低于 25%。更确切地说，那些在 SWE-Bench Verified（侧重于孤立的错误修复）上超过 70% 的模型，当任务需要持续的多文件推理时，得分会骤降至 25% 以下。当任务上下文中移除人类提供的需求和接口规范时，GPT-5 的分数从 25.9% 下降到 8.4%——这证明了当前的智能体对结构良好的脚手架（scaffolding）有多么依赖。

τ-bench (tau-bench) 衡量智能体在零售和航空领域执行客户服务任务的能力，并提供工具访问和领域政策指南。该基准测试使用 pass^k 指标：即所有 k 次尝试都成功的概率。当你需要智能体始终保持正确，而不是偶尔碰运气时，这是一个相关的指标。数据非常严峻：顶尖的函数调用智能体在不到 50% 的任务上取得成功，而在零售领域，pass^8 则降至 25% 以下。

GAIA 在需要网页浏览、工具使用和多模态推理的多步任务上对通用助手进行基准测试。发布时，人类解决了 92% 的任务，而带有插件的 GPT-4 仅解决了 15%。虽然差距正在缩小，但该基准测试暴露了一个一致的模式：智能体的失败不在于单步内的推理，而在于跨步骤的协调。

WebArena 要求智能体在多个网站上完成真实的基于 Web 的工作流。初始模型在人类得分为 78% 的基准测试中仅获得了 14% 的成功率。即使随着改进使某些智能体达到了 60% 以上，该基准测试始终会暴露出单轮 QA 无法发现的失败：智能体被意外的 UI 状态所困扰、忘记了之前的导航上下文，以及采取了看似有效但违反隐含任务约束的行为。

排名反转与基准测试陷阱

长时程可靠性研究的一个发现特别值得关注：当你从短时程评估切换到长时程评估时，模型排名会发生反转。

一个在短任务中排名第一的模型——GLM-4.5 Air，pass@1 为 94.9%——在极长任务中跌至第四，仅为 66.7%。而在短时程能力中排名第五或第六的模型，在长时程可靠性中则上升到第三或第四。如果你根据标准的基准测试排行榜为生产环境中的智能体选择模型，你可能会为你的实际工作负载选错模型。

排名反转的原因在于，某些模型通过极具攻击性的果断性在短时程任务中获得了高分——它们能快速且自信地给出答案。这在单轮设置中效果很好。但在长时程任务中，同样的攻击性会导致过早地投入错误的策略，并在出错时缺乏足够的恢复行为。

这产生了一个反直觉的推论：追求雄心勃勃的多步策略的前沿模型表现出最高的“崩溃率”（meltdown rates）。DeepSeek V3 和类似模型获得了最好的极长 GDS 分数，但分别表现出 19% 和 13% 的崩溃率。整体表现最好的模型，也最有可能在无法使其复杂策略生效时陷入语无伦次的境地。纯粹根据排行榜位置选择的模型在生产环境中可能是最危险的，如果它们没有鲁棒的故障模式处理能力。

构建能够捕捉长时程失败的评估框架

实际的问题是该如何应对。短时程的 pass@1 评估仍然值得保留——它们快速、廉价，且擅长捕捉在已理解任务上的回归。但它们需要辅以能够真正测试上述失败模式的评估基础设施。

衡量 pass^k，而不仅仅是 pass@1。 多次运行同一任务，并衡量智能体是否能一致地取得成功。60% 的 pass@1 与 10% 的 pass^8 意味着你拥有的是一个靠运气成功的智能体，而不是一个可以部署的智能体。对于面向客户或后果严重的任务，你希望 pass^k 很高——这意味着你需要显式地对其进行评估。

针对轨迹评分，而不仅仅是结果。 一个通过错误的中间路径到达正确最终状态的智能体隐藏了一个潜在的失败。记录完整的记录，包括工具调用、中间输出和推理追踪。检查轨迹是否有效，而不仅仅是最终状态是否匹配。这对于那些意外的巧合可能从错误的推理中产生正确结果的任务尤为重要。

在评估运行之间隔离状态。 评估基础设施的一个常见错误是允许状态在试验之间泄露。当试验 3 继承了试验 2 的产物时，失败就会变得相关——评估低估了真实的失败率，因为一个根因掩盖了看起来像是多次独立成功的表现。生产环境不会跨用户会话共享状态；你的评估环境也不应该这样做。

在评分器中加入部分得分机制。 二元的通过/失败会丢失关于智能体接近程度的信号。一个包含五个子任务的任务，智能体完成了四个，这与完成零个的任务有本质区别。加权的部分得分（Partial Credit）能揭示二元评分所隐藏的进展，并为调试多步任务中哪些部分失败提供更好的信号。

在轨迹中途注入故障。 长时程任务会遇到工具超时、意外的 API 响应、模糊的状态和用户澄清。一个仅测试理想路径（happy path）的评估无法揭示当出错时智能体将如何响应。添加一些评估案例：让工具在任务中途返回错误，让早期的假设在轨迹后期变得无效，以及让智能体需要修正其计划。

添加断路器以检测崩溃。 在生产智能体中，对工具调用序列实施滑动窗口监控。重复相同的工具调用、上下文迅速增长而没有进展，或者工具输出与之前的成功调用相矛盾，这些都是崩溃的前兆。评估框架应该识别这些模式出现的时间，并将其与简单的任务失败分开记录——它们代表了一类性质不同的问题，需要不同的修复方法。

使评估时程与部署时程相匹配。 如果你的生产智能体处理需要 20-30 步的任务，你的评估就需要包含该长度的任务。一个常见的错误是根据易于设置的任务（短、定义明确、有明确的成功标准）构建评估，但随后部署到完全不具备这些特征的任务中。评估套件应该覆盖你实际工作负载的任务长度分布。

前进方向

2025 年和 2026 年真正重要的基准测试并非那些数值最高的。而是那些对生产环境还原度最高的：动态环境、多步任务、一致性要求以及不可逆操作。τ-bench 的 pass^k 指标、SWE-Bench Pro 的多文件复杂度要求，以及 GAIA 的工具调用协作能力，之所以更难获得高分，正是因为它们更难以被“刷榜”。

对于构建智能体的团队来说，实际的结论是：基准测试排行榜上的名次并不能很好地代表其生产环境的就绪程度。工作的重点在于构建能够模拟长周期任务故障条件的评估基础设施——例如复合错误、状态漂移、工具性能下降和系统崩溃——并在这些情况出现在生产环境之前就进行测试。这种基础设施比单轮评估更难构建，但在评估变得更具挑战性之前，基准测试与生产环境表现之间的差距是无法缩小的。

构建运行 20 步的评估任务。测量 pass^k 指标。测试从任务中途失败中恢复的能力。基于你自己的真实流量构建的基准测试，会比任何排行榜都更有参考价值，因为它会具体告诉你你的智能体在哪些环节会崩溃。