https://svtter.cn/tags/compaction/Recent content in Compaction on Svtter's BlogHugo -- gohugo.iozh-cnThu, 19 Mar 2026 11:30:00 +0800https://svtter.cn/p/codex-%E5%92%8C-opencode-%E7%9A%84%E4%B8%8A%E4%B8%8B%E6%96%87%E5%8E%8B%E7%BC%A9/Thu, 19 Mar 2026 11:30:00 +0800https://svtter.cn/p/codex-%E5%92%8C-opencode-%E7%9A%84%E4%B8%8A%E4%B8%8B%E6%96%87%E5%8E%8B%E7%BC%A9/<img src="https://svtter.cn/p/codex-%E5%92%8C-opencode-%E7%9A%84%E4%B8%8A%E4%B8%8B%E6%96%87%E5%8E%8B%E7%BC%A9/cover.webp" alt="Featured image of post Codex 和 OpenCode 的上下文压缩" /><p>上下文压缩是 coding agent 必备的特性。</p> <p>最近翻 Codex 文档，看到一个点：它明确提到了 <code>server-side compaction</code>。</p> <p>我觉得这个点挺有意思。不是说&quot;压缩上下文&quot;这件事本身有多新鲜，而是它把这件事放在服务端做，并且写进了文档。也就是说，上下文管理不是用户自己在提示词层面想办法，而是产品本身就内建了一套机制。</p> <p>顺手我又去看了一下 OpenCode 的 compaction。两边都叫 <code>compaction</code>，但不是一回事。</p> <p>Codex 这边强调的是：服务端在上下文达到阈值时，会把前面的交互压缩成一个更短的表示，后续请求继续带着这个压缩后的状态跑。文档里写得很清楚，<code>server-side compaction</code> 会用更少的 tokens 携带之前的关键状态。</p> <p><img src="https://svtter.cn/p/codex-%E5%92%8C-opencode-%E7%9A%84%E4%B8%8A%E4%B8%8B%E6%96%87%E5%8E%8B%E7%BC%A9/compaction-flow.webp" width="2752" height="1536" srcset="https://svtter.cn/p/codex-%E5%92%8C-opencode-%E7%9A%84%E4%B8%8A%E4%B8%8B%E6%96%87%E5%8E%8B%E7%BC%A9/compaction-flow_hu_f03edb827bd032dc.webp 480w, https://svtter.cn/p/codex-%E5%92%8C-opencode-%E7%9A%84%E4%B8%8A%E4%B8%8B%E6%96%87%E5%8E%8B%E7%BC%A9/compaction-flow_hu_556f88c4a4052352.webp 1024w" loading="lazy" alt="Codex server-side compaction 示意图" class="gallery-image" data-flex-grow="179" data-flex-basis="430px" ></p> <p>OpenCode 这边，我看了一下源码，它也有 compaction，但更像应用层的会话压缩：上下文快满时，调用一个隐藏的 <code>compaction</code> agent 生成 summary，后续请求不再带完整旧历史，而是保留这段 summary 继续。还有 <code>prune</code> 会把旧的工具输出清掉，只保留占位文本。</p> <p><img src="https://svtter.cn/p/codex-%E5%92%8C-opencode-%E7%9A%84%E4%B8%8A%E4%B8%8B%E6%96%87%E5%8E%8B%E7%BC%A9/agent-compaction.webp" width="2752" height="1536" srcset="https://svtter.cn/p/codex-%E5%92%8C-opencode-%E7%9A%84%E4%B8%8A%E4%B8%8B%E6%96%87%E5%8E%8B%E7%BC%A9/agent-compaction_hu_ce8a676aa70786e6.webp 480w, https://svtter.cn/p/codex-%E5%92%8C-opencode-%E7%9A%84%E4%B8%8A%E4%B8%8B%E6%96%87%E5%8E%8B%E7%BC%A9/agent-compaction_hu_3701a87c6e58bf7c.webp 1024w" loading="lazy" alt="OpenCode 应用层 compaction 示意图" class="gallery-image" data-flex-grow="179" data-flex-basis="430px" ></p> <p>所以两边虽然名字一样，但关注点不一样：</p> <ul> <li>Codex：服务端的上下文管理能力</li> <li>OpenCode：应用层的会话状态续写</li> </ul> <p>这个区分我觉得值得记一下。很多人看到同一个词，就默认是同一种机制，其实不是。与其急着比较谁更省、谁更好，不如先把机制边界看清楚。</p> <h2 id="参考">参考 </h2><ul> <li><a class="link" href="https://developers.openai.com/api/docs/guides/compaction" target="_blank" rel="noopener" >OpenAI Compaction 文档</a></li> <li><a class="link" href="https://opencode.ai/docs/config/" target="_blank" rel="noopener" >OpenCode Config 文档</a></li> </ul>