手机里的 Agent 用着用着就"失忆"？这篇论文把上下文管理变成了一个可以学的动作

你有没有遇到过这种情况：让一个手机 GUI Agent 帮你"在 Amazon 上对比三款耳机的价格和续航，然后把结论记到备忘录里"——前几步它干得挺利索，可一旦跨了 App、走到第二十几步，它就开始犯迷糊：价格记串了、忘了自己要对比哪几款、甚至把还没做的操作当成已经做完了。

这不是个例，而是当下移动 GUI Agent 一个相当普遍的软肋。短程任务（点几下就完事）大家都做得不错，可一旦任务横跨几十步、要在多个 App 之间倒腾信息，成功率就断崖式下跌。

最近读到一篇叫 MemGUI-Agent 的论文（arXiv:2606.19926），它给这个问题开的药方挺有意思：不再让模型被动地把每一步都堆进 prompt，而是把"管理上下文"本身变成一个和点击、输入平起平坐的动作，让模型自己决定什么该压缩、什么该记住、什么该留着随时取用。我读完第一反应是——对，长程 Agent 早就该这么干了。

📖 一段话讲清楚这篇论文在做什么

长程移动 GUI Agent 不可靠，论文把锅甩给了 ReAct 式提示：它的做法是把每一步的记录被动地往 prompt 后面追加，结果就是两个病——prompt 爆炸（上下文随任务步数线性膨胀）和关键信息稀释（价格、验证码、复制的文本这些跨 App 的硬事实被冲淡、改写、截断甚至遗忘）。MemGUI-Agent 提出 Context-as-Action（ConAct），让同一个策略在选 UI 动作的同时，也输出三个结构化上下文字段的维护指令。配套构建了 MemGUI-3K 数据集（2,956 条带完整 ConAct 标注的轨迹），训出的 MemGUI-8B-SFT 在 MemGUI-Bench 上拿到开放数据 8B 模型的最佳成绩；而把 ConAct 零样本套到 Qwen3-VL-235B-Thinking 上，Pass@3 直接干到 62.5%，反超了基于 Gemini-2.5-Pro 的智能体框架。一句话评价：这是把"记忆/压缩"从外挂模块收编进策略本体的一次漂亮整合，思路干净，实验也撑得住。

论文信息 - 标题：MemGUI-Agent: An End-to-End Long-Horizon Mobile GUI Agent with Proactive Context Management - 作者：Guangyi Liu, Gao Wu, Congxiao Liu, Pengxiang Zhao, Liang Liu, Mading Li, Qi Zhang, Mengyan Wang, Liang Guo, Yong Liu - 链接：https://arxiv.org/abs/2606.19926 （提交于 2026 年 6 月 18 日，33 页 6 图） - 项目主页：https://memgui-agent.github.io/

🤔 问题到底出在哪：被动累积的原罪

先看一组让人有点扎心的数字。论文里提到，就连目前最强的 8B 端到端模型 GUI-Owl-1.5-8B，在 AndroidWorld（平均 8.4 步）上还有 71.6% 的成功率，可一到 MobileWorld（平均 27.8 步）就掉到 38.2%，再到 MemGUI-Bench（平均 36.2 步）只剩 11.7%。

任务一长，模型就崩。崩在哪？

论文的判断是：崩在上下文管理。现在的主流做法无非两条路。一条是智能体框架——给一个骨干 MLLM 配上规划、记忆、grounding 等一堆外挂模块，能打，但流程复杂、还经常依赖闭源大模型。另一条是端到端模型，简单、好部署，可它们管理上下文的方式特别"机械"：要么把每步动作-想法往后堆（Action-Thought），要么多轮对话硬塞（Multi-turn），要么按规则截断（Rule-based），要么干脆不留历史（No History）。

这几种姿势的共同毛病，论文这张图讲得很直白：

图1：ReAct 式被动累积 vs MemGUI-Agent 主动管理的对比。左侧每一步记录无脑追加，上下文随任务长度增长、无关信息越积越多；右侧通过 ConAct 维护三个紧凑而结构化的字段，上下文成本低、关键信息得以保留

图1：左边是过去的 ReAct 路线——passive history append，每一步 step₁、step₂…stepₙ 直接往下堆，于是"context grows with task length"，上下文成本高、无关信息不断累积；右边是 MemGUI-Agent 的 proactive manage via ConAct，把上下文拆成 Folded Action History、Folded UI State、Recent Step Record 三块，做到紧凑又结构化，上下文成本低、关键信息留得住。

