Onkos 长篇小说创作伙伴

长篇创作的核心挑战：信息过载与叙事断裂

在创作超过数十万字乃至数百万字的长篇小说时，作者面临两个核心挑战。其一是上下文过载：在撰写第100章时，AI模型需要理解前99章的所有情节、人物状态、已埋设的伏笔和设定的规则，这远远超出了任何大语言模型的上下文窗口限制。其二是连贯性维护：人工记忆难以确保“林风在第30章使用的法器名称”与“第150章他仍在使用同一件法器”保持一致，伏笔（如“神秘戒指”）可能被遗忘，角色性格可能在不同章节出现不一致的描写（OOC）。这些“叙事漏洞”会严重破坏读者的沉浸感。

Onkos 的解决之道：多维记忆与结构化管理

Onkos 并非一个简单的写作接口，而是一个围绕 持久化叙事记忆 构建的协作系统。它通过以下核心模块来应对上述挑战：

• 6级分层上下文压缩 (context_retriever.py)：这是系统的核心。它不尝试一次性塞入全文，而是为当前创作任务智能组装“上下文包”。这个包会动态包含全书摘要、当前阶段/弧线摘要、前章摘要，以及通过fact_engine.py检索出的相关事实（如主角当前境界、关键物品位置）和活跃伏笔。这就像为AI提供了动态的、有重点的“回忆”。
• 事实与图谱引擎 (fact_engine.py & knowledge_graph.py)：所有从文中提取的重要信息（人物关系、物品归属、事件结果）都会被结构化存储为事实，并关联到person/faction/location等类型的知识图谱节点。这使得查询“苏瑶的背景是什么”或“青云宗与天剑宗的关系”能直接检索到精确答案，而非依赖模型模糊的记忆。
• 角色心理建模 (character_simulator.py)：在创作或检查时，系统会模拟角色的Big Five人格特质、行为禁忌和说话风格，用于检测行为是否偏离设定（OOC），帮助作者保持角色一致性。
• 伏笔追踪 (hook_tracker.py)：新埋设的伏笔会被系统记录，并设置“预期回收章节”。系统会定期检查超期未收的伏笔，提醒作者“那枚神秘戒指的伏笔已经拖了50章，是否该处理了？”。

标准化工作流与关键操作

Onkos 强制实施一套七步标准化创作流程，确保每章完成后，叙事数据库都得到可靠更新：

1. 获取上下文：调用 for-creation 获取与该章相关的所有压缩上下文。
2. 阅读大纲：检查并确认该章的内容规划。
3. 创作正文：基于上下文和大纲进行写作。
4. 存储章节：调用 store-chapter 将内容分段存入数据库。
5. 提取实体：调用 extract-entities 从新内容中识别人物、地点等。
6. 录入事实与伏笔：将重要新事实 set-fact，并可能 plant-hook 新伏笔。
7. 更新摘要：更新章节摘要，定期更新弧线摘要。

修订已写章节是高风险操作。修改前必须先调用 analyze-revision 进行影响分析，评估对后续章节和事实的波及范围。执行修改时，需先 clear-chapter 清理该章旧数据，再重新执行创作和存储流程，以避免数据矛盾和冗余。

适用边界与注意事项

• 技术依赖：需要 jieba 分词库和可选的 ONNX 语义模型（用于更智能的检索）。未安装 ONNX 模型时，系统会降级为基于关键词的 FTS5 搜索。
• 协作性质：这是一个增强创作者能力的工具，而非完全自动生成小说的黑箱。情节构思、文笔润色和最终决策权始终在作者手中。系统负责的是信息管理、一致性检查和上下文维持。
• 数据一致性：所有状态（事实、伏笔、图谱）都存储在统一的 SQLite 数据库 (data/novel_memory.db) 中。操作数据库的脚本参数遵循 Python 命名风格（如 current_chapter），通过 command_executor.py 统一调度。
• 主动式智能体：设计上要求智能体主动推进，例如在创建角色时主动建议人格模型，在规划阶段主动提议故事弧线结构，而非被动等待指令。这要求使用者与AI建立高效的协作节奏。