OpenBiliClaw 项目调研与吸收评估

OpenBiliClaw 项目调研与吸收评估

结论

OpenBiliClaw 值得按 Partial Absorb / L3 局部能力吸收 处理：吸收它的“跨平台内容发现供给架构”和“浏览器扩展登录态任务桥”，不要整项目并入，也不要替代我们现有 B站管线、小红书 skill、AutoCLI/OpenClaw/Hermes 搜索路由。

最值得补充我们的能力是三块：

1. 平台搜索任务桥：后端只负责编排、预算、队列、候选池；真实平台搜索尽量交给浏览器扩展在用户登录态页面里执行。
2. 统一候选池与混源评估：不同平台结果先统一入 discovery_candidates，再由同一 evaluator 按用户画像、近期负样本、来源上下文评分，而不是每个平台独立推荐。
3. 平台健康与降级状态机：B站 412 / v_voucher、X cookie 失效、抖音 hit_shark、小红书登录态等都显式进入冷却、fallback、重新登录或预算耗尽状态。

项目定位

OpenBiliClaw 是本地优先的跨平台个性化内容发现 Agent。README 宣称覆盖 B站、小红书、抖音、YouTube、X、知乎与 Web，并把用户行为、反馈、聊天对话沉淀到本地 SQLite，再用画像驱动跨平台内容发现。公开搜索结果与仓库 README 均显示它不是单一 B站脚本，而是一个本地推荐/画像/发现系统。

源码目录结构也能印证这一点：

• src/openbiliclaw/sources/：平台 adapter 与任务队列
• src/openbiliclaw/runtime/*_producer.py：各平台 runtime producer
• src/openbiliclaw/discovery/：候选池、发现策略、统一 evaluator
• extension/src/background/*-task-dispatcher.ts：浏览器扩展任务调度
• extension/src/content/*/task-executor.ts：平台页面 DOM / state / fetch tap 执行器
• src/openbiliclaw/storage/database.py：SQLite 持久化
• src/openbiliclaw/soul/：画像与偏好学习

平台搜索/调用链拆解

1. B站：API-first，扩展 DOM search 兜底

B站是实现最完整的平台之一。

后端主链路：

• BilibiliAPIClient 直连 https://api.bilibili.com
• 使用 WBI 签名参数
• 搜索接口遇到 v_voucher / 412 Precondition Failed 时有进程级冷却
• _SEARCH_COOLDOWN_BASE_SECONDS=180，412 冷却 600 秒，最大 1800 秒
• 连续关键词失败达到阈值后触发搜索冷却，并激活 DOM fallback 信号

扩展 fallback 链路：

• 后端入队 B站 search task
• 扩展 bili-task-dispatcher.ts 轮询 /api/sources/bili/next-task
• 打开 https://search.bilibili.com/all?keyword=...
• content script bili/task-executor.ts 从已渲染搜索结果卡片提取 BV、标题、UP、封面、播放量等
• 结果 POST 回 /api/sources/bili/task-result

关键判断：这套设计比单纯调 B站 API 更稳，因为它把“API 反爬失败”和“用户浏览器真实页面还能看到结果”拆成两条路径。我们现有 B站管线里已经有 AutoCLI sidecar / SDK enrichment 的经验，OpenBiliClaw 的新增价值在于：把扩展 DOM fallback 做成正式 task queue，而不是临时诊断脚本。

2. 小红书：后端不直接爬，完全走扩展代理

小红书 adapter 明确是 stub：XiaohongshuAdapter.fetch() 不抓数据，真实入口是扩展 API 结果进入候选池。

调用链：

