一、拾枝杂谈

我正在用 WorkBuddy + Playwright 打造一个多平台数据矩阵，目的是为了方便我统计各平台的数据和流量。

之前我已经成功打通了CSDN 和 微信公众号的数据收集，流程就是 playwright 持久化浏览器登录态，然后模拟点击收集后台数据。

但是在完成了两个平台之后，WorkBuddy 在回答了提了一嘴“MEMORY.md之前超限被截断，我已重新做了精简合并”。

这给我吓一跳。

---

二、WorkBuddy中的MEMORY.md是干什么用的？

1.MEMORY.md介绍

超限被截断的这个 MEMORY.md 是项目级的 MEMORY.md 文件，WorkBuddy 中的 项目级MEMORY.md 代表了工作区记忆（Workspace Memory），我们可以把它理解为 WorkBuddy 给自己做了一个备忘录，专门用来记录当前工作区中的重要内容，比如一些关键约定和硬知识，这样可以方便下次对话直接回忆，不用重新摸索。

由于前期对WorkBuddy做了大量的准备工作，比如最终操作方案的确认，飞书表格的格式问题，多平台字段不匹配问题，等等。所以 WorkBuddy 在帮我完成两个平台的数据收集后，Memory里面已经存放了一大堆数据，比如7个平台对应的飞书表格的token，飞书子表的命名规则、日期格式、表头格式，各平台的真实字段约定，以及写入飞书子表的一些约定，等等。

与 WorkBuddy 每天的日志文件不同，这个 MEMORY.md 是当前工作区对话提炼后的精华版，会随着项目演进不停的变化，因为 WorkBuddy 会自己整理并迭代这个文件。

2.MEMORY.md 和当前工作目录的关系是什么？

项目级 MEMORY.md 和当前的工作区是强绑定的，因为它就存放在当前的工作区下面，并且它和当前的工作区是一一对应的关系。

也就是说，只要是在当前的工作区开一个新对话或者新任务，WorkBuddy 每次都会加载同一份 MEMORY.md，相当于共享一套项目记忆。

但是如果我们开的是另外一个工作区的新任务，就是用的不同的项目级 MEMORY.md 文件了。

3.MEMORY.md 超限怎么办？

一般来说，项目级 MEMORY.md 超限问题不大。

因为“截断”这一操作，本身是发生在每次会话开始时，系统注入时发现文件太大，就只注入了一部分到 WorkBuddy 任务的上下文里面，但是磁盘上面的文件本身是完整的，没丢数据。

WorkBuddy 的Agent系统自带“防膨涨”机制，正常维护下它会在超限后自动重写 MEMORY.md，去重合并，使其更加精简，低于 3000 字符的上限。

但是，并不是说有了防膨胀机制就高枕无忧了。如果在 WorkBuddy 自动归纳、裁剪，精简之后，MEMORY.md 还是反复撑爆 3000 字符，说明这个工作区里可能混杂了太多彼此无关的长期使用上下文，泥沙俱下。这时，考虑把不相关的几条工作线拆成各自独立的工作区（每个工作区一份自己的 MEMORY.md），可能会是更好的做法。

4.WorkBuddy的三层 Memory 机制

如果你打开过 WorkBuddy 的设置，就会发现有一个 Memory 选项。如下图所示：

这是 WorkBuddy 的顶层 Memory，属于 Cloud Memory（云端记忆），存放在 WorkBuddy 的服务器端，本质是 WorkBuddy 服务器端自动从你所有历史对话中提炼出来的长期用户画像。

在每次新对话开始时，它会被自动注入到 system prompt 中，它代表了用户的长期画像，比如你是谁，你在做什么，你关心什么。

WorkBuddy 的第二层Memory机制，是用户级 MEMORY.md，区别于我们之前讨论的 项目级 MEMORY.md，这个文件是跨项目使用的，也就是说所有的工作区都可以看到并访问。

用户级的 MEMORY.md 存放在你电脑的系统硬盘中，具体在用户目录的.workbuddy 目录下。用户级的 MEMORY.md 记录的是你跨项目使用 WorkBuddy 的个人习惯，它是需要明确写入的，不会被自动生成，比如，你可以主动告诉 WorkBuddy，“以后不管哪个项目，你都叫我迅哥！”。

WorkBuddy 的第三层Memory机制，是工作区记忆（Workspace Memory）。准确来讲它是分两种的，一种就是我们上文说的 项目级 MEMORY.md；还有一种就是每天的工作日志，比如2026-07-31.md这种的。

工作区记录的特点是，它是和每一个工作区一一绑定的，只在当前工作区内生效，不能跨项目。

---

三、Playwright 是如何识别网页的？

再了解了 MEMORY.md 超限的背后机制后，我突然脑子一热，问了 WorkBuddy 一个问题，“每次爬取数据的时候，我是否要把你切换到一个多模态模型呢？帮助你识别网页”。

结果 WorkBuddy 无情嘲讽了我，她说Playwright (Python) 脚本可以直接通过 DOM 选择器，页面 JS 变量，以及拦截接口等来读取数据，整个过程不需要经过“视觉”参与，之前我爬取CSDN和微信公众号的数据，就是这么整滴。

多模态大模型更适合“页面只有图、没有结构化文本”这样的场景，比如图片验证码、图标截图、滑块验证等。而up要收集数据的七个平台，全部都是由表格、列表、JSON这些组成，DOM 提取要比OCR来得更快、更准、更稳。

于是乎，up便继续进行知乎的数据采集工具，有了前面两个平台的经验，知乎的数据收集还是比较顺利的。

---

Δ总结

• OK，以上就是本篇文章的全部内容了，感谢阅读！。
• 其实up在通过 WorkBuddy 收集知乎的文章后台数据时，还遇到了很多其他问题，例如飞书的格式问题，到时候 up 会统一整理出一篇文章来。
• 关注迅高AI实验室，学习AI不迷路！