Scroll：阿里将上下文变可编程环境，长任务超最优37.4分

Context as an Environment: Programmatic Context Management for Long-Horizon Agents

在大语言模型（LLM）逐渐从单轮问答转向执行长期复杂任务（如仓库级软件工程、开放网络深度研究）的今天，智能体（Agent）面临着一个不可回避的物理瓶颈：随着交互轮次、工具调用和观察结果的不断累积，会话历史的长度将不可避免地远超单一模型的上下文窗口上限。更严峻的是，即使模型宣称支持百万级上下文，其在超长输入下的检索与推理能力也会随着长度的增加而显著衰退。

ArXiv URL：https://arxiv.org/abs/2608.21690v1

面对这一问题，现有的智能体框架通常采用两种妥协方案：上下文压缩（Context Compression）或外部记忆（External Memory）。无论是像 Claude Code、Cursor 这样的生产级工具通过截断旧片段、丢弃工具输出、生成摘要来压缩历史，还是通过向量数据库将信息提取为外部记忆存储，它们在本质上都犯了同一个错误——有损的信息取舍。这些系统要求在尚未知晓未来需要什么信息之前，就提前决定保留什么、丢弃什么。一旦关键细节在摘要或提取过程中丢失，即便原始日志仍躺在硬盘里，智能体也永远无法在后续任务中召回它们。

为了彻底解决长程任务中的历史遗忘问题，阿里巴巴集团与哥伦比亚大学的研究团队提出了一种颠覆性的上下文管理范式——Scroll。该研究放弃了将上下文视为“被动塞满文本的缓冲区”，而是将其重构为一个可执行的会话环境（Session Environment）。在这个环境中，上下文管理变成了一项模型最擅长的“编程任务”：智能体通过编写 Python 代码来检索、计算和投影历史状态，而底层的事件日志则无损地保存着所有交互真相。

实验数据揭示了这一机制的巨大潜力：以 Qwen3.8-Max 为基座模型，Scroll 在 1000 万 Token 级别的 BEAM 基准测试中达到了 73.1% 的准确率，超越此前最优的记忆系统 5.1 分；在长程行动基准 LOCA（256K 复杂度）上，更是取得了 86.7% 的惊人成绩，将此前公开发布的最优长程智能体远远甩开了 37.4 分。

为什么传统的上下文管理注定失败？

要理解 Scroll 的创新，首先需要看清当前系统在处理长上下文时的根本缺陷。

我们将智能体在 $t$ 个步骤后的会话状态定义为 $S_t = (L_t, P_t, V_t)$。其中 $L_t$ 是带有元数据的事件序列，$P_t$ 是事件引用的有效负载（如长文本工具输出），$V_t$ 是衍生的辅助状态（如记忆库）。然而，模型每次调用时，只能消耗一个受限的“工作视图”（Working View）$c_t$，其长度必须小于模型的上下文窗口上限 $C$。

因此，上下文管理的核心数学问题就是如何定义映射 $S_t \mapsto c_{t+1}$。

现有的压缩方法会在轨迹增长时应用一个有损算子，决定哪些片段能在紧凑化过程中幸存；外部记忆系统则在数据摄入时应用提取算子，固定了存储内容和未来的检索方式。这两条路线的致命弱点在于：它们都把压缩后的表征直接替换了原始历史。 对于长程任务而言，智能体可能需要在几千步之后，精确对比两次截然不同的工具输出日志，或者提取一个极为细微的报错代码。事前生成的摘要根本无法预测这种细粒度的未来需求。

研究人员敏锐地指出，解决这一困境的唯一出路是：将历史记录与模型的即时上下文剥离开来，用程序化的接口延迟信息的筛选决策，直到真正需要查询的那一刻。

Scroll 核心架构：将会话化为持久化可执行环境

基于上述洞察，Scroll 将完整的会话状态 $S_t$ 实例化为一个持久的、可执行的“会话环境”。在这个架构下，长篇累牍的交互记录不再被强行序列化到 Prompt 中，而是安放在模型上下文之外，由一套严密的组件进行管理。

这一会话环境主要由三个核心物理基础设施构成：

第一，只追加的事件日志（Append-only Event Log）。 这是智能体会话的绝对“事实来源”。每一次用户输入、模型响应、工具调用都被视为一个类型化的事件追加到日志中。Scroll 在底层采用了稳定的 SQLite 数据库来存储这些事件。相比于依赖大模型计算 Embedding 的向量检索，Scroll 默认使用确定性的 BM25 词法检索，这不仅避免了构建索引时高昂的 LLM 调用成本，还为每个事件分配了单调递增的不可变序列号（seq），确保历史具有稳定的寻址空间。

