原文標題：Codex-maxxing
原文作者：Jason Liu
編譯：Peggy

編者按：AI Agent 正在從「寫程式的工具」，變成一種新的工作操作系統。

本文作者 Jason Liu（OpenAI Codex 團隊工程師）以自己使用 Codex 的經驗為線索，記錄了這一變化如何發生：從置頂線程、語音輸入、共享記憶，到瀏覽器控制、遠端操作、Heartbeats 自動循環和側邊面板，Codex 不再只是一個等待 prompt 的聊天視窗，而開始成為一個可以承載任務、記住上下文、生成產物並持續推進工作的空間。

最值得關注的，不是 Codex 能不能寫出更好的程式碼，而是它正在改變「工作如何被組織」。過去，AI 的使用常常停留在「一問一答」：用戶提出需求，模型給出結果，任務隨對話結束而中斷。但在這套新的工作流裏，線程可以長期存在，記憶可以沈澱為文件，任務可以定期自動執行，用戶可以隨時介入、審閱和修正，最終形成一個小型的運行循環。

這意味著 Agent 的價值正在從「能力」轉向「連續性」。它不只是幫人完成某個單點任務，而是在不同工具、文件、瀏覽器、Slack、Gmail、日曆和本地應用之間建立連接，讓工作在用戶離開後仍然保持推進。對於知識工作者來說，這可能是 AI 工具真正進入日常生產流程的關鍵一步：不是替代某個動作，而是讓更多工作不再死在一次 prompt 之後。

以下為原文：

Codex 不只是寫程式碼，而是在接管工作流

在 Codex 出現之前，我就已經大量使用編程 Agent 了。不過，大多數時候，我是在專門為編程工作設計的界面裡使用它們：生成 diff、修改程式碼倉庫、交付程式碼。

大約從 11 月開始，我開始把它們推向知識工作場景。我用 Slidev 做簡報，把 Agent 當成帶語音輸入的筆記員來用，也一直在尋找其他可以由編程 Agent 協助生成的產物：一個 index.html、一個 PDF、一張電子表格、一套幻燈片。

最新一輪 Codex App 的升級，是我用過的第一個真正讓這種更廣義工作模式顯得「原生」的產品。Codex 依然非常擅長寫程式碼，但更有趣的變化在於，它開始給我的工作提供一個可以「安放」的地方。

真正改變我使用習慣的，是我學會了給工作建立一個運行迴圈：一個可長期保存的線程、共享記憶、能夠操作我電腦的工具、可以隨時介入和恢復任務的方式，以及一個能讓我直接審閱產物本身的介面。

持久線程

第一個改變我行為的功能，是上下文壓縮。

現在，我會為每一個重要的工作流保留一個置頂線程：

我的 Chief of Staff 線程

Agents SDK

OpenAI CLI

Codex for open source

一個專門用來監控 Twitter 的線程

這些都不是短對話。它們是我已經壓縮了幾個月的巨型線程。它們不斷積累歷史、偏好和過去做過的決定，而這些資訊我不想每次回來時都重新交代一遍。

置頂線程快速鍵

你可以通過 Command-1 到 Command-9，直接跳轉到置頂線程。

這裡當然有取捨。長期運行的線程並不是免費的。如果你之後再次打開它們，對話大概率已經不在快取裡，因此相比新開一個短線程，成本可能更高。但對於我真正關心的工作流來說，連續性是值得的。

語音輸入

語音輸入能讓 Codex 獲得更多我真實的思考過程。

它的好處並不在於速度，而在於 Agent 能拿到未經編輯的思考原貌。Codex 內置了語音輸入，但我也會使用 Wispr Flow，因為系統級聽寫會改變我向其他工具輸入上下文的方式。如果我正在規劃一項工作，我可能會說：「我記得 Slack 里有個叫 Ben 的人提過這事，我不太記得具體是什麼，你去找一下。」這句話如果打出來，會顯得模糊又煩人，但說出來卻非常自然。

轉錄文本也是如此。如果我想寫一篇文章，我可以給某個人打電話，錄下對話，或者用手機上的 Granola 記錄一次線下談話，然後把轉錄稿作為起點材料。很多計畫之所以會變得更好，是因為模型拿到了我混亂但真實的想法，而不只是被我打磨過的版本。

