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）
秒懂
- 它是什麼？
- 它用本地 SQLite 保存你的行為訊號，靠瀏覽器插件抓取需要登入的平台，再由 LLM 生成心理畫像並主動找內容。本文拆解它的資料流、安裝路徑、DSH 插件與 Tailnet 遠端存取的代價，以及什麼情況下你應該改用別的方案。
- 適合誰用？
- OpenBiliClaw 適合已經在多個內容平台留下大量行為、又不想把興趣圖譜交給平台推薦演算法的人，前提是你願意讓一個常駐後端跑在自己的機器上，並且接受需要登入態的平台必須靠瀏覽器插件才能讀取。不適合只想被動接收推薦、不想維護任何本地服務的讀者，也不適合把推薦品質當成唯一指標、不打算給回饋的人，因為它的畫像完全依賴你按下喜歡、不感興趣與對話回饋。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的不是推薦品質，而是推薦的歸屬權
README 對問題的定義寫得很直白：推薦系統是站在海量內容與海量使用者之間的仲介，排序分數同時權衡點擊率、完播率、按讚與投幣機率、停留時長、留存、創作者生態與廣告收入等十幾個目標，而這些權重由平台決定。專案主張，使用者滿意度在這種設計裡只是達成留存與變現的手段。
第二個問題是孤島。README 舉的例子是：你在 B 站看了三年機械鍵盤，小紅書完全不知道；你在小紅書種草的咖啡器具，B 站不會推給你。興趣被切碎存放在不同平台的資料庫裡，沒有任何一層把它們接起來。
OpenBiliClaw 的目標讀者因此不是「想找更好的影片」的人，而是「想知道自己的興趣被拆成幾份、並且想把它拼回來」的人。專案名稱來自 Bilibili 加 Claw，README 說明它從 v0.3.0 起才從單一平台擴展為通用跨平台 Agent，這個歷史痕跡在架構上仍看得出來。
畫像先於檢索：資料從插件流進本地 SQLite 再回到推薦
README 的標題句是「先懂你，再找內容」，並明確對比：不是從影片出發匹配標籤，而是從你出發。這是整個系統的資料流順序，也是它與平台推薦最根本的差別。
依照 README 與 topics 的線索，鏈路大致是這樣：瀏覽器插件在已登入的平台上採集行為訊號，訊號送到本機後端，後端把資料寫進本地 SQLite，再由 LLM 從這些訊號推導心理畫像，畫像成為跨平台搜尋的查詢條件，最後產出推薦並附上理由。使用者的喜歡、不感興趣與對話回饋會回流，改變後續推薦。這個閉環是專案自稱「自進化」的依據。
需要登入態的平台走插件，這是設計上的必然：小紅書、抖音、B 站這類來源沒有公開的個人化讀取介面，只有瀏覽器裡那個已登入的 session 能代表你。相對地，README 說明 Linux.do、Bangumi、V2EX、微博與 GitHub 可以公開發現，GitHub 由後端透過官方 REST API 匿名讀取公開 repository，也可以用公開使用者名稱把 starred repositories 當成初始化訊號，PAT 只是可選的提額與身分校驗方式。這條分流意味著：你沒有裝插件的平台，仍然可能貢獻訊號，但貢獻的是公開資料而非你的私人足跡。
四步啟動，但每一步都有分岔
README 的快速開始是四步：裝插件、裝後端、連接來源、開啟介面。真正需要判斷的是每步的岔路。
插件有兩條路：Chrome 應用商店一鍵安裝並自動更新，或從 Latest Release 下載 zip 手動安裝。README 明說手動版的新功能先到，商店版可能落後幾天。這是取捨，不是哪個比較好。
後端有兩種安裝包。精簡版預設在首次啟動時自動下載向量模型 bge-m3；-with-embedding 完整版已內建約 1.1GB 的 bge-m3，離線可用。README 的建議是網路差或想離線就選完整版，其餘選精簡版。這裡有個容易被忽略的細節：精簡版的首啟需要連外，如果你打算把這個服務放在沒有外網的環境裡，精簡版會在第一步就卡住。
介面入口是 http://127.0.0.1:8420/web。手機端掃插件二維碼開 http://<電腦區域網路 IP>:8420/m/，可存到主畫面當 App 用。想要原生體驗則裝獨立倉庫的 Flutter 客戶端，在設定裡填後端位址連同一個後端。
想改原始碼的人，README 給的做法是把一段指示貼給 Claude Code、Codex CLI 或 Cursor 這類 AI 編程助手，讓助手照 docs/agent-install.md 部署後端。README 特別提醒要用 Bash 的 curl 下載該文件，不要用 WebFetch，理由是會遺失關鍵指令。這個提醒本身就說明安裝流程對文件完整性有依賴。
應用內 Tailnet：遠端存取能力與它的前置成本
不在同一個區域網路時，README 給的方案是 Tailnet。這裡有一組必須分清楚的邊界：OpenBiliClaw-mobile 的 Android 與 iOS 原生 App 已內嵌 tsnet；Web、Linux、macOS、Windows 的 Flutter 客戶端不在這個能力範圍內。
電腦端要加入同一個 tailnet，桌面安裝包已內建 helper。操作路徑是設定 → 通用 → 應用內 Tailnet 遠端存取，開啟後有三種憑證填法：留空走網頁登入、填 tskey-auth-… Auth Key、或填帶授權裝置 tag 的 tskey-client-… OAuth Client Secret，然後完整重啟應用。README 說明憑證只在本機私有暫存到下一次啟動，不會進入 config.toml、API 回顯或日誌。
原始碼安裝的人不能直接用這個按鈕，必須先跑 openbiliclaw tailnet build-helper，這一步需要 Go 1.26.6，接著跑 openbiliclaw tailnet enable 並重啟。這是本文最想指出的一項隱藏成本：桌面安裝包幫你把 Go 工具鏈的問題吃掉了，原始碼路徑沒有。
安全邊界方面，README 說明電腦不需要安裝或全域開啟系統 Tailscale，入口預設關閉、只在 tailnet 私網可見，不啟用 Funnel 或 Serve，並建議同時開啟應用密碼，原始碼安裝可執行 openbiliclaw set-password。這是一組保守的預設值，值得肯定，但也代表你要主動做兩件事才能真的用起來。
DSH 插件與 22 個 Agent Bridge 工具
專案近期最明顯的變化是把自己塞進 DeepSeek Harness。README 的說明是：DSH 介面常駐第四欄，包含推薦、內容庫、對話、畫像、設定，並註冊 22 個 Agent Bridge 工具，讓 DSH 裡的 Agent 能讀推薦、答探測、閉環學習。插件在獨立倉庫 github.com/whiteguo233/dsh-openbiliclaw。
這個整合的意義不只是多一個入口。它把 OpenBiliClaw 從「你主動打開的推薦頁」變成「你工作時旁邊那一欄」，而 22 個工具代表 DSH 的 Agent 可以反過來查詢你的畫像與推薦結果。對已經把 DSH 當日常工作介面的人，這是降低切換成本的做法；對不用 DSH 的人，這段可以直接跳過，它不影響核心後端。
需要留意的是版本節奏。近期三個發行版 openbiliclaw-v0.3.220、extension-v0.3.220、desktop-v0.3.220 的時間戳幾乎相鄰，而 README 內文提到國內下載仍是 v0.3.219。後端、插件、桌面端各自發版，代表三者之間存在版本對齊問題，升級時最好不要只換其中一個。
什麼時候它會讓你失望
第一個限制來自資料來源的性質。需要登入態的平台必須靠插件，這意味著你在手機 App 裡滑的內容，插件抓不到。README 提到手機端可以掃碼開 /m/ 介面，但那是瀏覽器路徑，與原生 App 的行為資料是兩回事。如果你的主要使用場景在手機原生 App，這個系統看到的你是不完整的。
第二個限制是畫像的冷啟動。README 說畫像從跨平台使用、回饋與對話中持續深化，也說喜歡、不感興趣、聊天回饋都會改變後續推薦。這套機制的反面是：你不給回饋，它就不會變好。把它裝好然後放著不管，得到的東西不會比平台推薦更貼近你。
第三個限制是維運面。這是一個常駐在本機的後端服務，佔用 8420 埠，需要 Python 3.11 以上，精簡版還要首啟下載模型。它不是一個裝完就消失的工具，而是一個你要照顧的服務。
最後，README 沒有給出推薦準確度的量化指標，也沒有說明畫像是用哪個模型、以什麼頻率重算。這些在評估階段無法從現有材料確認，只能自己裝起來觀察。
與平台內建推薦、以及自架推薦系統的差別
最直接的替代方案是繼續用各平台的原生推薦。差別不在演算法強弱，而在目標函數：平台把點擊率、完播率、停留時長、留存與廣告收入一起加權，OpenBiliClaw 的排序目標只有一個，就是你的興趣。代價是它拿不到平台的完整行為資料，也無法像平台那樣做大規模的候選召回，只能靠插件可見的訊號加上公開來源。
另一個方向是自架開源推薦系統，例如以協同過濾為基礎的框架。這條路與 OpenBiliClaw 的差別在資料前提：協同過濾需要大量使用者的交互矩陣，而你只有你自己。單使用者場景下協同過濾沒有鄰居可找，所以 OpenBiliClaw 走的是內容理解加 LLM 畫像，而不是矩陣分解。反過來說，如果你手上真的有一群使用者的行為資料，OpenBiliClaw 的單人畫像路線就不是你要的東西。
第三種替代是自己寫腳本，用 RSS 或各平台 API 抓清單再自己過濾。這在單一平台、規則明確的場景下完全夠用，成本也低得多。OpenBiliClaw 的價值出現在你不想維護規則、且希望推薦理由能被解釋的時候。
授權、升級與維護成本
專案採 MIT 授權，這是最寬鬆的一類，允許修改與再散布，也允許商業使用。需要自己判斷的是：MIT 只涵蓋這個倉庫的程式碼，你接入的平台各自的服務條款、以及你使用的 LLM 供應商的條款，都不在這個授權範圍內。這不是法律意見，實際情況請自行確認。
維護成本主要來自三個會各自演進的元件：Python 後端、瀏覽器插件、桌面客戶端。近期三個 v0.3.220 發行版幾乎同時發布，說明維護者傾向於同步推進，但 README 內文仍指向 v0.3.219 的國內下載，這種文件與發行版的時間差在快速迭代的專案裡很常見，也代表你不能假設 README 裡的版本號是最新的。
升級時的具體動作取決於你的安裝路徑：走 Chrome 應用商店的插件會自動更新，走 zip 手動安裝的要自己換；桌面安裝包要重新下載對應平台的新版；原始碼路徑則要自己處理依賴。若你啟用了應用內 Tailnet，README 提醒憑證只暫存到下一次啟動，所以重啟後需要重新處理憑證，這是升級流程裡容易漏掉的一步。
專案沒有封存，首頁、Gitee 鏡像與 DSH 插件市場都有入口，README 也提供了 QQ 群與 Discord 兩個交流管道。這些管道的活躍程度無法從現有材料判斷，但至少說明維護者預期使用者會遇到需要提問的狀況。
編輯結論
OpenBiliClaw 適合已經在多個內容平台留下大量行為、又不想把興趣圖譜交給平台推薦演算法的人，前提是你願意讓一個常駐後端跑在自己的機器上，並且接受需要登入態的平台必須靠瀏覽器插件才能讀取。不適合只想被動接收推薦、不想維護任何本地服務的讀者，也不適合把推薦品質當成唯一指標、不打算給回饋的人，因為它的畫像完全依賴你按下喜歡、不感興趣與對話回饋。導入前先確認三件事：你的 Python 是否為 3.11 以上、向量模型要走首啟自動下載的 bge-m3 還是改用內含約 1.1GB 模型的 -with-embedding 安裝包、以及若要用應用內 Tailnet 遠端存取，是否具備 Go 1.26.6 來執行 openbiliclaw tailnet build-helper。
社群筆記