OpenAI絕地反擊！Codex大腦首曝，8億用戶極限架構(gòu)硬剛Claude

新智元報道

編輯：定慧 元宇

【新智元導(dǎo)讀】AI編程霸主之爭升級！Claude Code剛刷屏，OpenAI連甩兩張王：不僅首度揭秘Codex背后的大腦「Agent Loop」，還自曝驚人基建：僅用1個PostgreSQL主庫，竟抗住了全球8億用戶洪峰！

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

那個能在終端里自己讀代碼、改代碼、跑測試的AI助手，讓不少開發(fā)者直呼「這才是未來」。

一時間，社交媒體上全是「Claude Code吊打Cursor、Codex、Antigravity」之類的評論。

就在大家以為OpenAI還在憋GPT-5.3大招的時候，今天其官博和奧特曼突然在X平臺甩出了兩張王炸：

1.Agent Loop架構(gòu)揭秘：首次公開Codex的「大腦」是怎么運(yùn)轉(zhuǎn)的

2.PostgreSQL極限架構(gòu)：1個主庫扛起8億用戶的瘋狂操作

這一波組合拳打得太漂亮了。

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

Agent Loop

Codex的「大腦 」 是怎么運(yùn)轉(zhuǎn)的

什么是Agent Loop？

如果你用過Codex CLI、Claude Code等等CLI終端工具，你可能會好奇：

這玩意兒到底是怎么知道我想干啥的？怎么就能自己讀文件、寫代碼、跑命令？

答案就藏在一個叫Agent Loop（智能體循環(huán)）的東西里。

簡單來說，Agent Loop就像一個「總指揮」，它負(fù)責(zé)把「用戶意圖」「模型大腦」和「執(zhí)行工具」串成一個完美的閉環(huán)。

這不是普通的「你問我答」，而是一個包含了「觀察-思考-行動-反饋」的能干活的系統(tǒng)。

下面，把這個黑盒拆開，看看一個真正的AI Agent是如何跑起來的。

一個完整的Agent Loop是怎么跑起來的

用一個具體的例子來說明。

假設(shè)在終端里輸入：給項(xiàng)目的README.md加一個架構(gòu)圖。

第一步：構(gòu)建Prompt

這好比給大腦發(fā)工單。

Codex不會直接把你的話丟給模型，它會先構(gòu)建一個精心設(shè)計的「Prompt」：

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

• 我有什么工具（Tools）：有哪些工具可以調(diào)用（比如shell命令、文件操作）

• 環(huán)境上下文（Context）：當(dāng)前在哪個目錄、用的什么shell

• 用戶指令：給README.md加一個架構(gòu)圖。

這就像給模型發(fā)一封詳細(xì)的工作郵件，而不是只發(fā)一句「幫我干活」。

第二步：模型推理（Inference）

這一步，大腦開始轉(zhuǎn)動。

Codex把這個Prompt發(fā)給ResponsesAPI，模型開始思考：

「用戶想加架構(gòu)圖，我得先看看現(xiàn)在的README是什么樣的……」

然后模型做出決定：調(diào)用shell工具，執(zhí)行catREADME.md。

第三步：工具調(diào)用（ToolCall）

Codex收到模型的請求，在本地執(zhí)行命令，把README.md的內(nèi)容讀出來。

這就像手腳開始動起來。

第四步：結(jié)果反饋

這一步，終端把README.md的內(nèi)容吐了出來。

這時候流程沒有結(jié)束。Codex把命令的輸出追加到Prompt里，再發(fā)給模型。

第五步：循環(huán)

模型看到了README的內(nèi)容，再次進(jìn)行推理：

可能是生成一個Mermaid圖，可能是直接寫一段ASCII圖形……然后再調(diào)用工具寫入文件。

這個循環(huán)一直持續(xù)，直到模型認(rèn)為任務(wù)完成了，輸出一條「我搞定了」的消息。

它不是在回答問題，它是在解決問題。

為什么這很重要？

也許你可能會說：「這不就是多調(diào)了幾次API嗎？」

但絕非這么簡單。

傳統(tǒng)的LLM應(yīng)用是「一問一答」式的：你問，它答，完事兒。

但Agent Loop讓AI變成了一個能獨(dú)立干活的員工。

• 它會自己規(guī)劃路徑（Chain of Thought）。

• 它會自己檢查錯誤（Self-Correction）。

• 它會自己驗(yàn)證結(jié)果（Feedback Loop）。

這才是真正的「AI Agent」。

而Agent Loop，就是那個可以讓AI實(shí)現(xiàn)從「陪伴聊天」邁向「獨(dú)立干活」飛躍的橋梁。

