用 Crawl4AI + BrowserOS + Obsidian + Supermemory + OpenClaw 搭建个人 AI 信息流水线

状态: 草稿(待人工 review)
适用版本: BrowserOS CDP 9100 / crawl4ai 0.7+ / Supermemory MCP / OpenClaw 2026-06
作者: shenkang · 公众号/博客园: michaelleelll

一、为什么要搭这套体系

我做技术的第十一年,最痛的不是写代码,而是信息过载。

每天打开电脑,Chrome 标签栏动辄三四十个;Notion 里有写到一半的笔记;Obsidian 里散落着没打 tag 的随笔;知乎收藏夹里堆着 200+ 篇"以后再看"的文章;小红书的草稿箱里躺着十几个"今晚修一下"的开头——然后它们都再也没有被打开过。

更难受的是:这些信息彼此孤立。我读了一篇关于 BrowserOS 改 DOM 注入的最佳实践,半年后我在写一个 Playwright 脚本时,完全想不起来自己当时在哪个笔记里写过它的坑点。我的"知识"不是知识,是数字囤积症。

所以我决定把个人信息流当作一个工程系统来设计,而不是一个收件箱来管理。目标是:

采集:任何我读过的网页、推文、文档,自动结构化入库
整理:不需要我手动打 tag、写摘要,系统自己会做
记忆:跨设备、跨会话能立刻召回三个月前的某条想法
发布:一篇技术文章,知乎首发 → 改写小红书 → 改写博客园,一键多投,人只做最后一公里的审核

最终落地的方案就是下面这五件套:

组件	角色	一句话定位
Crawl4AI	信息采集	把任意 URL 变成干净的 Markdown
BrowserOS	浏览器底座	CDP 9100,让脚本能像人一样操作 Chrome
Obsidian	本地知识库	长期 vault,人脑可读可编辑
Supermemory	云端记忆层	跨会话上下文,AI 自己的"长期记忆"
OpenClaw	智能编排	Agent runtime,把上面四个串成流水线

下面挨个拆。

二、组件详解

2.1 Crawl4AI — 采集层

之前用 requests + BeautifulSoup 抓网页,十有八九拿到的是被 React/Vue 注水后的空壳 HTML,正文要靠一堆 CSS 选择器猜。Crawl4AI 的思路是直接驱动一个 headless 浏览器跑页面,等 JS 执行完再抽取语义内容,内置的 fit 模式会优先保留 <article>、<main> 等正文容器。

我用的是 0.7.x 版本,核心调用长这样:

from crawl4ai import AsyncWebCrawler, CrawlerRunConfig

async with AsyncWebCrawler() as crawler:
    config = CrawlerRunConfig(
        markdown_generator=DefaultMarkdownGenerator(
            content_filter=PruningContentFilter(threshold=0.48)
        ),
        excluded_tags=["nav", "footer", "aside"],
    )
    result = await crawler.arun(url=url, config=config)
    print(result.markdown.raw_markdown[:500])

关键点:

不抓 boilerplate:PruningContentFilter 会算文本密度,导航/侧边栏/页脚自动砍掉
支持登录态:把 storage_state 喂给 browser_config,爬需要登录的站(知乎、小红书)也能用
结构化输出:result.media 会列出页面里所有图片/视频 URL,做配图采集很方便

坑:Crawl4AI 默认会启自己的 Chrome 实例。我后来直接让它复用 BrowserOS 那个长期开着的 Chrome(通过 CDP attach),省内存,而且登录态不用重复维护。

2.2 BrowserOS — 浏览器自动化底座

OpenAI 出的那个 BrowserOS 我之前以为是玩具,试了一周发现是真香——本质上是一个带 UI 的 Chrome 包装,开了 CDP 9100 端口和 RPC 9201 端口,任何能调 CDP 的工具(Playwright/Puppeteer/裸 Chrome DevTools Protocol)都能把它当浏览器用。

我现在的标准模式:

from playwright.async_api import async_playwright

async with async_playwright() as p:
    browser = await p.chromium.connect_over_cdp("http://localhost:9100")
    context = browser.contexts[0]  # 主账号 session
    page = await context.new_page()
    ...

这样做的好处:

登录态零成本:我手动在 BrowserOS 里登录了知乎/小红书/博客园,Playwright 直接拿现成 cookie 用,不需要再走一遍 page.fill(密码) 那种容易触发风控的流程
可视化调试:page.on("console", ...) 的同时,肉眼能在 BrowserOS UI 里看到脚本正在点哪儿,出 bug 不用靠截图猜
多账号隔离:connect_over_cdp 进来之后调 browser.new_context() 拿一个隔离的 BrowserContext,塞不同的 storage_state,主账号和测试号互不污染

几个我自己踩过的坑(写出来省你时间):

browser.contexts 是 list,不是 awaitable —— 直接 contexts[0] 取,不要 await browser.contexts
跨平台多账号不需要 Context 隔离 —— 知乎/小红书/博客园域名不同,cookie 天然隔开;同平台多账号才需要 new_context
storage_state 路径约定 —— 我用 /tmp/<platform>_<username>.json,session 重启就重新 login
同一 Playwright 进程内完成 login → save storage_state —— 分两步会丢 cookie(我没仔细追原因,但现象稳定)

2.3 Obsidian — 长期 vault

Obsidian 在这套体系里是人脑可读那一层。所有最终沉淀的笔记都落在本地 Markdown 里,目录结构我用的是 PARA 改造版:

0_Meta/         # 元信息(身份、profile、记忆索引)
1_Projects/     # 进行中的项目
2_Stack/        # 技术栈笔记(就是给 OpenClaw / BrowserOS 这种工具开的档案)
3_Accounts/     # 各平台账号信息
4_Preferences/  # 个人偏好、风格
5_Daily/        # 日志
6_Resources/    # 引用资料、链接
drafts/         # 待发布草稿

关键决策:这是单一信源。任何笔记只在 Obsidian 里维护一份,Supermemory 是它的衍生层(后面会说)。

同步链路:本地 vault → Git private repo (my_ai_knowledge under jasonawe) → 15 分钟一次 vault_sync.sh cron → 多设备一致。我同时开了 Obsidian Git 插件做即时 commit,两者互补:cron 兜底,插件提供秒级反馈。

2.4 Supermemory — AI 的长期记忆

Supermemory 是这套体系里最容易被低估的一环。

Obsidian 是给我自己看的,Supermemory 是给 Agent 看的。每次 OpenClaw 启动一个会话,Supermemory 会自动注入一段背景信息,内容包括:

我的身份(叫什么、用什么语言、时区)
长期偏好(不喜欢被叫"亲"、回复要简洁、技术深度 OK)
近期上下文(最近在做什么项目、今天踩了什么坑)
跨会话的事实(我的 cnblogs 账号叫 michaelleelll,绑定 250893768@qq.com)

它的厉害之处是自动按相关性召回。我不写 tag,Supermemory 用 embedding 自动匹配。比如我今天问"我之前那个 BrowserOS 多 tab 的问题最后怎么解决的",它能从三个月前的某条 memory 里精准捞出来,不用我手动去翻笔记。

和 Obsidian 的关系:Obsidian 是显性知识(我主动写),Supermemory 是隐性知识(AI 在交互中自动沉淀的)。两边互为索引——我在 Obsidian 里写完一个工具的踩坑笔记,会让 OpenClaw 调 supermemory_store 把关键事实同步过去;反过来 Supermemory 召回的东西,会引导我去 Obsidian 里看完整版。

几个工程细节:

supermemory_store 时记得打 category(preference / fact / decision / entity),后续按类召回更准
Token 不要打到终端明文里(mcporter config add --url ... --header "..." 的方式注入,避免录屏泄露)
当前 MCP 工具集:recall / memory / fetch-graph-data / listProjects / whoAmI / memory-graph

2.5 OpenClaw — Agent runtime

最上面这层是 OpenClaw,我用来当整个流水线的调度器。

它本身是个 agent runtime,但我更看重的是它的MCP 协议集成——目前挂了 5 个 MCP server:

MCP	用途
BrowserOS	UI 操控 + DOM 解析
crawl4ai	内容抓取(复用 BrowserOS Chrome)
supermemory	记忆层
feishu / lark	飞书 OKR + 图片分发
wechatsync / chrome-devtools	辅助工具

跑一个工作流的姿势是这样的:

# 伪代码,实际我用 sessions_spawn 派子 agent
async def publish_article_pipeline(topic: str):
    # 1. 检索:从 supermemory 拿历史相关笔记
    related = supermemory.recall(query=topic, limit=5)

    # 2. 采集:crawl4ai 拉参考素材
    raw = []
    for url in related.links:
        md = crawl4ai.arun(url)
        raw.append(md)

    # 3. 起草:主 agent 写主稿,存 Obsidian drafts/
    main_draft = await agent.write(
        topic=topic,
        references=raw,
        style="cnblogs-technical",
    )
    save_to_obsidian(f"drafts/{date}_{slug}.md", main_draft)

    # 4. 改写:派生小红书/知乎版本
    zhihu_version = await agent.adapt(main_draft, target="zhihu")
    xhs_version = await agent.adapt(main_draft, target="xiaohongshu")

    # 5. 暂停:等用户 review(关键!)
    notify_user_for_review([main_draft, zhihu_version, xhs_version])

    # 6. 发布:用户点头后再跑 BrowserOS 自动化
    if user_approved:
        await publish_to_all([main_draft, zhihu_version, xhs_version])

最后那一步 publish_to_all 之前,一定停。这是写死的设计原则,后面单独说。

三、完整工作流:从一篇推文到三平台发布

举个真实的例子——我今天在 X 上看到一条推,讲 OpenAI 的 BrowserOS 改成了 headless mode,作者附了一个性能对比数据。我当时的处理流程:

Step 1 — 采集(30 秒)

OpenClaw 收到指令"分析这条推: "
crawl4ai 拉推文 HTML → 提取正文 + 图片
同时 supermemory 召回我过去关于 BrowserOS 的所有 notes(直接给 Agent 上下文,不用我去翻)

Step 2 — 整理(2 分钟)

主 agent 看完素材,生成结构化笔记:
- 事实(用了什么 benchmark)
- 观点(作者站位是支持还是反对)
- 和我已有知识的关系(对比我 6 月 30 日笔记里 BrowserOS 的多 tab 问题)
- 可行动项(要不要本地复现)
笔记落 2_Stack/AI_Models/ 下,带 frontmatter

Step 3 — 复用(15 分钟)

触发"发文章"指令
Agent 自动:
- 写主稿(技术博客调性,3000+ 字,带代码块)
- 派生知乎版(同结构,加一句开场白让读者愿意读下去)
- 派生小红书版(短图文,分段 + emoji,去代码块)
- 三个版本全部存到 drafts/ 目录
暂停,发飞书消息提醒我"三份草稿已就绪,请 review"

Step 4 — 人工审核(5 分钟)

我打开 Obsidian 翻看
改两个错别字、补一个我自己才记得的细节
在飞书回复"OK,发"

Step 5 — 自动发布(2 分钟)

OpenClaw 起 Playwright,connect_over_cdp 到 BrowserOS
对每个平台调起对应 skill:
- 知乎:走富文本编辑器,粘贴 Markdown 自动转(知乎的编辑器是 ProseMirror,粘贴支持还行)
- 小红书:Tiptap/ProseMirror 编辑器,需要把 Markdown 转成纯文本 + 分段 + 手动触发图片上传
- 博客园:走 agency-blog-publisher 工具,直接 POST Markdown,自动处理分类/标签
每个平台发布前在编辑器里截图给我看最终形态
全部发布完,飞书回执 + 文章链接入库

总耗时:不到 30 分钟,其中我真正动脑子的就 5 分钟。

四、几个反直觉的设计决策

写到这里想停下来单独说几个我故意这么做的设计,以及为什么。

4.1 永远不在采集环节直接发布

我最早的设计里,采集完直接进 Playwright 自动化发,中间零停顿。跑了两周发现问题很大:

事实错误 AI 写得比人自信,直接发出去会被读者抓到
敏感信息(比如不小心把草稿里的内部链接带到公开文章里)
不同平台调性差异大,AI 一稿三投会显得"机器味"很重

现在强制所有内容必须落 drafts/ 目录,人工 review 通过才发布。这个停顿看起来浪费时间,实际救了我好几次。

4.2 Obsidian 是单一信源,Supermemory 是索引

很多人会把 Obsidian 和任何 AI 工具对立起来——"我用 AI 记笔记,Obsidian 会不会被取代?"我的答案是不会。Obsidian 存的是结构化的、长期稳定的、人能编辑的知识。Supermemory 存的是碎片化的、动态更新的、AI 检索用的。两边通过 OpenClaw 定期双向同步。

