Jenova.ai 长上下文智能体编排基准测试 (2026年2月)


2026-02-24


Jenova.ai 长上下文智能体编排基准测试 — 31个场景中领先AI模型的准确性、速度和成本结果

概述

本基准测试衡量前沿 AI 模型在现实的、非编码工作流中,在极端长上下文压力(10万+词元) 下做出正确的下一步编排决策的能力。每个模型都从三个维度进行评估:准确性(场景正确率)平均延迟平均推理成本(输入+输出词元)

核心结果: Claude 4.5 Opus (76%)Gemini 3.1 Pro Preview (74%) 在基准测试中领先。更广泛地看,Claude 和 Gemini 模型家族在排行榜顶部占据主导地位——这与广大 LLM 社区对其强大的指令遵循和智能体能力的评估一致。表现最好和最差的模型之间差距接近2倍,揭示了传统基准测试未能捕捉到的差异化。


为何设立此基准测试

AI 行业在基准测试方面投入巨大。SWE-bench Verified 评估在真实 GitHub 仓库中修复 bug 的能力。GAIA 测试多工具问答。AgentBench 在八个交互式环境中对智能体进行压力测试。WebArena 衡量网页导航能力。τ-bench 评估在客户服务场景中的工具调用。这些基准测试在推动智能体能力发展方面发挥了重要作用。

但存在一个模式:这些评估大多数都集中在以编码为中心的任务短到中等上下文的交互上。SWE-bench 衡量 Python 仓库中的代码修复。WebArena 测试在模拟网站上的导航。τ-bench 评估在狭窄服务对话中的工具调用。即使是其中范围最广的 GAIA,也主要测试智能体是否能得出正确的最终答案——而不是它是否能在极端上下文压力下做出正确的编排决策

在生产级的智能体系统中,最难的问题不是回答一个问题或修复一个 bug。而是决定下一步该做什么——在一个12步工作流的第7步,当累积了15万词元的状态时,正确的行动需要综合系统提示中的指令、先前步骤的结果、用户的原始意图以及当前的进展状态。

现有的基准测试没有孤立地评估这种能力。而 Jenova.ai 长上下文智能体编排基准测试做到了。


此基准测试衡量什么

每个场景都回答一个问题:

当一个模型被置于拥有超过10万词元上下文的工作流编排者的角色时,它能否持续做出正确的下一步决策?

每个场景都向模型展示一个进行中工作流的真实、冻结的快照。输入可以包括对话历史、先前工作流步骤的累积结果、用户的当前请求以及特定领域的指令。模型必须分析这个密集的状态,并确定唯一正确的下一步行动,以推动工作流走向完成。

这些不是合成的推理谜题。这些场景源自真实世界的非编码工作流,涵盖研究、生产力、沟通、文档生成、日程安排、数据分析和多应用协调——这些任务定义了日常智能体的效用,但在基准测试领域却基本上被忽略了。


基准测试设计

场景

该基准测试包含 31 个场景(并且还在不断增加),每个场景代表一个潜在的单步或多步工作流中的关键决策点。每个场景都要求模型:

  1. 解析一个长上下文状态——通常超过10万词元——包括对话历史、累积的工作流结果、上传的文件、用户偏好和系统级指令。
  2. 在对话的完整上下文和任何先前已采取的行动中理解用户的意图
  3. 确定正确的下一步行动——即根据所提供的编排指令,能够正确推进整个工作流的唯一决策。

场景的多样性是刻意为之的。它们跨越了广泛的领域和复杂性级别,以测试模型是否能够泛化其编排能力,而不是对狭窄的任务类型产生过拟合。

评估标准

  • 二元评分。 每个场景被评为正确或不正确。没有部分分数。
  • 多个有效行动。 在多个行动都可以被合理地认为是正确的情况下,所有有效的选项都经过预定义并被接受。
  • 三个维度。 每个模型都从以下方面进行评估:
    • 准确性——模型选择正确下一步决策的场景百分比
    • 速度——所有场景的平均处理时间
    • 成本——每个场景的平均推理成本(输入+输出词元),反映了为每个决策处理10万+词元上下文的经济现实

模型配置

所有模型都在温度为0的情况下运行,并使用该模型可用的最低推理/思考设置。这反映了现实世界中的智能体编排环境,在这些环境中,确定性、速度和成本效益比创造性探索更重要。目标是评估模型的基础指令遵循和决策能力,而不是在给予无限计算资源时“更努力思考”的能力。


此基准测试有何不同

1. 非编码智能体评估

现有的智能体基准测试严重偏向于软件工程。SWE-bench Verified 评估在真实仓库中修复 bug 的能力。Terminal-Bench 测试 DevOps 和系统管理。即使是像 τ-bench 这样更广泛的基准测试,也专注于客户服务场景中狭窄的工具调用模式。

本基准测试针对通用的日常工作流——专业人士、研究人员和消费者实际需要 AI 智能体处理的多步骤任务。研究综合、邮件协调、日历管理、文档创建、多平台信息收集。这些工作流定义了现实世界中智能体的效用,却一直被系统性地低估。

