新智元报道
编辑：定慧 元宇
【新智元导读】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等终端工具，可能会想知道：
它们究竟是怎么知道我想做什么的？怎么能够自己读取文件、编写代码、执行命令呢？
答案就藏在一个叫Agent Loop（智能体循环）的机制中。
简单来说，Agent Loop就像是一个指挥官，负责把「用户的意图」「模型的思维」和「执行工具」紧密联系起来，形成一个完美的闭环。
这不仅仅是「你问我答」，而是一个包含「观察-思考-行动-反馈」的高效工作系统。
接下来，让我们拆解一下，看看一个真正的AI Agent是如何运行的。
完整的Agent Loop是如何运作的
让我们通过一个具体的例子来演示一下。
假设你在终端输入：给项目的README.md添加架构图。
第一步：构建Prompt
这就像是给大脑发出一份工作指令。
Codex不会直接把你说的话传给模型，而是会先精心构建一个「Prompt」：
这就像给模型写一封详细的工作邮件，而不只是简单地说「帮我工作」。
第二步：模型推理（Inference）
在这一阶段，大脑开始运转。
Codex将这个Prompt发送给ResponsesAPI，模型开始思考：
「用户想要添加架构图，我得先看看现在的README内容……」
然后模型决定：调用shell工具，执行cat README.md。
第三步：工具调用（ToolCall）
Codex接到模型的请求后，开始在本地执行命令，读取README.md的内容。
这就像是身体开始行动起来。
第四步：结果反馈
这一阶段，终端将README.md的内容反馈出来。
但流程并没有结束。Codex会把命令的输出添加到Prompt中，然后再发回模型。
第五步：循环
模型看到README的内容后，再次进行推理：
可能生成一个Mermaid图，或者直接绘制一段ASCII图形……然后再调用工具将其写入文件。
这个循环会持续进行，直到模型判断任务完成，并反馈一条「我搞定了」的消息。
它不是在回答问题，而是在解决问题。
为什么这很重要呢？
你可能会问：「这不就是多次调用了API吗？」
AI的进化：从问答到独立工作的小助手
其实，这事儿可没那么简单呢。
传统的LLM应用就像是「问问题、给答案」的简单互动：你提问，它回应，问题就算解决了。
然而，Agent Loop的出现，把AI变成了一个能自我完成任务的员工。
这才是真正意义上的AI代理。
而Agent Loop正是那座重要的桥梁，让AI从「陪你聊天」一步跨越到「独立完成工作」。
性能优化
两个重要技术
OpenAI在文章中提到两项厉害的优化措施，解决了Agent开发中的两大难题：
难题一：成本过高
每次Agent Loop运行时，都需要把之前的对话记录（包括那些冗长的错误信息和文件内容）再次发送给模型。
想想，谈话越长，花费就越大。如果不做优化，成本会呈平方级别飙升。
解决办法：PromptCaching（提示词缓存）
OpenAI采用了一种类似于「前缀匹配」的缓存策略。
简单来说，只要你给模型发送的前半部分内容（系统指令、工具定义、历史对话）没有变化，服务器就无需重新计算，直接调用缓存就行了。
这一策略让长对话的成本，从平方级别暴跌到线性级别。
不过这里有个小陷阱：只要改变Prompt前缀，缓存就会失效。比如：
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）
架构优化与开发工具的未来
通过连接池的管理，平均连接建立的时间从50毫秒降到了5毫秒，这可不是小数目哦！
想象一下，在每秒要处理上百万次查询的情况下，这样的提升真是相当可观。
2. 缓存锁定/租约机制（Cache Locking/Leasing）
这个设计真是非常聪明呢。
当缓存没有命中时，系统会限制只有一个请求去数据库查询并更新缓存，其它请求只能乖乖等着。
这样一来，就有效避免了「缓存雪崩」这种糟糕的情况——也就是大量请求同时冲向数据库的惨状。
3. 查询优化与负载隔离
团队发现并解决了一个涉及12张表的复杂查询问题。
他们把繁琐的逻辑转移到应用层，避免在数据库中进行不当的OLTP操作。
而且，他们把请求分成高优先级和低优先级，由不同的实例处理，这样就能避免「吵闹邻居」效应带来的性能问题。
4. 高可用与故障转移
主数据库采用高可用（HA）模式，并且有热备节点支持。
所有读取流量都转移到副本上，这样即使主库出现故障，服务依然可以保持只读状态，从而减小故障的影响。
天花板终究会到来
不过，OpenAI也承认这个架构已经遇到了物理极限，主要问题出在两个方面：
PostgreSQL的MVCC限制
PostgreSQL的多版本并发控制（MVCC）机制会导致写放大（更新一行时需复制整行）和读放大（扫描时需跳过死元组）。这对写密集型负载来说可真是个麻烦。
WAL复制压力
随着副本数量的增多，主库需要向所有副本推送预写日志（WAL）。副本越多，主库承受的网络压力就越大，副本延迟也会增加。
为了解决这些问题，OpenAI正在进行两项工作：
1. 将可分片、高写入负载迁移到Azure Cosmos DB等分布式系统；
2. 测试级联复制：让中间副本将WAL转发到下游副本，目标是支持超过100个副本。
这个案例很好地阐释了一个架构哲学：如无必要，勿增实体。
一开始不必盲目追求分布式，先用简单的解决方案应对，如果撑不住再说。
很多公司在还没到需要分布式的阶段时，就已经把架构弄得异常复杂，结果既没有享受到分布式的好处，反而背负了分布式的复杂性。
OpenAI用实践证明，一个优化得当的单机架构，能够走得比你想象的更远。
Codex与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的持续创新。
最终获益的，必然是我们这些开发者。
参考资料：
https://openai.com/index/unrolling-the-codex-agent-loop/
https://x.com/gdb/status/2014744842941956606
