Command Palette
Search for a command to run...
轻装前行,CarryOn:为长程智能体构建面向对象的上下文
轻装前行,CarryOn:为长程智能体构建面向对象的上下文
Yuchen Lu Julian McAuley Lei Zhang
摘要
长程智能体在持久任务状态中积累进展,却反复处理描述该进展如何取得的交互历史。这引出一个自然的问题:长程上下文能否围绕可复用的进展而非产生该进展的历史来组织?本文提出 CarryOn,一个面向对象的上下文运行时,它围绕可复用的任务对象来组织任务续接。CarryOn 不再将压缩后的历史或重构的进展叙述作为任务续接的主要依据,而是从续接载体(continuation carriers)、补充执行上下文以及近期交互的实时尾部构建上下文视图。核心挑战在于,当周围历史被移除后,如何保持这一可复用基础的有效性:CarryOn 如何在每次折叠时无需重建完整表示即可更新该基础?CarryOn 跨折叠维护载体记录,根据绑定证据和适用的环境检查修订受影响的记录,同时沿用未受影响的记录并联合更新执行上下文。在 OSWorld2.0 和 BrowseComp-Plus 上的实验显示,增益分别提升 5.8% 和 7.0%,同时总 token 使用量分别减少 51.9% 和 22.9%。项目主页:https://ethannju.github.io/carryon。
一句话总结
加州大学圣迭戈分校的研究人员提出了 CarryOn,一种面向对象的上下文运行时,围绕可复用任务对象组织长期限 agent 延续,通过绑定证据和环境检查维护载体记录而无需完全重建,并分别在 OSWorld2.0 和 BrowseComp-Plus 上实现 5.8% 和 7.0% 的增益,同时将总 token 使用量分别降低 51.9% 和 22.9%。
核心贡献
- CarryOn 是一种面向对象的上下文运行时,围绕可复用任务对象而非原始或压缩后的交互历史来组织长期限 agent 延续。它结合了延续载体(continuation carriers)、用于目标、约束和未解决问题的执行上下文,以及最近交互的实时尾部(live tail)。
- CarryOn 在各次折叠之间维护载体记录,仅依据绑定证据和适用环境检查修订受影响记录,继续保留未受影响记录,并联合更新执行上下文,而无需在每次折叠时重建完整表示。
- 在 OSWorld 2.0 和 BrowseComp-Plus 上的评测表明,CarryOn 将 Claude Opus 4.7 的表现分别从 43.9% 提高到 49.7%,从 49% 提高到 56%,同时将总 token 使用量分别降低 51.9% 和 22.9%,将总成本分别降低 35.9% 和 7.1%。
引言
长期限 agent 经常会积累冗余上下文,因为交互历史重复了持久任务状态中已有的信息,这会提高 token 成本,并使延续依赖于可能偏离实际状态的选择性重建。已有方法通过压缩、摘要、检索、剪枝或外部化状态来处理该问题,但这些方法可能仍然围绕压缩后的历史而非可复用结果来组织延续。作者提出了 CarryOn,一种面向对象的上下文运行时,它结合了用于可复用任务对象及其显式使用条件的延续载体、用于活动目标和未解决问题的执行上下文,以及最近交互的实时尾部。折叠操作逐步将已覆盖的历史替换为更新后的面向对象上下文视图,保留 agent 继续执行时仍然需要的信息。
方法
作者提出了 CarryOn,一个旨在围绕可复用任务对象而非产生这些对象的原始交互来组织长期限 agent 延续的框架。这种方法允许已建立的进展被保留下来,供后续检查和使用,同时由显式上下文保留互补的延续信息。
该框架将 agent 的活动上下文组织为三个互补组件,形成上下文视图。延续载体向后续执行暴露可复用进展。这些载体保持稳定身份,并记录可复用内容或其位置,以及复用条件。CarryOn 支持三种形式的载体:外部对象,即独立存在于环境中的工作产物,例如代码文件;信息产品,即捕获通过交互获得的可复用发现;情境状态,即仅在特定应用或会话中可用的进展。执行上下文对这些载体进行补充,保留执行所需但未编码在可复用任务对象中的信息,例如当前焦点、未解决约束和待完成工作。最后,实时尾部包含自最近一次折叠以来累积的原始 agent 与环境交互。
在交互步骤 t,令 k 表示最近一次折叠,bk 表示该折叠所覆盖的最后一个交互步骤。该折叠建立了一组持续维护的载体记录 Ak 和执行上下文 Ek,而其后的交互保留在实时尾部 Lt=(hbk+1,…,ht) 中。因此,上下文视图定义为:
Vt=(Ak,Ek,Lt).
为了在执行过程中维护此上下文视图,CarryOn 会周期性地将实时尾部中积累的交互折叠到已维护的表示中。该更新过程分为四个不同阶段:候选跟踪、证据准备、联合编译以及验证与提交。
首先,在候选跟踪阶段,Tracker 会识别在后续执行中可能变得可复用的进展。它维护代表潜在新载体或对现有载体更新的候选项。一旦候选项达到能够支持延续的状态,Tracker 就请求对其进行编译,并指定应编译的内容以及支持该编译所需的证据。
接下来,在证据准备阶段,系统收集每个已选候选项被授权的证据。对于信息产品,它检查所选材料与已记录来源是否一致。对于外部对象和情境状态,它将请求绑定到相应的环境对象,并由 Grounder 对相关条件执行只读检查。生成的输入包 Ut 包含已选候选项、适用的载体记录、已授权来源材料、对象引用和可用的检查结果。
在联合编译阶段,Compiler 联合更新延续载体和执行上下文,以保留后续执行所需的信息。Compiler 接收已准备的输入包 Ut、当前执行上下文 Ek 以及实时尾部的时间顺序文本投影 Π(Lt)。它提出载体编辑 ΔAt 和修订后的执行上下文 Ek+1:
(ΔAt,Ek+1)=Compile(Ut,Ek,Π(Lt)).Compiler 仅针对已选候选项提出编辑,使每项编辑都以其授权证据为依据,同时根据整个实时尾部修订执行上下文,以保留与延续相关的信息。
最后,在验证与提交阶段,CarryOn 检查所提出的载体编辑是否仍然指向当前候选项和载体版本,并与授权证据一致。它还会验证所需的身份、引用和输出约束。如果这些检查通过,CarryOn 会原子地应用载体编辑并提交修订后的执行上下文,使折叠推进到已覆盖的交互。最终得到的载体集和执行上下文定义了下一个上下文视图中已折叠部分,而后续交互则开始新的实时尾部。如果检查失败,现有上下文视图和实时尾部保持不变。
实验
实验在 OSWorld 2.0 和 BrowseComp-Plus 上使用 Claude Opus 4.7 对 CarryOn 进行评测,衡量长期限计算机操作和信息查找任务中的任务性能、token 使用量和成本。CarryOn 在两种场景下均提升了任务得分,同时降低了 token 消耗和成本,并且即使执行长度增长,其上下文仍然保持紧凑。与滑动窗口和基于摘要的压缩方法的对比表明,仅靠激进地削减历史会损害性能,而 CarryOn 的面向对象组织能够保留有用的任务状态,并支持更好的延续。消融实验进一步表明,延续载体和执行上下文提供了互补信息,帮助 agent 从已建立的进展中恢复执行,而不是重复之前的工作。
相对于其 Claude Opus 宿主 agent,CarryOn 在 OSWorld 2.0 上同时提升了二元任务完成率和部分任务完成率,部分得分从 43.9% 提高到 49.7%,二元得分从 15.7% 提高到 19.4%。这些提升超过了其他被评测的前沿模型,同时将总 token 使用量降低 51.9%,将每任务成本降低 35.9%,表明在不牺牲任务性能的情况下降低了长期限执行成本。CarryOn 在同一宿主 agent 上为部分得分增加了 5.8 个百分点,为二元得分增加了 3.7 个百分点。提升后的得分超过其他前沿模型,同时每任务成本下降约三分之一,token 使用量下降超过一半。
相对于基线,CarryOn 在 OSWorld 2.0 和 BrowseComp-Plus 上均降低了每任务资源使用量。最大的节省出现在 OSWorld 2.0 上,总 token 使用量下降超过一半,总成本下降约三分之一,而 BrowseComp-Plus 则显示出较小但一致的降低。这些改进与更低的上下文处理开销一致,且不会牺牲任务性能。CarryOn 在两个基准上均降低了每任务总 token 使用量,OSWorld 2.0 上的相对降幅大于 BrowseComp-Plus。每任务总成本也有所下降,主要反映为 agent token 使用量和 agent 成本的减少,而非新增的运行时开销。
在 100 题的 BrowseComp-Plus 子集上,将 CarryOn 添加到 Claude Opus 4.7 后,准确率从 49.0% 提高到 56.0%,超过了被比较的前沿模型。这一提升伴随着相对于 Claude Opus 基线的更低 token 使用量和成本。CarryOn 将 Claude Opus 4.7 在该 BrowseComp-Plus 子集上的准确率从 49.0% 提高到 56.0%,使其领先于 GPT-5、o3、GPT-OSS-120B 和独立的 Claude Opus 基线。同一 CarryOn 配置与 Claude Opus 基线相比,将总 token 使用量降低 22.9%,将总成本降低 7.1%。
在共享的 OSWorld 2.0 子集上,仅靠激进上下文压缩会相对于未压缩基线同时降低二元得分和部分得分。在文本摘要中应用面向对象组织可以恢复大部分损失,但完整的 CarryOn 运行时达到最高的部分得分,同时与基线的二元得分持平。CarryOn 还以比引导式摘要方法更少的保留文本实现了这一结果。滑动窗口和通用摘要保留的上下文最短,但相对于基线降低了二元得分和部分得分。CarryOn-Guided Summary 恢复了大部分损失的部分得分,而完整 CarryOn 在折叠后文本约短 10% 的情况下将部分得分提高了 5 个百分点。CarryOn 与基线的二元得分持平,并在无需保留最多文本的情况下达到最高的部分得分。
在共享的 OSWorld 2.0 子集上的消融实验表明,执行上下文和延续载体都对 CarryOn 的部分得分有贡献。移除执行上下文会降低二元得分和部分得分,但 agent 调用次数基本不变;移除延续载体则会降低部分得分,并增加 agent 调用次数和成本。这两个组件似乎为任务延续提供了互补信息。移除执行上下文导致二元得分和部分得分大幅下降,而 agent 调用次数几乎保持不变。移除延续载体增加了 agent 调用次数和成本,同时部分得分下降,这表明 agent 不得不恢复或重现之前的进展。
CarryOn 在 OSWorld 2.0 任务完成评测和一个 100 题 BrowseComp-Plus 子集上使用 Claude Opus 宿主进行了评估;在这些评测中,CarryOn 相对于基线提升了部分得分、二元任务得分或准确率,同时降低了总 token 使用量和每任务成本。消融实验表明,仅靠激进上下文压缩会损害性能,而具有面向对象组织以及执行上下文和延续载体的完整运行时能够恢复或提升得分。两个载体组件提供互补支持,其中执行上下文主要保持任务成功,延续载体则减少 agent 调用并帮助 agent 避免重现之前的进展。