OpenNovel（GitHub）

📌 工具简介

OpenNovel（Cppys/OpenNovel）是 GitHub 上一套完全基于 Claude 驱动的中文网络小说自动创作框架，采用 MIT 许可证。它的核心设计不是“辅助你写”，而是“替你跑完一条从选题到发布的流水线”：多个专职 AI 智能体——PlannerAgent（规划大纲与角色）、WriterAgent（创作章节初稿）、EditorAgent（润色与字数调整）、ReviewerAgent（多维度质量审核）、MemoryManagerAgent（跨章节上下文管理）、PublisherAgent（发布到番茄小说）——通过 LangGraph 工作流以有状态的方式协同运行，条件路由、错误恢复和自动重试全部内置，最终可通过浏览器自动化一键将章节上传到番茄小说平台。记忆层用 ChromaDB 存储章节摘要与角色状态，SQLite 做小说/章节/角色持久化，目标是在长篇连载中维持跨章节的一致性。它提供完整 CLI 和 TUI 界面，也支持自然语言对话模式，适合有 Python 基础、希望把网文生产工程化的创作者。需要留意的是，另有一个同名的“OpenNovel – Novel Translator”翻译 App（opennovel.co），与本项目无关。

⚡ 主要功能

• 多智能体流水线协作：规划、写作、编辑、审稿、记忆管理、发布各由一个专职 Agent 承担，各 Agent 的模型可独立配置（例如 WriterAgent 用 claude-opus-4-6 保证创作质量，EditorAgent 和 ReviewerAgent 用 claude-sonnet-4-6 控制成本），而不是让一个模型在同一上下文中包办所有环节
• LangGraph 有状态工作流：条件路由、错误恢复和自动重试贯穿全流程，每一步都有可追踪的状态，长篇连载不会因为某一章的生成失败而丢失整体进度，适合需要稳定跑量的自动化场景
• 向量化长期记忆（ChromaDB）：章节摘要和角色状态被向量化存储和检索，写入新章节时自动召回相关上下文，目标是在数十章乃至更长的篇幅中维持人物设定和情节线索的连续性
• 多维度质量控制：ReviewerAgent 从字数、情节、文笔和 AI 痕迹检测等维度审核生成的章节，不通过则触发重写或退回编辑环节，把“底线质量”交给工作流而非依赖单次生成运气
• 一键发布到番茄小说（差异化能力）：PublisherAgent 通过 Playwright 浏览器自动化直接登录番茄小说，将草稿或正式章节上传，opennovel publish -n 1 -c all 即可完成批量发布，把“写完”和“上线”之间的手工操作压缩到接近零
• 对话式 AI 助手与 CLI/TUI 双入口：新手可以直接运行 opennovel 进入自然语言对话模式，用聊天的方式描述需求，AI 自动调用工作流执行；熟练用户则可以用完整 CLI 精确控制每一步，opennovel new -g 玄幻 -p "少年偶得上古传承..." 即可从题材和一句话梗概启动
• SQLite + ChromaDB 双存储：SQLite 持久化小说、章节和角色的结构化数据，ChromaDB 负责向量化记忆检索，两套存储分工明确，项目状态不依赖单次会话的上下文窗口
• 独立 Skills 工具链（HKStudio011/Open-Novel-Skills）：另有社区维护的 CLI 工具和 7 个 Agent Skills，支持项目脚手架、故事圣经、情节大纲、章节写作、六层审查（逻辑→角色→情节→节奏→情感→文笔）、连续性追踪和导出，可与主框架配合使用，也适配 Claude Code、OpenCode、Codex 等编码助手

💰 价格信息

OpenNovel 框架本身以 MIT 许可证开源，不收取软件费用、订阅费或点数费。真正的使用成本集中在 Claude 模型调用上：项目依赖 Claude Code CLI 处理 Anthropic API 认证，生成章节、编辑润色和审稿都会消耗 API 额度。由于采用多智能体流水线，一章的生成可能涉及多次模型调用（规划、初稿、润色、审核、可能的 rewrite），实际 Token 消耗会高于“单次对话生成一章”的模式。各 Agent 的模型可独立配置，用更强的模型负责创作、较轻的模型负责审核，有助于在质量和成本之间找平衡。对于高频连载的创作者，Claude API 的月消耗需要根据章节更新频率和重写率自行估算。框架本身没有内置的用量监控或成本上限，建议先在少量章节上测试实际消耗，再决定连载节奏。

👥 适合人群

有 Python 基础、愿意用命令行和配置文件驱动创作流程的网文作者和开发者；希望把网文更新从“每天手动写”转变为“可配置、可监控的自动化流水线”的连载创作者；需要批量测试不同题材和开篇、快速验证市场反应的网文工作室或运营团队（番茄小说发布能力直接对接了国内主流免费阅读平台）；对 LangGraph 多智能体编排、ChromaDB 记忆管理和浏览器自动化发布感兴趣、想研究端到端 AI 写作系统的技术爱好者。OpenNovel 尤其适合“以量取胜、以快测款”的网文生产场景。如果核心需求是逐字逐句打磨个人风格、深度参与每一次修改，或者完全没有 Python 和命令行使用经验，这个框架的自动化导向和技术门槛会成为明显障碍；另有同名的翻译 App“OpenNovel – Novel Translator”，与本项目无关，选购时需注意区分。

✅ 优点

