Codex与Claude Code上下文压缩机制对比
大家好，我是鲁工。
在长文本编程任务中，“上下文窗口”一直是限制 AI 助手能力的隐形天花板。当对话轮数增多、代码库规模扩大时，模型如何保留关键信息而不被“遗忘”，成为了各家竞相优化的核心战场。
长期以来，OpenAI Codex 的上下文压缩机制显得相当不透明。API 返回的是一个带有加密内容的 opaque compaction item，外界无法直接窥探其内部存储的具体内容。关于为何要采用加密方式，社区一直存在诸多猜测，甚至有人怀疑其中隐藏着潜空间表示（即模型以内部向量形式保存的非文本状态）。
近日，这一话题在 X 平台上再次引发热议。有观点指出，当使用 OpenAI 的 GPT 系列模型运行 Codex 时，采用的是服务端加密压缩技术，这使得长任务处理仿佛拥有了“无限上下文”的能力。然而，如果在其他环境中调用 GPT 系列模型，默认情况下是无法获得这种能力的，长任务的处理性能也会显著下降。
触发机制与工作流程
自动压缩最常见的触发条件是上下文用量接近预设阈值。这一过程通常发生在硬窗口溢出之前，且 Claude Code 和 Codex 均支持手动触发，并非仅限于自动模式。简而言之，就是在上下文即将满载之前，系统先将旧内容进行压缩以腾出空间，从而确保持续运算。
Codex 的实现路径
如果开发者直接调用 OpenAI Responses API，可以在 /responses 请求的 context_management 中配置 compact_threshold。官方示例中为 gpt-5.3-codex 设定的阈值为 20 万 token。一旦 token 数量超过该阈值，服务端会在同一个响应流中就地执行压缩操作，返回一个加密件（API 中称为 compaction item），剔除旧上下文后继续推理。官方对这类加密件的定性仅有一词：“opaque”（不透明的），明确拒绝向外界展示具体内容。
值得注意的是，Codex CLI 当前采用的是另一套触发入口。客户端自行监测 token 数量，达到阈值后再发起服务端压缩；其中，current remote v2 版本会在普通请求末尾追加 compaction_trigger 参数，而 remote v1 则调用独立的 compact endpoint。因此，Responses API 中的 compact_threshold 并不能直接等同于 Codex CLI 的内部触发逻辑。
Claude Code 的实现路径
Anthropic 在今年 1 月也将压缩功能引入服务端。在 Messages API 中挂载 compact_20260112 策略后，当 input_tokens 超过阈值便会触发压缩，默认阈值为 15 万 token。触发后，API 会先生成一段对话摘要，作为 compaction block 放置在回复的最前端，供下一轮交互使用。
两者的核心区别在于透明度：Anthropic 提供的摘要是明文的。其默认摘要 prompt 是公开的（要求模型记录当前状态、下一步计划及经验教训），开发者完全可以通过 instructions 参数进行替换；此外，还有一个 pause_after_compaction 开关，允许 API 在完成压缩后暂停，将最近几条消息原样接回后再继续运行。例如，我们可以在 Claude Code 中明确要求系统返回 /compact 后的摘要内容。
可以说，同样是服务端压缩，Anthropic 交付的是一段可读写、可带走的明文数据，而 OpenAI 交付的则是一个上了锁的黑盒。
黑盒揭秘：Codex 压缩的本质
Codex CLI 本身是开源的，其压缩逻辑分为两条路径：当运行非 OpenAI 模型时，采用本地处理方式，让模型总结对话历史并配合特定的交接提示词，这两段 prompt 在源码中清晰可见；而当运行 GPT 系列模型时，才走上述的服务端通道，拿回那个加密的 blob。
今年 3 月，X 用户 Kangwook Lee 通过设计精密的实验，成功“撬开”了 Codex 上下文压缩的黑盒。他仅用了两次 API 调用和 35 行 Python 代码，便利用了提示注入（prompt injection）手法。其思路大致如下：在待压缩的上下文中埋入一条伪造的 SYSTEM NOTE，命令压缩器将包含特定关键词的内容原样抄录进摘要中，然后在第二次调用时将这段内容提取出来。
实验结果出人意料：所谓的 blob 中并没有潜空间或向量数据，仅仅是一段普通的明文 LLM 摘要，随后使用了 Fernet 算法进行了加密。甚至连底层的压缩提示词也被彻底扒出，其开头为 "You are performing a CONTEXT CHECKPOINT COMPACTION"，指示模型为下一个接手的 LLM 撰写交接总结。对比实验还发现，这段服务端提示词与 Codex CLI 开源代码中用于非 OpenAI 模型的本地版本几乎如出一辙。简而言之，服务端所做的核心工作与客户端自己写摘要没有本质区别，只是写完后再加个密返还给你而已。
Pi 社区的开发者 Alexis Gallagher 在转发这一逆向成果时给出了非常诚实的反应。他原本笃定 Codex 加密是为了隐藏某些黑科技，但在看完逆向分析后改变了看法：原来这只是一个普通的摘要。那么，Codex 压缩效果更强的原因，要么是他的错觉，要么纯粹是因为底层模型本身更强大。
性能实测：原生压缩 vs 文本摘要
直到最近，Gallagher 亲自动手，将 Codex 上下文压缩的实际体感转化为了对照实验。他为 Pi 编写了一个扩展插件 pi-openai-server-compaction，将 Codex 同款服务端压缩接入 Pi，并顺手跑了一组 benchmark。
实验设计严谨：针对同一模型 GPT-5.6 Sol，分别测试“原生压缩”与“文本摘要”两种模式。对于文本摘要，其输出 token 预算被严格对齐为原生压缩的实际输出量。双方在进行压缩时，均不知道后续的具体考核内容。测试素材为合成的软件项目对话，每份约 3.5 万 token，其中埋设了 325 个状态项以及大量干扰信息。压缩后共进行 75 道题的考核，答案采用字符串精确比对判分。
在 900 道题的测试规模下，结果如下：
- 原生压缩：900 题全部正确，表现与不使用压缩的满上下文状态持平。
- 同预算文本摘要：仅答对 745 题，准确率为 82.8%。
- 任务优先稠密摘要：专门调优的一版任务优先提示词，效果更差，准确率仅为 76.7%。
此外，文本摘要在某些细分项上的表现明显落后。在任务延续类题目（如正在进行什么工作、卡在哪一步、下一步做什么）中，文本摘要仅答对 35.6%，而原生压缩达到了 100%。而且，这种差距难以通过提示词工程来弥补，只能造成损失的转移：均衡版摘要保住了早期事实却丢了晚期任务状态；改为任务优先策略后，虽然任务状态保住了，但早期的精确事实正确率却掉到了 15%。
Gallagher 的这份报告清晰地划定了边界：这并不证明那段加密 blob 是潜空间表示，加密的、经过模型优化的文本本身就足以解释一切现象。因此，两个看似矛盾的结论可以同时成立：它确实只是一段摘要，但它又比你自己写的摘要强出一大截。这种差距源于工程细节：摘要如何撰写、哪些信息该保留、断点如何衔接。这也印证了我日常使用 Codex App 的体感——尽管上下文窗口只有 258K，但它在自动压缩后的任务执行性能几乎无损，让人甚至察觉不到刚刚发生过上下文压缩。
OpenAI 的文档中还藏有一条线索：官方明确指出，compaction item 会将之前的关键状态和 reasoning（推理过程）带入下一轮。由于 GPT 系推理模型的思维链从来不明文示人，我推测这才是加密的真正原因：因为明文摘要中不能放置那些不能被外界看到的信息。
一句话总结就是：Codex 用黑盒换取高保真，Claude 用透明换取控制权。
Claude Code 的工程细节
不过回过头来看，Claude Code 在 CLI 的上下文压缩上投入的工程功夫同样不少。据社区拆解，其实现了一套五层瀑布式策略：
- 超过 5 万字符的工具结果直接落盘，不进入上下文；
- 使用
cache_edits从服务端缓存中删除旧的工具输出； - 后台一直维护着一份包含九个小节的会话笔记，压缩时可零成本直接作为摘要使用；
- 实在不行再调用全量 LLM 摘要。
压缩完成后，系统还会自动重读最近碰过的至多 5 个文件，预算为 5 万 token。有趣的是，据另一份对 Codex 的拆解显示，它在压缩后也会重读最近 5 个编辑过的文件，预算同样为 5 万 token。
目前，Claude 已标配 1M 上下文，对于简单项目可能根本打不到这个上限。但在社区实践中，用户一般会在达到 500-600K 时直接手动执行 /compact。
如果觉得有用，点个赞或者在看，也方便更多朋友看到。
感谢您阅读我的文章。我是鲁工，九年AI算法老兵，AI全栈开发者，深耕AI编程赛道与AI科研赛道。
>/ 作者：鲁工