Steering：持續引導

語音輸入在和 Steering 結合時會變得更有用。

Steering 允許你在一次工具調用之後，繼續注入下一條消息。比如我在審閱一個網站時，可以一邊看一邊繼續說：

把這個調小一點

這句文案不對

這兩個元素之間的間距感覺不舒服

完成之後打開一個 PR

等預覽部署完成

把預覽連結發給需要在 Slack 上審閱的人

我不需要等每一步完成之後，再決定下一步做什麼。我可以在 Agent 還在工作時繼續追加意圖，然後帶著已經排好隊的任務離開。

之後，Heartbeats 可以在我離開後繼續監控 PR 或 Slack 線程。工作單位不再是「一個 prompt，一個回答」，而變成了一個小型運行循環。

記憶

一旦線程開始長期存在，它們就需要某種不依賴單一程式庫的共享記憶。

關鍵不只是保存消息歷史。一個長線程當然可以記住很多東西，但如果那些有用的信息沒有被序列化到某個持久位置，它們就會被困在線程裡。記憶系統的意義在於，把線程學到的東西轉化成一種我可以檢查、編輯、比對 diff，並重複使用的產物。

我的大多數長期線程都從一個 Obsidian vault 開始：

vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/

在最上層，我會保留 AGENTS.md 指令，內容包括：當你對某個人有更多了解、推進了某個項目，或者關閉了一個待辦循環時，請更新 vault 里對應的頁面。

这個 vault 就是 Agent「居住」的地方，它獨立於任何單個專案。程式碼倉庫存放程式碼；vault 則存放圍繞我工作的滾動上下文：人物、決策、未閉環事項、每日記事、專案狀態，以及那些原本很容易在線程之間遺失的理解。

我也會把這個 vault 作為一個 GitHub 倉庫來維護。這樣做給我帶來兩個好處：

它可以在雲端運行；

diff 成為審閱記憶的介面。

當 Agent 更新 vault 時，我可以閱讀 diff，看看它認為哪些內容重要到值得被記住。這個審閱步驟很關鍵。我不希望長青線程悄悄在對話歷史裡積累一種模糊的「感覺」。我希望它把真正發生變化的事情寫下來：這個人偏好什麼，這個專案在等什麼，這個決定已經做出，這個循環已經關閉。

這也是為什麼我喜歡把記憶做成檔案。檔案會迫使 Agent 把經驗壓縮成一種能夠脫離線程繼續存在的形式。如果線程消失了、壓縮得很糟糕，或者繼續依賴它變得太貴，有用的知識仍然在那裡。

到了這個階段，置頂線程開始不再像聊天視窗，而更像是不同的工作人員在閱讀同一本記事本。

Codex 在 Settings > Personalization > Memories 中也有第一方記憶功能。我把它理解為一種本地召回層：它適合記錄穩定偏好、重複工作流、專案慣例和已知坑點，但不能替代被提交進倉庫的指令，也不能替代一個顯式的 vault。Chronicle 在這裡尤其有趣，因為它可以利用最近的螢幕上下文來幫助構建記憶。我還沒有認真使用它，而且文件也明確說明，它是一個需要主動選擇加入的研究預覽功能，在權限、速率限制、提示注入和未加密本地記憶檔案等方面都有真實取捨。但從方向上看，它指向的正是我關心的事情：工作應該留下結構化記憶，而不只是留下更長的聊天記錄。

電腦與瀏覽器使用

一旦一個線程擁有了記憶，下一個問題就是：它能接觸到什麼？

在我自己的理解裡，最有用的區分是：

$browser：用於我想檢查和標註的本地網頁介面；

@chrome：用於已登錄的瀏覽器狀態和多個標籤頁；

@computer：用於那些只能通過圖形介面完成的工作。

如果我正在迭代一個本地應用，我想用 $browser。如果我需要在一個已登錄的瀏覽器會話裡操作，我想用 @chrome。如果完成任務的唯一方式是點擊某個桌面應用，那我就需要 @computer。