• XhsTaskProducer 基于画像或统一 keyword planner 生成关键词
• XhsTaskQueue 写入 SQLite 表 xhs_tasks
• 扩展 xhs-task-dispatcher.ts 轮询 /api/sources/xhs/next-task
• search task 打开 https://www.xiaohongshu.com/search_result?keyword=...
• creator task 打开 creator URL
• bootstrap task 用于初始化画像
• content script xhs/task-executor.ts 从 DOM 与 window.__INITIAL_STATE__ 中提取 note URL、title、user、xsec_token 等
• MAIN-world xhs-state-bridge.ts 专门把页面世界里的 window.__INITIAL_STATE__ 序列化传给 isolated content script
• 结果 POST 到 /api/sources/xhs/task-result

关键判断：它对小红书的路线是正确的——不在后端硬写模拟请求，不和 xsec_token / 登录态强对抗；把浏览器扩展作为“平台内代理”。我们现有 xiaohongshu-skill 是 Playwright 命令式工具，已能搜索/详情/推荐流/发布，但缺少这种“后端 producer + 异步任务队列 + 候选池”的系统化接法。

3. 抖音：DOM-first 插件 search/hot/feed，direct-cookie 只作诊断/兜底

抖音实现非常重，说明作者踩过反爬坑。

链路分两层：

• DouyinDirectClient：后端 direct-cookie 模式，可调 /aweme/v1/web/general/search/single/、/hot/search/list/、creator posts、feed 等；需要 cookie、msToken、X-Bogus / a_bogus 签名。
• DouyinPluginSearchClient：运行时主路径偏向插件任务，入队 dy_tasks(type="search"|"hot"|"feed")，扩展从抖音首页出发模拟真实 DOM 操作或用页面内 API bridge。

扩展层：

• dy-task-dispatcher.ts 轮询任务
• dy/task-executor.ts 负责页面操作
• dy-fetch-tap.ts 在 MAIN-world hook fetch / XMLHttpRequest，识别 search/hot/feed 响应
• search endpoint 覆盖 /aweme/v1/web/general/search/single/、/general/search/stream/、/web/search/item/
• 还能用页面内 byted_acrawler 给 API URL 补 X-Bogus / a_bogus
• 如果真实响应带 search_nil_info.search_nil_item="hit_shark" 且无候选，按反爬空结果处理

关键判断：这里最值得吸的是“平台内 fetch tap + DOM 操作 + API bridge 三段式 fallback”。我们现在如果要做抖音/小红书/B站跨平台供给，不应该优先后端逆向签名，而应该优先把浏览器登录态任务桥做稳。

4. X / Twitter：服务端 cookie replay，不走扩展任务桥

X 的路线与小红书不同：它是后端真实 fetch。

调用链：

• XClient 解析 cookie 中的 auth_token 和 ct0
• lazy import twitter-cli
• 用 fetch_search、fetch_home_timeline、fetch_user_tweets、fetch_user_likes、fetch_bookmarks
• 同步库用 asyncio.to_thread 包成 async
• 错误映射成 XMissingCookieError、XAuthError、XBlockedError、XRateLimitError
• XAdapter.fetch() 按 recipe.strategy 分发 search / feed / creator
• XDiscoveryProducer 只 fetch raw candidates，绝不直接写 content_cache

关键判断：X 这条链对我们有参考价值，但不是最高优先级。我们已有 xurl / Grok 社交发现补充路径；OpenBiliClaw 的价值在于 source health 状态机和 fetch-only producer 纪律。

5. YouTube：后端 steady-state discovery + 扩展/Takeout 初始化

架构文档说明 YouTube 有两类入口：

• 初始化画像：浏览器扩展读取观看历史 / 订阅 / 点赞，或 Google Takeout 离线导入
• steady-state discovery：后端 YoutubeDiscoveryProducer 跑 yt_search / yt_trending / yt_channel

实现口径：

• yt_search 用关键词搜索
• yt_trending 优先 InnerTube browse API，失效时抓公开 topic 页的 ytInitialData
• yt_channel 从 DB 中订阅/关注事件读取频道，再拉最新视频
• 与 X 一样，producer fetch-only，把候选交给统一 pipeline

关键判断：YouTube 这块可参考，但我们当前重点是 B站、小红书；YouTube 链的吸收优先级低于平台任务桥。

