EchoPath：GUI Agent 的记忆不是一段上下文，而是一条可重放的执行程序

GUI Agent 最容易被低估的成本，不是“不会点按钮”，而是已经做过的事情，下一次还要重新观察、重新规划、重新定位。企业里的表单更新、报表导出、资料搬运和桌面配置，往往不是一次性任务。每次都让模型从第一张截图开始推理，成功率可能还可以，成本和延迟却会随着步骤数一起增长。

EchoPath 试图把这个问题改成一个运行时问题：一次已经通过结果校验的 GUI 执行，能不能变成下一次可以直接调用的执行级记忆？

这篇论文的答案不是“把旧轨迹再放回 prompt”。它把轨迹整理成一个带任务意图、应用和状态前置条件、可变输入、视觉证据、验证来源和生命周期状态的记忆对象。新任务到来时，系统先判断这条记忆是否适用；只有当前状态兼容、目标能够被重新定位、需要变化的输入属于声明过的可变字段时，才跳过逐步规划和 grounding，直接重放。条件不满足，就拒绝重放，回到局部修复或普通规划。

论文是 Yao Zhao、Aditya Shanmugham、Swastik Roy 和 Yanxun Xu 的 arXiv 预印本，编号为 arXiv:2609.16635，提交时间是 2026 年 9 月 15 日。下文按论文正文和补充材料拆解；数字都保留实验口径，不把它们改写成“所有 GUI 任务都能复用”。

目录

1. EchoPath 到底要解决什么
2. 它把什么东西叫作记忆
3. 第一次执行：ActionLens 先把运行过程变成证据
4. 第二次执行：检索和门控先于重放
5. IBTR / IMTR：坐标不是目标，只是视觉证据
6. 生命周期：记忆不是写入后永久有效
7. 实验结果：省下来的到底是什么
8. 这篇论文证明了什么，没有证明什么
9. 对 GUI Agent 和自动化测试的启发
10. 总结

一、EchoPath 到底要解决什么

1.1 新任务需要推理，重复任务不该每一步都推理

典型的 GUI Agent loop 可以写成：

observe → plan → ground → act → observe → plan → ground → act

其中有两种开销经常被混在一起：

• 规划开销：模型根据任务和当前状态决定下一步做什么；
• grounding 开销：把“点击保存按钮”绑定成当前屏幕上的具体位置或控件。

新任务没有办法绕过这两步。问题在于，第二次处理同一类任务时，系统通常仍然把它当成新任务。即使有记忆模块，很多方案也只是把过去的轨迹、反思或工作流摘要取出来，再交给模型重新规划。记忆帮助了模型，但没有真正替代这次规划。

EchoPath 把目标收得更窄，也更工程化：它不试图让记忆解决所有 GUI 泛化问题，而是问一个可验证的问题——已经成功走过的动作序列，在当前桌面状态下能否被安全实例化？

1.2 三种常见复用方式，各自卡在哪里

复用方式	下次怎么用	主要问题
轨迹放回 prompt	让模型参考旧步骤重新计划	仍然要为每一步支付模型推理和 grounding 成本
原始 record-and-replay	原样执行旧坐标或脚本	窗口移动、分辨率变化、布局漂移后，旧坐标可能失效
Accessibility Tree 绑定	依赖系统暴露的控件节点	第三方桌面应用、Canvas 和不完整的可访问性树会留下盲区
EchoPath	先做状态兼容性判断，再重绑定输入和视觉目标	仍然依赖相对稳定的界面和足够区分度的视觉目标

这是论文在引言里建立的技术位置：EchoPath 既不满足于“记忆只是一段上下文”，也不接受“坐标脚本就是可复用程序”。它在两者之间加了一层可检查的执行边界。相关背景和对比见论文的 Introduction。

