从提示词到叙事生产：CanonLoom 0.2.0 的可审计长篇小说人机协作架构

版本： CanonLoom 0.2.0 定稿版 日期： 2026-08-03

文档性质： 系统设计论文；本文报告工程验证，并提出尚待实施的受控质量评估方案。

研究边界： 本文不声称 CanonLoom 的生成质量已经优于其他架构；没有实际采集的数据不以数值结果呈现。

摘要

长篇小说的人机协作并不只是把更长的上下文交给更大的语言模型。随着故事跨越更多章节，系统必须同时维护作者意图、层级计划、章节因果、角色目标、局部视角、读者揭示顺序以及尚未被作者确认的候选事实。若这些状态隐藏在一轮或多轮 Agent 对话中，生成过程通常难以恢复，审查意见难以定位，模型建议也可能在没有明确授权的情况下变成正文事实。

本文提出 CanonLoom 0.2.0，一个面向长篇小说人机协作的文件协议驱动架构。CanonLoom 将写作建模为显式状态转换：作者意图经过层级规划和章契约束，编译为有边界的证据上下文；生成器产生候选正文；结构、连续性、风格和读者承诺审查器生成带证据的 Finding；作者在阶段门禁处批准、退回或延期；最终将正文与状态变更分别结算。系统以 S0–S6 阶段协议、候选与正式状态分离、SHA-256 来源指纹、审查 provenance、可选叙事状态层和”单一主模型 + Python 确定性工具”作为默认运行策略。

本文的贡献不是提出新的语言模型，也不声称自动生成质量已经超过其他架构。我们首先给出一个可恢复、可审计、跨 Agent 的长篇叙事生产模型；其次定义章契、Beat、上下文包、审查报告和状态结算之间的边界；再次给出针对一致性、因果变化、角色能动性、知识泄露、揭示控制、token、延迟、重试和作者负担的完整评估方案；最后报告当前版本的工程验证结果，并明确将文学质量比较留给后续受控实验。该工作旨在为小说作者提供一组短指令可驱动的工作流，也为 Agent 系统研究提供一个能够复盘和恢复的生产协议。

关键词： 长篇小说生成；人机协作；Agent 工作流；叙事状态；可审计性；上下文编译；一致性；作者控制

1. 引言

“写一章小说”看起来像一次文本生成任务，但在长篇创作中，它更接近一个持续的状态管理问题。作者需要先形成创意，再将创意拆解为人物、冲突、世界规则、卷级目标、章级变化和场景节拍；写作过程中还要控制视角、信息差、伏笔、节奏与语言风格；章节完成后，上一章的结果又会成为下一章的约束。任何一层的隐式变化，都可能在数章之后以时间线冲突、动机漂移或过早揭示的形式出现。

现有的大语言模型写作实践往往把任务压缩为”提示词 + 历史文本 + 生成”。这种方式启动成本低，却使几个不同性质的东西混在一起：作者想法与模型提案混在一起，计划与实际发生的剧情混在一起，审查意见与故事事实混在一起，临时上下文与长期记忆混在一起。当作者或 Agent 需要重新运行某个阶段时，系统很难回答以下问题：这段文字依据了哪些材料？哪个版本的章契约束了它？一个事实是作者确认的，还是模型刚刚猜出来的？某个审查问题是否已经修复？如果修复，修复是否引入了新的状态变化？

CanonLoom 0.2.0 从”写作界面”转向”生产协议”。它不试图把作者变成一个复杂 GUI 中的操作员，也不默认把任务拆给多个相互共享隐式上下文的模型。作者只需要使用少量入口，例如初始化项目、开始创意、开始工作、继续工作、检查和结算；系统把复杂性留在文件、阶段产物和可读的 trace 中。Agent 可以通过同一组文件协议读取和写入项目，因此 Codex、Claude 或其他能够访问文件并执行命令的 Agent 都可以参与，而核心状态不依附于某个聊天产品。

本文围绕四个问题展开：

1. 如何将长篇叙事生产表示为可恢复、可审计的状态转换？
2. 章契、Beat、受限上下文和 S0–S6 门禁如何共同限制未经授权的状态变化？
3. 叙事状态层在什么条件下值得引入，它如何影响上下文成本与一致性？
4. 如何设计不把机械分数误认为文学价值的可靠评估？

2. 背景与问题定义

2.1 长篇小说中的状态

CanonLoom 将一部作品的运行状态拆为五类：

