十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Webnovel Writer 长期记忆架构深度解析:working、episodic、semantic 三层设计

Webnovel Writer 长期记忆架构深度解析:working、episodic、semantic 三层设计 Webnovel Writer 长期记忆架构深度解析working、episodic、semantic 三层设计【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writerWebnovel Writer 是基于 Claude Code 的长篇网文辅助创作系统支持 200 万字量级连载核心解决 AI 写作中的「遗忘」与「幻觉」问题。本文带你完整拆解它的长期记忆系统working工作记忆、episodic情景记忆、semantic语义记忆三层设计如何组装成一份写作记忆包让 AI 写到第 500 章还记得第 3 章埋的伏笔。为什么长篇网文写作需要长期记忆AI 写短文本没问题但写百万字连载时会遇到两个经典难题遗忘写到后面忘了角色的当前状态、未回收的伏笔幻觉人物关系、世界观规则前后矛盾Webnovel Writer 的解法是把记忆工程化每个章节提交后结构化结果自动沉淀到长期存储每次写作前系统按任务类型组装一份有预算、有优先级的记忆包注入上下文。这套机制的核心代码集中在 memory 模块目录。三层记忆总览一图看懂职责分工记忆层类比数据来源回答的问题working工作记忆书桌本章章纲 最近 3 章摘要 state.json快照我现在该写什么episodic情景记忆近几天日记index.db的近期状态/关系/出场记录最近发生了什么semantic语义记忆长期知识库.webnovel/memory_scratchpad.json故事里什么是恒真的三者都不单独住在某一处而是由 orchestrator.py 中的MemoryOrchestrator在运行时统一拼装。第一层working 记忆——本次写作的书桌working 记忆不单独落盘而是临时拼装来源有三块本章章纲写哪一章就加载哪一章最近 3 章摘要从summaries/目录读取每篇截取 800 字state.json运行时快照主角状态、情节线程、待消歧项对应实现见_build_working_memory()。它保证 AI 动笔时手边就有最近剧情和人物现状。第二层episodic 记忆——最近发生了什么episodic 记忆从index.db取三类近期结构化证据最近的状态变化谁升级了、谁受伤了最近的关系变化新结盟、新对立最近的角色出场记录它的特点是偏近期而非全量召回——这恰好符合写作场景写第 100 章时第 99 章刚发生的转折比第 10 章的细节更关键。第三层semantic 记忆——长期语义真源semantic 层是整个系统的核心存储于.webnovel/memory_scratchpad.json按7 个分类桶组织定义见 schema.py桶存什么网文场景举例character_state角色状态主角的修为、伤势story_facts剧情事实第 N 章的钩子world_rules世界观规则金丹期不能御空飞行timeline时间线事件大战发生的时间点open_loops未回收伏笔神秘玉佩的来历reader_promises对读者的承诺第 200 章前给女主交代relationships人物关系主角与反派的师门关系每条记忆项统一为MemoryItem结构带status状态机active有效/outdated被新值取代/contradicted矛盾/tentative待确认。旧值不删除而是降级为outdated保留审计轨迹——这是防幻觉的关键AI 可以追溯这个设定什么时候改过。记忆写入链路章节提交后的自动沉淀写完一章并提交后writer.py 中的MemoryWriter会把结构化结果映射为记忆项零成本映射state_changes角色状态、entities_new新角色、relationships_new新关系、章末钩子深度提取Data Agent 产出的memory_facts——时间线事件、世界规则、伏笔、读者承诺写入时ScratchpadManager.upsert_item()见 store.py按分类主键去重例如character_state以角色 字段为主键同 key 的旧值自动降级为outdated新值成为当前有效项。超阈值自动压缩当总量超过 500 条compactor.py 分四步瘦身——同 key 旧值只留最新、清理已回收伏笔、50 章以前的时间线合并为摘要、仍超限则按状态和新鲜度全局截断。这保证 scratchpad 不会随连载无限膨胀。老项目可一键回填memory bootstrap命令实现见 bootstrap.py会从现有index.db和summaries/抽取角色状态、历史变化、关系、伏笔区块生成初始长期记忆存量书也能用上这套系统。记忆读取链路按任务分配预算的记忆包写作前MemoryOrchestrator.build_memory_pack()是统一读取入口做四件事构建 working 层 → 构建 episodic 层 → 读取 active 语义项并做相关性过滤章纲命中 来源章节窗口→ 按预算截断。预算分配是这套架构的巧思budget.py任务类型总条目workingepisodicsemanticwrite写作3045%30%25%review审校4035%35%30%query查询2530%45%25%写作时最看重当前章纲查询时最看重近期证据——不同任务拿到不同配比的记忆上下文不浪费。最终这份记忆包由 context_manager.py 注入long_term_memorysection进入主写作上下文。记忆系统没有取代上下文管理器而是作为它的高精度数据源接入。日常运维用 memory CLI 体检你的记忆通过 memory_cli.py 提供的命令你可以随时检查记忆健康度memory stats各桶总量与状态分布memory query按分类/角色查询记忆项memory conflicts找出同主键下多条 active 的矛盾记忆memory dump导出完整 scratchpadmemory bootstrap从历史数据回填当前边界诚实的架构定位这套系统已接入主写作链路但仍建立在ContextManager state/index/summaries生态之上几个已知边界值得了解episodic 层偏近期证据不是全书范围的历史召回semantic 层仍是 JSON scratchpad尚未引入向量检索或图数据库冲突裁决是轻量规则主键去重 旧值降级 冲突统计完整现状说明可参阅官方文档 long-term-memory-architecture-v2.md。总结Webnovel Writer 的长期记忆架构可以浓缩为一句话working 管手边、episodic 管最近、semantic 管恒真三层由编排器按任务预算组装成一份不超支的记忆包。状态机保证旧设定可追溯压缩器保证存储不膨胀CLI 保证随时可体检——这正是它敢于支撑 200 万字量级连载的记忆底座。【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表