6. 知乎：插件登录态任务桥，模式比小红书更完整

架构文档描述知乎 discovery 走浏览器插件登录态任务：

• zhihu_tasks(type="search"|"hot"|"feed"|"creator"|"related")
• search 使用统一关键词
• hot 拉热榜
• feed 拉首页推荐
• creator 用最近任务中的作者主页作种子
• related 用最近候选 URL 作扩展种子
• 结果转成 DiscoveredContent 进入统一待评估池

关键判断：知乎链路进一步证明它的抽象不是只为 B站写的，而是“任务队列 + content script + 平台模式 + 统一候选池”的通用平台接入范式。

架构能力评估

真新增能力

#### A. 跨平台供给层统一抽象

SourceAdapter / SourceRecipe / DiscoveredContent / DiscoveryCandidatePipeline 这一组抽象值得吸收。

它解决的是：平台数据来源差异很大，但一旦变成候选内容，就应走统一身份去重、统一待评估池、统一 LLM 评分和统一 admission。

对我们现有体系的补充：

• B站新管线偏单平台深治理
• 小红书 skill 偏命令式平台工具
• search-worker / AutoCLI 偏检索路由
• OpenBiliClaw 提供的是“多平台内容供给层”的系统骨架

#### B. 浏览器扩展作为平台内代理

最值得吸收的是这个模式：

这个模式特别适合：

• 小红书
• 抖音
• B站 API 412 fallback
• 知乎
• 其他强登录态/强前端渲染平台

它比 Playwright 单脚本更适合常驻系统，因为扩展自然复用用户浏览器、cookie、页面 SDK、平台自身 fetch。缺点是安装/权限/调试成本更高。

#### C. 统一候选池 + 混源 batch evaluator

discovery_candidates 先收 raw，后统一评估，能避免平台各自为政。

强点：

• round-robin 混源 claim，避免一个平台占满评估 batch
• candidate_key 用 source_platform:content_id / URL / 标题作者 hash 去重
• 低分 observed 也保留诊断信号，但不进正式推荐池
• fetch-only producer 与 evaluator/admission 分离
• 正式池满时停止继续 discovery，避免浪费 LLM 和平台预算

这对我们的内容归档/推荐/Review Console 都有参考价值。

#### D. 平台健康与预算控制

每个平台都有预算、冷却、状态机或 health 语义：

• B站：412/v_voucher 冷却 + DOM fallback
• 小红书：task timeout、bootstrap timeout、单任务互斥
• 抖音：budget exhausted 与 direct-cookie fallback 区分，hit_shark 识别
• X：missing_cookie/expired_cookie/blocked/rate_limited 分流
• YouTube：daily search/trending/channel budget
• 知乎：不同 task type budget

这比“抓失败就 retry”成熟很多，值得吸收到我们的平台采集治理规范里。

不值得吸收的部分

#### A. 不吸整套推荐人格/心理画像系统

它的五层 Soul / MBTI / 心理画像很完整，但和我们现有 Memory/Hindsight/wiki/session_search/用户画像体系概念重叠且口径不同。直接并入会污染主记忆治理层。

可参考它的“画像摘要用于 query generation / evaluator”的投影方法，但不要把它作为主记忆中心。

#### B. 不吸桌面端/移动端/Web UI 壳

OpenBiliClaw 有 Web、mobile、desktop、browser extension、release pipeline，产品壳完整，但我们当前不缺一个独立推荐 App。吸收 UI 会变成平行系统，维护成本高。

#### C. 不替代现有 B站管线

我们的 B站 pipeline 已经有 UP-pool、Review Console、Bitable、UID rescue、broad sample 等治理链。OpenBiliClaw 的 B站搜索 fallback 有价值，但不足以替代现有管线。

#### D. 不替代现有小红书 skill

现有 xiaohongshu-skill 已有 Playwright 搜索、详情、推荐流、发布/互动/SOP 能力。OpenBiliClaw 小红书更偏“异步供给任务桥”。最佳关系是互补：skill 继续做专项工具，OpenBiliClaw 模式用于常驻任务队列化。

