整理 | 華衛(wèi)

用一個 PostgreSQL 主庫和 50 個只讀副本，就頂住了 ChatGPT 上的 8 億用戶！

近日，OpenAI 的工程師們不僅爆出了這一驚人消息，還直接把 Codex 的“大腦”給扒了個精光。在 OpenAI 官方工程博客主頁，OpenAI 工程師、Technical Staff 成員 Michael Bolin 發(fā)布了一篇文章，以“揭秘 Codex 智能體循環(huán)”為題，深入揭秘了 Codex CLI 的核心框架：智能體循環(huán)（Agent Loop），并詳細講解了 Codex 在查詢模型時如何構建和管理其上下文，以及適用于所有基于 Responses API 構建智能體循環(huán)的實用注意事項和最佳實踐。

這些消息傳出后，在 Hacker News 等技術論壇及社交平臺上獲得了高度關注?！翱此破降募夹g最終會勝出。OpenAI 正在證明，優(yōu)秀的架構遠勝于花哨的工具?！?/p>

值得一提的是，有網友透露，前不久 Anthropic 的一位工程師稱“他們用于 Claude Code UI 的架構糟糕且效率低下”。而就在剛剛，X 上出現(xiàn)一條爆料：Codex 已接管 OpenAI 100% 的代碼編寫工作。

對于“你們有多少百分比的編碼工作是基于 OpenAI 模型進行”的問題，roon 表示，“100%，我不再寫代碼了?！倍饲?，Sam Altman 曾公開發(fā)帖稱，“roon 是我的小號?！?/p>

Codex 的“大腦”揭秘

“每個人工智能智能體的核心都是 Agent Loop，負責協(xié)調用戶、模型以及模型調用以執(zhí)行有意義的軟件工作的工具之間的交互?！?/p>

據介紹，在 OpenAI 內部，“Codex”涵蓋了一系列軟件智能體產品，包括 Codex CLI、Codex Cloud 和 Codex VS Code 插件，而支撐它們的框架和執(zhí)行邏輯是同一個。

Agent Loop 的簡化示意圖

首先，智能體會從用戶那里接收輸入，并將其納入為模型準備的文本指令集，該指令集被稱為提示詞。下一步是通過向模型發(fā)送指令并要求其生成響應來查詢模型，這個過程稱為推理。推理過程中，文本提示詞首先被轉換為一系列輸入 token，隨后被用于對模型進行采樣，生成新的輸出 token 序列。輸出 token 會被還原為文本，成為模型的回復。由于 token 是逐步生成的，該還原過程可與模型的運行同步進行，這也是眾多基于大語言模型的應用支持流式輸出的原因。實際應用中，推理功能通常封裝在文本 API 后方，從而抽象化詞元化的細節(jié)。

推理步驟完成后，模型會產生兩種結果：（1）針對用戶的原始輸入生成最終回復；（2）要求智能體執(zhí)行某項工具調用操作。若為第二種情況，智能體將執(zhí)行該工具調用并將工具輸出結果附加至原始提示詞中。該輸出結果會被用于生成新的輸入內容，再次對模型進行查詢；智能體隨后會結合這些新信息，重新嘗試完成任務。這一過程會不斷重復，直至模型停止發(fā)出工具調用指令，轉而生成面向用戶的消息（在 OpenAI 的模型中，該消息被稱為助手消息）。多數(shù)情況下，這條消息會直接解答用戶的原始請求，也可能是向用戶提出的跟進問題。

由于智能體可執(zhí)行能對本地環(huán)境進行修改的工具調用，其 “輸出” 并不僅限于助手消息。在很多場景下，軟件智能體的核心輸出是在用戶設備上編寫或編輯的代碼。但無論何種情況，每一輪交互最終都會以一條助手消息收尾，該消息是智能體循環(huán)進入終止狀態(tài)的信號。從智能體的角度來看，其任務已完成，操作控制權將交還給用戶。

多輪智能體循環(huán)

這意味著，對話內容越豐富，用于模型采樣的提示詞長度也會隨之增加。而所有模型都存在上下文窗口限制，即其單次推理調用可處理的 token 最大數(shù)量，智能體可能在單次對話輪次中發(fā)起數(shù)百次工具調用，這有可能耗盡上下文窗口的容量。因此，上下文窗口管理是智能體的多項職責之一。

這套智能體循環(huán)如何運行？

據介紹，Codex 正是借助響應 API 來驅動這套智能體循環(huán)的，博文曝出許多背后的實際運行細節(jié)，包括：

• Codex 不會把用戶的話直接給大模型用，而是會主動“拼接”出一整套精心設計的提示詞結構，且涵蓋多個角色的指令、用戶輸入的一句話在結尾才出現(xiàn)。