2. 长上下文压力测试

这不仅仅是一个碰巧使用长上下文的基准测试。长上下文本身就是重点。每个场景都被设计为输入超过10万词元,迫使模型在密集的信息环境中保持连贯性、跟踪状态并提取相关信号。

许多在短上下文基准测试中表现良好的模型,在长上下文压力下性能会显著下降。正如最近关于LLM智能体评估的调查所指出的,短上下文和长上下文性能之间的差距仍然是模型能力中最少被衡量的维度之一。 本基准测试直接揭示了这一差距。

3. 最小化污染风险

本基准测试中使用的编排逻辑、行动分类法和工作流结构完全为 Jenova.ai 专有。没有任何公开的数据集、开源框架或已发表的论文描述了正在测试的特定决策模式。

数据污染是流行基准测试中一个有据可查的问题——模型可能在训练期间见过测试问题或其近似变体,从而夸大了它们的分数。《2025年斯坦福AI指数报告》特别强调,污染是基准测试有效性的一个持续挑战。

由于我们的编排逻辑和提示结构是专有的,并且在公共网络上没有任何存在,与基于公开可用数据集构建的基准测试相比,污染的可能性极低。与任何涉及闭源权重模型的评估一样,我们无法对预训练数据做出绝对保证——但该设计通过构造最小化了这种风险。

4. 与生产相关的指标

学术基准测试通常只优化准确性。在生产级的智能体系统中,准确性是必要但不足够的——你还需要知道一个模型能以多快的速度和多低的成本做出正确的决策。正如 Pluralsight 的 2026 年模型比较 在 SWE-bench 上所展示的,一个得分更高但成本高出14倍的模型,根据错误容忍度和业务量,可能是一个更差的生产选择。本基准测试报告所有三个维度,因为最佳的编排模型取决于您特定用例的准确性-成本-速度比率。


结果与分析

性能层级

根据结果,我们观察到三个不同的性能层级:

第一梯队:强大的编排者 (65%+)

模型准确性平均速度平均成本
Claude 4.5 Opus76%4.1s$0.35
Gemini 3.1 Pro Preview74%32.9s$0.13
Gemini 3 Pro Preview66%8.8s$0.12
Gemini 3 Flash Preview66%5.3s$0.03
Claude Opus 4.665%4.8s$0.35
Claude Sonnet 4.565%4.2s$0.21

Claude 和 Gemini 模型家族显然处于领先地位——这一结果与更广泛的 LLM 社区对其指令遵循和智能体能力的共识相符。值得注意的是,Gemini 3 Flash Preview 在准确性上与 Claude Opus 4.6 持平,均为66%,但成本仅为0.03美元,而后者为0.35美元——在同等性能下成本相差12倍,这使其可以说是基准测试中效率最高的编排者。

第二梯队:能力尚可但不稳定 (55–64%)

模型准确性平均速度平均成本
DeepSeek V3.261%9.4s$0.02
Claude Sonnet 4.658%4.8s$0.21

这一梯队的模型表现尚可,但在长上下文压力下表现出更多的不稳定性。Claude Sonnet 4.6 的58%相较于其4.5版本(65%)有明显下降,这表明模型代际升级并不总能转化为编排能力的提升。

第三梯队:低于55%

模型准确性平均速度平均成本
MiniMax M2.550%20.5s$0.02
GPT-5.248%2.5s$0.10
Grok 4.1 Fast47%6.7s$0.01
Kimi K2.547%12.1s$0.01
GLM 544%28.2s$0.02

这里有几点观察:

  • GPT-5.2 的48%是一个值得注意的结果。 它是基准测试中最快的模型(2.5秒),但准确性却是最低的之一。这与“最低推理设置”的限制直接相关——GPT系列模型为推理密集型配置进行了大量优化,当这种扩展推理被移除时,其在长上下文压力下的基础指令遵循能力会大幅下降。这并不表示其存在根本性弱点,而更多地表明其架构对推理计算的依赖性,而其他模型家族在同等程度上并不共享这种依赖。

  • 领先的中国开源模型——Kimi K2.5 (47%)、GLM 5 (44%) 和 MiniMax M2.5 (50%)——在此基准测试中表现相对较弱。 一个可能的因素是训练资源的分配。这些模型通常在比西方同行更紧张的计算预算下开发,因此可能会合理地将训练能力优先投入到已建立的、高知名度的基准测试类别(如推理、编码、知识)中,因为在这些类别中取得有竞争力的表现对于市场定位至关重要。而长上下文编排泛化能力——一个没有现有公共基准测试可供优化的能力——可能因此得到的针对性关注较少。这是一种理性的优先排序,而非根本性的局限,我们预计随着针对编排的评估变得更加成熟,这一差距将会缩小。

关键观察

1. 领先模型之间的编排能力存在显著差异。

