AgentFold: Long-Horizon Web Agents with Proactive Context Management

读前先抓住结论

AgentFold 讨论的是长程网页 agent 的一个核心瓶颈：任务越长，历史越多，模型越容易被自己的上下文拖垮。ReAct 式 agent 通常把每一步观察、思考和工具调用都追加到上下文里，短任务还好，长任务就会出现上下文饱和。另一类办法是每一步总结完整历史，但这种固定总结会带来不可逆信息损失，关键证据一旦被压掉，后面很难恢复。

AgentFold 的主张是，网页 agent 不应该把上下文当作被动日志，而应该把它当作可主动塑形的认知工作区。模型每一步不只决定下一次工具调用，还要决定如何折叠已有历史。折叠可以是细粒度压缩，保留某一步的重要细节；也可以是深度合并，把一整段失败探索或已完成子任务抽象成一个结论。

论文最亮眼的数字是：AgentFold-30B-A3B 在 BrowseComp 上达到 36.2%，BrowseComp-ZH 上达到 47.3%，WideSearch 上达到 62.1%，GAIA 上达到 67.0%。它用的是 Qwen3-30B-A3B 底座，预测时只有 3B 激活参数，却能超过或匹配大得多的开源模型和部分专有 agent。作者想证明的是：长程任务的瓶颈不只是模型规模，也在于上下文管理范式。

为什么长程网页 agent 卡在上下文

网页信息检索任务天然是长程的。agent 需要提出查询、打开网页、阅读片段、比较来源、处理失败链接、修正搜索方向、整合证据并给出最终答案。每一步都可能产生有用信息，也可能产生大量噪声。如果完整保留所有历史，模型后期会面对巨大的上下文，关键信号被失败尝试、无关网页和重复观察淹没。

固定摘要看似解决了 token 问题，但它有另一种风险。长程任务中的细节常常在未来才变得重要，比如某个网页中的约束、某次工具返回的异常、某个候选答案被排除的原因。如果每一步都对完整历史做统一总结，摘要器可能会为了简洁删掉这些细节。一旦删除，后续 agent 就无法再利用它们。

AgentFold 的认知类比很有意思：人类不会把所有草稿都永远放在脑中，也不会每隔几分钟把全部经历重写成一段短摘要。更自然的做法是回看最近几步，把死胡同概括成“此路不通”，把关键发现保留为独立笔记，把已经完成的子任务合并成结论。AgentFold 把这种 retrospective consolidation 做成模型的显式动作。

这个问题和 ACE 的上下文 playbook 有亲缘关系，但 AgentFold 更聚焦单条长程网页轨迹内部的上下文折叠。ACE 维护跨任务经验，AgentFold 管理当前长程任务的历史轨迹。二者都说明：上下文不是一段静态提示，而是 agent 系统中需要被持续维护的状态。

AgentFold 的认知工作区

AgentFold 把上下文设计成动态认知工作区，主要包含四类信息：用户问题、可用工具、多尺度状态摘要和最近交互。用户问题提供最终目标，工具列表限定可执行动作，多尺度状态摘要保存长期历史，最近交互保留当前步骤的高保真细节。

多尺度状态摘要不是单一全局摘要，而是一组连续步骤块的摘要序列。某些块可能只压缩一步，用来保存关键细节；某些块可能覆盖多步，用来把完整子任务或失败路径合并成粗粒度结论。这种表示让 agent 不必在“全保留”和“全摘要”之间二选一。

最近交互的作用同样重要。长程任务需要抽象，但当前步骤附近的细节不能过早压缩。比如刚刚打开的网页、刚刚失败的工具调用、刚刚得到的候选答案，都可能直接影响下一步行动。因此 AgentFold 同时保留最新一步的高保真记录，以及更早历史的压缩摘要。

这个结构的工程意义是，它把上下文窗口变成了可维护数据结构。ReAct 的历史更像追加日志，AgentFold 的历史更像分层笔记。日志适合审计，但不适合每一步都读；分层笔记更适合模型在长程任务中快速定位关键状态。

四块响应与 folding 操作

