那么回到这个问题，为什么dsh支持?可能是在模型上做了什么优化?比如AI infra 上的?比如精确到token的增量计算?还是什么优化?

先说结论：这条特性里「不破坏 KV Cache」的部分，大概率不是 AI infra 那种 token 级增量重算，而是「结构上把变化挪出缓存前缀」加「模型侧声明一个能力位」的组合。理由分三层。 第一层，为什么不能靠增量计算做到。 KV cache 是按 token 存 K/V 的，但第 i 个 token 的 K/V 不是独立算出来的，是它拿自己的 query 对前面所有 token 的 K/V 做 attention 得到的。所以你在 system prompt 里改一个 token，它的 K/V 变了，后面每一个 token 的 attention 输入就都变了，理论上整条链都得重算。「只重算变化的那几个 token、后面照旧复用」在数学上不等价，只能做近似（比如把 system 段当成独立 attention 源、或对后续影响做某种缓存），而无损的精确增量在通用推理栈里做不到——真做到无损，就得重算变化点之后的全部 KV，那反而比 cache 更贵。所以「精确到 token 的增量计算」这个方向基本可以排除。 第二层，dsh 自己能做的那部分。 dsh 的 system prompt 是每步重新组装的（dsh-system-prompt 的 README 写得很清楚：插件贡献有序 section、工具 schema、变量，loop 每步 assemble 一次）。但它同时把「动态运行时上下文」单独拿出来，作为带来源的 user-role 快照放进消息历史，而不是塞进 system prompt 本体。这样 system prompt 那段字节级稳定，前缀缓存就能一直命中；变化的部分落在历史里。 再结合 v0.1.5 同一条发布里的另一项改动——会话格式 V3「系统提示词纳入消息历史」——方向就更明显了：让 system prompt 成为历史里的一个可定位条目，而不是每次都重排开头。历史里的改动，追加是安全的（dsh-session README 明确说 appended surface entries preserve reusable prefixes），但 replace 会让复用从第一个被 shadow 的消息起失效。所以「动态修改且不破坏缓存」在客户端侧能成立的形态，基本就是追加式/后置式的修改，而不是回头改写开头那段。 第三层，「模型需显式声明支持」这句在说什么。 如果只是把动态内容挪到历史里，那纯属客户端技巧，不需要模型表态。它要求模型显式声明，说明这个能力涉及模型对提示词结构的处理：比如模型是否接受 system 角色消息出现在历史中段、是否能正确处理多段 system 指令、或者说服务端是否把 system 段和对话段的 KV 分开管理、只重算变化的那段。这几条都是我的推断——公开文档里我目前没找到这条特性的实现细节。dsh 仓库 master 分支上的 system-prompt、session、llm-deepseek 三个 README 到现在还写着「system prompt 的任何变化都可能从第一个变化 token 起让复用失效」，说明这个特性的说明要么还没写进这些文档，要么落在新的包里，要确认得去看对应的 PR 和代码。 所以回到你的猜测：AI infra 层面的优化不能说完全没有，但更准确的画像是「协议结构设计为主，模型侧能力声明兜底」。你想验证的话，最直接的办法是翻 v0.1.5-alpha.1 里 tianyicui 那个 commit（5dda764 附近），看他改的是 system prompt 的组装顺序、session 的条目类型，还是模型能力描述字段——改前两者就是结构方案，改第三个就是模型侧方案。