说白了……抱歉，换个说法——问题的核心在于：这些方法都把上下文当成一个游离在策略之外的日志。外置记忆把上下文的取舍交给了模型之外的模块；prompt 式或规则式方法要么被动累积、要么机械丢弃旧事实。两边都没解决那个真正的诉求：长程任务既需要紧凑的工作上下文（不然 prompt 撑爆、推理变慢变贵），又需要跨屏幕、跨步骤、跨 App 持久保留的 UI 事实（不然价格、ID 这些硬信息说没就没）。

于是作者抛出了那个核心问题——能不能让一个端到端 Agent，在选 UI 动作的同时，自己管好工作上下文，使得长程交互既保持紧凑、关键 UI 事实又能跨步跨 App 地活下来？

🏗️ ConAct：把"管上下文"变成模型亲自下的决策

MemGUI-Agent 的答案，建立在一个叫 Context-as-Action（ConAct） 的范式上。名字起得挺贴切——上下文即动作。

核心思想一句话：不再被动追加历史，而是让同一个策略在一次前向传播里，既决定执行什么 UI/记忆动作，又决定折叠哪段历史、怎么描述当前这一步。 压缩和记忆不再外包给单独的 summarizer、retriever 或记忆 agent，而是直接继承 Agent 自己的任务级推理。

具体怎么落地？看这张框架图：

图2：ConAct 单步执行流程。左侧是 t 时刻的状态 Sₜ=(G, Hₜ, Mₜ, Lₜ)，包含任务目标、折叠动作历史、折叠 UI 状态、最近步记录；中间单个 MLLM 策略一次性输出 thinking/folding/tool_call/ui_observation/action_intent 五部分；右侧 A/B/C 三个模块分别完成历史折叠、工具调用执行、最近步记录更新，迭代进入下一状态

图2：单步执行流。模型吃进当前截图 \(I_t\) 和状态 \(S_t\)，一次性吐出 ConAct 的五部分输出；A 模块按折叠指令更新历史 \(H_{t+1}\)，B 模块执行 UI 动作（改变屏幕）或记忆动作（只改上下文），C 模块更新最近步记录 \(L_{t+1}\)，三者合并成下一状态 \(S_{t+1}\)，循环往复。

三个结构化字段，各管一摊

ConAct 把工作上下文拆成三块，对应论文里反复出现的状态定义：

\[\mathcal{S}_t = (G, H_t, M_t, L_t)\]
  • Folded Action History（\(H_t\)，折叠动作历史）：压缩后的轨迹摘要。一句话解释：把走过的路浓缩成几行"我之前干了啥"，而不是逐帧回放。
  • Folded UI State（\(M_t\)，折叠 UI 状态）：持久化的 UI 派生事实。这是用来存价格、电话号、复制的文本这类一个字都不能错的硬信息的。
  • Recent Step Record（\(L_t\)，最近步记录）：最近一步的交互细节，保持新鲜和精确。

每一步，MLLM 策略输出一个联合决策：

\[y_t = (\tau_t, \phi_t, a_t, o_t, \iota_t) \sim \pi_\theta(\cdot \mid I_t, \mathcal{S}_t)\]

其中 \(\tau_t\) 是推理，\(\phi_t\) 是折叠指令，\(a_t\) 是 UI 或记忆动作，\(o_t\) 是 UI 观察，\(\iota_t\) 是动作意图。

五部分结构化输出

落到具体的输出格式上，ConAct 在 Qwen3-VL 的 function-calling 模板基础上扩了字段，每步吐出 5 个部分：

<thinking>     推理过程
<folding>      {range, summary} —— 要折叠的历史区间 + 生成的摘要
<tool_call>    一个 UI 动作 或 记忆动作
<ui_observation>  当前屏幕的精确事实（可见文本、数字、名称）
<action_intent>   这一步想达成什么

动作空间也扩了，多出了记忆操作这一类：

\[\mathcal{A} = \mathcal{A}_{ui} \cup \mathcal{A}_{mem}, \quad \mathcal{A}_{mem} = \{\text{add}, \text{update}, \text{delete}\}\]

\(\mathcal{A}_{ui}\) 是点击、输入、滑动、等待、终止这些；\(\mathcal{A}_{mem}\) 则是对折叠 UI 状态 \(M_t\) 的增删改。

