OpenAI绝地反击！Codex大脑首曝，8亿用户极限架构硬刚Claude

推荐语

OpenAI重磅揭秘Codex大脑架构，仅用1个PostgreSQL主库就扛住8亿用户洪流！

核心内容：
1. Agent Loop架构详解：Codex如何实现"观察-思考-行动-反馈"闭环
2. PostgreSQL极限优化：单主库支撑全球8亿用户的技术内幕
3. 与Claude Code的架构对比及未来AI编程助手发展趋势

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

最近，Anthropic的Claude Code引爆了AI编程圈！

那个能在终端里自己读代码、改代码、跑测试的AI助手，让不少开发者直呼「这才是未来」。

一时间，社交媒体上全是「Claude Code吊打Cursor、Codex、Antigravity」之类的评论。

就在大家以为OpenAI还在憋GPT-5.3大招的时候，今天其官博和奥特曼突然在X平台甩出了两张王炸：

1. Agent Loop架构揭秘：首次公开Codex的「大脑」是怎么运转的

2. PostgreSQL极限架构：1个主库扛起8亿用户的疯狂操作

这一波组合拳打得太漂亮了。

今天咱们就来拆解一下，OpenAI到底憋了什么大招。

如果你用过Codex CLI、Claude Code等等CLI终端工具，你可能会好奇：

这玩意儿到底是怎么知道我想干啥的？怎么就能自己读文件、写代码、跑命令？

答案就藏在一个叫Agent Loop（智能体循环）的东西里。

简单来说，Agent Loop就像一个「总指挥」，它负责把「用户意图」「模型大脑」和「执行工具」串成一个完美的闭环。

这不是普通的「你问我答」，而是一个包含了「观察-思考-行动-反馈」的能干活的系统。

下面，把这个黑盒拆开，看看一个真正的AI Agent是如何跑起来的。

用一个具体的例子来说明。

假设在终端里输入：给项目的README.md加一个架构图。

第一步：构建Prompt

这好比给大脑发工单。

Codex不会直接把你的话丢给模型，它会先构建一个精心设计的「Prompt」：

• 我是谁：（System）：告诉模型它是谁、能干什么

• 我有什么工具（Tools）：有哪些工具可以调用（比如shell命令、文件操作）

• 环境上下文（Context）：当前在哪个目录、用的什么shell

• 用户指令：给README.md加一个架构图。

这就像给模型发一封详细的工作邮件，而不是只发一句「帮我干活」。

第二步：模型推理（Inference）

这一步，大脑开始转动。

Codex把这个Prompt发给ResponsesAPI，模型开始思考：

「用户想加架构图，我得先看看现在的README是什么样的……」

然后模型做出决定：调用shell工具，执行catREADME.md。

第三步：工具调用（ToolCall）

Codex收到模型的请求，在本地执行命令，把README.md的内容读出来。

这就像手脚开始动起来。

第四步：结果反馈

这一步，终端把README.md的内容吐了出来。

这时候流程没有结束。Codex把命令的输出追加到Prompt里，再发给模型。

第五步：循环

模型看到了README的内容，再次进行推理：

可能是生成一个Mermaid图，可能是直接写一段ASCII图形……然后再调用工具写入文件。

这个循环一直持续，直到模型认为任务完成了，输出一条「我搞定了」的消息。

它不是在回答问题，它是在解决问题。

为什么这很重要？

也许你可能会说：「这不就是多调了几次API吗？」

但绝非这么简单。

传统的LLM应用是「一问一答」式的：你问，它答，完事儿。

但Agent Loop让AI变成了一个能独立干活的员工。

• 它会自己规划路径（Chain of Thought）。

• 它会自己检查错误（Self-Correction）。

• 它会自己验证结果（Feedback Loop）。

这才是真正的「AI Agent」。

而Agent Loop，就是那个可以让AI实现从「陪伴聊天」迈向「独立干活」飞跃的桥梁。

OpenAI在文章里分享了两个硬核优化，解决了Agent开发的两大痛点：

痛点一：成本爆炸

Agent Loop每跑一圈，都要把之前的对话历史（包括那些冗长的报错信息、文件内容）重新发给模型。

对话越长，成本越高。如果不优化，成本是平方级增长的。

解决方案：PromptCaching（提示词缓存）

OpenAI采用了一种类似于「前缀匹配」的缓存策略。

简单来说，只要你发给模型的前半部分内容（System指令、工具定义、历史对话）没变，服务器就不需要重新计算，直接调取缓存。

这一招，直接让长对话的成本从平方级增长降到了线性级。

但这里有个坑：任何改变Prompt前缀的操作都会导致缓存失效。比如：

• 中途换模型

• 修改权限配置

• 改变MCP工具列表

OpenAI团队甚至在文章里承认，他们早期的MCP工具集成有bug：工具列表的顺序不稳定，导致缓存频繁失效。

痛点二：上下文窗口有限

再大的模型，上下文窗口也是有限的。

如果Agent读了一个巨大的日志文件，上下文瞬间就满了，前面的记忆就会被挤掉。

对于程序员来说，这就意味着：「你把前面我定义的函数给忘了？！」

这不仅是智障，更是灾难。

解决方案：Compaction（对话压缩）