表现最好和最差的模型之间的差距接近2倍(76% vs. 44%)。考虑到这些模型中有许多在 MMLU、GPQA 或 LMArena 等成熟基准测试上的得分仅相差几个百分点,这一点尤为引人注目。长上下文智能体编排揭示了传统基准测试未能捕捉到的差异化。

2. 准确性、速度和成本之间的相关性并非如你所想。

最昂贵的模型并非最准确的(Claude Opus 4.6 成本为0.35美元,得分为65%,而同价位的 Claude 4.5 Opus 得分为76%)。最快的模型(GPT-5.2 为2.5秒)是准确性最低的模型之一(48%)。最便宜的模型覆盖了整个准确性范围——从 Grok 4.1 Fast 的47%(0.01美元)到 Gemini 3 Flash Preview 的66%(0.03美元)。这再次强调了将所有三个维度结合评估的重要性——这一发现与正在成为智能体评估最佳实践的成本-性能帕累托分析相一致。

3. 长上下文压力下的指令遵循能力是差异化的关键。

大多数模型出错的场景往往有一个共同的模式:正确的行动要求模型优先处理深埋在上下文中的特定指令,而不是一个更“明显”或“默认”的行动。在此基准测试中表现出色的模型展示了卓越的能力,即即使相关指令被数万词元的竞争信息所包围,也能保持指令的保真度。 这与 GAIA 评估框架 的发现相符,其中最苛刻的任务——需要广泛规划和多工具集成——仍然是智能体能力的真正试金石。

4. 最低推理设置暴露了基础能力的差距。

所有模型都在其最低推理设置下进行评估。一些以在高推理模式下表现强劲而闻名的模型在这里显示出令人惊讶的疲弱结果。我们观察到,某些模型家族在实现可靠性方面,对扩展推理模式的依赖性要大得多。 当这种推理计算被移除时——在延迟和成本约束占主导地位的生产编排环境中必须如此——其底层的指令遵循能力便暴露无遗。这是 GPT-5.2 表现不佳的主要因素:其架构为推理密集型工作流进行了大量优化,而最低推理的限制对其影响尤为严重。


方法论说明

  • 可复现性。 每个场景都是一个静态、确定性的评估。没有实时工具执行,没有外部 API 依赖,也没有随机变化。在给定相同的输入和模型配置下,结果是完全可复现的。这解决了智能体评估研究中提出的一个关键问题:智能体的非确定性通常需要跨多次运行进行统计评估。由于本基准测试在温度为0的情况下评估每个场景的单个决策点,因此它实现了确定性的可复现性,而无需进行多次运行的聚合。
  • 输出评分。 模型输出根据每个场景预定义的一组可接受的下一步决策标签进行评估。当多个行动有效时,所有这些行动在评估前都包含在允许的集合中。
  • 场景选择。 场景经过精心策划,以代表现实的编排挑战,而非对抗性的边缘案例。目标是衡量与生产相关的能力,而不是设计模型的失败。
  • 持续扩展。 该基准测试正在积极维护中。随着生产使用中出现新的工作流模式,会添加新的场景。当前版本(n=31)代表了首次发布。

在基准测试领域中的定位

基准测试主要焦点上下文长度领域
SWE-bench Verified修复真实GitHub仓库中的bug中等编码
GAIA多工具问答中等通用
AgentBench多环境智能体行为不定8个领域
WebArena网页导航任务短–中等网页
τ-bench服务场景中的工具使用客户服务
Jenova 编排基准测试长上下文下的下一步决策10万+词元非编码工作流

本基准测试不与现有评估竞争或取代它们。SWE-bench 仍然是编码智能体的标准。GAIA 仍然是通用智能体能力最广泛的测试。本基准测试隔离了一个不同的层面:在非编码领域极端上下文压力下的下一步决策质量。


对智能体设计的影响

我们的结果表明,编排能力与推理能力是不同的。 在推理基准测试上的高性能并不能保证在长上下文编排上的高性能。

对于构建智能体系统的开发者来说,这种解耦具有实际意义:

  1. 模型选择。 “最聪明”的模型不总是最可靠的编排者。仅根据推理基准测试评估模型可能会导致为编排层选择次优的模型。
  2. 成本优化。 如果在上下文压力下具有更优的指令遵循稳定性,推理开销较低的模型可以胜过昂贵的前沿模型。在生产规模下,这种差异会显著放大。
  3. 架构。 依赖单个模型同时进行编排和任务执行可能效率低下。专门的路由——使用高稳定性的模型负责编排层,使用高推理能力的模型负责特定的子任务——可能会以更低的成本获得更好的可靠性。

我们发布这些结果,旨在为该架构决策提供一个数据点。随着我们扩展场景集以覆盖更多领域和工作流模式,我们将继续更新这些指标。


Jenova.ai 长上下文智能体编排基准测试由 Jenova 工程团队开发,用于评估模型在生产编排环境中的性能。有关技术咨询或方法论详情,请联系 [email protected]