← 返回资料站  /  Continuous Learning
论文 程序性记忆

Agent Workflow Memory

AWM:从成功轨迹中归纳可复用工作流的 agent 记忆
一句话CMU 提出 Agent Workflow Memory(AWM):让 web agent 从成功轨迹中用 LLM 归纳出抽象化的子任务工作流(workflow),写进 prompt 记忆里指导后续任务,在 Mind2Web / WebArena 上相对基线提升 24.6% / 51.1%(WebArena 35.5% SR,当时最好的公开结果),且平均步数还更少;但 WebArena 数字后来有第三方复现不出来(issue #12)。

这是什么

背景是 2024 年的 web agent 普遍处理不好长程任务:每个任务从零开始规划,同一个网站上反复出现的子流程(比如"在购物站搜一个商品""在地图上定位一个地点")每次都要重新摸索。人类的做法是把过去经验沉淀成可复用的例程(routine),下次直接套用。AWM 就是把这件事机械化:从过去的任务轨迹里归纳出 workflow,作为程序性记忆注入 agent。

一个 workflow = 一句自然语言的功能描述 d + 一串步骤,每步含环境状态描述、推理、可执行动作;关键设计是把实例相关的具体值抽象掉("dry cat food" 换成 "{product-name}"),让它跨任务可复用,粒度刻意压到子任务级而不是完整任务级。归纳本身就是拿 LLM prompt 一下,没有训练。

AWM 有 offline 和 online 两种用法:offline 是有标注训练轨迹时,先批量归纳好 workflow 再在测试时全部塞进 memory;online 是完全没有训练数据,agent 流式处理测试 query,每做完一个任务用一个 LM judge(沿用 AutoEval)判断成败,成功的轨迹就地归纳成 workflow 加进 memory,供后面的任务用——这是论文里更有意思的"边测边学"设定。发表于 arXiv 2024-09(后收录于 ICML 2025),Semantic Scholar 引用 247。

AWM 主流程:agent 在环境中执行任务得到轨迹(Step 1),LM judge 判断任务是否解决(Step 2),成功轨迹被归纳成 workflow——一句功能描述加上抽象化的步骤序列(环境描述/推理/动作,具体值换成 {id} 这类占位符)——写回 memory(Step 3),失败轨迹直接丢弃。
AWM 主流程:agent 在环境中执行任务得到轨迹(Step 1),LM judge 判断任务是否解决(Step 2),成功轨迹被归纳成 workflow——一句功能描述加上抽象化的步骤序列(环境描述/推理/动作,具体值换成 {id} 这类占位符)——写回 memory(Step 3),失败轨迹直接丢弃。

机制与做法

Workflow 的归纳与表示

归纳模块 I 就是一个 prompt:把一条或多条成功经验(指令 q + 轨迹 (o, a) 序列)喂给 LLM,要求它抽取跨任务复用的公共子例程,并把实例特定值替换成占位符。模型输出按空行切分成多条 workflow,分别存入 memory(实现上就是拼进 system prompt / 上下文)。附录里还试了纯规则的归纳(按公共前缀合并),效果与 LM 版接近(WebArena 35.6 vs 35.5)。

每条 workflow 带 NL 描述 + 步骤轨迹,步骤里保留了推理句("Order {id} is found, I will now terminate"),相当于给 agent 一份带注释的可执行 SOP,而不是死板的宏。论文强调这种抽象表示比 Synapse 那种检索完整具体轨迹的做法偏差更小:Mind2Web 上 element accuracy 比 Synapse 高 5.0。

WebArena map split 上 online AWM 的累积成功率曲线:前 40 个例子内快速学会基础 workflow(按名字找地点、查坐标),之后在其基础上自举出更复杂的 workflow(查邮编、算驾车时间),与基线差距拉大到 22.5 个点。
WebArena map split 上 online AWM 的累积成功率曲线:前 40 个例子内快速学会基础 workflow(按名字找地点、查坐标),之后在其基础上自举出更复杂的 workflow(查邮编、算驾车时间),与基线差距拉大到 22.5 个点。

Offline vs Online 两种流程

Offline:把某网站的全部训练样例拼成一个 prompt 一次性归纳出 workflow 集合,测试时对每条指令都用同一份 workflow memory。适合有高质量标注、且训练/测试分布一致的场景。

Online:memory 从空(仅内置动作文档)起步,逐条处理测试 query;每条轨迹先过 LM-based 二分类评估器判成败,判成功的才归纳入库,memory 单调增长。这个设定不需要任何标注,但也意味着两处噪声:LM judge 会误判,错误轨迹会被归纳成错误 workflow(论文自己承认这会拖低表现)。WebArena 主实验用的正是 online 模式,按网站分五个 split 各自跑。

一个亮点观察:workflow 会自举式变复杂——先学会 "Find a place by its name",后面遇到查邮编的任务时复用前几步再接新步骤,归纳出 "get the zip code of a place"。学习曲线也很陡:WebArena map split 上前 40 个例子内成功率快速爬升,之后趋稳,与基线的差距拉大到 22.5 个点。

实验设置与对照

WebArena(812 任务、5 个网站):AWM 总 SR 35.5%,比 BrowserGym 基线(15.0)高 12.0 个绝对点、相对提升 51.1%,也比用人工手写 workflow 的 SteP(33.0)高;平均步数 5.9,比基线少 2 步,比要反复自我修正的 AutoEval 少 40.8 步。针对"WebArena 很多任务来自同一模板、workflow 是不是只在模板内起作用"的质疑,作者抽了每模板一例的 cross-template 子集重跑,AWM 33.2 vs 基线 20.5,说明泛化不完全靠模板重复。

Mind2Web:offline 模式下 gpt-4 的 step SR 45.1(MindAct 36.2),但注意任务级 SR 绝对值都很低(AWM 4.8% vs MindAct 2.0%)。跨分布测试里 online 模式优势随 train-test 差距增大而扩大:cross-domain step SR 35.5 vs MindAct 18.6(+16.9),因为 online 根本不依赖训练分布。

关键结果

实证核查

有水分方法本身简单干净、代码全开源,Mind2Web 结果有第三方复现成功;但 WebArena 的头牌数字(35.5%,Reddit split 50.9)有第三方按默认代码复现只得到 20-35%,作者归因于 OpenAI checkpoint 更替和环境不稳定,issue 关闭时并没有人贴出成功复现——这个 SoTA 数字对模型版本和环境状态相当脆弱。
WebArena 35.5% SR、Reddit split 50.9,为当时最佳公开结果。
repo issue #12(Reproduction Issue on WebArena):复现者未改代码,Reddit 只跑出 30-35%(gpt-4o 最新 checkpoint),换成作者建议的 gpt-4o-2024-05-13 后反而约 20%,还遇到 WebArena 环境本身的发帖限制报错(web-arena-x/webarena#120)。作者回复"更新的 checkpoint 会显著劣化表现"并贴了自己的轨迹,但 issue 关闭前无人报告复现成功。同一位复现者明确说 Mind2Web 结果复现成功了。
AWM online 是 supervision-free 的,只需要测试 query。
严格说不算无监督:它依赖 AutoEval(pan et al. 2024)的 LM judge 判断轨迹成败(method.tex §3.3),judge 误判会把失败轨迹归纳成错误 workflow,论文 Mind2Web 分析部分自己也承认这会降低表现。另外 WebArena 的 online 评测是按网站流式跑完整个测试集,memory 在测试集内部持续增长,前面任务的成功会直接帮到后面同类任务——好在作者用 cross-template 子集实验(33.2 vs 20.5)部分回应了这一点。
README 宣称 "state-of-the-art result -- 35.6% success rate"。
35.6 其实是论文正文表格里被注释掉的规则归纳变体(AWM_rule)的数字,正式上表的 LM 版是 35.5(source/sections/results/webarena.tex 第 25-26 行);差别很小,但 README 挑了两者中更高的那个。另外注意这是 2024 年 9 月的 SoTA,WebArena 榜单此后已被大幅刷新。
代码开源,webarena/ 和 mind2web/ 两个目录可一键复跑。
代码确实全在(Apache-2.0,463 stars,持续维护到 2025-12),但工程质量一般:issues 里一串路径/文件缺失问题(#6、#7、#19 找不到 workflow/shopping.txt 和 scores_all_data.pkl,#16-#18 参数名和文档 typo),大多已修复关闭;跑 WebArena 还需自己搭 docker 环境,成本问题见 issue #1。

与我们方向的关系

对 continual-learning 方向,AWM 是"程序性记忆"最干净的参照实现:不动权重、不训练,纯靠 prompt 级的归纳-写入-复用循环实现测试时的持续学习,而且给出了记忆条目该长什么样的具体答案——子任务粒度、变量抽象化、带推理注释的步骤序列。它和 Voyager 的 skill library 是一个谱系,但把技能从可执行代码换成了 NL workflow,归纳来源从自我探索换成了成功轨迹。

可借鉴的点:(1) online 模式的"LM judge 过滤 + 只从成功经验归纳"是记忆质量控制的最小可行方案,但 judge 噪声是明确的失效模式,做实验时值得量化;(2) cross-template 子集实验是回应"记忆增益是否只是测试集内部泄漏"质疑的好模板,我们做经验积累类实验时应该照做;(3) 复现教训:这类依赖闭源 API 的 agent 结果对模型 checkpoint 极其敏感,报数字必须钉死模型版本,隔一年就可能复现不出来。

阅读笔记

论文源码是 ICLR 2025 模板但最终录用在 ICML 2025(S2 venue 显示 ICML)。WebArena 主表标注用 gpt-4,而作者在 issue #12 里让复现者用 gpt-4o-2024-05-13,两处口径值得留意。memory 只增不删,论文没有讨论 workflow 冲突或过期的处理——在更长的持续学习时间尺度上这会是问题。

材料清单

TeX 源码
已存档:Raw/agent-workflow-memory/source/
代码仓库github.com/zorazrw/agent-workflow-memory
463★ · 最近推送 2025-12-22
复现讨论github.com/zorazrw/agent-workflow-memory/issues/12
第三方 WebArena 复现失败的完整讨论,含作者提供的参考轨迹链接
评估器arxiv.org/abs/2404.06474
AWM online 依赖的 AutoEval LM judge(Pan et al. 2024)

同类条目