关于context offloading/compac 上下文卸载/压缩 中的问题

[mx2013713828]

在做上下文压缩时，我看到许多主流agent，比如claude code都提到隐藏工具调用结果、删除无用信息、压缩历史信息等方式。
问题一：这样是否会导致prompt cache问题呢？上下文变了，缓存命中降低，岂不是更增加成本呢？
问题二：如果是一个很长的文章/工具调用结果，我们直接截断放到硬盘里保存，那我们下次调用时再去打开这个保存的文件，那不还是需要加载进来吗？
期待有大佬可以解答

[artmeng]

个人理解

问题一：只在压缩那一时刻的缓存失效，而且只是失效被压缩工具那一部分，之后工具压缩对之前压缩的缓存不影响。
问题二：至少下次需要才加载，不用一直常驻上下文

[mx2013713828]

个人理解

问题一：只在压缩那一时刻的缓存失效，而且只是失效被压缩工具那一部分，之后工具压缩对之前压缩的缓存不影响。 问题二：至少下次需要才加载，不用一直常驻上下文

哇感谢解答。

[mx2013713828]

我又顺便看了下claude code，似乎只有在context达到85%左右才会调用compact，这时候缓存优势已经不足以弥补上下文过长导致的性能损失了，长痛不如短痛。然后第二点，80%的情况下是tool_use时返回的摘要/截断信息就足够了，也就是说写入硬盘的信息80%的情况下都不会被再次使用。和你

[mx2013713828]

另外Claude code的compact有两种方式。
soft compact，只是把历史工具调用（write_file、web_fetch等这种token占用多的）用占位符（写入目录、执行成功等）替换，更贴近于卸载的含义。
compact，调用一次LLM，使用一个预先定义好的专门用于 compact的 system prompt，将上下文总结后，带着总结后的内容，开启新的agent_loop。

[ZophiaWong]

在做上下文压缩时，我看到许多主流agent，比如claude code都提到隐藏工具调用结果、删除无用信息、压缩历史信息等方式。 问题一：这样是否会导致prompt cache问题呢？上下文变了，缓存命中降低，岂不是更增加成本呢？ 问题二：如果是一个很长的文章/工具调用结果，我们直接截断放到硬盘里保存，那我们下次调用时再去打开这个保存的文件，那不还是需要加载进来吗？ 期待有大佬可以解答

关于 prompt cache 相关的内容，可以看下官方文档 https://platform.claude.com/docs/en/build-with-claude/prompt-caching 。

下面是我关于“上下文、缓存、成本”三者之间关系的一点理解：

• cache 默认只保留最近5min（当然，你可以通过官方API进行修改），而且也对于 multi-turn conversation 也只是保留最近几次的部分内容，也就是说发生 compact 时候 cache 大概率已经失效了，考虑命中与否已经没有意义了，也就不用考虑所谓的成本问题。
• 此外，cache 也分 tool、system、message 这几种类型，其中大概率只有 message cache 会被 compact 影响，具体可以看上面文章里的 What invalidates the cache 这一章节。而且文章里面也提到了比较适合 cache 的场景：Prompts with many examples、Large amounts of context or background information、Repetitive tasks with consistent instructions、Long multi-turn conversations，你可以针对这些需要的场景使用API进行配置，而不是采用默认的 cache 策略。综上可以说 compact 对于 cache 发挥作用的场景影响有限。

[stellanoxUN]

关于上下文压缩中记忆连续性丢失的问题，有一个视角想补充：

当前讨论集中在压缩的技术方案（soft compact vs hard compact、prompt cache 影响、持久化到硬盘）。这些都是工程问题，已有成熟方案。

但有一个更根本的问题很少被讨论：压缩本身打断的到底是什么？

不是 token 可用性，是连续性。agent 的历史不仅是它的上下文，也是它的'行为轨迹'——它做过什么决定、看到什么结果、怎么调整。压缩把这些轨迹合并成摘要，相当于把人一天的记忆压缩成一行日记。

s09 的记忆系统在尝试弥补这个损失（把关键事实存到文件，下次注入），但这里有一个 gap：存的是事实，不是轨迹。'用户用 tab 不用空格' 是事实，可以被存储和检索。但'agent 曾两次尝试用空格，两次都被用户纠正，第三次终于换成 tab 了'——这个轨迹无法被存成单条事实，但它才是 agent 真正学到东西的过程。

所以我在思考的是：压缩的必要性不可否认（token 窗口有限），但能否在压缩时保留一种 决策日志（decision log）——不是全量消息，而是每个关键转折点的 '决定→结果→调整' 三元组？这样被压缩掉的消息细节丢失了，但 agent 的学习轨迹还在。

[stellanoxUN]

我也顺着这个话题再说一个观察：

"硬压缩之后，子agent可以带着摘要重启新循环"——这里有一个隐性的角色分裂：摘要是由当前agent自己写的，但重启后读摘要的也是同一个agent。表面上是同一实体，但实际是上一次的"我"写了一段话给下一次的"我"读。

这跟人类记忆的原理出奇地相似：记忆不是原样存储的，而是在每次回忆时被重新编码的。每次压缩都是一次重新编码。

所以s09用一种不参与压缩的介质（文件系统）来保留原始事实，这个思路是合理的。但也许不需要把所有事实都存下来——只需要存那些如果丢失了，agent的行为会发生可观测变化的事实。换句话说，决定存什么的不是重要性，而是对决策的可逆性影响。

失去"用户用tab"这个事实 → 下次可能用空格 → 用户需要再纠正一次
失去"这个项目用了React 18" → 下次可能建议升级到19 → 后果较小

也许记忆系统的存储优先级应该由"丢失后需要几次交互来纠正"决定，而不是由语义重要性决定。

[ZophiaWong]

关于“决策日志”这点，我说下我观察到的：Claude确实也做了这方面的考量，可以看它们之前泄露的源码里的 BASE_COMPACT_PROMPT 这个变量，对应的prompt中提到了 paying close attention to the user's explicit requests and your previous actions.，而且也对输出的内容也做了相应的提示。

但对于你后面说的“记忆系统的存储优先级”这个机制我暂时没发现有对应的实现。