核心思路：把播客生产拆成三个独立技能

很多人一上来就想写一个"万能脚本"，几千行代码从头干到尾。别这么做。正确的方式是让你的 Agent 掌握三个可复用的技能（Skills），然后像流水线一样串起来：

  • Ebook Researcher（图书管理员）：负责找书、拆书、整理素材
  • NotebookLM Manager（制作人）：负责把素材扔进 Google NotebookLM，生成双人对话音频
  • Podcast Publisher（发布者）：负责转码、上传、分发到播客平台

说白了，就是"备料→烹饪→上菜"三步。每一步都是独立模块，随时可以单独调用，也可以换掉其中任何一块。

深度拆解：一本书变成播客的全过程

以"处理《金钱心理学》"为例，当你给 Agent 下达这个指令后，后台实际发生了这些事：

第一步：素材处理

Agent 调用 ebook-researcher 技能，从你的电子书库（Calibre 或 Apple Books）中找到这本书，把整本书拆解成数十个独立的 Markdown 章节文件，归档到 Obsidian 笔记库。

为什么要拆？因为如果你把一整本书直接扔给 NotebookLM，AI 只会泛泛而谈。但如果你喂给它"第三章：复利的非直觉性.md"，它就能围绕这个主题做深度讨论。颗粒度决定内容质量，这一点没得商量。

第二步：音频生成

Agent 通过 notebooklm-py（一个开源库）操控 Google NotebookLM——创建笔记本、上传章节文件作为 Source、触发音频生成。

这里有个关键问题：NotebookLM 没有官方 API。notebooklm-py 本质上是在模拟浏览器操作，所以这一步通常要等 5 到 15 分钟。你的 Agent 不能傻等着，否则就被阻塞了，干不了别的事。在 OpenClaw 里可以用 sessions_spawn 启动后台子进程；如果你用 Claude Code 或其他本地 Agent，写个 Python 脚本用 nohup 跑在后台就行。

第三步：转码与上传

NotebookLM 生成的是 .m4a 文件，你需要把它转成标准 MP3 再上传到公网。

为什么要多此一举用 FFmpeg 转码？不只是为了压缩体积——NotebookLM 直出的 .m4a 或 .wav 文件，在部分播客客户端（尤其是 Apple Podcast）上会出现"无法拖动进度条"的诡异问题。用 ffmpeg 转成 44.1kHz、128kbps 的标准 MP3，能彻底解决这个兼容性噩梦。

上传目标推荐 Google Drive（生成公开分享链接），如果你有自己的服务器或对象存储（S3、R2），那会更可控。但有一点要特别注意：绝对不要用 Dropbox，它的链接因为防滥用机制很容易失效。

第四步：发布分发

拿到音频的公开链接后，调用 DearTape API，瞬间完成 RSS 更新，手机上的播客客户端立刻弹出新一期通知。DearTape 本质上就是一个"音频分发的基础设施"，它不管你的音频从哪来，只要你给它一个链接，它就帮你包装成标准的 Podcast RSS。

让你的 Agent 动手搭建

如果你打算让自己的 Agent（OpenClaw、Claude Code 等）来实现这套系统，直接把下面这段 Prompt 复制给它：

我想在我的电脑上部署一套基于 "NotebookLM + DearTape" 的自动播客系统。
请帮我创建以下三个独立的 Skill：

Skill 1: Podcast Publisher（发布者）
- 接收本地音频文件 -> 强制使用 FFmpeg 转码为标准 MP3 -> 上传到 Google Drive -> 获取公开链接 -> 发布到 DearTape
- Google Drive 认证：引导我去 Google Cloud Console 创建项目，启用 Drive API，获取 OAuth 凭证（credentials.json），一步步来
- DearTape API：POST https://deartape.com/api/v1/podcasts/{podcast_id}/episodes，Body 必须 CamelCase：{"audioUrl": "..."}，遇到 500 错误自动重试

Skill 2: NotebookLM Manager（制作人）
- 依赖 notebooklm-py 库
- 能够创建笔记本、上传 Source、触发音频生成、下载音频
- 音频生成是耗时操作，需要轮询状态，不要让进程死掉

Skill 3: Ebook Researcher（图书管理员）
- 询问我的电子书库路径和 Obsidian 笔记库路径
- 能在书库中模糊搜索书籍、用 pandoc 转 Markdown、按章节拆分保存到 Obsidian

最后，创建一个 make_podcast 主流程，把三个 Skill 串联起来。

必须知道的技术坑

这些是实际调试中反复踩过的雷，提前标出来能省你不少时间：

1. API 参数大小写陷阱

DearTape 的 JSON body 是大小写敏感的，必须用驼峰命名。写成 audio_url（Python 程序员的本能反应）不会报错，API 照样返回 200 OK，但音频字段是空的，播客无法播放。正确写法是 audioUrl。这种"静默失败"最坑人。

2. Google Drive OAuth 认证

这不是填个 API Key 就完事的。你的 Agent 需要引导你创建 Google Cloud Project、启用 Drive API、下载 OAuth 凭证文件。这是大多数人卡住的地方，别跳过。

3. 异步处理

生成播客要等 5-15 分钟，Agent 必须用后台进程处理，否则主线程被阻塞，你连问个问题都没人理你。

不止于 NotebookLM：更多玩法

DearTape 不关心音频怎么来的，这意味着你可以把"音频生成"这块积木随意替换：

  • ElevenLabs / OpenAI TTS：不喜欢 NotebookLM 的双人对话风格？写一段独白脚本，用你喜欢的声音朗读，自动发布——就是你的"个人电台"
  • Agent 自动播报：让 Agent 每天自动总结社交媒体热门话题，生成语音，推送给你听
  • RSS 转播客：把你订阅了但没时间读的 Newsletter 转成音频，通勤路上听完
  • iOS 快捷指令：甚至不需要 Agent，录一段语音备忘录，上传到 iCloud Drive，调用 DearTape API，就是一个"私人语音日记播客"

这套架构的精髓不在于某个具体工具，而在于"模块化拼装"的思维方式——每个环节都可以独立替换和升级。对于一人公司来说，能用一句指令就完成"选题→制作→分发"的全流程，这才是 AI Agent 真正该干的事。