Open Notebook 上手：NotebookLM 自托管替代的两容器部署

Open Notebook 是一个自托管的笔记研究工具，定位是 Google NotebookLM 的开源替代。把资料传进去、对着资料提问、把回答整理成笔记，整套流程跑在自己的机器上，模型由自己选。

它用 MIT 许可发布，主语言 TypeScript，2026 年 11 月 8 日查看时 仓库有 41,745 个 Star、4,797 个 Fork，当天仍有新提交。最近一次发布是 11 月 4 日的 v1.15.1，被标为安全版本。

Open Notebook 是什么：资料、笔记与对话装进一个本地库

整个工具围绕三个对象转：源、笔记、对话。源是喂进去的材料，可以是 PDF、网页链接、纯文本、PPT、YouTube 视频或音视频文件。上传之后由后台 worker 抽取正文、切块、算向量，检索时全文与向量两条路一起走。它与官网首页列举的方向一致：先把资料收进库，再让模型在库内工作。

笔记是人工与模型共同产出的中间层。可以在对话里把某段回答存成笔记，也可以让变换功能按预设提示词批量生成摘要、要点、问答。对话始终绑定当前这一组源，回答会标出引用来自哪一段，这一点与 NotebookLM 的引用体验接近。

另一个相对独立的功能是播客。它把笔记与源组合成脚本，再调用 TTS 合成音频，说话人可以设 1 到 4 个，各自配音色与角色。这比 NotebookLM 固定两人对谈宽松，也是仓库自述里重点强调的差异。

版本节奏偏快。项目 2024 年 10 月 21 日首次提交，到 2026 年 11 月 8 日已有 1,040 次提交。近期两次发布是 10 月 4 日的 v1.15.0 与 11 月 4 日的 v1.15.1，前者换了视觉、加了 SiliconFlow 与 Z.ai 两家服务商，后者修的是源处理链路里的安全校验。

部署：两个容器，启动前改三处

官方推荐 Docker Compose，一共两个服务。open_notebook 承载界面与 API，surrealdb 存数据，上传文件与安装缓存放在另一个卷里，容器重建不丢。前置条件只有 Docker 与一个模型服务商的密钥，上手文档把这几步列在同一页。

mkdir open-notebook && cd open-notebook
curl -o docker-compose.yml https://raw.githubusercontent.com/lfnovo/open-notebook/main/docker-compose.yml
openssl rand -hex 32   # 用输出替换 change-me-to-a-secret-string
docker compose up -d

等半分钟左右，打开 http://localhost:8502 就是界面，REST API 在 5055 端口，接口文档在 5055/docs。SurrealDB 的 8000 端口只绑在 127.0.0.1，留给本机调试，不对外。

三处必须改。加密密钥要换成随机值，它加密数据库里存的各家 API Key，弄丢只能重录。其次是暴露面，界面与 API 默认监听所有网卡且没有密码，同一个局域网里谁都能进。再就是 SurrealDB 账号，默认 root 配同名密码，得用 .env 覆盖。

还有一个容易踩的坑：改完环境变量要重新执行 docker compose up -d，docker compose restart 不会重新读取环境变量。

接模型：谁出算力，决定数据去哪

模型在界面里加，不写在配置文件里。侧边栏进 Models，选服务商、填密钥、点测试，然后勾选模型并分配默认值。至少要有一个对话模型和一个嵌入模型，缺了后者，检索只能靠全文匹配。

支持的服务商超过 20 家，OpenAI、Anthropic、Google、Mistral、OpenRouter 都在列，国内可用的 SiliconFlow 与 Z.ai 是 v1.15.0 补进来的，同一版本还加了 MiniMax 的语音合成。任意 OpenAI 兼容端点也能接，LM Studio、vLLM 这类本地方案按这个口子进。

这个取舍不是抽象的。选云 API，隐私优势就只剩「数据存在自己库里、由自己决定发给谁」；选本地模型，4GB 内存的下限基本不成立，得看显存够不够。

