點擊上方藍字關注我，加個??標不迷路。
大家好，我是 cxuan，一個和 AI Agent 互相折磨的 builder。
OpenAI 2026 年 6 月 22 日發了一份新白皮書，叫 Codex-maxxing for long-running work。
這兩個 double x 是亮點，直接讓白皮書沒那么生硬了。
這個白皮書的內容簡單來說就是，OpenAI 想讓大家常駐在 Codex 中了。
這讓我想起了 Mac 為何能入侵用戶心智，而現在，Codex 也想這樣。
我來給大家詳細說說這個白皮書都有啥東西。
白皮書開頭先承認，Codex 從生下來就是 for coding work 為了編碼開發工作來做的：你可以用 Codex 改 repo、做 diff、review、幫助發版。
但是，OpenAI 說，當 Codex 有了durable thread、shared memory、tools、recurrence，還有一個能 review 產物的地方，后面的重點就變了。
你有可能會想，整這些拗口的英文詞兒干啥，這 OpenAI 又開始造詞兒了？別急，下面會告訴你這些是干啥的。
不過現在，你需要先記住一點的就是， Codex 想要殺入每個職場人的辦公桌面了。
圖源：OpenAI 官方白皮書，本地 PDF 渲染截圖
這份白皮書里，首先介紹的是 durable thread。
大家知道，在 Codex 里面，每個任務都叫一個 thread，也就是線程。
說白了，它就是一個聊天窗口。
只不過微信開個聊天窗口只能聊天，而 Codex 開個聊天窗口可以真的幫你干活。
你每次重新打開一個 thread，都像是公司里新來了一個同事。
雖然他很能干，但你得重新交代背景，比如這個項目干到哪了，前面踩過什么坑，哪些地方不能碰，誰之前說過什么，他都不知道。
durable thread 要解決的就是這個問題。
圖源：OpenAI 官方白皮書，本地 PDF 渲染截圖
OpenAI 舉了幾個例子來說明：社交反饋監控、開源項目維護、OpenAI CLI、Agents SDK、Chief of Staff。
這些任務都有一個特點：一天干不完。
比如開源項目維護，你不是今天讓 Codex 修一個 issue 就完事了。
它可能要長期看 issue、看 release note、看貢獻者習慣，還要記住怎么 review。
這類事情如果每次都新開線程，之前的記憶就沒了。
所以這節 Codex 更像是在說：重要的工作，可以先把一個 thread pin 起來，讓它能夠方便的能夠找到。
然后你長期在里面處理同一件事，比如上下文、偏好，等慢慢沉淀之后，你這個 thread 就成為了 durable thread ，就有了故事，有了背景，可以沉淀下來了，就是這么簡單。
當然，durable thread 也有代價，因為它帶著更多 context，跑起來可能會更貴。
第二個點是 voice input。
這個詞很容易被理解成語音轉文字，但其實不是。
OpenAI 給了一個場景：
假如你此時正在看 Codex 做出來的一個頁面。
你一邊看，一邊語音說：
“這個按鈕小一點。”
“這句文案不對。”
“我記得微信里有個叫 cxuan 的人提過這事，但我不太確定，你去找找。”
這些話如果讓你打字，你很可能會本能地整理一下，刪掉不確定的部分。
比如你會想想哪個按鈕需要小一點，哪個文案不太對，你可能會想想 cxuan 到底是誰。
但是語音輸入不是這樣，它就喜歡這些模糊的不確定的線索。
不要覺得這些模糊的細節沒啥用，相反，它對 Agent 很有用。
圖源：OpenAI 官方白皮書，本地 PDF 渲染截圖
白皮書里 Jason Liu 的用法是這樣的：
他一邊在瀏覽器里看 Agent 做出來的頁面，一邊錄語音吐槽和提修改意見。
錄完之后，按下 Enter 發送。
Codex 再把這段語音變成要執行的反饋。
它是在把 review 過程塞回同一個 thread 里。
電話、會議、走廊里隨口聊出來的一段話，也一樣可以這么用。
Codex 再把這堆原話整理成計劃、草稿、頁面、報告，或者下一步動作。
圖源：OpenAI 官方白皮書，本地 PDF 渲染截圖
這一節的主題，叫 Steering，Shape the queue while Codex works。
Codex 正在干活的時候，你可以繼續往隊列里塞下一步，讓 Codex 優先執行你插隊的指令。
比如它正在改一個頁面。
你看著看著，突然發現按鈕太大。
你不用等它整輪跑完，再開一條新指令。
你可以直接補一句：
“這個按鈕小一點。”
“這句文案不對。”
“這個做完之后，開一個 PR。”
“先等 preview 部署好。”
“發布前先把 preview 鏈接給我看。”
圖源：OpenAI 官方白皮書，本地 PDF 渲染截圖
這就是 steering。
它可以和 voice input 更好的配合。
語音輸入負責把你腦子里那堆沒整理好的話說出來。
steering 負責把這些話變成 Codex 工作中的下一步。
這節來講講 memory。
我在今年 4 月份的時候就說過，memory 會成為今年優先解決的主題。
這次白皮書對 memory 有了更進一步的解釋。
它說的是：長線程里的重要信息，不能只存在于聊天記錄中。
聊天記錄太長，人也不會逐條看，Agent 自己也可能抓錯重點。
所以有用的信息要寫出來，變成你能打開、能編輯、能看 diff、能復用的文件。
白皮書給了一個結構：
vault/
TODO.md
people/
projects/
agent/
notes/
圖源：OpenAI 官方白皮書，本地 PDF 渲染截圖
就是你可以建一個 vault/ 文件夾。
代碼倉庫放代碼。
vault 放工作上下文。
比如你長期讓 Codex 幫你維護一個開源項目，這個 vault 可以長這樣：
vault/
TODO.md
people/
alex.md
maintainer-lucy.md
projects/
codex-cli.md
agent/
review-rules.md
release-checklist.md
notes/
2026-06-24.md
TODO.md 里放還沒處理完的事。
比如：
- 等 preview 部署完成后，把鏈接發給 cxuan 看。
- 檢查 issue #184 里用戶提到的參數問題。
- 下次發版前確認 changelog 里有沒有漏掉 CLI 參數變化。
people/maintainer-lucy.md 里放人的偏好。
比如：
cxuan 不喜歡大 PR。
他 review 時會先看測試和 changelog。
涉及 release 的改動，最好先給他一個簡短 summary。
projects/codex-cli.md 里放項目狀態。
比如：
當前重點：減少 reconnecting 相關問題。
已決定：先修日志可觀測性，再動重試策略。
阻塞點：還缺 Windows 用戶的復現日志。
agent/review-rules.md 里放給 Codex 自己看的規則。
比如：
不要改認證邏輯。
不要順手重構無關文件。
改 CLI 行為后，必須更新幫助文檔和測試。
這樣你下次再回到這個 thread，Codex 不用只靠聊天歷史猜。
它可以直接打開這些文件，看人、項目、規則、待辦分別是什么。
這些東西放在聊天記錄里，過幾天就很難找。
放進 vault/，就變成了項目的臺賬。
如果這個 vault 放在 GitHub 里，還有個好處：你能看 diff。
也就是說，Codex 寫下來的“記憶”，它改了哪個文件，新增了哪條記錄，你都能看到。
圖源：OpenAI 官方白皮書，本地 PDF 渲染截圖
memory 講完之后，白皮書下一節講的是 Computer and browser use。
這節看起來像工具介紹，其實是在講權限邊界。
OpenAI 把這些入口分得很清楚
browser 適合本地網頁、preview、annotation。
chrome 適合需要登錄狀態的網頁，比如你已經登錄的后臺、工作臺、內部系統。
computer use 適合那些只能點 GUI 的任務。
connectors 則是 Slack、Gmail、Calendar、GitHub 這些工作入口。
skills 則是可以復用的工作流程。
圖源：OpenAI 官方白皮書，本地 PDF 渲染截圖
這一節是 Remote control。
這節其實沒啥好值得拿出來細講的。
無非就是你可以通過移動設備來實時監控和審查桌面端 Codex 的工作進度。
你人可以不用在工位前，但是活可以讓工位上的 Codex 來干。
圖源：OpenAI 官方白皮書，本地 PDF 渲染截圖
白皮書里還有一個東西叫 thread automations。
它就是讓 Codex 定時回到同一個線程里，看事情有沒有變化。
普通 prompt 是：
現在做這個。
thread automation 更像：
每 30 分鐘回來看看，如果有新情況，就準備下一步。
圖源：OpenAI 官方白皮書，本地 PDF 渲染截圖
白皮書舉了一個 Chief of Staff 的例子。
Codex 每 30 分鐘檢查 Slack 和 Gmail，看看有沒有需要回復的消息。
它可以找上下文，寫草稿，列出需要你判斷的問題。
但是，它不能直接替你發送。
圖源：OpenAI 官方白皮書，本地 PDF 渲染截圖
白皮書后面還有一節叫 Three examples of loops。
這節其實是在把前面那些東西串起來，形成一個閉環。
前面講 thread、memory、tools、automation、review，單獨看都像功能點。
但真正有用的是 loop。
也就是：Codex 按節奏回來，看上下文，用工具做一部分事，然后把需要人判斷的地方交給你。
圖源：OpenAI 官方白皮書，本地 PDF 渲染截圖
白皮書給了三個例子。
第一個就是前面說的 Chief of Staff：定時看 Slack 和 Gmail，找需要回復的消息，補上下文，寫草稿。
但是發不發、什么時候發、用什么語氣，還得是讓人來決定。
第二個是 monitor for feedback。
可以想象一下一個團隊在 Slack 等平臺里給一段動畫提反饋。
Codex 定時去看這個線程。
有新反饋，就先整理成修改清單。
然后去改 Remotion 項目。
Remotion 你可以簡單理解成用代碼做視頻和動畫的工具。
改完之后，Codex 重新渲染一版，寫清楚這版改了什么，再給一個 review 鏈接。
也就是說 Codex 負責讀反饋、改動畫、出新版本。
而人負責看效果、判斷創意方向、決定能不能發。
圖源：OpenAI 官方白皮書，本地 PDF 渲染截圖
第三個例子更生活化：get a refund。
這個例子說的是退款流程。
比如你在某個網站申請退款，客服系統一直顯示“等待人工接入”。
這時候你不想一直盯著頁面。
Codex 可以定時看一眼：客服來了沒，對話有沒有新消息，退款狀態有沒有變化。
一旦客服回復了，它先幫你把東西準備好。
比如訂單號、付款記錄、之前的溝通內容、為什么要退款。
然后它起草一段回復，順便給你一個建議：下一步應該補截圖，還是直接要求退款。
但它不能替你點“確認”。
圖源：OpenAI 官方白皮書，本地 PDF 渲染截圖
這三個例子放在一起，白皮書想說的就很清楚了。
Codex 已經太想把大家能干的活都干完了，除了最后一步它不敢做：點確認按鈕。
白皮書后面講 goal 。
這個我有太多話想說了。
我之前就跑了一個 75 h 的 goal ，結果產出是一坨，真的沒法說。
一個很 low 的 goal 是這樣的：
Implement the plan in this Markdown file.
翻譯一下就是：按這個計劃做。
問題是，做到什么程度算做完？
不知道。
所以 Codex 很容易一直忙，而且還在燒你的 SSD， 看起來很努力，但努力并不一定有結果。
圖源：OpenAI 官方白皮書，本地 PDF 渲染截圖
比較優質一點的 goal 要有驗收基線。
白皮書舉了 Rich-to-Rust 的例子。
不是簡單說“把這個庫遷到 Rust”。
它的完成標準是：遷完之后，還能通過原來的單元測試。
我自己用 Codex 的時候，也會越來越喜歡寫這種話：
完成標準：
- 原有行為不變。
- 對應測試通過。
- 不改無關模塊。
- 輸出改動文件、驗證命令和失敗嘗試。
記住一點：goal 一定要能驗收。
關于 goal 的更多用法，可以看一下這一篇。
好家伙，可算是把 goal 玩明白了。
最后是一節是 side panel。
這個東西也很好理解。
你不能永遠在聊天框里 review 工作。
Markdown、表格、CSV、PDF、slides、網頁，這些東西本身就是立體的。
只靠聊天框描述，是說不清楚，講不明白的。
圖源：OpenAI 官方白皮書，本地 PDF 渲染截圖
side panel 的價值就是：你和 Codex 在看同一個東西。
你看一個頁面，說這個按鈕太擠了。
你看一個表格，說這個公式不對。
你看一個 slide，說這個標題太長了。
這些評論會直接變成可執行的下一步指令。
這比在聊天框里說“剛才那個頁面左上角第二塊下面那個東西”要靠譜很多。
它不能只是一個聊天窗口。
它得讓你看到文件、網頁、表格、PPT，然后在這些東西的基礎上進行修改。
我覺得到這一步，Codex 才開始像一個真正能干活的東西。
Codex 更新到現在，一些最有亮點的功能都在這份白皮書中了。
所以最后來給這份白皮書做個總結，如果大家懶得看上面的內容可以直接看總結。
Codex 要成為你桌面的操作系統
白皮書通篇在講一件事：如何讓 AI 參與那些干不完的長期工作。OpenAI 想讓你把 Codex 常駐在桌面，像當年 Mac 入侵用戶心智一樣，讓它變成你工作的默認入口。
給 AI 裝上腦子
以前每次開新對話都是“新同事”，現在通過常駐線程（durable thread）+ 記憶庫（vault），Codex 有了長期記憶。項目背景、人員偏好、踩坑記錄全都能沉淀下來，來讓新同事直接變為你的老同事。
交互方式變了
語音輸入可以處理模糊的指令，Steering（插隊）讓你不用等它干完就能中途指揮，Side panel讓你和它同屏看東西。交互方式從發送指令等待結果變成了實時預覽。
最大的突破是 Loop
Codex 可以定時（比如每30分鐘）自動回來檢查郵件、Slack、網頁狀態，自己讀反饋、改代碼、寫草稿。它能幫你把一切都準備好，但絕不替你點擊確認按鈕，最終決策權永遠是你自己。
Goal 必須要能驗收
低級的 goal 會讓 Codex 瞎忙，而優質的 goal 必須帶驗收基線才行。