第二，持久化存储（Durable storage）。 对于工具返回的海量 JSON 数据、生成的巨型工件等“大块头”有效负载，将它们全塞进数据库行中是不明智的。Scroll 的做法是将小负载保留在 SQLite 内联存储，而将大负载转移到文件系统中的 JSON 或工件存储区。数据库行只保留一个长度受限的预览内容和一个指向外部文件的“恢复指针”。这使得底层的事件日志始终保持轻量和高查询效率。

第三，持久化运行时与常驻命名空间（Persistent runtime and resident namespace）。 这是 Scroll 区别于所有传统记忆系统的灵魂所在。Scroll 在模型调用之间维护了一个持久的、沙盒化的 Python 内核。这个内核的命名空间里存放着“环境对象”（如常驻的 Python 变量、延迟加载的句柄等）。这意味着，模型通过工具获取的数据可以直接绑定在 Python 变量上，而不需要将其转化为长文本塞进 Prompt 里。

每一次大模型被唤醒前，Scroll 的外壳程序只需在 Prompt 头部插入一段简短的“命名空间摘要”（Namespace Digest），告诉模型当前环境里有哪些变量名、它们的数据类型和形状尺寸即可。由于沙盒采用默认封闭（fail-closed）的安全机制，模型生成的代码被严格限制权限，只能通过声明的接口访问系统资源。

代码即上下文：用 `exec` 与 `print` 划定边界

有了底层的持久化环境，智能体如何构建自己的上下文？Scroll 引入了类似 CodeAct 的接口，将上下文管理转化为纯粹的编程任务。

研究团队为模型提供了一个受控的能力对象 ms（Memory Surface），它将底层的物理存储抽象为四种基本操作：定位（Location）、物化（Materialization）、计算（Computation）和暴露（Exposure）。

模型通过编写 Python 代码并使用 exec 执行来与环境交互。例如，模型可以编写代码在事件日志中搜索特定的用户偏好，或者提取某个工具返回的复杂列表。所有这些检索到的记录、工具输出和中间计算结果，都会一直驻留在 Python 内核的命名空间中，绝对不会自动进入模型的上下文中。

只有当模型在代码中明确调用 print() 打印出特定的投影结果时，这些被输出的内容才会被 Scroll 框架捕获，并作为下一次模型调用的“观察结果”插入到 Prompt 的工作视图中。

这种设计精妙地解耦了“全量数据处理”与“上下文注意力分配”。大模型本身具有极强的代码编写和逻辑处理能力，它完全可以写一段 Python 脚本，在沙盒里对几万条航班数据进行过滤、排序和聚合，最后只 print 出最符合要求的三条航班信息。如此一来，数以万计的 Token 在后台被无损处理，而主模型的上下文窗口却只消耗了寥寥数百个 Token。

优雅的驱逐算法与无上下文导航机制

尽管通过代码投影可以大幅减少不必要的信息，但在无限延伸的长程任务中，模型的“工作视图”迟早会触及预算上限 $\rho C$。传统系统此时会选择截断旧对话，而 Scroll 则引入了一套不会造成数据丢失的“驱逐与导航”机制。

当视图超出预算时，Scroll 会触发驱逐程序。该算法优先保护当前活动轮次、最近的尾部对话以及最新的工具结果。对于需要腾出空间的内容，它会按照恢复成本的递增顺序进行折叠：优先折叠已完成的工具有效负载（因为只需一个 seq 指针就能随时恢复），如果仍然超标，则移除整个旧的交互跨度。

最关键的区别在于：被驱逐出工作视图的内容并没有消失，它们依然完好无损地躺在事件日志中。

为了让模型知道“自己忘记了什么”，Scroll 独创了多级标题索引机制（Tiered Index of Headlines）。在日常交互中，模型每次生成回复时都需要顺手写一个极短的“标题”（Headline），概括当前的任务、状态或行动。Scroll 会将这个标题与底层日志的 seq 地址绑定。

当某段历史被驱逐出视图时，它的标题会被送入多级索引区。为了防止索引本身无限膨胀，Scroll 采用了对数级别的合并策略：最底层的索引块填满后，最新的块保留完整细节，而旧的块则被折叠成单行摘要并向上合并。经过 $n$ 次驱逐后，索引只占用 $O(k \log_k n)$ 个块。

这使得智能体在 Prompt 中始终拥有一个清晰的“历史导航地图”：对于最近发生的事，它能看到细粒度的锚点；对于很久以前的事，它能看到粗粒度的范围。当智能体需要回顾被驱逐的细节时，它不需要像盲人摸象一样进行模糊搜索，而是可以直接根据索引地图中的 seq 地址，通过代码精准无误地将原始负载重新提取到沙盒变量中。

实验验证：在极长与极复杂环境中的碾压性优势