这里有一个容易混淆的地方：论文把这种接口形态类比成 MCP-style tool call，但这不是在说 EchoPath 已经实现了 MCP 协议。更准确的说法是，它把记忆包装成了类似工具调用的“有输入、有前置条件、有结果”的可调用对象。

二、它把什么东西叫作记忆

2.1 记忆单位不是一段对话，而是一条 episode

论文把可重放记忆写成：

$$m=(K_m,u_m,\Pi_m,A_m,\mathcal{E}_m,B_m,v_m,r_m,\ell_m)$$

这些字段分别表示：

字段	含义	重放时回答的问题
$K_m$	检索键和任务意图	这是不是同一类任务
$u_m$	应用或环境标签	当前打开的是不是同一个应用
$\Pi_m$	状态前置条件和预期效果	当前桌面是不是这条路径的起点
$A_m$	有序的动作程序	具体要执行哪些 GUI 原语
$\mathcal{E}_m$	每一步的截图、crop、坐标和状态证据	当前界面能不能重新绑定目标
$B_m$	可变输入绑定	哪些字段允许换成这次任务的值
$v_m$	外部工件校验证据	首轮结果是否真的成立
$r_m$	consolidation / reasoning 报告	这条路径为什么值得晋升
$\ell_m$	生命周期状态	这条记忆现在是否还能被默认检索

这个对象的关键不在字段多，而在它把三个决定分开了：

1. 首次成功的轨迹能不能成为记忆；
2. 新任务是否应该检索这条记忆；
3. 检索到以后，当前 GUI 是否允许安全重放。

很多“记忆失效”其实是把这三个问题压成了一个相似度分数。EchoPath 的门控设计让拒绝也变成一种正常结果，而不是系统异常。

2.2 固定动作和可变输入必须分开

如果任务是“把一份新的 CSV 导入桌面应用”，文件名可能变化，但打开应用、进入菜单、选择导入入口、点击确认这些步骤通常不应该被模型随意改写。EchoPath 因此把动作分成两类：

• fixed action：导航、聚焦、热键、等待、保存、结构性操作；
• flexible action：输入框中的 URL、文件名、表单值或搜索文本。

重放时只允许在记忆里声明过的 action_index 和 parameter_path 上替换值。一个没有声明为可变的字段，即使模型觉得它应该变化，也不能直接修改。

这条限制看起来保守，却是执行记忆能否审计的分界线。否则“复用旧流程”很容易退化成“让模型拿旧流程当灵感再写一遍新流程”。

三、第一次执行：ActionLens 先把运行过程变成证据

3.1 记忆的来源不是 agent 的私有日志

EchoPath 没有直接把 host agent 的思维链或 SDK 事件流当成记忆源。论文把 GUI 操作包在一个叫 ActionLens 的 controller-compatible wrapper 里。它保留底层本地或远程控制器的动作接口，但把真正触碰桌面的动作统一记录下来。

一次 action step 的记录包含：

• 动作原语和参数；
• 动作前、动作后的截图与观察；
• UTC 时间、耗时和执行器输出；
• 异常文本和错误状态；
• 逻辑屏幕尺寸、截图尺寸、鼠标位置；
• 截图区域和像素到 controller 坐标的比例信息。

补充材料还说明，运行会写出 manifest、action-step JSONL、standalone-observation JSONL、lifecycle-event JSONL 和截图资产。这样做的价值是：即使 host agent 的内部日志格式发生变化，重放层仍然有一份相对稳定的动作证据。

3.2 “点击成功”不等于“任务成功”

EchoPath 不会因为每个 GUI 原语都返回成功，就把整条轨迹晋升为 active memory。首次执行的结果还要经过外部 artifact evaluator。比如“导出报表”不能只看鼠标点击过导出按钮，而要检查目标文件或最终页面状态是否真的成立。

论文给出的晋升逻辑可以压缩成下面这段伪代码：

