从 D&D 到 AI 故事模拟引擎：让 NPC 自主行动，让世界记住发生过什么

如果把 AI 写小说理解成“给模型一个设定，让它接着写”，就很难解释为什么有些 AI 游戏能让玩家在一个世界里连续冒险数百回合，也很难解释为什么同样的模型有时能扮演一个有秘密、有立场的 NPC，有时却会让所有角色说话都像同一个客服。

《龙与地下城》（Dungeons & Dragons，D&D）提供了一个更有价值的参照。D&D 不只是奇幻世界、职业、装备和骰子。它还有一个持续运行的世界、一组需要被遵守的规则、一群有各自动机的角色，以及一位负责解释规则、扮演 NPC、控制节奏和处理玩家行动后果的 Dungeon Master（DM）。

LLM 加入之后，DM 的部分工作可以交给 AI：理解玩家意图、扮演角色、提出事件、生成场景和对白。但如果只把 DM 做成一个很长的 System Prompt，游戏很快就会遇到记忆丢失、人物性格漂移、物品凭空出现、NPC 知道不该知道的事情、规则前后不一致等问题。

真正值得研究的方向不是“让模型更会讲故事”，而是把它做成一个 AI Story Simulation Engine（AI 故事模拟引擎）：程序负责保存世界事实和执行确定性规则，AI 负责理解、推理、角色扮演、提出可能性和文学表达。它既可以驱动 RPG，也可以成为长篇小说的底层创作工具。

本文重点分析已经公开的产品、开源项目和研究工作，并从中提炼 AI 系统设计方法。项目功能以公开仓库和官方文档为依据；项目自述的能力不等于经过独立测试的质量结论。

一、先区分三类产品：AI Dungeon Master、互动小说和小说工作台

它们看起来都在“让 AI 写故事”，但目标和系统边界并不相同。

类型	用户做什么	AI 主要负责什么	系统必须维护什么
AI Dungeon Master / RPG	扮演角色，描述行动	DM、NPC、规则解释、场景叙述	角色卡、物品、地图、任务、战斗、世界状态
互动小说	选择行动或分支	生成后果、分支、角色互动	故事节点、选择历史、分支状态、剧情条件
AI 小说工作台	设计和创作作品	构思、规划、角色模拟、写作、编辑	作品设定、人物弧光、情节图、伏笔、章节和版本

三类产品可以共享记忆、人物、世界和事件模型，但不能把它们的评价标准混在一起。

RPG 需要回答“玩家做了这件事，世界会发生什么”，所以规则判定、资源管理和玩家行动边界很重要。互动小说强调选择是否真正改变后续体验。长篇小说则不需要每件事都由读者选择，作者还要控制主题、叙事视角、节奏、信息披露和语言风格。

因此，AI DM 的目标不是直接等同于 AI 小说作者。一个擅长即兴回应玩家的 DM，不一定擅长构建几十万字小说的主题结构；一个擅长规划章节的 Writer，也不一定能实时处理玩家绕过预设路线的行动。

二、值得实际体验或阅读代码的产品

1. Friends & Fables：把 AI DM、D&D 5e 战斗和虚拟桌面放在一起

Friends & Fables 是目前最接近“在线 AI D&D 平台”的商业产品之一。官方介绍包含 AI Game Master、世界构建工具、战术回合制 5e 战斗、任务、地图、多人组队和语音朗读。

它的产品价值在于把几个原本分散的部分整合起来：玩家不只是和聊天机器人对话，还能在世界地图和战斗地图中行动，使用法术、物品和能力，接受任务，并与其他玩家一起参与战役。官方称 AI Game Master Franz 会根据玩家选择调整故事，并负责叙事和规则裁决。

从 AI 架构角度，值得观察的是 DM 如何把自然语言行动映射到游戏状态，以及叙事、地图、战斗和任务系统如何共享同一份 Campaign Context。商业产品的内部实现并未公开，因此不能仅凭产品页面断言它使用了哪一种 Agent 框架或记忆算法。

适合：想直接体验 AI DM 产品形态、多人 RPG 和 D&D 规则整合的人。

