19.5k stars 的 notebooklm-py，正在把 Gemini Notebook 接进 Agent

今天给大家分享 GitHub 上很热门的 notebooklm-py。它把 Gemini Notebook 的资料库、问答和生成产物接到 Python、命令行、MCP 与 Agent Skill 里，让 Agent 能围绕一组指定来源做研究、生成内容并导出结构化文件。

目前仓库累计有 19,523 stars、2,609 forks。这些是累计数字，不代表单日增长。项目 README 也直接标注了边界：notebooklm-py 使用未公开的 Google 接口，不是 Google 官方 SDK，接口可能变动，重度调用可能受限。它受到关注的原因，在于开发者正在尝试把一个已有大量用户的资料库产品接进自己的 Agent 工作流。期望对大家有所帮助。

热度背后不是一个孤立的数字

这个仓库创建于 2026 年 1 月 7 日，目前已有 2,526 次提交。最新提交涉及 FastMCP 依赖升级，以及 MCP 产物检查与重试元数据修复。仓库的 Releases 页面显示，最新稳定版 v0.8.3 于 9 月 26 日发布。

这版围绕不确定调用结果做了工程补强：它增加了写操作的提交状态、恢复建议和操作日志，让调用方区分“请求没有发出”“服务已拒绝”和“请求可能已经提交但结果未知”。对会创建 notebook、导入资料或触发生成任务的 Agent 来说，这类差异决定了失败后应重试、停下检查，还是等待人工确认。

项目也修正了一个更现实的边界：MCP 的 source_add 若要读取服务端本地文件，默认拒绝，必须显式配置允许目录；常见凭证文件和 Playwright profile 即使位于允许目录内也会被拒绝。这个变化并不代表整套系统已经安全，却说明维护者至少把“Agent 能读取文件”视为需要收窄的能力，而不是默认打开的便利选项。

Google 侧的变化提供了另一个背景。Google 在 7 月将 NotebookLM 更名为 Gemini Notebook，并称当时已有超过 3,000 万用户和 60 万组织使用它；6 月的产品更新还给 notebook 加入了受保护的云端计算机、代码执行和更复杂的研究能力。notebooklm-py 没有得到这些能力的官方授权，它只是尝试让开发者以代码方式编排同一类资料导入、提问、生成和导出流程。

它实际把什么接进了 Agent

README 里的能力可以归成一条很具体的链路：把 URL、PDF、YouTube、Google Drive 文件或文本放进 notebook；等待资料完成处理；围绕这些来源提问；再把音频概览、视频、幻灯片、测验、闪卡、数据表或思维导图导出为本地文件。

资料与链接
    ↓
Gemini Notebook 的来源处理与带引用回答
    ↓
notebooklm-py：Python API / CLI / MCP
    ↓
编码 Agent 的计划、代码与最终交付

它的核心作用，是把一部分资料处理留在 Notebook 产品内部，再让 Agent 通过明确的命令取得有引用的回答或结构化产物。比如一个团队可以把 RFC、事故复盘和服务文档放在 notebook 里，再让编码 Agent 先查询带来源的答案，然后才开始修改代码。另一种用法是把研究结果导出成 Markdown、CSV 或 JSON，交给本地脚本继续处理。

这也是 Skill 出现的原因。项目根目录有完整的 SKILL.md，它不只是列命令，而是规定了操作顺序：用完整 UUID 指向 notebook 和 artifact；导入来源后等待状态变成 ready；生成任务完成后再下载指定产物；并且不要把“最新产物”当成正确产物。这类约束把 Agent 最常见的误操作 - 任务未完成就读取、失败后盲目重发、并发时串用上下文 - 变成了可检查的流程。

为什么是现在

GitHub Trending Developers 的位置只说明当时的社区关注度，不代表下载量或 Google 的官方背书。Gemini Notebook 在今年扩展到 Gemini 产品体系，仓库刚发布新版本，也持续修复 Agent 接入时最棘手的认证、MCP 文件读取、轮询和不确定写入问题。这些信号共同解释了它为何进入视野。

从技术路线看，notebooklm-py 面向的是跨会话、可查询、可导出的长资料项目上下文。项目提供了本地 stdio MCP，也提供实验性的远程 MCP 连接方式；前者更适合个人工作站，后者则会把身份验证、网络暴露和单租户隔离带进部署范围。两种模式需要分别评估。

先把风险看在安装之前

它最需要被认真对待的事实，恰好写在 README 顶部：这是使用未公开 Google API 的非官方库。Google 改动内部端点时，现有脚本可能失效；它也不等同于 Google 对功能、配额、数据处理方式或长期兼容性的承诺。

认证边界更不能轻描淡写。项目支持浏览器登录、导入浏览器 cookie，以及更适合无头环境的 master token。它自己的 Skill 将 master token 定义为持久的、等同于完整账号权限的凭证，并要求不要输出、记录或提交这类文件。对个人实验，最好使用专门的低权限测试账号；对公司资料，先确认 Gemini Notebook 的账号层级、来源可见性、保留规则和组织政策，再决定是否上传。不要把生产账号的浏览器会话或长期凭证交给一个未经评估的远程 MCP 服务。

适合尝试它的人，是已经在 Gemini Notebook 中管理公开资料或低风险项目材料，并且愿意维护一层非官方集成的开发者。先从本地 CLI、一个隔离账号和几份可公开的来源开始，确认 auth check、来源状态、导出结果与失败处理都符合预期。若你的目标只是把内部文档可靠地交给 Agent 使用，官方 API、企业检索系统或已有的权限审计链路，通常仍是更稳妥的起点。

---

• 仓库：teng-lin/notebooklm-py
• 版本说明：v0.8.3