在我的工作電腦上，Twitter 登錄在 Safari 裡。如果我讓 @computer 在那裡讀取 Twitter，它工作時我就不能用 Safari 了。而當我希望 Agent 同時使用多個已認證標籤頁，但又不想接管我正在使用的整個應用時，@chrome 會更合適。

Connectors 則把這種能力延伸到了我真實工作的其他部分。我最常用的是 $slack、$gmail 和 $calendar，因為很多工作在變成代碼之前，首先會出現在 Slack 線程、收件匣和日曆裡。

Skills 則讓重複工作流變得可重用。Skill Creator 和 Skill Installer 是很好的起點。Skill Installer 允許你直接從 composer 添加 OpenAI 推薦的 skills。Codex pets 發布後，我用它安裝了 Hatch Pet skill，但真正有價值的是這種通用模式：一旦你成功做過某件有用的事，通常就可以把它打包起來，讓 Codex 下次不需要重新學習整個流程也能再做一遍。

持續推進工作

遠端控制

遠端控制讓這些更長的工作循環變得可攜帶。

Codex 可以繼續在那台已經擁有你的檔案、權限和本地環境的機器上工作，而你則可以通過手機查看進展、審閱它發現的東西、回答問題、批准下一步，或者在不用回到桌前的情況下改變方向。OpenAI 把它描述為一種可以隨時隨地與 Codex 協作的方式。

當 Codex 已經在執行一個長期任務，而你又想保持推進勢頭時，這一點最重要。你可以啟動一個任務，然後離開；當它抵達某個需要決策的節點時，再用手機進行引導。

這與置頂主題、語音輸入和 Heartbeats 重要的原因是一樣的：工作不再因為我換了地點而暫停。一個主題可以繼續運行，而我只需要投入足夠少的注意力，幫助它解鎖下一步。

Heartbeats

置頂主題很有用，但它們仍然會等待你發出指令。Heartbeats 則讓它們能夠周期性運行。

Heartbeat 是一種主題本地自動化。你可以說：「每隔幾個小時幫我看一下這個。」然後這個主題就可以為自己設定計劃。一個主題可以有多個日程安排，可以一直運行直到某個條件被滿足，也可以隨著時間調整自己的執行頻率。

Chief of Staff

我的 Chief of Staff 主題每 30 分鐘運行一次：

每 30 分鐘檢查一次 Slack 和 Gmail，看看有沒有需要我注意但尚未回覆的消息。
幫我判斷哪些事情最重要。
如果有人問我問題，儘可能深入研究答案，並為我草擬回覆，但不要發送。

當我回到 Slack 時，很多回覆往往已經在草稿裡了。我仍然決定哪些內容要發送，但最費力的上下文收集已經完成了。

監控反饋

同樣的模式也適用於審閱循環。Heartbeat 可以監控 Google Docs 評論、pull request 評論或 Slack 回覆，並在反饋出現時繼續推動工作。

我最喜歡的一個例子來自一個動畫專案。我把一個視頻發到 Slack 上，然後讓 Codex 每 15 分鐘檢查一次主題，看看有沒有反饋；如果有評論，就重新渲染一個新版本，並在該主題裡回覆、標記審閱者。Slack MCP 伺服器無法上傳文件，於是 Agent 使用 @computer 點擊「Add file」按鈕，仍然把修訂後的渲染文件發了上去。

有趣的不只是它每 15 分鐘檢查一次 Slack，而是這個循環跨越了多個工具邊界：Slack 用來收集反饋，Remotion 用來渲染，@computer 用來上傳。當 Heartbeats、connectors 和電腦操作結合在一起時，它們就不再像一個個獨立功能，而變成了一個無需我坐在那裡也能持續運行的反饋循環。

申請退款

最近，我有一個包裹被偷了。Amazon 告訴我，大概要等 25 分鐘才能和真人客服溝通。於是我創建了一個帶 @computer 的線程，並告訴它：

每 5 分鐘檢查一次，看看客服人員是否已經加入這個對話。
如果他們加入了，盡你所能幫我爭取退款。
一旦對方回覆，就改為每分鐘檢查一次，這樣你可以更快回應。

等我洗完澡出來，退款已經處理好了。

我的許多 Heartbeats 也會更新我的 Obsidian vault，把它作為一種顯式記憶。

目標

