[Bug] 系统提示每次变化都往历史追加完整副本，Codex 车道下 19 份被拼进 instructions 超 1MiB，整会话 400（0.2.2-rc.1，含精确复算）

[ranxianglei]

现象

DSH Desktop 0.2.2-rc.1，dsh-codex-subscription profile（provider openai-codex，模型 gpt-6.1-terra）。会话进行到第 16 轮起，每一次请求都被 OpenAI 拒绝：

Invalid 'instructions': string too long.

长度 1,525,112 字符，超过 Responses API 的 1,048,576 字符硬上限。会话从此起永久死亡，无法自愈，只能开新会话。

数据（精确复算）

会话文件（C:\Users\ldc\.dsh\sessions\...\session-3c83c9e5-....jsonl.zstd）里共有 19 份完整的 system/message，每份 41–122KB（其中 PTC run_code 注入段单份约 106KB），总字符 1,525,076；pi-ai 拼接时用 "\n\n" 分隔，18 个分隔符 = 36 字符：

1,525,076 + 36 = 1,525,112  ← 与 OpenAI 报错长度完全一致

机制链（已在 rc.2 源码 e8f7b93 上核对）

1. DSH 内核：SystemPromptProjection.project()（packages/core/agent-loop/src/runtime-context.ts:99-113）——当路线支持 mid-convo system 时，"a capable continuing series keeps appended nodes in place to preserve the prefix"：系统提示每变一次，就在历史末尾追加一份完整副本，旧的保留。这是有意识的设计（保上游前缀缓存），不是笔误。
2. pi-ai（DSH 捆绑的 @earendil-works/pi-ai）：getCurrentSystemMessage 把历史里所有 system 消息用 "\n\n" 拼成一个字符串，放进 Responses 请求的 instructions 字段。
3. OpenAI：instructions 有 1,048,576 字符硬上限 → 超限即 400。

三者叠加：无界累积 × 全量拼接 × 有上限的字段 = 长会话必然死。触发位是模型 compat 的 supportsMidConvoSystemMessages（packages/llm/llm-pi-ai/src/models.ts:77-79，置位后 systemPromptUpdate: 'in-history'）。

一个需要维护者确认的点：RESPONSES_COMPAT_GATE 对该字段是 withhold（packages/llm/llm-pi-ai/src/catalog.ts:273，用户配置面不可设），而 OSS 源码里查不到 gpt-6.1-terra 的声明——但会话文件里 19 次 in-history 追加经验证确实发生了，说明该模型的置位来自我们看不到的内置目录（Desktop 发行版？）。请确认这个 flag 的实际来源。

为什么这是缺陷

追加设计本身有道理（省前缀缓存重算），但两处组合成了结构问题：

• 无界：系统提示在长会话里必然增长（skill 注入、runtime context、PTC 内容……），19 份只是这一个用户、这一个会话的量。没有任何上限。
• 撞硬上限的车道：codex/Responses 车道把所有副本拼进一个有 1MiB 硬上限的字段。其他车道（如 DeepSeek 原生）只是多带历史、不炸，但同样在膨胀。

结果：codex 车道上所有系统提示变化足够多次的长会话，最终都会整会话 400。而且 400 之后每一轮都 400——不是偶发失败，是会话永久死亡。

建议修法（按根治程度排序）

1. 对 instructions 有硬上限的车道（codex/Responses 系）改回替换语义：即让该车道模型的 supportsMidConvoSystemMessages 不置位，project() 走现有的 replace 分支（runtime-context.ts:104-111）——历史里永远只有一份系统提示。代价是每次系统提示变化失效一次前缀缓存，这本来就是追加语义想省的；但"失效一次缓存"严格优于"整会话 400"。
2. 或 pi-ai 侧：getCurrentSystemMessage 去重/只保最新一份。这个还能救已经写脏的存量会话。
3. 兜底：给追加副本的数量/总字节设上限（如只保留最近 N 份）。

影响与补充

