OpenBiliClaw：把推荐算法从平台手里拿回来的本地 Agent
本地私有、开源的自进化跨平台 AI 内容发现 Agent：先理解你，再主动从 B站、小红书、抖音、YouTube、X、知乎、Reddit、微博等平台与开放 Web 寻找内容。（支持 deepseek harness 插件） | Local-first open-source cross-platform AI content discovery agent: understands you, then proactively finds content across Bilibili, Xiaohongshu, Douyin, YouTube, X, Zhihu, Reddit, Weibo and the open web.（support deepseek harness plugin）
秒懂
- 它是什么？
- OpenBiliClaw 是一个本地优先的开源内容发现 Agent，用浏览器插件收集你在 B 站、小红书、抖音等平台的行为，在本地 SQLite 里构建画像后跨平台推荐。它把推荐逻辑从平台黑盒搬到你的机器上，但代价是你得自己维护模型、后端和来源登录态。
- 适合谁用？
- 适合愿意为隐私和控制权付出操作成本的人：你接受命令行、愿意管理一个常驻后端进程，并且主要活动平台恰好是 B 站、小红书、抖音这些插件能覆盖的站点。不适合只想装个扩展就完事的普通用户，也不适合对推荐实时性要求极高的人，行为同步、向量计算和模型加载都有延迟。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是平台推荐的黑盒问题，不是推荐精度问题
它解决的是平台推荐的黑盒问题，不是推荐精度问题。OpenBiliClaw 的立论很直接：B 站、抖音这类平台的推荐系统优化的是平台目标，点击率、完播率、留存、广告收入，十几个指标加权成一个分数，用户满意度只是其中一个权重。你在 B 站看三年机械键盘，小红书对此一无所知。项目想做的事是把推荐从平台手里拿回来，放在你自己的机器上。做法是用浏览器插件收集你在各平台的行为，在本地生成一个心理画像，再基于这个画像跨平台找内容。注意它的定位：它不承诺推荐得比平台更准，它承诺的是推荐逻辑归你。README 里反复强调 local-first、数据默认留在本机 SQLite，这个立场比功能本身更值得注意。
数据流：插件采集、本地后端消化、画像驱动搜索
数据流从浏览器插件开始。你登录 B 站后，插件采集浏览行为作为初始信号。这些信号进入本地后端，后端在 SQLite 里维护画像，用向量模型计算内容与画像的匹配度。推荐结果通过 Web 界面展示，地址是 http://127.0.0.1:8420/web，每个推荐都带解释。你点喜欢或不感兴趣，或者直接聊天反馈，这些动作会写回画像。下一次推荐就基于更新后的画像重新计算。整个循环不经过任何第三方服务器，这是它和云端推荐系统的根本区别。
部署路径：桌面包开箱即用，源码安装需要 AI 助手代劳
部署路径分两层。桌面用户装插件加安装包即可，后端常驻菜单栏。想改源码的人需要自己跑 Python 3.11 以上的环境，README 建议让 AI 编程助手按 docs/agent-install.md 操作，且明确要求用 curl 而非 WebFetch 获取该文档。这个提示暗示文档里有普通 HTTP 抓取会遗漏的指令。另外还有一个 Tailnet 远程访问功能，桌面安装包内置 helper，源码安装需要先运行 openbiliclaw tailnet build-helper，要求 Go 1.26.6，再运行 openbiliclaw tailnet enable 并重启。凭据只在本机暂存到下次启动，不写入 config.toml。远程访问默认关闭，只在 tailnet 私网可见，不启用 Funnel 或 Serve。
DSH 插件与移动端：生态在扩展，但核心后端只有一个
DSH 插件不是独立产品，它把 OpenBiliClaw 的界面和工具嵌入 DeepSeek Harness，让用户在 DSH 里干活时也能刷推荐。22 个 Agent Bridge 工具意味着 DSH 里的 Agent 可以编程方式调用推荐、画像、反馈这些能力。移动端则是另一层壳，推荐、对话、画像、收藏、稍后再看、30 天历史都有，但核心计算还是回到本地后端。这种架构的好处是后端逻辑单一，扩展只做界面适配。代价是后端一旦出问题，所有入口都瘫痪。
平台覆盖的真相：公开可发现与需要账号态的差别很大
平台接入深度不均等。GitHub 走官方 API，匿名就能读公开仓库。Linux.do、Bangumi、V2EX、微博也是公开发现。但 B 站、小红书、抖音这些核心内容平台依赖插件里的登录态，登录过期或 cookie 失效，采集就中断。README 没有说明各平台采集频率、反爬策略或接口稳定性，这些在自托管项目里通常是隐藏的维护成本。你选平台时得先确认自己的账号在这些站点上是否活跃，否则画像会偏。
真正的替代方案是平台自带推荐，而不是另一个推荐引擎
拿 OpenBiliClaw 和平台自带推荐比没有意义，数据量和算力不在一个量级。更实际的参照是 RSS 加关键词过滤，或者干脆用平台自带的关注列表。RSS 是确定性工具，你订阅什么就看到什么。OpenBiliClaw 是概率性工具，它根据画像猜测你可能喜欢什么。前者适合目的明确的阅读，后者适合探索性发现。还有一个隐性替代是平台自带的跨平台推荐，但那些功能通常要求你授权平台访问其他平台数据，隐私代价和 OpenBiliClaw 完全不同。
维护成本与许可证：模型下载、平台接口变动、MIT 的双面性
维护成本是自托管项目绕不开的议题。模型下载是第一关，bge-m3 精简版要联网拉取，完整版占 1.1GB。第二关是平台接口的稳定性，这些站点没有为第三方采集提供官方支持，接口变动是常态，插件需要跟着适配。项目迭代速度快，v0.3.219 与 v0.3.220 间隔极短，升级频繁但修复也及时。第三关是 Tailnet 功能依赖 Go 1.26.6，源码安装者得额外装 Go 工具链。MIT 许可证给了最大的自由度，你可以改源码、自己维护 fork，但这也意味着上游没有义务为你修 bug。单点维护者项目，平台接口一改，你可能要等上游发版，或者自己动手。
编辑结论
适合愿意为隐私和控制权付出操作成本的人：你接受命令行、愿意管理一个常驻后端进程，并且主要活动平台恰好是 B 站、小红书、抖音这些插件能覆盖的站点。不适合只想装个扩展就完事的普通用户，也不适合对推荐实时性要求极高的人，行为同步、向量计算和模型加载都有延迟。不适合把 GitHub star 数当唯一信号的人，匿名 REST API 能拿到的公开数据有限。采用前先验证三件事：你的平台账号在装了插件的浏览器里能否正常登录；首次启动时 bge-m3 模型能否顺利下载，网络受限就选 -with-embedding 完整版；以及你是否接受画像数据以明文 SQLite 形式留在本机，应用密码和 Tailnet 通道默认关闭，需要你主动开启。项目迭代很快，v0.3.220 与 v0.3.219 间隔很短，升级前看 release notes 里有没有破坏性配置变更。
社区笔记