← 返回 2026-02-25

通用 LLM 智能体的测试时扩展基准测试 Benchmark Test-Time Scaling of General LLM Agents

Xiaochuan Li, Ryan Ming, Pranav Setlur, Abhijay Paladugu, Andy Tang, Hao Kang, Shuai Shao, Rong Jin, Chenyan Xiong 📅 2026-02-22 👍 10 2026-07-13 08:35
Benchmark LLM Agent Multi-Domain Evaluation Test-Time Scaling Tool Use

揭示通用LLM智能体存在性能退化与测试时扩展瓶颈

前置知识

Test-Time Scaling(测试时扩展)

测试时扩展是指在推理阶段通过增加计算量来提升模型性能的策略,而非在训练阶段增加参数。主要分为两种范式:(1)Sequential Scaling(顺序扩展),通过延长交互历史、增加推理轮数来让模型进行更深入的反思和探索;(2)Parallel Scaling(并行扩展),对同一查询独立采样多条轨迹(trajectory),然后从中选择最优结果。这一策略在数学推理等领域已被证明有效(如 Muennighoff et al., 2025 的 s1 工作),但在通用智能体场景下的表现尚不清楚。

本文的核心研究问题就是测试时扩展在通用智能体场景下是否依然有效,理解这两种扩展范式是读懂全文实验设计和结论的前提。

LLM Agent(大语言模型智能体)

LLM Agent 是以大语言模型为核心推理引擎,能够自主规划、调用外部工具(如搜索引擎、代码执行器、API)、与环境多轮交互并完成开放性任务的系统。与传统的单轮问答不同,智能体需要在不确定和动态变化的条件下,组合多种技能来处理用户请求。典型的智能体框架包括 ReAct(推理+行动)、Reflexion(反思)等。

本文评估的对象正是这类通用智能体,而非单纯的 LLM 推理能力。理解智能体的定义有助于把握为什么现有领域专用基准不足以评估通用智能体。

Model Context Protocol(MCP,模型上下文协议)

MCP 是由 Anthropic 提出的标准化协议,定义了 LLM 智能体与外部工具服务器之间的通信规范。在 General AgentBench 中,每个基准环境被实例化为一个 MCP 服务器,所有服务器由一个统一的 Host 管理。Host 维护全局工具注册表,向智能体暴露单一的统一工具空间。当智能体调用工具时,Host 路由请求到对应的服务器执行并返回结果。

MCP 是本文统一评估框架的技术基础,理解它有助于理解智能体如何在不知道任务领域的情况下选择和调用工具。

Pass@K 与 Self-Choice

Pass@K 是并行扩展的理想化上界指标:独立采样 K 条轨迹,只要其中至少一条正确即算通过,反映的是解空间的理论覆盖范围。Self-Choice 则是实际可用的评估方式:智能体必须从自己生成的 K 条轨迹中自主评估并选出最佳结果,分为 Point-wise(逐条打分)和 Pair-wise(两两比较排序)两种策略。Self-Choice 的准确率通常低于 Pass@K,两者之间的差距被称为验证缺口(Verification Gap)。

这对指标是本文分析并行扩展有效性的核心工具,验证缺口是本文最重要的发现之一。

Context Ceiling(上下文天花板)

在顺序扩展中,随着交互轮数增加,对话上下文不断累积。Context Ceiling 是指存在一个最大有效上下文长度,超过这个阈值后,更多的交互历史不仅不能带来性能提升,反而会导致性能波动或下降。这与模型的固有上下文长度密切相关——当累积上下文接近并略微超过模型的固有上下文长度时,性能达到峰值;大幅超过后则出现退化。

Context Ceiling 是本文关于顺序扩展的核心发现,直接挑战了「更多推理轮数 = 更好性能」的朴素假设。

研究动机

当前主流的智能体评估基准几乎都是领域专用的(domain-specific),例如 SWE-Bench 在 Docker 环境中评估软件工程能力,WebVoyager 在浏览器界面中评估网页导航能力,Tau2-Bench 在客服场景中评估工具调用能力。这些基准将任务环境和可用工具集限定在特定领域内,智能体无需判断「这个任务属于什么领域」「该用哪些工具」。然而,真实世界的用户请求是开放式的,往往跨越多个领域,需要智能体从一个大型的、混杂的工具池中自主选择合适的工具。研究表明,在这种领域专用设置下,现有基准可能高估了智能体的鲁棒性。例如,GPT-5 在领域专用设置下的综合得分约为 60.9,但在统一的通用智能体设置下骤降至 47.1,降幅达 22.7%。大多数模型的性能退化幅度在 10% 到 30% 之间。

