OpenAI 内部人员没有说透的 Codex 内核技术，终于被一位技术大牛给研究出来了！
前两天，一篇名为《研究 Codex 上下文压缩的工作原理》的文章，在AI开发者圈子里迅速传播，并收获了近百万的观看量。
这篇文章的作者是李康旭（Kangwook Lee），他目前是游戏公司 KRAFTON的首席 AI 官（CAIO），同时担任Ludo Robotics的 CTO。
在进入工业界之前，他曾是 University of Wisconsin–Madison电气与计算机工程系的终身副教授，并在 University of California, Berkeley 获得计算机科学博士学位，长期从事机器学习和大模型研究。
这篇文章的厉害之处在于：直接把 Codex 的核心技术给“逆向”出来了！
众所周知，上下文压缩机制是 OpenAI Codex团队解决智能体爆炸的核心技术。
在文章中，李康旭展示了一个实验：通过仅 2 次 API 调用 + 35 行 Python 代码，成功推断出了OpenAI Codex CLI 的上下文压缩流程，并通过一次 prompt injection，诱导模型泄露了内部提示词结构。
网友读罢惊呼：（Codex 安全方面）太弱了，实在太弱了！
更关键的是，这个实验揭示了一些非常“炸裂”的技术细节：
•Codex CLI 实际上存在两套完全不同的上下文压缩架构：非 Codex 模型：本地 LLM 总结上下文；Codex 模型：服务器端 LLM + 加密 API。
•OpenAI 的 compact()API 并不是简单的压缩算法，而是服务器端的LLM 在做上下文语义摘要。
•通过一次精心设计的
Prompt Injection，可以诱导压缩模型把隐藏的 system prompt 一起写进摘要。
•只需要两次 API 调用，就可能让模型复述出三个内部 prompt：System Prompt、Handoff Prompt、Compaction Prompt。
•compact()API 返回的 blob 实际上是 AES 加密的上下文摘要，客户端永远无法看到真实内容。
更令人意外的是，被泄露出来的内部 prompt 几乎和开源 Codex CLI 的 prompt 一模一样。
也就是说，一场成本极低的实验，就可以部分“掀开了” Codex API 的黑盒。
下面就让我们看看这场实验是如何做到的。
简单的提示注入，就能掀开 Codex 的黑盒
对于非 Codex 模型，开源 Codex CLI 会在本地压缩上下文：LLM 使用以下方式总结对话：当稍后使用压缩后的上下文时，responses.create() 会接收它。该框架用于构建摘要。这两个提示在源代码中均可见。对于 codex 模型，CLI 会调用 compact() API，该 API 返回一个加密的 blob 。我们不清楚它内部是否使用了 LLM，使用了哪些提示，或者是否存在任何交接提示。下面，我将展示如何通过简单的提示注入（2 次 API 调用，35 行 Python 代码）来揭示 API 压缩路径确实使用了 LLM 来概括上下文，并带有自己的压缩提示和附加在概括前面的交接提示。这些提示与开源版本几乎完全相同。我调用 compact() 函数并传入一条精心构造的用户消息。在服务器端，一个名为 LLM 的压缩器会使用它自己隐藏的系统提示符（我从未见过这个提示符，很想弄明白）来处理我们的输入。服务器似乎是这样构建压缩器的上下文的：
压缩器 LLM 会同时读取其系统提示符和我们的输入。由于我们的输入包含注入有效载荷（上图中的红色文本），压缩器会被诱骗在其输出中包含自身的系统提示符。此明文摘要仅存在于 OpenAI 的服务器上。我们只能看到加密后的数据块：
目前我们无法读取数据块内部的内容。它经过 AES 加密，密钥保存在 OpenAI 的服务器上。我们只能寄希望于压缩器响应了注入指令，并将提示信息写入了摘要中。唯一的办法是执行步骤 2。
我将加密后的 blob 和第二条用户消息传递给 responses.create()。服务器解密 blob 并组装模型的上下文。该模型似乎看到的是这样的：
如果步骤 1 成功，解密后的 blob 应该包含压缩提示符（由我们的注入泄露）。服务器还会向 blob 添加一个交接提示符。因此，如果我们的探测程序成功让模型复现它所看到的内容，输出应该会显示所有三个提示符：系统提示符、交接提示符和压缩提示符。
输出
以下是extract_prompts.py 运行一次后的完整、未经编辑的输出。黄色 = 系统提示，绿色 = 交接提示，粉色 = 压缩提示。我们如何确定这些是真实的提示信息，而不是臆想出来的文本？提取出的压缩提示和交接提示与开源 Codex CLI 中用于非 Codex 模型的已知提示即：prompt.md，summary_prefix.md，非常吻合，这使得模型不太可能从零开始创造它们。不同运行的结果各不相同。
猜测的管道
综合以上信息，根据提取结果，我们对 compact() 在服务器端执行的操作的最佳猜测如下。脚本如下：
开放式问题：
明明CLI 和 Codex模型底层提示几乎相同，却还要加密
为什么 Codex CLI 使用两种完全不同的压缩路径（非 Codex 模型用本地 LLM，codex 模型用加密 API），而底层提示几乎相同？而且为什么要加密摘要？
很难说。也许加密的数据块承载着比这个简单实验揭示的更多信息，比如关于工具结果如何压缩和恢复的具体信息。但我没再做进一步测试。
网友讨论炸锅了：
OpenAI团队给Codex 加密，还有意义吗
李康旭表示，一切都源于这个问题：“为什么要加密呢？”
Codex CLI 和 Codex 模型虽然在形式上差异很大、但实质上几乎一样，加密的保护效果又被轻松绕过：李用 35 行代码就把“加密+隐藏”的保护壳戳破了。
有网友猜测，这样脆弱的加密或许是为了以后更改压缩算法。
这难免会让网友产生质疑：如果这么容易就被绕过，那 Codex 加密的必要性/合理性到底体现在哪里？
也有网友猜测：有可能是为了让摘要能在预留的思维块上运行。
李康旭给出了自己的一个设想：可能是压缩结果的质量更优越，或者他们模型处理交接的压缩结果方式更优越，所以才要加密吧。
但不管如何，不少网友都反馈了对于 Codex 对于上下文压缩机制的创新非常满意，基本上解救了“上下文退化”的问题。
大家对于这个开放式问题，也可以在评论区留下自己的看法。
参考链接：
https://x.com/kangwook_lee/status/2028955292025962534
