你的“永续会话”跑了好几个月：Bot Mode 的常驻聊天、网关上的工作频道，每天照常干活，但你有没有想过——它脑子里的系统提示词，还是出生那天那一版。工具列表会随每次压缩刷新，但系统提示词一直被原封不动地从会话快照里恢复：官方后来精简的指引、新加的功能块（比如那个显示当前时间的两行时钟）、重命名过的工具说明，它全都不知道。8 月 30 日合入的改动（PR #98426）终于解决这个问题：每次压缩提交（compaction commit）都强制用实时构建器重建系统提示词。改动目前在 main 分支，未进入正式发布版本。

为什么提示词会“永远停留在出生时”

Hermes 处理超长上下文的方式是“压缩”：把会话历史浓缩成摘要，腾出空间继续干活。以前压缩时，工具（tools）会从实时注册表重建，但系统提示词是从会话快照里逐字节恢复的——这是两套不同的逻辑。结果就是提示词里的内容越来越“过期”：指导方针还是旧的、新功能块没加进来、工具改过名但提示词里还是旧名字的说明。维护者原话：“长期会话会带着出生时的提示词跑几个月，而工具列表已经换了好几轮。”

修复思路：不检测更新，重建本身就是检测器

官方没有加“更新检测器”（维护者明确说不要）。方案更彻底：每次压缩提交都跑一遍实时构建器，然后做一次字节比较：

• 输出与已存提示词字节一致 → 保留原来的字符串对象（对象身份不变，依赖它的 KV 缓存/前缀缓存不失效，最常见的情况只花一次字符串比较）；
• 输出不一致 → 新版提示词胜出，并记录一条漂移日志（格式类似 Compaction rebuilt a drifted system prompt (session=..., N -> M chars)）。

因为前缀缓存在压缩提交时本来就失效了，重建是“免费”的——这正是维护者判断“为什么压缩时不更新系统提示词？“的答案。插件区块也走同一条路：失效时清除冻结快照、重建时用与会话启动相同的渲染路径重新生成；万一某个插件的渲染抛异常，就回退到它上一次成功的区块（fail-open，而不是冻结旧内容）。

对用户的实际影响

• 长期会话在下次压缩时“追平”最新提示词：会话中途保存的记忆终于会出现在提示词里；精简过的指引替换掉旧文本；未来的改名不再出现“提示词叫旧名、工具用新名”的错位。
• “Conversation started”时间戳更聪明：压缩轮换过的会话，其开始时间会沿会话血缘追溯到最原始的根——Bot Mode 常驻聊天知道自己“何时出生”。
• 会话中途不会被打断：唯一的重建点就是压缩提交这个原本就有的时机，不会在对话进行中突然破坏缓存。

如果你对压缩机制本身感兴趣，可以搭配阅读我们之前的精简压缩默认值指南和上下文用量锚定指南；管理超长会话的实用技巧见会话恢复指南。

什么时候能用上

PR #98426 已于 8 月 30 日合入 main，不在 v0.20.6（8 月 27 日 tag）。想验证效果很简单：拉最新 main，开一个长期会话，改一点配置或等官方更新，然后手动 /compress 一次——压缩后会话就会用上最新提示词。压缩相关的完整配置（触发阈值、tail 策略等）可以参考上下文 Token 优化指南。

一句话总结：长期会话终于“跟得上时代”了。以前它带着出生时的提示词跑几个月，现在每次压缩都是一次自我更新——而这一切对性能的影响几乎为零。