AgentFold 的响应不是一个普通自然语言回答，也不只是一个工具调用。论文定义每步响应为四元组：thinking、folding、explanation 和 action。thinking 用于分析当前上下文和候选策略；folding 指令说明要折叠哪段历史、替换成什么摘要；explanation 解释下一步行动理由；action 则发起工具调用。

folding 指令是 AgentFold 和普通 tool-use agent 的分水岭。普通 agent 最多会想“下一步搜什么”，AgentFold 还要想“刚才这几步应该如何进入未来上下文”。如果某一步发现了关键事实，它可以做 granular condensation，把这一步折成保真摘要；如果多步探索证明某个方向是死胡同，它可以做 deep consolidation，把整段历史替换成一句结论。

1Require: question $Q$, tools $T$, initial summaries $S$, latest interaction $I$2for step $t = 1...T_{max}$:3  $C_t \leftarrow (Q, T, S_{t-2}, I_{t-1})$4  $(th_t, f_t, e_t, a_t) \leftarrow AgentFold(C_t)$5  $S_{t-1} \leftarrow apply\_folding(S_{t-2}, I_{t-1}, f_t)$6  $o_t \leftarrow execute\_tool(a_t)$7  $I_t \leftarrow (e_t, a_t, o_t)$8return final answer

这使得行动和记忆管理形成闭环。模型不是等任务结束后再总结，而是在探索过程中不断修剪自己的认知工作区。折叠做得好，agent 后续会看到更干净的状态；折叠做错，可能丢掉证据或保留噪声。因此论文把 folding 作为可训练输出，而不是简单启发式。

训练：把折叠能力蒸馏进模型

作者指出，训练 AgentFold 需要一种原本不存在的数据：不仅要展示网页 agent 如何行动，还要展示它如何在行动时管理上下文。普通轨迹通常只有观察、思考、动作和答案，没有高质量 folding 指令。因此作者用一系列生成和拒绝采样机制构造交互对，再对开源模型做监督微调。

训练样本可以理解为 $(C_t, R_t^*)$：给定结构化上下文，目标响应不仅包含下一步工具调用，还包含理想的折叠指令和解释。这个设计把昂贵的 generate-and-filter 策略蒸馏到模型参数中，使模型推理时不需要每一步再调用外部复杂程序来决定如何折叠。

论文强调，仅靠提示工程很难让先进模型稳定地产生准确的多部分响应。原因不难理解：folding 需要同时判断任务语义、历史重要性、未来可用性和摘要尺度。它不是一句“请总结历史”能可靠完成的能力，所以作者选择 SFT 让模型直接学习这种结构化输出习惯。

这也是 AgentFold 和许多上下文压缩方法的差异。很多方法把压缩当作外部模块或固定策略，而 AgentFold 把压缩决策放进 agent 本身，让它在行动中学习何时压、压什么、压到多粗。这种“自我管理上下文”的能力才是论文所谓 proactive context management 的核心。

实验结果与上下文动态

主结果表比较 AgentFold-30B-A3B 和多个开源、闭源 agent。AgentFold 在 BrowseComp 上达到 36.2%，超过 671B 规模 DeepSeek-V3.1 的 30.0%；在 BrowseComp-ZH 上达到 47.3%；在 WideSearch 上达到 62.1%，超过多个专有 agent；在 GAIA 文本子集上达到 67.0%。这些结果说明主动上下文管理可以让较小模型在长程任务上获得非常强的竞争力。

上下文动态分析更能说明方法为什么有效。作者在 BrowseComp 上分析二百条轨迹，发现 AgentFold 的平均上下文长度从约三千五百 token 增长到约七千 token，不到翻倍。相比之下，ReAct 式追加历史会随着轮数不断线性膨胀。AgentFold 的 fold 操作让历史保持结构化和可读。

块数量同样重要。即便 token 不多，如果上下文被切成大量碎片，模型仍然难以理解任务状态。AgentFold 的深度合并可以把多步失败探索或完成子任务变成一个摘要块，因此块数量也不会像 ReAct 那样每轮线性增加。这种结构简化让模型更容易维持长期计划。

论文还比较了 AgentFold 和 ReAct 在第一百轮时的上下文差异。AgentFold 平均比 ReAct 小超过 84k token，减少约 92%，估计每个推理实例能节省接近 7GB 显存。这说明 folding 不只是提高准确率，也直接影响长程 agent 的服务成本和可扩展性。