• 作者意图（intent）：题材、目标读者、语气、边界、自动化程度和不可妥协的创作原则。
• 正式事实（canon）：作者已经确认的角色、世界规则、时间线、事件和关系。
• 计划状态（plan）：卷、篇章、章节和 Beat 的目标及约束。
• 候选状态（candidate）：模型提出但尚未被作者批准的剧情、事实或修订。
• 叙事运行状态（narrative state）：事件是否发生、谁知道哪些事实、哪些揭示和伏笔仍处于开放状态。

关键点在于，候选状态和正式事实不能使用同一个容器。模型输出的内容即使写得很确定，也不自动取得 canon 权限；一条审查 Finding 即使指出”应该如此”，也仍然只是待处理的建议。状态只有在作者明确批准后才能进入正式结算。

2.2 四类常见失败

上下文失败。 把整部作品塞进提示词会增加成本，也会把当前任务不需要的材料带入生成。过度压缩则可能丢失决定性证据。

状态失败。 角色目标、资源、知识范围、时间位置和世界规则在不同章节之间漂移。模型可能记得某个名称，却忘记该名称在当前视角中不可见。

决策失败。 模型提出的选项、Agent 做出的临时选择和作者批准的决定没有分层，导致”建议”在后续上下文中被当成”事实”。

评估失败。 审查器给出一个总体分数，却没有指出哪句话违反了哪条约束，也没有把问题变成可回退的修订任务。生成器因此可能重复同一个错误，或为了修复局部问题破坏全局状态。

2.3 形式化描述

将项目状态记为 $S_t$，作者在阶段 $t$ 的显式决定记为 $A_t$，当前任务的受限上下文为 $C_t$，生成结果为 $D_t$，审查结果为 $R_t$。CanonLoom 不允许生成结果直接覆盖正式状态，而是要求：

$$S_{t+1}=\operatorname{settle}(S_t, A_t, D_t, R_t)$$

其中 settle 只有在通过门禁且存在作者批准时才允许产生正式状态变化。候选结果可以被保存、比较和修订，但它不能通过普通生成动作直接成为 $S_{t+1}$。

上下文不是整个历史，而是一个带来源说明的选择函数：

$$C_t = f(I, K, P_t, N_t, X_t, Q_t)$$

这里 $I$ 是意图，$K$ 是正式 canon，$P_t$ 是当前计划，$N_t$ 是叙事状态，$X_t$ 是工作流产物，$Q_t$ 是当前任务及其权限。函数的输出必须记录包含项、排除项、选择原因和来源哈希。

3. 设计目标与非目标

3.1 设计目标

CanonLoom 具有六个优先级相同但相互制衡的目标：

1. 可恢复：中断后可以从最后一个合法产物继续，而不是重新依赖聊天历史。
2. 可审计：每个候选正文、审查 Finding 和状态变化都有来源、版本和时间信息。
3. 作者可控：作者拥有正式事实和状态晋升的最终决定权。
4. 跨 Agent：核心协议由 Markdown、JSON、JSONL 和普通目录组成，不依赖某个客户端。
5. 低耦合：确定性检查与语言模型生成分离，默认采用单一主模型加 Python 工具。
6. 渐进增强：先使用最轻量的计划和章契；需要时再启用叙事状态、深度审查和适配器。

3.2 非目标

CanonLoom 不是 GUI 小说编辑器，不是自动出版平台，不是新的基础模型，也不承诺在没有人工评审的情况下生成可发表作品。它不把”更多 Agent""更大图数据库”或”更高自动化”视为必然改进。论文也不把 token 更少、文本更长或某个语言模型的偏好分数直接解释为文学质量。

4. 相关工作与设计定位

长篇故事生成研究已经反复指出，单次提示难以稳定保持长距离结构。DOC 将详细大纲和生成控制结合，用于维持更长范围的情节连贯 [1]；StoryWriter 将大纲、规划和写作拆开，并讨论历史压缩 [4]；DOME 关注动态层级大纲、记忆增强和时间冲突分析 [3]；STORYTELLER 使用结构化情节节点和叙事实体知识表示 [6]。关于悬念的研究强调读者问题、伏笔和揭示的迭代维护 [2]；关于故事评价的工作则提示因果合理性、角色意图、戏剧冲突和读者参与不能由单一表面指标替代 [8, 9]。

另一条研究路线引入知识图谱、世界模型或多 Agent 批评者，以改善长期记忆和多维评价。Collective Critics 表明不同批评视角有助于暴露创造性、连贯性和读者体验问题 [7]；Narrative World Model、MAGNET/ATLAS 等近期方向进一步强调叙事时间、角色知识和世界状态 [10, 11]；知识图谱与文学理论的结合则为长故事的一致性维持提供了另一种结构手段 [5]；SuperWriter-Agent 与 Lost in Stories 则分别提示显式规划、反思和长故事一致性诊断的价值 [12, 13]。不过这些方向也带来状态同步、检索解释性和运行成本的问题。CanonLoom 的选择是先把这些方向的核心概念投影为轻量文件协议，再把数据库、复杂多 Agent 和自动评分保留为可选后端或未来实验变量。

