MemGUI-Agent：把「上下文管理」变成 Agent 的一等动作

论文精读 · 第 4 篇 论文：MemGUI-Agent: An End-to-End Long-Horizon Mobile GUI Agent with Proactive Context Management arXiv:2606.19926 · 2026.06 · Liu et al. · 项目主页

与本站 Harness Engineering · Context、Memory 直接对话——讲长程任务里，上下文该主动管，而不是被动堆。

---

TL;DR

移动 GUI agent 在短任务上很能打，但一放到长程任务（跨多步、跨多个 app、要记住中间状态）就崩。根因是 ReAct 式提示被动累积每步记录，上下文越滚越长，关键事实被稀释淹没。MemGUI-Agent 提出 ConAct（Context-as-Action）：把「上下文管理」本身变成 agent 的一等动作——和点按钮一样，由同一个策略模型决定。用一个 8B 模型，在 MemGUI-Bench 上做到开源 8B 最佳，还能泛化到没见过的 MobileWorld。

一句话：长程任务里，管上下文不是预处理，是动作。该删什么、保留什么、折叠什么，得 agent 自己边做边决定。

---

一、它想解决什么问题

先理解长程 GUI 任务为什么难。

一个典型长程任务：「订下周二去北京的机票，然后把航班号发给妈妈，再设个起飞前两小时的闹钟」。这跨三个 app，要记住航班号、时间、联系人这些中间事实，跨越十几个步骤。

现在主流 GUI agent 用 ReAct 范式：每一步都「思考 + 动作 + 观察」，把每步记录追加到上下文里。

[第1步记录] → [第2步记录] → ... → [第N步记录]  ← 上下文越堆越长

这在大模型长上下文窗口下能撑一会，但长程任务会暴露两个病：

病症	表现
Prompt 爆炸	上下文超过窗口或显著拉高延迟/成本
关键事实稀释	真正重要的跨步事实（航班号、联系人）被埋在几十步流水账里，模型检索不到

第二个比第一个更要命——上下文没爆，但 agent 「忘记」了关键信息，因为它压根没被「显式管理」，只是被动躺在历史里。

这呼应本站 Harness Engineering · Context 的核心论点：

上下文窗口大，不等于上下文管得好。把所有东西塞进窗口，是最偷懒也最脆弱的上下文工程。真正要管的是「什么该进上下文、什么该出上下文」。

MemGUI-Agent 就是把这个「该进该出」的决定，从规则脚本交还给 agent 自己。

---

二、核心思想：Context-as-Action（上下文即动作）

整篇的灵魂：

上下文管理不该是被动的预处理，而是 agent 主动发出的动作。

为什么这是关键转变？

传统做法里，上下文怎么管是规则定的：保留最近 N 步、或用检索按需召回、或定期摘要。这些规则是人写死的、脱离任务的。但「什么重要」高度依赖任务——订机票时航班号重要，发消息时联系人重要，规则没法预先覆盖所有情况。

ConAct 的解法：让同一个选 UI 动作的策略模型，同时发出「上下文管理动作」。也就是 agent 在每一步可以选择：

• 点哪个按钮（UI 动作）
• 折叠/保留/丢弃 哪段历史（上下文动作）

两者由同一个策略统一决策。这样上下文管理就成了任务感知、主动、可学习的——agent 知道当前目标，自然知道该记什么。

维度	传统规则式上下文管理	ConAct
决策者	人写的规则	agent 自己
任务感知	否（一刀切）	是（看当前目标）
主动性	被动累积/定期清理	边做边主动管理
可学习	否	是（随策略一起训练）

这呼应 Harness Engineering · Memory 的判断：

记忆/上下文的管理逻辑，应该和任务执行逻辑同源，而不是割裂的两套系统。割裂会导致「管记忆的不懂任务，做任务的不顾记忆」。

ConAct 让它们合一。

---

三、三个结构化上下文字段

ConAct 不维护一长串流水账，而是把上下文维护成三个结构化字段：

字段	内容	作用
折叠的动作历史	已压缩/摘要过的早期步骤	保留「做过什么」的骨架，丢掉细节
折叠的 UI 状态	已离开页面的关键状态	保留「页面长啥样、有什么关键信息」，丢掉噪声
最近的步骤记录	最近几步的完整记录	当前决策需要的精细上下文

关键设计是「折叠」：老步骤不是直接删（会丢信息），也不是原样留（会爆），而是压缩成摘要。哪个该折、折到什么粒度，由 agent 动作决定。