2. AI Dungeon：自由叙事与长期记忆机制

AI Dungeon 是较早把 LLM 用于开放式互动冒险的产品。它的特点不是严格模拟 D&D，而是让用户通过输入行动持续改变故事。

它的官方文档对记忆设计有比较清楚的说明：

Auto Summarization：把一段历史压缩成较高层次的故事摘要。
Memory Bank：保存并在相关时刻检索过去发生的事件。
Plot Essentials：放置始终需要进入上下文的关键信息。
Story Cards：根据触发词，将特定人物、地点或世界设定动态加入上下文。

这几种信息并不是同一种记忆。摘要负责保留整体进展，Memory Bank 负责找回具体事件，Plot Essentials 负责稳定的核心事实，Story Cards 负责按需注入局部知识。官方也明确指出，模型上下文长度和生成成本是记忆系统必须面对的约束。

这套设计值得借鉴的地方，是不再把“记住故事”理解成无限增加 Prompt，而是将压缩、索引、检索和常驻信息分开处理。

适合：研究开放式互动叙事、上下文管理、长期记忆产品化。

3. Narrative Engine：自托管的长期 AI Dungeon Master

Narrative Engine 是一个 MIT 许可的自托管 TTRPG 引擎，支持 OpenAI-compatible API 和本地 Ollama 模型。它面向跨多次会话的 Campaign，提供世界设定、规则文件、NPC、物品、地图和扩展机制。

这个项目尤其值得关注，因为它不只是一个聊天前端。用户可以把世界 Lore、Ruleset 和可选物品数据作为文件导入 Campaign；系统负责分块、索引和后续召回。规则文件定义 GM 的行为方式、叙事风格、NPC 行为和事件协议，记忆和世界资料则由引擎负责管理。

截至 2026 年 11 月初，仓库仍在积极迭代。近期更新包括 GM operating system 规则集、Prompt Injection 管理和 NPC/世界状态相关修正。它的具体机制应以当前代码和文档为准，不宜把 README 中的“永不遗忘”等产品措辞理解为已经解决了所有长程一致性问题。

适合：研究自托管 AI DM、可配置规则集、长期 Campaign 和本地模型接入。

4. Project Lunar：独立 NPC 心智与反应式世界

Project Lunar 是开源的本地优先叙事 RPG 引擎，而不是一个固定剧情的单体游戏。作者可以创建世界、NPC、地点和阵营，玩家通过行动经历由 LLM 叙述的冒险。

它有几个很值得研究的设计：

Independent Minds：NPC 分别维护自己的情绪、目标、对玩家的看法和秘密计划，而不是所有 NPC 共用一个“世界摘要”。
Witness Filtering：NPC 的知识受到目击范围限制，避免一个没有在场的人自动知道刚发生的事情。
Reactive World：玩家不在场时，世界也会根据故事时间继续变化。
Knowledge Graph：使用 Neo4j 管理实体、关系抽取和规范名称解析。
Four-tier Memory：把记忆分成 SHORT、MEDIUM、LONG 和 MEMORY 等层级，并周期性整理。
Event Store / Persistence：通过事件记录恢复 NPC、物品、剧情种子和记忆等状态。

它还采用了偏叙事的战斗机制：不完全依赖传统 HP 和 Mana，而是让模型结合行动合理性、创造性和情境评估结果。这种设计适合强调故事表达的互动体验，但如果目标是严格的 D&D 规则模拟，就需要另外引入确定性的规则系统。

最值得借鉴的不是某一个 Prompt，而是 NPC 有自己的私有状态、知识边界和秘密计划。人物不再只是等待玩家提问的对话接口。

适合：研究自主 NPC、知识边界、事件驱动记忆和动态世界。

5. AI-GM-Engine：让 LLM 主持游戏，但不让它随意改写事实

AI-GM-Engine 的实现思路很直接：用规则规范和一个小型 Python Helper，让不同 LLM 扮演 Game Master，同时记录跨回合的世界状态。

项目将骰子、数学、记录合并和检查交给 Python Helper。Helper 负责计算，但不替 GM 决定故事。它的设计原则可以概括为：