当Token数超过阈值，Codex不会简单地「删除旧消息」，而是会调用一个特殊的/responses/compact接口，把对话历史「压缩」成一个更短的摘要。

普通的总结（Summary）只是把长文本变成短文本，会丢失大量细节。

OpenAI的Compaction返回的是一段encrypted_content（加密内容），保留了模型对原始对话的「隐性理解」。

这就像把一本厚书压缩成一个「记忆卡片」，模型读了卡片就能回忆起整本书的内容。

这让Agent在处理超长任务时，依然能保持「智商」在线。

这一次，OpenAI硬核揭秘Codex CLI背后的「大脑」「Agent Loop」，释放出一个信号：AI真的是要把活儿给干了。

在大家都在聊AI模型有多牛的时候，OpenAI悄悄曝光了一个更劲爆的消息：

支撑全球8亿ChatGPT用户、每秒处理数百万次查询的，竟然只是一个单一主节点的PostgreSQL数据库！

它只用1个PostgreSQL主节点+50个只读副本就做到了。

8亿用户，这简直是在开玩笑！有网友惊叹。

在分布式架构盛行的今天，大家动不动就是「微服务」「分片」「NoSQL」。

能用巨型分布式集群解决的问题，绝不用单机。

结果OpenAI告诉你：我们就用个PostgreSQL，照样扛。

他们是怎么做到的？

根据OpenAI工程师披露的信息，关键技术包括：

这套架构的核心思想是：读写分离，极致优化读路径。

毕竟对于ChatGPT这种应用，读请求远远多于写请求。用户发条消息，系统可能需要读几十次数据（用户信息、对话历史、配置信息……），但写入只有一次。

根据OpenAI官方博客披露，关键技术包括：

1.连接池代理（PgBouncer）

通过连接池管理，把平均连接建立时间从50ms降到了5ms。

别小看这45ms，在每秒百万级查询的场景下，这是巨大的性能提升。

2.缓存锁定/租约机制（CacheLocking/Leasing）

这是一个非常聪明的设计。

当缓存未命中时，只允许一个请求去数据库查询并回填缓存，其他请求等待。

这避免了「缓存雪崩」——大量请求同时涌向数据库的灾难场景。

3.查询优化与负载隔离

团队发现并修复了一个涉及12张表连接的复杂查询。

他们把复杂逻辑移到应用层处理，避免在数据库里做OLTP反模式操作。

同时，请求被分为高优先级和低优先级，分别由专用实例处理，防止「吵闹邻居」效应导致的性能下降。

4.高可用与故障转移

主库运行在高可用（HA）模式，配有热备节点。

读流量全部分流到副本，即使主库宕机，服务仍能保持只读可用，降低故障影响级别。

不过，OpenAI也坦言，这套架构已经碰到了物理极限。问题出在两个地方：

PostgreSQL的MVCC限制

PostgreSQL的多版本并发控制（MVCC）机制会导致写放大（更新一行需要复制整行）和读放大（扫描时需要跳过死元组）。对于写密集型负载，这是个硬伤。

WAL复制压力

随着副本数量增加，主库需要向所有副本推送预写日志（WAL）。副本越多，主库的网络压力越大，副本延迟也越高。

为了突破这些限制，OpenAI正在做两件事：

1. 把可分片的、高写入负载迁移到AzureCosmosDB等分布式系统；

2. 测试级联复制：让中间副本向下游副本转发WAL，目标是支持超过100个副本。

这个案例完美诠释了一个架构哲学：如无必要，勿增实体。

不要一上来就搞分布式：先用简单的方案撑住，撑不住了再说。

很多公司的问题是：还没到需要分布式的阶段，就已经把架构搞得无比复杂了。结果既没有分布式的好处，还背上了分布式的复杂度。

OpenAI用实践证明：一个优化到极致的单机架构，能走得比你想象的更远。

Claude Code的杀手锏是什么？是端到端的开发体验。

它不是一个简单的代码补全工具，而是一个能在终端里独立干活的Agent。

它能读代码、改代码、跑测试、处理Git、甚至自己修Bug。现在甚至还能写文档，做PPT。

这直接威胁到了Codex CLI的地位。

OpenAI这波更新，其实是在说三件事：

第一，我的Agent架构更成熟。

Agent Loop的公开，展示了OpenAI在Agent架构上的深厚积累。这不是一个临时拼凑的产品，而是经过精心设计的系统。

Prompt Caching、Compaction、MCP工具集成……这些都是实打实的工程能力。

第二，我的基础设施更强。

PostgreSQL的案例，展示的是OpenAI的后端能力。8亿用户的规模，不是随便一个创业公司能玩转的。

这也是在暗示：我们的「护城河」不只是模型，还有整个工程体系。

第三，我的模型在变得更强大。

网络安全评级的公开，一方面是在做「预期管理」，告诉大家模型有风险，我们在负责任地处理。

另一方面，这也是在秀肌肉：我们的模型已经强大到需要专门评估网络安全风险了。

这场AI编程工具的竞争才刚刚开始。

Claude Code逼迫OpenAI加快了Codex的迭代速度。OpenAI的回应，又会倒逼Anthropic继续创新。

最终受益的，是我们这些开发者。