《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数和成熟度综合排序：
| Agent操作系统 | InkOS | 8.8k | ⭐⭐⭐⭐ | 真相文件+多Agent审计+守护进程+Studio/TUI/CLI三端 | 质量还是依赖基座模型，且AGPL协议 |
| 产品级平台 | NovelForge | 1.1k | ⭐⭐⭐⭐ | 卡片+Schema架构最扎实，长期潜力大 | 工作流系统还是Beta |
| 产品级平台 | 马良写作 | 850+ | ⭐⭐⭐⭐ | 最完整的中文网文开源产品，可商用 | Java+Flutter栈重，部署复杂 |
| 多智能体框架 | NovelClaw | 361 | ⭐⭐⭐ | 动态记忆优先的协作框架，OpenClaw生态 | 相对早期 |
| 仿写引擎 | 方寸写作 | – | ⭐⭐ | 从源文到全书量产，0人工号称 | 成熟度未知，效果待验证 |
| Agent管线 | ai-novel-lab | 55 | ⭐⭐⭐ | 有完整43万字成品，可复现的SOP | 质量自评，仍需大量人工 |
| Agent管线 | InkFlow | 26 | ⭐⭐ | 7-Agent管线+去AI腔引擎+文风蒸馏 | 极早期，6个commit |
| 传统训练 | RWKV-Runner | 3.8k | ⭐⭐⭐ | 网言语感地道、本地部署 | 风格粗、不可控、质量一般 |
| SFT风格微调 | StyleLLM | 362 | ⭐⭐ | 指定作品级风格迁移 | 每个风格一个模型，不通用 |
| 作品DNA提取 | works-dna-extractor | 5 | ⭐⭐ | 16层结构分析、可评估可迭代 | 依赖基座LLM，推理成本高 |
| 少样本嵌入 | TinyStyler | 33 | ⭐⭐ | 作者级风格迁移、可插值 | 英文短文本为主，长篇未验证 |
最值得关注的三个方向：
研究方法与样本选择
数据采集方法
本文的项目样本来自三个渠道：
- GitHub关键词搜索（“novel writing AI”、“AI小说”、"story generation"等）
- 开源社区推荐（HuggingFace、Reddit r/LocalLLaMA、V2EX等）
- 产业链上下游项目交叉引用
评估维度与基线
对每个项目从7个维度评估：
| 完成度 | 功能完整度 + 可运行性 | 能跑通完整流水线=及格，有完善文档=良好 |
| 架构合理性 | 模块划分 + 可扩展性 | 单层脚本=差，三层分离=良好 |
| 社区活跃度 | star数 + 提交频率 + issue响应 | 100star以下=小众，1k以上=活跃 |
| 可复现性 | 是否有可运行的示例 + 成品样本 | 只有文档=低，有完整成品=高 |
| 许可证 | 商用友好度 | AGPL=传染性强，MIT/Apache=友好 |
| 技术路线 | 方案独特性 + 技术深度 | 纯Prompt封装=浅，有状态管理=深 |
| 维护状态 | 最后更新时间 + 版本号 | 6个月以上无更新=停滞 |
样本偏差说明
- 样本偏GitHub英文社区，中文Gitee/Gitcode上的项目覆盖不全
- 未纳入闭源项目和仅提供API服务的项目
- star数受营销因素影响，不完全等于技术质量
- 项目质量判断基于文档和代码分析，未全部实际运行验证
路线成熟度评级标准
本文对各技术路线的⭐评级基于以下维度：
- ⭐⭐⭐⭐ = 已有成熟可商用产品，社区活跃，验证充分
- ⭐⭐⭐ = 有可运行demo/项目，有一定验证，但未大规模商用
- ⭐⭐ = 有研究论文或早期原型，可行性初步验证，但离实用远
- ⭐ = 纯概念或初步探索，尚无实际验证
注意：评级是对路线整体成熟度的定性判断，不是对单个项目的质量评分。
一、InkOS — 8.8k Star，当前最成熟的开源AI小说Agent
| GitHub | Narcooo/inkos |
| Star | 8.8k（AI小说生成类开源项目最高） |
| Fork | 1.7k |
| Commits | 1500+ |
| 版本 | v1.7.x（多语言创作、剧情多线推演） |
| 许可证 | AGPL-3.0-only（强传染性） |
| 技术栈 | TypeScript（Monorepo + pnpm workspace）+ React Studio + TUI |
| 底座 | pi-agent-core（事件驱动Agent循环） |
| 交互方式 | Studio（Web工作台4567端口）/ TUI（终端仪表盘）/ CLI / OpenClaw Skill |
| 安装 | npm i -g @actalk/inkos |
定位：不是"写作工具"，是"自动化小说写作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：修订员，根据审计意见做定向修改
核心功能亮点
评价
优点：
- ✅ 功能最完整的开源AI小说系统——从生成到审计到修订到状态管理到可视化，全覆盖
- ✅ 真相文件机制是当前开源里最成熟的一致性方案——比纯RAG靠谱得多
- ✅ 三种交互方式 + OpenClaw Skill，使用门槛低，非开发者也能用
- ✅ 社区活跃——8.8k star，更新频繁，有交流群
- ✅ 支持中文网文——原生中文支持，针对中文网文场景做了很多优化
缺点/风险：
- ⚠️ AGPL-3.0-only强传染性——如果你基于它做SaaS/网络服务，修改后的代码必须开源。本地个人使用没问题
- ⚠️ TypeScript栈——Python生态的AI工具链用起来不如Python项目方便
- ⚠️ 产出质量还是依赖基座模型——系统再完善，生成质量的天花板还是模型决定的
- ⚠️ 真相文件自动更新的准确性——逆向导入和自动抽取的准确率有多高，没有第三方独立验证
- ⚠️ 9个Agent串行调用成本高——每写一章要调用9次LLM，推理成本是单模型的好几倍
InkOS 与逆向拆解思路的对比
InkOS是正向生成系统，而逆向拆解类项目走的是"逆向拆解"路线——先从已有的成功小说里提取结构化状态，再指导生成。两者的概念对比如下：
| 真相文件（7种） | 角色状态卡/伏笔池/信息差/情绪流/弧线等 | 逆向拆解更细，且是从成品中提取而非人工设定 |
| 审计Agent | 一致性检查模块 | InkOS审计维度更多（20+），逆向拆解侧重状态跟踪 |
| 文风指纹 | 文风标杆库/血肉引擎 | 思路类似，都是先定义风格再指导生成 |
| 旧书导入续写 | 拆书系统 | InkOS为了续写，逆向拆解为了分析和提取方法论 |
| 写手Agent | 生成引擎 | 逆向拆解项目普遍尚未做生成端 |
核心差异：InkOS是"正向生成系统"，逆向拆解项目是"逆向分析系统"。两者结合——用逆向提取的精细状态去喂正向生成系统——理论上效果会比单一路线更好。
二、产品级平台路线：重工程，重功能
2.1 NovelForge — 技术路线最先进
| GitHub | RhythmicWave/NovelForge |
| Star | 1.1k |
| Fork | ~200 |
| 许可证 | AGPL-3.0（商业需注意传染性） |
| 技术栈 | Python (FastAPI + SQLite/Neo4j) + Electron + Vue3 |
| 提交 | 227次，多人协作 |
核心理念：Schema-first卡片系统
不是"编辑器加个AI按钮"，而是所有内容都是卡片——人物卡、场景卡、伏笔卡、世界观卡。每张卡都有JSON Schema定义结构，生成时通过@DSL语法精确引用任意卡片数据。
架构优势：
- 数据模型最扎实：卡片 + Schema + 上下文注入，从根本上解决"AI忘了设定"的问题
- 工作流系统：代码式工作流 + 自然语言Agent生成工作流，灵活性极高
- 知识图谱：SQLite默认 + Neo4j可选，支持关系推理
- 拆书工作流：导入已有小说逆向生成卡片（对标笔灵拆书）
- 灵感助手：独立的灵感工作台
评价：
- ✅ 技术理念最先进，Schema-first路线长期潜力最大
- ✅ 工程成熟度高（227次提交、工程规范文档、贡献指南、发布版）
- ✅ 桌面端 + Web版，非开发者也能用
- ⚠️ AGPL-3.0许可证，做商业SaaS需要注意传染性
- ⚠️ 前后端混合仓库，部署复杂度较高
- ⚠️ 工作流系统还是Beta
2.2 马良写作（MaliangAINovalWriter）— 中文网文开源产品最完整
| GitHub | Deng-m1/MaliangAINovalWriter |
| Star | 850+ |
| Fork | 241 |
| 许可证 | Apache 2.0（可商用） |
| 技术栈 | Flutter Web + Spring Boot 3 + MongoDB + Chroma + LangChain4j |
| 版本 | v1.0.0正式版（2025-11） |
架构特点：
- 完整前后端产品，不是玩具项目
- Flutter前端 + Java后端 + MongoDB数据库 + Chroma向量库
- 多用户SaaS架构 + RBAC权限 + 积分计费系统
- Docker一键部署
核心功能：
- 作品→卷→章节→场景 四级结构
- 三级大纲生成（小说→卷→章节）
- 知识图谱一致性维护（角色、剧情线、伏笔）
- 番茄小说拆书功能 + 剧情推演抽卡
- 提示词管理、数据分析、管理员后台
评价：
- ✅ 当前中文网文开源项目里最完整的产品
- ✅ 对网文生态理解深（拆书、抽卡、番茄适配都是国内特有需求）
- ✅ 可商用（Apache 2.0），有商业化部署能力
- ⚠️ 是工具平台，不直接产出小说——质量取决于使用者
- ⚠️ 部署重，需要Docker + MongoDB + 一堆环境变量
三、Agent管线路线：多智能体协作写小说
3.1 InkFlow（墨流）— 7-Agent全自动管线
| GitHub | real-Elysia886/inkflow |
| Star | 26（极早期） |
| 许可证 | MIT |
| 技术栈 | Python + FastAPI + Jinja2 |
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写作实验
| GitHub | xindoo/ai-novel-lab |
| Star | 55 |
| 产出 | 《大厂重生：我用代码征服世界》100章/42.8万字 |
| 方法 | AGENTS.md + 代码库索引 + DeepSeek |
最值得研究的不是代码，是方法论。
它没有后端服务，核心就是一个AGENTS.md文档 + 一套SOP流程 + Git版本管理。用Kilo Code（AI编程助手）的代码库索引功能做上下文检索，让AI Agent像写代码一样写小说。
4阶段SOP：
修订工程最有价值：
- 初稿40章 → 发现5大类问题 → 连贯性评分73/100
- 系统性修订 → 新增10章过渡章 → 评分提升到93/100
- 然后继续扩展到100章
它证明了什么？
- 证明了纯Prompt工程 + 软件工程方法，也能产出40万字长篇
- 证明了"系统性修订"比"追求一次性写好"更重要
- 证明了AI写的初稿，经过人工指导的多轮修订，质量可以显著提升
它的局限：
- 质量是自评的，93/100有水分
- 人物工具化、语言重复等问题，通过修订缓解了但没根本解决
- 还是需要大量人工干预（修订、补章、调方向）
本文为《60分天花板》系列第2篇（上）
上一篇：P1（商业工具全景调研）
下一篇：P3（开源项目技术路线拆解·下——训练路线、DNA提取与路线选择）
