浏览器工作流的编译与回放
浏览器工作流为什么值得程序化？
- 类比: 相当于电子表格的宏录制;
- 首次探索: 多模态 Agent 通过观察—思考—行动，寻找“撰写、收件人、主题、正文、发送”这些控件;
- 后续任务: 流程没有变化，只有收件人和内容不同，没必要再次调用模型从像素和 DOM 中重新发现整条路径;
- 产物: 把第一次探索产生的轨迹编译成一个带参数、状态检查和版本信息的小程序;
工作流的生命周期包含哪六步？
| 步 | 动作 | 关键内容 |
|---|---|---|
| 1 捕获轨迹 | 记录导航、点击、输入、下拉选择 | 保存动作参数、当时的 URL、XPath 与 CSS 等元素定位证据 |
| 2 参数化 | 把首次运行中的字面量识别为模板变量 | test@example.com、主题、正文替换为 {recipient}、{subject}、{content}，其余稳定动作不变 |
| 3 定义状态检查 | 为动作增加执行前检查与执行后检查 | 例如“发送按钮当前可见”；为整个工作流增加最终状态检查 |
| 4 独立回放验证 | 重置到独立初始状态后完整回放 | 执行前检查、执行后检查与最终状态检查全部通过才能发布 |
| 5 匹配与回放 | 按意图和关键词在能力库中寻找工作流，提取参数后由 Playwright 直接执行 | 回放路径不需要逐步调用 LLM，但仍需等待元素可用并完成所有状态检查 |
| 6 失效与重学 | 找不到目标元素、状态检查不通过、API Schema 改变或最终状态错误 | 回退到完整的 Agent 模式重新探索 |
- 定位信息的边界: XPath、CSS 只用于再次寻找元素，不能证明任务已经完成;
动作执行成功与任务成功有什么区别？
- 结论: 是两件事，动作执行成功不等于任务成功;
- 要求: 最终状态检查必须读取真实页面或后端状态;
- 危险假象: 系统很容易得到一种假象——每个按钮都点过了，但某个字段其实为空，任务从未真正完成;
程序化经验能带来多少加速？
- 观察: 这类程序在重复任务上实现了 8.5–13 倍的端到端加速;
- 机制: 回放阶段不需要逐步调用语言模型;
- 更重要的结论: 流程记忆必须同时具备动作前验证、动作后验证和独立回放验证;
流程记忆的真正价值是什么？
- 不是重复执行动作: 加速本身不是目标;
- 而是最终状态仍然正确: 必须确保任务的最终状态仍然正确;
- 必要条件: 可复用工作流必须有独立验证和失效机制;
- 否则: 加速只是把错误更快地重复;