世界不会只围绕玩家运转。
原因必须先于依赖它的结果确定。
叙述不能反过来改变已经确定的状态。

第三点尤其重要。模型可以说“你从口袋里拿出一把钥匙”，但如果状态记录中没有这把钥匙，叙述本身不应该让物品凭空出现。AI 可以描述事实，不能通过语言直接创造权威事实。

项目使用可读的存档和规则文件，支持继续 Campaign。其 README 也指出，规则文件和世界背景本身会占用上下文窗口；这说明即使使用长上下文模型，世界资料的装载和压缩仍然是工程问题。

适合：研究 LLM 与确定性代码之间的职责边界，以及如何让游戏状态可追溯。

6. NovelClaw：从互动 RPG 转向长篇创作工作区

NovelClaw 更接近长篇小说生成工作台，而不是 D&D 引擎。它将长期写作组织成会话、运行检查、稿件审阅、Storyboard 和 Memory Banks，强调写作、审核和记忆控制是持续的工作区，而不是一次性 Prompt。

它的价值在于把“生成一章”扩展成一个可检查、可继续、可复用故事状态的过程。对于小说系统，记忆不仅要供模型检索，还要让作者知道模型依据了什么、上一轮生成了什么、当前稿件和故事资料是否已经同步。

适合：研究长篇写作中的持续会话、记忆工作区和生成过程检查。

7. SillyTavern：角色卡、Lorebook 和多角色对话的可组合前端

SillyTavern 不是完整的 AI DM 或小说引擎，但它的角色卡、Group Chat 和 World Info/Lorebook 很适合研究角色扮演上下文如何组织。

它的 World Info 支持关键词触发、正则匹配，以及全局、角色、Persona 和单次 Chat 等不同作用域。生成回复时，系统会按配置顺序把匹配到的 Lore 条目插入上下文。

这是一种相对轻量的“按需上下文注入”机制：不是每次把整个世界观都发给模型，而是根据当前对话选择相关资料。缺点也很明显：关键词触发不等于理解了故事语义；如果人物状态和关系变化没有被独立维护，Lorebook 仍然可能停留在静态设定层。

适合：研究角色扮演前端、角色定义、动态 Lore 注入和模型兼容性。

三、真正的 AI 特色：从“一个模型扮演所有人”到“世界中有多个认知主体”

很多 AI RPG 的早期做法，是给一个模型一份世界设定，再要求它同时扮演 DM、主角、配角、旁白和规则裁判。这种方式启动成本低，但很容易出现角色声音趋同、知识边界混乱和剧情完全由最近一次 Prompt 决定的问题。

更有意思的做法，是把世界中的角色看作不同的认知主体。它们不一定需要各自部署一个模型，但必须有独立的状态、记忆、目标和可见信息。

1. NPC Agent 不应该只是 Character Prompt

一张传统角色卡通常包含姓名、外貌、性格、背景和说话风格。它能让模型模仿一个角色，却不一定能让角色持续地像一个人一样行动。

一个可运行的 NPC 至少需要几类状态：

状态	含义	示例
Identity	相对稳定的身份和经历	身份、职业、成长背景
Traits	性格倾向和价值观	多疑、重承诺、厌恶权威
Goals	长期目标与短期目标	保护家族、争取职位
Beliefs	对世界和他人的判断	误以为盟友已经背叛
Knowledge	亲眼所见、听闻、推断	知道仓库失火，但不知道纵火者
Relationships	对其他人物的关系认知	信任、亏欠、嫉妒、恐惧
Emotional State	当前情绪和压力	愤怒、疲惫、羞愧
Private Plans	不公开的打算	私下联系敌对阵营

这些字段不能全部当成永久事实。性格和经历相对稳定，目标和情绪会变化，信念可能被证据推翻，关系会受到具体事件影响。系统还需要记录每次变化的来源：是谁做了什么、NPC 当时知道什么、它如何解释这件事。

NPC 的下一步行动不应该由“当前场景需要什么剧情”直接决定，而应该从它的目标、信念、资源、风险和当前局面中推导出来。DM 可以控制叙事节奏，但不应随意替人物抹掉自己的动机。