为了验证 Scroll 的有效性，研究团队在两个极具挑战性的长周期设定下进行了评估：超长历史检索推理，以及长上下文环境中的推理与行动。

在千万级 Token 历史中大海捞针：BEAM 基准测试

BEAM 基准测试要求模型在长达数百万乃至上千万 Token 的连贯历史中进行问答。这不仅要求检索非相邻的证据，还必须跟踪随时间变化的状态、对重复信息进行去重，甚至对分布在各处的离散事实进行全局聚合。

在最极端的 BEAM_10M（1000 万 Token 历史）规模下，传统的长上下文模型直接读取已成奢望，必须依赖记忆系统。实验表明，以此前最强开源记忆系统配置为基准，Scroll 凭借无损环境和代码计算能力取得了 73.1% 的最高得分，比此前公开发布的最优系统（如 MemGPT 等专属记忆流变体）高出 5.1 分。

进一步的消融实验（Ablation Study）深刻揭示了 Scroll 各组件的价值。如果将 Scroll 退化为“有损压缩”（即在摄入时用摘要替换原始记录），系统的整体得分会断崖式暴跌至 19.9 分，在信息提取、时间推理和知识更新等必须保留精确数值的任务上几乎全军覆没。如果移除持久化 Python 内核（REPL），强迫所有工具结果序列化到 Prompt 中，系统性能会下降 7.3 分；这主要是因为没有代码环境辅助，模型无法对分散的记录执行过滤、连接或聚合操作。

在不断膨胀的环境中行动：LOCA 基准测试

LOCA 评估的是智能体在环境状态不断累积时，能否持续保持清醒的推理与行动能力。基准测试按照“环境描述长度”（即通过工具输出看到的环境状态 Token 总数）进行了划分。

在 256K 的最大环境复杂度下，研究人员对比了四种共享 Qwen3.8-Max 基座与工具集的策略：

摘要智能体（Summarization Agent）：定期将历史压缩为摘要的 ReAct 变体。
检索智能体（Retrieval Agent）：溢出历史被驱逐，但可通过召回工具重新访问。
传统 CodeAct 智能体：通过程序化调用工具。
Scroll。

数据表现出了惊人的差距：传统摘要方法在 256K 环境下的准确率直接暴跌，而 Scroll 则以 86.7% 的准确率稳居第一，较 128K 环境仅有极微弱的衰减。不仅如此，与 LOCA 论文中报告及排行榜上此前公开发布的最优长程智能体相比，Scroll 的领先幅度达到了夸张的 37.4 分。这强有力地证明了，将中间结果绑定在环境对象中进行代码级处理，远比在上下文中拖曳长篇乱码要稳健得多。

广泛的模型适配性与低廉的运行成本

Scroll 是否只是高度定制基座模型的特权？为了回答这个问题，研究人员在固定框架规则的前提下，替换了包括 Qwen3.7-Max、Deepseek-v4-pro、GLM-5.2 在内的六种不同基础模型。

结果显示，不同模型都能利用 Scroll 取得显著超越基线的成绩，证明了“将上下文视为可编程环境”是一项具有普适性的架构红利。当然，更强的代码能力和逻辑规划能力，能够让顶级模型更聪明地使用 exec 和 print，从而逼近系统的上限。

在成本效率方面，Scroll 展现出了极高的经济性。由于事件摄入（Ingestion）过程完全基于确定性存储，不需要任何额外的 LLM 调用；在查询时，大量冗余记录被 Python 脚本过滤在沙盒内部。统计显示，在千万 Token 的 BEAM_10M 任务中，Scroll 每项任务输入给 LLM 的中位数仅为 10.5 万 Token——这意味着模型实际上只“看”到了语料库的 1%，就完美完成了极高难度的长程推理。

结语与未来展望

总结而言，阿里与哥伦比亚大学共同提出的 Scroll 框架，不仅是一项工程实现上的突破，更是对 LLM 上下文管理哲学的一次彻底重构。

长期以来，我们习惯于将“增加 Context Window 上限”和“提高 RAG 检索精度”视为解决长文本问题的唯二路径。而 Scroll 向我们展示了第三条路：通过赋予模型一个持久的、可编程的会话环境，让上下文管理从框架的“隐式机制”转变为模型的“显式策略”。模型自己编写代码检索历史，自己决定将哪些计算结果打印到视野中，而底层系统只负责提供稳定确定的存储与沙盒执行。

这项工作也为未来的模型训练指明了新方向：既然边界被清晰划定，我们完全可以收集前沿模型（Frontier Models）在成功长程轨迹中的代码交互记录，去监督微调更小的模型。教会小模型在何时编写检索代码（Context Retrieval）、何时将结果注入视野（Context Injection），或许将是打造下一代低成本、高可靠端侧智能体的核心钥匙。