• 模型推理與工具調用之間可能會進行多輪迭代，提示詞的內容會持續(xù)增加。

構建初始提示詞

作為終端用戶，在調用響應 API 時無需逐字指定用于模型采樣的提示詞，只需在查詢中指定各類輸入類型，由響應 API 服務器決定如何將這些信息組織為模型可處理的提示詞格式。在初始提示詞中，列表中的每個條目均關聯(lián)一個角色。該角色決定了對應內容的權重占比，優(yōu)先級從高到低分為以下幾類：系統(tǒng)、開發(fā)者、用戶、助手。

響應 API 接收包含多個參數(shù)的 JSON 負載，其中三個核心參數(shù)有：

• 指令：插入模型上下文的系統(tǒng)（或開發(fā)者）消息

• 工具：模型生成回復過程中可調用的工具列表

• 輸入：向模型傳入的文本、圖片或文件輸入列表

在 Codex 中，若已配置，指令字段的內容會從～/.codex/config.toml 配置文件中的模型指令文件讀??；若未配置，則使用與該模型關聯(lián)的基礎指令。模型專屬指令存儲在 Codex 代碼倉庫中，并被打包至命令行工具中。工具字段為符合響應 API 定義的模式的工具定義列表。對于 Codex 而言，該列表包含三部分工具：Codex 命令行工具自帶的工具、響應 API 提供且開放給 Codex 使用的工具，以及通常由用戶通過 MCP 服務器提供的自定義工具。JSON 負載的輸入字段為一個條目列表。在添加用戶消息前，Codex 會先向該輸入中插入以下條目：

1. 一條角色為開發(fā)者（role=developer）的消息，用于描述僅適用于工具部分中定義的 Codex 內置 Shell 工具的沙箱環(huán)境。也就是說，其他工具（如由 MCP 服務器提供的工具）并不受 Codex 的沙箱限制，需自行負責實施自身的防護規(guī)則。該消息基于模板構建，核心內容均來自打包在 Codex 命令行工具中的 Markdown 代碼片段。

2. 一條角色為開發(fā)者的消息，其內容為從用戶的 config.toml 配置文件中讀取的 developer_instructions 配置值。

3. 一條角色為用戶的消息，其內容為用戶指令；該內容并非來源于單個文件，而是從多個數(shù)據源聚合而來。一般而言，表述越具體的指令，排序越靠后：

4. 加載 $CODEX_HOME 目錄下 AGENTS.override.md 和 AGENTS.md 文件的內容

5. 在默認 32 千字節(jié)的大小限制內，從當前工作目錄對應的 Git / 項目根目錄（若存在）向上遍歷至當前工作目錄本身，加載任意 AGENTS.override.md、AGENTS.md 文件的內容，或加載 config.toml 配置文件中 project_doc_fallback_filenames 參數(shù)指定的任意文件內容

6. 若已配置相關技能，則補充以下內容：關于技能的簡短引言、各技能對應的技能元數(shù)據、技能使用方法說明章節(jié)。

7. 一條角色為用戶的消息，用于描述智能體當前的運行本地環(huán)境，其中會明確當前工作目錄及用戶所使用的終端 Shell 信息。

當 Codex 完成上述所有計算并完成輸入初始化后，會追加用戶消息以啟動對話。需注意的是，輸入中的每一個元素都是一個 JSON 對象，包含類型、角色和內容三個字段。當 Codex 構建好要發(fā)送至響應 API 的完整 JSON 負載后，會根據～/.codex/config.toml 中響應 API 端點的配置方式，攜帶授權請求頭發(fā)起 HTTP POST 請求（若有指定，還會添加額外的 HTTP 請求頭和查詢參數(shù)）。當 OpenAI 響應 API 服務器接收到該請求后，會使用 JSON 數(shù)據來推導出模型的提示信息，（需要說明的是，Responses API 的自定義實現(xiàn)可能會采用不同的方法）。

可見，提示詞中前三項的順序由服務器決定，而非客戶端。也就是說，這三項里僅系統(tǒng)消息的內容同樣由服務器控制，工具與指令則均由客戶端決定。緊隨其后的是 JSON 負載中的輸入內容，至此提示詞拼接完成。

模型采樣

提示詞準備就緒后，模型才開始進行進行采樣。

第一輪交互：此次向響應 API 發(fā)起的 HTTP 請求，將啟動 Codex 中對話的第一輪交互。服務器會以服務器發(fā)送事件（SSE）流的形式進行響應，每個事件的數(shù)據均為一個 JSON 負載，其 type 字段以 response 開頭。Codex 接收該事件流并將其重新發(fā)布為可供客戶端調用的內部事件對象。response.output_text.delta這類事件用于為用戶界面實現(xiàn)流式輸出功能，而response.output_item.added等其他事件則會被轉換為對象，附加至輸入內容中，為后續(xù)的響應 API 調用所用。