三个机制的细节，各自解决一个具体的病

历史折叠（管 \(H_t\)）：从第 2 步开始，Agent 必须输出一个 <folding> 块。折叠指令 \(\phi_t = ([s_t, t], z_t)\)，\([s_t, t]\) 是要压缩的历史区间，\(z_t\) 是生成的摘要。这里有个我觉得挺巧的设计——区分了两种粒度：\(s_t = t\) 是步级蒸馏（把最新一步压成紧凑记录），\(s_t < t\) 是跨步抽象（把一个完成的子任务整段总结成一条可复用记录）。它替换掉了那种不受控的 <conclusion> 堆积，把上下文增长从线性往次线性推。

UI 记忆动作（管 \(M_t\)）：每条记忆是个三元组 \(m = (\text{id}, d, c)\)——唯一标识、简短描述、完整内容。注意论文这里强调了一点，我认为是整篇最关键的工程直觉：记忆写入存的是完整的、任务相关的原始信息，而不是引用或有损摘要。存的是"那个完整的价格 $129.99"，而不是"之前看到的那个值"。当价格、验证码、联系方式必须熬过屏幕切换、长时间等待和 App 跳转时，这点至关重要。

自描述步输出（填 \(L_t\)）：<ui_observation> 给出带精确可见文本/数字的屏幕描述，<action_intent> 说明这步工具调用想干啥。这两个字段让每一步都"可被未来的上下文动作复用"。论文有个发现挺诚实——如果没有这俩字段，折叠和记忆动作就只能从原始的 <thinking> 和 <tool_call> 里去猜这步啥意思，他们实测发现，把上下文动作硬叠到 ReAct 的 3 部分协议上是不够用的。

整个状态转移合起来就是：UI 动作改屏幕、记忆动作只改上下文，三个字段各自更新，喂进下一步。因为折叠、记忆、意图都由同一个多模态策略在一次前向里预测，压缩和记忆天然带着 Agent 的任务级理解，而不是甩给一个独立模块去拍脑袋。

📚 MemGUI-3K：为什么光有协议还不够，得让模型学

这里有个反直觉的发现，是我觉得这篇论文做得最扎实的地方。

你可能会想：ConAct 既然是个 prompt 协议，那直接套到各种尺寸的模型上不就行了？作者老老实实做了这个实验，结果是——不行。

图6（此处先看模型尺寸消融的结论）：MemGUI-3K 数据采集与过滤流水线。扩展后的任务由 Qwen3-VL-235B-Thinking 教师在 Android 模拟器中并行 rollout，经 MemGUI-Eval+ 评估和步级合理性标注，在轨迹级与步级双重过滤后转化为 SFT 样本

图3：MemGUI-3K 的数据流水线。从 MemGUI-Bench 的 128 个种子任务出发，经过实体替换、记忆操作增强、任务简化三种策略扩展成 7,303 个任务池，5,293 个进入 rollout；Qwen3-VL-235B-Thinking 当教师用完整 5 部分 ConAct 协议执行，MemGUI-Eval+ 做评估、每一步打"合理/不合理"标签，双重过滤后最终得到 2,956 条轨迹、64,430 个 SFT 步样本。

回到那个"协议够不够"的问题。论文把同一套 5 部分 ConAct 协议零样本套到不同尺寸的 Qwen3-VL 上，结果是这样的：

模型尺寸 Base P@1 ConAct P@1 Base P@3 ConAct P@3 Base IRR ConAct IRR
Qwen3-VL-2B 10.0 5.0 ↓ 17.5 10.0 ↓ 10.8 1.6 ↓
Qwen3-VL-4B 20.0 12.5 ↓ 27.5 15.0 ↓ 19.0 10.7 ↓
Qwen3-VL-8B 12.5 7.5 ↓ 22.5 15.0 ↓ 15.0 10.7 ↓
Qwen3-VL-235B-Instruct 23.4 19.5 ↓ 36.7 28.9 ↓ 29.2 32.5 ↑
Qwen3-VL-235B-Thinking 5.0 40.0 ↑ 27.5 62.5 ↑ 19.5 51.0 ↑

看明白了吗？在 MemGUI-Bench-40 上，只有最强的 235B-Thinking 套上 ConAct 才暴涨——P@1 从 5.0% 飙到 40.0%。其余的小模型、甚至 235B-Instruct，加了这套协议反而掉点。