我還在學習如何更好使用的最新功能，是 Goals。

你應該給它設定更有野心的目標。一個弱目標是：「執行這個 Markdown 檔案裡的計劃。」一個強目標則應該有真正的成功標準，讓 Agent 能持續朝著它推進。

上週，我嘗試把 Python Rich 庫遷移至 Rust。由於原項目本身已經有一套龐大的單元測試，我就可以設定這樣一個目標：把 Rich 遷移到 Rust，但它必須通過原 Python 庫的所有單元測試。

這套測試給運行過程提供了一個真正的判定標準：Rust 版本只有通過與 Python 原庫相同的測試，才算完成。

這不同於和 AI 進行一場漫長對話，積累一個 Markdown 計劃，然後最終說一句：「實現它。」執行效果的上限，取決於你給出的目標和驗證方式。沒有驗證的野心，只是願望。

AI 真正進入工作流

側邊面板

Codex 裡最讓我興奮的部分，是側邊面板。

人們很容易把它理解成一個預覽發生的地方。但這種理解低估了它。側邊面板是 Codex 不再只是一個聊天應用，而開始成為工作發生之處的地方。

對我來說，它承擔三件事：檢查產物、操作網頁界面、審閱變更。在這三種情況下，我都可以查看並評論 Agent 正在操作的同一個對象。

檢查產物

Markdown、電子表格、CSV、PDF 和簡報都可以放在那裡。

Markdown 可以註釋。電子表格可以渲染公式，並支持儲存格編輯，我會用它來管理 Codex 開源計畫。CSV 會顯示成表格，而不是原始文本。PDF 可以直接渲染，這對 LaTeX 尤其有用。簡報也可以在不離開應用的情況下創建和審閱。

關鍵不只是 Codex 能夠生成這些產物，而是我可以在不打斷循環的情況下檢查和標註它們。

操作網頁介面

應用內瀏覽器更有趣。Agent 可以看見它，通過 $browser 使用 JavaScript 控制它，而我可以直接在自己正在查看的內容上留下標註。

有幾個網頁介面，是我現在經常以這種方式使用的：

index.html，用於輕量級靜態產物；

Storybook，用於審閱 UI 元件；

Remotion Studio，用於程式化動畫；

Slidev，用於簡報；

Streamlit，用於數據應用。

最小版本往往是最好的。你可以讓模型創建一個帶 JavaScript 和 CSS 的單檔 index.html，在側邊面板中打開它，然後立即開始互動。不需要伺服器。我一直在嘗試用 Heartbeats 隨時間更新一個靜態 index.html，這樣每次我回到線程時，已經有一個新鮮的產物在等著我。

Thariq 有一篇很好的文章，討論為什麼相比 Markdown，他更偏好 HTML 作為輸出格式。我認為這個直覺是對的。一旦輸出變成一個小型應用，而不只是一個文件，人與產物之間的關係就改變了。

如果我需要更重的東西，也可以用 Vite 應用，但那樣我就需要保持一個伺服器運行。一個純 index.html 要持久得多。

做動畫時，我經常把 Storybook 和 Remotion Studio 並排打開。我可以留下類似「讓這個彈一下」或「這個應該更大一點」的評論，而 Agent 可以檢查我正在看的同一個瀏覽器狀態，包括動畫中的當前幀。

在進行簡報時，我經常使用 Slidev。Codex 可以檢查投影片，發現被截斷的內容，在不同頁面之間切換，並在我審閱時回應註釋。

我也期待這種方式未來在 Streamlit 和 Jupyter 等工具中變得更有用。不同的人本來就生活在不同的應用程式中。Codex 正在越來越多地進入他們所在的地方。

Codex 越是擁有可以記憶、回訪、檢查和執行的地方，我的工作就越不容易死在一次次 prompt 之間。這才是我真正關心的變化：不是 Agent 能替我寫程式碼，而是當我離開之後，更多工作仍然可以繼續推進。

[原文連結]

歡迎加入律動 BlockBeats 官方社群：

Telegram 訂閱群：https://t.me/theblockbeats

Telegram 交流群：https://t.me/BlockBeats_App

Twitter 官方帳號：https://twitter.com/BlockBeatsAsia