基于LangGraph与本地大模型的AI长篇小说创作系统：Smart State模式解析

简介在人工智能内容生成领域大语言模型因其强大的文本生成能力备受关注。然而其固有的上下文窗口限制和缺乏长期记忆能力使其在生成长篇、连贯的叙事内容时面临挑战。为解决这一问题业界常引入外部记忆机制和状态管理策略。其核心原理在于将复杂的创作状态如人物档案、世界观、情节脉络进行结构化持久化存储并通过向量检索等技术在每次生成时动态组装最相关的上下文从而突破模型自身的记忆瓶颈。这一技术方案的价值在于它使得AI能够辅助人类进行大规模、高复杂度的内容创作如百万字小说的持续生成同时保持情节、人物和世界观的一致性。其应用场景广泛不仅限于小说创作还可扩展至游戏剧情生成、剧本写作、互动叙事等需要长期状态维护的AIGC领域。本文深入探讨的“Smart State”模式正是这一方向的工程实践它结合了LangGraph框架与本地部署的大模型构建了一套完整的、可处理文件级长期记忆的AI创作系统。1. 项目概述当AI开始写百万字小说最近在捣鼓一个挺有意思的东西一个能写长篇小说的AI系统。这听起来可能有点科幻但确实是我花了大量时间基于现有的大模型技术栈折腾出来的一个“AI长篇小说创作系统”。它的核心目标很简单让AI能像人类作家一样持续创作一部几十万甚至上百万字的小说并且保证情节连贯、人物不崩、世界观不塌。为什么这件事有挑战用过ChatGPT或者Midjourney的朋友都知道当前的大模型有个通病——“健忘症”。你让它写个几百字的短文它可能文采斐然但你让它接着上一章写下一章它很可能把主角的名字、性格、甚至上一章刚发生的关键事件忘得一干二净。这就是所谓的“上下文窗口”限制和缺乏“长期记忆”能力。为了解决这个问题我设计并实现了一套基于“文件级长期记忆”的“Smart State”模式。简单来说就是给AI配了一个超级详细的“创作笔记”和“情节大纲”让它每次动笔前都能快速回顾整个故事的全貌和最新进展。这个系统不是玩具。它已经能稳定支持百万字级别的创作从世界观设定、人物小传到章节细纲、正文生成再到风格统一和情节伏笔管理形成了一套完整的自动化流水线。如果你是对AI内容生成感兴趣的开发者、想探索AIGC在文创领域落地的产品经理或者本身就是一位想借助工具提升效率的网络作家那么接下来的内容或许能给你带来一些实实在在的启发和可复用的代码思路。2. 核心架构与Smart State模式解析2.1 为什么传统的Prompt工程在长文本创作中会失效在深入讲解我的系统之前我们必须先理解问题的根源。传统的、基于单次对话的Prompt工程比如“请写一个关于星际探险的开头”对于长篇创作来说是远远不够的。其失效主要体现在三个方面信息衰减与丢失大模型的上下文就像一块有限的黑板。当你不断写入新的章节内容最早写下的设定比如主角的童年创伤、某个神秘组织的信条就会被挤出黑板彻底遗忘。这直接导致后期人物行为动机矛盾、设定吃书。状态维护的复杂性一部小说的创作状态是极其复杂的多维数据。它包括所有出场人物的最新状态位置、情绪、装备、人际关系、世界的最新动态时间线推进、势力变化、未回收的伏笔列表、正在推进的主线/支线任务进度等。用简单的文本来描述这个状态会变得无比冗长且难以被模型有效解析。生成的一致性与可控性即使你将整个故事大纲一次性喂给模型让它生成第50章模型也可能会忽略大纲中的细微约束或者产生不符合整体基调的“幻觉”写出突兀的情节或对话。因此我们需要一个专门的“状态管理”层来持久化、结构化地维护整个创作项目的核心信息并在每次生成时智能地选取最相关的部分提供给AI。这就是“Smart State”模式要解决的问题。2.2 Smart State模式为AI配备创作大脑Smart State不是一个单一的算法而是一套设计理念和实现模式的组合。它的核心思想是将创作过程视为一个状态机而AI是驱动这个状态机演进的核心引擎所有的长期记忆和上下文都外置于一个精心设计的数据结构中。在我的实现里Smart State由以下几个关键部分组成状态定义首先我们需要定义什么是小说的“状态”。我将其抽象为几个核心的、可序列化的数据模块项目元信息书名、作者、总纲、目标字数、风格基调如轻松幽默的都市异能。人物档案库每个人物是一个独立对象包含基础属性姓名、年龄、外貌、性格标签、背景故事、技能列表以及一个动态更新的“当前状态”字段记录最近章节中的情绪、健康、人际关系变化等。世界设定库地理、历史、势力、货币、力量体系等所有世界观相关的设定条目。情节图谱这不是一个线性大纲而是一个网络。节点是“情节单元”可以是一章也可以是一个关键事件边代表因果关系、时间顺序或人物关联。每个节点包含摘要、关键对话/动作、涉及的伏笔埋下或回收。章节仓库已生成的所有章节的完整文本及其元数据字数、生成时间、关键情节索引。会话上下文最近几次AI生成/用户交互的详细记录用于保持短期内的对话连贯性和风格一致性。记忆的存储与检索这就是“文件级长期记忆”的体现。所有上述状态数据都以结构化的格式我选择了JSON因其通用性和可读性持久化存储在磁盘文件中。整个项目的根目录就是一个完整的“记忆体”。存储每次AI生成一个新的情节单元或章节后系统会自动解析输出内容提取其中涉及的状态变更例如人物A受伤了宝物B被发现了角色C和D的关系变成了敌对并更新到对应的状态文件中。这是一个“写回”过程。检索当需要生成下一段内容时系统不会把整个百万字的小说和所有设定都塞给模型。相反它会根据当前要创作的目标例如“写第121章主角团进入黑暗森林”执行一次“相关性检索”。这个过程会 a. 锁定相关人物主角团成员、森林中的原住民势力。 b. 提取相关世界设定黑暗森林的地理环境、危险生物、传说。 c. 查找相关的前置情节之前哪些章节提到了黑暗森林有哪些伏笔指向这里。 d. 组装成一个精炼的、结构化的“上下文提示包”送给AI模型。这极大地减少了令牌消耗并提升了生成内容的精准度。状态演进引擎这是系统的“智能”所在。它负责决定故事下一步该如何发展。这个引擎可以基于简单的规则如每十章必须有一个小高潮也可以集成一个轻量级的规划模型根据当前情节图谱和人物目标自动推荐接下来最合理的3-5个情节发展方向供用户选择或由AI直接执行。实操心得在定义状态结构时切忌追求一次完美。我最初设计了一个极其复杂的人物关系图谱结果发现AI在生成时很难精准利用这些信息。后来我简化了只保留“当前对其他人物的主要情感倾向信任、敌对、爱慕等 最近一次交互事件”这样的键值对效果反而更好。记住状态结构是为了被高效检索和利用而不是为了人类阅读的百科全书。2.3 技术栈选型为什么是LangGraph 本地大模型要实现上述架构技术选型至关重要。我放弃了直接调用OpenAI API完成所有事情的简单想法原因有三成本、可控性和数据隐私。对于动辄百万字的生成使用GPT-4的成本是天文数字其次我需要深度定制生成逻辑和状态管理流程最后所有的小说底稿我不希望流到第三方服务器。我的核心技术栈如下LangChain / LangGraph这是整个系统的“胶水”和“调度中心”。LangGraph特别适合用来构建有状态的、多步骤的AI智能体工作流。我可以把“检索相关记忆”、“生成章节大纲”、“润色正文”、“更新状态”等每一个步骤定义为一个节点用有向图控制它们的执行流程完美契合Smart State的状态机模型。本地部署的大语言模型我主要使用Qwen2.5-7B-Instruct或Llama 3.1-8B这类中等尺寸的、指令微调效果好的开源模型。通过Ollama或vLLM等工具在本地部署实现完全离线的文本生成。虽然生成速度不如GPT-4但经过精心的Prompt工程和状态管理在长篇叙事的一致性上表现令人惊喜。向量数据库用于实现高效的“相关性检索”。所有的人物档案、世界设定条目、情节单元摘要都被转换成向量嵌入存储起来。当需要为“黑暗森林”章节生成上下文时系统会以“黑暗森林”、“探险”、“未知生物”等为查询词快速从向量库中找出最相关的设定和过往情节。我选用的是ChromaDB轻量且易于集成。应用框架使用FastAPI构建了系统的后台服务提供创建项目、管理人物、触发生成、查看进度等RESTful接口。前端则是一个简单的Streamlit面板用于可视化当前的故事图谱、人物关系和生成进度。这个技术栈的组合在单台配备RTX 4090显卡的消费级PC上就能流畅运行使得个人开发者或小型工作室构建自己的“AI创作助手”成为可能。3. 系统核心模块深度拆解3.1 人物与世界观管理动态档案库人物是小说的灵魂。在我的系统里人物档案不是一成不变的“角色设定纸”而是一个动态更新的“生命记录”。创建与初始化 用户可以通过界面或API创建一个新人物。需要填入基础信息姓名、年龄等并可以用自然语言描述其性格和背景。系统会调用一次LLM将这些描述解析并结构化为一组标签和关键事实。例如描述“他曾经是一名正义的骑士但因被诬陷而家破人亡从此变得沉默寡言、疑心重重但内心深处仍保留着一丝对光明的渴望”会被解析为{ “核心性格标签”: [“坚韧”, “沉默”, “多疑”, “内心矛盾”], “关键经历”: [“曾为骑士”, “遭受诬陷”, “家庭破碎”], “当前动机”: [“查明真相”, “复仇”, “寻求内心的平静”], “初始状态”: { “情绪”: “忧郁/愤怒”, “健康”: “良好”, “人际关系”: {} } }动态更新机制 这是关键。每生成一章后系统会运行一个“状态更新器”。这个更新器其实是一个特定的LLM调用它的Prompt是“请分析以下章节片段找出其中关于人物[人物名]的所有状态变化包括情绪、身体状况、所在地点、与他人的关系变化、获得或失去的重要物品等并以JSON格式输出。” 例如章节中写道“李默在战斗中为保护队友王雪左臂被毒刃划伤虽经治疗仍行动不便。王雪看着他苍白的脸眼中充满了感激与愧疚。” 更新器会输出{ “人物”: “李默”, “更新”: { “健康”: “左臂受伤行动不便”, “情绪”: “坚韧/忍受痛苦”, “关系变化”: { “王雪”: “信任与感激加深” } } }这个JSON会被自动合并到李默的档案中。于是当下一章需要写李默时系统就知道他“左臂有伤”从而影响其战斗动作描写。世界设定的版本化管理 世界观设定同样需要更新。比如在故事中“精灵王国与人类帝国正式缔结盟约”。这条信息会作为一个“世界事件”记录到时间线中并链接到相关的“精灵王国”和“人类帝国”设定条目下标记为“已更新”。这样后续所有涉及两族外交的描写都必须基于这个新状态。3.2 情节图谱与生成规划引导故事走向线性大纲容易限制发挥而完全随机又会导致故事散架。情节图谱是一种折中且强大的方案。图谱的构建 每个情节单元Chapter Node包含ID和标题内容摘要由AI生成后总结出场人物列表涉及的关键地点/物品埋下的伏笔Foreshadowing列表回收的伏笔Payoff列表与前驱节点的关系如“紧接着”、“三个月后”、“另一条故事线并行”当新生成一章后系统会自动创建节点并尝试通过LLM分析将其与已有的伏笔列表进行关联。例如新章节中“主角发现了半块玉佩”LLM会判断这是一个新的伏笔系统便将其加入全局“未回收伏笔池”。智能规划下一章 这是系统的“导演”功能。当用户点击“生成下一章”时规划引擎会启动状态分析检查当前所有主要人物的“当前目标”和“未解决的冲突”。伏笔检索从“未回收伏笔池”中找出那些已经“酝酿”得足够久比如超过了5章或者与当前人物地点关联度高的伏笔。可能性推演结合以上信息形成几个核心的“情节问题”。例如“面对帝国追兵受伤的李默是选择正面突围还是利用他对王雪的信任设计陷阱那个关于玉佩的伏笔是否可以在这次逃亡中揭示一部分线索”方案生成与选择将这些问题和当前状态打包发送给一个专门负责“构思”的LLM通常使用思维链提示要求其生成3-5个具体的下一章情节发展方案每个方案包括核心冲突、可能结局、以及会涉及哪些伏笔。这些方案会呈现给用户选择或者由系统根据“戏剧张力最大化”等简单规则自动选择一个。注意事项完全依赖AI规划有时会产生过于戏剧化或不合逻辑的情节转折。我的经验是必须加入“人工审核点”。规划引擎生成的3-5个方案最好由用户作者来最终拍板选择哪一个。这保留了人类的创作主导权AI则承担了“超级创意助理”的工作提供了大量可能被人类忽略的优秀选项。3.3 文本生成与风格控制保持文笔一致有了精准的上下文和明确的情节方向最后的文本生成反而是相对标准化的步骤但其中仍有几个关键技巧。上下文组装 这是Prompt工程的核心。发送给文本生成模型的最终提示是一个结构化的多部分文档# 写作任务 请续写以下小说的下一章。本章标题建议为[规划引擎提供的标题]。 # 故事总览与风格 [项目元信息中的总纲和风格基调] # 当前章节前情提要 [上一章的AI生成摘要] # 核心情节指令 [本次规划引擎选定的具体情节方案描述] # 关键人物当前状态 [通过检索得到的本章将出场所有人物的最新动态档案只摘取最相关的部分] # 相关世界设定 [通过检索得到的与本章场景、事件相关的世界设定条目] # 待回收伏笔提醒 [本次情节方案计划要触及的1-2个伏笔及其背景] # 写作要求 1. 严格依据上述信息创作不得出现人物性格、设定或情节矛盾。 2. 语言风格保持与之前章节一致[风格描述]。 3. 本章字数控制在3000字左右。 4. 在章节末尾请用“---”分隔然后列出本章中发生的、需要更新到人物状态的关键事件每项用“-”开头。 # 正文开始风格一致性训练 为了让AI更好地模仿特定作者的文风我采用了“少样本微调”的思路。但并非直接微调大模型而是构建一个“风格向量”。收集该作者的10-20段代表性文本可以是已完结小说的章节。使用文本嵌入模型如BGE将这些段落转换为向量。计算这些向量的平均向量作为“风格锚点”。在每次生成时将这个“风格锚点”向量也作为检索条件之一从已生成的、用户评价高的章节中找出文风最接近的段落作为“风格参考片段”加入到上下文中。这样模型在生成时就有了一面“文风镜子”来对照。迭代润色 生成初稿后系统并非直接保存。还有一个“自我审阅”环节。另一个LLM实例或同一个模型的不同调用会扮演编辑的角色检查初稿是否存在明显的事实错误如人物伤疤位置错了、语气突变、或者遗漏了规划中要求回收的伏笔。如果发现问题它会提出修改意见并驱动生成模型进行局部重写。这个过程通常只进行1-2轮以避免无限循环。4. 百万字级创作的工程实践与运维4.1 项目初始化与数据流设计启动一个百万字级别的创作项目就像启动一个大型软件工程良好的初始化至关重要。项目目录结构 一个清晰的结构是管理复杂状态的基础。我的典型项目目录如下my_novel_project/ ├── project_meta.json # 项目元信息 ├── characters/ # 人物档案目录 │ ├── li_mo.json │ ├── wang_xue.json │ └── ... ├── world_lore/ # 世界设定目录 │ ├── geography.json │ ├── factions.json │ └── ... ├── plot_graph/ # 情节图谱目录 │ ├── nodes/ # 每个情节节点一个JSON文件 │ │ ├── ch_001.json │ │ └── ... │ └── global_foreshadowing.json # 全局伏笔池 ├── chapters/ # 生成的完整章节 │ ├── ch_001_raw.md # 原始生成文本 │ ├── ch_001_refined.md # 润色后文本 │ └── ... ├── memory_vectors/ # 向量数据库存储ChromaDB └── logs/ # 系统运行日志数据流闭环 系统的运行是一个严密的闭环用户触发用户通过UI或API请求生成下一章。状态检索规划引擎根据当前情节节点检索相关人物、设定、伏笔。规划决策生成多个情节方案用户或系统选择其一。上下文组装根据选定方案组装包含所有相关记忆的巨型Prompt。文本生成调用本地LLM生成章节初稿。状态解析与更新解析生成文本提取状态变更更新所有相关JSON文件。向量化更新将新的情节摘要、人物状态变更等文本生成新的向量存入向量数据库供未来检索。持久化存储将润色后的章节文本保存为Markdown文件。日志记录记录本次生成的所有关键决策、使用的Token数、耗时等信息。这个闭环确保了每一次生成都是在前序所有积累的基础上进行的记忆得以持续累积。4.2 性能优化与成本控制在本地运行大模型性能是必须考虑的挑战。模型推理优化量化使用GPTQ或AWQ等量化技术将7B或8B的模型量化到4bit或5bit精度能在几乎不损失生成质量的情况下将显存占用降低50%以上让RTX 4090甚至4060Ti这样的消费级显卡也能流畅运行。推理引擎使用vLLM作为推理后端。它的PagedAttention技术能极大地提高长序列生成的吞吐量对于需要处理较长上下文组装后的Prompt可能很长的场景特别有效。缓存策略对于“风格锚点向量”、“世界基础设定”等不常变化但每次生成都可能被检索的静态内容将其嵌入向量缓存到内存中避免每次从磁盘或向量库加载。提示词Prompt优化 Prompt是最大的性能开销和效果影响点。精简上下文通过向量检索进行精准筛选是减少Prompt长度的根本。实验表明提供10条高度相关的记忆比提供100条泛泛相关的记忆效果更好且更便宜。结构化压缩在将人物状态、世界设定喂给模型时不使用冗长的自然语言描述而是使用紧凑的、带标签的键值对或列表形式。模型对结构化信息的理解能力很强。分层生成对于超长章节不要试图让AI一口气写完。可以先让AI生成一个详细的“场景序列”然后针对每个场景分别生成正文。这样每个子任务的上下文更短可控性更强。成本考量 本地部署的主要成本是电费和硬件折旧。以一台搭载RTX 4090的电脑为例生成100万字约3000章每章3000字总耗时可能达到数百小时。电费是可观的但相比使用GPT-4 API百万字可能需要数千美元成本仍然低好几个数量级且数据完全私有。4.3 质量评估与人工干预机制AI不是万能的必须建立有效的人工干预节点确保作品质量。自动化质量检查点一致性检查器在状态更新后运行一个简单的规则检查脚本。例如检查同一个人物是否在同一时间出现在两个地点或者某个物品的状态是否出现逻辑矛盾如“已毁坏”又“被使用”。情绪曲线监控跟踪主要人物的情绪状态变化。如果某个角色连续多章处于极端情绪如愤怒而毫无发展系统会标记提示建议在规划下一章时考虑加入情绪转折事件。伏笔健康度报告定期分析“未回收伏笔池”标记那些埋下超过50章仍未有任何进展的“僵尸伏笔”提醒作者可能需要处理。关键人工审核节点 我将创作过程分为“战略层”和“战术层”。战略层人工主导包括项目初始设定、主要人物关系重大转折如结盟、背叛、死亡、主线剧情的关键节点如卷末高潮的规划。这些必须由作者亲自决定。战术层AI主导人工审核包括具体章节的情节方案选择、日常对话的生成、场景描写等。AI提供多个选项作者进行选择或微调。对于生成的正文作者可以快速浏览并使用系统内置的“高亮修改”工具直接对不满意句子进行改写改写后的内容会立即触发局部状态更新。迭代改进循环 系统会记录作者的所有干预行为拒绝了哪些情节方案、修改了哪些文本。这些数据可以被收集起来作为“偏好数据”在未来用于微调一个小的“偏好模型”让系统逐渐学习作者的独特品味和创作习惯使生成的选项越来越贴合心意。5. 常见问题、挑战与未来展望5.1 实战中踩过的坑与解决方案在开发和使用这个系统的过程中我遇到了无数问题以下是几个最具代表性的1. 人物性格漂移问题即使有详细档案AI在生成长对话时偶尔还是会让人物说出不符合其性格的话。例如一个冷酷的角色突然开了个蹩脚的玩笑。解决方案在人物档案的“核心性格标签”之外增加了“典型对话示例”字段。存放2-3段能极致体现该人物说话风格的原文片段可从过往章节中抽取。在生成涉及该人物的对话时将这些示例作为“最相关记忆”高优先级放入上下文效果立竿见影。2. 情节陷入循环或停滞问题AI有时会倾向于重复类似的剧情模式比如“遇险-战斗-胜利”的循环导致故事缺乏进展。解决方案在规划引擎中引入“多样性惩罚”机制。记录最近N章的情节类型如战斗、探索、对话、解密。当规划新章节时如果AI推荐的方案类型与近期类型过于重复则降低该方案的评分。同时在状态中显式地维护一个“故事阶段”标签如开局、发展、危机、高潮、尾声并让规划引擎在不同阶段侧重不同的情节目标开局重介绍发展重冲突高潮重解决。3. 生成速度慢问题随着项目进行状态文件越来越多检索和组装上下文的时间变长整体生成一章耗时从几分钟增加到十几分钟。解决方案索引优化为向量数据库建立更高效的索引。缓存热点数据将主要人物的最新状态、最近5章的情节摘要等“热点”数据常驻内存。异步生成将“状态更新”和“向量化入库”这类I/O密集型任务与AI生成这个计算密集型任务异步化使用消息队列解耦让用户在AI生成下一章的同时系统已经在后台处理上一章的数据了。4. AI的“安全”与“平庸”倾向问题许多经过安全对齐的模型倾向于生成四平八稳、缺乏戏剧冲突和尖锐矛盾的内容导致故事张力不足。解决方案在Prompt的“写作要求”部分明确鼓励冲突和困难。例如加入“请确保本章包含至少一个令人意外的转折或艰难的道德抉择。不要让人物轻易达成目标适当的挫折和困境能使故事更吸引人。” 同时可以考虑使用“角色扮演”提示法让模型完全代入一个“追求戏剧效果最大化”的编剧角色而不是一个客观的叙述者。5.2 系统的边界与局限性必须清醒认识到当前这只是一个强大的“辅助工具”而非“替代作者”。创意上限取决于人类系统能提供选项但无法凭空产生革命性的、前所未有的伟大创意。故事的灵魂、核心的思想表达仍然完全依赖于作者输入的初始种子和过程中的关键决策。情感深度与文学性AI可以模仿文风可以编织复杂情节但在刻画人物内心最细微的情感涟漪、创造那些直击灵魂的比喻和意象方面与顶尖人类作家仍有差距。它生成的是“合格”甚至“良好”的叙事但距离“杰出”的文学作品还有很长的路。对复杂逻辑的把握涉及非常精密的阴谋、硬核的科学推理或需要深厚专业知识的领域如法律庭审细节AI容易出错需要作者具备该领域知识进行严格把关。5.3 可能的演进方向尽管有局限但这个系统的潜力巨大未来可以从以下几个方向演进多模态扩展集成文生图模型根据章节内容自动生成关键场景的概念图、人物立绘甚至为有声书生成配套的背景音效和简单配乐打造真正的“多媒体故事工厂”。交互式创作从“作者-AI”的二元模式转向“作者-AI-读者”的三角模式。可以设想一个功能在发布平台连载时系统分析读者对最新章节的评论情绪和讨论焦点自动生成几个下一章的发展方向选项由读者投票决定实现一定程度的“交互式叙事”。垂直领域深化针对特定类型小说如修仙、科幻、悬疑进行定制化训练和规则强化。例如为修仙小说定制“境界体系管理”、“功法相生相克计算”模块为悬疑小说强化“线索埋设与回收逻辑校验”模块。协作创作平台将系统升级为云端服务支持多位作者共同创作同一部作品AI作为协调者确保不同作者撰写的部分在人物、设定和情节上保持一致。构建这个系统的过程让我深刻体会到AI在创造性工作中最宝贵的价值不是替代而是扩展。它扩展了我们的记忆容量让我们能驾驭更庞大的故事宇宙它扩展了我们的想象力边界提供了无数我们独自思考时可能忽略的可能性它更扩展了我们的生产效率将我们从重复性的、机械的叙事劳动中解放出来让我们能更专注于最核心的创意和情感表达。它不是一个自动写作机器而是一位不知疲倦、博闻强记、总能给出建议的超级创作伙伴。本文还有配套的精品资源点击获取