当最大交互轮数提高到 256 时，AgentFold 仍能持续受益，而更大的 GLM-4.5 baseline 更早饱和。作者进一步探索 500 轮上下文动态，说明主动折叠让 agent 有机会处理真正极长的问题。这里的关键信息是：能否长时间工作，不只取决于窗口长度，还取决于历史是否被整理成可继续推理的状态。

案例、局限与工程复用

案例研究展示 AgentFold 如何处理一串失败尝试。模型在第 6 到第 16 步沿某个方向探索但没有成功，于是执行 deep consolidation，把这 11 步失败压缩成一个结论，并决定切换搜索方向。这个案例说明 folding 不是机械压缩，而是带有任务语义的轨迹管理。

AgentFold 的局限也很清楚。第一，论文主要用 SFT 展示范式潜力，没有深入优化 folding 策略。作者自己也说下一步是用强化学习，让 agent 直接以任务成功为目标发现更优 folding policy。第二，folding 本身可能犯错：过早合并会丢掉细节，过晚合并会导致上下文膨胀，错误摘要会误导后续推理。

第三，AgentFold 的训练数据构造成本不低。高质量折叠轨迹需要生成、筛选和监督信号，不是随便拿普通 ReAct 日志就能训练出来。对于工程团队来说，一个更现实的起点可能是先用规则或外部 summarizer 模拟 folding，再逐步收集数据训练模型内生折叠能力。

从复用角度看，AgentFold 适合所有需要长程探索的 agent：网页检索、科研调研、代码仓库探索、复杂客服流程、企业知识库排障。只要任务会产生长历史，而且历史中既有关键证据又有大量噪声，就可以考虑引入多尺度摘要和最近交互的结构。

最小可用实现不一定要训练新模型。可以先让现有 agent 输出一个额外字段：本轮之后应该压缩哪些历史、保留哪些结论。再由外部程序执行 fold，维护 $S_t$ 和 $I_t$。等收集到足够多高质量轨迹后，再考虑像论文一样用 SFT 蒸馏到模型里。

AgentFold 的核心启发是：长程 agent 的能力不仅来自会不会调用工具，也来自会不会管理自己的工作记忆。把历史原样追加进去很容易，把历史整理成对未来有用的多尺度状态才难。论文把这个能力变成模型输出和训练目标，因此为长程 agent 提供了一个很具体的系统方向。

如何把 AgentFold 思想迁移到自己的系统

如果要在真实项目里借鉴 AgentFold，第一步是把“历史”拆成两层。最近一两步保留完整细节，作为短期工作记忆；更早的步骤进入多尺度摘要，作为长期任务状态。这样做的好处是，模型既不会丢掉当前网页或工具返回的细节，也不会被几十轮之前的无关失败尝试拖慢。

第二步是定义折叠触发条件。不是每一步都必须压缩，也不是所有步骤都适合合并。遇到关键证据时，应做细粒度压缩，保留来源、结论和适用条件；遇到连续失败路径时，应做深度合并，记录“尝试过什么、为什么失败、下一步不要再重复什么”。如果折叠策略不能区分这两类情况，就很容易要么丢证据，要么留噪声。

第三步是让折叠结果可审计。每个压缩块最好保存覆盖的步骤范围、摘要文本、生成时间和触发原因。这样当最终答案出错时，开发者可以回看某个 block 是否错误地丢掉了信息。AgentFold 的公式 $s_{x,y}$ 看似简单，但它提醒我们：摘要不是散文，而是带有历史范围的状态对象。

第四步是把工具调用结果纳入折叠判断。网页 agent 的失败往往不是推理失败，而是搜索词不合适、页面无关、工具返回空结果、某个来源互相矛盾。折叠摘要如果只写“进行了搜索”，价值很低；更好的摘要应写“这个方向为什么不再值得继续”或“这个来源确认了哪个约束”。这会直接影响后续重新规划。