社区项目提供了大量可复用实践：autonovel 展示了从种子到成书的迭代流水线；creative-writing-skills、story-skills 和 novel-creator-skill 展示了 Agent skill、风格文件、连续性审查和门禁；book-os 强调标准、小说状态和手稿的分层；authorclaw、inkos 和 NovelWriter 分别展示了任务日志、时序记忆以及批量审查与多模型后端。CanonLoom 吸收了这些实践中最容易检查和回退的部分，但保持无 GUI、单模型优先和文件协议核心。

因此，CanonLoom 的定位不是声称”比所有竞品更会写”，而是把长篇写作中常被隐含处理的状态转换和作者批准点显式化。相关工作提供了组件启发；本文试图提供一个可操作的组合边界。

论文和项目链接见本文末尾参考文献。

5. CanonLoom 0.2.0 系统架构

图 1 展示了从作者意图到正式手稿的主要数据流。实线表示生产路径，虚线表示提案或待批准变化。

图 1. CanonLoom 将意图、计划、状态、上下文、候选正文、审查和结算分层。审查结果与状态变化不能绕过作者批准点。

5.1 目录与协议

一个项目的核心目录可以简化为：

intent/                 作者意图、边界、风格和自动化偏好
canon/                  已确认的角色、规则、时间线和来源
plan/                   卷、篇章、章契、Beat 和开放问题
workspace/              当前上下文包、任务包和中间产物
drafts/                 候选正文与修订版本
reviews/                结构、连续性、风格和读者承诺审查
memory/narrative-state/ 事件、知识状态和揭示记录（可选）
manuscript/             作者批准后结算的正文
traces/                 run manifest、provenance、handoff 和结算轨迹

Markdown 适合作者阅读和编辑；JSON 适合 schema 验证和工具读取；JSONL 适合追加式事件和状态记录；哈希和 manifest 用于复现上下文。目录名称本身不是隐式权限，真正的写入边界由阶段协议和命令约束共同定义。

5.2 层级规划

计划从项目、卷、篇章、章节契约到 Beat 逐层收窄：

高层计划规定方向和长期承诺，章契规定本章必须发生或不能发生的变化，Beat 把因果骨架拆成可生成单元，场景则保留语言和动作层面的创作自由。下层产物可以提出偏差，但不能静默覆盖上层约束。

5.3 章契不是摘要

章契至少应描述：

• 本章任务和前置条件；
• 必须发生的变化与禁止发生的变化；
• 每个 Beat 的参与角色、动作、冲突和出口；
• 因果变化：什么条件导致什么结果；
• 角色能动性：谁做出不可替代的选择；
• 读者效果：应该产生的问题、压力或情绪变化；
• 揭示更新：哪些信息可以揭示，哪些必须继续隐藏；
• 章节出口状态：下一章可继承的事实和开放问题。

这使章契同时成为生成输入、审查基准和实验记录。它不要求正文逐句复述计划，而要求正文可从证据中解释”计划中的变化是否实际发生”。

5.4 上下文编译

上下文编译器从当前任务所需的材料中建立有边界的 context package。包中记录：

{
  "task": "chapter-draft",
  "included": [{"path": "...", "sha256": "...", "reason": "..."}],
  "excluded": [{"path": "...", "reason": "out_of_scope"}],
  "authority": ["approved-canon", "selected-contract"],
  "narrative_state": "optional-state-snapshot"
}

“被选入”不代表”被模型相信”，而是让输入边界可检查；“被排除”也不是数据删除，而是本次任务不应读取。系统可以从全文上下文逐步演进到目录检索、状态查询和高风险条目优先，但每次升级都应保持包的可解释性。

5.5 模块职责与权限边界

CanonLoom 可以按职责分为四层：

表 2. CanonLoom 的模块职责与权限边界。

该分层体现的是”AI 解耦”，而不是”去 AI 化”。Agent 仍然承担大量创作和解释工作，但 AI 输出被限制为候选、证据和建议；项目的正式状态、阶段迁移和批准记录由文件协议、确定性工具和作者决定共同控制。这样既保留语言模型的创造性，也避免让一个模型同时成为作者、事实源、审查者和批准者。