执行轨迹
  ├─ 有动作失败 / 不支持的原语
  ├─ 没有正向 artifact validation
  ├─ consolidation 报告不可晋升
  └─ 仍有 blocker
       → 留在仓库中用于诊断或修复
       → 不暴露给默认 replay retrieval

外部工件通过 + 路径可行
       → candidate
       → active memory

这个设计把“会运行”与“结果成立”分开。对于桌面自动化，后者往往才是业务真正关心的状态。

3.3 consolidation 不是简单截断轨迹

一次成功的探索过程通常包含试探点击、被覆盖的输入、无效移动和失败动作。consolidator 会选择一条保持顺序的成功子序列，删除探索性或冗余步骤，同时保留能准备状态的依赖，例如：

• 关闭首次启动提示；
• 处理登录或权限弹窗；
• 恢复被遮挡的菜单；
• 等待一个必要的状态转移；
• 获取后续输入所需的焦点。

截图和视觉 crop 会以 content-addressed blob 的方式单独保存，路径和动作节点只保留引用、尺寸、坐标框和来源运行 ID。这样既保留审计证据，也能让多个记忆复用同一份视觉资产，减少重复存储。

四、第二次执行：检索和门控先于重放

重放阶段的顺序很重要。EchoPath 不是先发出第一个点击，再看是否出错，而是先把候选记忆筛到足够窄，再逐步绑定动作。

4.1 第一层：按任务意图检索

补充材料中的检索流程大致是：

1. 对当前请求和记忆中的意图短语做大小写、空白和常见动词归一化；
2. 去掉常见功能词，把 save/store、find/search、replace/overwrite 等操作词归并；
3. 根据任务目标、调用方提供的意图短语、嵌套任务描述等字段构造查询；
4. 先用意图分数筛出候选，再加载完整 path 和 action-node 记录做兼容性检查。

论文给出了当前实现的两道阈值：第一阶段的 intent 过滤阈值为 $\lambda=0.18$，最终兼容性分数阈值为 $\theta=0.75$。这两个数是当前实现配置，不应该被理解成所有环境都适用的通用超参数。

4.2 第二层：compatibility gate

候选记忆还要通过多项 gate：

• 生命周期必须是 active；
• 任务类型和应用上下文要匹配；
• 首轮 artifact validation 必须为正；
• consolidation reasoning 必须认为路径可用；
• 动作原语必须是 replay 支持的；
• 任务意图要达到更严格的匹配条件。

应用标签的规则也比较克制：如果任一侧没有应用标签，允许继续；如果两侧都有标签，就要求归一化后的精确匹配。最终选中的记忆是通过所有 gate 且兼容性分数最高的候选；没有候选通过时，系统记录 miss 或 rejection，进入普通规划。

这一步是 EchoPath 和“从历史里找最像的一条轨迹”之间的差别。相似只是入场券，不能替代安全检查。

4.3 第三层：只绑定声明过的变化

重放时，路径上的导航、热键、等待和保存动作保持不变。只有 flexible_action_inputs 中声明过的字段可以被替换。论文在 50 个 active memories 上做了离线测试：

• 合法的柔性文本替换：50/50 接受；
• 修改固定、非柔性字段：50/50 拒绝。

这不是为了让系统“更聪明”，而是为了让记忆的修改面可见、可审计、可回归。

五、IBTR / IMTR：坐标不是目标，只是视觉证据

5.1 为什么不能直接缩放旧坐标

如果首轮在 1920×1080 的桌面上点击了 x、y，第二次把屏幕改成 1600×900，按比例缩放坐标是一个合理的 baseline，但它没有回答一个更重要的问题：窗口是否移动了？工具栏是否重排了？页面是否插入了一个新的控件？旧坐标附近是否出现了两个相似按钮？

EchoPath 的做法是把旧坐标当成“在哪里截 target crop 的线索”，而不是把坐标本身当成目标。记忆里保存 target、context 和 wide_context 等 crop 候选，并记录点击点在 crop 内的相对比例。重放时，用这些 crop 去当前全屏截图里找匹配位置，再把 crop 内的相对点击点换算成新的 controller 坐标。

