OpenAI最近发表了一系列文章中的第一篇，这些文章详细介绍了他们的Codex软件开发代理的设计与功能。点击这篇文章即可阅读更多内容。这篇开篇文章重点讲解了Codex框架的内部结构，而Codex框架是Codex命令行界面的核心组成部分。
与所有人工智能代理一样，Codex框架也是一个循环系统：该系统会接收用户的输入，然后利用大语言模型生成相应的工具调用指令或反馈信息发送给用户。但由于大语言模型的局限性，这个循环系统还包含一些用于管理上下文信息以及减少提示信息缓存未命中情况的策略。其中一些策略其实是根据用户报告的错误问题总结出来的。由于Codex命令行界面使用了Open Responses API，因此它并不局限于使用某种特定的大语言模型；只要该模型能够通过这个API进行调用，无论是本地部署的开源模型还是其他模型，都可以被Codex命令行界面所使用。根据OpenAI的说法，他们的这种设计思路和经验教训，对于任何基于这个API开发人工智能代理的人来说都具有参考价值。
我们重点介绍了一些实用性的考虑因素及最佳实践，这些内容适用于任何基于Open Responses API构建人工智能代理循环系统的人。虽然人工智能代理循环系统为Codex的基础架构提供了支持，但这仅仅是一个开始。在后续的文章中，我们将深入探讨Codex命令行界面的架构原理，分析工具使用功能的实现机制，并仔细研究Codex的沙箱测试模型。
这篇文章描述了用户与人工智能代理进行对话时一个完整“轮次”中的具体流程。每个对话轮次首先会为大语言模型生成一条初始提示信息。这条提示信息包括指令——即一些系统规定的规则，比如编码规范；工具列表——人工智能代理可以调用的各种工具；以及输入数据——包括文本、图片和文件等内容。所有这些信息会被打包成一个JSON对象，然后发送给Open Responses API。
接收到这个请求后，大语言模型会开始进行推理计算，并生成一系列输出结果。其中一些结果会提示人工智能代理应该调用特定的工具；在这种情况下，代理就会使用指定的输入参数来调用相应的工具，并收集其输出结果。另外一些结果则代表大语言模型的推理结果，这些结果通常是一些具体的操作步骤。无论是工具调用还是推理结果，都会被添加到最初的提示信息中，然后再重新发送给大语言模型进行进一步的处理。这样的循环过程被称为“内部循环”的一个轮次。当大语言模型通过发送完成信号来表示内部循环已经结束时，整个对话轮次也就结束了，此时系统会向用户返回相应的回复信息。
在这个设计方案中，一个主要的挑战在于大语言模型的推理性能。由于在整个对话过程中需要向Open Responses API发送大量的JSON数据，因此其推理效率与发送的数据量呈二次方关系。正因为如此，提示信息缓存技术就显得尤为重要：通过重用之前推理计算的结果，可以显著提升推理效率，使其从二次方关系变为线性关系。不过，如果修改工具列表等配置，就会导致缓存失效。此外，Codex命令行界面在最初支持MCP功能时存在一个错误，导致工具列表的排序顺序不一致，进而引发了缓存未命中的问题。
Codex CLI同样使用了压缩技术来减少大语言模型上下文中的文本量。一旦对话的长度超过了预设的字符数上限，系统就会调用一个专门的响应API端点，该端点会提供对话内容的简化版本，从而替代原有的输入内容。
Hacker News上的用户们正在讨论这篇文章，他们称赞OpenAI决定将Codex CLI开源，同时也指出了Claude Code并未被开源这一事实。其中有一位用户这样写道：
我记得他们曾经宣布过Codex CLI是开源的……这一决定意义重大，对于任何想要了解编码式智能体工作原理的人来说都非常有用，尤其是像OpenAI这样的知名机构发布的开源项目。不久前我也为他们的CLI贡献了一些改进方案，并且一直在关注他们的更新内容以及Pull Request，以此来扩展自己的知识面。