MemGUI-Agent 在长程手机任务里翻车，先别急着换模型或改提示词，先判断断点落在哪一层。通常可以分成三层看：记忆负责把上一步的页面结果带进下一步，规划负责把长程目标拆成当前页面上能执行的子目标，点击执行负责在正确的控件上真正触发动作。最常见的误判是把执行层问题当成记忆丢失：页面还在加载、控件已经出现但不可点、弹窗遮挡，Agent 重复点了同一个按钮，回放里看起来就像“忘了上一步做过什么”。可用证据只有四类——配置、运行日志、任务回放、页面文本与控件状态；没有回放记录时，建议先补记录，再谈挑哪一层改。
排查顺序建议固定：先在回放里查上一步摘要有没有进入下一步的输入（记忆），再看页面变化后规划有没有重新选动作（规划），最后看每次点击前后的控件状态与无反馈重试次数（执行）。页面加载慢引起的重复点击，经常被读成记忆丢失。三层结论都要落到页面文本、控件状态或回放记录上；缺回放时先补日志，不要凭一张截图定性。
在任务指令里标出跨应用的长程步骤
先做一件手工活：把任务从开始到结束经过的应用和页面按顺序列出来，逐个标出“必须记住上一步结果”的节点。跨页面、跨应用的边界就是记忆层最容易出问题的位置，因为这些位置通常伴随着应用切换、页面重建和上下文重置。以“把昨天订单的物流单号发给同事”为例，可以先写成下面这种步骤图，包名和页面名按自己设备替换。
task: 查订单物流并发给同事
steps:
- app: 购物App page: 订单列表 need_remember: 选中的订单
- app: 购物App page: 订单详情 need_remember: 物流单号
- app: 系统 page: 最近任务 need_remember: 当前任务未结束
- app: 聊天App page: 会话列表 need_remember: 目标联系人
- app: 聊天App page: 单人会话 need_remember: 待粘贴的物流单号标完之后看两点：哪些节点是“切应用”，哪些节点是“页面重建”。这两类节点如果日志里没有携带上一步摘要，后面的动作多半会走偏。这张步骤图同时也是后面回放定位的索引，不建议跳过。
从任务回放里确认记忆是否保存了上一步结果
回放记录里通常能找到每步的观测摘要与动作摘要，字段名各实现不一样，先按自己项目里的字段名替换后再查。目的很单一：看第 N 步的摘要有没有出现在第 N+1 步的输入或动作参数里。
# 字段名以实际实现为准，这里只是通用骨架
grep -n "step_summary\|observation_summary\|action_input" agent_run.log | tail -40对比时看三种情况。第一种，上一步摘要在下一步输入里原样出现，说明记忆层至少完成了传递。第二种，下一步没有引用摘要，而是重新打开同一个页面再读一遍——这通常不是记忆丢失，而是规划层选择“重新观测”，需要结合任务耗时和风险判断是否可接受。第三种，下一步既没引用也没重读，直接用了默认值或空值，这种更接近记忆断点。判断边界在于：能不能在回放里指认出“摘要消失的那一步”，指认不出来就先别改提示词。
检查规划层有没有把长程目标拆成可执行子目标
规划层要回答的问题是：当前页面能不能支撑下一步动作，不能的话该切到哪。给一段任务指令示例，要求目标、子目标、当前页面三者能对上：
目标: 把昨天订单的物流单号发到同事的聊天窗口
当前页面: 购物App / 订单详情
子目标:
1) 在当前页找到并复制物流单号
2) 切到聊天App
3) 打开与目标联系人的会话
4) 粘贴并发送
约束: 每一轮只能执行一个子目标；页面变化后重新判断当前子目标是否仍成立验证方式是看规划输出随页面变化有没有重新选择动作。如果弹出一个权限弹窗，规划应该把“关闭弹窗”插为当前子目标，而不是继续执行“粘贴发送”。如果日志里同一子目标在页面已经变化后仍被反复输出，规划层就值得先查。反过来，如果规划每步都在重写整个子目标列表，长程任务里也容易丢上下文，需要结合回放确认。
观察点击执行层是否因页面等待而重复操作
这一层最容易被误读成记忆问题。做法是记录每次点击前后的页面文本或控件状态，并标出无反馈时的重试次数。
[click] target="提交订单"
before_text="提交中，请稍候"
after_text="提交中，请稍候"
new_element=false
retry=2判断规则建议自己定义并写进配置：点击后等待某个条件成立（目标文本变化、出现新控件、页面标题切换），而不是固定 sleep；在等待窗口内 after_text 与 before_text 相同且没有新元素出现，就记为“无反馈”，重试次数加一。如果同一个 target 在页面文本完全没变的情况下被点了多次，优先怀疑等待条件写得不够，而不是记忆层丢了信息。需要留的边界是：有些应用确实需要二次点击确认，重试次数不能一味压到 1，否则会把正常确认流程也拦掉，具体阈值要结合所测应用确认。
给每三层之间加一个可验证的交接证据
三层分开看只是排查手段，真正让后续长程任务可以复用，是在层与层之间留一份可核对的交接证据。下表是一份通用检查表，字段名可按自己日志格式调整。
| 交接 | 必须留的证据 | 验证方式 |
|---|---|---|
| 记忆 → 规划 | 上一步页面摘要，含关键标识（订单号、联系人名、页面标题） | 在回放里确认摘要出现在下一步规划输入中，而不是被重新观测覆盖 |
| 规划 → 点击执行 | 本轮选定的子目标与目标控件定位信息 | 对比点击日志里的 target 是否等于规划输出的控件，页面切换后是否重新选择 |
| 点击执行 → 下一轮记忆 | 点击前后的页面文本或控件状态、是否出现新元素、重试次数 | 看下一轮摘要是否反映点击后的真实页面，而不是点击前的旧状态 |
观察清单可以按同一划分落地：记忆层看“摘要是否传递、是否被重读覆盖”；规划层看“页面变化后是否重选动作、子目标是否与当前页面对应”；点击执行层看“无反馈重试次数、等待条件是否成立”。先用页面状态和任务回放把断点定位到某一层，再改对应的配置或提示词，比三层一起调更容易看出改动是否有效。若回放里三层证据都齐但任务仍失败，通常说明问题在环境侧（网络、账号权限、应用版本），这时建议先复现一次并保留原始页面截图，再决定是否继续调整 Agent 侧。