若首次向響應 API 發(fā)起的請求返回兩個response.output_item.done事件，一個類型為推理（reasoning），一個類型為函數(shù)調用（function_call），那么當結合工具調用的返回結果再次向模型發(fā)起查詢時，這些事件必須在 JSON 的輸入字段中進行體現(xiàn)。后續(xù)查詢中用于模型采樣的最終提示詞結構如下：

需要特別注意的是，舊提示詞是新提示詞的完整前綴。這一設計是有意為之的，因為它能讓用戶借助提示詞緩存提升后續(xù)請求的效率。

在 Codex 命令行工具中，會將助手消息展示給用戶，并聚焦輸入編輯區(qū)，以此提示用戶輪到其繼續(xù)對話。若用戶做出回應，上一輪的助手消息以及用戶的新消息均需附加至響應 API 請求的輸入字段中，從而開啟新一輪對話。同樣，由于對話處于持續(xù)進行的狀態(tài)，發(fā)送至響應 API 的輸入內容長度也會不斷增加。

棄用簡單參數(shù)費力做優(yōu)化，

就為了用戶隱私？

“在對話過程中，發(fā)送至響應 API 的 JSON 數(shù)據量，是否會讓智能體循環(huán)的時間復雜度達到二次方級別？”答案是肯定的。

據悉，盡管響應 API 支持通過可選的 previous_response_id 參數(shù)緩解這一問題，但目前 Codex 并未啟用該參數(shù)，主要是為了保證請求完全無狀態(tài)，并兼容零數(shù)據保留（ZDR） 配置，即不存儲用戶對話數(shù)據。

取而代之的，是兩套需投入大量研發(fā)精力、涉及復雜實施流程的技術策略。文中，OpenAI 詳細介紹了這兩項硬核優(yōu)化的具體方案。

通常，模型采樣的開銷遠高于網絡傳輸?shù)拈_銷，采樣環(huán)節(jié)會成為優(yōu)化效率的核心目標，這也是提示詞緩存至關重要的原因，它能復用前一次推理調用的計算結果。當緩存命中時，模型采樣的時間復雜度將從二次方降至線性。OpenAI 相關的提示詞緩存文檔對這一機制有更詳細的說明：僅當提示詞存在完全匹配的前綴時，才有可能實現(xiàn)緩存命中。為充分發(fā)揮緩存的優(yōu)勢，需將指令、示例等靜態(tài)內容置于提示詞開頭，而將用戶專屬信息等可變內容放在末尾。這一原則同樣適用于圖片和工具，且其內容在各次請求中必須保持完全一致。

基于這一原則，Codex 中可能有以下導致緩存未命中的操作：

1. 在對話過程中修改模型可調用的工具列表；

2. 更換響應 API 請求的目標模型（實際場景中，這會改變原始提示詞中的第三項內容，因該部分包含模型專屬指令）；

3. 修改沙箱配置、審批模式或當前工作目錄。

因此，Codex 團隊在為命令行工具開發(fā)新功能時，必須審慎考量，避免新功能破壞提示詞緩存機制。例如，他們最初對 MCP 工具的支持曾出現(xiàn)一個漏洞：工具的枚舉順序無法保持一致，進而導致緩存未命中。需要注意的是，MCP 工具的處理難度尤為突出，因為 MCP 服務器可通過 notifications/tools/list_changed 通知，動態(tài)修改其提供的工具列表。若在長對話過程中響應該通知，極易引發(fā)高成本的緩存未命中問題。

在可能的情況下，針對對話過程中發(fā)生的配置變更，他們會通過在輸入中追加新消息的方式體現(xiàn)變更，而非修改已有的早期消息：

• 若沙箱配置或審批模式發(fā)生變更，我們會插入一條新的role=developer消息，格式與原始的條目保持一致；

• 若當前工作目錄發(fā)生變更，我們會插入一條新的role=user消息，格式與原始的條目保持一致。

據介紹，為保障性能，OpenAI 在實現(xiàn)緩存命中方面投入了大量精力。除此之外，他們還重點管理了一項核心資源：上下文窗口。

其規(guī)避上下文窗口耗盡的通用策略是：一旦詞元數(shù)量超過某個閾值，就對對話進行壓縮。具體來說，會用一個更精簡、且能代表對話核心內容的新條目列表替代原有輸入，讓智能體在繼續(xù)執(zhí)行任務時仍能理解此前的對話過程。早期的壓縮功能實現(xiàn)方案，需要用戶手動調用 /compact 命令，該命令會結合現(xiàn)有對話內容和自定義的摘要生成指令，向響應 API 發(fā)起查詢；Codex 則會將返回的、包含對話摘要的助手消息，作為后續(xù)對話輪次的新輸入。