性能優(yōu)化

兩個關(guān)鍵技術(shù)

OpenAI在文章里分享了兩個硬核優(yōu)化，解決了Agent開發(fā)的兩大痛點(diǎn)：

痛點(diǎn)一：成本爆炸

Agent Loop每跑一圈，都要把之前的對話歷史（包括那些冗長的報錯信息、文件內(nèi)容）重新發(fā)給模型。

對話越長，成本越高。如果不優(yōu)化，成本是平方級增長的。

解決方案：PromptCaching（提示詞緩存）

OpenAI采用了一種類似于「前綴匹配」的緩存策略。

簡單來說，只要你發(fā)給模型的前半部分內(nèi)容（System指令、工具定義、歷史對話）沒變，服務(wù)器就不需要重新計算，直接調(diào)取緩存。

這一招，直接讓長對話的成本從平方級增長降到了線性級。

但這里有個坑：任何改變Prompt前綴的操作都會導(dǎo)致緩存失效。比如：

• 中途換模型

• 修改權(quán)限配置

• 改變MCP工具列表

OpenAI團(tuán)隊甚至在文章里承認(rèn)，他們早期的MCP工具集成有bug：工具列表的順序不穩(wěn)定，導(dǎo)致緩存頻繁失效。

痛點(diǎn)二：上下文窗口有限

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

如果Agent讀了一個巨大的日志文件，上下文瞬間就滿了，前面的記憶就會被擠掉。

對于程序員來說，這就意味著：「你把前面我定義的函數(shù)給忘了？！」

這不僅是智障，更是災(zāi)難。

解決方案：Compaction（對話壓縮）

當(dāng)Token數(shù)超過閾值，Codex不會簡單地「刪除舊消息」，而是會調(diào)用一個特殊的/responses/compact接口，把對話歷史「壓縮」成一個更短的摘要。

普通的總結(jié)（Summary）只是把長文本變成短文本，會丟失大量細(xì)節(jié)。

OpenAI的Compaction返回的是一段encrypted_content（加密內(nèi)容），保留了模型對原始對話的「隱性理解」。

這就像把一本厚書壓縮成一個「記憶卡片」，模型讀了卡片就能回憶起整本書的內(nèi)容。

這讓Agent在處理超長任務(wù)時，依然能保持「智商」在線。

這一次，OpenAI硬核揭秘Codex CLI背后的「大腦」「Agent Loop」，釋放出一個信號：AI真的是要把活兒給干了。

1個主庫扛8億用戶

PostgreSQL的極限操作

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

支撐全球8億ChatGPT用戶、每秒處理數(shù)百萬次查詢的，竟然只是一個單一主節(jié)點(diǎn)的PostgreSQL數(shù)據(jù)庫！

它只用1個PostgreSQL主節(jié)點(diǎn)+50個只讀副本就做到了。

8億用戶，這簡直是在開玩笑！有網(wǎng)友驚嘆。

在分布式架構(gòu)盛行的今天，大家動不動就是「微服務(wù)」「分片」「NoSQL」。

能用巨型分布式集群解決的問題，絕不用單機(jī)。

結(jié)果OpenAI告訴你：我們就用個PostgreSQL，照樣扛。

他們是怎么做到的？

根據(jù)OpenAI工程師披露的信息，關(guān)鍵技術(shù)包括：

1. PgBouncer連接池代理 ：大幅減少數(shù)據(jù)庫連接開銷

2. 緩存鎖定機(jī)制 ：避免緩存穿透導(dǎo)致的寫入壓力

3. 跨地域級聯(lián)復(fù)制 ：讀請求分散到全球各地的副本

這套架構(gòu)的核心思想是：讀寫分離，極致優(yōu)化讀路徑。

畢竟對于ChatGPT這種應(yīng)用，讀請求遠(yuǎn)遠(yuǎn)多于寫請求。用戶發(fā)條消息，系統(tǒng)可能需要讀幾十次數(shù)據(jù)（用戶信息、對話歷史、配置信息……），但寫入只有一次。

根據(jù)OpenAI官方博客披露，關(guān)鍵技術(shù)包括：

1.連接池代理（PgBouncer）

通過連接池管理，把平均連接建立時間從50ms降到了5ms。

別小看這45ms，在每秒百萬級查詢的場景下，這是巨大的性能提升。

2.緩存鎖定/租約機(jī)制（CacheLocking/Leasing）

這是一個非常聰明的設(shè)計。

當(dāng)緩存未命中時，只允許一個請求去數(shù)據(jù)庫查詢并回填緩存，其他請求等待。