从数据流看，系统包含三种不同方向：生成流从意图和上下文产生候选正文，验证流从候选正文产生结构化 Finding，批准流从作者决定产生正式结算。三者不能互相替代：验证流不能直接改正文，生成流不能直接改 canon，结算流不能重新发明内容。这个方向性约束是架构可靠性的核心。

6. S0–S6 强约束生产协议

图 2 展示项目实际实现的生产阶段和失败回退。Beat 生成、上下文编译等准备动作属于 S0 的输入准备，不另占一个阶段编号；每个正式阶段都有自己的输入、输出和写入边界。失败时回到最近一个合法产物，不以重新生成覆盖证据。

图 2. S0–S5b 负责准备、生成和证据审查，S6 负责作者批准后的结算。修复优先回到当前阶段或最近的合法边界。

表 1. S0–S6 阶段协议、产物和失败边界。

6.1 强约束的含义

强约束不是让模型不能写出计划之外的新细节，而是要求新细节保持候选身份，直到作者判断它是否改变正式状态。系统强制检查的是边界：输出格式、必需字段、来源存在性、审查证据、状态版本、批准记录和结算目标。文学层面的新意仍然属于生成器和作者共同负责的区域。

6.2 修复循环

当审查发现问题时，系统不以”重新写一遍”作为唯一动作，而是生成包含以下信息的修复任务：

• Finding 的唯一 ID 和严重级别；
• 被违反的契约字段或状态约束；
• 原文证据和来源；
• 允许的修复范围；
• 不能破坏的已有变化；
• 修复后必须重新验证的 Finding。

修复可以被 Agent 执行，但修复结果仍然是候选正文。若问题来自配置、上下文或章契，系统应回退到对应的上游阶段，而不是继续在错误输入上堆叠文本。

7. 叙事状态层

图 3 描述叙事状态的最小模型。CanonLoom 不把状态层视为默认必需的图数据库，而把它作为在作品复杂度增加时可以启用的可选层。

图 3. 事件、知识和揭示状态分别记录”发生了什么""谁知道什么”和”什么时候让谁知道什么”；验证器只提出问题，作者决定是否晋升。

7.1 事件

事件记录发生的动作及其影响，典型字段包括 subject、action、object、时间位置、参与实体、来源和状态。事件可以是 planned、proposed、confirmed 或 rejected，但 proposed 不等于已发生。

7.2 知识状态

知识状态记录角色、读者、叙述者或其他实体在某个时间点可访问的事实。它用于防止视角角色使用尚未获得的信息，也帮助上下文编译器选择与当前视角相容的材料。

7.3 揭示与伏笔

揭示记录 setup、promise、reveal 和 payoff 等阶段。它不替作者决定”应该悬念多久”，而是让延迟揭示成为可见对象，从而能在章节审查中指出某个秘密被过早暴露或某个长期承诺失去追踪。

7.4 采用模式

状态层支持三种使用方式：

• disabled：只使用章契、canon 和审查报告，适合轻量任务。
• optional：在高风险章节或出现连续性问题时启用。
• required：对复杂时间线、多视角信息差或高密度伏笔项目，状态验证成为门禁的一部分。

状态条目经过 Agent 识别后仍应标记为 PROPOSED，只有作者确认才进入 CONFIRMED。正文结算和状态晋升是两个相关但独立的决定，避免作者只批准文字却无意中批准了模型推断出的全部事实。

8. 运行策略与跨 Agent 使用

8.1 默认运行时：单一主模型 + Python

CanonLoom 推荐一个主模型承担计划、生成和大部分审查角色，Python 负责文件扫描、schema 检查、哈希、阶段状态、索引、报告和命令编排。单一主模型减少多模型之间的提示风格差异、上下文重述和隐式状态同步；不同审查视角仍可以作为同一模型的有标签任务，但不能因此获得独立状态写权限。

多模型并非禁止，而是应当作为隔离变量：每个模型读取同一冻结上下文，输出带模型和运行标识的候选 Finding，不能直接互相覆盖或修改 canon。只有当单模型基线已经稳定，且实验问题明确需要不同模型时，才值得承担额外成本。

8.2 Codex、Claude 与其他 Agent

项目的核心交互是文件和命令，而不是特定聊天产品。一个 Agent 只要能够：

1. 读取项目目录和 AGENTS.md、CLAUDE.md 等入口文件；
2. 执行公开命令并读取命令输出；
3. 遵守产物路径、格式和批准边界；
4. 在需要时把任务交给 Python 工具；

就可以使用相同架构。不同客户端可以拥有不同入口文件，但不应拥有不同的事实源。跨客户端继续工作时，handoff 应指向 manifest、context package、当前阶段、待处理 Finding 和最近一次作者决定。