2. 角色必须有自己的知识边界

角色一致性不仅是说话风格一致，更重要的是它不能知道不该知道的事情。

例如，A 在密室里与 B 讨论一项阴谋，C 当时不在现场。之后 C 可以通过线索、传闻或他人告知逐步获知，但不能因为模型看过完整聊天记录，就直接把秘密当作 C 的知识。

这要求区分至少四种内容：

World Truth：世界中真实发生的事情。
Character Knowledge：某个人实际知道的内容。
Character Belief：某个人认为是真的内容，可能是错误的。
Reader Knowledge：读者已经看到或被暗示的内容。

这四种状态不能混成一份“故事摘要”。Project Lunar 的 witness filtering 是一个很具体的工程例子；在小说创作中，它还可以延伸到谣言传播、情报不对称、误会和悬念管理。

如果一个人物在没有证据的情况下突然猜中真相，可能不是聪明，而是作者和读者之外的模型上下文泄漏到了角色认知中。

3. NPC 应该能在主角不在场时行动

“世界是活的”不等于每个 NPC 每秒都要调用一次 LLM。那样既昂贵，也没有必要。

可以按事件和重要性采用不同的模拟频率：

普通人物：只在与其相关的事件发生时更新。
有持续目标的关键 NPC：在时间推进、资源变化或关键事件发生时更新。
当前场景中的重要角色：需要更细粒度地生成意图和反应。
影响主线的角色：在重要转折前后进行专门的状态检查。

这种分层模拟可以减少模型调用，也让“后台人物行动”有明确触发条件。比如主角离开城市三天，商会会因为债务到期采取行动；被主角拒绝的盟友可能改变立场；一个没有被及时处理的威胁可能已经造成后果。

这比让 DM 每隔几轮随意生成一个“世界新闻”更可信，因为事件有行动主体、目标、资源和因果链。

4. 多 Agent 的价值是认知和职责分离，不是 Agent 数量

在系统设计中，“一个 Agent 对应一个人物”听起来很自然，但并不意味着每个 NPC 都需要一个独立的模型实例。

可以将 Agent 分成两层：

角色层：每个重要人物有独立的角色状态、记忆、目标和知识视图。执行时可以共享同一个模型服务，通过不同的上下文和工具调用模拟不同角色。

职责层：DM/Director 负责场景和节奏；NPC Simulator 负责角色行动提案；World Simulator 负责世界事件；Rules Engine 负责规则判定；Narrator 负责叙述；Memory Manager 负责提取和检索；Continuity Reviewer 负责检查事实和因果。

这种分工比“创建几十个 Agent，然后让它们互相聊天”更容易控制。Agent 的数量应该由需要独立维护的状态和职责决定，而不是为了追求 Multi-Agent 的形式。

四、AI 叙事引擎的核心技术模块

1. Intent Parsing：把自然语言转成行动意图

玩家可能输入：“我不直接进门，先绕到酒馆后面，看看有没有人从仓库出来。”

系统需要把它理解成一组可执行意图，而不是把整句话直接交给 Narrator 自由续写：

行动主体：玩家角色。
目标：观察仓库出入口。
方式：绕行、隐蔽观察。
风险：可能被发现。
预期结果：获得现场信息，不保证成功。

LLM 擅长把自然语言映射成结构化意图，但不能独自决定最终状态。程序可以检查角色位置、行动成本、时间消耗和可用资源；规则系统再决定是否需要检定。

2. World State：事实由系统维护，而不是由模型“记住”

世界状态至少包括人物、地点、物品、资源、任务、阵营、时间和事件。它应该有明确的权威来源。

例如：

物品是否在角色背包中，由 Inventory State 决定。
某扇门是否上锁，由 Location State 决定。
NPC 是否死亡，由 Character State 决定。
一场战斗是否结束，由 Combat State 决定。
某人是否知道秘密，由 Character Knowledge 决定。

LLM 可以提出状态变更，例如“角色把钥匙交给守卫”，但变更应该经过验证，再写入权威状态。不能让模型在叙述里说钥匙已经交出，就自动把数据库中的钥匙删除。

