AI网文写作全景调研（二·上）：开源项目技术路线拆解——Agent与平台路线

《60分天花板：AI网文写作行业全景调研》
全15篇（14篇正文+1篇开篇导读），覆盖13个主题：商业工具、开源项目、文风蒸馏、学术前沿、瓶颈分析、路线判断、行动指南、失败案例、合规政策、多模态、经济学、实验验证、方法论

技术路线完整地图：本系列技术路线的完整分析分布在P2（工程架构）、P3（训练与DNA）、P4（文风专项），三篇合起来构成技术全景。本文（P2）聚焦Agent与平台工程，训练路线、文风蒸馏、作品DNA见P3/P4。
样本量：10个核心项目 + 10+个边缘项目 + 4个文风蒸馏项目（GitHub）
研究方法：GitHub数据采集 + 代码架构分析 + README/文档研读 + 社区活跃度评估
核心问题：不同的技术路线，分别能走到哪一步？哪条路最有前途？
更新说明：v2版补充了InkOS（8.8k star，当前star最高）、方寸写作、NovelClaw、NovelStudio、Awesome Novel Studio等此前遗漏的项目

数据可信度说明：

• ✅ Star数、许可证、技术栈、提交数、文件结构：来自GitHub仓库页面，可信
• ⭕ 功能描述：来自项目README和文档，为项目方自述，可能有夸大
• ❌ 产出质量：除ai-novel-lab有完整作品外，其余项目未做一手验证
• ❌ 实际效果：“架构优势”"长期潜力"等判断为分析结论，非事实

结论先行

在公开可验证的开源项目中，尚未发现能稳定"全自动写出合格网文"的项目。但不同路线的天花板差异很大。

按star数和成熟度综合排序：

最值得关注的三个方向：

1. InkOS的真相文件+多Agent审计路线 — 当前最成熟、star最高、功能最完整的开源方案
2. NovelForge的卡片+Schema路线 — 数据模型设计最扎实，长期潜力最大
3. 作品DNA提取路线 — 不训练模型，纯方法论，可解释性最强，瞄准结构层

研究方法与样本选择

数据采集方法

本文的项目样本来自三个渠道：

• GitHub关键词搜索（“novel writing AI”、“AI小说”、"story generation"等）
• 开源社区推荐（HuggingFace、Reddit r/LocalLLaMA、V2EX等）
• 产业链上下游项目交叉引用

评估维度与基线

对每个项目从7个维度评估：

样本偏差说明

• 样本偏GitHub英文社区，中文Gitee/Gitcode上的项目覆盖不全
• 未纳入闭源项目和仅提供API服务的项目
• star数受营销因素影响，不完全等于技术质量
• 项目质量判断基于文档和代码分析，未全部实际运行验证

路线成熟度评级标准

本文对各技术路线的⭐评级基于以下维度：

• ⭐⭐⭐⭐ = 已有成熟可商用产品，社区活跃，验证充分
• ⭐⭐⭐ = 有可运行demo/项目，有一定验证，但未大规模商用
• ⭐⭐ = 有研究论文或早期原型，可行性初步验证，但离实用远
• ⭐ = 纯概念或初步探索，尚无实际验证

注意：评级是对路线整体成熟度的定性判断，不是对单个项目的质量评分。

一、InkOS — 8.8k Star，当前最成熟的开源AI小说Agent

定位：不是"写作工具"，是"自动化小说写作AI Agent系统"——写、审、改，全程接管。

核心架构：三层 + 两套记忆 + 9-Agent管线

三层架构：

控制层（输入治理）：author_intent.md / current_focus.md / plan + compose
    ↓
执行层（多Agent管线）：9个Agent串行协作
    ↓
持久层（真相文件）：7个结构化JSON + Markdown投影
    ↓
SQLite时序记忆库（memory.db，按相关性检索）

9个Agent串联管线：

Radar → Planner → Composer → Writer → Observer → Reflector → Normalizer → Auditor → Reviser

每个Agent的职责：