8.3 最轻量使用路径

作者不需要先学习所有内部 schema。最小路径是：

./bin/canonloom init --root ~/my-novel
./bin/canonloom start-idea --root ~/my-novel
./bin/canonloom start-work --root ~/my-novel
./bin/canonloom continue --root ~/my-novel
./bin/canonloom check --root ~/my-novel
./bin/canonloom settle --root ~/my-novel

Agent 负责把自然语言输入落到对应产物，并在每个需要决定的地方给出引导提示。高级用户可以直接操作 status、query、repair、advanced 和低层检查命令，但普通作者不必接触内部实现。

9. 实现细节

9.1 来源与 provenance

每次运行生成 manifest，至少记录运行 ID、阶段、时间、输入路径、来源哈希、模型标识、提示版本、输出路径和状态。审查 Finding 必须引用证据路径或文本定位；如果 Finding 来自模型判断，应保留对应运行信息，而不是只保存一个无来源的自然语言结论。

9.2 配置优先级

配置分为作者配置、项目约束和 Agent 运行参数。优先级必须显式可见，且模型不能通过自然语言输出静默修改高优先级的作者边界。初始化时，作者操控题材、目标读者、风格、语言、自动化级别和禁止事项；Agent 可以识别并提议人物关系、叙事视角、节奏偏好和潜在状态结构；提案需要作者确认后才能成为项目约束。

9.3 检查与自我修复

系统的”自我修复”不是无条件自动改写。它由诊断、修复计划、受限执行和回归验证组成：

确定性问题，例如缺字段、坏引用、重复 ID、哈希不匹配和非法阶段迁移，可以由工具修复或明确提示。文学问题，例如动机不足、节奏松散和语气不稳定，只能生成修复建议或候选版本，并经过同一审查链和作者批准。

9.4 结算

S6 产生两类结果：作者批准的正文进入 manuscript/；状态变化以单独的 settlement trace、proposed delta 或 open issue 记录。当前版本不把生成器提出的事件自动写成正式状态，也不把正文晋升等同于所有状态晋升。

10. 评估方法

10.1 当前工程验证与未来质量评估的边界

0.2.0 当前可以报告的是工程可靠性：测试是否通过、命令是否可运行、产物是否符合协议、阶段是否可恢复、公开路径是否能完成最小 smoke。当前不能据此报告”小说质量领先”，因为尚未完成同模型、同任务、同上下文和人工盲评条件下的正式对照实验。

这一边界十分重要。一个更严格的门禁可能减少错误，却也可能增加 token 和作者等待时间；一个较短的上下文可能降低成本，却可能损失文学细节。质量结论必须由受控实验和人工评价共同支持。

10.2 研究对象与基线

建议使用完全原创、无版权依赖的短长篇任务集。每个任务包含创意、角色表、世界规则、前置章摘要、章契和隐藏的验证标签。固定模型、温度、最大输出、随机种子（若接口支持）、输入材料和目标字数。

推荐比较以下条件：

表 3. 受控实验的比较条件。

“竞品对比”应在同一协议下比较可测的机制和成本，而不是把不同项目的默认模型、提示词、编辑器功能和作者经验混为一谈。社区项目可作为设计参照；只有在能够固定输入输出和运行条件时，才将其实现为严格基线。

10.3 指标

工程指标

• 协议通过率：成功完成所需阶段且产物结构合法的运行比例；
• 恢复成功率：中断后从最近合法状态继续完成的比例；
• 非法写入率：未经批准写入 canon 或 manuscript 的次数；
• Finding 可追溯率：能定位到来源和证据的 Finding 比例；
• 修复回归率：修复后原问题消失且未引入新高严重度问题的比例；
• 重试次数、失败阶段和平均恢复时间。

叙事结构指标

• 章契遵循率：必需变化、禁止变化和出口状态的人工或半自动判定；
• Beat 覆盖率：正文是否提供每个 Beat 的可定位证据；
• 因果一致性：事件前因后果是否成立；
• 角色能动性：关键结果是否由角色选择而非作者便利推动；
• 时间线冲突数和实体关系冲突数；
• 知识泄露率：角色使用其未获得的信息的比例；
• 揭示控制：秘密过早揭示、承诺丢失和 payoff 缺失的比例。

体验与成本指标

• 输入 token、输出 token、总 token；
• 墙钟时间、模型调用次数和工具调用次数；
• 作者需要确认的门禁次数；
• 作者人工修改字数与修改时间；
• 盲评中的连贯性、可读性、人物可信度、悬念和整体偏好。

总成本应报告为：