推荐采用事件记录和当前状态并存的设计：

Event Log 保存发生过什么、谁触发、时间和证据。
Current State 保存当前可快速读取的状态。
State Projection 根据事件更新当前状态。
Rewind/Branch 可以从事件历史恢复或分叉。

这样既能快速读取当前世界，也能解释某个状态为什么变成现在这样。

3. Memory：不要把所有历史都塞进上下文窗口

长期叙事的记忆可以拆成多个层次：

记忆层	保存什么	何时使用
Working Context	当前场景、最近几轮互动	每次生成
Episodic Memory	具体事件、对话、行动结果	需要回忆某次经历时
Semantic Memory	世界设定、人物关系、稳定知识	需要理解人物或世界时
Character Memory	某个角色亲历、听闻和相信的事情	NPC 做决定时
Story Summary	较长时间跨度的阶段摘要	跨章节或跨 Session
Canonical State	物品、位置、生命状态、任务等权威事实	规则判定和状态校验

这里需要特别区分“记忆”与“事实”。模型生成的摘要可能漏掉细节，也可能把推断写成事实。摘要可以帮助检索，但不能替代原始事件和权威状态。

AI Dungeon 的 Memory Bank 和 Auto Summarization、Project Lunar 的分层记忆、Narrative Engine 的长期 Campaign 管理，分别体现了产品层面的不同实现方向。

一个可行的检索流程是：

根据当前场景识别人物、地点、事件和目标。
检索相关的角色记忆、世界资料和历史事件。
过滤角色没有资格知道的信息。
将高优先级事实、近期上下文和相关记忆组装成有限 Prompt。
生成后抽取候选记忆和状态变更。
对候选记录去重、校验、关联证据，再写入存储。

Embedding 相似度只是检索手段之一。对于“谁在什么时候把戒指交给谁”这种事实，实体、时间和关系查询往往比语义相似度更可靠。

4. Plot Director：AI 负责规划，但不能把故事写成固定状态机

DM/Director 的工作不是每回合都生成一个更大的敌人，而是判断当前故事处于什么状态：

当前人物各自想要什么？
哪些目标互相冲突？
哪些信息已经公开，哪些仍然隐藏？
当前有哪些未解决的问题？
哪个事件能自然地改变人物处境？
如果没有人采取行动，世界会发生什么？
当前场景需要推进、停顿、转向，还是让人物关系发生变化？

Director 可以提出若干候选事件或场景计划，再由规则、世界状态和人物动机筛选。它应该能调整计划，而不是为了完成预设大纲强迫人物做出不符合动机的行为。

小说创作尤其要允许计划被新发现改变。人物的意外选择可能比原定剧情更有价值。系统应记录计划变化和受影响的后续节点，而不是把临时生成的建议自动升级为 Canon。

5. Narrator：叙事不是状态更新的副产品

Narrator 的任务是把已确定的行动和结果写成读者能够体验的场景。它可以选择叙事视角、描写密度、句子节奏、信息披露顺序和对白潜台词。

这里应该明确分离两种输出：

Simulation Result：发生了什么、人物做了什么、状态如何变化。
Narrative Text：读者如何看到这些事情。

同一个事件可以写成紧张的动作场景，也可以写成克制的心理描写；事实不变，叙述体验不同。

对于小说，文学质量不能被规则引擎取代。人物状态正确、事件逻辑完整，只能说明故事没有明显的结构错误，不代表文字有感染力。Narrator 需要有作品自己的 Style Sheet、叙事视角和文学目标，而不是把“准确复述模拟结果”当成唯一任务。

五、AI 与传统规则引擎应该怎样分工

D&D 式系统最容易犯的架构错误，是让 LLM 同时承担规则裁判和故事叙述。语言模型是概率性生成系统，适合处理模糊意图和开放表达，不适合成为 HP、骰子、库存、金钱和状态转移的唯一权威。

建议采用以下分工：