此后，響應 API 不斷迭代，新增了專用的 /responses/compact 端點，能以更高效率完成壓縮操作。該端點會返回一個條目列表，可替代原有輸入繼續(xù)對話，同時釋放出更多的上下文窗口空間。該列表中包含一個特殊的 type=compaction 條目，其附帶的 encrypted_content 加密字段為透明化設計，可保留模型對原始對話的潛在理解。

現(xiàn)在，當詞元數(shù)量超過 auto_compact_limit 自動壓縮閾值時，Codex 會自動調用該端點對對話內容進行壓縮。

極限擴容：用 1 個數(shù)據庫

扛住了 8 億用戶

在另一篇技術博文中，OpenAI 工程師 Bohan Zhang 介紹， OpenAI 通過嚴苛的技術優(yōu)化與扎實的工程實踐，對單個數(shù)據庫 PostgreSQL 進行深度擴容，實現(xiàn)以單套體系支撐 8 億用戶、每秒數(shù)百萬次查詢的訪問需求。

據稱，多年來，PostgreSQL 一直是支撐 ChatGPT、OpenAI API 等核心產品的核心底層數(shù)據系統(tǒng)之一。過去一年，公司 PostgreSQL 的負載增長超 10 倍，且這一增長趨勢仍在持續(xù)加速。OpenAI 稱，PostgreSQL 的橫向擴展能力遠超此前行業(yè)普遍認知，能夠穩(wěn)定支撐規(guī)模大得多的讀密集型工作負載?！斑@套最初由加州大學伯克利分校的科學家團隊研發(fā)的系統(tǒng)，助力我們通過單主節(jié)點 Azure PostgreSQL 彈性服務器實例，搭配分布在全球多個區(qū)域的近 50 個只讀副本，承接了海量的全球訪問流量?！?/p>

而且，OpenAI 表示，其擴容在實現(xiàn)規(guī)模提升的同時，始終將延遲控制與可靠性優(yōu)化放在核心位置：生產環(huán)境中，客戶端 99 分位延遲穩(wěn)定保持在十幾毫秒的低水平，服務可用性達到五個九標準；過去 12 個月內，PostgreSQL 僅出現(xiàn)過一次零級嚴重故障，該故障發(fā)生在 ChatGPT 圖像生成功能爆紅上線期間，一周內超 1 億新用戶注冊導致寫流量突發(fā)暴漲超 10 倍。

盡管 PostgreSQL 的擴容成果已達預期，OpenAI 仍在持續(xù)探索其性能極限。目前，他們已將可分片的寫密集型業(yè)務負載遷移至 CosmosDB 等分片式數(shù)據庫系統(tǒng)；對于分片難度更高的剩余寫密集型負載，相關遷移工作也在積極推進，以此進一步減輕 PostgreSQL 主節(jié)點的寫壓力。同時，OpenAI 正與微軟 Azure 團隊展開合作，推動級聯(lián)復制功能落地，實現(xiàn)只讀副本的安全、大規(guī)模擴容。隨著基礎設施需求的持續(xù)增長，其將繼續(xù)探索更多擴容方案，包括基于 PostgreSQL 的分片架構改造、引入其他分布式數(shù)據庫系統(tǒng)等。

有網友評價道，“這招的高明之處，就在于極簡。他們沒用什么花里胡哨的冷門技術，不過是把最佳實踐做到了極致。過去十年，行業(yè)里全是 ‘一切皆分片、擁抱 NoSQL、全面分布式，為 CAP 定理折腰’ 的論調，而 OpenAI 倒好， 服務十億級用戶的解法，居然只是一句‘試過加只讀副本嗎？’”

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

https://openai.com/index/scaling-postgresql/

聲明：本文為 AI 前線整理，不代表平臺觀點，未經許可禁止轉載。

會議推薦

InfoQ 2026 全年會議規(guī)劃已上線！從 AI Infra 到 Agentic AI，從 AI 工程化到產業(yè)落地，從技術前沿到行業(yè)應用，全面覆蓋 AI 與軟件開發(fā)核心賽道！集結全球技術先鋒，拆解真實生產案例、深挖技術與產業(yè)落地痛點，探索前沿領域、聚焦產業(yè)賦能，獲取實戰(zhàn)落地方案與前瞻產業(yè)洞察，高效實現(xiàn)技術價值轉化。把握行業(yè)變革關鍵節(jié)點，搶占 2026 智能升級發(fā)展先機！

今日薦文

你也「在看」嗎？