Pack Light, CarryOn: Building Object-Oriented Context for Long-Horizon Agents 论文阅读

全文概览

长程 Agent 会把进度留在文档、代码、表单和检索结果中，同时不断读取描述这些进度如何产生的交互历史。CarryOn 将可复用任务对象作为后续工作的依据，再单独维护当前目标、约束和未完成事项，以减少反复处理旧历史的开销。

它的主要设计是持续维护对象记录、为更新绑定证据，并把载体与执行上下文一起提交。历史退出当前提示词后，原始交互日志仍然保留。原型的检查保证记录和引用满足运行时约束，不代表任务已经正确完成。

下图先给出完整结构。上半部是 Agent 与环境的逐步交互，下半部在需要时整理可复用进度，最后把新视图交回 Agent。

图源：Yuchen Lu、Julian McAuley、Lei Zhang，原论文图 2，CC BY 4.0。查看高清流程图。手机内的细小标签可打开原图查看，后文按流程逐步解释。

阅读主线依次是进度与历史的关系、三类载体、四阶段更新、实验统计，以及适用边界与验证建议。下文数值来自作者报告，本文未复现实验。

背景与问题

以修改演示文稿为例，Agent 可能已经生成背景图片并应用到幻灯片，后续还要确认透明度与保存结果。文稿承载了已完成编辑，历史则记录生成图片、打开菜单和点击按钮的过程。若继续完整输入这些过程，模型会反复处理已经存在于任务对象中的信息。

历史压缩还面临一个问题：压缩后保留了什么，是否足以继续工作。文档存在不等于全部要求已满足，点击保存也不等于保存已经确认。CarryOn 因此把已建立的进度与剩余义务分别表示，并为对象记录保留适用条件。

论文把一次成功整理称为折叠，fold。折叠改变当前可见上下文，覆盖过的原始交互仍在只追加日志中。它不把全部历史永久删除，也不要求每次重新生成所有既有对象记录。原文第 1–3 节

整体方法与关键创新

三部分上下文承担不同职责

当前视图包括持续任务载体、执行上下文和最近交互。载体说明已有进度在哪里、怎样复用及其条件。执行上下文保存当前关注点、尚未解决的约束与下一步义务。最近交互保留自上次折叠以来的原始行动和观察。

载体有三类。外部对象是可以独立打开或修改的文件，例如文档和代码。信息产品是从多次交互中形成的可复用发现，内容与来源直接保存在记录中。情境状态依赖特定应用或会话，例如尚未提交的表单，必须记录环境锚点及可继续使用的范围。

同一任务可以同时包含三类载体。完成程度也不决定类型，一份仍待编辑但可以读取的文稿依然属于外部对象。稳定身份用来关联同一对象的后续版本，未变化的记录可继续沿用。原文第 3.2 节、附录 A.1

从候选到提交的四个阶段

Tracker 先跟踪可能复用的进度，并维护候选登记表。候选可以跨多次扫描逐步积累信息，登记或更新候选本身不触发折叠。达到可复用状态后，Tracker 才提出编译请求。

运行时随后固定候选版本、既有载体与被授权的证据。信息产品接受来源引用和摘录检查。涉及对象或环境状态时，Grounder 执行限定范围内的只读检查，例如文件存在、内容哈希是否变化、文件是否为空，以及文档容器结构。

检查结果分为支持、矛盾和未知。对象请求的全部声明条件得到支持后才进入编译，未知或矛盾条件不会被自动写成已验证结果。检查作用仍限于被声明、被观察的条件。

Compiler 同时修改选定载体和执行上下文。载体吸收可复用进度，执行上下文保留未被载体覆盖的目标和义务，避免刚生成一个对象记录就丢掉相关未完成要求。信息产品的修改依赖授权来源，不能凭模型概括补出环境事实。

最后，运行时核对身份、引用、版本和输出约束。一次成功折叠必须含有真实载体变更，仅改写执行上下文不会移走历史。通过后，载体更新与执行上下文一起提交，后续交互开始新的最近交互区间。原型还区分记录提交与安装到宿主对话，安装前保留消息状态快照。原文第 3.3 节、附录 A

触发规则影响成本

OSWorld 原型在自上次扫描或折叠以来的交互文本估计超过 6,000 tokens 时调用 Tracker，估计方式为文本字符数除以四，不含思考摘要。BrowseComp-Plus 按记录的提示词增长触发，初始门槛是 120,000 tokens 加 1,024 的余量，并要求有新检索结果。

这些是作者实验中的调度设置，不是通用最佳门槛，也不等于直接预测下一次折叠能省多少钱。没有合格请求时可以不折叠，原型还会对连续无折叠的扫描增加间隔。附录 A.3

实验与证据

先明确比较范围

