OpenBiliClaw

一个条目，两个仓库

这个目录里大多数条目对应一个仓库。这一条不同：它描述的是一个 DSH 集成，而集成的代码、许可和发版节奏都在另一个仓库里，所以先把这层关系理清楚，比看功能列表更重要。

上面的 repo: 和 install: 指向 whiteguo233/OpenBiliClaw，也就是主项目。它是一个本地优先、跨平台、自称「自进化」的内容发现 Agent，形态是 Python 后端 + Manifest V3 浏览器插件 + openbiliclaw 命令行工具 + 桌面安装包 + 移动端 Web。行为、画像和历史都存在本机 SQLite 里，采用 MIT 许可。它的 README 只用一段话提到 DSH 插件，没有写插件的安装命令、版本号或清单细节。

DSH 集成则在独立仓库 whiteguo233/dsh-openbiliclaw，以 npm 包 @openbiliclaw/dsh-plugin（v0.4.0）发布，许可是 BSD-3-Clause。它不是 Agent 的第二份实现，而是一个客户端：通过 HTTP 与 WebSocket 连接正在运行的后端，默认地址 http://127.0.0.1:8420，并且要求后端必须已经在跑。插件自己的 README 把边界说得直白——它只做「消费侧」，爬取、平台源管理和账号同步是有意留在主项目里的。只读其中一个仓库的文档，很容易把另一个误读掉。

这个插件给 Harness 加了什么

• 给人用的抽屉。 DSH 左侧栏底部多一个按钮（sidebar.footer.action），点开从右侧滑出面板（shell.overlay），里面五个视图：推荐、内容库、对话、画像、设置。组件表里还列了一个消息抽屉。面板沿用浏览器插件那套粉/蓝配色，深色模式跟随 DSH 主题。
• 推荐流：整卡宽的惊喜推荐 hero、滚到距底部约 800px 就提前预加载的无限滚动、换一批 / 追加 / 刷新、卡片内反馈，以及底部由探测、惊喜和保存事件组成的动态流。
• 内容库：稍后再看与收藏，与主项目共享同一份本地列表；支持逐条与全量同步并轮询展示成功 / 失败 / 需登录；近 30 天历史按「点开过 / 出现过 / 移除的」分页，移除的收藏可以一键恢复。
• 对话：苏格拉底式对话循环，兴趣探测与回避探测卡片支持确认 / 拒绝 / 聊聊 / 稍后，反馈会回写画像。
• 画像：MBTI、核心特质、深层需求、兴趣树，外加一张「阿B 最近新记住了什么」的认知卡。
• 设置面与浏览器插件的后端设置页对齐：模型实例与降级链、embedding、调度与版本更新、P1/P2/P3 多模态开关、连接地址、海外代理、局域网访问密码与日志。
• 22 个 openbiliclaw_* Agent 工具——recommend、reshuffle、get_delight、submit_feedback、chat、next_probe、get_profile、list_saved、save_local、get_runtime_status 等——外加一个从后端 SKILL.md 注册的 openbiliclaw-adapter skill。抽屉和工具读写的是同一份后端状态：面板里点了收藏，Agent 工具立刻看得到。

运行要求

• OpenBiliClaw 后端必须已经装好并在运行，且开启了 Agent Bridge v2。插件默认通过 HTTP + WebSocket 连 http://127.0.0.1:8420；地址可以在面板设置里改，README 提醒地址本身不要再附加 /api。
• 需要一个指向后端项目根目录的 workdir。 插件默认用 <workdir>/.venv/bin/python 调 bridge CLI，所以后端的 virtualenv 必须存在，adapter 的 SKILL.md 也要在。pythonBin、skillPath、timeoutMs（默认 300000）与 stdoutMaxBytes（默认 2000000）可以覆盖默认值。
• DSH 0.1.5-rc.1 或更新，且 peer ABI 与对应版本的 dsh-* 包和 @deepseek-ai/cordis ^4.0.2 对齐。README 明确提醒：不要在同一个 profile 里混用旧版（0.0.1，或 0.1.x 之前）的 DSH 工具包。
• 后端本身的依赖：Python 3.11+ 与 git——这是安装脚本自己声明的两项。主 README 没有给出 Node 版本，也没有提到根目录的 package.json；npm 只出现在构建浏览器插件的步骤里。
• 登录内容平台是在你自己的浏览器里完成。README 没有要求注册项目账号。