第五步是区分训练期和推理期。论文通过 Fold-Generator 和拒绝采样构造高质量折叠轨迹，再用 SFT 蒸馏进模型。工程上可以先不用训练新模型，而是外接一个 folding 模块维护上下文；当积累了足够的成功轨迹，再考虑微调模型，让它内生地产生 thinking、folding、explanation 和 action 四块输出。

第六步是为错误折叠准备回退。任何自动摘要都会犯错，长程任务中一次错误折叠可能影响后续几十步。实际系统可以保留原始日志作为审计层，同时只把折叠后的状态送入模型。这样推理时享受短上下文，排查时仍能回到完整历史。

第七步是把 AgentFold 和检索结合。多尺度摘要可以作为模型输入，但完整历史也可以放进外部存储。当前任务需要细节时，系统可以根据摘要块的范围回查原始网页或工具返回。这样既保持上下文简洁，又避免摘要成为唯一信息来源。

AgentFold 最值得学习的不是某个具体 prompt，而是它把上下文管理变成 agent 的核心动作。长程 agent 要想稳定工作，必须学会管理自己的注意力和记忆：哪些内容原样保留，哪些内容压缩，哪些失败路径应该归档，哪些证据必须在最后回答前重新检查。这些问题解决得越好，模型规模带来的压力就越小。

从产品视角看，AgentFold 适合那些“任务过程比答案更长”的场景。比如市场调研、竞品分析、科研搜索、法律资料检索、复杂代码排查和企业知识库问答。这些任务中，agent 经常会走弯路；如果弯路不被整理，它们会污染上下文；如果弯路被正确折叠，它们反而成为后续规划的依据。

最后要注意，AgentFold 并不意味着可以随意缩短上下文。它强调的是主动、语义化、多尺度的折叠。粗暴截断历史、固定窗口摘要、每步重写全文，都不等于 AgentFold。真正的 AgentFold 思路要求模型理解任务进展，并根据未来是否还需要这些信息来决定折叠尺度。

实验数字背后的判断

AgentFold 的实验读法不能只看主表最高分。第一层要看任务类型是否足够长程。BrowseComp 和中文版本强调难找信息定位，WideSearch 强调多方面信息综合，GAIA 则偏通用 agent 能力。它们共同要求模型不断搜索、筛选、修正方向和整合证据，因此很适合检验上下文管理，而不是只检验单次问答能力。

第二层要看模型规模。AgentFold 使用的是三百亿总参数、预测时三十亿激活参数的模型，却能超过更大规模开源模型。这说明论文主张不是“模型越大越好”，而是“长程任务中，模型如何管理历史会显著影响可用能力”。如果一个大模型被无序历史拖垮，小模型配合更好的上下文结构也可能反超。

第三层要看上下文动态。主表证明任务效果，token 曲线和块数量曲线证明机制确实生效。如果只提升准确率但上下文仍然线性增长，方法很可能无法扩展到更长任务。AgentFold 在一百轮后仍维持约七千 token，并且块数量也保持次线性增长，说明它不是靠扩大窗口硬扛，而是在整理历史。

第四层要看案例。案例里的关键不是“模型总结了一段话”，而是模型判断一串失败尝试已经构成死胡同，并把它折叠成可以指导后续规划的结论。这种语义判断比普通摘要更难，因为它要求模型理解失败路径和任务目标之间的关系。对长程网页 agent 来说，知道哪些方向不该继续，本身就是重要知识。

如果要复现实验，最容易出错的是评估预算。工具调用轮数、最大上下文长度、是否强制终止、是否允许回查完整历史，都会影响结果。论文把最大工具调用数设为一百，并额外测试更高轮数，是为了展示 AgentFold 在长程预算下的优势。复现者需要保持这些设置清楚，否则很难判断提升来自方法还是来自更宽松的预算。

另一个容易出错的是基线公平性。ReAct 的上下文会不断增长，如果直接给它无限窗口，成本会爆炸；如果截断它，又可能丢历史。AgentFold 的优势正是在这个矛盾中出现的。比较时既要看成功率，也要看上下文长度、显存、延迟和轮数扩展。否则只看最终分数，会低估上下文管理带来的系统价值。