任务	推荐执行者	原因
理解玩家行动	LLM	自然语言意图复杂且多样
提出角色行动	LLM + Character State	需要结合动机、信念和情境
选择检定类型	LLM 提案 + Rules Engine 校验	需要理解语义，也要遵守规则
骰子与数值计算	确定性代码	结果必须可复现
背包、金钱、生命值	数据库/状态引擎	不能由叙述随意改变
NPC 知识边界	数据和访问过滤	防止全知视角泄漏
事件因果关系	结构化事件模型 + Reviewer	保证后续事件有依据
章节和场景写作	LLM Narrator	需要文学表达
伏笔与读者信息	Story Graph + LLM 分析	既有结构关系，也有叙事解释

一个关键原则是：LLM 可以提出动作和解释，但不能单方面成为世界事实的写入者。

也不应该把所有规则都写成死板的硬约束。游戏规则中的骰子、资源和战斗结果通常需要确定性；人物的动机、情绪和创意选择则需要保留弹性。系统必须区分“违反规则”和“出乎预料但合理”。

例如，一个胆小的人物在关键时刻选择牺牲自己，不能因为 Character Sheet 上写着“胆小”就被判定为不合法。系统应检查此前的经历、关系、压力和选择成本，让人物变化有依据，而不是把人物标签变成状态机。

六、研究工作给出的信号：角色模拟可能比直接续写更有效

这不只是工程师的架构偏好，也有研究工作在探索类似方向。

1. Multi-Agent Based Character Simulation for Story Writing（In2Writing 2025）

这篇论文提出一个两阶段故事生成系统：

Role-play：让由 LLM 驱动的角色 Agent 按时间顺序演绎故事。
Rewrite：再把角色模拟结果整理、改写，使其符合预先给定的叙事计划。

它与“根据大纲直接生成下一段正文”的常见方法不同：先让人物依据自己的角色状态互动，再把互动结果转化成符合整体结构的故事文本。论文报告称，该方法生成的故事比两个 LLM 基线方案更受评估者偏好。

值得注意的是，这并不证明角色 Agent 越多越好，也不意味着模拟出来的对话可以直接作为小说正文。它支持的是一个更具体的判断：在某些故事生成任务中，先模拟人物行动，再做叙事整理，可能比直接从大纲续写更有效。

论文：Multi-Agent Based Character Simulation for Story Writing

2. Agents’ Room（ICLR 2025）

Agents’ Room 将复杂叙事任务拆分成多个子任务，由不同的专用 Agent 协作完成。论文还发布了 Tell Me A Story 数据集和面向长篇叙事的评估方法。研究报告显示，专门化协作生成的故事在专家评估中优于基线系统。

它对工程设计的启发是：小说写作不是一个单一能力。构思、人物、情节、叙事表达和评估可以有不同的职责和中间产物。Agent 的拆分应围绕任务和输出，而不是只把一个 Prompt 复制成多个角色名称。

3. DOME（NAACL 2025）

DOME：Generating Long-form Story Using Dynamic Hierarchical Outlining with Memory-Enhancement 研究长篇故事中的动态分层大纲和记忆增强。

它的两个关键机制是：

Dynamic Hierarchical Outline：把规划与写作结合起来，让大纲能适应生成过程中的变化。
Memory Enhancement Module：基于时间知识图谱存储和检索生成内容，并使用 Temporal Conflict Analyzer 检查时间和上下文冲突。

它说明长篇故事的规划不能完全固定，也不能完全放任模型自由续写。大纲需要在较高层面保持方向，在较低层面根据新情况调整；记忆则应该能表达时间和关系，而不仅是自然语言摘要。

七、从这些项目中可以提炼出的架构

如果要构建一个既支持 RPG、互动小说，也能辅助长篇小说创作的系统，建议把底层设计成共享的 Story Simulation Core，而不是为每一种产品重新做一套记忆和人物系统。

                    Story World
       世界设定 / 地理 / 历史 / 规则 / 阵营
                         |
          +--------------+--------------+
          |                             |
   Character System              World Simulation
   人物状态与认知                  事件与环境变化
   目标 / 信念 / 关系              时间 / 资源 / 因果
   私有记忆 / 秘密计划              阵营 / 地点 / 事件
          |                             |
          +--------------+--------------+
                         |
                 Story Director / DM
            情节规划 / 冲突 / 节奏 / 行动提案
                         |
                Rules & State Engine
            规则判定 / 状态校验 / 事件提交
                         |
                  Narrative Engine
             视角 / 场景 / 对话 / 文学表达
                         |
                 Story State Update
          记忆 / 人物弧光 / 关系 / 伏笔 / 时间线
                         |
                   Next Turn