这说明什么？主动上下文管理不是改个 prompt 格式那么简单。模型得真的学会：什么时候该折叠历史、什么时候该把 UI 事实写进记忆、怎么生成可复用的步描述。这些是需要监督信号去教的决策能力。这个观察直接撑起了 MemGUI-3K 存在的必要性——我挺欣赏这种"先证伪简单方案、再引出复杂方案"的写法，比上来就甩数据集有说服力多了。

数据集长什么样

图4：MemGUI-3K 数据集统计。(a) 26 个 App 跨 7 个功能类别的任务分布，Productivity 占 32%、Shopping 16.6%、Information&News 14.5%；(b) 轨迹长度分布，MemGUI-3K 平均 28.8 步、约为 GUIOdyssey 平均 15.3 步的 1.9 倍；(c) 65.1% 的轨迹用到了记忆动作；(d) 23.8% 的折叠是跨步级摘要

图4：MemGUI-3K 全景。(a) 覆盖 26 个安卓 App、7 大类，Joplin、Amazon、Bing 这些是高频应用；(b) 轨迹平均 28.8 步、中位数 25，约为此前最长的移动 GUI SFT 数据集 GUIOdyssey（平均 15.3 步）的 1.9 倍；(c) 1,924 条（65.1%）轨迹用到了记忆动作；(d) 17,664 个（23.8%）折叠是跨步级摘要，平均跨度 6.25 步，88.7% 的轨迹至少有一次跨步折叠。

几个关键数字记一下：MemGUI-3K 最终含 2,956 条成功轨迹，跨 26 个 App，与 128 个 MemGUI-Bench 评测任务零重叠（这点很重要，避免了刷自家测试集的嫌疑）。抽取合理步后得到 64,430 个 SFT 样本（57,951 训练 + 6,479 测试）。步级合理性分析里，75.7% 的步被标为合理，平均每条轨迹 21.8 个可训练步。

训练用的是从 Qwen3-VL-8B-Instruct 出发、用 ms-swift 做 LoRA SFT，得到 MemGUI-8B-SFT。

🧪 实验：零样本反超 Gemini，8B 学完能跨基准迁移

评测在三个地方做：MemGUI-Bench、MobileWorld GUI-Only，以及用于消融和失败分析的 MemGUI-Bench-40。指标用 Pass@k（k∈{1,3}）、IRR（信息保留率）、MTPR（记忆-任务熟练比）。

图5：MemGUI-Agent 的核心性能。(a) 在 128 个任务、Qwen3-VL-235B-Thinking 上跑前 150 步，ConAct 的平均输入 token 增长明显比 ReAct 平缓，第 150 步时省约 1.5k tokens；(b) 更低的上下文成本转化为更高的成功率，MemGUI-Agent-235B 在 MemGUI-Bench 上 Pass@3 达 62.5%、MobileWorld 上 Pass@1 达 29.1%

图5：(a) Lower Context Cost——ReAct 的 token 随步数一路爬升，ConAct 则平缓得多，在长程区（step 50 之后）差距拉开，第 150 步省下约 1.5k tokens；(b) Higher Success Rate——在 MemGUI-Bench 上 MemGUI-Agent-235B 的 Pass@3 冲到 62.5%（紫色柱），超过基于 Gemini-2.5-Pro 的 Agent-S2（49.2）；MemGUI-8B-SFT（浅紫，35.9）也明显高于同尺寸基线。右半 MobileWorld 同样领先。

主结果：零样本 ConAct 在 MemGUI-Bench 上刷新 SOTA

先看 MemGUI-Bench 的主表，按难度（Easy 1–20 步 / Medium 21–40 步 / Hard 41+ 步）拆开：

Agent 类型 Easy P@1 Medium P@1 Hard P@1 Overall P@1 Overall P@3 Overall IRR
Agent-S2 (Gemini-2.5-Pro) 记忆 Agent 41.7 19.0 18.4 27.3 49.2 39.5
M3A (Gemini-2.5-Pro) 记忆 Agent 39.6 35.7 21.1 32.8 47.7 39.3
Qwen3-VL-235B-Thinking Action-Thought 18.8 28.6 26.3 24.2 46.9 30.0
Qwen3-VL-8B-Instruct Action-Thought 18.8 4.8 2.6 9.4 20.3 15.1
GUI-Owl-1.5-8B-Instruct Action-Thought 22.9 2.4 7.9 11.7 15.6 15.5
MemGUI-Agent-235B（零样本） ConAct 41.7 35.7 34.2 37.5 62.5 46.8
MemGUI-8B-SFT ConAct 25.0 23.8 21.1 23.4 35.9 30.2