5.2 算法流程

论文补充材料中的算法可以分成五步：

1. 把当前截图转换为匹配表示，默认是灰度；
2. 对每个存储 crop 按多个 scale 重采样，当前实现的范围是 0.5 到 2.0，步长 0.05；
3. 在当前全屏截图上滑窗，计算归一化相关性；如果 crop 太平坦，则改用归一化平方差；
4. 找到最高分候选 $\gamma^\*$，再找一个与它空间上不重叠的次高候选 $\gamma^{(2)}$；
5. 同时满足绝对分数阈值和差值阈值，才把点击点变换到当前 controller 坐标。

论文给出的当前配置是：

$$\gamma^\* \geq \eta,\qquad \gamma^\*-\gamma^{(2)}\geq \eta_{\mathrm{margin}},$$

其中 $\eta=0.78$，$\eta_{\mathrm{margin}}=0.02$。任一条件不满足，系统会在发出 pointer event 之前拒绝这一步。

这个拒绝条件非常关键。GUI 里最危险的不是“完全找不到目标”，而是“找到了一个看起来也对的目标”。重复列表项、相似图标和多处相同按钮，都会让单纯追求最高匹配分的算法误点。EchoPath 用 best-versus-second margin 把不确定性暴露出来，宁可回退，也不把低置信度坐标当成确定动作。

5.3 它不是通用视觉理解器

IBTR 的职责很窄：

• 它不根据自然语言发现一个从未见过的目标；
• 它不理解整个页面的业务语义；
• 它不负责把一个失败任务重新规划完；
• 它只判断一个已经成功使用过的视觉目标，当前是否还能被明确定位。

因此，视觉重瞄准和 grounding model 不是同一个层次的问题。前者可以减少已知路径上的定位调用，后者仍然负责新目标或回退路径。

还有一个需要在读论文时留意的命名细节：正文和摘要把模块写作 IBTR（image-based target-reaiming），补充材料 B.3 和 Algorithm 1 的标题又写作 IMTR（image-match target-reaiming）。本文用“IBTR / IMTR”并列标注，表示同一条目标重瞄准机制，不替论文掩盖这个术语不一致。

六、生命周期：记忆不是写入后永久有效

EchoPath 的 memory repository 更像一个小型版本库，而不是一个只增不减的向量表。

candidate
   ↓ artifact + reasoning gate
active
   ├─ replay 成功：累计复用证据
   ├─ 状态变化：branch / repair
   ├─ 等价路径：merge
   ├─ 风险或失效：quarantine
   └─ 过时或不安全：deprecate

几条工程含义值得单独拿出来：

1. 失败轨迹不会因为“有诊断价值”就自动变成可调用技能。 它可以留在仓库里，但默认检索只看 active 子集。
2. 修复应该产生 lineage。 新分支和旧路径之间要能追溯，不应该静默覆盖原记忆。
3. 过期不是物理删除。 deprecate 或 quarantine 之后仍然保留审计线索，方便解释为什么某条路径不再被调用。
4. 动作图和视觉资产分离。 路径可以共享 action-node 前缀和 content-addressed screenshot blob，减少重复存储并保留来源。

这也是 EchoPath 里比“Token 降了多少”更值得借鉴的部分：可执行记忆要有版本、证据和生命周期，否则它只是把旧错误保存得更久。

七、实验结果：省下来的到底是什么

7.1 实验不是一次随机抽样，而是 paired two-pass

主实验在 OSWorld-Verified 上采用 paired two-pass 设计：

• 第一轮：从新任务开始执行，形成候选轨迹并构建记忆；
• 第二轮：对同一批任务再次执行，测试记忆能否被召回、通过门控、完成参数绑定和视觉重瞄准。