这个架构有几个重要边界：

World State 是权威事实层。 模型不能通过叙述直接改写它。

Character State 是人物认知层。 每个人物知道什么、相信什么、想要什么，应该独立维护。

Story Director 是规划层。 它决定当前有哪些值得发生的冲突和选择，但不应该替人物决定所有行为。

Narrative Engine 是表达层。 它负责把结果写得好看，而不是为了让状态字段完整而牺牲文学性。

Memory Manager 是跨回合连续性层。 它负责把事件、人物和关系变化整理成可追溯记忆，并在正确的时间召回。

同一套 Core，三种运行模式

模式	输入	Director 的职责	输出
RPG	玩家行动	判断行动后果、世界响应和任务进展	互动叙事、战斗和状态变化
Interactive Fiction	玩家选择	选择分支、生成后果和新选择	分支故事与新场景
Novel Writing	作者目标和章节计划	推演人物行动、提出情节候选	场景草稿、章节正文和审核证据

小说模式与 RPG 模式的关键区别是：RPG 以玩家行动为主要驱动；小说模式以作者的创作意图为上层约束，但允许人物模拟产生作者原先没有想到的可能性。作者可以选择、修改或拒绝这些可能性。

八、真正困难的地方：AI 叙事系统还没有解决什么

1. 长期记忆不等于长期理解

记忆库里有一条记录，不代表模型在正确的时机会检索它；检索到了，也不代表模型会正确理解它。摘要可能把“人物怀疑某人”压缩成“某人是叛徒”，一次错误写入就可能在后续几十轮不断放大。

所以需要保留原始事件、来源、时间、主体和置信状态。模型生成的摘要应当是索引和辅助材料，而不是事实的唯一副本。

2. 多 Agent 可能放大错误，而不是提高智能

如果 Writer、DM、NPC 和 Reviewer 都从同一份错误记忆出发，它们可能互相确认错误。Agent 数量增加也会带来更多上下文、更多状态同步和更多模型调用。

多 Agent 的收益必须通过任务拆分和对照评估证明。不能只看系统是否有多个 Agent，而要看它是否减少了角色知识泄漏、提高了人物行为差异、改善了长程剧情一致性。

3. 自主 NPC 不等于每个角色都要有完整人生模拟

并不是每个路人都需要独立目标规划和长期记忆。系统应根据人物重要性、与当前事件的关联程度和叙事价值分配模拟预算。否则成本会快速增长，故事也会被大量无关的后台活动拖慢。

4. 规则正确不代表故事精彩

一个完全遵守世界规则、时间线和人物状态的系统，也可能写出非常平庸的故事。模型可能不断选择最安全、最常见的情节，让所有人物趋于合理但无趣。

创意需要多种可能性、价值冲突、意外选择和审美判断。系统可以帮助发现逻辑漏洞，但不能把“没有漏洞”误当成“值得阅读”。

5. 不能把人物弧光变成固定状态机

人物的变化经常是反复的、迟缓的，甚至表面和内心相互矛盾。一个人可能已经知道自己错了，却仍然按照旧习惯行动；也可能为了某个人做出一次突破，但并没有从此彻底改变。

人物模型应该记录变化的证据和张力，而不是强迫人物按照“胆小—勇敢”“自私—无私”这样的单向标签推进。

九、如果要做一个真正有价值的 AI 小说引擎，应该先实现什么

不建议一开始就追求完整的开放世界、实时 NPC 群体模拟和多人战斗。先把几个最能影响长篇创作质量的能力做扎实：

