10 个 AI Agent 写了 45 万字小说，没崩：InkOS 深度测评
一句话说清楚
InkOS 是一套开源的 AI 小说自动化生产系统——不是”帮你写”，是”替你跑完整条流水线”。从市场趋势扫描到成稿质检，10 个 Agent 各管一段，写完的长篇小说前后不矛盾。
AI 写小说，现在烂到什么程度
你让 ChatGPT 写一本玄幻小说。前三章男主角有一把青锋剑，第七章突然变成了赤焰刀，第十二章青锋剑又回来了。没人记得男主口袋里有多少灵石，没人在意第五章埋的伏笔到第二十章还没收。
这不是 GPT 写得差。GPT 单章质量其实不错。问题是——它没有记忆。
每一章都是一次全新对话。上下文窗口装不下一本小说的全部设定。你手动把设定贴进去，字数一多就溢出；你不贴，它就自由发挥。结果就是：单章读着还行，连起来一团乱麻。
目前 GitHub 上的 AI 写小说工具，基本都卡在这个坎上。Long-Novel-GPT（1.1k stars）用 RAG 检索相关段落来维持一致性，但 RAG 只能找到”相关”内容，找不到”矛盾”内容。AI_Gen_Novel（419 stars）探索多 Agent 方向，但还处于实验阶段。dramatica-flow（150 stars）引入了戏剧理论，思路有趣，社区还小。
核心矛盾很明确：AI 的生成能力已经够用，但一致性管控几乎为零。
竞品数据一览
| 维度 | ChatGPT 手动写 🔴 | Long-Novel-GPT 🟡 | InkOS 🟢 |
|---|---|---|---|
| GitHub Stars | — | 1,100 | 6,800 |
| 一致性机制 | 无，靠人工记忆 | RAG 检索相关段落 | 7 真相文件 + 33 维度审计 |
| Agent 数量 | 1（你自己） | 1（单层级 Agent） | 10（全流水线） |
| 自动连续写作 | 不支持 | 需手动触发 | 守护进程，Telegram/飞书推送 |
| 同人文支持 | 无 | 无 | 4 种模式 |
| 可视化界面 | 无 | 基础 WebUI | Studio 全功能工作台 |
| 实测长篇字数 | 看你的耐心 | ~10 万字 | 45.2 万字，31 章 |
6,800 stars 和 1.3k forks 不是虚的——InkOS 是目前这个赛道上社区最大的项目。
为什么写 45 万字不崩：流水线拆解
InkOS 的核心不是某个厉害的 prompt，而是一套 10 Agent 协作流水线。每写一章，10 个角色依次上场：
Radar（雷达） → 扫描平台趋势，知道读者现在爱看什么。可跳过。
Planner（策划） → 根据作者意图生成本章计划，不是随机往下编。
Composer（编排） → 从 7 份真相文件里挑选本章需要的上下文和规则。
Architect（架构师） → 首次建书时出场，定体裁、定规则、建角色矩阵。
Writer（写手） → 正式写稿，有字数管控。
Observer（观察者） → 写完之后提取 9 类事实：人物、地点、资源、关系、情绪、信息、伏笔、时间、物理规则。
Reflector（反射器） → 输出 JSON 增量更新，不是重写全部 Markdown。
Normalizer（校准器） → 字数超了压缩，不够扩展，一次搞定。
Auditor（审计员） → 33 维度连续性检查，对照 7 份真相文件逐项核验。
Reviser（修订者） → 审计不过的，改。默认最多修一轮，可配置。
这条流水线的设计逻辑很清楚：写作和质检分离。写手只管写，审计员只管查，观察者只管记录。没有哪个 Agent 需要同时完成多件事。
打个比方：ChatGPT 写小说像一个人从原材料干到成品，Long-Novel-GPT 像加了个检索助手帮忙查资料，InkOS 像一条分工明确的工厂产线。
7 份真相文件：AI 的长期记忆
流水线能跑起来，靠的是 7 份持久化的”真相文件”——这是 InkOS 最关键的设计。
| 文件 | 内容 | 解决什么问题 |
|---|---|---|
current_state.md | 世界当前状态、人物关系、已知信息 | 人物关系不会突然变 |
character_matrix.md | 角色互动历史和信息边界 | A 知道的事 B 不该知道 |
particle_ledger.md | 资源追踪，带衰减机制 | 灵石不会越花越多 |
pending_hooks.md | 未解决的伏笔线索 | 埋了的坑不会忘记填 |
chapter_summaries.md | 每章元数据 | 回顾不用重读全文 |
subplot_board.md | 多线程剧情进度 | 副线不会凭空消失 |
emotional_arcs.md | 角色情感轨迹 | 人物成长不会断裂 |
注意 particle_ledger.md 里的”衰减机制”——灵石用掉了就是用掉了，不会因为 AI 忘了而重新出现。这解决了 AI 小说中最常见的 bug：资源凭空再生。
还有 character_matrix.md 里的”信息边界”——角色 A 在第三章听到一个秘密，角色 B 不在场。到了第十章，B 不该知道这个秘密。这种”谁知道什么”的管理，手动 prompt 几乎做不到。
33 维度审计：AI 小说的质检流程
每一章写完，审计员会跑一遍 33 项检查。涵盖：
- 角色记忆一致性
- 资源账本平衡
- 剧情线索连贯
- 节奏和情绪弧线
- 未关闭伏笔追踪
- 物理规则遵守（玄幻小说里的”修炼体系”也算物理规则）
实测数据：31 章、45.2 万字，审计通过率 100%。 48 项追踪资源，20 条活跃伏笔，10 条已解决。
话说回来，审计通过不等于写得好。通过只代表逻辑不矛盾、设定不冲突。文笔、节奏、吸引力这些主观指标，机器审计暂时管不了。但”不崩”是”好看”的前提——一个角色连自己的武器都记不住，谈什么精彩。
不只是长篇：短篇和同人文
InkOS 不是只能写玄幻长篇。
短篇模式一条命令出完整故事：
inkos short run \
--direction "都市短篇 婚姻反转 女主证据反杀" \
--chapters 12 \
--chars 1000
产出物：完整小说 + 营销文案 + 封面 prompt + 自动生成封面。对短视频小说赛道的创作者来说，这套输出刚好能直接用。
同人文模式支持四种玩法：
inkos fanfic init --from source.txt --mode canon # 正典续写
inkos fanfic init --from source.txt --mode au # 平行宇宙
inkos fanfic init --from source.txt --mode ooc # 角色重塑
inkos fanfic init --from source.txt --mode cp # CP 向
导入一本已有小说，InkOS 会反向工程出完整的真相文件，然后在这个基础上续写。你可以拿金庸的小说做底，让 AI 写一个令狐冲和东方不败的平行宇宙故事。
导入续写也值得一提——如果你已经手写了前十万字，InkOS 能接手：
inkos import chapters my-book --from existing.txt --split "第.*章"
它会分析已有内容，建立真相文件，然后从你停笔的地方继续。
AI 味检测：自己查自己
InkOS 内置了 AI 味检测功能：
inkos detect my-book --all --stats
它会扫描生成的文本，识别重复词汇、句式单调、风格化模式。配合”风格分析”功能，你可以导入一位作者的文风指纹，让 InkOS 模仿：
inkos style analyze reference.txt
inkos style import reference.txt my-book
检测到 AI 味重的段落会被标记，审计流程中自动触发修改。这比写完之后人工逐段排查效率高得多。
Studio 界面：不用命令行也能用
如果你看到前面那些命令行就头疼——InkOS 有一个完整的 Web 工作台：
inkos # 启动 Studio，默认端口 4567
Studio 提供：
- 书籍管理和章节审阅
- 实时写作进度
- 模型配置（可视化填 API Key，支持测试连接）
- 市场分析面板
- AI 味检测面板
- 聊天式交互，支持会话恢复
还有一个全屏 TUI 终端界面，支持自然语言操作。不想打命令，直接说”写下一章，重点写师徒冲突”就行。
模型兼容性
InkOS 走 OpenAI 兼容接口，几乎能接所有主流大模型：
| 厂商 | 支持情况 |
|---|---|
| Google Gemini | 支持 |
| DeepSeek | 支持 |
| Moonshot (Kimi) | 支持 |
| MiniMax | 支持 |
| 智谱 GLM | 支持 |
| 百炼 | 支持 |
| Ollama 本地模型 | 支持 |
| 任意 OpenAI 兼容端点 | 支持 |
更有意思的是多模型路由——你可以让写手用便宜的模型跑量，审计员用聪明的模型抓 bug：
inkos config set-model writer deepseek-v3 --provider deepseek
inkos config set-model auditor kimi-k2.5 --provider moonshot
流水线里的 10 个 Agent 可以各用各的模型。Token 成本敏感的用户，这个功能省的钱是实打实的。
5 步上手
# 1. 安装
npm i -g @actalk/inkos
# 2. 初始化项目
inkos init my-novel && cd my-novel
# 3. 创建一本书
inkos book create --title "吞天魔帝" --genre xuanhuan
# 4. 配置模型（用 Studio 更直观）
inkos # 打开 Studio，在"模型配置"里填 API Key
# 5. 开始写
inkos write next 吞天魔帝
一条 inkos write next 会自动跑完策划→编排→写稿→审计→修订的全流程。挂上守护进程就更省心：
inkos up # 后台自动写，写完一章推通知
值得留意的局限
- 文笔天花板受限于底层模型。InkOS 解决的是一致性问题，不是文学性问题。用 GPT-4o 和用 DeepSeek-V3 写出来的质量差距，InkOS 抹不平。
- 33 维度审计覆盖逻辑一致性，不覆盖”好不好看”。节奏拖沓、对话无聊这类问题，机器暂时判断不了。
- 资源消耗不小。10 个 Agent 跑一章，Token 用量是普通对话的好几倍。用便宜模型能缓解，但别指望免费。
- AGPL-3.0 许可证。商用需注意合规。
写在最后
6,800 stars。10 Agent 流水线。33 维度质检。45 万字实测不崩。
InkOS 不会让 AI 写出下一本《三体》。但它第一次让”AI 写完一本长篇且前后不矛盾”变成了现实。对于网文创作者、同人作者、短视频小说赛道的内容生产者来说，这可能是目前最值得试的开源方案。
GitHub 地址：github.com/Narcooo/inkos