Webnovel-Writer Harness v6 架构设计解析以 Claude Code 为底座的长篇网文创作流水线重构方案【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer本文依据仓库设计文档 docs/archive/superpowers/specs/2026-04-02-harness-v6-design.md 展开并结合 memory_contract.py、memory_contract_adapter.py、reviewer.md、context-agent.md、review_pipeline.py 等源码佐证。Webnovel-Writer 是一套基于 Claude Code 的长篇网文辅助创作系统目标是支撑 500-2000 章、200 万字量级的连载写作。本文详解其 Harness v6 设计如何围绕「23 条问题清单」完成主流程收敛废弃 → 合并 → 接口冻结重构写前上下文、统一审查、记忆契约与章纲约束把单章 Token 消耗从 300-500 万压缩到预估 80-150 万。读完你将掌握这套「Claude Code 原生能力 卷纲约束 记忆契约」三层 harness 的完整架构、接口冻结策略与迁移退出标准。1. 设计背景与终极目标v6 设计文档2026-04-02 起草2026-04-09 更新为草案 v7源于三类输入用户反馈、issue#5 的 token 分析、以及 23 条问题清单。它的终极目标不是做一个更大的工具集而是写出一本长篇网络小说500-2000 章支持多种主流题材文笔优秀减少 AI 味剧情跌宕起伏、出人意料AI 主导创意作者事后审核长上下文后保持文风且不吃书完善的人机协作可注入作者灵感系统稳定减少上下文消耗合适的错误改善机制2. 核心原则三层 harness减法优先v6 的设计哲学可浓缩为四条原则原则含义Claude Code 本身就是 harness不另建编排层充分利用原生能力/resume、Task、子 agent 隔离、自动 compaction卷纲是 harness给写作 AI 足够约束防止跑偏、失控、遗忘记忆是根基防吃书靠记忆系统不靠大纲节点减法优先砍掉不产生价值的环节而非叠加更多流程2.1 本轮非目标避免 scope creep以下方向已确认但不在 v6 迁移基线内避免范围蔓延Plan schema 全量落地——章纲字段草案仅作参考plan skill 重构排在 Phase 6References 全量范例化——P0 方法论先补P1 允许后续迭代Memory 底层存储重构——Phase 5先冻结 v0 契约即可Init 迭代打磨机制——待 init 方案细化不阻塞主链Anti-AI 超越黑名单的新机制——Phase 7当前先用 reviewer 的ai_flavor维度兜底本轮优先事项只有一个主流程收敛废弃 → 合并 → 接口冻结 迁移退出标准达成。3. 问题清单23 条痛点的根因分析v6 重构的起点是一份覆盖 Init、Plan、Write、记忆、系统级五个层面的问题清单。逐条理解这些问题才能看懂后续每个设计决策的动机。3.1 Init 层3 条#问题根因1参考文件重结构轻范例教了「格式」没教「品味」LLM 知道填什么字段但不知道什么内容算好2缺少题材标杆没有「好世界书长什么样」的真实小说范例作为 few-shot3生成不可迭代总纲、设定集一次生成就结束无打磨循环3.2 Plan 层6 条#问题根因4约束了「发生什么」而非「方向和边界」章纲写「主角救了叫朵朵的小女孩」→ 全量灌入写作 AI → 剧透5缺少卷级叙事功能定义每章在卷中承担什么角色起/承/转/合不明确6时间约束太显性时间锚点、倒计时直接写在章纲里AI 反复在正文中提及7Strand 比例硬编码 60/20/20不同题材节奏不同末世文和甜宠文不可能一样8四层产出下游利用率不明节拍表、时间线、卷纲、章纲——write 阶段真正消费的只有章纲910 章/批生成质量递减后面几章趋向套路化3.3 Write 层7 条#问题根因10流水线太重8 步 workflow 记录大量 token 花在流程管理而非写作11context-agent 是 token 黑洞全量灌入所有数据输出巨大执行包12审查消耗大产出低6 个 checker 各自独立 context打 90 分但用户觉得很差13anti-AI 必须加强黑名单只能挡已知口癖挡不了叙事结构/情绪表达/节奏层面的 AI 味14data-agent 太重9 个子步骤归入记忆模块统一设计15写作和回写耦合回写失败卡住整条链但回写时机不变下一章前必须完成16workflow_manager resume skill 浪费Claude Code 原生/resume即可恢复中断会话3.4 记忆层4 条#问题根因176 种存储太分散state.json / index.db / scratchpad / summaries / vectors / snapshots 各自读写18分层不符合写作直觉应按时效分级近期详细→ 中期摘要→ 远期活跃事实19时间线不是索引轴所有记忆应挂在时间线上支持「第 N 章时角色是什么状态」的查询20记忆类型需明确角色状态可变、世界规则稳定、伏笔有生命周期、时间线单调递增3.5 系统级3 条#问题根因21Skill/Agent prompt 格式混乱缺少统一模板每个文件组织方式不同LLM 抓不住重点22参考资料需要清理和补充删冗余、补方法论含真实小说片段作为正面/反面范例23Token 消耗过高单章 300-500 万审查占大头但产出最低4. 已确认的设计方向废弃、合并与重构4.1 废弃项清单废弃替代workflow_manager.pyClaude Code 原生/resumeresume skillClaude Code 原生/resumeStep 2B独立风格适配步骤合并到 Step 4 润色6 个独立 checker agent合并为 1 个审查 agent审查评分机制改为 code review 格式输出具体问题清单memory_scratchpad.json长记忆系统基于远端无长记忆版本重新设计统一记忆模块可以看到废弃项的共性都是「重复造轮子」或「token 无产出」——Claude Code 原生能力能替代的编排层全部砍掉这是减法优先原则的直接体现。4.2 新 Write 流程与章节状态模型重构后的写章流程从 8 步收敛为 6 步Step 0.5 预检 → Step 1 上下文搜集context-agentresearch 模式 → Step 2 起草 → Step 3 审查单 agentcode review 格式 → Step 4 润色 风格适配 anti-AI → Step 5 数据回写统一记忆模块单次调用 → Step 6 Git 备份章节状态模型单调递进不可回退状态进入条件允许结束会话允许开始下一章允许 git backupchapter_draftedStep 2 完成正文初稿存在✅❌❌chapter_reviewedStep 3-4 完成blocking 清零且 anti-AI 复检通过✅❌❌chapter_committedStep 5 完成记忆回写成功✅✅✅状态推进规则解决问题 #15 的写作/回写耦合由 Step 2/4/5 完成时分别推进写入state.json.progress.chapter_status[NNNN]Step 5 失败不回滚 Step 1-4章节停留在chapter_reviewed不得开始下一章允许带着回写 debt 结束会话但下次会话必须先补完 Step 5查询入口python -X utf8 ${SCRIPTS_DIR}/webnovel.py --project-root ${PROJECT_ROOT} state get-chapter-status --chapter {N}这套模型的关键设计是「把回写失败从整条链的阻断点降级为章节级 debt」——写作链不再被存储故障卡死但状态机的单调性又保证了记忆永远不欠账。4.3 Context-Agent 新模式从全量灌入到按需 research旧模式的病根是「一次性全量灌入 → 输出巨大执行包」新设计改为 research 模式四步走调用记忆模块合并接口 → 拿到基础上下文章纲目标、角色状态、未闭合伏笔思考这章还需要什么额外信息按需调用记忆模块独立接口补充某角色历史、某条世界规则、上章结尾确认信息充分 → 按固定格式输出写作提示在仓库实现中这一点已经完全落地。context-agent.md 定义的主入口与按需补查命令如下# 主入口一次性拿全基础包 python -X utf8 ${SCRIPTS_DIR}/webnovel.py --project-root {project_root} memory-contract load-context --chapter {NNNN} # 按需补查基础包不足时才调已含的不重复查 python -X utf8 ${SCRIPTS_DIR}/webnovel.py --project-root {project_root} memory-contract query-entity --id {entity_id} python -X utf8 ${SCRIPTS_DIR}/webnovel.py --project-root {project_root} memory-contract query-rules --domain {domain} python -X utf8 ${SCRIPTS_DIR}/webnovel.py --project-root {project_root} memory-contract get-timeline --from {N} --to {M} python -X utf8 ${SCRIPTS_DIR}/webnovel.py --project-root {project_root} index get-reader-signals --limit 5 --last-n 20load-context已打包的基础内容无需重复查询包括story_contractsMASTER/volume/chapter/review、recent_summaries、urgent_loops、active_rules、protagonist、memory_pack追读力、genre_profile_excerpt、author_style_patterns/webnovel-learn 累积的作者文风修正、style_contract设定集/风格契约。只有当 contracts 返回空时才直接 Read.story-system/*.json。4.4 统一审查code review 格式 blocking 语义审查从「6 个 checker 各自打 90 分」重构为「1 个 agent 输出结构化问题清单」。最小 schema{ issues: [ { severity: critical | high | medium | low, category: continuity | setting | character | timeline | ai_flavor | logic | pacing | other, location: 第3段, description: 主角使用了第15章已失去的能力xxx, evidence: 原文萧炎催动xxx斗技 vs 记忆第15章已失去该能力, fix_hint: 改为使用当前已有的yyy能力, blocking: true } ], blocking_count: 1, summary: 发现1个阻断问题2个高优问题 }阻断规则blockingtrue的问题替代原timeline_gate语义——存在任何 blocking issue 时不得进入 Step 4severitycritical默认blockingtrue其余 severity 由审查 agent 判断blocking 修复循环存在 blocking issue 时由主流程非 reviewer修复对应问题修复后必须重跑 Step 3完整审查确认 blocking 清零若用户明确覆盖如判断为误报可跳过重审直接进入 Step 4需在 review report 中标注覆盖原因关于用户覆盖仓库提供了更细的裁决依据blocking-override-guidelines.md 明确区分了三类场景——涉及设定冲突、时间线冲突、事实错误、连续性断裂的 issue禁止建议 override而节奏偏差、角色风格软偏差、可选节点未覆盖等场景才允许用户确认后 override。指标沉淀轻量每次审查结果写入index.db.review_metrics字段chapter, issues_count, blocking_count, categories, severity_counts, timestamp用于趋势观测连续 N 章某类问题反复出现 → 提示系统性问题overall_score保留为衍生兼容字段由 severity_weighted 扣分计算仅用于排序/趋势不可用于 gate 决策gate 决策始终以blockingtrue和 issue 明细为准仓库中的 review-schema.md 已将这套设计冻结为 schemareview_results.json保留完整issues列表随后由 review-pipeline 生成review_metrics.json同时包含落库兼容字段overall_score、dimension_scores、severity_counts等与 v6 观测字段issues_count、blocking_count、categories等。review_pipeline.py 的main()支持--review-results、--metrics-out、--report-file、--save-metrics四个参数其中--save-metrics可直接写入index.db省去单独调用。anti-AI 职责划分Step 3 负责发现anti-AI 问题categoryai_flavor列入问题清单Step 4 负责修复——消费 Step 3 的ai_flavorissue 逐条修改Step 4 修复后必须独立复检——默认路径重跑reviewer仅启用ai_flavor维度。Step 4 不得自判 pass/fail替代检查方案必须同时满足① 独立于 Step 4 执行不可由润色流程自判② 结构化 JSON 输出含blocking_count③ 结果可落盘、可追溯写入.webnovel/tmp/这一设计的核心动机是避免「自己改、自己说通过」的闭环偏差——审查与修复必须分离到不同步骤执行。仓库中的统一审查 agent reviewer.md 进一步收窄了职责只查 5 个维度设定一致性setting、时间线timeline、叙事连贯continuity、角色一致性character、逻辑logic不评分、不给建议、不写摘要性评价且强制要求对每个维度输出结论无问题也显式输出pass并规定「只报可验证的问题——必须有 evidence原文引用 or 数据对比」。category取值规范中pacing/other仅为后端兼容枚举该 agent 不主动产出。4.5 记忆模块接口契约先行存储实现后置记忆模块分两阶段交付核心策略是先把契约冻结存储重构不阻塞主链。阶段 A接口契约先定不依赖存储实现上层消费者context-agent、data-agent、审查 agent只依赖契约不依赖具体存储实现。v0已实现当前冻结——由memory_contract.pyProtocol 类型定义和memory_contract_adapter.py适配器实现CLI 入口为webnovel.py memory-contract子命令# 合并接口 memory.commit_chapter(chapter: int, result: dict) - CommitResult memory.load_context(chapter: int, budget_tokens: int) - ContextPack # 独立接口context-agent research 模式按需调用 memory.query_entity(entity_id: str) - EntitySnapshot memory.query_rules(domain: str) - list[Rule] memory.read_summary(chapter: int) - str memory.get_open_loops(status: str active) - list[OpenLoop] memory.get_timeline(from_ch: int, to_ch: int) - list[TimelineEvent]在 memory_contract.py 中这套契约被实现为runtime_checkable的MemoryContractProtocol并定义了六个 dataclass 返回类型CommitResult、EntitySnapshot、Rule、OpenLoop、TimelineEvent、ContextPack每个都带to_dict()便于序列化落库。上层消费者只依赖该 Protocol不直接依赖StateManager/IndexManager/ScratchpadManager等具体实现。memory_contract_adapter.py 则是薄适配器不做存储重构仅委托给现有模块。从源码可见commit_chapter会根据 result 是否包含review_result/fulfillment_result/disambiguation_result/extraction_result四个键自动选择主链ChapterCommitService或 legacy 路径load_context内部组装 9 类 sectionsstory_contracts、runtime_status、memory_pack、outline、recent_summaries、protagonist/progress、active_rules前 5 条、urgent_loops前 3 条、genre_profile_excerpt、author_style_patternsproject_memory.json、style_contract风格契约.md截取前 2000 字符各契约方法内部均有 try/except 降级任一存储模块失败只记 warning 不中断整链与 v0 配套的提交类型化在 chapter_commit_schema.py 中可见ReviewResult要求顶层blocking_count字段、FulfillmentResultplanned_nodes/covered_nodes/missed_nodes/extra_nodes、DisambiguationResultpending、ExtractionResultaccepted_events/state_deltas/entity_deltas——这正是 v1 中「result: dict→ 类型化CommitPayload」的落地形态。v1Phase 3 增强目标v0 冻结后再迭代commit_chapter的result: dict→ 替换为类型化CommitPayload明确字段chapter_file、review_result、entities、summary 等load_context增加intent: Literal[draft, review, repair]参数按意图裁剪返回内容query_rules的domain: str→ 细化为domain: str, scope: str all支持子域过滤所有返回结构统一包含横切元数据source、chapter_range、confidencev0 → v1 的升级不影响上层 prompt仅影响 CLI 参数和返回字段丰富度——这正是接口冻结的价值prompt 改动永远有稳定接口可依赖。阶段 B存储实现后做已确认方向按时效分层近期详细→ 中期摘要→ 远期活跃事实时间线作为索引轴记忆类型角色状态可变、世界规则稳定、伏笔有生命周期具体实现方案搁置待进一步思考。4.6 Plan章纲约束重构方向章纲作为 harness 给 write 足够约束但约束形式需要变约束「方向和边界」不约束「具体发生什么」时间约束隐性化——不在章纲里写死时间锚点通过记忆系统间接传递写后校验Strand 比例按题材预设不硬编码 60/20/20卷级叙事功能——每章需要标注在卷中的叙事角色起/承/转/合章纲最小字段草案待验证内容层章纲本体{ chapter_goal: 主角通过考验进入迦南学院, must_payoff: [第3章埋下的丹药伏笔], forbidden_turns: [主角不可直接暴露隐藏身份], narrative_role_in_arc: 承, strand_profile: main_heavy, time_pressure_source: 入学截止 }消费策略层控制章纲如何喂给写作 AI不属于故事内容{ writer_exposure_policy: { verbatim_fields: [chapter_goal, must_payoff, forbidden_turns], transform_fields: { narrative_role_in_arc: 转为隐性节奏提示不直接告知承, time_pressure_source: 仅作为校验依据不在正文中直接提及具体数字或倒计时 } } }说明chapter_goal方向而非剧透不写「主角救了叫朵朵的小女孩」forbidden_turns明确边界防止跑偏strand_profile取代硬编码数值配比由 genre-profiles 定义具体权重如main_heavy 主线 70%、balanced 均衡、relationship_heavy 感情线主导writer_exposure_policy独立于内容层由 context-agent 消费时解释章纲 schema 本身不混入传输逻辑这套设计直指问题 #4、#6、#7 的根因章纲只负责「方向与边界」是否剧透、如何暴露由消费策略层单独控制时间压力只作为写后校验依据而不再进入正文。4.7 Skill/Agent Prompt 统一模板每个 skill/agent 文件按固定结构编写解决问题 #21 的格式混乱1. 身份与目标 2. 可用工具与脚本含调用方式 3. 思维链ReAct / 其他 4. 输入 5. 执行流程每步输入 → 动作 → 输出 6. 边界与禁区 7. 检查清单 8. 输出格式 9. 错误处理仓库中的 context-agent.md 与 reviewer.md 正是这一模板的完整落地样板均为 9 段式结构含工具调用、边界禁区、检查清单、SubagentRun 信号、错误处理表。4.8 参考资料删冗余、补范例删除冗余引用、已废弃文档、重复的 shared 引用共 13 个文件。补充P016 条反派设计、镜像反派、对手梯度、人物关系动力学时间线设计、长篇升级节奏、反派压迫递进、伏笔埋设与回收感情线递进、身份隐藏与曝光暧昧/打脸/反转/对峙场景写法章节开头钩子、章节结尾 cliffhanger要求参考资料按优先级分层补充真实小说片段P0关键方法论必须包含真实小说片段作为正面/反面范例——追读力钩子、反转写法、对峙场景等直接影响写作质量的方法论P1次级方法论允许先用自写范例或抽象示例后续逐步替换为真实片段改造现有genres/和write/references/下的文件从「结构模板」改为「方法论 范例 反面教材」。5. Token 优化预估以下为方向性估算具体取决于正文长度、审查轮次、research 命中率。需用真实运行日志验证。环节当前优化后预估区间节省审查~200 万6 agent × ~33 万30-50 万1 agent含 Step 4 后 ai_flavor 复检~75-85%Context-agent~50 万全量灌入10-20 万按需检索~60-80%风格适配~30 万独立 Step 2B0合并到润色100%Workflow 记录~5 万16 次 CLI0废弃100%单章总计300-500 万预估 80-150 万~60-70%假设条件单章正文 2000-2500 字审查无 blocking 需返工的情况context-agent research 模式命中率 80%值得强调的是最大的两个节省来源审查合并、context-agent research 化都源于「减少 token 无产出环节」而非压缩正文信息量——这与问题 #12、#11 的根因一一对应。6. 实施路径与接口冻结策略阶段内容依赖状态Phase 1废弃 workflow/resume 审查合并 Step 2B 合并无✅ 已完成Phase 2ASkill/Agent prompt 统一模板 参考资料清理删冗余无✅ 已完成Phase 2B参考资料范例补强真实小说片段用户收集素材待定Phase 3记忆模块接口契约设计无✅ 已完成Phase 4Context-agent research 模式重构Phase 3契约✅ 已完成Phase 5记忆模块存储实现Phase 3契约 用户设计确认待定Phase 6Plan 章纲约束重构Phase 45待定Phase 7anti-AI 加强 写作 prompt 优化Phase 2A4待定Phase 1/2A/3 可并行探索但合并前需一次接口冻结优先冻结以下两项review-schemareviewer 输出格式 metrics 落库字段memory-contract CLI记忆模块接口签名 返回类型冻结后 Phase 1/2A 的 prompt 改动才有稳定的接口可依赖。7. 迁移退出标准v6 完成的 6 条硬指标以下条件全部满足时视为 v6 迁移完成仓库内不再存在对 6 个 checker 的运行时引用——skill/agent prompt 中无continuity-checker、setting-checker等旧名webnovel-write / webnovel-review 均只走 reviewer 流——审查路径唯一workflow_manager相关代码完全移除——不残留 import、调用或配置legacy 术语分层清零运行时引用skill/agent/script 中0 处prompt/skill 生效路径引用0 处测试 fixture / 迁移兼容样本允许存在但必须集中在evals/或tests/目录历史文档docs/允许存在但必须标注[deprecated]至少 1 个真实项目完成连续 10 章验证验收维度无流程阻断异常全链路 plan → write → review → data 跑通无状态回写错乱chapter_status 单调递进state.json / index.db 一致无 review / write / data 契约不一致reviewer 输出可被 review-pipeline 正确解析data-agent 产物符合 memory v0 契约章节状态模型已落地到 state.json——chapter_drafted/chapter_reviewed/chapter_committed可通过 CLI 查询状态推进由 Step 2/4/5 原子写入8. 未解决的设计问题#问题状态1记忆模块具体实现分层、存储、接口搁置待进一步思考2章纲具体字段设计什么算「方向和边界」已有最小草案待实际 plan 验证后定稿3anti-AI 的具体机制超越黑名单的方案待写作 prompt 设计时解决4context-agent 输出的写作提示具体格式待 write 方案细化5参考资料的真实小说片段收集待用户收集6Init 的迭代打磨机制待 init 方案细化7节拍表/时间线是否保留待确认下游是否消费8批量生成章纲的最佳批次大小待实验9Memory 契约 v0→v1 增强Phase 3 细化CommitPayload 类型化、load_context 增加 intent、返回结构加横切元数据9. 总结v6 设计对同类系统的可迁移启示Harness v6 的价值不止于一个网文工具的内部重构它的方法论对任何「LLM 长流程 Agent 系统」都有借鉴意义把编排层让给平台原生能力Claude Code 的/resume、Task、自动 compaction 能覆盖的绝不自建 workflow 层——省下的是真金白银的 token。审查与修复必须职责分离「自己改、自己说通过」是闭环偏差的温床发现Step 3、修复Step 4、独立复检重跑 ai_flavor 维度三段式是不可省略的最小可信闭环。接口契约先于存储实现冻结MemoryContractProtocol review-schema的冻结让 prompt 改动与存储重构解耦Phase 1/2A/3 因此可以并行。状态机单调性是长链系统的安全网chapter_drafted → chapter_reviewed → chapter_committed不可回退配合「回写 debt 可带出会话但必须先补」的规则兼顾了健壮性与数据一致性。减法优先胜过叠加流程23 条问题中有近半数审查、context、workflow、风格适配是通过「砍」而不是「加」解决的。仓库中 memory_contract.py、reviewer.md、context-agent.md、review_pipeline.py、review-schema.md 等文件即为该设计的现存实现可作为深度阅读的起点。【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考