OpenAI 最近发布了Codex应用服务器的详细架构描述，这是一个双向协议，它将 Codex 编码智能体的核心逻辑与其各种客户端界面解耦。应用服务器现在支持每一个 Codex 体验，包括命令行界面（CLI）、VS Code 扩展、Web 应用、macOS 桌面应用，以及来自 JetBrains 和苹果 Xcode 的第三方 IDE 集成，通过一个单一、稳定的 API 实现。
这篇文章由 OpenAI 工程师Celia Chen撰写，是一系列详细介绍开源 Codex CLI 内部结构的文章之一。正如 Chen 所描述的，智能体交互与简单的请求/响应交换有着根本的不同：
一个用户请求可以展开成一个结构化的动作序列，客户端需要忠实地表示：用户的输入、智能体的增量进度、沿途产生的工件。
Codex 应用服务器的内部架构：标准输入输出（stdio）读取器和 Codex 消息处理器将客户端的 JSON-RPC 请求转换为 Codex 核心操作，并将内部事件转换回稳定的、UI 就绪的通知（来源）。
为了对此进行建模，OpenAI 设计了三个对话原语。项（Item）是输入或输出的原子单位，具有明确的生命周期：“开始”（started）、可选的流式“增量”（delta）事件和“完成”（completed）。这可以是用户消息、智能体消息、工具执行、审批请求或差异。轮次（Turn）将由单个智能体工作单元产生的项序列分组，由用户输入启动。一个线程（Thread）是正在进行的会话的持久容器，支持创建、恢复、分叉和存档，并保留事件历史记录，以便客户端可以在不丢失状态的情况下重新连接。
该协议还支持服务器发起的请求。当智能体在执行命令之前需要批准时，服务器会向客户端发送请求，并暂停轮次，直到收到“允许”或“拒绝”的响应。通信使用JSON-RPC作为 JSONL 流式传输在stdio上，OpenAI 将其设计为向后兼容，以便旧版客户端可以安全地与新版服务器通信。
值得注意的是，OpenAI 在最终确定这个设计之前尝试并拒绝了模型上下文协议（MCP）。Chen 解释说，在构建 VS Code 扩展时，团队最初尝试将 Codex 作为MCP服务器公开，但“在 VS Code 中维护 MCP 语义以使其有意义被证明是困难的。”IDE 交互所需的更丰富的会话语义，如流式差异、审批流程和线程持久性，并没有干净地映射到 MCP 的工具导向模型上。OpenAI 仍然支持将Codex作为 MCP 服务器运行以适应更简单的工作流程，但建议使用应用服务器来实现全保真集成。
带有可选批准的工具执行的协议消息流。服务器暂停轮次并向客户端发送请求，客户端必须在智能体可以继续之前用“允许”或“拒绝”响应（来源）。
文章描述了客户端用于嵌入应用服务器的三种部署模式。像 VS Code 扩展和桌面应用这样的本地客户端捆绑一个特定于平台的二进制文件，将其作为子进程启动，并保持一个双向的标准输入输出通道开放。像 Xcode 这样的合作伙伴通过保持客户端稳定而指向更新的应用服务器二进制文件来解耦发布周期，允许他们采用服务器端改进而无需等待客户端发布。
Codex Web运行时采取了不同的方法：一个工作器配置一个容器，在其中启动应用服务器，浏览器通过 HTTP 和服务器发送事件进行通信——保持浏览器端 UI 轻量级。同时，对于长时间运行的任务，服务器仍然是数据源。
应用服务器的演变与更广泛的行业努力以标准化代理-编辑器通信相平行。由 Zed Industries 发起现在由JetBrains支持的智能体客户端协议（Agent Client Protocol，ACP）采取了互补的方法：OpenAI 的应用服务器是特定于 Codex 框架的协议，而 ACP 旨在成为连接任何编码智能体到任何编辑器的通用标准，直接类比于十年前通过语言服务器协议（Language Server Protocol ）标准化语言工具的方式。Codex CLI 本身也被列为 ACP 兼容智能体之一。这些方法的共存反映了行业仍然在为智能体集成确定正确的抽象边界——一个 OpenAI 承认正在“快速演变”的空间。
Codex 应用服务器的所有源代码都可以在开源Codex CLI存储库中找到，协议文档包括用于 TypeScript 和 JSON Schema 的模式生成工具，以方便使用任何语言进行客户端绑定。
原文链接：