本文的目标是本文的具体目标是:(1)构建一个统一的基准框架 General AgentBench,将搜索、编程、推理、工具使用四大领域的任务整合到一个共享界面中,模拟真实世界的多领域交互场景;(2)系统性地研究通用智能体在两种测试时扩展策略(顺序扩展和并行扩展)下的表现,回答「在通用智能体场景下,增加推理时间计算是否有效」这一核心问题;(3)对 10 个前沿 LLM 智能体进行全面评估,量化从领域专用设置到通用设置的性能退化幅度。

与已有工作不同的是,本文的独特切入角度在于抓住了两个被忽视的关键问题。第一,已有基准忽略了通用智能体需要「跨领域工具选择」这一核心能力——在真实部署中,智能体面对的是一个包含 301 个工具、35 个服务器的统一工具空间,必须先理解用户意图再选择工具。第二,测试时扩展在非智能体推理场景(如数学问题)中已被证明有效,但从未在通用多领域智能体场景下被系统研究过。本文首次将顺序扩展和并行扩展的分析框架引入通用智能体评估,发现了两个根本性限制——上下文天花板和验证缺口——这是此前文献中未被报告的。

核心方法

General AgentBench 的设计思路可以类比为一个「全能型考试」:传统基准像是学科专项测试(数学考试只考数学,编程考试只考编程),而 General AgentBench 则像是一场综合能力考试,考生需要先判断题目属于哪个学科,再从一个混杂的工具箱中找到合适的工具来解题。技术路线上,框架基于 MCP 协议构建了一个 Host-Client-Server 三层架构:所有基准环境(Docker 容器、搜索 API、推理引擎等)被实例化为 MCP 服务器,由统一的 Host 管理全局工具注册表,向智能体暴露一个跨领域的统一工具空间。智能体在不知晓任务领域的情况下,必须从 301 个工具中选择合适的工具,进行多轮交互直到产生最终答案。评估覆盖搜索(BrowseComp、WebVoyager)、编程(SWE-Bench Verified、Terminal-Bench)、推理(MathHay)和工具使用(Tau2-Bench、MCP-Bench)四大领域。

本文最核心的创新不是单个技术点,而是评估范式的转变——从「领域内评估」转向「统一通用评估」。已有基准的隐含假设是:如果一个智能体在各个领域单独测试时都表现良好,那么它在综合场景中也应该表现良好。本文通过实验证伪了这一假设:大多数模型在统一设置下出现 10%-30% 的性能退化。更关键的是,本文发现了两个此前未被报告的根本性限制:(1)顺序扩展的上下文天花板——在通用智能体场景中,更长的交互历史不一定带来更好的性能,反而可能引入干扰;(2)并行扩展的验证缺口——即使正确的解存在于采样空间中(Pass@K 上升),智能体也无法可靠地识别和选择它们。这两个发现从根本上挑战了「增加推理计算就能提升智能体性能」的乐观假设。

方法步骤详情

方法分为三个层面。第一层面是基准构建:从四个领域各选取两个现有基准(共 8 个),每个基准进行采样以控制评估规模(总计约 471 个样本),所有环境通过 MCP 协议统一接入。智能体接收统一的系统提示和工具描述,工具描述本身可达数万 token,加上用户查询和多轮交互历史,自然进入长上下文范畴。第二层面是评估框架设计:每个评估实例以多轮交互方式运行,智能体发出工具调用请求后,Host 路由到对应服务器执行并返回结果。即使任务是搜索类的,代码相关工具调用也可被执行(只是与解题无关),这暴露了真实的错误工具使用可能性。第三层面是测试时扩展分析:顺序扩展通过在智能体尝试结束回合时注入额外的环境反馈来鼓励进一步反思,上下文长度从 64K 扩展到 192K;并行扩展对每个查询独立采样 K=1 到 K=4 条轨迹,分别用 Pass@K 和 Self-Choice 两种指标评估。

技术新颖性

本文的技术新颖性体现在三个层面。首先是评估设置的创新:现有工作如 AgentBench、GAIA 虽然也涵盖多领域,但每个领域仍使用独立的工具集和交互协议,而 General AgentBench 首次将所有工具统一到一个共享界面中,暴露了跨领域工具选择这一被忽视的能力需求。其次是分析框架的创新:首次将测试时扩展的分析引入通用智能体场景,发现了上下文天花板和验证缺口这两个非智能体场景中不存在的根本性限制。最后是跨领域工具使用的发现:通过轨迹级分析,发现 Claude Sonnet 4.5 在 26% 的搜索任务中使用了超出搜索领域的专业工具(如 Google Maps API 78 次、arXiv/PubMed 论文搜索 60 次、HuggingFace 模型 API 36 次),这种跨领域工具组合能力在领域专用评估中是无法观察到的。

General AgentBench 的统一框架架构图
Figure 2: General AgentBench 的统一框架架构图
Qwen3-235B(全注意力)与 Qwen3-Next(混合线性注意力)的注意力行为对比
Figure 11: Qwen3-235B(全注意力)与 Qwen3-Next(混合线性注意力)的注意力行为对比