为了避免“复制原坐标”带来的假重放，第一轮分辨率是 1920×1080，第二轮改成 1600×900。论文把这项变化作为反坐标复制的实验条件，而不是说真实生产环境只会发生这种分辨率变化。

主分析池包含 159 个 active executable memories。首轮任务保留 2–29 个 GUI action，多数任务为 4–13 步；首轮的 median token cost 约 572k，median execution time 约 4.5 分钟；consolidation 把约 30% 的探索步骤从最终记忆轨迹中去掉。

7.2 与 trajectory-prompt baseline 的对比

论文表 1 的第二轮结果如下：

方法 / 客户端	成功率	median tokens	median time
Codex + EchoPath	91.2%	20,370	127.5 秒
Claude Code + EchoPath	92.8%	30,503	139.3 秒
Kimi Code + EchoPath	87.3%	19,928	130.5 秒
Synapse + Codex	91.8%	586,386	315.7 秒

以 Codex 这一行和 Synapse baseline 的中位数粗算：

• token 消耗减少约 96.5%；
• 执行时间减少约 59.6%；
• 成功率低 0.6 个百分点。

这解释了摘要中“median token cost 降低超过 90%、median execution time 约降 60%”的说法。更准确的结论是：在这批已构建、已匹配、状态兼容的重复任务上，EchoPath 用确定性执行替代了大部分重复的模型调用，同时保持了相近的成功率。它不是在一个全新的任务集合上让模型凭空变强。

7.3 组件诊断比总成功率更能说明问题

论文还做了几组离线或半离线诊断：

组件	条件	结果
Retrieval	记忆库从 159 增加到 659 条，加入非目标轨迹干扰	正确召回率始终 100%
Retrieval	上述库规模变化	median lookup 208.9ms → 573.8ms
Target reaiming	原始截图，200 个 pointer cases	接受 95.5%，接受样本偏差 0 像素
Target reaiming	随机缩放，200 个 cases	接受 95.0%，94.0% 在 2 像素内
State gate	兼容起点	接受准确率 98%
State gate	已经过可选准备步骤的部分变化起点	接受准确率 92%
State gate	不兼容应用起点	拒绝准确率 78%
Flexible rebinding	合法柔性输入 / 非法固定字段修改	100% / 100%

这些数字揭示了两个不同的事实。

第一，目标重瞄准在受控的视觉诊断里很准，但它仍然会在重复控件和近似控件处拒绝。拒绝不是实验失败后的补救，而是算法设计的一部分。

第二，state gate 的“接受兼容起点”表现明显好于“拒绝不兼容起点”。78% 的不兼容拒绝准确率说明，单个视觉 probe 对通用桌面控件还不够；如果把 gate 错误地当成绝对安全证明，风险会被掩盖。

八、这篇论文证明了什么，没有证明什么

8.1 它确实证明了三件事

第一，GUI 记忆可以落到执行层。 记忆不必只作为 prompt 上下文存在；在有明确的任务、状态、输入和验证证据时，它可以成为一条可实例化的 action program。

第二，坐标重放可以被视觉证据约束。 旧坐标不需要被完全信任，也不需要每次都交给大模型重新定位。target crop、scale search、best-versus-second margin 和屏幕坐标变换构成了一个确定性的中间层。

第三，拒绝和回退应该是正常分支。 状态不兼容、固定字段冲突、动作不支持和目标歧义都可以在发出危险动作前被拒绝。

8.2 它还没有证明四件事

它没有证明对广泛 UI 漂移都稳健。 论文自己把适用环境限定在应用版本、窗口系统、浏览器 profile、字体、主题和软件配置相对稳定的场景。工具栏重排、本地化、响应式布局、显示缩放和近重复控件仍然会影响视觉重瞄准。

它没有证明企业规模下的长期治理成本。 检索压力、局部存储和生命周期结构做了诊断，但还没有展示长时间运行、多人并发写入、隐私隔离和组织级回收策略。

