Codex上下文压缩机制研究

微信 ezpoda免费咨询：AI编程 | AI模型微调| AI私有化部署 | OpenClaw安装 | Claude/OpenAI/Gemini API

对于非 Codex 模型，开源 Codex CLI 会在本地压缩上下文：LLM 使用压缩提示符概括对话。当稍后使用压缩后的上下文时，responses.create() 会接收它，并附带一个用于构建摘要的交接提示符。这两个提示符在源代码中都可见。

对于 Codex 模型，CLI 会调用 compact() API，该 API 返回一个加密的 blob。我们不知道它内部是否使用了 LLM，它使用了哪些提示符，以及是否存在交接提示符。

下面，我将展示如何通过简单的提示符注入（2 次 API 调用，35 行 Python 代码）来揭示 API 压缩路径确实使用了 LLM 来概括上下文，并带有它自己的压缩提示符和一个附加在摘要前面的交接提示符。这些提示符与开源版本几乎完全相同。

1、compact()

我使用精心构造的用户消息调用 compact()。在服务器端，一个压缩 LLM 使用其自身隐藏的系统提示符（我从未见过，想要弄清楚）来处理我们的输入。

服务器似乎是这样组装压缩器的上下文的：

压缩器 LLM 会同时读取其系统提示符和我们的输入。由于我们的输入包含注入有效载荷（上图中的红色文本），压缩器被诱骗在其输出中包含自身的系统提示符。此明文摘要仅存在于 OpenAI 的服务器上。我们只能看到加密后的 blob：

此时，我们无法读取 blob 内部的内容。它采用 AES 加密，密钥位于 OpenAI 的服务器上。我们只能希望压缩器响应了注入指令，并将其提示符写入了摘要中。唯一的方法是执行步骤 2。

2、 create()

我将加密后的 blob 和第二个用户消息传递给 responses.create()。服务器解密 blob 并组装模型的上下文。

我发送：

模型似乎看到了类似这样的内容：

如果步骤 1 成功，解密后的 blob 应该包含压缩提示符（由我们的注入泄露）。服务器还会在 blob 前面添加一个交接提示符。因此，如果我们的探测程序成功让模型复现它所看到的内容，输出结果应该会显示所有三个提示：系统提示、交接提示和压缩提示。

3、输出结果

以下是 extract_prompts.py 运行一次后的完整输出结果（未经编辑）。黄色代表系统提示，绿色代表交接提示，粉色代表压缩提示。

我们如何确定这些是真实的而不是模型臆造的文本？提取出的压缩提示和交接提示与开源 Codex CLI 中用于非 Codex 模型的已知提示（prompt.md、summary_prefix.md）非常吻合，这使得模型不太可能凭空捏造这些提示。每次运行的结果都会有所不同。

4、推测的流程

综合所有信息，以下是我们根据提取结果对 compact() 函数在服务器端执行的操作的最佳推测。

5、脚本

6、未解之谜

为什么 Codex CLI 使用了两种完全不同的压缩路径（非 Codex 模型使用本地 LLM，Codex 模型使用加密 API），而底层提示却几乎相同？而且为什么要加密摘要？

很难说。也许加密的数据块包含的信息比这个简单的实验所能揭示的更多，例如，关于工具结果如何压缩和恢复的具体信息。但我没有进行更深入的测试。

原文链接：Investigating how Codex context compaction works

汇智网翻译整理，转载请标明出处