实验结果

本文的核心发现可以归纳为三个层面。第一,通用设置下的性能退化:在 10 个前沿模型中,Claude Sonnet 4.5 表现最为鲁棒,从专用设置的 45.1 分微降到通用设置的 45.0 分(仅 -0.2%);GPT-5 虽然在搜索和推理领域得分最高(搜索 39.1、推理 64.0),但综合得分从 60.9 降至 47.1(-22.7%);开源模型中 DeepSeek-V3.2 表现最佳(39.0 分),甚至超过了两个 Gemini 变体。最严重的退化出现在 Gemini 2.5-Flash 上,平均相对退化达 31.2%。BrowseComp(搜索稀有信息)在所有模型上表现一致低迷,GPT-5 也仅得 27.4 分。第二,顺序扩展的上下文天花板:对 Qwen3-235B 和 Gemini 2.5-Flash 的分析显示,性能在接近模型固有上下文长度时达到峰值(Qwen3-235B 约 112K,Gemini 2.5-Flash 约 96K),超过该阈值后性能饱和或退化。在推理领域,性能在窄范围内振荡(stagnant fluctuation);在编程领域,初始改善后一致性退化(saturation and degradation)。实例级分析表明,智能体要么反复在已擅长的查询上成功、在失败的查询上毫无进展,要么在 0 和 1 之间不稳定波动。第三,并行扩展的验证缺口:Pass@K 从 K=1 到 K=4 平均提升约 50%,DeepSeek-V3.2 在编程和推理领域接近翻倍。但 Self-Choice 性能始终低于 Pass@K 上界,甚至在某些情况下随 K 增加而下降。即使用 GPT-5 作为外部验证器,其表现也不如模型自身的自我判断,说明验证能力与生成能力之间存在根本性差距。

General AgentBench 的组成
Table 1: General AgentBench 的组成
General AgentBench 主要结果
Table 2: General AgentBench 主要结果
基线设置与通用设置的详细性能对比
Table 3: 基线设置与通用设置的详细性能对比
现有长上下文基准的分类体系
Table 5: 现有长上下文基准的分类体系
在真实用户交互场景下评估通用 LLM 智能体
Figure 1: 在真实用户交互场景下评估通用 LLM 智能体
从领域专用设置到通用设置的各领域相对性能变化
Figure 3: 从领域专用设置到通用设置的各领域相对性能变化
领域专用设置与通用设置的性能对比及平均相对退化
Figure 4: 领域专用设置与通用设置的性能对比及平均相对退化
通用 LLM 智能体的测试时扩展行为
Figure 5: 通用 LLM 智能体的测试时扩展行为
顺序扩展下的实例级正确性动态
Figure 6: 顺序扩展下的实例级正确性动态
Gemini 2.5-Flash 和 Qwen3-235B 的顺序扩展行为,标注固有上下文长度
Figure 7: Gemini 2.5-Flash 和 Qwen3-235B 的顺序扩展行为,标注固有上下文长度
生成能力与自我验证能力之间的验证缺口
Figure 8: 生成能力与自我验证能力之间的验证缺口
静态长上下文基准与智能体领域性能的成对相关性
Figure 9: 静态长上下文基准与智能体领域性能的成对相关性
模型之间的成对相关性
Figure 10: 模型之间的成对相关性
查看结构化数据
任务指标本文基线提升
BrowseComp(搜索) Accuracy GPT-5: 27.4, Claude Sonnet 4.5: 23.1 领域专用设置 GPT-5: 55.8, Claude Sonnet 4.5: 26.1 GPT-5 退化 -29.9%,Claude Sonnet 4.5 提升 +33.0%
SWE-Bench Verified(编程) Pass Rate Claude Sonnet 4.5: 54.0, Claude Haiku 4.5: 56.0 领域专用设置 Claude Sonnet 4.5: 49.2, Claude Haiku 4.5: 41.5 Claude Sonnet 4.5 提升 +9.8%, Claude Haiku 4.5 提升 +34.9%
MathHay(推理) Accuracy GPT-5: 64.0 领域专用设置 GPT-5: 64.0 GPT-5 无变化 0.0%,Gemini 2.5-Pro 退化 -60.8%
MCP-Bench(工具使用) Score Claude Sonnet 4.5: 72.9 领域专用设置 Claude Sonnet 4.5: 73.0 Claude Sonnet 4.5 退化 -1.4%
综合平均(所有领域) Avg Score Claude Sonnet 4.5: 45.0, GPT-5: 47.1 领域专用设置 Claude Sonnet 4.5: 45.1, GPT-5: 60.9 Claude Sonnet 4.5 退化 -0.2%, GPT-5 退化 -22.7%
顺序扩展(Qwen3-235B 搜索) Context Length vs Accuracy 峰值在 ~112K token 单次交互基线 初始改善后在超过阈值后退化
并行扩展(DeepSeek-V3.2 编程) Pass@K Pass@4 约为 Pass@1 的 2 倍 Pass@1 Self-Choice 增益迅速饱和,远低于 Pass@K