• 端到端自动化程度在开源网文工具中突出：从选题、大纲、章节生成、审稿到一键发布番茄小说，整条链路在同一框架内闭环，不需要在写作工具、编辑器、发布后台之间手动搬运内容
• 多智能体分工比“单模型单上下文”更适合长篇连载：规划、写作、编辑、审稿各自独立，每个 Agent 可以针对自己的任务选择最合适的模型和参数，减少了单一模型同时处理所有角色和情节时容易出现的视角混乱和设定遗忘
• 一键发布番茄是实打实的差异化能力：通过 Playwright 浏览器自动化直接上传草稿或正式章节，省去了复制粘贴、格式调整和后台登录的重复操作，对于日更或批量发布的节奏来说，节省的是最枯燥的那部分时间
• LangGraph 的有状态工作流和自动重试提高了工程可靠性：长篇连载最怕“写到一半工作流断了、进度丢了”，条件路由和错误恢复让流程可以在异常后继续，而不是从头再来
• MIT 许可证宽松，代码可自由修改和商用：对于想在此基础上定制题材模板、调整 Agent 逻辑或接入其他发布渠道的开发者，没有法律层面的障碍
• CLI 和对话双模式降低了分层使用门槛：新手可以用自然语言对话启动，熟练用户可以精确控制每个参数，同一套框架服务不同技术水平的用户
• 配套的 Open-Novel-Skills 工具链提供了另一条轻量路径：如果不想跑完整的 Python 框架，可以用 Node.js CLI 和 7 个 Agent Skills 在 Claude Code 等编码助手中完成类似的工作流，选择更灵活

⚠️ 缺点

• 深度绑定 Claude 生态：框架“完全基于 Claude 驱动”，依赖 Claude Code CLI 处理 API 认证，.env 中的模型配置也以 Claude 系列为主。如果用户已有其他模型的 API 或希望使用国产模型降低成本，迁移和适配的成本较高，本质上是为 Claude 用户设计的工具
• 不是开箱即用的写作 App，技术门槛明确：需要 Python 3.10+、克隆仓库、安装 requirements、配置 Claude Code CLI 认证，发布功能还需要安装 Playwright Chromium 和拥有番茄小说账号。没有命令行和 Python 环境经验的用户，在“跑通第一次生成”这一步就可能卡住
• 全自动生成的内容存在同质化和平台风险：流水线式生成容易产出结构工整但缺乏独特“人味”的章节，番茄小说等平台对 AI 生成内容的识别和限流政策存在不确定性，批量发布同一框架产出的内容，账号风险需要自行评估和承担，框架本身不提供合规兜底
• 质量控制是“底线过滤”而非“精品保证”：ReviewerAgent 的多维度审稿能拦截字数不足、明显 AI 痕迹等问题，但无法保证情节的吸引力、人物的情感深度和章末钩子的有效性，生成结果仍需要人工判断是否值得发布
• 项目健康度和社区活跃度需要关注：第三方健康评估显示该仓库活跃度偏低（健康评分约 36/100），作为个人开源项目，长期维护、文档更新和 issue 响应的持续性存在不确定性，不适合作为生产级商业连载的唯一依赖
• 同名产品混淆风险：搜索“OpenNovel”会大量出现翻译 App“OpenNovel – Novel Translator”（opennovel.co，Freemium $4.99/月起），两者名称完全相同但功能毫无关系。用户在查找、讨论和引用时容易混淆，增加了信息筛选的成本

💡 使用技巧

• 先跑通“大纲到单章”的最小闭环，不要一上来就追求批量生成和自动发布。克隆仓库、装好依赖后，用 opennovel new -g 玄幻 -p "一句话梗概" 生成大纲，再 opennovel write -n 1 -c 1-3 写前三章，确认生成质量、API 消耗和流程稳定性都符合预期后，再尝试 opennovel publish 和批量章节
• 利用各 Agent 独立模型配置来控制成本和质量：WriterAgent 用 claude-opus-4-6 保证初稿的创作质量，EditorAgent 和 ReviewerAgent 用 claude-sonnet-4-6 完成润色和审稿，GenreResearchAgent 按需配置。不要所有 Agent 都用最强模型，流水线里大部分调用是审核和润色，用轻量模型可以显著降低单章成本
• 发布到番茄小说前，先用少量章节测试账号风控反应。opennovel publish 通过浏览器自动化操作，平台对自动化行为的检测策略可能变化，建议先发布 1—2 章草稿或非高峰时段发布，观察是否有异常提示或限流，再决定是否全量自动发布，不要把账号安全完全交给自动化脚本
• 把 ReviewerAgent 的审稿结果当作“诊断”而非“判决”：它标记出的 AI 痕迹、节奏问题或字数偏差值得参考，但不意味着修完这些指标小说就“好看”了。建议在自动审稿之后，人工快速通读一章，重点检查章末钩子是否成立、人物对话是否像真人、情节推进是否符合你对这个故事的整体判断
• 如果主要目的是测试题材而非长期连载，可以调低单次生成的章节数（如 -c 1-5），用较小的成本跑多个不同题材的开篇，对比数据后再决定对哪个题材投入更多 API 额度。框架的批量能力适合“广撒网”，但不适合在未验证方向时一次性生成几十章
• 不想部署完整 Python 框架的用户，可以先尝试 Open-Novel-Skills（npx @hkstudio011/opennovel init my-story）：它用 Node.js CLI 和 Agent Skills 在 Claude Code 等编码助手中完成类似的故事圣经、大纲、章节写作和审查流程，门槛更低，适合作为 OpenNovel 主框架的“轻量替代”或前置试验
• 使用前明确版权和平台规则：AI 生成内容的版权归属和平台发布政策因平台而异，番茄小说等平台对 AI 辅助创作有相应规定。在批量发布前，先阅读目标平台的最新规则，确认自动发布和 AI 生成内容的使用边界，避免账号因规则不符而受到影响