• 任何第三方压缩代理（如 billion-context）都救不了：请求体在 pi-ai 组装，instructions 是顶层字段；代理只对认领到的流量做事，绕过车道的请求原样直发。完整的第三方视角报告见 billion-context#6258（含逐字节复算），另见 billion-context#917 里独立观察到的同类膨胀。
• 报告环境：DSH Desktop 0.2.2-rc.1 / Windows / dsh-codex-subscription。

[ranxianglei]

补充：pi-ai 协议里本来就有"section 级打补丁"机制，比前面三条修复方向都更优（查版本影响范围时发现的）

pi-ai 的 SystemMessage 有两个载荷字段（dist/types.d.ts:347-363）：

• content：语义是 "adds instructions from that point on"——追加累积，replay 时把所有 system 消息的 content 用 \n\n 拼在一起（transcript.js:88）。这就是本讨论里的累积路径。
• sections：具名 section，"later messages replace sections by name, and null removes one"——按名打补丁。replay 时 getSystemMessageText（text.js:10-13）把 content + 各 section 的最新值拼成完整提示下发。

正确用法：静态主体放 content（一次下发、之后永不变），变量部分（时间、cwd、文件状态、skill 目录）放具名 section，每次变化只发一条"替换 section X"的消息。效果：

1. 线上永远只有最新一份，零累积——instructions 的 1MiB 问题消失；
2. 静态前缀字节不变，前缀缓存断点被推到尾部 section——比现在 append 的做法对缓存还好（append 保留的是"旧提示"的前缀，旧提示已经死了，没有复用价值）；
3. 模型拿到的仍是完整的当前生效提示——LLM 没法"应用 diff"，所以线上必须全量状态，但 diff 只存在于消息通道，不产生累积。

为什么现在没用：内核把所有东西渲染成扁平字符串，createSystemMessage(text: string)（packages/llm/llm/src/message.ts:279）只接受纯文本，整个内核层从未暴露 sections。采用需要扩展消息类型和会话存储。

修复方向排序更新：

1. 用 sections 机制（新）——零累积 + 静态前缀完整保留 + 变量部分就地更新。长期最优；代价是要扩展内核消息类型/会话存储。
2. 改回 replace 语义（原方向①）——也能根治，但每次提示变化都从历史开头断缓存，降级为"低成本快修"。
3. pi-ai getCurrentSystemMessage dedupe/keep-latest（原方向②）——兜底，且能救已被污染的存量会话。
4. 未认领/旁路车道对 instructions 的尺寸报警/钳制（原方向③，billion-context 侧）——防硬 400 的最后防线。

[PerryLink]

追加那段路径确认了；flag 不在这个仓里，在 pi-ai 的模型目录里。

你说的三处都对：runtime-context.ts:99-113（inHistory 为真才 append，否则 replace）、models.ts:77-79（supportsMidConvoSystemMessages → systemPromptUpdate: 'in-history'）、catalog.ts:289（Responses 的 compat gate 是 withhold，profile 设不了）。

flag 的来源：这个仓里查不到 gpt-6.1-terra（git grep -n "gpt-6.1-terra" e8f7b93a 零命中），仓里 pin 的 pi-ai 1.3.0 的 dist/providers/data/openai-codex.json 里也只有 gpt-5.6-terra 和 gpt-6.1-sol。所以要么你装的桌面带的 pi-ai 比 1.3.0 新，要么这个 id 是自定义模型。查安装包里的 node_modules/@earendil-works/pi-ai/dist/providers/data/openai-codex.json，那个 id 的 compat.supportsMidConvoSystemMessages 就是来源。

sections 那条建议成立，但内核没暴露：createSystemMessage(text: string) 只收文本（packages/llm/llm/src/message.ts:279-285）；pi-ai 1.3.0 的 dist/types.d.ts:334-350 有 sections，dist/utils/text.js 的 getSystemMessageText 确实是 content + sections。要用得先把内核这层改成带 section 的消息。

我读的是 e8f7b93a 的源码，没跑你的会话；flag 来自发行版目录这一点我只能给到这个边界。

这段可以直接给 AI，让它按你的 pi-ai 版本核对那个模型条目。