四层审计

1. 宣称层

README 宣称本地、私有、跨平台、支持 B站/小红书/抖音/YouTube/X/知乎/Web。源码结构和架构文档基本支撑这个宣称。唯一需要注意：不是每个平台都同等成熟；小红书是扩展代理而非后端 adapter fetch，X 是 cookie replay，YouTube/知乎依赖各自 producer/task。

2. 实现层

实现可拆性较好：平台 source、runtime producer、候选 pipeline、扩展 dispatcher 分层清晰。真正可吸收的是模式和少量 adapter 设计，不需要搬整个项目。

3. 运行层

本轮未完整部署运行，原因是仓库下载网络非常慢，git clone 与 zip 下载均超时；但 GitHub API / raw 文件足够完成静态实现审计。若要进入试点，必须再做最小运行验证：后端启动、扩展安装、至少 B站 DOM fallback 或小红书 search task 成功跑通。

4. 检索与治理层

它本身有本地 SQLite、task 表、candidate 表、content_cache、source health、budget ledger，治理意识较强。但如果接入我们体系，应落在“平台供给 sidecar / adapter 模式”层，不进入长期知识主层。

三个专项验证

静态面 vs 运行面一致性

静态文档与源码一致：B站 API-first + extension fallback；小红书扩展代理；抖音 DOM-first/plugin search；X cookie replay；YouTube producer；知乎 task queue。运行面本轮未部署，需后续 smoke。

精确回捞能力

源码路径明确，可精确定位平台调用链：

• B站：bilibili/api.py、bili-task-dispatcher.ts、bili/task-executor.ts
• 小红书：xiaohongshu_adapter.py、xhs_tasks.py、xhs_producer.py、xhs-task-dispatcher.ts、xhs/task-executor.ts、xhs-state-bridge.ts
• 抖音：douyin_plugin_search.py、douyin_direct.py、douyin_producer.py、dy-fetch-tap.ts
• X：twitter_adapter.py、x_client.py、x_producer.py
• YouTube：youtube_producer.py
• 知乎：zhihu_tasks.py、zhihu_producer.py

降级与回退路径

项目降级意识强：B站 API → DOM fallback；抖音插件 search → direct-cookie 诊断 fallback；X cookie 状态机；YouTube budget；小红书 task timeout。这是可吸收重点。

与我们现有体系的关系

建议吸收清单

P0：吸收“浏览器扩展平台任务桥”作为平台内容供给标准模式

落点：平台搜索/采集 sidecar 设计规范，优先服务 B站 fallback、小红书常驻任务、未来抖音/知乎。

最小 contract：

不要一上来搬扩展全量代码；先在我们体系里定义 task/result schema 和 proof-of-concept。

P0：吸收“fetch-only producer → unified candidate pool → evaluator/admission”纪律

落点：跨平台内容候选治理 / Review Console 供给层。

关键规则：

• producer 不直接推荐、不直接写正式池
• 所有平台先转统一候选结构
• 统一身份去重
• 混源 batch eval
• 正式池满则停 discovery
• observed 不等于自动通过，仍需评分

P1：吸收平台健康状态机与预算语义

落点：B站、小红书、抖音、X、知乎等平台采集 runbook。

建议统一状态：

• ok
• missing_cookie
• expired_cookie
• blocked
• rate_limited
• anti_bot_empty
• budget_exhausted
• task_timeout
• dom_fallback_active

P1：补强小红书 skill 的常驻异步模式

现有小红书 skill 是命令行/Playwright 同步工具。建议增加一个轻量 sidecar 思路：

• 后端入队 keyword/creator/explore task
• 由已登录浏览器或 Playwright worker 执行
• 回传 note metadata 与 xsec_token
• 进入统一候选池

