记忆放在哪：文件、知识图谱，还是数据库
上一篇讲清了「长篇为什么会崩」：状态必须外置。但外置到哪里，这件事本身有分歧——而且分歧比方法本身更大。
有人把全部状态压进一份 12KB 的 Markdown，有人为此搭一整套 Neo4j 知识图谱，还有人干脆把记忆塞进向量索引。三种做法都在生产环境里跑着，都有人用。
选错介质，代价不是「慢一点」，是写了两百章以后想改都改不动。
一、三条路线，三种「形状」
文件派：一切压成可读文本。 代表是 Oh Story——维护一份固定七栏、硬上限 12KB 的上下文文件，写下一章前只读这一份，且这份文件不进正文提示词。
它的好处极其明显：人可读、可编辑、可 diff、可版本管理。你随手打开就能看见「主角现在在哪、哪条伏笔还没收」。写崩了想回滚，复制一份旧的覆盖即可。不需要装任何服务。
图谱派：把关系显式画出来。 代表是 SAGA——用 Neo4j 知识图谱记人物、事件与关系。它的杀手锏是关系查询：谁跟谁是什么关系、某件事的因果链是什么、某条伏笔涉及哪几个人。这些在文件里是「散在两段的字」，在图里是「一条可以直接查的边」。
向量派：让它随时能查。 代表是 Goink——本地中文语义模型 + sqlite-vec 向量索引。它不追求「记住」，追求「找得到」：写到第五十章要找「主角第一次见到那个吊坠」，不用逐章翻，一句话按意思搜出来，离线可用。
二、各自的代价，没人会主动告诉你
文件的代价：关系不显式，会越写越乱。 十二栏撑得住单线叙事，撑不住群像。当一本书有三十个主要人物、五条并行线、上百个伏笔，一份 Markdown 迟早变成谁也读不完的流水账。它的上限是「一个人还能一眼扫完」。
图谱的代价：运维。 搭 Neo4j 意味着装 Java、配数据库、管备份、处理端口与权限。SAGA 的说明里光数据库配置就占了整节，还特意写明「示例配置是一次性的冒烟测试，不是可持久的部署」。你搭的是一套系统，不是一个文件——它需要你有能力维护它。
向量的代价：只能检索，不能校验。 向量索引能帮你「找到相关的片段」，但它不判断对错。它不会告诉你「这里人物性格跟档案矛盾了」。检索解决的是「我找不到」，校验解决的是「我写错了」——这是两回事，别指望一个工具干两件事。
三、SAGA 给的一条关键警醒
SAGA 的说明里有一句最容易被忽略、但最重要的话：
图谱事务、稿件文件、SQLite 检查点是三套独立的存储边界。恢复时要对账，而不是假设某一次写入是原子的。
翻译成人话：你把状态拆到几套系统里，就有几处会不一致。
图谱里主角已经死了，稿件文件里还活着；检查点记着第 47 章，实际只写到第 45 章。这不是哪个系统写错了，是它们本来就不可能同时写完。断电、崩进程、并发写，任何一次意外都会让几套存储错位。
所以选介质之前，先回答一个问题：出故障时，我有没有能力看出哪一套是对的、并把它们对齐？ 如果没有，就别拆那么多套。存储越分散，对账越难。
四、选型表：按你的书写法挑
| 你的情况 | 建议路线 | 理由 |
|---|---|---|
| 单线叙事、人物二十个以内 | 文件 | 一份状态卡加一张伏笔表就够，多余的都是负担 |
| 群像、多线并行、伏笔上百 | 文件 + 图谱 | 关系必须显式，否则查不动 |
| 资料量大、常要「按意思找」 | 文件 + 向量检索 | 补上「找得到」，但校验仍靠文件 |
| 文风试写、短篇、练手 | 只要文件 | 别为三万字搭数据库 |
| 想长期连载（百万字级） | 文件打底 +（图谱或向量择一） | 先稳下限，再补能力 |
一句话原则：先文件，后加装。 文件是所有路线的公共底座——图谱和向量检索最终也是把片段取出来，交给文件里的规则去比对。跳过文件直接上图谱，等于地基不浇直接搭楼。
五、不管放哪，两件事决定成败
第一件：能不能回写。 存储介质再花哨，只要缺了「写完把变化写回去」这一步，整套系统就是死的。这一条不分流派，是共同底线。
第二件：能不能检查。 NovelClaw 给自己的卖点是「可检查的运行」——每一步都能回看、能改，不是丢给你一段文字了事。这个特性在选介质时比「快不快」重要得多：看不到、改不动的记忆，等于没有记忆。
六、结论
介质之争，本质是规模之争。
- 二十万字以前，一份 Markdown 无所不能。
- 五十万字往上，关系开始比内容重要，这时才轮到图谱或向量登场。
- 而无论到哪一步，「回写」和「可检查」永远是横在所有介质之上的两条铁律。
所以别纠结「哪个最先进」。先问你的书多大、你的关系有多乱、你出故障时能不能自救——这三个答案会直接告诉你该用哪个。