它没有让记忆获取变便宜。 第一轮仍然需要 agent 从任务说明开始完整探索，可能包含失败动作和冗余尝试。论文把交互式示范、用户引导录制和增量 consolidation 列为后续方向。

它没有证明“代码已经可以直接复现”。 论文正文写的是“OpenPath package is provided at”并给出 github.com/JackZhao1998/EchoPath；我在 2026-09-21 发布前检查该地址时返回 404，因此本文没有把它当作可用源码或复现实验入口。这里也要把论文命名中的 OpenPath / EchoPath 不一致记录下来。

九、对 GUI Agent 和自动化测试的启发

9.1 把记忆写入当成一次发布，而不是一次缓存

如果把 EchoPath 的思路迁移到自己的 agent runtime，最值得照搬的不是某个相似度公式，而是写入门槛：

raw trajectory
  → normalized action evidence
  → external outcome validation
  → consolidation
  → active / quarantine / deprecated

这条链会让 memory write 变慢，但能避免“任何成功调用过的工具都自动变成技能”。对于 GUI，动作原语执行成功只是局部事实，最终工件状态才是任务事实。

9.2 让 replay 和 repair 使用同一个动作边界

ActionLens 的工程价值在于，首次规划、重放、局部 grounding repair 和最终校验都经过同一层 controller-compatible action boundary。这样可以统一记录：

• 计划动作和真正执行的动作；
• before / after 截图；
• 目标坐标和坐标变换；
• 失败类型、耗时和执行器输出。

如果 replay 使用一套接口、repair 使用另一套接口，最后很难判断失败来自记忆、grounding 还是底层控制器。

9.3 测试框架可以直接借用 fixed / flexible 的分法

在 APP 或桌面自动化里，同一个测试流程往往既有固定导航，也有随 case 变化的测试数据。把所有参数都暴露给模型，会让回放变成一次不可控的重新规划；把所有参数都锁死，又无法复用。

更稳的做法是把测试动作拆成：

• 固定：进入页面、关闭弹窗、选择菜单、提交和保存；
• 可变：账号、文件名、搜索词、表单值、日期或 URL。

然后在测试报告里记录“这次替换了哪些参数”，而不是只记录整条脚本最终跑没跑通。参数边界本身就是可审计的测试资产。

9.4 失败要分成“局部可修”和“任务已不适用”

EchoPath 把失败拆成两层：

• 局部 grounding failure：任务和路径仍然合理，只是当前这个目标没有被确定地绑定；
• 结构性 failure：应用、起点、固定参数、动作能力或后置状态已经不再匹配。

前者可以给一个受限的 repair operator，后者要回到普通规划。这个区分对自动化测试同样有用：按钮位置漂了和被测流程改版，不应该进入同一个重试队列。

十、总结

EchoPath 的核心贡献可以压缩成三句话：

1. 写入端：只有通过外部工件校验的 GUI 轨迹，才有机会成为 active memory；
2. 读取端：先检索和做状态兼容性门控，再做声明过的参数重绑定与视觉重瞄准；
3. 执行端：确定性重放失败时，拒绝发出不确定动作，转入局部修复或普通规划。

这条路线的价值不在于让 GUI Agent 永远不再思考，而在于把“什么时候可以不思考”变成一个有证据、有边界的运行时判断。论文目前最有说服力的结果，是在受控重复任务上用相近的完成率换来了更少的模型调用和更短的执行时间；它最需要继续验证的地方，则是界面漂移、长期记忆治理、隐私和首次采集成本。

如果把 agent memory 看成“经验”，EchoPath 给出的更准确说法是：经验只有在被校验、被参数化、被门控并且能够安全落到当前界面时，才配叫作可执行记忆。

参考资料

• EchoPath: Execution-Level Replayable Memory for GUI Agents
• EchoPath 论文 HTML 全文
• OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments