site-memory 上手：别让浏览器 Agent 每次都从零摸网页

浏览器 Agent 最浪费 token 的地方，往往不是“打开网页”本身，而是每次都像第一次来一样：先观察页面、猜按钮含义、试筛选器、点错一个弹窗、再回头修正路线。同一个后台、同一个报表页、同一个下单流程，昨天已经摸清楚了，今天换个会话又从头摸一遍，这事挺亏。

site-memory 抓住的就是这个缝隙。它不是新的浏览器控制框架，也不是给 Agent 加一个万能长期记忆库。它更窄、更实用：把“这个网站怎么走、哪些选择器稳定、哪里容易踩坑、哪些动作需要人工确认”沉淀成少量站点笔记。下次 Agent 再进同一个网站，先读几条强相关笔记，再去现场验证，少走弯路。

这类东西看着小，实际很关键。Agent 能不能长期干活，不只看模型多聪明，还看它能不能把每次探索变成下一次的资产。没有这层，浏览器自动化就像天天新员工入职；有了它，至少老路不用天天重走。

site-memory 解决的是“重复网页探索成本”，不是“把所有东西都记下来”。

它的工作边界很清楚：

这和普通对话记忆不是一回事。普通记忆可能记住“用户偏好”“项目背景”“长期事实”；site-memory 更像浏览器 Agent 的站点作业本，记录的是“这个站的登录入口在哪、报表按钮藏在哪、列表分页怎么翻、哪个按钮看着能点但没用”。

官方 README 给的定位也很直接：浏览器自动化 Agent 在同一网站上会反复摸索页面结构，site-memory 让它记住访问过的网站，下一次直奔目标。在 WebVoyager benchmark 上，项目给出的结果是成本降低 70% 到 90%，速度提升 4 倍以上，准确率不下降。

这个数字不用神化。真正值得看的是方向：Agent 工作流里，页面结构、交互路线、失败经验都应该成为可复用资产，而不是每次都烧上下文重新推理。

site-memory 特别适合结构相对稳定、任务反复出现的网站。

比如：

它不适合这种场景：

说白了，site-memory 记的是“路书”，不是“钥匙”。路书可以帮 Agent 少绕路；钥匙、会话和权限还是要按安全边界管住。

site-memory 本身很轻，但要跑得稳，先确认三件事。

第一，Node.js 版本。官方要求 Node.js 22+。我本地验证脚本时，Node 22 可以正常初始化 runtime、生成 recall 输入。

第二，你的 Agent 运行时要能加载 Skill。README 里提到 Claude Code、Codex、OpenClaw、Gemini CLI 等都可以让 Agent 自己安装，也可以手动把 skills/site-memory/ 复制到对应 skills 目录。

第三，你要有一个浏览器控制工具。site-memory 不负责真正点页面，它只负责记忆循环。浏览器控制可以用它内置的 Chrome DevTools Protocol skill，也可以搭配 browser-use、Playwright MCP、Claude in Chrome，或者任何能导航、读取页面、点击输入的工具。

这点很重要：不要把 site-memory 当浏览器自动化框架。它不替代 browser-use，也不替代 Playwright MCP。它更像浏览器工具前面的一层“站点经验检索”和后面的一层“复盘写回”。

最快方式是让支持 Skills 的 Agent 自己装：

如果你的环境里能用 Skills CLI，可以直接：

手动安装也不复杂：

然后复制 skill 目录：

Gemini CLI 或其他 Agent 运行时，把目标目录换成对应的 skills 目录即可，例如：

或者放到项目级目录：

项目里还带了一个可选的 CDP 浏览器控制 skill，作为 git submodule：

所以如果你准备使用它内置的 CDP 工具，clone 时要带 --recurse-submodules。如果你本来就用 browser-use 或 Playwright MCP，那这个 bundled CDP 只是可选项。

site-memory 默认把运行时记忆放在：

可以用环境变量覆盖：

也可以每次命令传 --runtime-base：

初始化后，目录里至少会有一个 INDEX.md。官方 SKILL.md 里把 runtime 结构设计得很克制：

INDEX.md 只做短索引，不应该塞长篇正文。真正的站点知识放在 topic 文件里，并用 frontmatter 标明类型。

site-memory 支持四类笔记：

这套分类比“全部扔进一个 memory.md”靠谱。浏览器自动化最怕记忆变成垃圾桶，笔记一多，Agent 还没打开网页就先被旧信息带偏。

安装后先进入 skill 目录：

初始化 runtime：

输出会包含 memoryRoot 和 indexPath，类似：

第一次访问一个网站时，记忆里通常没有任何东西。仍然建议先跑 recall 输入，因为这会把标准流程固定下来：

如果是新 runtime，manifestCount 会是 0，index 也为空。没关系，这代表 Agent 应该直接用浏览器工具探索页面。

完成任务后，再做写回。官方流程里是用：

它会生成一个 after-action prompt，要求 Agent 根据最近若干消息提炼可复用知识，只允许写 memory root 里的文件。这个设计挺关键：写回不是把整个浏览记录倒进去，而是让 Agent 做一次“复盘压缩”。

第一次任务如果只是随便看一眼网页，可能不值得写；如果发现了稳定入口、分页模式、表格选择器、导出按钮位置，就应该写。

假设 Agent 第一次跑一个图书示例站，发现分页和标题选择器比较稳定，可以写成这样：

这条笔记有几个好点。

它没有保存整页 HTML，没有保存一次性结果，也没有写“今天我拿到了 20 本书”。它保存的是下一次能少走路的结构事实：URL 模式、选择器、坑点、成功路径。

如果是企业后台，笔记也应该这样写，只记录稳定路由和交互方式，不保存客户姓名、订单号、邮箱、token、cookie。

下次再做相关任务，先跑：

脚本会输出几块内容：

这里不要让 Agent 把全部笔记都读一遍。正确做法是让它根据 selector prompt 选最多 5 个最相关文件。比如只选：

然后读取选中的文件：

拿到笔记后也不能盲信。页面可能改版，按钮可能换文案，选择器可能漂移。Agent 应该先做一次现场验证：打开目标页，确认路由还通、选择器还有结果，再继续执行。

这就是 site-memory 设计里很成熟的一点：记忆是线索，不是真理。它减少探索，不取消验证。

site-memory 可以搭配不同浏览器工具。最小心智模型是这样：

如果用内置 CDP skill，官方 SKILL.md 里给了一组命令入口，都是通过 scripts/cdp-proxy.mjs 调用：

如果你用 browser-use，那 site-memory 只负责在任务前给 Agent 提供站点笔记，真正的页面操作仍然交给 browser-use。

如果你用 Playwright MCP，也是同理：任务前 recall，任务后 distill，中间仍走 Playwright MCP 的浏览器能力。

真正要避免的是把 site-memory 写成又一层“自动点击封装”。每多一层封装，就多一个不透明故障点。site-memory 的价值不在封装动作，而在把“上一次怎么走通的”变成下一次能用的线索。

浏览器 Agent 一旦进入真实后台，风险就不是“会不会点错按钮”这么简单。它可能看到客户数据、财务数据、内部工单，也可能拥有导出、发送、修改、删除权限。

所以 site-memory 的 runtime 最好按环境隔离。

个人测试可以用默认目录：

公司项目建议分开：

生产后台再单独隔离：

如果多个项目共用一份全局记忆，Agent 可能把 A 系统的经验带到 B 系统里。轻则无效，重则误操作。尤其是后台产品常有相似按钮，比如 Export、Archive、Deactivate，看着一样，语义差不少。

顺手提一嘴，如果你打算让浏览器 Agent 长期跑后台任务，最好准备一台独立实验机，不要和生产服务、个人主力电脑混在一起。像 site-memory 这种站点经验层，本身不重，但它通常会搭配 Chrome、MCP、Playwright、日志和各种自动化脚本。雨云这类轻量云服务器适合做这种隔离环境：重装快，成本低，翻车也不会波及主业务。

官方 memory-phrasing 里列得很明确，真实使用时也要严格执行。

不要保存：

应该保存的是：

记忆越克制，越好用。浏览器 Agent 的长期记忆不是越多越强，很多时候是越多越糊。

如果要把 site-memory 接进团队工作流，可以按这个节奏来。

第一步，给每个环境定 memory root：

第二步，所有浏览器任务都从 recall 开始：

第三步，只加载少量相关笔记。不要为了保险把 manifest 里的文件全读了。读太多，Agent 会被旧路线和无关规则污染。

第四步，执行任务时把高风险动作列成暂停点：

第五步，任务结束后写回，但只写可复用经验：

第六步，定期清理记忆。过期站点路线、改版后的选择器、临时活动入口都要删掉或标记失效。

比较稳的团队目录可以这样分：

如果团队已经有代码评审习惯，也可以把重要 memory root 放进私有仓库，由人审 PR。但前提是里面绝不出现业务数据和密钥。站点路线可以审，用户数据不能进 git。

项目 README 里给了 WebVoyager 测试结果：15 个网站、50 个任务，每个任务 3 轮，总共 150 次运行，全部正确。第一轮使用 Claude Sonnet 4.6，第二、三轮使用更便宜的 Claude Haiku 4.5。

汇总数据里，命令数从第一轮 498 降到第三轮 162，平均每个任务从 10.0 个命令降到 3.2 个。时间从 6944 秒降到 1674 秒，平均每任务从 139 秒降到 33 秒。

几个站点提升特别明显：Booking 从 35.7 个命令降到 5.0，Amazon 从 14.7 降到 2.0，ArXiv 从 9.5 降到 1.5。结构稳定、路径明确的网站，确实容易吃到记忆红利。

但也有反例。Apple 在表格里第三轮命令数和时间没有变好，甚至变差。这反而说明 benchmark 更可信一点：site-memory 不是通杀魔法。页面结构复杂、入口变化、站点策略强、视觉元素多的时候，旧记忆可能帮不上忙，甚至会误导。

所以正确用法不是“信记忆”，而是“先看记忆，再验证现场”。能省掉重复探索最好；省不掉，就当没有。

第一个坑是把每次任务都写成一条新笔记。今天导出报表写一条，明天也写一条，最后十几条都在说同一个按钮。这会让 selector 阶段变得嘈杂。

更好的做法是更新已有 topic 文件：

新的经验补到同一个文件里，并删掉过期内容。

第二个坑是把“答案”当“记忆”。比如这次查到某个订单状态，不应该写进 site-memory。下次再查订单，真正有用的是订单页入口、搜索框 selector、状态字段位置，不是上次那个订单号。

第三个坑是把敏感信息写进 reference。很多后台页面的 URL 里可能带 tenant、workspace、token、一次性 query。写之前要脱敏，只保留路由模式。

比如不要写：

可以写：

第四个坑是跳过现场验证。记忆只能告诉 Agent “上次这条路走通过”，不能保证今天还走得通。按钮文案、弹窗、权限、A/B 实验都可能变。

site-memory 很容易被误解成 RPA。其实不是。

RPA 更像把一套步骤录下来，下次按脚本确定性回放。它适合流程稳定、输入输出明确、异常少的任务。

site-memory 更像给 Agent 一本站点攻略。它不强制回放每一步，而是把关键路线、稳定选择器、坑点和确认点提前交给 Agent。Agent 仍然会根据当前页面做判断。

可以这样搭配：

也就是说，site-memory 更适合“半结构化网页工作”，RPA 更适合“已验证稳定流程”。两者不是替代关系。

下面这个模板可以直接改成团队里的 wrapper，让每次浏览器任务都走同一套前后钩子。

这个脚本不负责替你选择笔记，也不负责浏览器操作。它的作用是把 recall 和 distill 固定成纪律，避免 Agent 一上来就开浏览器乱摸，或者任务结束后什么都不沉淀。

真正接进日常浏览器 Agent 前，至少过一遍这个清单。

site-memory 的价值不在“记住更多”，而在让 Agent 少重复犯同一种笨。浏览器自动化最耗钱的部分，常常是模型在页面上反复找路。把找路经验留下来，下一次先看路书再出发，这就是它的意义。

但别上头。网页会改，权限会变，记忆会过期。成熟用法不是把 site-memory 当神经中枢，而是把它当一层轻量、可审查、可删除的站点经验缓存。能省 token 就省，能少点错就少点错；该让人确认的地方，一步也别省。