论文没有把强化学习作为当前主要方法，这一点也值得注意。作者用监督微调展示 folding 范式已经有效，但承认未来可以用强化学习直接优化折叠策略。也就是说，当前结果更像证明“让模型学会主动折叠是有用的”，而不是证明“当前折叠策略已经最优”。这给后续研究留下了很大空间。

在工程系统里，AgentFold 可以拆成两个阶段上线。第一阶段，让现有模型继续负责行动，由外部程序或额外模型负责折叠历史。这样可以快速验证多尺度摘要是否降低成本、提高稳定性。第二阶段，收集足够多人工或自动筛选过的折叠轨迹，再训练模型直接输出四块响应。这样风险更低，也更容易定位问题。

折叠质量可以用几个指标监控。一个是摘要块命中率：后续推理是否真的引用或依赖某个压缩块。一个是回查率：模型是否频繁需要回到原始历史，若回查太多，说明摘要不够有用。一个是错误归因率：最终失败是否来自某个错误折叠。还有一个是上下文增长率：任务变长时 token 和块数量是否仍然可控。

AgentFold 也提醒我们，长上下文窗口不是万能解。窗口变大以后，系统仍然要决定哪些信息值得注意。把几十万 token 原样塞给模型，不等于模型能稳定利用它们。主动折叠的价值在于让模型看到经过整理的任务状态，而不是把注意力浪费在已经失败、重复或无关的轨迹上。

从人机协作角度看，AgentFold 的压缩块也可以成为用户可读的任务进度。用户不一定想看每次网页点击和工具返回，但会想知道 agent 已经排除了哪些方向、确认了哪些事实、当前计划是什么。多尺度摘要天然适合做这种进度解释，让长程 agent 更透明。

对于中文网页 agent，AgentFold 的 BrowseComp-ZH 结果尤其有参考价值。中文长程检索常遇到来源质量不一、页面结构复杂、表达变体多等问题。如果 agent 不能整理搜索历史，就容易重复搜索同一线索，或忘记已经排除的候选。主动折叠可以把这些过程性知识变成后续可用状态。

对于代码和数据分析 agent，AgentFold 思路也能迁移。一次复杂排障可能包含几十次命令、错误日志和假设验证。把所有终端输出原样塞回模型会很快膨胀；每次粗暴总结又可能丢掉某个错误码。更好的做法是保留最近命令的完整输出，把已经验证过的假设折叠成状态摘要，把失败路径折叠成“不要再尝试”的结论。

从安全角度看，自动折叠也需要边界。如果压缩块错误地把“不确定”写成“已确认”，后续 agent 可能建立在错误事实上继续行动。因此高风险系统应让摘要保留不确定性标记，例如“尚未验证”“来源冲突”“需要二次确认”。折叠不是把历史变得更自信，而是把历史变得更可用。

最后，AgentFold 的价值可以概括为一种长期工作记忆设计。它把 agent 的上下文从线性聊天记录，改造成由目标、工具、长期摘要和最近交互组成的工作区；把 agent 的输出从单一动作，改造成同时包含思考、折叠、解释和行动的结构化响应。这个设计让长程 agent 有机会真正持续工作，而不是在自己的历史里逐渐迷路。

设计取舍与常见误解

第一个常见误解是把 AgentFold 理解成普通摘要。普通摘要通常追求把历史变短，而 AgentFold 追求的是让历史在未来可用。二者的差异很大。一个好的折叠块不仅要短，还要说明这一段历史对后续任务意味着什么。比如一串失败网页搜索，不应该只被总结成“搜索了若干网页”，而应该总结成“沿某关键词方向没有找到满足条件的来源，下一步应更换实体别名或数据源”。这样的摘要才会改变后续行动。

第二个误解是认为 AgentFold 只是节省 token。节省 token 当然重要，但论文更强调推理质量。上下文太长会带来两个问题：成本上升和注意力污染。即使模型窗口足够大，长历史中的噪声也会干扰判断。AgentFold 把历史整理成多尺度状态摘要，实际上是在降低认知负担，让模型更容易看到任务当前处于什么阶段、哪些方向已经排除、哪些证据仍需验证。