长程任务的上下文演化（概念）：

步1─步8：     [折叠历史]              ← 骨架 + 关键状态
步9─步12：    [最近步骤] [最近步骤]   ← 当前精细
            │
            │ agent 执行到步13
            │ 发出 ConAct 动作：折叠步9-10
            ▼
步1─步10：    [折叠历史]              ← 更长的骨架
步11─步13：   [最近步骤]              ← 滚动窗口

这样上下文像一条传送带：老的不断被折叠进骨架，新的不断滚入精细区，关键的跨步事实（航班号、联系人）被 agent 显式保留在「折叠的 UI 状态」里，不会被淹没。

---

四、让它可学习：MemGUI-3K 数据集

ConAct 的难点：上下文管理动作怎么学会？

如果只在推理时让 agent「自己决定折不折」，没有监督，它不会主动这么干。MemGUI 的解法是造数据 + 监督训练：

• 构建 MemGUI-3K：2956 条轨迹，每条都带完整的 ConAct 标注（每一步该发什么上下文动作）
• 在 MemGUI-3K 上 SFT 训练一个 8B 模型 → MemGUI-8B-SFT

这套数据不仅用来训练，还用来离线分析长程任务里上下文到底该怎么管。这是论文的一个附加贡献：它不只是给方法，还给了一份「长程上下文管理的标注范本」，供后续研究复用。

呼应 Harness Engineering 反复讲的工程观：

一个能力要可靠，光有 prompt 提示不够，得让它变成模型可学习的、稳定的行为。靠提示词拼凑的能力，换任务就崩。

---

五、实验结果

指标	结果
MemGUI-Bench（长程）	开源 8B 最佳
泛化到 MobileWorld（OOD）	有效，不只在训练分布内有效

两个点值得强调：

1. 8B 就够。 不是靠堆参数，而是靠管好上下文。这又一次说明：长程任务的瓶颈常常不是模型容量，是上下文工程。
2. 能泛化。 ConAct 学到的「上下文管理策略」是任务无关的通用能力——在不同 app、不同任务上都能迁移。如果它只是在背训练集，MobileWorld（分布外）上就该崩。

---

六、工程对照：MemGUI-Agent 验证了什么

MemGUI-Agent 的设计，对应本站 Harness Engineering 几个核心论断：

MemGUI 设计	对应论断	系列文章
上下文管理是动作	管「进出上下文」重于堆窗口	Context
三个结构化字段	记忆要结构化，不是流水账	Memory
ConAct 随策略训练	能力要可学习，不靠提示词	Runtime
折叠而非删除	压缩 > 丢弃，保留骨架	Context

更深一层的启发，和 EDV（本站精读）形成一组对照——两者都在讲「经验/上下文的可靠性」，但角度互补：

• EDV 讲：经验写入记忆前要验证（跨任务、跨时间复用的长期记忆）
• MemGUI 讲：上下文在任务执行中要主动管理（单任务、当下的工作记忆）

一个是长期记忆的质检，一个是工作记忆的动态调度。合起来，就是 agent 记忆工程的两个端：写入要严，使用要活。

---

七、启发与局限

启发：

1. 长程瓶颈在上下文，不在模型。 与其追更大窗口，不如让 agent 学会「什么该进上下文」。MemGUI 用 8B 打长程，是上下文工程 > 模型容量的又一证据。
2. 「管理」本身要是一等能力。 折叠、保留、丢弃这些动作，不该是人写规则，而该是 agent 可学习的策略。规则管不过来的长尾，学习能覆盖。
3. 折叠优于删除。 老信息直接删会丢关键事实，原样留会爆。压缩成骨架（折叠）是中间道，既控量又留痕。

局限：

1. 依赖标注数据。 MemGUI-3K 的 ConAct 标注要人工造，成本不低。能否用更弱的监督（如 EDV 那种共识验证）自动生成，是开放问题。
2. 折叠摘要会丢细节。 摘要必然有损，万一关键信息在折叠时被压没，长程任务仍可能出错。「折到什么粒度」是个需要校准的旋钮。
3. 三个字段的划分偏经验。 为什么是这三个字段（折叠历史/UI状态/最近步），而非其他结构？论文给了实证但没有理论推导，这套划分是否最优待验证。

一句话点评： MemGUI-Agent 把「上下文管理」从 agent 的后勤，提升为它的本职动作。它点破的常识是——长程任务里，记住什么和做什么一样重要，而前者长期被当成预处理草草带过。让 agent 自己管上下文，是比堆窗口更根本的解法。