把长程目标直接丢给 MemGUI-Agent，最容易出现的不是“跑不动”，而是跑偏之后没有落脚点：点错了按钮、进错了页面，只能整条流程重来，前面的上下文和已确认字段全部作废。更可控的做法是：先人工把流程拆成几个带页面证据的中间状态，再在任务指令里写明“偏离时退回哪个检查点”。前提是每一步都有页面上看得见的完成标志；只能靠“感觉差不多”的步骤，不适合当检查点。

把长程手机流程拆成“打开应用—进入目标页面—填写字段—提交结果”这类中间状态，并为每个状态绑定一个页面上可观察的证据（页面标题、按钮可用状态、输入框内容、列表项文本），再在 MemGUI-Agent 的任务指令里写明偏离后返回上一个检查点。这套写法适合界面结构稳定、步骤可复述的流程；登录过期、随机弹窗等情况仍需人工兜底，检查点是否真的生效，要用一次故意误点来验证。

把长程目标拆成可验证的中间状态

拆分的标准不是“动作有多小”，而是“每个阶段结束时有确定的页面状态”。建议按页面而不是按手指数来分段：每段的结束标志都是下次重新开始时可以直接到达的位置。下面是一个可以照着改的拆分示例，第三列是给检查点起的名字，方便在日志和指令里引用。

拆完之后建议数一遍：如果某个阶段既要打开应用又要填表，那它中途失败时就没法判断该退回哪里，需要继续拆。起步阶段可以先拆 3~4 段，页面结构稳定后再细化。

为每个中间状态选一个页面上的可见证据

判断阶段是否完成，不要用“看起来差不多了”，要用页面上明摆着的东西。常见的可观察证据包括：

• 页面标题或顶部栏文本：最稳的一类证据，页面切换时通常会变。
• 按钮状态：启用/禁用、文案变化，适合判断表单是否满足提交条件。
• 输入框内容：用输入框里的文本确认填写步骤真的落到了页面上。
• 列表项文本：确认已经进入正确的结果列表，而不是同名的另一个入口。
• 弹窗或提示文本：用于判断提交结果，但要留意它可能是随机出现的。

建议每个检查点选一到两个证据，其中一个尽量是标题类文本，另一个是交互状态。只依赖颜色、图标位置这类证据通常不够稳，因为不同设备、不同分辨率下的表现需要结合运行环境确认。

在 MemGUI-Agent 任务指令里写入回到检查点的条件

检查点只有写进任务指令，才有机会被智能体在偏离时用上。下面是一段通用骨架，方括号里的内容按实际页面替换；它的结构是“目标 + 检查点清单 + 偏离后的返回动作”，可以整段作为任务描述提交给 MemGUI-Agent。

目标：在应用 [应用名] 中完成 [最终结果]，例如提交一条 [表单名称]。

检查点（按顺序推进，每到达一个就停下核对证据）：
- cp0：应用首页可见，出现 [底部导航文本]。
- cp1：页面标题为 [目标页面标题]，[入口按钮] 处于可点状态。
- cp2：输入框内出现 [预期文本]，[提交按钮] 从禁用变为可点。
- cp3：出现 [成功提示文本] 或结果页标题 [结果页标题]。

推进规则：
1. 每一步只做通往当前检查点的动作，不要提前执行后续步骤。
2. 做完一个动作后，先核对当前检查点的证据；证据不满足，不要继续往下点。
3. 如果页面出现与当前检查点不符的状态（例如跳到了其他页面、出现非预期弹窗）：
   - 优先尝试一次系统返回（返回键或页面返回按钮）；
   - 返回后核对最近一个已通过的检查点，例如 cp1；
   - 若证据重新出现，从该检查点的下一步重新执行；
   - 若连续多次无法回到该检查点，停止操作并输出当前页面文本，交由人工处理。

输出要求：每次重试后记录“重试前页面标题 / 执行的动作 / 重试后页面标题 / 是否回到检查点”。

其中“连续多次”建议在指令里写死一个具体次数，方便后续对照日志判断，而不是留给模型自己拿捏。返回动作优先用系统返回，是因为它比重新从头启动更接近“回退一步”的语义。

用一次故意误点验证检查点能否触发重试

指令写完不等于检查点生效，需要构造一次受控的偏离来验证：

1. 在到达 cp1 之后，让 MemGUI-Agent 点击一个通向无关页面的按钮，或点进一个同名的错误入口。
2. 观察它接下来的行为：是否先返回，再看当前页面标题，然后从 cp1 的下一步继续，而不是从头重启应用。
3. 记录返回动作是系统返回、页面返回按钮，还是重新启动；这三种在日志里的表现不同，出现的频率也值得留意。
4. 重复两次同样的误点，看结果是否一致。只有能稳定复现的返回，才算检查点真的被页面行为触发。

这一步只验证“机制是否触发”，不需要评价完成得多快。如果误点一次之后就彻底退不回来，说明检查点证据选得太模糊，或者指令里的返回条件写得不够具体。

记录每次重试前后的页面状态差异

只记“失败了一次”没有用，需要把重试前后的页面状态并排记下来。下面这张表可以直接作为日志格式，每次重试填一行；连续几行放在一起，就能区分是证据选错还是动作没执行。

读表的方式：如果重试后页面确实回到了预期检查点，但流程依然走不下去，通常问题出在检查点证据选得不对，需要换成更稳定的标题类证据；如果重试后页面根本没变化，那是返回动作本身没有被执行，要检查指令里的返回描述是否被正确理解和落地。两种问题的修法不同，不要混在一起改。

先搭好检查点再跑长程流程，代价是多花一点时间做拆分和验证；换来的是跑偏时有一个明确的回退位置，以及一份可以逐行比对的页面状态记录。页面结构变化后，建议重新跑一次上面的误点验证，确认检查点仍然成立。