AgentSwing：长时Web Agent的上下文管理，为什么"一条路走到黑"行不通
你有没有碰到过这种情况——让AI Agent在网上搜一个冷门信息，刚开始还挺靠谱，搜着搜着就开始重复访问同一个页面，或者对着一条已经证明走不通的线索死磕不放？
这不是模型变笨了，是上下文炸了。
当Agent在长时搜索任务中积累了上百轮交互历史，有限的上下文窗口会被大量冗余、过时、甚至误导性的信息占满。模型看到的不再是有用的线索，而是一堆噪音。这时候，怎么管理上下文就成了决定Agent能不能完成长程任务的关键。
阿里通义实验室这篇AgentSwing，从一个很漂亮的概率视角重新审视了这个问题，然后给出了一个"并行分支+前瞻路由"的方案。实测效果确实能打——用不到静态方法1/3的交互轮次，就能匹配甚至超越它们的性能。
核心摘要
长时Web Agent面临一个根本矛盾：保留全部历史会因"上下文腐烂"导致精度崩塌，丢弃历史又会让搜索效率断崖下跌。现有方法都是选一种策略从头用到尾，但不同阶段的最优策略其实不一样。AgentSwing的核心思路是在上下文超限时，并行展开多种管理策略（保留最近N轮、摘要压缩、全部丢弃），让每个分支继续跑几步看效果，再选最有希望的走下去。这个"多试几步再选"的前瞻路由，使得Agent在不同状态之间自适应切换，比任何单一路径策略都更优。在BrowseComp等基准上，AgentSwing把开源模型推到了接近甚至超越闭源专有模型的水准。
论文信息
- 标题：AgentSwing: Adaptive Parallel Context Management Routing for Long-Horizon Web Agents
- 作者：Zhaopeng Feng, Liangcai Su, Zhen Zhang, Xinyu Wang, Xiaotian Zhang, Xiaobin Wang, Runnan Fang, Qi Zhang, Baixuan Li, Shihao Cai, Rui Ye, Hui Chen, Jiang Yong, Joey Tianyi Zhou, Chenxiong Qian, Pengjun Xie, Bryan Hooi, Zuozhu Liu, Jingren Zhou
- 机构：通义实验室，阿里巴巴集团
- 链接：arxiv.org/abs/2603.27490
问题动机：为什么静态策略一定不够好
先说一个很多人可能没意识到的现象——上下文不是越多越好。
你可能觉得，给Agent更大的上下文窗口，它就能记住更多信息，做判断更准确。但AgentSwing的实验发现恰恰相反：随着上下文预算增大，Agent的对齐终端精度（在同样完成的任务集上算正确率）反而一致下降。
图2：BrowseComp上Discard-All在不同上下文预算下的表现。注意对齐终端精度随上下文增大而下降——这就是"上下文腐烂"
道理很简单，历史信息越多，模型越容易被早期错误假设带偏。这个现象在Tongyi-DR-30B-A3B和GPT-OSS-120B上都很明显。作者把这叫做"context rot"——上下文腐烂。信息放太久就馊了。
这就引出了一个根本性的权衡：
- 保留全部历史：搜索效率高（不丢信息，不容易卡住），但终端精度低（被噪音干扰）
- 丢弃全部历史：终端精度高（干净上下文做判断更准），但搜索效率低（丢掉了可能有用的线索，需要从头再来）
现有的上下文管理方法——Keep-Last-N、Summary、Discard-All——说到底就是在这个效率-精度权衡面上各选了一个点。但问题在于：你在搜索过程中不同阶段，最优策略是不一样的。有时候你积累了大量误导信息需要全部丢弃，有时候你恰恰需要保留最近几轮新发现的线索。
你想想看，一个人在网上搜索的时候，也是这样——有时候需要清空思路从头来，有时候需要在最近的发现上继续深挖。没人会从头到尾只用一种策略。
概率框架：把问题拆开看
AgentSwing的第一个贡献，是给这个问题建立了一个干净的数学框架。
对于任务 \(\tau\)，在策略 \(\pi\) 下，任务成功的概率可以分解为两个因子：
- 搜索效率 \(\eta^\pi\) = P(在资源耗尽前到达停止点)——你到底能不能搜到足够信息
- 终端精度 \(\rho^\pi\) = P(答案正确 | 已经到达停止点)——搜到了信息后能不能判断对
这个分解看似简单，其实挺关键的。之前大家看端到端的Pass@1，分不清一个方法到底是"搜得更快"还是"判断更准"。把两个维度拆开，才能看清楚每种策略到底在干什么。
图3：不同上下文管理策略在效率-精度平面上的分布。Baseline高效率低精度，Discard-All低效率高精度，AgentSwing移动到更有利的区域
从图3可以清楚看到：
- Baseline（不管理上下文）：搜索效率最高，但终端精度最低
- Discard-All：终端精度最高，但搜索效率最低
- Keep-Last-N / Summary：介于两者之间
- 它们在效率-精度平面上形成了一条经验权衡前沿
有意思的是，Keep-Last-N和Summary虽然处于中间位置，但Pass@1并没有明显优于两个极端——因为它们在效率和精度上的"折中"并没有真正创造额外价值。
这就引出了AgentSwing的核心问题：能不能不沿着这条静态权衡前沿走，而是跳出这个面，到更有利的区域去？
方法核心：并行分支 + 前瞻路由
AgentSwing的架构如下图所示：
图4：AgentSwing架构。上下文超过阈值时触发，同时展开多个候选策略，每个分支继续K轮交互，然后路由选择最有希望的分支
两个核心组件：
并行上下文管理
当累积上下文长度超过模型最大上下文长度的预设比例 \(r\) 时触发。同时对当前上下文应用三种候选策略：
| 策略 | 做了什么 | 特点 |
|---|---|---|
| Keep-Last-N | 只保留最近N轮交互 | 保留新线索，丢弃旧干扰 |
| Summary | 将轨迹压缩为摘要文本 | 压缩冗余，但摘要可能丢失细节 |
| Discard-All | 丢弃全部历史，只保留原始问题 | 最激进的重置，干净但可能丢关键线索 |
三种策略各有优劣，关键是不预先决定用哪个，而是都试试看。
前瞻路由
这是AgentSwing最精巧的设计。并行管理之后，每个分支不是立即被选或被丢弃，而是继续与环境交互 \(K\) 个额外轮次。然后再把候选延续连同原始上下文交给模型，让它判断哪个分支最靠谱。
这个设计的直觉很好——光看压缩后的上下文本身，你很难判断哪个策略更好。但当每个分支都往前走了几步，看到了真实的环境反馈，选择就有据可依了。
消融实验也证实了这一点（Table 3）：
| 路由机制 | GPT-OSS-120B | Tongyi-DR-30B-A3B |
|---|---|---|
| 随机选择 | 51.0 | 56.5 |
| 无前瞻 | 50.0 | 57.0 |
| 前瞻 K=1 | 52.5 | 58.0 |
| 前瞻 K=3 | 60.0 | 60.5 |
| 前瞻 K=5 | 55.0 | 59.0 |
说实话，看到这个数据的时候我愣了一下——从K=1到K=3，GPT-OSS-120B直接从52.5跳到60.0，涨了7.5个点。前瞻3步的效果远超随机选择和无前瞻版本，说明"多走几步看效果"这个思路确实work。
但K=5反而下降，作者解释是可能超出模型最大长度约束。这个解释我觉得还可以，但更深层的原因可能是：走太多步之后，分支之间差异被放大，模型反而不太好判断哪个"更好"——因为走了5步的分支可能已经偏移太多了。K=3可能恰好是"有足够信号但不过度偏移"的甜点。
实验结果：开源模型追上闭源
主实验结果如下（Table 1）：
| 模型 / 方法 | BrowseComp | BrowseComp-ZH | HLE |
|---|---|---|---|
| 闭源模型参考 | |||
| Claude-4.5-Opus（无CM） | 37.0‡ | 62.4 | 43.4‡ |
| Gemini-3.0-Pro（无CM） | 37.8‡ | 66.8 | 45.8‡ |
| GPT-5.1 High（无CM） | 50.8‡ | – | 42.7‡ |
| OpenAI DeepResearch | 51.5‡ | 42.9 | 26.6‡ |
| MiroThinker-v1.5-30B-A3B | 56.1‡ | 66.8 | 31.0‡ |
| GPT-OSS-120B | |||
| 基线（无CM） | 39.5 | 28.4 | 33.2 |
| Discard-All | 50.5 | 31.5 | 34.2 |
| Keep-Last-N | 52.5 | 33.6 | 34.1 |
| Summary | 48.0 | 30.8 | 34.4 |
| AgentSwing | 60.0 | 38.0 | 35.1 |
| DeepSeek-v3.2 | |||
| 基线（无CM） | 43.5 | 61.6 | 40.2 |
| Discard-All | 58.0 | 70.2 | 42.0 |
| Keep-Last-N | 52.0 | 69.9 | 39.6 |
| Summary | 48.5 | 69.2 | 43.5 |
| AgentSwing | 62.5 | 71.3 | 44.4 |
| Tongyi-DR-30B-A3B | |||
| 基线（无CM） | 48.0 | 47.1 | 31.7 |
| Discard-All | 58.0 | 53.9 | 32.7 |
| Keep-Last-N | 53.0 | 50.1 | 32.2 |
| Summary | 55.0 | 49.1 | 32.0 |
| AgentSwing | 60.5 | 56.7 | 33.1 |
几个值得关注的点：
DeepSeek-v3.2 + AgentSwing = 71.3% BrowseComp-ZH，直接超越了Claude-4.5-Opus（62.4%）和Gemini-3.0-Pro（66.8%）。一个开源模型靠上下文管理策略就追上了闭源大模型，这个结果还是很能打的。
AgentSwing在所有模型和所有基准上都是最优，这不是偶然。而且 BrowseComp 上 GPT-OSS-120B 从基线39.5到AgentSwing 60.0，涨了超过20个点——这已经不是微调级别的提升了，是质变。
不过坦率的讲，HLE上的提升相对有限。DeepSeek-v3.2从43.5到44.4只涨了0.9，Tongyi从32.0到33.1涨了1.1。HLE主要考学术推理，搜索策略的空间本身就小一些，上下文管理的收益也就没那么大。
对齐困难案例分析：效率与精度的真实博弈
Table 2做了一个很有意思的分析——只看所有策略都触发了上下文管理的对齐任务集，排除掉"根本没触发上下文管理"的简单案例：
| 模型 | 策略 | \(\eta\)(%) | \(\rho\)(%) | Pass@1(%) | 平均轮次 |
|---|---|---|---|---|---|
| GPT-OSS-120B | Discard-All | 41.8 | 68.6 | 28.7 | 297.2 |
| Keep-Last-N | 74.6 | 47.3 | 35.2 | 205.4 | |
| AgentSwing | 73.8 | 56.7 | 41.8 | 190.3 | |
| Tongyi-DR-30B-A3B | Discard-All | 24.4 | 81.8 | 20.0 | 340.8 |
| Keep-Last-N | 93.3 | 21.4 | 20.0 | 153.0 | |
| AgentSwing | 75.6 | 41.2 | 31.1 | 203.6 |
这张表把之前说的效率-精度权衡看得更清楚了。拿Tongyi来说，Keep-Last-N搜索效率93.3%但精度只有21.4%，Discard-All精度81.8%但效率只有24.4%——两个极端在Pass@1上居然打平了，都是20%。
而AgentSwing在效率75.6%和精度41.2%的中间位置，Pass@1直接干到了31.1%，比两个极端高了超过11个点。这不是简单的折中，是真的在效率-精度空间里找到了一个更优的点。
更关键的是平均轮次——AgentSwing的190-203轮，远低于Discard-All的297-340轮，接近Keep-Last-N的153-205轮。用更少的交互轮次拿到更高的正确率，这就是"3倍效率"的来源。
案例研究：路由选择的直觉
论文给了两个案例，非常直观地展示了前瞻路由的价值。
"Mando"案例（DeepSeek-v3.2）：第23轮触发上下文管理时，历史里混着错误假设（"Nipsey Hussle"、"Lil Durk"）和新出现的局部线索（"$tupid Young"）。三个分支走了不同方向：
- Discard-All：全扔了，从头搜索，等于前功尽弃
- Summary：摘要保留了占主导的错误假设"Lil Durk"，误导了后续搜索
- Keep-Last-N：保留了最近的"$tupid Young"线索链，最终验证了说唱者身份
路由器选了Keep-Last-N，然后Agent验证了剩余约束，找到了答案"Mando"。
这个案例特别说明问题——如果用静态策略，Summary会保留错误主导假设，Discard-All会丢弃关键新线索，只有Keep-Last-N恰好是对的。但换个任务，可能Keep-Last-N就不是最优的了。你需要的是根据当前状态做判断，而不是预先指定一个策略。
"live-crickets"案例（GPT-OSS-120B）：轨迹里充满了失败的PDF提取记录，这种情况下保留历史只会继续让模型重试同样的错误路径。路由器正确选择了Discard-All，重置后Agent通过替代访问路径成功找到了答案。
交互预算的扩展性
图5：不同最大交互轮次下各策略在BrowseComp上的性能
图5揭示了一个关键发现：在交互轮次预算有限的时候，所有上下文管理方法的增益都很小。但预算一旦充足，AgentSwing的优势就非常明显——它总能在更少的轮次下达到更高的性能。
这个发现其实挺有工程指导意义的：如果你的任务预算只有50轮交互，上下文管理帮不了太多忙。但如果预算能到200轮以上，AgentSwing就是明显更优的选择。
一些批判性思考
这篇论文思路清晰、实验扎实，但也有几个我觉得值得讨论的地方：
路由器的天花板。目前路由选择是由Agent模型自己做的——把多个候选分支放在一起，让模型判断哪个最合理。这方便是方便（不需要额外训练路由器），但模型自身的判断能力就是路由的天花板。论文在局限性里也承认了这一点。一个更强的专用路由器，或者用验证器来做分支评估，可能会进一步提升效果。
计算开销。并行分支 + 前瞻K步，意味着每次触发上下文管理时，需要跑3个分支 × K步的前瞻交互。虽然论文论证了AgentSwing的总token开销并不显著高于静态方法（因为AgentSwing通常用更少的轮次就完成了任务），但在触发时刻的瞬时计算量确实是3倍。对于延迟敏感的应用场景，这可能是个问题。
策略多样性。附录的消融实验（图8）显示，Discard-All + Summary的组合已经优于任一单独策略。但如果候选策略集本身不够多样——比如三个策略都是"不同程度的压缩"——那并行扩展的增益就有限。当前的三种策略（保留最近、摘要、全扔）确实覆盖了主要的上下文管理范式，但未来可能还有更好的候选策略。
和AgentFold的关系。同期有一篇AgentFold（2025年10月），同样关注长时Web Agent的上下文管理，但走的是"主动折叠"路线——在Agent内部训练一个上下文压缩能力，而非在外部做路由选择。AgentSwing是测试时方案，不需要重新训练模型；AgentFold是训练时方案，改了模型能力。两者的关系更像互补而非竞争：一个是从外部架构层面做自适应，一个是从内部模型层面做压缩。理想情况下，两者可以结合——用AgentFold训练的模型跑AgentSwing的路由框架，可能效果更好。
Token效率
图6：对齐案例中每个完成任务的交互轮次 vs 累计token数
图6的散点图说明了一个重要事实：AgentSwing的增益不是靠烧更多token换来的。Keep-Last-N在相似轮次下累计token更高（因为保留了更多历史），Discard-All累计token更少但需要更多轮次。AgentSwing大致处于中间位置——轮次比Discard-All少，token比Keep-Last-N少。
前瞻路由的额外token开销是适中的。考虑到它在Pass@1上的巨大提升，这个投入产出比是划算的。
策略转移：不同模型的偏好不一样
附录的策略转移分析（图9）也很有意思：DeepSeek-v3.2倾向于选择Summary，GPT-OSS-120B更常选择Discard-All。这说明不同模型在面对同样的上下文溢出时，"自救"的方式不一样——有些模型更适合"压缩继续"，有些更适合"推倒重来"。
这从另一个角度证明了静态策略为什么不行：连不同模型的最优策略都不一样，何况同一个模型在不同任务状态下的需求。
工程启发
如果你在做长时Agent系统，这篇论文有几个直接的takeaway：
-
上下文管理不是可选的，是必须的。不管理上下文的基线性能，在长时任务上远远落后于任何管理策略。如果你在跑BrowseComp这类长时搜索任务，最该做的第一件事就是加上下文管理。
-
不要只用一种策略。Keep-Last-N、Summary、Discard-All各有适用场景，最好的办法是动态选择。如果实现AgentSwing完整的并行分支太重，至少可以根据一些简单启发式做切换——比如最近K轮都在失败就切换到Discard-All。
-
前瞻几步再选。纯看压缩后的上下文做选择，效果明显不如让每个分支走几步看实际效果。即使只前瞻1步，也比无前瞻好。
-
交互轮次预算要给够。上下文管理的收益在轮次预算充足时才显现。如果你的应用场景只能承受几十轮交互，可能需要优先优化搜索策略本身而非上下文管理。
我的判断
AgentSwing这篇论文，我觉得最值钱的地方不在具体的并行分支机制——那个思路其实很直觉——而在于那个效率-精度的概率框架。\(\text{Pass@1} = \eta \cdot \rho\) 这个分解，把一个看似混沌的问题拆成了两个可以独立优化的维度，让后续的分析和设计都有了清晰的方向。
前瞻路由是个工程上很实用的设计，不需要训练额外模块，直接复用Agent模型自身做判断。K=3的甜点也很有工程指导意义。
不过，这个方向还有更深的问题没解决：现在的路由判断还是"黑盒"式的——模型看了几个分支的短期延续，凭"直觉"选一个。更理想的状态是，我们能理解什么样的上下文状态适合什么样的管理策略，然后把这个判断规则化。论文的策略转移分析（图9）其实已经触及了这个问题，但还没给出一个principled的回答。
总的来说，这是一篇在正确的时间点、对正确的问题、给出了一个工程上可行且有理论支撑的方案的好论文。如果你在做长时Agent系统，值得认真读一下。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我