第三个误解是认为折叠越频繁越好。过度折叠会带来信息损失，尤其是在证据还没完全理解时。AgentFold 的关键不在于每步都压缩，而在于让模型根据任务语义决定折叠尺度。刚得到的重要网页片段可能应该暂时留在最近交互中；已经反复验证失败的搜索方向则适合深度合并。折叠频率应由任务状态决定，而不是由固定步数决定。

第四个误解是把 deep consolidation 看作删除失败历史。实际上，它不是简单删除，而是把失败转化为可用结论。长程任务里，失败探索很有价值，因为它告诉 agent 哪些方向不再值得尝试。若直接删除失败路径，模型可能重复犯错；若完整保留失败路径，又会污染上下文。深度合并的目标是在二者之间取平衡：保留“这个方向已失败及其原因”，删去无用的中间冗余。

第五个误解是认为 Latest Interaction 不重要。多尺度摘要提供长期记忆，但最近一步的原始细节往往决定下一步动作。比如刚刚打开的网页标题、表格字段、工具报错、页面跳转结果，都可能需要精确读取。AgentFold 保留最近交互，就是为了防止关键短期细节过早进入摘要而被模糊化。

第六个误解是忽略工具 schema。论文把工具列表放进上下文结构，并不是形式主义。网页 agent 的行动能力由工具决定，工具参数和返回格式会影响下一步计划。一个折叠摘要如果不记录和工具相关的失败原因，例如参数错误、搜索结果为空、页面无法访问，就很难帮助后续调用。上下文管理必须和工具使用绑定，而不是只管理自然语言推理。

第七个误解是只看最终答案，不看轨迹。AgentFold 的贡献发生在轨迹内部：它怎样压缩、何时合并、如何重新规划，都需要通过中间状态观察。只用最终准确率评价，会看不到方法为何有效。论文因此展示 token 曲线、块数量曲线和案例图，这些材料证明 AgentFold 真的改变了长程推理过程。

第八个误解是把训练看作普通指令微调。AgentFold 的 SFT 目标包含结构化响应，尤其是 folding 指令。模型不只是学习“回答网页问题”，而是学习在每一步产生可解析的上下文维护动作。这类数据比普通问答数据更难构造，因为它要求标注或生成器知道哪些历史应该保留，哪些应该合并，哪些应该舍弃。

从系统设计看，AgentFold 有一个很明确的状态转移。当前状态包括问题、工具、多尺度摘要和最近交互；模型输出折叠指令和工具调用；系统先应用折叠更新摘要，再执行工具得到新观察；新观察和解释形成下一轮最近交互。这个转移让 agent 的内部记忆随任务推进而变化，也让开发者有机会在每一步检查状态是否合理。

这种状态转移的难点在于一致性。如果摘要块之间互相矛盾，或者同一事实在不同尺度上有不同说法，模型会困惑。因此实际实现时，可以给摘要块增加来源范围、置信度和状态标签。例如“已确认事实”“失败方向”“待验证假设”“临时线索”。这样模型和系统都能更清楚地使用这些块。

另一个设计取舍是摘要粒度。粒度太细，块数量仍然会膨胀；粒度太粗，关键细节容易丢。论文中的 granular condensation 和 deep consolidation 正好对应这两个端点之间的动态选择。好的系统不应固定一种粒度，而应允许不同历史片段以不同尺度存在。

在多轮网页搜索中，信息常常有时效和来源质量差异。AgentFold 的论文没有深入展开来源可信度，但工程落地时应把来源质量写进摘要。例如来自官方文档、新闻报道、论坛帖子和模型猜测的信息，置信度应该不同。如果摘要只保留结论不保留来源，后续模型可能把弱证据当成强证据。

AgentFold 对中文场景也有一个隐含启发：中文搜索常需要多种实体别名、简称、英文名和翻译名之间切换。长程 agent 如果不记录哪些别名已经试过，容易重复搜索。折叠块可以把这些尝试整理成“已尝试关键词集合”和“仍需尝试方向”，帮助 agent 更系统地扩展搜索空间。

对开发者来说，最小实现可以很轻量。维护一个列表作为多尺度摘要，每一轮让模型输出一个 JSON 形式的折叠指令，包含范围、摘要、原因和类型。系统验证范围合法后更新列表，再把最新工具结果保留为最近交互。即使不训练模型，这种结构也比线性追加所有历史更容易控制。