本地模型有两个参数值得先调。worker 并发默认 5，单卡跑本地模型时设成 1，免得并行请求把模型压住；单次模型调用默认 180 秒超时，慢模型可以调到 420 之类的值，但要压在 600 秒以内，否则前端会先放弃请求。

容器里的 localhost 指向容器自己。Ollama 如果写在同一个 compose 文件里，Base URL 要填服务名加端口，而不是 127.0.0.1，这是自托管最常见的错配。

解析与检索的边界：PDF、中文与分块

默认镜像刻意做小，Docling 与 Crawl4AI 都没有预装。要用 OCR、版面分析、图片描述，得打开 OPEN_NOTEBOOK_ENABLE_DOCLING；要抓复杂网页，打开 OPEN_NOTEBOOK_ENABLE_CRAWL4AI，它自带一个 Chromium。两个开关都在容器首次启动时下载安装，缓存在数据卷里，所以第一次启动会明显变慢。

这带来一个现实判断：文字版 PDF 走默认引擎够用；扫描件、双栏排版、带表格的财报，不开 Docling 往往拿不到可用文本。之前实测过Docling 把 PDF 转成结构化 Markdown 的流程，双栏与表格的还原质量直接决定了后面的检索命中率。开了之后如果运行时没装上，提取会退回 auto 模式，日志里留一行提示，不会直接报错停下。

上传上限是 100MB，按请求体算，超了返回 413。前面如果还挂了 nginx，client_max_body_size 是另一道闸，两道都得过。这个限制与源的数量无关，源数量本身没有硬上限，压力主要在解析时间与向量库体积上。

切块默认 400 token，重叠 15%，短于 5 token 的块会被丢掉。这三个数值按 token 计，与字符数不是一一对应，中文文档实际切成多少块，要用自己的材料跑一遍才知道。官方文档没有按语种给出解析质量评测，界面提供简体中文只说明 UI 已翻译，不代表中文 PDF 的抽取效果。

另外两个容易忽略的点：它没有官方安卓或 iOS 客户端，移动端只能靠浏览器访问自建地址；第三方评测也提到，接本地模型跑完整流程会偏慢。这两点决定了它更像桌面办公场景的工具，而不是随手记的便签。如果需求其实只是把网页收进库、回头能搜到，Karakeep 这类书签工具的负担要小得多。

和 NotebookLM 的差别，以及上手的三条建议

差别集中在四件事：模型不受限、播客说话人可以配到 4 个、有完整 REST API 能被脚本调用、数据在自己的硬盘上。代价同样清楚：产品打磨程度、检索调优、默认可用的顺滑度，都属于开源项目还在追赶的部分，出问题得自己看日志。

三条上手建议：

• 先跑影子流程。拿一份自己熟的文档走完上传、提问、生成笔记、导出播客，对着原文核引用，比看功能列表有效。
• 先收暴露面，再谈功能。把 8502 与 5055 收到本机，或者设密码再加反向代理，这两步做完再往里放资料。
• 把模型当成可替换件。对话模型与嵌入模型分开选，换模型意味着已有向量要重算，重算的时间和费用提前估。

适合谁：常年读长文档的研究者、学生、分析师，以及手里有台常开机器、介意文档外流的人。只想要开箱即用的笔记体验，或者习惯在手机上随手记，先别急着迁移，用Open WebUI 这类界面做日常对话、把研究库单独放着，也是可行的分工。

相关地址

以下为文中项目的官方入口，版本号、部署命令与文档以这些页面为准。

• Open Notebook（GitHub 仓库）：https://github.com/lfnovo/open-notebook
• Open Notebook（官网）：https://www.open-notebook.ai/
• Open Notebook（版本发布页）：https://github.com/lfnovo/open-notebook/releases
• Open Notebook（官方 compose 文件）：https://raw.githubusercontent.com/lfnovo/open-notebook/main/docker-compose.yml