几个值得拎出来的点：

MemGUI-Agent-235B 零样本拿到 37.5% Pass@1 / 62.5% Pass@3，超过了最强的智能体框架 M3A on Gemini-2.5-Pro（32.8% / 47.7%）。相比同骨干的 Qwen3-VL-235B-Thinking 基线，Pass@1 涨了 13.3 个点、IRR 涨了 16.8 个点。注意，这是零样本——权重一点没动，只换了 prompting 和动作协议。这个对比图5(a) 也补刀了：增益不是靠更大的 prompt 堆出来的，恰恰相反，ConAct 的 prompt 增长比 ReAct 平缓得多。

MemGUI-8B-SFT 从 9.4% 提到 23.4% Pass@1，而且增益集中在难任务上——Medium 涨 19.0、Hard 涨 18.5，Easy 只涨 6.2。这个难度趋势很能说明问题：MemGUI-3K 教的不是个新输出格式，而是在长程上下文漂移最严重的区间真正改善了行为。

跨基准迁移：MobileWorld 上同样能打

Agent 类型 GUI-Only SR (%)
GUI-Owl-1.5-32B-Instruct Action-Thought 43.9
GUI-Owl-1.5-8B-Instruct Action-Thought 38.2
OpenMobile-8B（开放数据） Action-Thought 17.7
Qwen3-VL-235B-Thinking Action-Thought 14.5
Qwen3-VL-8B-Instruct Action-Thought 9.4
MemGUI-Agent-235B（零样本） ConAct 29.1
MemGUI-8B-SFT ConAct 17.9

MobileWorld 这个基准的环境、App 集、评测协议跟 MemGUI-Bench 全不一样。MemGUI-Agent-235B 零样本拿到 29.1% SR，比 Qwen3-VL-235B-Thinking 基线高 14.6 个点；MemGUI-8B-SFT 也有 17.9% SR（比骨干高 8.5 个点），在开放数据 8B 模型里排前列。换句话说，学到的上下文管理技能是真的能迁移的，不是只会在源基准上过拟合。

离线技能分析：到底学会了啥

光看端到端成功率有点黑盒，作者又在 MemGUI-3K 测试集（295 条轨迹、6,479 步）上做了步级离线评估，把每个子技能拆开看。结论挺有意思：

  • UI 动作：匹配准确率从 29.2% 升到 36.3%，点击和输入涨得多——温和提升。
  • 记忆时机：触发 F1 从 19.9% 暴涨到 48.0%，甚至超过零样本 235B 的 34.3%——涨得最猛。
  • 深度折叠：MemGUI-8B-SFT 做到 26.1% 深度比、58.9% 深度区间准确率，而零样本 8B 只有 8.8% 深度比（gold 是 23.2%）。
  • 格式合规：99.9%，结构化生成基本不出错。

论文给的洞察我很认同：MemGUI-3K 教的是上下文控制决策，不只是格式；最大的增益来自把转瞬即逝的观察提升为持久记忆。

消融：三个组件，缺一不可

这张消融表是全文的"题眼"，直接验证了 ConAct 三件套的互补性（MemGUI-Bench-40，零样本 235B-Thinking）：

变体 P@1 P@2 P@3 MTPR IRR
ReAct 基线 5.0 20.0 27.5 0.143 19.5
+ UI 记忆动作 17.5 35.0 42.5 0.357 39.1
+ 历史折叠 22.5 25.0 32.5 0.179 25.7
+ 自描述步 25.0 40.0 45.0 0.214 33.1
完整 ConAct 40.0 52.5 62.5 0.429 51.0

读这张表我停了一下。单看每个组件：UI 记忆动作把 Pass@1 从 5.0% 直接翻三倍到 17.5%，持久状态的价值立竿见影；历史折叠 Pass@1 到 22.5% 但 Pass@3 只有 32.5%，说明光压缩留不住关键事实；自描述步到 25.0%。可一旦三个合起来，Pass@1 冲到 40.0%、Pass@3 到 62.5%，远超任何单组件变体。

