夜雨聆风让 AI 在手机上查商品参数、记笔记、更新联系人，听起来像是很顺手的自动化任务。它会看屏幕，会点按钮，会输入文字。可任务一拉长，问题就来了：App 页面变了，它要重新适应；几十步之后，前面看到的价格、规格、手机号，又可能被上下文冲掉。
让 AI 在手机上查商品参数、记笔记、更新联系人，听起来像是很顺手的自动化任务。
它会看屏幕，会点按钮，会输入文字。
可任务一拉长，问题就来了：App 页面变了，它要重新适应；几十步之后，前面看到的价格、规格、手机号，又可能被上下文冲掉。
快手主站技术部和浙江大学 APRIL 实验室最近连续放出两项手机 GUI Agent 工作。
一项叫 MobileForge。解决的是手机 Agent 怎么低成本适应真实 App。
另一项叫 MemGUI-Agent。解决的是长程任务里，Agent 怎么保存关键 UI 事实。
两个项目都已经开源。
这两篇论文拼在一起看，手机 Agent 的瓶颈被拆得很清楚：会点屏幕，只是第一步。
先看适应问题
MobileForge 针对的场景很现实。
手机 App 太碎了。页面结构、按钮位置、功能入口、任务流程，今天一版，明天又一版。
如果每个 App 都要人工写任务、录专家轨迹、标奖励信号，成本会很快失控。
MobileForge 的做法，是把这套适配流程做成一条闭环：真实 App 探索，自动生成任务，分层评估执行过程，再把反馈转成训练信号。
这条链路里有两个关键组件。
MobileGym
它负责进目标 App 里探索。系统会根据 APK 里的 activity 信息和当前截图，生成面向功能的探索目标。探索轨迹不会被当成专家示范，而是用来发现真实页面、可点击控件和实际存在的功能。
这一步很重要。
Agent 不能靠脑补学习一个 App。它得先知道这个 App 真的有什么页面，哪些控件能点，哪些流程跑得通。
探索之后，MobileGym-Curriculum 会把轨迹转成可执行任务。每个任务包含任务指令、预估步数、核心功能、变化类型和前置条件。形式不复杂，关键是任务必须锚定真实观察到的 App 行为。
随后 MobileGym-Critic 对 rollout 做分层评估：任务最终成没成，每一步是否合理，失败后下一次应该避开什么。
HiFPO
它负责把这些反馈变成训练。
同一个任务，Agent 会尝试多次。第一次没有额外提示；如果失败，Critic 会生成纠错 hint。第二次尝试时，这些 hint 会被放回任务上下文，提醒模型别重复犯错。
这里最有意思的地方，是失败任务没有被简单丢掉。
在长链路手机任务里，一条失败轨迹也可能包含正确局部步骤：打开 App 是对的，搜索入口找对了，某个筛选动作也对，只是最后确认时出错。
MobileForge 会保留全失败和部分成功任务，再用步骤级反馈挑出合理动作。已经每次都能成功的 mastered tasks，反而训练价值不高。
这套设计不是只停在流程图上。
在 AndroidWorld 上，Qwen3-VL-8B 基线 Pass@3 是 55.2%。经过 900 个自动生成任务适配后，ForgeQwen3-8B 提到 67.2%。Pass@1 从 40.5% 到 50.9%，Pass@2 从 49.1% 到 60.3%。
基于 GUI-Owl-1.5-8B 适配得到的 ForgeOwl-8B，AndroidWorld Pass@3 达到 77.6%。在没有用 MobileWorld 任务、轨迹或反馈训练的情况下，它在 MobileWorld GUI-only 117 个任务上拿到 41.0% 成功率。
还有一个消融数字更直观。
Qwen3-VL-8B 在 200 个生成任务上 rollout，不加前一次失败 hint。多次尝试总成功率是 52.0%；加入纠错提示后，总成功率到 77.0%，Pass@3 从 49.0% 到 72.5%。
前一次失败，真的能变成下一次尝试的燃料。
再看记忆问题
MobileForge 解决的是“App 变了怎么学”。
MemGUI-Agent 盯的是另一道坎：任务长了怎么记。
手机 GUI 长程任务最烦人的地方，是关键信息经常只出现一次。
你让 Agent 在 Amazon 查三款手机的屏幕尺寸、电池容量、存储选项，再去 Joplin 里写笔记。参数出现在中间页面，几十步后才要用。
你让它从 Mastodon 最新帖子里提取 Olivia 的新手机号和邮箱，更新 Contacts，再去 Messages 发短信。联系人信息也只在某个页面短暂出现。
传统 ReAct 风格会把每一步思考、动作和结果追加进上下文。短任务里还能用。任务一长，历史记录线性膨胀，成本上去，噪声也上去。
前面看到的价格、电话号码、规格、日期、待写入文本，很容易被稀释、转述错误，甚至丢掉。
MemGUI-Agent 的核心设计叫 ConAct，Context-as-Action。
它把上下文管理变成和点击、输入、滑动同级的动作。
每一步，Agent 不只决定下一次点哪里，还要决定三件事：
折叠哪些历史。
保存哪些 UI 事实。
怎么描述当前步骤。
ConAct 里有三个结构化字段。
Folded Action History 保存压缩后的历史轨迹。完成的子任务不再机械堆进去，而是折叠成可复用摘要。
Folded UI State 保存关键 UI 事实。比如完整电话号码、商品价格、规格参数、联系人信息。这里不能只写“我看到一个价格”，而要保存完整内容。
Recent Step Record 记录最近一步的屏幕观察、动作意图、执行动作和结果，给下一步折叠和记忆更新当原料。
这不是简单加一段提示词。
论文在 Qwen3-VL 不同规模模型上做了零样本实验。只有 Qwen3-VL-235B-Thinking 明显受益于 ConAct；较小规模模型或 235B-Instruct 直接套 ConAct，性能可能下降。
模型得学会什么时候压缩历史，什么时候写入 UI 事实，怎么生成可复用步骤描述。
为此，研究团队构建了 MemGUI-3K。
这个数据集由 MemGUI-Bench 的 128 个种子任务扩展而来。研究者通过实体替换、记忆操作增强、任务简化，把任务池扩到 7303 个，其中 5293 个进入 teacher rollout。
最终数据包含 2956 条成功轨迹，覆盖 26 个 Android App、7 类功能场景，提取出 64430 个 SFT 样本。训练集里有 57951 个合理步骤，测试集有 6479 个合理步骤。
平均轨迹长度 28.8 步，中位数 25 步。
65.1% 的轨迹至少用过一次 memory action。
88.7% 的轨迹至少包含一次 span-level fold，也就是把多个步骤压缩成一个已完成子任务摘要。
这组数字说明，MemGUI-3K 教的不是“怎么点按钮”。它在教 8B 模型长程任务里怎么管理自己的工作记忆。
结果也对应上了。
MemGUI-Agent-235B 在 MemGUI-Bench 上达到 37.5% Pass@1、62.5% Pass@3、46.8% IRR。相比同一 235B backbone 的 ReAct 基线，Pass@1 提升 13.3 个百分点。Pass@3 提升 15.6 个百分点，IRR 提升 16.8 个百分点。
MemGUI-8B-SFT 在 MemGUI-Bench 上达到 23.4% Pass@1、35.9% Pass@3、30.2% IRR。相比 Qwen3-VL-8B-Instruct 基线，分别提升 14.0、15.6 和 15.1 个百分点。
在 MobileWorld GUI-only 上，MemGUI-Agent-235B 成功率是 29.1%。比 Qwen3-VL-235B-Thinking 基线高 14.6 个百分点。
MemGUI-8B-SFT 是 17.9%，比 Qwen3-VL-8B-Instruct 高 8.5 个百分点。也略高于 OpenMobile-8B 的 17.7%。
完整 ConAct 的组件消融也很清楚。
在 MemGUI-Bench-40 上，ReAct baseline Pass@1 只有 5.0%。单独加入 UI memory actions 是 17.5%，单独加入 history folding 是 22.5%。单独加入 self-describing step 是 25.0%。
完整 ConAct 到 40.0% Pass@1，Pass@3 到 62.5%，IRR 到 51.0%。
少任何一块，信息流都会不稳。
两道坎，其实是一件事
把两篇论文放到一起，手机 Agent 的落地方向更清楚。
MobileForge 让 Agent 在真实 App 中探索，生成任务，吃下分层反馈。它补的是适应能力。
MemGUI-Agent 让 Agent 在执行过程中主动折叠历史、写入 UI 事实、描述当前步骤。它补的是长程记忆。
一个解决“环境会变”。
一个解决“任务会长”。
这也解释了为什么很多手机 Agent demo 看起来很顺，但一到真实任务就掉链子。
单次点击能力不够用。
真实 App 里有版本更新、入口变化、跨页面跳转、重复流程、临时出现的信息，还有几十步之后才需要用到的关键事实。
比如删除三项支出。基础 Qwen3-VL-8B 能进入删除确认流程，但删掉早期项目后，任务流丢了，反复打开和关闭侧边栏。MobileForge 适配后的 ForgeQwen3-8B 能沿着同一 App 的删除模式连续处理多个项目。
又比如商品规格对比写入笔记。MemGUI-Agent 会在看到屏幕尺寸、电池容量、存储选项时写入 UI memory，完成阶段性子任务后折叠历史。后面切到 Joplin，不用从冗长轨迹里重新捞事实。
这些都不是“多点几次”能自然解决的问题。
Agent 要在手机上办事，得把失败经验、局部正确动作、跨页面事实，都变成可用状态。
别把 benchmark 当产品发布
这两项工作值得看，但边界也要放在桌面上。
第一，数字主要来自 AndroidWorld、MobileWorld、MemGUI-Bench 这些评测。它们能说明研究方向有效，不能直接推出普通用户手机上已经稳定可用。
第二，跨域泛化还受基础模型能力限制。MobileForge 里，ForgeOwl-8B 在 MobileWorld GUI-only 上到 41.0%；但 ForgeQwen3-8B 只是从 7.6% 到 10.3%。基座对移动 UI 理解弱，适配算法也很难凭空补齐全部能力。
第三，MemGUI-Agent 的失败分析里，ConAct 主要减少上下文诱发的幻觉。process hallucination 从 52 降到 30，output hallucination 从 30 降到 13。但 knowledge deficiency、intent misunderstanding 和环境鲁棒性改善有限。
也就是说，记得住，不代表一定理解任务；适应了一个 App，也不代表跨 App 协调就没问题。
手机 Agent 下一步要看的，不是又一个点击 demo。
要看它能不能在真实 App 更新后继续探索，能不能在几十步之后准确拿回中间看到的事实，能不能在失败轨迹里挑出可学的局部动作。
浏览器 Agent、桌面 Agent、办公 Agent 也会撞上同一类问题。页面会变，任务会长，历史会膨胀，失败里也有能用的经验。
手机只是把这些矛盾压缩到一块小屏幕上。
如果未来手机 Agent 真能从“会点”走到“能办事”，适应和记忆这两块，绕不过去。
