新智元報(bào)道

編輯：定慧 元宇

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

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

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

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

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

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

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

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

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

Agent Loop

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

什么是Agent Loop？

如果你用過(guò)Codex CLI、Claude Code等等CLI終端工具，你可能會(huì)好奇：

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

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

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

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

下面，把這個(gè)黑盒拆開(kāi)，看看一個(gè)真正的AI Agent是如何跑起來(lái)的。

一個(gè)完整的Agent Loop是怎么跑起來(lái)的

用一個(gè)具體的例子來(lái)說(shuō)明。

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

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

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

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

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

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

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

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

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

第二步：模型推理（Inference）

這一步，大腦開(kāi)始轉(zhuǎn)動(dòng)。

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

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

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

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

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

這就像手腳開(kāi)始動(dòng)起來(lái)。

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

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

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

第五步：循環(huán)

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

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

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

它不是在回答問(wèn)題，它是在解決問(wèn)題。

為什么這很重要？

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

但絕非這么簡(jiǎn)單。

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

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

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

• 它會(huì)自己檢查錯(cuò)誤（Self-Correction）。

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

這才是真正的「AI Agent」。

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

性能優(yōu)化

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

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

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

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

對(duì)話越長(zhǎng)，成本越高。如果不優(yōu)化，成本是平方級(jí)增長(zhǎng)的。

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

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

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

這一招，直接讓長(zhǎng)對(duì)話的成本從平方級(jí)增長(zhǎng)降到了線性級(jí)。

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

• 中途換模型

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

• 改變MCP工具列表

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

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

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

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

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

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

解決方案：Compaction（對(duì)話壓縮）

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

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

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

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

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

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

1個(gè)主庫(kù)扛8億用戶

PostgreSQL的極限操作

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

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

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

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

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

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

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

他們是怎么做到的？

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

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

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

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

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

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

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

1.連接池代理（PgBouncer）

通過(guò)連接池管理，把平均連接建立時(shí)間從50ms降到了5ms。

別小看這45ms，在每秒百萬(wàn)級(jí)查詢的場(chǎng)景下，這是巨大的性能提升。

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

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

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

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

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

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

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

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

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

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

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

天花板終究會(huì)到來(lái)

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

PostgreSQL的MVCC限制

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

WAL復(fù)制壓力

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

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

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

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

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

不要一上來(lái)就搞分布式：先用簡(jiǎn)單的方案撐住，撐不住了再說(shuō)。

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

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

Codex VS Claude Code的爭(zhēng)霸賽

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

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

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

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

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

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

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

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

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

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

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

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

網(wǎng)絡(luò)安全評(píng)級(jí)的公開(kāi)，一方面是在做「預(yù)期管理」，告訴大家模型有風(fēng)險(xiǎn)，我們?cè)谪?fù)責(zé)任地處理。

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

這場(chǎng)AI編程工具的競(jìng)爭(zhēng)才剛剛開(kāi)始。

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

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

參考資料：

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

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