bingdada本文深入介绍了 OpenAI Codex App Server 的架构设计与实现原理。从 CLI 到 IDE 扩展，Codex 如何通过统一的 JSON-RPC 协议实现跨平台集成？文章揭示了对话原语、线程管理、双向通信等关键技术细节，为开发者提供将 Codex 能力嵌入自身产品的实践指南。
2026年2月4日，工程团队
OpenAI 的编程代理 Codex 横跨多个界面：网页应用、CLI、IDE 扩展以及全新的 Codex macOS 应用。在底层，它们都由同一个 Codex 引擎驱动——即支撑所有 Codex 体验的代理循环与逻辑。而连接它们的关键纽带，正是 Codex App Server——一个对客户端友好的、双向 JSON-RPC 协议 API。
在这篇文章中，我们将介绍 Codex App Server；分享迄今为止关于如何将 Codex 的能力集成到你的产品中，以帮助用户提升工作流效率的最佳实践。我们会深入探讨 App Server 的架构与协议，以及它如何与不同的 Codex 界面集成。同时，无论你想将 Codex 打造成代码审查员、SRE 代理还是编程助手，我们都会提供利用 Codex 的实用技巧。
在深入架构之前，了解 App Server 的诞生背景会很有帮助。最初，App Server 只是在不同产品间复用 Codex 引擎的一种实用方式，后来逐渐演变成了我们的标准协议。
Codex CLI 最初是一个 TUI（终端用户界面），这意味着用户通过终端访问 Codex。当我们构建 VS Code 扩展（一种更符合 IDE 习惯的与 Codex 代理交互的方式）时，我们需要一种方法来使用相同的引擎，从而在不重新实现的情况下，从 IDE UI 驱动相同的代理循环。这意味着要支持超越简单请求/响应的丰富交互模式，例如浏览工作区、流式传输代理推理过程中的进度，以及生成差异（diffs）。
我们首先尝试将 Codex 作为 MCP 服务器公开，但事实证明，维护对 VS Code 有意义的 MCP 语义非常困难。于是，我们引入了一个镜像 TUI 循环的 JSON-RPC 协议，这成为了 App Server 的非官方第一版。当时，我们并未预料到其他客户端会依赖 App Server，因此它并非作为稳定的 API 来设计。
随着 Codex 在接下来的几个月里被广泛采用，内部团队和外部合作伙伴都希望能够将相同的引擎嵌入到他们自己的产品中，以加速用户的软件开发工作流。例如，JetBrains 和 Xcode 希望获得 IDE 级别的代理体验，而 Codex 桌面应用则需要并行编排多个 Codex 代理。这些需求推动我们设计一个平台界面，使我们的产品和合作伙伴集成都能长期安全地依赖它。它需要易于集成且向后兼容，这意味着我们可以在不破坏现有客户端的情况下演进协议。
接下来，我们将介绍如何设计架构和协议，以便不同的客户端可以使用相同的引擎。
首先，让我们聚焦于 Codex 引擎的内部构造，以及 Codex App Server 如何将其暴露给客户端。在上一篇 Codex 博客中，我们分解了协调用户、模型和工具之间交互的核心代理循环。这是 Codex 引擎的核心逻辑，但完整的代理体验远不止于此：
这里提及的所有代理逻辑，包括核心代理循环，都存在于 Codex CLI 代码库中一个名为“Codex core”的部分。Codex core 既是一个包含所有代理代码的库，也是一个可以启动以运行代理循环并管理单个 Codex 线程（对话）持久化的运行时。
要使其发挥作用，Codex 引擎需要能够被客户端访问。这就是 App Server 的用武之地。
App Server 既是客户端与服务器之间的 JSON-RPC 协议，也是一个长期运行、托管 Codex core 线程的进程。从上图可以看出，一个 App Server 进程包含四个主要组件：stdio 读取器、Codex 消息处理器、线程管理器以及核心线程。线程管理器为每个线程启动一个核心会话，然后 Codex 消息处理器直接与每个核心会话通信，以提交客户端请求并接收更新。
一个客户端请求可能产生多个事件更新，正是这些详细的事件使我们能够在 App Server 之上构建丰富的 UI。此外，stdio 读取器和 Codex 消息处理器充当客户端与 Codex core 线程之间的转换层。它们将客户端的 JSON-RPC 请求转换为 Codex core 操作，监听 Codex core 的内部事件流，然后将这些底层事件转换为一小组稳定的、UI 就绪的 JSON-RPC 通知。
客户端与 App Server 之间的 JSON-RPC 协议是完全双向的。一个典型的线程包含一个客户端请求和多个服务器通知。此外，当代理需要输入（如审批）时，服务器可以发起请求，然后暂停轮次，直到客户端响应。
接下来，我们将分解构成 App Server 协议构建块的对话原语。为代理循环设计 API 颇具挑战性，因为用户/代理交互并非简单的请求/响应。一个用户请求可能会展开为一个结构化的动作序列，客户端需要忠实地呈现这些动作：用户的输入、代理的增量进展、过程中产生的产物（例如差异）。为了使这种交互流易于集成，并在不同 UI 中保持稳健，我们引入了以下对话原语：
通过这些原语，App Server 能够以结构化的方式向客户端传递信息，而客户端则可以根据这些信息构建出丰富的用户界面，无论是进度条、代码差异视图还是对话历史。
Codex App Server 的设计体现了我们对灵活、可扩展代理架构的追求。通过将核心引擎抽象为一个稳定的、双向通信的 JSON-RPC 接口，我们不仅统一了 OpenAI 内部各产品的 Codex 体验，也为外部合作伙伴提供了强大的集成能力。
未来，我们将继续优化 App Server 的性能、安全性和易用性。我们计划引入更细粒度的策略控制、更高效的事件流处理，并探索对更多客户端语言和框架的原生支持。我们相信，通过开放和标准化的协议，Codex 能够成为推动软件工程自动化的核心力量。
如果你对将 Codex 集成到你的产品中感兴趣，或者有任何反馈，欢迎联系我们。让我们一起解锁更强大的编程未来！
SEO & GEO 技术探索者，专注于搜索引擎优化和生成式引擎优化。
OpenAI 宣布启动“OpenAI for Ireland”计划，与爱尔兰政府、Dogpatch Labs 及 Patch 合作，通过 SME Booster 培训、初创企业支持及青年培养项目，助力中小企业与创业者利用AI实现增长与创新。
OpenAI 被 Gartner 评为生成式 AI 新兴领导者，标志着企业级 AI 部署进入新阶段。文章探讨了 OpenAI 在安全、规模化部署方面的进展，以及 ChatGPT 在企业中的爆发式增长，展望了未来 AI 系统的协作与集成趋势。
OpenAI 任命前 Slack CEO Denise Dresser 为首席营收官，负责全球营收战略。她将推动企业 AI 普及，帮助更多企业将 AI 融入日常运营。当前已有超百万企业客户使用 OpenAI 技术。
获取最新的 SEO 与 GEO 技术资讯。
我们尊重您的隐私，随时可以取消订阅。
