OpenAI揭秘Codex智能体循环：单数据库支撑8亿用户

一个PostgreSQL主库和50个只读副本，就支撑了ChatGPT上的8亿用户！OpenAI工程师们不仅揭示了这一惊人事实，还深入剖析了Codex的“大脑”工作原理。

在OpenAI官方工程博客上，工程师Michael Bolin以“揭秘Codex智能体循环”为题，详细介绍了Codex CLI的核心框架：智能体循环（Agent Loop），并讲解了Codex在查询模型时如何构建和管理上下文，以及基于Responses API构建智能体循环的实用注意事项和最佳实践。

这些消息在技术论坛和社交平台上引起了高度关注。“看似平淡的技术最终会胜出。OpenAI正在证明，优秀的架构远胜于花哨的工具。”

值得一提的是，有网友透露，Anthropic的一位工程师曾表示他们用于Claude Code UI的架构糟糕且效率低下。而最近的一条爆料称，Codex已接管OpenAI 100%的代码编写工作。

对于“你们有多少百分比的编码工作是基于OpenAI模型进行”的问题，roon表示，“100%，我不再写代码了。”此前，Sam Altman曾公开表示“roon是我的小号。”

Codex的“大脑”揭秘

“每个人工智能智能体的核心都是Agent Loop，负责协调用户、模型以及工具之间的交互，以执行有意义的软件工作。”

据介绍，在OpenAI内部，“Codex”涵盖了一系列软件智能体产品，包括Codex CLI、Codex Cloud和Codex VS Code插件，而支撑它们的框架和执行逻辑是同一个。

Agent Loop的简化示意图

智能体会从用户那里接收输入，并将其转换为模型可处理的文本指令集。随后通过向模型发送指令并要求其生成响应来查询模型。推理过程中，文本指令首先被转换为输入token，用于对模型进行采样，生成新的输出token序列。输出token会被还原为文本，成为模型的回复。由于token是逐步生成的，还原过程可与模型运行同步进行。实际应用中，推理功能通常封装在文本API后方，从而抽象化词元化细节。

推理步骤完成后，模型会产生两种结果：（1）针对用户的原始输入生成最终回复；（2）要求智能体执行某项工具调用操作。若为第二种情况，智能体将执行工具调用并将结果附加至原始提示词中。这一过程会不断重复，直至模型停止发出工具调用指令，转而生成面向用户的消息。

多轮智能体循环

对话内容越丰富，用于模型采样的提示词长度也会随之增加。所有模型都存在上下文窗口限制，智能体可能在单次对话中发起数百次工具调用，可能耗尽上下文窗口的容量。因此，上下文窗口管理是智能体的多项职责之一。

这套智能体循环如何运行？

据介绍，Codex正是借助响应API来驱动这套智能体循环的。博文曝出许多背后的实际运行细节，包括：

• Codex不会直接把用户的话给大模型用，而是会主动“拼接”出一整套精心设计的提示词结构。
• 模型推理与工具调用之间可能会进行多轮迭代，提示词的内容会持续增加。

构建初始提示词

作为终端用户，在调用响应API时无需逐字指定提示词，只需在查询中指定输入类型。响应API服务器会决定如何组织这些信息为模型可处理的格式。初始提示词中每个条目均关联一个角色，决定对应内容的权重占比。

响应API接收包含多个参数的JSON负载，其中三个核心参数有：指令、工具和输入。

模型采样

提示词准备就绪后，模型才开始进行采样。

第一轮交互：向响应API发起的HTTP请求将启动Codex中的第一轮交互。服务器以SSE流的形式响应，每个事件的数据均为一个JSON负载。Codex接收事件流并将其重新发布为内部事件对象。若首次请求返回两个response.output_item.done事件，则这些事件必须在后续查询的输入字段中体现。

弃用简单参数费力做优化，就为了用户隐私？

“在对话过程中，发送至响应API的JSON数据量是否会让智能体循环的时间复杂度达到二次方级别？”答案是肯定的。

尽管响应API支持通过可选的previous_response_id参数缓解这一问题，但目前Codex并未启用该参数，主要是为了保证请求完全无状态并兼容零数据保留（ZDR）配置。

取而代之的是两套需投入大量研发精力、涉及复杂实施流程的技术策略。文中详细介绍了这两项硬核优化的具体方案。

极限扩容：用1个数据库，扛住了8亿用户

在另一篇技术博文中，OpenAI工程师Bohan Zhang介绍，通过严苛的技术优化与扎实的工程实践，对单个数据库PostgreSQL进行深度扩容，实现以单套体系支撑8亿用户、每秒数百万次查询的访问需求。

据称，多年来PostgreSQL一直是支撑ChatGPT、OpenAI API等核心产品的核心底层数据系统之一。过去一年公司PostgreSQL的负载增长超10倍且仍在加速。OpenAI称PostgreSQL的横向扩展能力远超此前行业普遍认知。

“这套最初由加州大学伯克利分校的科学家团队研发的系统助力我们通过单主节点Azure PostgreSQL弹性服务器实例搭配分布在全球多个区域的近50个只读副本承接了海量的全球访问流量。”

“而且我们始终将延迟控制与可靠性优化放在核心位置：生产环境中客户端99分位延迟稳定保持在十几毫秒的低水平服务可用性达到五个九标准；过去12个月内PostgreSQL仅出现过一次零级严重故障。”

“尽管扩容成果已达预期我们仍在持续探索其性能极限。目前我们已将可分片的写密集型业务负载迁移至CosmosDB等分片式数据库系统；对于分片难度更高的剩余写密集型负载相关迁移工作也在积极推进以此进一步减轻PostgreSQL主节点的写压力。”