更高级的实现可以加入自动评估。每当最终答案正确时，可以回看哪些摘要块被引用或贡献较大；每当答案错误时，可以检查是否存在错误折叠。长期积累后，系统甚至可以学习哪些类型的历史适合细粒度压缩，哪些适合深度合并。这正是论文未来希望用强化学习探索的方向。

AgentFold 也不是所有 agent 的答案。如果任务只有两三步，折叠机制可能增加复杂度；如果任务必须保留完整法律或医疗证据，自动摘要可能需要严格审计；如果工具反馈不可靠，折叠出的结论也可能错误。它最适合的是长程、探索性、可容忍过程压缩、且失败路径很多的信息任务。

最终，AgentFold 把长程 agent 的问题从“窗口够不够大”转成“记忆结构是否合适”。窗口扩大只能推迟饱和，不能自动判断什么重要。主动上下文折叠则试图让 agent 学会管理自己的历史，把任务过程变成可持续的工作记忆。这是它和普通上下文压缩最大的区别。

把 AgentFold 放进站内其他 agent 论文脉络里看，会更容易理解它的位置。AFlow 关心的是如何自动搜索和优化 agentic workflow，让系统找到更好的算子组合和执行流程；ACE 关心的是跨任务上下文如何演化成 playbook，让经验持续积累；AgentFold 关心的是单条长程网页轨迹内部如何折叠历史，让当前任务不会被自己的过程噪声拖垮。三者都在处理反馈和状态，只是状态对象不同。

如果说 AFlow 优化的是“怎么做任务的程序结构”，ACE 优化的是“跨任务保留下来的经验手册”，那么 AgentFold 优化的是“当前任务进行到一半时，模型眼前应该看到什么”。这个问题看似更局部，但对网页 agent 很关键，因为网页搜索任务的失败常常不是缺少最终知识，而是在中途被错误线索、过长历史和重复探索带偏。

AgentFold 还可以和传统 memory 方法对比。很多 memory 系统会把过去事件存入向量库，之后按相似度检索。AgentFold 并不主要解决跨会话检索，而是在同一任务轨迹中维护连续历史。它的摘要块带有时间范围和任务语义，更像当前工作记忆的分层压缩，而不是长期经验库。这种区别决定了它适合长程单任务推理。

和 RAG 相比，AgentFold 也不是外部知识检索方法。RAG 负责把外部文档拿进来，AgentFold 负责管理 agent 已经经历过的搜索过程。一个强网页 agent 可能同时需要二者：RAG 或搜索工具提供新材料，AgentFold 负责把已读材料、失败路径和中间结论整理成可继续推理的上下文。

所以，这篇论文的最大启发是把“上下文”看成运行时状态，而不是输入字符串。状态需要被更新、压缩、恢复、解释和验证。只要 agent 任务足够长，这个状态管理问题就无法靠扩大窗口彻底解决。AgentFold 给出的答案是让模型自己学习状态管理动作，这也是它比固定摘要策略更进一步的地方。

对未来研究来说，一个很自然的问题是：folding policy 是否可以和任务成功率直接联合优化。监督微调能模仿生成器筛出的好轨迹，但强化学习可以让模型探索非显然折叠策略。例如有些失败路径暂时看似无用，后面可能成为排除条件；有些证据现在很重要，几步后可以合并。如何学习这种时间相关的价值判断，是 AgentFold 后续最有意思的方向。

落到实践里，最稳的原则是先保守再自动。早期系统可以少折叠、保留更多原始证据，并把每次折叠展示给开发者检查；等确认哪些折叠类型稳定有益，再提高自动化程度。这样既能获得长程上下文管理的收益，也能避免模型过早把重要信息压成错误结论。AgentFold 给出的不是一个必须一次到位的方案，而是一条从结构化历史、可审计摘要到可学习记忆管理的渐进路线。

这也是它对 agent 工程最朴素的提醒：长程能力不是把窗口撑大就结束了，还要让系统知道如何整理自己的过去。

只有过去被整理成可用状态，未来的每一步行动才不会被历史噪声反复拖回原点。

这正是长程智能体真正需要补上的记忆工程能力。