当人们提起 "Codex" 时，他们指的并不总是同一件事。有时指的是模型，有时指的是应用，有时指的是代理。
不言而喻，这可能会让人困惑。
简而言之，Codex 是 OpenAI 的软件工程代理，可以通过多种界面访问。代理是模型加上指令和工具的组合，包装在一个可以代表你执行任务的运行时中。
大多数开发者不需要去理解底层细节。选择适合你工作流的界面，通过快速入门开始构建——如果你是代理编程的新手，独立运行的 Codex 应用是最简单的入口点。
但如果你正在为团队评估 Codex——或者试图理解在线讨论、文档和频繁发布的版本——这些区别就很关键。"Codex" 可以指系统的不同层面。
这篇文章面向开发者，分享我个人的（非常非官方的）心智模型，用来理解新功能发布时究竟发生了什么变化。
我的心智模型：Codex = 模型 + 工具链 + 界面
从高层次来看，我认为 Codex 由三个部分组成：
Codex = 模型 + 工具链 + 界面
其中：
- 模型提供智能。
- 工具链（即指令和工具的集合）将智能转化为可以在真实开发环境中安全运行的东西。
- 界面是运行代理的运行时和接口。
更具体地说：
- 模型 + 工具链 = 代理
- 界面 = 你与代理交互的方式
一旦你区分开这些层面，其余的就更容易理解了。
模型：为软件工程优化的智能
Codex 的核心是专门为软件工程优化的大型语言模型（LLM）。
从基本层面来说，LLM 预测下一个 token，而代码就是文本。但推理变体远不止自动补全。在生成答案之前，模型可以进行结构化的内部推理：分解任务、评估选项、规划多步编辑。这就是为什么 Codex 不会总是立即响应——它正在推理。
附注：你可能会注意到模型名称后面有时会附带 high 或 xhigh 这样的术语。这是 reasoning_effort 参数，一个可配置的 dial，用来控制模型进行多少推理。较高的推理努力通常以延迟为代价，换取更强的规划和复杂任务上更好的结果。
但真正的软件工程不仅仅是生成代码行。它涉及：
- 阅读和理解代码仓库
- 制定多步计划
- 跨多个文件编辑
- 运行工具并解释输出
- 响应失败
- 迭代直到实际工作
目前 OpenAI 的旗舰模型是：
- GPT-5.3-Codex — 为复杂的、长时间运行的代理编程任务设计
- GPT-5.3-Codex-Spark — 一个更小、更快的变体，专为实时编码交互优化
这些相同的模型可以为其他编码体验提供动力，取决于产品和集成选择。例如，你可以在 Cursor 或 GitHub Copilot 等工具中使用它们。你可以通过 ChatGPT 计划在 OpenCode 等工具中访问它们。它们也可以通过 Responses API 获得，尽管 API 发布可能会落后于第一方界面以确保安全部署。
关键点是：模型就是智能。但仅有智能并不能成为代理。
工具链：什么把模型变成代理
模型可以生成代码、建议编辑、推理 diff。但它无法自行在真实仓库中操作。它无法检查文件系统、运行测试、执行构建或调用工程师每天依赖的工具。
这就是工具链的作用。
工具链是将模型连接到工作软件环境的系统。它提供对文件和仓库的受控访问、安全运行命令的能力，以及将信息传入传出模型的结构化方式，这样它才能承担更大的任务而不会在上下文中崩溃。工具链让模型能够获取额外上下文并使用工具完成工作——例如通过 MCP 服务器或技能。
从实际来说，工具链使代理能够读取、规划、执行、验证并迭代直到获得工作结果。
没有工具链，你得到的只是建议。
有了工具链，你得到的是执行。
值得注意的是，Codex 工具链是开源的。你可以检查它如何工作，理解执行是如何结构的。例如，对于长时间运行的任务，系统使用压缩。它不是传递不断增长的对话历史，而是将之前的上下文压缩成保留继续状态所需的摘要。目标是保持连续性而不使上下文膨胀。
如果你想了解更多关于 Codex 工具链的知识，可以参考我们的工程博客文章。
为工具链训练的模型
模型和工具链不是后来才组装在一起的——它们是协同设计的。
Codex 模型在工具链的存在下进行训练。工具使用、执行循环、压缩和迭代验证不是被附加上去的行为——它们是模型学习操作方式的一部分。反过来，工具链围绕模型如何规划、调用工具和从失败中恢复而塑造。
想想运动员和他们的球拍。专业人士会使用特定设备训练多年。你不会在比赛前一天换掉它而期望获得相同的表现。
Codex 的行为来自这种配对。改变一个，就会改变代理。
界面：你如何让代理工作
一旦你有了模型和工具链，你就有了代理。剩下的问题是你想如何使用它。这就是产品界面发挥作用的地方。
你可以根据任务以不同方式使用 Codex 代理。有时你想并行监督多个长时间运行的线程。有时你想要紧密的编辑器内迭代。有时你想要终端原生的可组合性。有时你想要一个轻量级入口点用于远程或异步工作。
Codex 存在于多个界面上，因为软件开发生命周期的不同阶段需要不同的交互模式。
在底层，这些体验中的许多都由 Codex 应用服务器驱动。应用服务器管理身份验证、对话历史、审批和流式代理事件，使富客户端——如 IDE 扩展或嵌入式集成——能够与相同的底层代理系统交互。这使得将 Codex 嵌入其他产品成为可能，同时保持一致的执行模型。应用服务器也是开源的，所以团队可以直接检查它或在其上构建。你可以在这篇文章中了解更多关于应用服务器的信息。
Codex 也被设计出现在协作工作流中。在 GitHub 中，你可以用它进行代码审查，并在 PR 中触发异步 Web 任务。在 Slack 或 Linear 等工具中，它可以在团队规划和协调工作的地方运行，触发任务并将执行连接回共享的规划系统。
展望
总之，从模型、工具链和产品界面的角度思考 Codex 帮助我理解新功能发布时实际发生了什么。
也就是说，随着时间的推移，这些区别在日常使用中应该变得不那么重要。你只需在任务需要的地方使用 Codex，它应该感觉像一个统一的工具包——一致的行为、一致的安全边界、一致的期望——无论你在哪里调用它。
如果你是代理编程的新手，最佳的下一步不是去理解架构。而是尝试一个端到端的真实任务。选择一个界面（Codex 应用通常是最简单的起点），看看它在你关心的任务上表现如何。
一个历史注记作为结尾："Codex" 最初指的是驱动第一个版本 GitHub Copilot 的模型。今天的 Codex 模型和产品线是一个独立的系统——不同的架构、不同的工具链、不同的代理设计——但名称保留了下来。底层理念始终如一：帮助开发者更快地用 AI 构建。现在，Codex 不仅仅协助编写代码行，它可以帮助你交付完整的工作——而你只需要构建东西。