这里的 install 命令装的是后端，不是插件

这一点必须先说清楚，两份 README 都是这个意思。上面那条命令执行的是主项目的 shell 脚本：克隆后端、跑终端向导、装依赖、启动后端并做健康检查。它是前置条件，不是完整安装，也完全不会往 DSH 里装任何东西。

装插件是另一件事，在另一个仓库里。插件仓库声明了 dsh.bundle，因此 README 说可以交给 Harness 自己的插件添加路径或某个插件市场；也可以走 npm 上发布的 @openbiliclaw/dsh-plugin（pnpm 同理）。无论哪条路径，之后都要加一条配置行，把 workdir 指到你的后端 checkout。README 里有一个不说就很容易踩的细节：在当前 DSH 版本中，新增配置行必须放在顶层 insert: 之下，因为不带 insert 的 id 条目会被当成对已有行的覆盖，找不到时直接跳过。最后重启 DSH Web 进程并刷新页面。README 也记录了本地方式：把仓库复制进 profile 的 node_modules 目录。

许可、安全与数据处理

• 许可是分裂的。 主项目是 MIT——本条目 license: 字段记录的就是它；而 DSH 插件包是 BSD-3-Clause。如果组织在意授权条款，两边都要看，并且要知道目录里这一个 license: 字段装不下这两种许可。
• 这是实验性预发布。 README 称桌面安装包未签名、ad-hoc 签名，未经公证，macOS 上会常规出现「无法验证开发者」的拦截，Windows 上有 SmartScreen 弹窗；Safari 构建在发布时未配置 Apple 凭据的情况下也是 ad-hoc 包。Flutter 移动客户端被描述为新特性预览版，尚未经过长期实测。签名情况按产物而异，并非统一：README 写明 macOS 在发布时配置了 Apple 凭据则使用 Developer ID 签名并公证，未配置则为 ad-hoc 包；Firefox 扩展使用 Mozilla AMO unlisted 签名；Android 为已签名 APK，iOS 为自签名 IPA。请针对你实际下载的那个产物去核对，而不要假定存在统一的签名结论。
• 会话 Cookie 会被复用，平台密码不存储。 浏览器插件把已登录的会话同步给后端（例如 X 需要 auth_token 与 ct0，Reddit 需要 reddit_session）；README 说项目既不保存你的平台密码，也不替你绕过你自己登录不了的边界。
• .obcbackup 导出明确未加密。 README 说它可能包含模型与来源的 API Key、Cookie、画像和历史，虽然排除了源机整段 API auth（密码、session、设备 key），但仍只适合在可信设备之间传递。
• 对外数据流取决于你的配置。 核心数据留在本机 SQLite，项目声明不会把数据发送到开发者运营的服务器，也没有 OpenBiliClaw 云端账号；但如果你配置了云端 LLM 或 embedding，相应内容会按你的配置发给对应服务商。README 完全没有把遥测当作一类事项来讨论，因此不要把这种沉默读成更广泛的隐私承诺：它唯一作出的对外数据承诺就是上面那条，关于开发者运营的服务器。

覆盖范围与已知限制