Obsidian 不在的时候(比如我用手机),Supermemory 顶上;Supermemory 召回不准的时候(比如查一个很细节的配置),我翻 Obsidian。两边都不是孤岛。

4.3 不强求所有平台都自动化

博客园和知乎我做到了接近 100% 自动化(内容、标签、分类全自动)。小红书我没做到,目前只能自动填充文字和图片,最后提交那一步必须我手动点——因为小红书的风控触发太敏感,任何"看起来太像机器人"的行为都会进审核。

这个妥协是有意的。自动化的目标是减少重复劳动,不是消除最后一步的人工。最后的 1% 人工,是给系统留的纠错空间。

4.4 弃用项要写进文档

我的 2_Stack/ 笔记里专门有一节叫"已弃用",记录:

opendia —— 4 小时前卸载,page_analyze 在 Baidu SERP 失效
kimi-webbridge daemon v1.10.0 —— Xianyu 旧方案,改走 BrowserOS

这些"踩过的坑"和"成功用起来的工具"一样重要,甚至更重要——它让我三个月后不会再想"咦这个工具当时为啥不用了来着?"。

五、给想搭这套体系的人的建议

别一上来就上五个组件。先 Crawl4AI + Obsidian 跑通采集→存储,再加 BrowserOS 做交互,最后上 Supermemory 做记忆层。OpenClaw 这种编排器是最后一步,不是第一步。
storage_state 是这个体系的核心资产。比任何代码都重要,定期备份到 1Password / iCloud Keychain。
CDP 端口别乱开。我只开 9100 一个端口给本机,不开外网。BrowserOS 暴露 CDP 等于把所有登录态暴露。
Obsidian 的 frontmatter 是给 AI 看的元数据。tags: [browseros, playwright, cdp] 这种写好,Supermemory 召回时能拿到结构化上下文,比纯文本准。
审核停顿不是可选项。所有发布类操作前必须有一个人工 review 节点,这是底线。

六、接下来想做的事

把 crawl4ai 的输出直接灌进 Supermemory 的 entity 分类,实现"看到一个 URL 就能关联到我所有相关历史笔记"
飞书的图片分发链路(feishu-media-send skill)还没完全自动化,目前是半自动
小红书的安全发布模式还在探索,目标是找到一个既不被风控、又能减少人工的中间态

如果你也在搭类似的体系,欢迎评论区交流。这一行最大的成本不是工具,是找到自己舒服的"停在哪里"——AI 跑得太快反而会让人焦虑,慢一点、稳一点、可控一点,长期跑得动。

工具清单(自用,2026-07 快照)

macOS 26.2 / MacBook Pro / Asia/Shanghai

Python 3.11.15 (/Users/shenkang/.local/bin/python3.11)

OpenClaw 2026-06

BrowserOS CDP 9100 / RPC 9201

Crawl4AI 0.7.x

Obsidian 1.x + Obsidian Git plugin

Supermemory MCP(云端)

飞书 OpenAPI + feishu-media-send skill

自动化工具链:Playwright 1.4x + mcporter + vault_sync.sh cron

posted @ 2026-07-01 13:08 michaelleel1 阅读(1) 评论(0) 收藏举报

刷新页面返回顶部

lijian19890310

用 Crawl4AI + BrowserOS + Obsidian + Supermemory + OpenClaw 搭建个人 AI 信息流水线

用 Crawl4AI + BrowserOS + Obsidian + Supermemory + OpenClaw 搭建个人 AI 信息流水线

一、为什么要搭这套体系

二、组件详解

2.1 Crawl4AI — 采集层

2.2 BrowserOS — 浏览器自动化底座

2.3 Obsidian — 长期 vault

2.4 Supermemory — AI 的长期记忆

2.5 OpenClaw — Agent runtime

三、完整工作流:从一篇推文到三平台发布

四、几个反直觉的设计决策

4.1 永远不在采集环节直接发布

4.2 Obsidian 是单一信源,Supermemory 是索引

4.3 不强求所有平台都自动化

4.4 弃用项要写进文档

五、给想搭这套体系的人的建议

六、接下来想做的事

公告