跨应用长程操作中断，排查顺序建议是“先看记忆、再看等待”：切换应用那一刻，上一步的关键信息有没有被写进可读的记忆字段；下一步动作发出时，目标页面是否已经进入可操作状态。这两件事都能通过会话记录、日志和页面行为验证，不需要靠猜。一个常用的判断依据是——单跑某个应用正常、串起来才失败，多半是等待不足读到了旧页面；串联后字段丢失或串味，多半是记忆写入被截断或覆盖。

若断点只出现在跨应用串联阶段，先怀疑页面等待不足：点击之后立刻取页面内容，读到的往往是中间跳转页或上一个应用的旧页。若单跑正常、串联后账号、金额、订单号对不上，先怀疑记忆写入被截断。处理方向是给每次应用切换补一个“记忆快照 + 页面就绪证据”的确认点，验证方式用单跑与串联结果对比。具体等待时长和字段范围需要结合目标应用的加载特性确认。

在会话记录里确认跨应用时记忆是否被截断

先把记忆里你真正依赖的字段固定下来，通常包括：账号标识、金额、收货地址、订单号。这些字段在应用 A 里产生，在应用 B 里被读取，一旦被截断，后续步骤就会出现“值变空”“值还是上一条”“值被新页面的同名元素覆盖”三种表现。

做法是在切换应用前后各打一次记忆快照，而不是只在任务结束时打印完整上下文。下面是一段通用骨架，字段名按你的实际记忆结构替换，放在切换动作的两侧执行：

def log_memory_snapshot(tag, memory):
    keys = ["account", "amount", "address", "order_id"]
    snap = {k: memory.get(k) for k in keys}
    logger.info("MEM[%s] %s", tag, json.dumps(snap, ensure_ascii=False))

log_memory_snapshot("before_switch_A_to_B", memory)
switch_app("B")
log_memory_snapshot("after_switch_A_to_B", memory)

跑完后用 grep "MEM\[" run.log 按时间顺序看两行快照：某字段从有值变 None，说明写入没落盘或被后续步骤清空；字段值在两个应用之间发生串换，说明新页面的元素被误当成旧字段来源。需要结合环境确认的一点是，有的框架把记忆写在会话级、有的写在任务级，作用域不同，重启后表现也不同。

对比两个应用页面加载耗时差异

页面等待不足的典型信号是：下一步动作能执行、也能拿到元素，但拿到的是中间页或旧页的内容。要判断这一点，建议每次切换时记录两类页面状态：中间页面（加载提示、闪屏、跳转中转页、同一应用的二级页）和最终页面（你真正要操作的页面）。

记录方式不必复杂，在等待函数里把每次探测到的页面标题和关键元素文本打出来即可：

def wait_ready(page, is_ready, timeout=30, interval=0.5):
    elapsed = 0
    seen = []
    while elapsed < timeout:
        title = page.title()
        if title not in seen:
            seen.append(title)
            logger.info("PAGE_SEEN %s", title)
        if is_ready(page):
            logger.info("PAGE_READY %s", title)
            return True
        time.sleep(interval)
        elapsed += interval
    logger.warning("PAGE_TIMEOUT seen=%s", seen)
    return False

把两个应用各自的 PAGE_SEEN 序列拉出来对比：如果应用 B 的序列明显更长，或者“就绪”判定条件写得过松（例如只要页面有 body 就算就绪），那下一步很可能在旧页面上发出。判定条件要落到具体证据上，比如应用 B 的页面标题或某个只在详情页出现的按钮文本。

检查任务指令是否要求等待固定时间

很多中断来自指令里写死的“等待 3 秒”“sleep 5s”。固定等待的问题不是一定错，而是它同时做两件事：在加载慢的环境里掩盖加载差异，在加载快时造成无谓停顿，而且它无法告诉你是哪一步读到了旧页面。

建议先把指令里的等待条件找出来，逐条改写成“等待具体页面证据”：

改写时保留一个上限超时，避免真正卡死。超时后要打日志而不是静默重试，否则断点会被掩盖成偶发。

用短任务叠加成长任务观察断点位置

偶发中断想复现成可定位的步骤，可以用“分—合”的办法：先只跑应用 A 的任务，再只跑应用 B 的任务，最后把两者串起来跑同一批输入。对比三轮的失败位置，通常能区分是哪个环节引入的。

1. 单跑 A：确认 A 内部记忆写入和页面等待都正常，记录 A 结束时关键字段的值。
2. 单跑 B：用手工构造的输入直接喂给 B，确认 B 自身不依赖 A 的上下文也能跑通。
3. 串联 A→B：对比 A 结束时的字段值与 B 开始读取时的字段值是否一致，并对比页面就绪日志的时间点。

如果断点只在第三轮出现，且两轮单跑都正常，问题基本落在切换环节——要么记忆没传递，要么 B 的页面还没就绪。这个对比不依赖任何性能指标，只依赖日志的时间顺序，属于可核验范围。

给跨应用步骤加入显式确认动作

与其在每个动作前加更长的等待，不如在每次切换应用后加一个显式确认动作：确认页面已经就绪，再执行下一步。确认动作要落在具体证据上，比如页面标题、只在目标页出现的关键按钮文本、或者一个业务字段已经可见。

def confirm_on_page_b(page):
    title_ok = "订单详情" in page.title()
    btn_ok = page.exists("text=确认收货")   # 换成目标页独有元素
    if not (title_ok and btn_ok):
        raise RuntimeError("not on page B yet: %s" % page.title())

switch_app("B")
wait_ready(page, lambda p: "订单详情" in p.title(), timeout=30)
confirm_on_page_b(page)
# 确认通过后再执行下一步动作

确认失败时不要直接重试整个任务，先把当前页面标题和记忆快照打出来，再决定是补等待、修记忆写入，还是调整元素定位。需要结合环境确认的是：有的应用会先渲染旧缓存再刷新，这种情况下确认动作要放在刷新之后，而不是页面一出现就判定就绪。