OpenAI最近发表了系列文章的第一篇，详细介绍了他们的Codex软件开发智能体的设计和功能。首篇文章重点介绍了 Codex 框架的内部结构，这是Codex CLI的核心组件。
与所有 AI 智能体一样，框架由一个循环组成，该循环从用户那里获取输入，并使用大语言模型（LLM）生成工具调用或回应用户。但由于 LLM 的限制，循环还具有管理上下文和减少提示缓存未命中的策略。其中一些策略是从用户报告的错误中学到的教训。因为 CLI 使用Open Responses API，所以它是与 LLM 无关的：它可以使用任何被这个 API 包装的模型，包括本地托管的开放模型。根据 OpenAI 的说法，他们的 CLI 设计和经验教训因此可以惠及任何基于这个 API 设计智能体的人：
我们强调了任何适用于在 Responses API 之上构建代理循环的实际考虑和最佳实践。虽然代理循环为 Codex 提供了基础，但这只是一个开始。在即将发布的文章中，我们将深入探讨 CLI 的架构，探索工具使用是如何实现的，并对 Codex 的沙箱模型进行更仔细的观察。
文章描述了用户与智能体对话中的一轮或一次交流中发生的事情。这一轮交流始于为 LLM 组装一个初始提示。这包括指令，这是一个包含智能体通用规则的系统消息，例如编码标准；工具，一个智能体可以调用的 MCP 服务器列表；以及输入，这是一个包含文本、图像和文件输入的列表，包括 AGENTS.md、本地环境信息和用户的输入消息等。所有这些都被打包成一个 JSON 对象发送到 Responses API。
这触发了 LLM 推理，从而产生一系列的输出事件。其中一些事件可能表明智能体应该调用其中一个工具；在这种情况下，智能体使用指定的输入调用工具并收集输出。其他事件表明 LLM 的推理输出，通常是计划中的步骤。工具调用和推理都被追加到初始提示中，然后再次传递给 LLM 进行更多的推理或工具调用迭代。这就是所谓的“内”循环。当 LLM 用 done 事件响应内部循环时，会话轮次结束，其中包括给用户的响应消息。
在这种模式中，一个主要的挑战是 LLM 推理的性能：它是“与发送到 Responses API 的 JSON 数量成二次方关系的”。这就是为什么提示缓存是关键：通过重用先前推理调用的输出，推理性能变成线性而不是二次方。改变工具列表等事物将使缓存失效，Codex CLI 最初对 MCP 的支持有一个错误，即“未能以一致的顺序枚举工具”，这导致了缓存未命中。
Codex CLI 还使用压缩来减少 LLM 上下文中的文本量。一旦对话长度超过某个设定的 token 数量，智能体将调用一个特殊的 Responses API 端点，该端点提供了一个更小的会话表示，替换了之前的输入。
Hacker News 用户讨论这篇文章时，赞扬了 OpenAI 开源 Codex CLI 的决定，并指出 Claude Code 是封闭的。一位用户写道：
我记得他们宣布 Codex CLI 是开源的……这对于任何想要了解编码智能体如何工作的人来说都是一件大事，非常有用，尤其是来自像 OpenAI 这样的主要实验室。我还在一段时间前为他们的 CLI 贡献了一些改进，并一直在关注他们的发布和 PR，以扩大我的知识。
Codex CLI 的源代码、缺陷跟踪和修复历史可以在 GitHub 上找到。
原文链接：