• 内容源共 13 个，而开箱只启用 B 站。 README 列出 B 站、小红书、抖音、YouTube、X、知乎、Reddit、Linux.do、Bangumi、V2EX、微博、GitHub 与通用 Web，随后说明发现流程开箱只启用 B 站，其余平台必须在设置里显式打开。不要假设新装就覆盖全部十三个。
• 插件按设计只做消费侧。 平台源与爬取配置、源状态、池配比、同步到外部平台账号，以及插件专属的设备配对，都在有意不做的范围内。抽屉的内容库提供了保存与同步入口，但 README 声明的边界是把平台配置留在主项目。
• 主项目里的 Agent 集成是 workspace skill 加版本化 Agent Bridge，不是 MCP。 两份 README 都没有出现 MCP 这个词。README 列出的宿主目标是 OpenClaw、Hermes、WorkBuddy、Claude Code、Codex CLI 与 Cursor；DSH 是通过这个独立插件接入的。
• 这个插件不替代 OpenBiliClaw 独立的 Web 界面。 桌面 /web、移动 /m、浏览器插件与 DSH 抽屉是同一个本地 API 的并列客户端。
• 两个仓库各自发版。 插件依赖一个独立版本化的后端，同时插件 README 又钉住了 DSH 的 ABI。实际使用中要对齐三样东西：DSH 版本、插件版本、后端版本。
• 来源中没有给出的信息： 星数、一份汇总的签名说明、「无遥测」承诺、主项目的 Node 版本，以及根目录 package.json。README 自身在平台收藏同步的成熟度上还存在互相矛盾的说法，因此对分平台的同步能力宜保守看待。

什么时候用它、什么时候不要用

该用的情况： 你已经在跑 DSH Web GUI，也已经有能正常工作的 OpenBiliClaw 后端，并且希望把这个 Agent 的消费侧搬进 Harness——一个侧栏抽屉装推荐、内容库和画像，同时让同一个会话里的 Agent 能拉推荐、答探测、把反馈写回同一个闭环。抽屉与工具共享同一份后端状态，这才是值得单独装插件、而不是另开一个标签页看主项目 Web 界面的真正理由。

不该用的情况： 只要下面任一条成立就再等等。后端还没部署——插件没有可连的对象，请先从主项目开始。你想要一条命令搞定安装——这一对不是那样：先后端、再插件、再配 workdir、再重启。你以为插件能配置内容源、管理爬取或处理账号同步——这些被明确划在范围之外。你需要已签名、已公证的桌面软件——项目自己的 README 就把桌面包称作实验性预发布。你的 DSH 固定在 0.1.5-rc.1 以下，或者 profile 里还留着旧版 DSH 工具包——请装进一个干净的 profile。

FAQ

DSH 插件和 OpenBiliClaw 是同一个项目吗？

不是。OpenBiliClaw 是主项目——Python 后端、浏览器插件、CLI 和安装包都在这里，许可是 MIT。DSH 集成是独立仓库 whiteguo233/dsh-openbiliclaw，以 @openbiliclaw/dsh-plugin 发布，许可是 BSD-3-Clause。本条目的 repo: 与 install: 指向主项目，是因为那个后端才是前置条件。

插件必须等后端跑起来才能用吗？

是的。插件是客户端：它通过 HTTP 与 WebSocket 连后端（默认 http://127.0.0.1:8420），通过后端的 virtualenv 调 Agent Bridge CLI，并要求后端开启 Agent Bridge v2。没有运行中的后端，抽屉和 Agent 工具都没有可读写的东西。

条目 install: 里的那条命令会把 DSH 插件装好吗？

不会。它装的是后端——克隆主仓库、装依赖、启动服务并做健康检查。插件要另外安装：走 Harness 的插件添加路径、某个插件市场，或 npm 上发布的包，然后加一条把 workdir 指向后端的配置行，再重启。

许可到底怎么算？

主项目是 MIT，也就是本条目 license: 字段记录的那个；DSH 插件包是 BSD-3-Clause。目录字段装不下两个，所以这个区分对你重要的话，请直接去看插件仓库。

关于隐私，我不该假设什么？

不要以为「本地优先」等于什么都不会离开这台机器。核心行为、画像和历史留在本机 SQLite，项目也声明不往开发者运营的服务器发数据；但你配置云端 LLM 或 embedding 后，内容会发给对应服务商，浏览器插件会复用你已登录的会话，.obcbackup 导出也明确未加密。README 并没有把遥测当作一类事项来讨论。