• Radar：雷达，扫描当前状态，发现问题和机会
• Planner：规划下一章的大纲和节奏
• Composer：组装上下文（真相文件+前情+风格）
• Writer：写手，生成正文
• Observer：观察者，从生成内容中提取新信息
• Reflector：反思者，检查逻辑和一致性
• Normalizer：归一化，更新真相文件
• Auditor：审计员，20+维度质量审查
• Reviser：修订员，根据审计意见做定向修改

核心功能亮点

1. 守护进程模式（inkos up）：后台自动写章，到点通知你审核。类似"24小时码字机器人"
2. 旧书导入续写：导入已有50章，系统自动拆章+逆向生成7个真相文件，然后无缝接续
3. 同人创作：四种模式（canon正典/au架空/ooc性格重塑/cp向），内置正典导入器和同人专属审计
4. 文风仿写：inkos style analyze分析参考文本→导入书→后续自动注入风格指南
5. 多模型路由：Provider bank内置20+服务商（Google/Moonshot/MiniMax/DeepSeek等）。每个Agent可独立配置模型、Provider、Base URL和API Key——写手用便宜模型快出稿，审计用强模型精审
6. 双重记忆：7个真相文件（结构化JSON+Markdown投影）+ SQLite时序记忆库（memory.db，按相关性检索）
7. Studio Web工作台（端口4567）：书籍管理、章节审阅编辑、实时进度、数据分析、AI检测、真相文件编辑
8. 互动小说/开放世界：Studio Play支持分支叙事+自由动作+自动配图

评价

优点：

• ✅ 功能最完整的开源AI小说系统——从生成到审计到修订到状态管理到可视化，全覆盖
• ✅ 真相文件机制是当前开源里最成熟的一致性方案——比纯RAG靠谱得多
• ✅ 三种交互方式 + OpenClaw Skill，使用门槛低，非开发者也能用
• ✅ 社区活跃——8.8k star，更新频繁，有交流群
• ✅ 支持中文网文——原生中文支持，针对中文网文场景做了很多优化

缺点/风险：

• ⚠️ AGPL-3.0-only强传染性——如果你基于它做SaaS/网络服务，修改后的代码必须开源。本地个人使用没问题
• ⚠️ TypeScript栈——Python生态的AI工具链用起来不如Python项目方便
• ⚠️ 产出质量还是依赖基座模型——系统再完善，生成质量的天花板还是模型决定的
• ⚠️ 真相文件自动更新的准确性——逆向导入和自动抽取的准确率有多高，没有第三方独立验证
• ⚠️ 9个Agent串行调用成本高——每写一章要调用9次LLM，推理成本是单模型的好几倍

InkOS 与逆向拆解思路的对比

InkOS是正向生成系统，而逆向拆解类项目走的是"逆向拆解"路线——先从已有的成功小说里提取结构化状态，再指导生成。两者的概念对比如下：

核心差异：InkOS是"正向生成系统"，逆向拆解项目是"逆向分析系统"。两者结合——用逆向提取的精细状态去喂正向生成系统——理论上效果会比单一路线更好。

二、产品级平台路线：重工程，重功能

2.1 NovelForge — 技术路线最先进

核心理念：Schema-first卡片系统

不是"编辑器加个AI按钮"，而是所有内容都是卡片——人物卡、场景卡、伏笔卡、世界观卡。每张卡都有JSON Schema定义结构，生成时通过@DSL语法精确引用任意卡片数据。

架构优势：

• 数据模型最扎实：卡片 + Schema + 上下文注入，从根本上解决"AI忘了设定"的问题
• 工作流系统：代码式工作流 + 自然语言Agent生成工作流，灵活性极高
• 知识图谱：SQLite默认 + Neo4j可选，支持关系推理
• 拆书工作流：导入已有小说逆向生成卡片（对标笔灵拆书）
• 灵感助手：独立的灵感工作台

评价：

