Webnovel Writer 上下文预算管理context_manager 与 context_ranker 如何控制 token 消耗【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writerWebnovel Writer 是基于 Claude Code 的长篇网文辅助创作系统专为解决 AI 写作中的「遗忘」和「幻觉」问题而生支持 200 万字量级连载。它的秘密武器之一就是一套精密的上下文预算管理机制由context_manager负责该带什么、带多少由context_ranker负责什么排前面。两者配合让每一章的创作都在有限的 token 预算内拿到价值最高的信息而不是把整本书硬塞进模型窗口。为什么全量塞入在长篇连载中行不通写第 1 章时上下文可能只有几百字写到第 500 章时如果要把全部大纲、设定、前文摘要、角色状态都喂给模型token 消耗会爆炸式增长而且大量信息对这一章毫无用处。Webnovel Writer 的思路是先圈定范围只加载与当前章节相关的窗口内数据再按权重装配不同章节类型剧情/战斗/情感/过渡使用不同的预算配比最后排序加分把悬念、钩子、高严重度告警等高信号内容排到最前面。这样模型读到的每一段文字都在预算之内token 花在刀刃上。✂️预算三杠杆窗口、截断、权重杠杆一固定窗口 —— 只带身边的数据在 config.py 中所有预算参数都有明确默认值每个章节包只取窗口内的内容配置项默认值作用context_recent_summaries_window3只带最近 3 章的剧情摘要context_recent_meta_window3只带最近 3 章的章节元数据context_max_appearing_characters10出场角色最多 10 个context_story_skeleton_interval20全书骨架每 20 章采样一次context_story_skeleton_max_samples5骨架采样最多 5 个context_story_skeleton_snippet_chars400每个骨架摘要截断到 400 字context_alerts_slice10歧义告警最多保留 10 条其中故事骨架story_skeleton设计得特别精巧写第 400 章时系统会按context_manager.py中_load_story_skeleton的逻辑从第 380、360、340……章各摘一段 400 字的缩影让模型记得住全书大走向却不用付出整本书的 token 代价。️此外章节大纲加载时硬截断在 1500 字见_load_outline世界观、力量体系等全局设定也只取骨架文件。杠杆二模板权重 —— 不同章节类型不同预算在 context_weights.py 中系统定义了 4 种上下文模板每种模板对三大区块core 剧情核心 / scene 场景人物 / global 全局设定的预算配比不同模板coresceneglobalplot剧情章默认0.400.350.25battle战斗章0.350.450.20emotion情感章0.450.350.20transition过渡章0.500.250.25战斗章把 45% 的预算给场景与人物招式、在场角色最关键过渡章则把 50% 给剧情核心推进主线最重要——预算跟着写作任务走而不是平均分配。⚖️杠杆三动态预算 —— 连载越久预算重心越偏移这是很多长文工具忽略的细节。_resolve_context_stage会把章节分为三个阶段early第 30 章前core 权重上浮人物和剧情刚铺展最需要记得住设定mid30~120 章使用基础权重late第 120 章后global 权重从 0.25 提升到 0.35。为什么后期要加大全局设定权重因为连载越久遗忘的代价越大——力量体系、人物关系网早就定型模型必须看到更多全局锚点才能避免前后矛盾。这套阶段权重同样定义在 context_weights.py 的TEMPLATE_WEIGHTS_DYNAMIC_DEFAULT中。ranker 的排序魔法不删内容只调顺序窗口和权重决定了装什么而 context_ranker.py 决定了先看到什么。它不删除任何内容只做确定性排序对摘要、元数据、出场角色、故事骨架、告警五个列表重新打分排序。核心打分公式_combine_score总分 新近度 × 0.7 频率 × 0.3 加分项三个因子各有门道新近度1 / (1 章节差距)上一章的摘要几乎满分十章前的摘要只剩约 1/11 的分数频率log(1 出场次数) / log(11)用对数压缩避免戏份最多的主角无限霸榜钩子加分0.2摘要里如果出现悬念钩子反转冲突说明这是剧情关键节点直接提权置顶。另外两个细节体现了工程经验出场角色如果带有warning标记存疑实体扣 0.15 分防止待澄清的角色干扰创作告警列表中严重级别为 critical/high 的 0.3文本含冲突、矛盾、违规、断裂等关键词的再 0.3——红线问题永远排最前。所有权重0.7 / 0.3 / 0.2都是可配置项打开context_ranker_debug后每个条目还会附带_context_score调试分方便你验证排序是否符合预期。一条完整流水线build_context 做了什么在 context_manager.py 中一次上下文构建分三步走_build_pack(chapter) → 装配 13 个区块core / scene / global / 契约 / 信号 / 骨架…… ↓ ranker.rank_pack(pack) → 对五个高频列表重新排序并写入 meta 中的 ranker 参数 ↓ _assemble_json_payload(...) → 按模板权重裁剪区块标记 context_contract_version最终产出的不是原始文件堆而是一份结构化的上下文包。下游的 context-agent.md写作前的研究 agent会消费这份包输出一份五段写作任务书交给起草阶段——也就是说token 预算在这里被两次压缩先由 manager 圈范围再由 agent 压缩成人类可读的任务书。新手上手建议如何调好你的上下文预算先跑默认值所有参数在 config.py 都有经过调校的默认值大多数项目无需修改摘要窗口3 章偏小如果你的剧情伏笔跨度常超过 3 章可以适当调大context_recent_summaries_window但记得它直接乘在每章 token 消耗上连载过 120 章留意context_dynamic_budget_late_chapter阈值确保后期章节自动切到 late 阶段把全局设定权重拉高想验证排序开启context_ranker_debug在输出里检查_context_score_detail确认钩子章节是否真的排在前面想临时关闭排序设context_ranker_enabled为 False 即可回到纯按窗口装配的模式。相关行为均有测试覆盖可参考 test_context_manager.py 与 test_context_ranker.py。相关源码导航文件职责webnovel-writer/scripts/data_modules/context_manager.py上下文包装配主入口窗口截断与模板权重解析webnovel-writer/scripts/data_modules/context_ranker.py确定性排序器新近度/频率/钩子打分webnovel-writer/scripts/data_modules/context_weights.py4 种模板 × 3 个阶段的基础与动态权重表webnovel-writer/scripts/data_modules/config.py全部预算参数的默认值与说明webnovel-writer/agents/context-agent.md消费上下文包的写作研究 agent 定义一句话总结Webnovel Writer 用窗口圈范围 → 权重定预算 → 排序提信号三层漏斗把 200 万字量级的记忆压缩成每章几十 K 的有效上下文——这正是它敢让 AI 连续写几百章而不失忆、不幻觉的底气所在。【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/15 20:36:25 · 阅读 1.2k Webnovel Writer 上下文预算管理：context_manager 与 context_ranker 如何控制 token 消耗
Webnovel Writer 上下文预算管理context_manager 与 context_ranker 如何控制 token 消耗【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writerWebnovel Writer 是基于 Claude Code 的长篇网文辅助创作系统专为解决 AI 写作中的「遗忘」和「幻觉」问题而生支持 200 万字量级连载。它的秘密武器之一就是一套精密的上下文预算管理机制由context_manager负责该带什么、带多少由context_ranker负责什么排前面。两者配合让每一章的创作都在有限的 token 预算内拿到价值最高的信息而不是把整本书硬塞进模型窗口。为什么全量塞入在长篇连载中行不通写第 1 章时上下文可能只有几百字写到第 500 章时如果要把全部大纲、设定、前文摘要、角色状态都喂给模型token 消耗会爆炸式增长而且大量信息对这一章毫无用处。Webnovel Writer 的思路是先圈定范围只加载与当前章节相关的窗口内数据再按权重装配不同章节类型剧情/战斗/情感/过渡使用不同的预算配比最后排序加分把悬念、钩子、高严重度告警等高信号内容排到最前面。这样模型读到的每一段文字都在预算之内token 花在刀刃上。✂️预算三杠杆窗口、截断、权重杠杆一固定窗口 —— 只带身边的数据在 config.py 中所有预算参数都有明确默认值每个章节包只取窗口内的内容配置项默认值作用context_recent_summaries_window3只带最近 3 章的剧情摘要context_recent_meta_window3只带最近 3 章的章节元数据context_max_appearing_characters10出场角色最多 10 个context_story_skeleton_interval20全书骨架每 20 章采样一次context_story_skeleton_max_samples5骨架采样最多 5 个context_story_skeleton_snippet_chars400每个骨架摘要截断到 400 字context_alerts_slice10歧义告警最多保留 10 条其中故事骨架story_skeleton设计得特别精巧写第 400 章时系统会按context_manager.py中_load_story_skeleton的逻辑从第 380、360、340……章各摘一段 400 字的缩影让模型记得住全书大走向却不用付出整本书的 token 代价。️此外章节大纲加载时硬截断在 1500 字见_load_outline世界观、力量体系等全局设定也只取骨架文件。杠杆二模板权重 —— 不同章节类型不同预算在 context_weights.py 中系统定义了 4 种上下文模板每种模板对三大区块core 剧情核心 / scene 场景人物 / global 全局设定的预算配比不同模板coresceneglobalplot剧情章默认0.400.350.25battle战斗章0.350.450.20emotion情感章0.450.350.20transition过渡章0.500.250.25战斗章把 45% 的预算给场景与人物招式、在场角色最关键过渡章则把 50% 给剧情核心推进主线最重要——预算跟着写作任务走而不是平均分配。⚖️杠杆三动态预算 —— 连载越久预算重心越偏移这是很多长文工具忽略的细节。_resolve_context_stage会把章节分为三个阶段early第 30 章前core 权重上浮人物和剧情刚铺展最需要记得住设定mid30~120 章使用基础权重late第 120 章后global 权重从 0.25 提升到 0.35。为什么后期要加大全局设定权重因为连载越久遗忘的代价越大——力量体系、人物关系网早就定型模型必须看到更多全局锚点才能避免前后矛盾。这套阶段权重同样定义在 context_weights.py 的TEMPLATE_WEIGHTS_DYNAMIC_DEFAULT中。ranker 的排序魔法不删内容只调顺序窗口和权重决定了装什么而 context_ranker.py 决定了先看到什么。它不删除任何内容只做确定性排序对摘要、元数据、出场角色、故事骨架、告警五个列表重新打分排序。核心打分公式_combine_score总分 新近度 × 0.7 频率 × 0.3 加分项三个因子各有门道新近度1 / (1 章节差距)上一章的摘要几乎满分十章前的摘要只剩约 1/11 的分数频率log(1 出场次数) / log(11)用对数压缩避免戏份最多的主角无限霸榜钩子加分0.2摘要里如果出现悬念钩子反转冲突说明这是剧情关键节点直接提权置顶。另外两个细节体现了工程经验出场角色如果带有warning标记存疑实体扣 0.15 分防止待澄清的角色干扰创作告警列表中严重级别为 critical/high 的 0.3文本含冲突、矛盾、违规、断裂等关键词的再 0.3——红线问题永远排最前。所有权重0.7 / 0.3 / 0.2都是可配置项打开context_ranker_debug后每个条目还会附带_context_score调试分方便你验证排序是否符合预期。一条完整流水线build_context 做了什么在 context_manager.py 中一次上下文构建分三步走_build_pack(chapter) → 装配 13 个区块core / scene / global / 契约 / 信号 / 骨架…… ↓ ranker.rank_pack(pack) → 对五个高频列表重新排序并写入 meta 中的 ranker 参数 ↓ _assemble_json_payload(...) → 按模板权重裁剪区块标记 context_contract_version最终产出的不是原始文件堆而是一份结构化的上下文包。下游的 context-agent.md写作前的研究 agent会消费这份包输出一份五段写作任务书交给起草阶段——也就是说token 预算在这里被两次压缩先由 manager 圈范围再由 agent 压缩成人类可读的任务书。新手上手建议如何调好你的上下文预算先跑默认值所有参数在 config.py 都有经过调校的默认值大多数项目无需修改摘要窗口3 章偏小如果你的剧情伏笔跨度常超过 3 章可以适当调大context_recent_summaries_window但记得它直接乘在每章 token 消耗上连载过 120 章留意context_dynamic_budget_late_chapter阈值确保后期章节自动切到 late 阶段把全局设定权重拉高想验证排序开启context_ranker_debug在输出里检查_context_score_detail确认钩子章节是否真的排在前面想临时关闭排序设context_ranker_enabled为 False 即可回到纯按窗口装配的模式。相关行为均有测试覆盖可参考 test_context_manager.py 与 test_context_ranker.py。相关源码导航文件职责webnovel-writer/scripts/data_modules/context_manager.py上下文包装配主入口窗口截断与模板权重解析webnovel-writer/scripts/data_modules/context_ranker.py确定性排序器新近度/频率/钩子打分webnovel-writer/scripts/data_modules/context_weights.py4 种模板 × 3 个阶段的基础与动态权重表webnovel-writer/scripts/data_modules/config.py全部预算参数的默认值与说明webnovel-writer/agents/context-agent.md消费上下文包的写作研究 agent 定义一句话总结Webnovel Writer 用窗口圈范围 → 权重定预算 → 排序提信号三层漏斗把 200 万字量级的记忆压缩成每章几十 K 的有效上下文——这正是它敢让 AI 连续写几百章而不失忆、不幻觉的底气所在。【免费下载链接】webnovel-writer基于 Claude Code 的长篇网文辅助创作系统解决 AI 写作中的「遗忘」和「幻觉」问题支持 200 万字量级 连载创作。项目地址: https://gitcode.com/GitHub_Trending/we/webnovel-writer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考