Canonical Story State：人物、事件、时间、物品、关系和世界规则有结构化记录，且每次变化都能追溯来源。
Character Knowledge & Belief：人物知道什么、相信什么、误解什么分开维护，避免模型全知视角泄漏。
Independent Character Goals：主要人物有自己的目标、资源、秘密和行动计划，能够在主角不在场时合理变化。
Event & Causal Graph：记录事件之间的因果、依赖、触发条件和后果，支持调整大纲时发现受影响的情节。
Dynamic Story Director：根据人物行动和世界变化提出新的剧情可能性，同时保留作者对关键方向的控制。
Literary Narrator：把模拟结果转化为具有视角、节奏、情绪和风格的文学文本，不能退化为状态报告。
Continuity & Creative Review：分别检查事实连续性、人物行为可信度和文学表达；审核结果应给出证据与修改建议，而不是只给一个分数。

评估也应该分层进行：

状态正确性：物品、位置、时间、任务和规则有没有被错误改写？
知识边界：角色是否知道了没有机会获知的信息？
人物一致性：角色是否有独立目标，行为变化是否有依据？
因果连贯性：事件是否有原因，结果是否影响后续？
创意多样性：不同人物是否会提出不同方案，剧情是否总落入同一类套路？
文学质量：人物是否有吸引力，场景是否有感染力，文字是否有自己的声音？

其中，前五项可以通过结构化测试、模拟场景和对照实验发现一部分问题；文学质量仍然需要人工阅读和判断。不能用自动指标替代作品本身。

结语：让 AI 不只是续写故事，而是参与故事世界的运行

D&D 的启发不是给小说加上等级、装备和骰子，而是把故事理解为一个持续运行的世界：人物有自己的目标，行动会产生后果，信息不会自动共享，世界不会因为主角暂时离开就停止变化。

AI 的真正特色也不只是它能生成自然语言，而是它可以在同一个系统中承担多种认知工作：理解行动、模拟人物、提出事件、检索记忆、规划冲突、解释规则和生成叙述。要让这些能力可靠协作，就必须把模型的概率性判断与程序的确定性状态管理分开。

对于小说创作，最有价值的变化可能是：先让人物基于自己的目标和认知做出选择，再让 Narrator 把这些选择写成文学。 作者不再只是让模型沿着大纲补字，而是可以观察人物之间的冲突如何产生新情节，再决定哪些变化值得成为作品的一部分。

这不是让 AI 接管作者。相反，世界模拟可以提供更多意料之外但有依据的可能性；作者仍然决定作品的主题、方向、取舍和最终表达。一个好的故事引擎应该扩大创作空间，而不是把文学创作变成一场自动执行的工作流。

参考资料与项目

开源项目

Project Lunar —— 本地优先的叙事 RPG、独立 NPC 心智、分层记忆、知识图谱和反应式世界。
Narrative Engine —— 自托管 AI DM、Campaign、规则集、世界 Lore 和长期记忆。
AI-GM-Engine —— 规则规范、存档和确定性 Python 计算辅助。
NovelClaw —— 长篇写作工作区、会话检查、稿件审阅和记忆管理。
SillyTavern —— 角色卡、Group Chat、World Info/Lorebook 和多模型前端。

商业产品与官方文档

Friends & Fables —— AI Game Master、D&D 5e 战斗、世界构建和多人虚拟桌面。
AI Dungeon —— 开放式 AI 互动冒险。
AI Dungeon: The Memory System —— Auto Summarization、Memory Bank 与上下文构建。
AI Dungeon: Plot Components —— Story Summary、Plot Essentials 和 Story Cards。
SillyTavern: World Info —— Lorebook 的触发、作用域和上下文插入策略。

研究论文

Multi-Agent Based Character Simulation for Story Writing (In2Writing 2025) —— 通过角色 Agent 先进行 Role-play，再 Rewrite 以贴合叙事计划。
Agents’ Room: Narrative Generation through Multi-step Collaboration (ICLR 2025) —— 将叙事生成拆分为专用 Agent 协作的子任务。
Generating Long-form Story Using Dynamic Hierarchical Outlining with Memory-Enhancement (NAACL 2025) —— 动态分层大纲、时间知识图谱记忆和时间冲突分析。