LOCA-bench：在可控和极端上下文增长下评估语言代理 LOCA-bench: Benchmarking Language Agents Under Controllable and Extreme Context Growth
提出可控扩展环境状态的基准测试，揭示语言代理在长上下文下的性能退化与失败模式
前置知识
上下文窗口（Context Window）
大语言模型在单次推理中能够处理的文本长度上限，通常以token数量衡量。现代前沿模型如GPT-5.2支持400K tokens，Gemini-3-Flash支持1050K tokens。上下文窗口决定了模型能「看到」多少历史信息，直接影响其在复杂任务中的表现。随着上下文长度增加，模型性能往往会下降，这一现象被称为「上下文腐烂」（context rot）。
本文的核心研究对象就是模型在不同上下文长度下的性能变化，理解上下文窗口的概念是理解论文实验设计的基础
语言代理（Language Agent）
以大语言模型为核心，能够通过工具调用与外部环境交互、执行多步骤任务的智能系统。与传统的单轮问答不同，语言代理需要探索环境、遵循指令和计划、提取有用信息并预测正确动作。代理通常采用ReAct等框架，将推理（Reasoning）与行动（Acting）相结合。
LOCA-bench评估的不是静态的长文本理解能力，而是代理在动态探索过程中处理长上下文的能力
环境描述长度（Environment Description Length）
本文提出的新指标，用于量化代理环境的复杂度。具体计算方法是：运行脚本化的工具调用来获取代理需要读取的所有工具输出，将这些文本拼接后使用GPT-4的tokenizer进行分词，记录token数量作为环境描述长度。这个指标类似于信息论中的描述长度概念，用编码数据所需的比特数来衡量数据复杂度。
这是本文控制实验变量的核心机制，通过调整环境描述长度来隔离上下文长度对代理性能的影响
上下文工程（Context Engineering）
一系列用于优化代理上下文使用效率的技术策略，包括：上下文编辑（如清除过时的工具调用结果、删除思考内容、压缩对话历史）、上下文感知（让模型实时了解剩余上下文容量）、记忆工具（跨对话的持久化存储和检索）、程序化工具调用（通过代码编排工具而非逐个调用）。这些策略旨在缓解上下文窗口压力，帮助模型在长交互中保持专注。
论文的重要贡献之一是系统评估了不同上下文工程策略的效果，为代理设计提供了实用指导
研究动机
现有长上下文基准测试主要评估单步设置下模型从长文本中检索信息的能力，例如「大海捞针」测试或单步聚合分散事实。然而，现实世界中的代理任务是动态的：代理通常从有限的环境知识开始，必须在执行过程中决定要查找什么、探索什么，并将新发现的信息不断添加到上下文中。核心难点不仅在于一次性找到正确的证据，还在于随着上下文增长在每个动作上保持组织性和可靠性。在实际应用中，如软件工程、深度研究和代理工作流，随着任务复杂度增加，代理需要在上下文中跟踪的文本量从几千个token扩展到数十万、数百万甚至更多。尽管前沿模型提供了数百万token的上下文窗口，但在实践中它们并不能同等有效地使用上下文的每个部分，随着token增加，性能往往变得不一致且更容易出错。
本文的目标是本文的具体目标是创建一个可控、可扩展的基准测试平台LOCA-bench，用于评估语言代理在长上下文、代理场景下的表现。该基准测试需要满足四个设计原则：（1）复杂推理驱动的探索，不同于主要测试单步检索的现有基准；（2）通过可扩展环境实现可控的上下文扩展，保持任务语义固定；（3）可验证的评估，使用基于规则的脚本检查任务后环境状态；（4）可扩展的测试平台，支持评估不同模型和上下文管理策略。
与已有工作不同的是，本文的独特切入角度是将语言代理视为模型和脚手架（scaffold）的组合，并通过自动化的环境状态生成来控制上下文长度。具体而言，LOCA-bench通过调整环境描述长度（如Excel表格大小、PDF文件大小、数据库规模）来调节代理需要处理的上下文量，同时保持底层任务提示固定。这种设计使得LOCA-bench能够以可控的方式将上下文长度扩展到潜在无限，同时保持任务语义不变。此外，论文不仅评估模型的原生长上下文能力，还提供了上下文工程工具包，评估不同上下文管理策略的效果。
核心方法
LOCA-bench的整体思路是：首先从Toolathlon基准测试中选取15个高质量的种子任务，这些任务来自真实场景并配备了多样化的工具集；然后通过可配置的环境生成器，自动创建不同规模的环境状态，使环境描述长度从8K到256K tokens可控变化；最后使用规则化的评估脚本检查代理完成任务后的环境状态，给出二元化的成功/失败评价。技术路线的核心创新在于「解耦」：将环境、工具、任务和脚手架分离，使得可以独立评估每个组件对代理性能的影响。具体实现上，论文构建了本地的模拟服务器（如Google Calendar、Canvas、Email、BigQuery等），使用简化的本地数据库模拟远程服务后端，避免了复杂的认证需求，同时提供了透明且易于控制的后端，允许灵活注入数据和操纵环境描述长度。
LOCA-bench的核心创新点在于「可控的环境状态扩展」。不同于传统长上下文基准测试假设静态设置（模型预先接收所有相关信息，或通过简单的检索步骤获取），LOCA-bench模拟真实的代理场景：代理从有限的环境知识开始，必须通过工具调用逐步探索环境。通过调整环境配置参数（如课程数量、Canvas公告与邮件通知的比例），可以自动生成不同规模、难度和干扰水平的环境状态。这种设计使得LOCA-bench能够以可控的方式将上下文长度扩展到潜在无限，同时保持底层任务语义不变，从而隔离上下文长度对代理性能的影响。与已有方法的本质区别在于：LOCA-bench不仅测试检索能力，还测试复杂推理、指令遵循、环境探索和幻觉控制等综合能力。
方法步骤详情
LOCA-bench的方法步骤如下：（1）种子任务选择：从Toolathlon基准测试中选取15个高质量种子任务，涵盖Canvas课程管理、邮件处理、BigQuery数据分析、WooCommerce库存管理等多种场景，共包含280个工具。（2）环境配置定义：为每个任务定义环境配置参数，如课程数量M、Canvas公告比例P、邮件通知比例1-P等。（3）环境状态生成：使用预定义的模板（课程、考试、公告、邮件等）和自定义生成器，根据环境配置参数实例化具体的环境状态，注入到模拟服务器中。（4）环境描述长度控制：对每个任务创建7个不同目标长度的配置（8K、16K、32K、64K、96K、128K、256K tokens），每个长度使用5个随机种子生成不同的环境状态，共525个样本。（5）代理评估：使用ReAct代理脚手架，在每个环境状态下运行代理，记录轨迹长度、工具调用次数、工具输出长度等效率指标。（6）结果验证：使用手动实现的评估脚本，比较代理产生的最终环境状态与真实环境状态，给出二元化的成功/失败评分。
技术新颖性
LOCA-bench的技术新颖性体现在多个方面：首先，提出了「环境描述长度」这一新指标，用token数量量化代理环境的复杂度，这是对信息论中描述长度概念的创造性应用；其次，设计了可扩展的环境构建框架，通过模板和生成器自动创建不同规模的环境状态，实现了上下文长度的可控扩展；第三，将语言代理评估解耦为环境、模型和脚手架三个独立组件，使得可以系统评估不同上下文工程策略的效果；第四，构建了本地模拟服务器避免真实服务的认证和维护问题，同时保持工具接口的一致性；第五，识别并系统分析了代理在长上下文下的四种主要失败模式：复杂推理能力下降、指令遵循能力下降、探索不足和幻觉。这些创新使得LOCA-bench成为首个专门针对长上下文代理场景的基准测试。
实验结果
LOCA-bench的实验结果揭示了语言代理在长上下文下的显著性能退化。在短上下文设置（8K tokens）下，大多数模型表现强劲，准确率通常超过70%，其中Claude-4.5-Opus达到96%。然而，随着环境描述长度增加，性能急剧下降：在256K tokens时，Claude-4.5-Opus降至14.7%，GPT-5.2-Medium降至21.3%，开源模型如Kimi-K2-Thinking更是降至2.7%。前沿模型与开源模型的差距在长上下文下显著扩大，前沿模型的准确率约为开源模型的2-3倍。在效率指标上，大多数模型的轨迹长度和工具调用次数在描述长度达到96K后趋于平稳，表明模型的探索行为受到限制。工具输出token数量与任务准确率强相关，前沿模型检索的工具输出远多于开源模型。上下文工程技术显著影响代理性能：程序化工具调用在所有模型上表现最佳，在128K设置下将GPT-5.2-Medium的准确率从38.7%提升至49.3%，将Claude-4.5-Opus从34.0%提升至40.0%，同时大幅减少轨迹长度。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 长上下文代理任务（128K环境描述长度） | 准确率(%) | Claude-4.5-Opus: 34.0, GPT-5.2-Medium: 38.7, Gemini-3-Flash: 21.3 | DeepSeek-V3.2-Thinking: 10.7, MiniMax-M2.1: 20.0, GLM-4.7: 10.7, Kimi-K2-Thinking: 8.0 | 前沿模型比开源模型高2-3倍 |
| 程序化工具调用策略（128K环境描述长度） | 准确率(%) | GPT-5.2-Medium: 49.3, Claude-4.5-Opus: 40.0, Gemini-3-Flash: 30.7 | 无策略: GPT-5.2-Medium 38.7, Claude-4.5-Opus 34.0, Gemini-3-Flash 21.3 | GPT-5.2-Medium提升10.6%, Claude-4.5-Opus提升6.0%, Gemini-3-Flash提升9.4% |
| 上下文感知策略（128K环境描述长度） | 准确率(%) | GPT-5.2-Medium: 41.3, Gemini-3-Flash: 33.3 | 无策略: GPT-5.2-Medium 38.7, Gemini-3-Flash 21.3 | GPT-5.2-Medium提升2.6%, Gemini-3-Flash提升12.0% |
| 短上下文代理任务（8K环境描述长度） | 准确率(%) | Claude-4.5-Opus: 96.0, GPT-5.2-Medium: 72.0, DeepSeek-V3.2-Thinking: 78.7 | 所有模型均表现良好 | 短上下文下模型差距较小 |
局限与改进
LOCA-bench存在多方面局限性。首先，种子任务数量相对有限，仅有15个，虽然相比传统长上下文基准测试（通常只有1-几个任务）已有显著提升，但可能无法完全代表真实世界代理任务的多样性。其次，环境描述长度的扩展主要通过增加环境状态中的无关信息实现，这可能与真实场景中上下文增长的模式存在差异——真实场景中新增信息往往与任务相关且需要被有效利用。第三，评估采用二元化的成功/失败标准，无法捕捉代理行为的细粒度质量差异，例如部分正确的解决方案或效率差异。第四，模拟服务器虽然简化了评估设置，但可能无法完全模拟真实服务的复杂行为和边界情况。第五，论文主要关注文本模态的代理任务，未涉及多模态代理场景。此外，论文的实验主要在128K环境描述长度下评估上下文工程策略，对更长上下文下的策略效果分析不足。
独立分析的弱点
LOCA-bench的主要弱点包括：（1）任务多样性不足：15个种子任务虽然涵盖多个场景，但仍可能无法代表真实世界代理任务的全部复杂性，特别是在需要长期规划和多步推理的任务上。改进方向是增加更多领域的任务，如医疗诊断、金融分析、科研实验设计等。（2）环境状态扩展方式单一：当前主要通过增加无关信息来扩展上下文长度，这可能导致模型学会简单的过滤策略而非真正的长上下文理解。改进方向是设计更复杂的环境状态扩展模式，如增加相关信息的密度、引入信息冲突等。（3）评估粒度粗糙：二元化的成功/失败标准无法区分部分正确的解决方案。改进方向是设计更细粒度的评估指标，如子任务完成率、效率分数、错误类型分类等。（4）上下文工程策略实现可能不够优化：论文实现的策略可能与前沿模型内部使用的策略存在差距，如Anthropic的官方程序化工具调用实现比论文实现效果更好。改进方向是与模型提供商合作，获取更优化的策略实现。
未来方向
基于LOCA-bench的成果，未来研究可以在多个方向展开：（1）长上下文代理训练：利用LOCA-bench生成的多样化训练数据，开发专门针对长上下文场景的代理训练方法，如课程学习、强化学习等。（2）自适应上下文管理：开发能够根据当前上下文状态动态调整策略的上下文管理方法，而非使用固定的阈值或规则。（3）多模态长上下文代理：将LOCA-bench扩展到包含图像、音频、视频等多模态信息的场景，评估多模态模型的长上下文能力。（4）协作代理：研究多个代理在共享长上下文环境下的协作机制，评估分布式上下文管理的效果。（5）可解释性分析：深入分析代理在长上下文下的决策过程，识别导致失败的具体认知瓶颈。（6）真实世界部署：将LOCA-bench的评估方法应用于真实的代理部署场景，验证基准测试结果与实际性能的相关性。
复现评估
LOCA-bench的复现性较好。论文已开源代码和数据，地址为https://github.com/hkust-nlp/LOCA-bench。评估框架基于GEM实现，具有高度兼容性和可扩展性。环境配置、随机种子和评估脚本均已发布，确保了结果的可重现性。模拟服务器使用简化的本地数据库，避免了真实服务的认证和维护问题，降低了复现门槛。然而，复现仍需要一定的算力资源，特别是评估前沿模型时需要API访问权限。论文提供的上下文工程工具包也使得研究者可以方便地测试自己的策略。总体而言，LOCA-bench为长上下文代理研究提供了一个可靠、可扩展的评估平台。
论文图表
展示了一个代理因探索不足而失败的案例。任务要求识别所有符合条件的产品并保存到CSV文件，但代理只获取了第一页结果（100个产品），未找到匹配项后就停止探索，错误地得出结论认为没有符合条件的产品。实际上商店包含200多个产品，正确行为应该是继续分页浏览剩余页面。图中用红色标注了失败的目标、导致失败的工具调用以及不匹配的最终工作空间。
这张图具体展示了论文识别的四种失败模式之一——探索不足，帮助读者理解代理在长上下文下的典型错误行为
展示了一个代理因复杂推理能力下降而失败的案例。任务要求从Canvas公告和邮件通知中收集期末考试详情，然后将每个考试映射到Canvas中的正确课程，最后输入到Excel表格中。正确执行需要结合部分重叠的证据并进行中间查找以保持课程-考试映射。然而，模型忽略了邮件中的考试信息，从未查询Canvas仪表板获取课程标识符，导致写入Excel的考试信息不完整。
这张图展示了论文识别的另一种失败模式——复杂推理能力下降，说明代理在长上下文下难以处理需要整合多个信息源的复杂推理任务
展示了一个代理因指令遵循能力下降而失败的案例。任务明确要求：「将这些结果记录在record.csv中，遵循该文件中使用的相同格式——不要更改列名。」然而，模型没有检查现有的csv文件，使用了不同的列名（A_conversion_pct和B_conversion_pct而非A_conversion %和B_conversion %），破坏了所需的格式。图中用红色标注了失败的目标、导致失败的工具调用以及不匹配的最终工作空间。
这张图展示了论文识别的另一种失败模式——指令遵循能力下降，说明代理在长上下文下更容易忽略明确的约束条件
展示了一个代理因幻觉而失败的案例。任务要求查询工厂机器的实时传感器数据并识别超出正常范围的读数。模型正确查询到机器M006在2025-08-19 12:30的振动值为1.61，但在后续编写Python代码时，将同一数据错误地记录为2.46，表明最终输出不再基于检索到的结果。这种问题在长上下文设置下被放大。图中用红色标注了失败的目标、导致失败的工具调用以及不匹配的最终工作空间。
这张图展示了论文识别的最后一种失败模式——幻觉，说明代理在长上下文下即使检索到正确信息，也可能在后续推理中产生扭曲
展示了一个使用程序化工具调用的成功案例。任务要求识别WooCommerce中库存低于阈值的产品。在检查工具输出格式后，模型选择使用程序化工具调用，在代码中调用WooCommerce工具检测库存低于阈值的产品，并在代码中显式处理了分页等操作。这种方法比逐个工具调用更高效，减少了上下文消耗，并能更好地处理边界情况。
这张图展示了论文评估的最有效的上下文工程技术——程序化工具调用的实际应用，帮助读者理解为什么这种技术能带来性能提升
展示了7个模型在7个不同环境描述长度下的轨迹长度（token数）。Claude-4.5-Opus的轨迹长度增长最快，从8K的33,231增长到256K的1,839,973，这主要因为其较小的上下文窗口（200K）导致需要更多工具调用来恢复被截断的信息。GPT-5.2-Medium的轨迹长度增长相对平稳，表明其能更有效地管理上下文。开源模型的轨迹长度普遍低于前沿模型，这可能限制了它们的探索深度。
这个表格提供了代理效率的定量数据，帮助分析模型在长上下文下的行为模式
展示了7个模型在7个不同环境描述长度下的平均工具调用次数。Claude-4.5-Opus和DeepSeek-V3.2-Thinking的工具调用次数最高，分别达到93.9次和48.4次，主要因为它们的上下文窗口较小。大多数模型的工具调用次数在描述长度达到96K后趋于平稳，表明模型的探索行为受到限制。GPT-5.2-Medium的工具调用次数相对稳定，表明其能更有效地利用上下文。
这个表格提供了代理工具使用行为的定量数据，帮助理解模型的探索策略
展示了7个模型在7个不同环境描述长度下的平均工具输出长度（token数）。Claude-4.5-Opus的工具输出长度最高，从8K的11,149增长到256K的1,537,605，表明其检索了大量工具输出。GPT-5.2-Medium和Gemini-3-Flash的工具输出长度相对稳定，表明它们能更有效地筛选信息。开源模型的工具输出长度普遍较低，这可能限制了它们获取足够信息的能力。
这个表格提供了代理信息检索行为的定量数据，帮助分析模型的信息获取策略
列出了LOCA-bench中15个种子任务各自使用的服务器（工具集）。任务涵盖多种场景：Canvas课程管理、邮件处理、BigQuery数据分析、WooCommerce库存管理、Google Sheets、Snowflake等。每个任务只访问这些工具的子集，由环境配置参数控制。这个表格展示了LOCA-bench任务设计的多样性和工具集的丰富性。
这个表格展示了LOCA-bench任务设计的多样性和工具覆盖范围，帮助读者理解基准测试的全面性