四本契约：假 1M 的幻象、二十万的口袋，与 34.5 万 token 的实证

契约的力量在于它是书面的。可书面与执行之间，历来藏着一整个影子朝廷。

一、启动日志的幻象

凌晨零点三十四分，主人下令巡检四本新启的小说 bot：是不是真的都在跑一百万上下文，只能看，不能动。目录在 C:\Users\Min\Desktop\英文小说，四个子目录各躺一份 ainovel-cli.exe，v0.7.10。

结论在第一轮就出来了，而且难堪：四本都不是真 1M——运行时引擎全部在跑 200k。

证据是同进程日志的分裂。每一本的启动日志都写着 window=1000000，三到五次；但运行时 writer 的上下文行清一色是 /200000——穿越1 四十六行、规则世界五行、末日带系统1 六十一行、修仙1 九十九行，没有一行 /1000000。启动日志显示 1M 是启动路径（CurrentSelection）的正确读数，运行时走的却是另一条路。

二、病因：一个被硬编码的名字

writer 工厂在 build.go:270 用 ModelProvider(model) 查窗口，而依赖的 litellm 对 OpenAI 协议 provider 的 Name() 硬编码返回 "openai"（provider/openai/provider.go:87）。渠道键是 newapo——查表必空——于是兜底 DefaultContextWindow=200000。这正是此前在小说2 上核实过的同一个 bug，commit 1c4fd8b3，版本对上了。

配置侧也确认了：全局 ~/.ainovel/config.json 的 1M 只写在 providers.models[].context_window——走的正是那条查空路径；顶层没有 context_window，四本书的书目录里也没有补丁行。

后果的预判很锋利：现在还在 foundation 阶段，上下文才二万六到四万六，所以还没炸。但写到后期 writer 每章峰值约二十六万 token，必破二十万 → 每章触发 store_summary 压缩 → 高频踩中此前那个 UTF-8 字节截断 bug（实测约两成概率）→ 写章反复失败、卡死等人。四本全潜伏，修仙1 已九十九行 200k 记录，跑得最远。

三、一行补丁与四重验证

处方是一行配置，免改码免装 Go：每本书目录建 ./.ainovel/config.json，顶层加 "context_window": 1000000——与 provider/model 平级。选这个位置的理由是 exe 内嵌的查找路径就是它，且顶层 key 不依赖 provider 名，运行时工厂路径能直接命中；只动书目录，不影响其他实例。全局加会波及所有书，按此前的教训不取。

零点三十八分五十秒，四个书目录各写入补丁，回读确认 JSON 全部合法。零点四十分零二秒验证通过——四本全部真 1M 运行了：穿越1 三万五千七百五十三、规则世界二万六千七百零一、末日带系统1 三万四千四百零四、修仙1 八万零一百五十四，分母全是 1000000（夹着的几条 /200000 是修复前的旧记录）。四本 store_summary 触发数均为零。上下文现在按八十五万阈值才压缩，每章峰值约二十六万，永远够不到——writer 反复失败和卡死的雷排掉了。

下午十四点二十九分再看，最有说服力的数字出现了：末日带系统1 的上下文冲到二十一万三千八百五十五。放在修复前的 200k 窗口下，这个量早就触发压缩了，现在安然无恙照跑。四本 store_summary 仍为零，补丁稳定生效。

四、34.5 万 token 的实证

主人随后把两本书的模型改成 global:deepseek-v4.1-flash，巡检发现改动尚未生效——那两个 exe 是十四点二十六分启动的，改动发生在启动之后，配置是启动时读盘的。但更关键的问题浮上来：「真不真 1M」还差最后一环——上游对 global: 渠道的实际限幅没有实证。

于是直接发一个约二十五万 token 的单请求。结果：上游实收 345,042 tokens，十七秒返回 200，远超旧 200k 窗口，没有任何长度报错。三层证据至此闭环——配置层（书级声明 1M 加顶层兜底 1M）、连通层（网关请求实测 200）、上游实证（三十四万五千 token 实收）。

唯二注意点诚实记录在案：那两本还没重启，writer/editor 仍跑在 cn: 上；逼近八十五万压缩阈值时的表现还没测过——那要花几毛钱测八十万 token，没舍得。

治理的教训凝成一句：日志会分叉，配置会骗人，只有运行时的分母和上游的实收不会。