這避免了「緩存雪崩」——大量請求同時涌向數(shù)據(jù)庫的災(zāi)難場景。

3.查詢優(yōu)化與負(fù)載隔離

團(tuán)隊發(fā)現(xiàn)并修復(fù)了一個涉及12張表連接的復(fù)雜查詢。

他們把復(fù)雜邏輯移到應(yīng)用層處理，避免在數(shù)據(jù)庫里做OLTP反模式操作。

同時，請求被分為高優(yōu)先級和低優(yōu)先級，分別由專用實(shí)例處理，防止「吵鬧鄰居」效應(yīng)導(dǎo)致的性能下降。

4.高可用與故障轉(zhuǎn)移

主庫運(yùn)行在高可用（HA）模式，配有熱備節(jié)點(diǎn)。

讀流量全部分流到副本，即使主庫宕機(jī)，服務(wù)仍能保持只讀可用，降低故障影響級別。

天花板終究會到來

不過，OpenAI也坦言，這套架構(gòu)已經(jīng)碰到了物理極限。問題出在兩個地方：

PostgreSQL的MVCC限制

PostgreSQL的多版本并發(fā)控制（MVCC）機(jī)制會導(dǎo)致寫放大（更新一行需要復(fù)制整行）和讀放大（掃描時需要跳過死元組）。對于寫密集型負(fù)載，這是個硬傷。

WAL復(fù)制壓力

隨著副本數(shù)量增加，主庫需要向所有副本推送預(yù)寫日志（WAL）。副本越多，主庫的網(wǎng)絡(luò)壓力越大，副本延遲也越高。

為了突破這些限制，OpenAI正在做兩件事：

1. 把可分片的、高寫入負(fù)載遷移到AzureCosmosDB等分布式系統(tǒng)；

2. 測試級聯(lián)復(fù)制：讓中間副本向下游副本轉(zhuǎn)發(fā)WAL，目標(biāo)是支持超過100個副本。

這個案例完美詮釋了一個架構(gòu)哲學(xué)：如無必要，勿增實(shí)體。

不要一上來就搞分布式：先用簡單的方案撐住，撐不住了再說。

很多公司的問題是：還沒到需要分布式的階段，就已經(jīng)把架構(gòu)搞得無比復(fù)雜了。結(jié)果既沒有分布式的好處，還背上了分布式的復(fù)雜度。

OpenAI用實(shí)踐證明：一個優(yōu)化到極致的單機(jī)架構(gòu)，能走得比你想象的更遠(yuǎn)。

Codex VS Claude Code的爭霸賽

Claude Code的殺手锏是什么？是端到端的開發(fā)體驗(yàn)。

它不是一個簡單的代碼補(bǔ)全工具，而是一個能在終端里獨(dú)立干活的Agent。

它能讀代碼、改代碼、跑測試、處理Git、甚至自己修Bug。現(xiàn)在甚至還能寫文檔，做PPT。

這直接威脅到了Codex CLI的地位。

OpenAI這波更新，其實(shí)是在說三件事：

第一，我的Agent架構(gòu)更成熟。

Agent Loop的公開，展示了OpenAI在Agent架構(gòu)上的深厚積累。這不是一個臨時拼湊的產(chǎn)品，而是經(jīng)過精心設(shè)計的系統(tǒng)。

Prompt Caching、Compaction、MCP工具集成……這些都是實(shí)打?qū)嵉墓こ棠芰Α?/p>

第二，我的基礎(chǔ)設(shè)施更強(qiáng)。

PostgreSQL的案例，展示的是OpenAI的后端能力。8億用戶的規(guī)模，不是隨便一個創(chuàng)業(yè)公司能玩轉(zhuǎn)的。

這也是在暗示：我們的「護(hù)城河」不只是模型，還有整個工程體系。

第三，我的模型在變得更強(qiáng)大。

網(wǎng)絡(luò)安全評級的公開，一方面是在做「預(yù)期管理」，告訴大家模型有風(fēng)險，我們在負(fù)責(zé)任地處理。

另一方面，這也是在秀肌肉：我們的模型已經(jīng)強(qiáng)大到需要專門評估網(wǎng)絡(luò)安全風(fēng)險了。

這場AI編程工具的競爭才剛剛開始。

Claude Code逼迫OpenAI加快了Codex的迭代速度。OpenAI的回應(yīng)，又會倒逼Anthropic繼續(xù)創(chuàng)新。

最終受益的，是我們這些開發(fā)者。

參考資料：

https://openai.com/index/unrolling-the-codex-agent-loop/

https://x.com/gdb/status/2014744842941956606