新智元报道
编辑：定慧元宇
AI 编程霸主之争升级！Claude Code 刚刷屏，OpenAI 连甩两张王：不仅首度揭秘 Codex 背后的大脑「Agent Loop」，还自曝惊人基建：仅用 1 个 PostgreSQL 主库，竟抗住了全球 8 亿用户洪峰！
最近，Anthropic 的 Claude Code 引爆了 AI 编程圈！
那个能在终端里自己读代码、改代码、跑测试的 AI 助手，让不少开发者直呼「这才是未来」。
一时间，社交媒体上全是「Claude Code 吊打 Cursor、Codex、Antigravity」之类的评论。
就在大家以为 OpenAI 还在憋 GPT-5.3 大招的时候，今天其官博和奥特曼突然在X平台甩出了两张王炸：
1. Agent Loop 架构揭秘：首次公开 Codex 的「大脑」是怎么运转的
2. PostgreSQL 极限架构：1 个主库扛起 8 亿用户的疯狂操作
这一波组合拳打得太漂亮了。
今天咱们就来拆解一下，OpenAI 到底憋了什么大招。
Agent Loop
Codex 的「大脑 」 是怎么运转的
什么是 Agent Loop？
如果你用过 Codex CLI、Claude Code 等等 CLI 终端工具，你可能会好奇：
这玩意儿到底是怎么知道我想干啥的？怎么就能自己读文件、写代码、跑命令？
答案就藏在一个叫Agent Loop（智能体循环）的东西里。
简单来说，Agent Loop 就像一个「总指挥」，它负责把「用户意图」「模型大脑」和「执行工具」串成一个完美的闭环。
这不是普通的「你问我答」，而是一个包含了「观察-思考-行动-反馈」的能干活的系统。
下面，把这个黑盒拆开，看看一个真正的 AI Agent 是如何跑起来的。
一个完整的 Agent Loop 是怎么跑起来的
用一个具体的例子来说明。
假设在终端里输入：给项目的 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 真的是要把活儿给干了。
1 个主库扛 8 亿用户
PostgreSQL 的极限操作
在大家都在聊 AI 模型有多牛的时候，OpenAI 悄悄曝光了一个更劲爆的消息：
支撑全球 8 亿 ChatGPT 用户、每秒处理数百万次查询的，竟然只是一个单一主节点的 PostgreSQL 数据库！
它只用 1 个 PostgreSQL 主节点 +50 个只读副本就做到了。
8 亿用户，这简直是在开玩笑！有网友惊叹。
在分布式架构盛行的今天，大家动不动就是「微服务」「分片」「NoSQL」。
能用巨型分布式集群解决的问题，绝不用单机。
结果 OpenAI 告诉你：我们就用个 PostgreSQL，照样扛。
他们是怎么做到的？
根据 OpenAI 工程师披露的信息，关键技术包括：
1. PgBouncer 连接池代理 ：大幅减少数据库连接开销
2. 缓存锁定机制 ：避免缓存穿透导致的写入压力
3. 跨地域级联复制 ：读请求分散到全球各地的副本
这套架构的核心思想是：读写分离，极致优化读路径。
毕竟对于 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 用实践证明：一个优化到极致的单机架构，能走得比你想象的更远。
Codex VS Claude Code 的争霸赛
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 继续创新。
最终受益的，是我们这些开发者。
参考资料：
