MemGUI-Agent 中途不认路，先别急着调记忆窗口大小。这两类成因的排查顺序建议反过来：先看第一次偏离目标的动作，再看当时页面上的关键文本和等待时长，最后才去翻记忆层。页面改版和加载不足这两种情况，表面表现和记忆断裂很像，但需要修改的地方完全不同——前者要改定位方式，后者要改等待或重试策略，记忆层可能根本没坏。

如果偏离动作和上一步落在同一个页面、同一个控件上，且回放里上一步的页面摘要是完整的，优先怀疑控件文本或加载时机变了；如果上一步摘要缺失，或下一步动作引用的元素名称来自更早的页面，才更像记忆没续上。可以按回放定位偏离点、等待时间对照重跑、任务两段拆分这三步依次做，通常能定位到具体是哪一层出的问题，不必先改记忆策略。

在任务回放里定位第一次偏离目标的动作

回放里逐条对照原始目标描述，找第一个「本应做 A、实际做了 B」的步骤。偏离动作的判定标准通常是三条之一：点到了与目标无关的元素、对同一元素重复点击两次以上、或者动作指向的元素在当前页面根本不存在。把偏离动作前最后一条正确操作单独标出来，连同它当时的页面标题、关键文本、等待耗时一起记下来。这条记录是后面所有对比的基准。

多数框架会把每步写成一行的结构化记录，字段名按实际替换即可：

{"step_id": 14, "action": "click", "target": "提交订单",
 "page_title": "订单确认", "page_digest": "...",
 "wait_ms": 800, "step_elapsed_ms": 1200}

用 jq 之类工具把偏离点前后几步单独拉出来看：

jq -c 'select(.step_id >= 12 and .step_id <= 20)
  | {step_id, action, target, page_title, wait_ms}' replay.jsonl

重点不是看它报了什么错，而是看第 14 步的 target 名称，和第 13 步页面摘要里列出的可操作项对不对得上。

对比前后页面控件文本是否发生改动

把原任务依赖过的控件名逐一列出来——按钮、输入框的 placeholder、列表项的文案、菜单项，都算——然后到当前页面里一个个查。排查范围不要只限「存在与否」，还要看三件事：文本是否改了字（比如「提交」变「确认提交」）、可交互角色是否变了（按钮变成链接、可点区域被包在内层元素里）、以及是否多了一层折叠或懒加载。

一个可直接改的检查骨架，替换成你实际用的浏览器自动化接口：

# 通用骨架，query_selector 换成你的库
names = ["提交订单", "收货地址", "确认支付", "返回"]
for n in names:
    el = page.query_selector(f"text={n}")
    print(n, "找到" if el else "缺失或已改名")

如果某个名称在当前页面查不到，但页面上有个意思相近的新文案，基本可以判定是页面改动导致定位失效，而不是记忆问题。这时更稳的做法是把定位从「精确文本」放宽到「角色 + 部分文本」，或者直接把新文案写回任务配置，而不是去调记忆窗口。

检查 MemGUI-Agent 是否保留上一步的页面摘要

在任务记录或界面状态里找到每一步的页面摘要字段，常见命名是 page_summary、page_digest、visible_actions 之类。核对两件事：上一步摘要里有没有列出下一步要操作的元素；下一步动作的 target 是不是直接引用了摘要中的条目。

如果字段命名不明确，可以用哨兵法反过来验证：在某一步的页面上写入一个本次运行唯一的随机串（放在不会被业务逻辑覆盖的只读文本区域），然后看下一步的摘要里有没有带上这个串。带上，说明页面的可见信息确实被提取并传下去了；没带上，说明摘要生成或传递链路断了，这属于记忆层问题。哨兵串只能证明当次链路状态，换一次任务要重新放。

用相同起点重跑任务，只改变页面等待时间

保持任务起点、初始数据、操作序列完全一致，只改等待策略，跑两次做对照。第一次用默认配置，第二次把等待调大或改成条件等待，其余不动。

# 第一次：默认等待
agent:
  step_wait_ms: 800
  wait_for: null

# 第二次：只改等待，其他配置保持原样
agent:
  step_wait_ms: 5000
  wait_for: "target_visible"

具体数值按你自己观察到的页面加载上限来定，不要照搬。比较两次跑下来第一次偏离目标的 step_id：如果第二次偏离位置明显后移、或者干脆不再偏离，问题主要在加载时序上，把固定等待换成「等目标元素可交互」通常更稳；如果两次都停在同一处，等待时间就不是主因，回到前两节继续查控件文本和摘要。

把任务拆成两段，观察记忆跨段是否生效

拆分点选在偏离之前最近的一个稳定页面，例如列表页、提交成功页或首页。第一段跑到这个页面为止，结束时记录页面证据：URL、页面标题、关键可见文本、列表条目数或当前选中项。第二段从这里启动，先不把第一段的上下文带过去，只用一句话描述起点，看它能否正常继续。

三种结果对应三种判断：第二段不带上下文也能走通，说明原来的问题是跨段上下文丢失，属于记忆在段间没续上；第二段必须重新补全上下文才走通，说明段内记忆本身也在丢，需要检查摘要生成；两段都不带上下文时都失败，且页面证据和第一段结束时不一致，那就不是记忆问题，而是拆分点之后的页面已经和第一段结束时不同。每段的结束证据都要落盘，否则跨段对比没有基准。