$$Cost = c_{in}T_{in}+c_{out}T_{out}+c_{tool}N_{tool}+c_{human}H$$

其中 $T$ 为 token，$N_{tool}$ 为工具调用数，$H$ 为作者投入时间；不同模型价格和作者时间价值应单独列出，不用一个不可解释的总分替代。

10.4 消融实验

最关键的消融不是”多 Agent 对单 Agent”，而是逐个移除架构约束：

表 4. CanonLoom 关键组件消融及其观察指标。

如果一个组件只增加成本而没有改善目标指标，应降低其默认等级，而不是因为它在架构图中存在就强制所有作者使用。

10.5 统计与人工评审

同一任务应使用多个随机运行或多个独立样本，报告均值、标准差和置信区间；对错误计数使用适当的计数模型，对盲评使用混合效应模型或配对非参数检验。人工评审者应看不到系统条件和模型名称，并对章契遵循、因果、角色能动性、信息控制和语言质量分别评分。至少两名评审者共同标注一部分样本，以报告一致性。

LLM-as-a-judge 可以用于筛选和错误定位，但不应作为唯一文学质量指标；其提示、模型、温度和评分 rubric 必须随实验材料公开。

11. 当前版本结果与案例分析

11.1 已完成的工程验证

在当前仓库中，0.2.0 已完成以下工程层检查：

• Python 单元测试通过，覆盖命令、协议、配置优先级、状态验证和公共表面等核心路径；当前测试套件为 18 项；
• 最小项目 smoke 通过，能够从初始化路径生成并检查基础项目；
• public check 通过，能够发现面向使用者的文档和入口问题；
• CLI 默认帮助与高级命令入口分离，作者路径保持短小；
• 一次外部测试项目的章节工作流能够经过 S0–S5b，并生成状态验证和审查产物。

这些结果证明协议在当前样例和工具层面可运行，不证明生成文本在文学质量上优于 B0–B2，也不证明在所有模型、题材和长篇规模下都不会漂移。外部测试项目的正文和具体小说上下文不属于本项目的研究数据，也不应被读者当作公开 benchmark。

11.2 一个典型运行的解释

在一次正常运行中，作者先确认本章的目标和禁止变化，Agent 准备 Beat 和上下文包；S0 冻结并验证章契、选择和上下文；S1 产生候选正文；S2 快速检查；S3 按 Finding 修复；S4 做严格检查；S5 生成独立审查；S5b 对审查报告进行交叉验证；最后作者决定哪些正文进入手稿、哪些状态变化保持为提案。

这个过程的价值不是增加”看起来专业”的步骤，而是让错误具有位置：如果 S0 失败，应检查章契、选择或上下文；如果 S2 发现问题，应进入 S3；如果 S4 或 S5b 失败，应保留报告并回退到修复或人工决策；如果作者不同意某个状态 delta，则无需删除全文，只需拒绝该 delta 并保留正文候选。这种定位能力是长篇协作系统持续运行的基础。

11.3 预期分析

基于架构机制，可以提出但尚不能宣布的假设：

• H1：章契和 Beat 会降低章节出口状态与计划不一致的比例；
• H2：context package 会降低不相关输入 token，同时提高来源可追溯性；
• H3：叙事状态层会降低知识泄露和揭示顺序错误，但会增加状态维护成本；
• H4：provenance 和回归审查会提高修复可复现性，但增加延迟和调用次数；
• H5：单一主模型路径在相同上下文下可能比多模型共享隐式记忆具有更低同步成本，但不意味着所有维度的审查能力都更高。

这些假设需要第 10 节的对照实验验证。论文不能把架构设计的合理性写成实验结论。

12. 讨论：可靠性、成本与创作自由

12.1 约束并不等于模板化

强约束应限制状态边界，而不是规定每个句子的表达。章契可以要求”某个选择造成不可逆代价”，却不必规定角色用哪句话表达。Beat 可以指定冲突和出口，却不应取代场景中的动作、感官和潜台词。约束若深入到每个修辞决定，系统会变成模板引擎，失去创作空间。

12.2 为什么不默认多模型交叉

多模型可以增加批评视角，但也会带来额外的输入重复、风格冲突、知识版本不一致和错误互相放大。CanonLoom 的默认建议是先让一个主模型在冻结上下文中完成完整路径，再把多模型当成隔离审查实验。这样既保留可扩展性，也避免把”模型数量”误认为”可靠性”。

12.3 为什么不立即采用图数据库

