用本地小模型搭一个多智能体播客工作室

做一期播客要经历选题调研、写稿、录音、剪辑——每一步都很花时间。Podcast Agent 这个项目的目标是把这条生产线交给一组 AI 智能体:一个负责研究,一个负责写对话脚本,人只在关键节点做审核,最后由语音合成引擎输出多说话人的播客音频。
它有一个重要的前提约束:全链路本地运行(local-first)。模型用 Ollama 管理的 Qwen 系列小模型(SLM),语音合成用 VibeVoice——没有 API 费用,没有云依赖,数据不出本机。

架构:四层设计
1. 智能层(Local SLMs & EdgeAI)——地基是 Ollama + Qwen 本地小模型。选小模型不是妥协而是设计:播客脚本生成不需要 100B 参数,8B 量级在 16GB 内存的笔记本上就能流畅工作,零延迟、零 API 成本、隐私可控。
2. 编排层(Hybrid Workflow Engine)——基于 Microsoft Agent Framework 的混合工作流:
- Search Agent(研究员):带 Web 搜索工具,负责收集主题素材
- Script Agent(撰稿人):以 Chain-of-Thought 推理模式生成对话脚本
- Review Executor(人工审核):human-in-the-loop 节点,脚本不合格走条件路由回环打回重写,合格才放行
这个”生成→审核→有条件打回”的回环是整个工作流的关键——纯自动化的多智能体系统很容易在质量上失控,把人放在审批位、把打回做成路由逻辑,输出质量就有了下限。
3. 多模态合成层(VibeVoice)——审核通过的脚本进入 VibeVoice(LLM + Diffusion 架构的 TTS),支持最多 4 个说话人、90 分钟长音频、7.5Hz 帧率的对话式韵律。多说话人是播客场景的硬需求——单一音色念稿子不是播客,是有声书。
4. 可观测层(DevUI)——Web 界面提供智能体的实时执行追踪、自动发现和输入自动生成,调试多智能体协作时能看清每一步谁在做什么。
角色系统:让对话有”人味”
脚本质量的另一半来自角色设计。系统内置 6 种预定义风格角色(新闻主播、技术大咖等),生成时指定说话人组合:
python generate_podcast.py --topic "人工智能的发展" --speakers "news_anchor,tech_guru"生成的脚本不只是对话文本,还带音效指示(【开场音乐渐弱】)和语气标注(【语气转为专业】),角色之间的风格区分明显——新闻主播负责推进节奏和提问,技术角色负责深入和展开,对话有真实播客的攻防感。
在此基础上我还设计了文化角色系统的扩展方向:让不同文化视角的 AI 主持人(中式思维、西方视角、日本美学等)围绕同一主题对谈,配合 Cultural Context Agent 做文化背景增强——同一个话题在不同文化语境下的讨论,是真人播客都很难凑齐的阵容。
使用方式
命令行一步生成:
cd code/02.Workflow-MultiAgent/03.Applicationpython generate_podcast.py --topic "你的主题" --speakers "news_anchor,tech_guru"# ✓ 脚本已保存到: podcast_20260113_171200.txt也有交互式应用 personalized_podcast_app.py,逐步引导选题、选角色、审核脚本,最后接 VibeVoice 出音频。
几点经验
- 小模型 + 好编排 > 大模型裸跑:8B 模型在明确分工的多智能体结构里,产出质量远超单次大 prompt 的”一把梭”
- human-in-the-loop 要做成路由,不是做成暂停:把”打回重写”建模为工作流的条件边,人审核的成本才能真正摊薄
- 本地 TTS 是被低估的一环:VibeVoice 的多说话人长音频能力让”全本地播客生产”从玩具变成可用工具
- 可观测性决定调试效率:多智能体系统没有执行追踪就是黑盒,DevUI 这层投入非常值
从一个想法到能出音频的完整流水线,这个项目验证了 local-first 多智能体应用的可行性:不依赖任何云服务,一台笔记本就是一个播客工作室。
文章分享
如果这篇文章对你有帮助,欢迎分享给更多人!