• ✅ 技术理念最先进，Schema-first路线长期潜力最大
• ✅ 工程成熟度高（227次提交、工程规范文档、贡献指南、发布版）
• ✅ 桌面端 + Web版，非开发者也能用
• ⚠️ AGPL-3.0许可证，做商业SaaS需要注意传染性
• ⚠️ 前后端混合仓库，部署复杂度较高
• ⚠️ 工作流系统还是Beta

2.2 马良写作（MaliangAINovalWriter）— 中文网文开源产品最完整

架构特点：

• 完整前后端产品，不是玩具项目
• Flutter前端 + Java后端 + MongoDB数据库 + Chroma向量库
• 多用户SaaS架构 + RBAC权限 + 积分计费系统
• Docker一键部署

核心功能：

• 作品→卷→章节→场景 四级结构
• 三级大纲生成（小说→卷→章节）
• 知识图谱一致性维护（角色、剧情线、伏笔）
• 番茄小说拆书功能 + 剧情推演抽卡
• 提示词管理、数据分析、管理员后台

评价：

• ✅ 当前中文网文开源项目里最完整的产品
• ✅ 对网文生态理解深（拆书、抽卡、番茄适配都是国内特有需求）
• ✅ 可商用（Apache 2.0），有商业化部署能力
• ⚠️ 是工具平台，不直接产出小说——质量取决于使用者
• ⚠️ 部署重，需要Docker + MongoDB + 一堆环境变量

三、Agent管线路线：多智能体协作写小说

3.1 InkFlow（墨流）— 7-Agent全自动管线

7个专职Agent串联管线：

Plan → Compose → Write → Edit → Observe → Reflect → Librarian

每个Agent有专职职责：

• Plan：大纲规划（滚动5章，叫Prophet）
• Compose：组装上下文
• Write：生成正文
• Edit：编辑润色
• Observe：观察提取信息
• Reflect：反思修正
• Librarian：管理真相文件

7种真相文件（Truth Files）：
世界观状态、角色档案、关系图谱、伏笔池、时间线、情绪弧线、地点信息。这是它的一致性保障机制。

差异化亮点：

• 去AI腔引擎（anti_ai.py）：40+类AI腔识别和改写
• 文风蒸馏系统（distiller/）：book_analyzer + skill_generator，从原著分析生成写作技能
• 双层审计：代码层 + LLM层质量检查

评价：

• ✅ 架构设计完整，思路正确
• ✅ 文风蒸馏+去AI腔是独特亮点，其他项目很少做
• ❌ 只有6个commit，太早期了，很多功能可能还没实现
• ❌ 单人开发，社区几乎为零
• ❌ 实际效果未知，没有产出完整小说样本

3.2 ai-novel-lab — 最诚实的AI写作实验

最值得研究的不是代码，是方法论。

它没有后端服务，核心就是一个AGENTS.md文档 + 一套SOP流程 + Git版本管理。用Kilo Code（AI编程助手）的代码库索引功能做上下文检索，让AI Agent像写代码一样写小说。

4阶段SOP：

1. 上下文检索（大纲+进度+记忆+总结）
2. 正文撰写（情绪流设计 → 5000字/章）
3. 文件归档（规范命名）
4. 进度更新（状态+字数+一致性检查）

修订工程最有价值：

• 初稿40章 → 发现5大类问题 → 连贯性评分73/100
• 系统性修订 → 新增10章过渡章 → 评分提升到93/100
• 然后继续扩展到100章

它证明了什么？

• 证明了纯Prompt工程 + 软件工程方法，也能产出40万字长篇
• 证明了"系统性修订"比"追求一次性写好"更重要
• 证明了AI写的初稿，经过人工指导的多轮修订，质量可以显著提升

它的局限：

• 质量是自评的，93/100有水分
• 人物工具化、语言重复等问题，通过修订缓解了但没根本解决
• 还是需要大量人工干预（修订、补章、调方向）

本文为《60分天花板》系列第2篇（上）
上一篇：P1（商业工具全景调研）
下一篇：P3（开源项目技术路线拆解·下——训练路线、DNA提取与路线选择）