主实验使用 OSWorld 2.0 的完整评测集，版本为 v2026.08.08，任务预算为 500 步。宿主、Tracker 与 Compiler 都使用 Claude Opus 4.7，没有额外训练。上下文策略比较与消融另外使用同一组 40 项任务，不能将其分数和主实验直接混排。

BrowseComp-Plus 实验使用固定的 100 题子集，预算为 60 轮，以 BM25 检索，每次最多五条结果、每条 512-token 片段，不执行全文检索。最终答案由 Qwen3-32B 按官方评分提示评判，结果不代表完整题库或实时开放网页搜索。原文第 4.1 节、附录 A.3 和 B

性能、累计处理量与费用分别统计

M 表示百万。这里的总 tokens 是跨调用累计处理量，同一段输入在后续请求中再次处理会再次计数，缓存读取也计入。因此，40.10M 不表示一次调用具有四千万 token 的上下文。

总量包含 Tracker、Compiler 等管理开销。OSWorld 中管理模块另消耗约 0.69M tokens 和 3.11 美元的标称模型费用，作者给出的 51.9% 是计入这些开销后的减少比例。费用依据论文固定费率估算，排除评测器、用户模拟器与基础设施成本，不能作为当前报价或整个系统账单。原文表 1–3、附录 B.3

对象记录怎样承接进度

下面的两个案例展示折叠前后保留的工作与待办。上方是演示文稿编辑，下方是实验报告填写，原图保留了对象、执行上下文和近期交互三者之间的关系。

图源：Yuchen Lu、Julian McAuley、Lei Zhang，原论文图 1，CC BY 4.0。查看高清案例图。

这两次变化是具体折叠案例，不是全数据集的平均节省。图中已编辑文档与待确认保存同时存在，说明对象进度和完成判定需要分别保留。原文图 1、附录 C.2

在 40 项任务的策略比较中，普通摘要的部分得分为 44.94%，按对象组织的摘要为 50.93%，完整 CarryOn 为 55.93%。后者保留的文字还少于对象组织摘要，提示表示与更新方式值得独立研究。

消融实验在保留内部运行时状态的同时，对宿主隐藏一个组件。隐藏执行上下文后部分得分降至 44.00%，隐藏载体后为 44.62%，后者还增加调用与费用。它支持两个组件在所测任务中的互补作用，不能解释成删除任意一段历史都会产生相同损失。原文表 4–5

局限与适用边界

从实验设置可见，主证据来自同一宿主模型和两个任务环境，浏览任务仅为 100 题子集。附录保留了模型配置、预算和检索方式，迁移到其他模型、工具协议或应用状态前仍需重新评估。

Grounder 的只读检查覆盖明确条件，例如文件存在和结构是否有效。文件内容满足全部业务要求、信息产品的推理是否正确、会话状态是否仍可恢复，需要其他任务检查。原文明确说明运行时检查不验证任务正确性。

成本收益依赖任务长度与缓存结构。短流程可能无法抵偿额外管理调用，本文认为应直接比较包含管理开销的总费用与延迟，避免只汇报宿主减少了多少输入。论文也未给出可普遍套用的触发阈值。

对象身份、适用范围和版本一旦描述错误，旧记录可能被错误复用。论文把来源、当前版本和使用条件纳入提交检查，本文认为跨文件移动、会话失效与并发修改仍是部署时需要单独验证的边界。原型把思考摘要标为 Agent 生成内容，与环境观察区分，这一证据来源区别也应保留。附录 A、B

可验证的启发

本文首先建议从一个可持续编辑的文档任务开始，比较普通摘要与对象记录。保持宿主、任务预算和触发条件一致，记录重新打开文件、重复检索与重复执行的次数，同时检查最终任务结果。如果调用减少却漏掉保存确认或未完成计算，就不能只按压缩比例判断成功。依据是图 1 与载体隐藏消融中的继续执行差异。

第二个建议是检查证据状态如何传递。在文件为空、容器损坏、版本改变和路径变化的受控条件下，确认请求被支持、判为矛盾或留为未知，并检查旧记录是否仍被错误安装。成功标准应包含没有把未知条件改写成已完成，而不只看流程能否继续。

第三个建议是寻找实际成本边界。选择长短不同的任务，分别统计宿主、Tracker、Compiler 的累计 tokens、缓存分类、模型费用和端到端耗时。若额外管理开销超过输入节省，或任务质量下降，应停止沿用该触发设置。这些是本文提出的验证方法，原文没有完成所有模型和场景下的对应测试。

参考资料

• arXiv 摘要与版本记录，核验于 2026-10-19。

• CarryOn v2 全文，阅读范围包括正文第 1–5 节、实现与实验附录 A–C、提示词附录 D，以及关键表格与图文。

• 作者项目页，链接来自原始论文。

• 图 1 与图 2 来自 Yuchen Lu、Julian McAuley、Lei Zhang 的原论文，按原文标明的 CC BY 4.0 许可署名引用，未修改原图。