图数据库对复杂查询有吸引力，但会引入 schema 迁移、部署和调试成本。早期项目的主要问题通常不是查询性能，而是状态定义、来源、批准边界和错误分类尚未稳定。JSONL、索引和校验足以支持第一阶段；当公开 benchmark 证明查询成为瓶颈时，再以可替换后端实现，而不是改变作者看到的协议。

12.4 作者负担是核心指标

一个系统如果降低模型错误，却让作者每天处理大量确认卡片，可能并没有改善实际体验。因此门禁数量、确认时间、人工修订字数和作者对建议的采纳率必须与一致性一起报告。未来可以根据风险动态调整门禁：低风险章节采用轻量路径，高风险状态变化触发更强审查。

13. 局限性

本节区分”当前实现的边界”和”本文证据的边界”。这些限制不会否定 CanonLoom 的协议设计，但会限制本文能够作出的结论。

13.1 证据范围有限

本文当前报告的是仓库级工程验证，包括协议检查、CLI 测试和最小项目 smoke；样本规模不足以支持跨模型、跨题材或跨架构的质量结论。尤其是，测试通过只能说明产物和阶段迁移符合预期，不能说明生成文本具有更高的文学质量。因此本文将 CanonLoom 定位为”可运行、可审计的系统设计”，而不是”已经证明更优的生成方法”。后续工作需要预注册任务集、固定模型和参数，并补充独立样本与人工盲评。

13.2 指标不能完全代表文学质量

章契遵循率、时间线冲突、知识泄露、token 和延迟都是有用的工程或结构指标，但它们只是文学质量的代理变量。一个严格遵循 Beat 的章节仍可能缺乏新意，一个较长的输出也不必然更有价值。LLM-as-a-judge 还可能受到提示、模型偏好、文体和语言的影响。为降低这一风险，后续评估应将确定性检查、结构标注、作者负担和匿名人工盲评分开报告，不把它们压缩成一个总分。

13.3 跨题材与跨语言的外部有效性

叙事状态和揭示指标对多视角悬疑、线性成长故事、喜剧或意识流文本的适用性并不相同；中文和英文的分词、篇章结构、风格判断也可能产生不同误差。当前架构只提供通用字段和流程，没有证明每个字段对所有题材都同样有效。因此 benchmark 应按题材、视角、语言和章节长度分层，并允许作者关闭不适合自身作品的状态字段。

13.4 状态抽取与文件协议的系统风险

叙事状态本身通常由模型从正文中抽取。如果抽取错误，错误状态可能被上下文编译器再次使用，形成”结构化的错误记忆”；作者批准边界可以降低风险，但不能自动发现所有语义误读。文件协议也不等同于完整的并发控制、权限系统或数据库事务：多人同时编辑、跨机器同步和大量项目索引仍需要额外的锁、版本合并和后端设计。当前版本采用 JSONL、哈希和阶段检查，是轻量可审计方案，不是高并发生产数据库。

13.5 成本、延迟与作者负担

审查、状态验证和修复回归会增加模型调用、输入 token、墙钟时间和作者确认次数。单一主模型降低了上下文同步复杂度，却不保证在所有任务上成本最低；更强的门禁也可能把作者变成频繁确认者。因而”可靠性提高”不能脱离人工时间和实际预算来评价。未来应以风险分层的方式启用门禁，并报告每次确认的时间、人工改写量和最终采纳率。

13.6 客户端和模型依赖

跨 Agent 的可移植性来自文件协议和命令入口，但仍依赖具体客户端能否正确读取项目说明、执行命令并遵守写入边界。当前仓库没有为每个 Codex、Claude 或其他 Agent 客户端提供同等成熟的官方适配器；不同模型的上下文窗口、工具调用行为和指令遵循能力也可能改变结果。因此”跨 Agent 可用”应理解为协议层可迁移，而不是已经完成所有客户端上的等价性能验证。

14. 伦理、版权与隐私

CanonLoom 应使用作者拥有或有权处理的材料。参考作品只能在符合版权、授权和平台规则的范围内用于研究或风格分析；架构文档不应携带具体小说的私人上下文、未公开稿件或可识别的作者资料。项目日志可能包含完整正文和提示词，公开仓库前必须检查 .gitignore、脱敏策略和运行 trace。

系统应明确标注 AI 参与，避免将模型生成内容伪装为未经编辑的人类创作。对于涉及现实人物、敏感身份或潜在伤害的内容，作者仍需承担最终判断责任。自动修复不得绕过作者批准，也不得因为检测到版权或安全风险就擅自删除用户资料；应生成可解释的警告和可恢复的建议。

15. 可复现性附录

15.1 代码与文档