这就是关键。三者分工明确：折叠控制上下文增长，记忆保留精确事实，自描述给前两者提供 grounding。哪个单拎出来都不够。

失败分析：ConAct 治的是哪种病

图6：失败类型热力图。按 ReAct→+记忆动作→+历史折叠→+自描述→完整 ConAct 五列，统计过程幻觉、输出幻觉、知识缺陷、意图理解、其他五类失败的数量。完整 ConAct 把总失败从 99 降到 58（降 41%），主要来自过程幻觉（52→30）和输出幻觉（30→13）的下降

图6：失败类型热力图。完整 ConAct 把总失败数从 99 砍到 58，降了 41%。降幅主要集中在两类：过程幻觉（从 52 降到 30，降 42%）和输出幻觉（从 30 降到 13，降 57%）。而知识缺陷（11）、意图理解（4）、其他（0）基本没动。

这张图说得很清楚：ConAct 主要治的是上下文引发的幻觉——过程幻觉（偏离流程或误以为某步已完成）和输出幻觉（拿到了 UI 证据却报错/存错事实）。但知识缺陷、意图理解这些跟上下文关系不大的失败，它管不着。论文的洞察很克制：剩下的天花板在于知识、意图理解和环境鲁棒性。 这种不夸大自己疗效的态度，我挺受用。

💡 我的判断：一次干净的"收编"，但别神化

聊聊我的看法。

最值钱的地方，是它把"上下文管理"这件一直被当成外挂模块（记忆库、retriever、summarizer）的事，收编进了策略本体。让同一个模型在一次前向里既选动作又管上下文，这个统一带来的好处是实打实的——压缩和记忆继承了任务级推理，而不是交给一个啥都不懂的独立总结器去拍脑袋。那个"记忆写完整原始信息而非引用"的细节，看着朴素，但恰恰是长程任务里跨 App 传价格、传验证码不出错的命门。

那个模型尺寸消融也让我对这套方法多了几分信任。它没有藏着掖着说"我这协议放之四海皆准"，而是诚实地展示了小模型套上去反而掉点——主动上下文管理是门需要学的手艺，不是换个 prompt 模板就白嫖的。这个发现本身就有价值。

不过有几个地方我会保持谨慎。

其一，MemGUI-3K 是用 Qwen3-VL-235B-Thinking 当教师蒸馏出来的，而零样本表现唯一能打的也正是这个 235B-Thinking。这里多少有点"自家教师教自家学生"的味道——8B 学到的上限，某种程度上被这个特定教师的行为模式框住了。换个骨干家族，ConAct 的零样本红利还在不在？论文没回答，我也不确定。

其二，绝对成功率还是偏低。MemGUI-Bench 上最好的 Pass@1 也才 37.5%，离"能放心交给它干活"还有距离。这不是贬低——长程移动 GUI 本来就难——但读者别被"反超 Gemini 框架"这种表述带飞，37.5% 的含义是十次里有六次第一遍就没做成。

其三，整套方法目前是 SFT，没上 RL。失败分析里那些没被治住的知识/意图问题，以及"记忆该写什么、何时折叠"这类决策的进一步优化，按理说是 RL 的天然战场。论文也把这个留作了未来工作。

对工程的启发

如果你也在做长程 Agent（不限于 GUI，长文档处理、多轮工具调用都算），这篇论文有两个思路值得抄：

  1. 别再无脑往 context 里 append 了。把上下文显式拆成"可压缩的历史 / 必须精确保留的硬事实 / 新鲜的最近记录"三类，让模型自己决定怎么维护——哪怕你不训练，光是这个结构化拆分本身，在足够强的骨干上就有红利。
  2. 记忆要存完整原文，不要存引用。"那个之前看到的值"这种有损指代，是长程任务里事实丢失的重灾区。

🔗 写在最后

MemGUI-Agent 不是那种横空出世改写一切的工作，它更像是一次思路清晰、执行扎实的"整合与收编"——把散落在外挂模块里的上下文管理，干净利落地塞回了策略本体，并且用一个尺寸消融诚实地告诉你"这玩意儿得学"。对长程 Agent 这个方向，我觉得 ConAct 这种"把上下文管理当一等动作"的范式，很可能会成为后续工作的一个标准组件。

代码、数据和模型作者说会在 https://memgui-agent.github.io/ 放出，感兴趣的可以蹲一下。

（本文基于 arXiv:2606.19926 解读，数据与图表均来自论文原文。）

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我