不要把 OpenBiliClaw 小红书代码直接搬进 skill；应吸收“后端 producer + task queue + result endpoint + 扩展/浏览器执行器”模式。

P1：B站 API 失败时引入 DOM fallback 作为正式 rescue

我们 B站 pipeline 已有 AutoCLI rescue 和 SDK enrichment。可以再补一个扩展/浏览器 DOM fallback 选项：

• 当 direct API 412 / empty 且浏览器页面正常时触发
• 搜索页渲染结果转 CandidateVideo-like 记录
• 只作为 discovery fallback，不作为 sole evidence
• 后续仍可用 SDK enrichment 补 desc/duration/tags

P2：参考 X/YouTube/知乎实现扩展跨平台供给

这些平台不是当前最急，但可作为后续扩展模板：

• X：server-side cookie replay + health machine
• YouTube：search/trending/channel producer
• 知乎：search/hot/feed/creator/related task modes

风险与边界

风险 1：浏览器扩展权限与安装维护成本

扩展方式比后端 API 稳，但引入 manifest、权限、Chrome Web Store/手动安装、content script 兼容、service worker 生命周期等复杂度。建议作为 sidecar/试点，不直接压进 Hermes 主链。

风险 2：平台条款与反爬边界

小红书、抖音、X 这类平台登录态抓取存在合规和账号风控风险。吸收时应限制为个人本地、只读、低频、可关闭，不做批量爬取和公开服务。

风险 3：画像系统概念污染

OpenBiliClaw 的 Soul/MBTI/心理画像很重。我们应只吸收“画像摘要投影给搜索/评估”的方法，不能让它覆盖 Hermes USER/MEMORY/Hindsight/wiki 的分层治理。

风险 4：本轮未完成真实运行 smoke

因为网络下载超时，本轮是源码与文档静态审计。进入工程吸收前必须做真实最小验证：后端启动、扩展联通、一个 B站或小红书任务从 enqueue 到 result 成功。

最终决策

Partial Absorb / L3 局部能力吸收。

一句话：OpenBiliClaw 最值得吸的不是推荐 App，也不是心理画像壳，而是“本地后端统一编排 + 浏览器扩展登录态执行 + 平台任务队列 + 混源候选池 + 统一 evaluator + 平台健康状态机”这一套跨平台内容供给骨架。

下一步建议

1. 先做一个最小 POC：B站或小红书 platform_tasks → browser/extension executor → discovery_candidates，只验证一条搜索任务闭环。
2. 把“fetch-only producer + unified candidate pool”写进我们现有 B站/小红书/平台采集治理 skill/reference。
3. 暂不部署完整 OpenBiliClaw，也不接入其 Soul/桌面/Web UI；等 POC 真实跑通后再决定是否做 sidecar 试点。

证据来源

• GitHub 仓库元数据与 README 搜索结果：https://github.com/whiteguo233/OpenBiliClaw
• 仓库源码树：GitHub API repos/whiteguo233/OpenBiliClaw/git/trees/main?recursive=1
• 关键 raw 源码文件：
• src/openbiliclaw/bilibili/api.py
• src/openbiliclaw/sources/xiaohongshu_adapter.py
• src/openbiliclaw/sources/xhs_tasks.py
• src/openbiliclaw/runtime/xhs_producer.py
• src/openbiliclaw/sources/douyin_plugin_search.py
• src/openbiliclaw/sources/douyin_direct.py
• src/openbiliclaw/runtime/douyin_producer.py
• src/openbiliclaw/sources/twitter_adapter.py
• src/openbiliclaw/sources/x_client.py
• src/openbiliclaw/runtime/x_producer.py
• extension/src/background/bili-task-dispatcher.ts
• extension/src/content/bili/task-executor.ts
• extension/src/background/xhs-task-dispatcher.ts
• extension/src/content/xhs/task-executor.ts
• extension/src/main/xhs-state-bridge.ts
• extension/src/main/dy-fetch-tap.ts
• 架构文档：docs/architecture.md、docs/modules/discovery.md