局限与改进

本文存在若干局限性。首先,评估规模受限于 API 成本:每个模型最多采样 4 条轨迹,上下文长度最多扩展到 192K token,这可能无法充分暴露更大 K 值或更长上下文下的行为。整个评估的 API 成本约为 $29,576(并行扩展)+ $24,392(顺序扩展),复现门槛较高。其次,Self-Choice 的评估仅使用了模型自身的判断能力,未探索更先进的验证器(如专门训练的过程奖励模型),因此验证缺口的实际大小可能被高估。第三,本文聚焦于 Pass@K 和 Self-Choice 两种最基本的扩展策略,未涉及更复杂的方法如 Tree-of-Thoughts、MCTS 或 self-correction,这些方法可能在一定程度上缓解观察到的瓶颈。第四,虽然框架暴露了 301 个工具,但这些工具的复杂度和交互模式仍有限,真实世界的工具生态可能更加复杂。最后,本文的分析主要关注性能指标,对智能体行为的定性分析(如错误模式分类、工具误用的具体原因)相对有限。作者也承认,静态长上下文基准(LongBench、HELMET、MRCR)与智能体领域的性能相关性很低(Pearson 相关系数普遍低于 0.7),说明现有长上下文评估方法无法替代智能体场景的评估。

独立分析的弱点

第一个弱点是验证策略过于简单。本文仅使用 Point-wise(逐条二元判断)和 Pair-wise(两两比较排序)两种 Self-Choice 策略,且未引入专门训练的验证器(如过程奖励模型 PRM)。改进方向是引入基于 PRM 的验证器或训练专门的轨迹排序模型,可能显著缩小验证缺口。第二个弱点是顺序扩展仅通过注入额外环境反馈来实现,缺乏更精细的上下文管理机制。改进方向包括:实现基于摘要的上下文压缩(将长交互历史压缩为关键信息)、引入分层记忆机制(短期/长期记忆分离)、或使用 context engineering 技术动态裁剪不相关的历史信息。第三个弱点是对跨领域工具使用的分析停留在统计层面,缺乏对失败案例的深入分析。例如,当智能体选择了错误领域的工具时,是什么导致了这种误判?是工具描述不够清晰,还是模型的意图理解能力不足?改进方向是建立工具误用的分类体系,并分析每种误用类型的根因。第四个弱点是评估中的静态与动态长上下文的对比分析不够深入。虽然论文指出静态基准与智能体性能相关性低,但未进一步探索哪些特定的上下文特征(如异质性、多轮交互、工具执行反馈)导致了这种差异。

未来方向

作者提出的研究方向包括:(1)开发更有效的上下文管理和推理控制机制,以突破顺序扩展的上下文天花板;(2)改进验证器能力,缩小并行扩展中的验证缺口;(3)探索介于顺序和并行之间的混合扩展策略。基于本文成果可延伸的方向包括:(a)将分析框架扩展到更多模型架构(如混合注意力模型),论文中已发现 Qwen3-Next(线性注意力)比 Qwen3-235B(全注意力)的扩展潜力更弱,这为注意力机制与扩展能力的关系研究提供了线索;(b)探索动态工具选择策略,让智能体根据任务阶段自适应地缩小工具搜索空间,而非始终面对全部 301 个工具;(c)将 General AgentBench 扩展到更多领域(如多模态交互、实时 API 调用),进一步逼近真实部署场景;(d)研究智能体的「自我诊断」能力——当智能体在通用设置下表现退化时,它能否识别出退化的原因(如选错了工具、上下文过长)并采取补救措施。

复现评估

论文已开源代码(https://github.com/cxcscmu/General-AgentBench),但复现面临几个挑战。首先是算力成本:完整评估 10 个模型的 API 费用总计约 $50,000-$60,000,其中 SWE-Bench 的编程任务成本最高(并行扩展下 $17,692)。如果仅评估单个模型的默认设置,成本可降至 $6-$3,569(取决于模型)。其次是数据可用性:所有基准数据均来自已有的公开数据集(BrowseComp、SWE-Bench Verified 等),但需要分别配置各个环境(Docker 容器、搜索 API 等)。第三是工具生态:框架包含 301 个工具、35 个服务器,配置较为复杂。论文提供了详细的提示模板和工具 Schema 说明,以及两种上下文压缩策略(compress-tools 减少 18.6% token,minimal-tools 减少 90.1% token),有助于降低复现成本。总体而言,复现难度中等偏高,主要瓶颈在于 API 成本和环境配置。