项目仓库提供命令行入口、schema、示例项目、测试和运行说明。研究稿对应当前版本 v0.2.0；若实验使用后续版本，应同时记录 Git commit、配置文件和模型版本。

15.2 每次实验需要记录

• repo_commit
• model_id
• model_parameters
• prompt_or_skill_version
• input_manifest_and_hashes
• chapter_contract
• random_seed_if_available
• token_usage
• wall_clock_time
• retry_count
• review_findings
• author_edits
• final_ratings

15.3 复现实验步骤

1. 创建原创测试项目并执行 init；
2. 固定作者意图、canon、前置摘要和章契；
3. 选择 B0–B5 中一个条件；
4. 使用相同模型参数运行生成；
5. 保存 manifest、候选正文、审查报告和最终批准结果；
6. 执行协议检查和回归检查；
7. 对所有条件进行匿名人工评审；
8. 汇总工程、结构、成本和体验指标，并公开聚合结果。

15.4 结果报告规范

本稿不放置没有实际采集依据的质量或成本数字。正式实验报告应为每个条件提供：协议通过率、时间线错误、知识泄露、章契遵循、输入与总 token、重试次数、人工修改时间和盲评质量，并同时报告样本量、模型版本、参数、置信区间和评审者一致性。若某项指标尚未采集，应在实验报告中标记为”未采集”，而不是填入估计值或保留模糊占位符。

因此，本文是系统设计论文，不是质量 benchmark 论文；第 10 节给出可复现实验协议，第 11 节只报告已经完成的工程验证。

16. 结论

CanonLoom 0.2.0 把长篇小说人机协作从一次性的提示词活动重新表示为一个可恢复的生产流程。其核心不是增加模型数量或把所有复杂组件一次性装进系统，而是建立清晰的边界：作者意图不同于模型提案，计划不同于正文，正文不同于正式事实，审查 Finding 不等于故事事实，状态变化必须经过作者批准。S0–S6 阶段、章契、Beat、受限上下文、provenance 和可选叙事状态层共同构成了这套边界。

当前版本已经具备可运行的工程骨架和基础验证，但还没有完成能够支持文学质量优越性结论的公开受控 benchmark。下一步最重要的工作不是继续堆叠 Agent，而是建立原创、可复现、包含人工盲评的长篇一致性数据集，并测量可靠性收益是否值得额外 token、延迟和作者负担。只有在这些指标被单独报告之后，CanonLoom 才能从一个结构合理的开源工作流，进一步成为经过验证的叙事生产架构。

本文的实证声明限定为当前版本的工程可运行性：协议、CLI、测试和最小项目路径已经得到验证。关于文学质量、跨架构优势、token 收益和作者体验的结论，必须等待第 10 节所述的受控实验；在完成实验之前，CanonLoom 只应被描述为一个可审计的叙事生产协议和研究框架。

参考文献与相关项目

论文

1. DOC: Improving Long Story Generation with Detailed Outline Control.
2. Creating Suspenseful Stories: Iterative Planning and Narrative Questions.
3. DOME: Dynamic Outline, Memory Enhancement, and Temporal Conflict Analysis.
4. StoryWriter: A Unified Framework for Long Story Generation.
5. Long Story Generation via Knowledge Graph and Literary Theory.
6. STORYTELLER: Structured Narrative Planning and Entity Knowledge.
7. Collective Critics: Multi-perspective Critique for Creative Generation.
8. Can LLMs Generate Good Stories?.
9. Text-to-Text Automatic Story Generation: A Survey.
10. Narrative World Model.
11. MAGNET / ATLAS.
12. SuperWriter-Agent.
13. Lost in Stories.

社区项目

• autonovel
• creative-writing-skills
• story-skills
• novel-creator-skill
• book-os
• authorclaw
• inkos
• NovelWriter
• GPTAuthor
• agent-skills

完整论文与外部链接

• CanonLoom 完整论文（GitHub）↗
• CanonLoom 项目仓库（GitHub）↗

作者信息与声明

作者： Liyuk

利益冲突： 作者声明无利益冲突。本研究未受任何商业机构资助；文中引用的公开项目、行业报告与报道均仅作方法或方向参考。

数据可用性： 本文报告真实的工程验证数据：当前测试套件为 18 项 Python 单元测试，另含最小项目 smoke、public check、CLI 入口检查，以及一次外部测试项目走完 S0–S5b 的章节工作流（详见 §11.1）。这些结果证明协议在当前样例和工具层面可运行，不构成对生成文本文学质量的评估。生成文本的文学质量比较、跨模型与跨题材的正式对照实验尚未完成，故不报告相关数值。实现代码与复现步骤见 CanonLoom 仓库。

术语表