AI 如何自主編碼、測試、最佳化？從獨立思考、到存取終端、最後改寫未來！
編譯 | Eric Harrington
出品丨AI 科技大本營（ID：rgznai100）
程式碼世界的下一個浪潮將由誰掀起？當 AI 不再僅僅是輔助工具，而是化身為能夠獨立思考、存取終端、甚至擁有「專屬電腦」的智慧體軟體工程師，軟體開發的未來圖景正被徹底改寫。從去年最早的 Devin 號稱「首個 AI 程式設計師」，GitHub Copilot 逐漸成為全球程式設計師的主流工具，今年 Cursor 的爆紅，再到前幾日 OpenAI 發布 Coding Agent 產品 Codex，這些幻想正在逐漸變為現實。
今日分享一篇知名 AI 工程師播客 Latent Space 的最新深度訪談，主持人邀請到了 Codex 團隊的核心成員 Josh Ma 與 Alexander Embiricos。
他們分享了 Codex 專案的緣起——從賦予模型存取終端權限帶來的「AGI 曙光乍現」時刻，到建構「智慧體軟體工程師」的宏偉藍圖。這場對話不僅揭示了 Codex 背後技術思考與產品哲學，更探討了人與 AI 結對程式設計的全新範式，以及開發者如何在這個智慧時代乘風破浪。
AI 正從輔助工具進化為能獨立思考、存取終端、擁有「專屬電腦」的智慧體軟體工程師，徹底改寫軟體開發未來。
賦予 AI 模型存取終端的權限，是 OpenAI 團隊初見「AGI 曙光乍現」的關鍵時刻，催生了為智慧體配備專屬電腦的構想。
OpenAI 核心成員預測，未來兩年內有望打造出能獨立完成軟體工程工作的「智慧體軟體工程師」。
Codex 不僅是編碼模型，更是擅長獨立完成軟體工程工作、能長時間自主工作的智慧體，追求「一次性搞定」複雜任務。
在 AI 時代，模型本身就是產品核心。未來模型將承擔更多決策，人類開發者則更聚焦於 AI 尚不擅長的架構設計與創新性工作。
以下為本次訪談的精彩內容：
主持人：今天的節目嘉賓是來自 ChatGPT Codex 團隊的 Josh Ma 與 Alexander Embiricos，我們和 Alexander 算是新相識，他一直在主導 Codex 的許多測試和演示工作。
Alexander：大家好，我是 Alexander，來自 OpenAI 的 ChatGPT Codex 產品團隊。
主持人：我們就默認讀者都看過 Codex 的發布直播了。你們當天還發了一篇博客，裡面有不少測試演示視頻，非常有意思。我注意到演示視頻裡，工程師們都是單打獨鬥，形單影隻，然後就對著他們的 AI 夥伴自言自語，一起寫程式碼。我不知道這是不是你們想營造的氛圍，但給我的感覺就是這樣。
Alexander：說得在理。那些視頻，我們追求的是極致的真實感，就是工程師本人講述 AI 如何助其一臂之力。這個反饋我收下了。
主持人：不過，這倒是實話。有時候，值夜班很孤獨，行動端開發也挺寂寞的，畢竟這類職位人不多。所以，完全理解。話說回來，你們各位具體都做了些什麼呢？或許我們可以從這裡開始。你們是怎麼被拉進這個專案的？後續又有哪些進展？
“人與 AI 結對程式設計，賦予模型存取終端的巨大價值”
Alexander：或許我先說吧，因為我們倆如何開始合作的，還有個挺有意思的故事。在加入 OpenAI 之前，我做了一款叫 Malti 的 macOS 原生軟體，專注於人與人之間的協作，算是一種結對程式設計工具。後來 ChatGPT 之類的東西火了，我們就開始琢磨，如果不再是人與人結對程式設計，而是人與 AI 結對程式設計，會怎麼樣呢？
所以，中間的曲折我就不細說了，總之就是這麼一段歷程，然後我們都加入了 OpenAI。我之前主要做桌面軟體。後來我們推出了推理模型。我相信你們在理解推理模型價值方面肯定遙遙領先，但對我而言，它一開始只是個更強大的聊天工具，可一旦你能給它工具，它就能真正化身為一個「智慧體」（agent）。所謂智慧體，就是一個配備了工具、擁有環境和安全邊界，並且可能針對特定任務進行過訓練的推理模型。
總之，我們對此產生了濃厚的興趣，並開始思考如何將推理模型引入桌面端。與此同時，OpenAI 內部也在進行大量實驗，嘗試賦予這些推理模型存取終端的權限。需要澄清的是，我並沒有參與最初的那些實驗，但那些實驗確實是我第一次真正感受到「AGI 曙光乍現」的時刻。那次經歷發生在我與一位名叫 David K 的設計師交談時，他當時在做一個叫 Scientist 的專案。他向我展示了一個它能自我更新的演示。放到現在，修改個背景顏色可能已經驚豔不到我們任何人了。
主持人：是指修改它自己的程式碼嗎？
Alexander：是的。而且，他們當時還設置了熱重載。我那時簡直驚呆了。時至今日，那依然是個超酷的演示。我們當時嘗試了很多類似的東西，我後來加入了其中一個正在搗鼓這個方向的小組。我們意識到，弄清楚如何賦予推理模型存取終端的能力，價值巨大。然後，我們就必須解決如何將其打造成有用的產品，以及如何確保其安全性的問題，對吧？你總不能讓它在你的本地檔案系統裡為所欲為，但人們最初確實是這麼嘗試使用的。
這些經驗很多最終演變成了最近發布的 Codex CLI。其中，我最引以為傲的思考是實現了諸如全自動模式之類的功能，並且在這種模式下，我們實際上增強了沙箱隔離，以確保用戶安全。
我們當時就在做這類事情，然後開始意識到，我們希望模型能有更長的「思考」時間，希望模型更大，希望模型能在無需任何審批的情況下安全地做更多事情。於是我們想，或許我們應該給模型一台它自己的電腦，給這個智慧體一台專屬電腦。與此同時，我們也在嘗試將 CLI 放入我們的持續整合（CI）流程中，讓它自動修復測試。我們還搞了個異想天開的破解方法，讓它能自動修復我們問題追蹤器 Linear 上的工單。就這樣，我們最終創建了這個名為 Codex 的專案，它的核心理念就是賦予智慧體存取電腦的能力。哎呀，我意識到我可能沒回答你問的我個人具體做了什麼，但無論如何，故事我是講完了，希望沒關係。
主持人：你已經巧妙地把個人經歷融入到宏大敘事中了，我相信 Josh 還有後續要補充。
“兩年內打造出智慧體軟體工程師！”
Josh：我的故事有些不同。我來 OpenAI 兩個月了，這是我人生中最有趣也最兵荒馬亂的兩個月。不過，或許我該從幾年前我創立的一家叫 Airplane 的公司說起。我們當時在建構一個內部工具平台，初衷是讓開發者能夠非常輕鬆地建構內部工具，並且真正深入開發者需求。這聽起來可能與現在做的沒什麼關聯，但很多方面，類似的主題又浮現了：本地開發的最佳形態是什麼？如何將工具部署到雲端？如何在雲端運行程式碼？如何將儲存、計算和使用者介面這些基礎模組組合起來，讓開發者能極速建構軟體？
我常開玩笑說我們只是早了兩年。專案快結束時，我們開始嘗試 GPT-3.5，想把它做得更酷。我們當時已經能很快地搭建一個 React 視圖了。我想如果我們繼續做下去，或許它就會演變成今天你看到的那些 AI 建構工具。但那家公司最終被 Airtable 收購了，我在那裡負責過一些 AI 工程團隊。
就我個人而言，今年年初，我目睹了我們在智慧體式軟體開發方面取得的進展。對我來說，那有點像我自己的「登月時刻」，我預感到這件大事即將發生。無論我是否參與其中，未來兩年內，我認為我們將打造出一個智慧體軟體工程師。於是，我找到了我在 OpenAI 的朋友，問他：「嘿，你們是不是在做類似的東西？」他瞪大了眼睛看著我，說：「我什麼都不能告訴你，但或許你可以和團隊聊聊。」
所以，非常幸運的是，當時 Alex 和 Foster 正好在啟動相關專案。我記得在面試時，我們就針對產品形態展開了激辯，對吧？它應該是命令列工具（CLI）嗎？這種形態的問題在於，等待它完成任務時無法時常打斷，而且你可能想同時運行四次、十次。或許就在那時我說，也許兩者兼備才好。我們現在也正朝著這個方向努力。總而言之，我當時非常激動，現在依然如此，致力於推動這個專案前進。我認為 Codex 還處於非常初級的階段。很高興能與世界分享它，但還有很多工作要做。
Alexander：我們第一次見面那場對話非常有趣。他一進來——我以前從未遇到過這種情況——就說：「世界正在發生這樣的變革，因此我想打造這樣的產品。我知道你不能確認你們是否在做這個，但這是我唯一想做的事情。」然後我問了幾個開放式問題，我們立刻就切入了一些關於工具形態的核心爭論點。我心想，太棒了，我們必須一起共事。
主持人：我想，開發者工具圈的人，彼此之間總能一眼認出同道中人。
說句題外話，蘋果早期的 iPhone 團隊也是這樣，因為團隊成員之間都不知道對方是否在同一個專案組，他們不被允許互相透露。所以他們只能靠「三角定位法」來判斷。
產品形態大討論：CLI 還是雲端？
主持人：談到產品形態，你們提到了已經發布的 CLI，我想市面上還有其他一些雲端程式碼工具，比如 Aider 等等。大家是否應該把 ChatGPT 中的 Codex 看作是一個託管版的 Codex CLI？兩者之間有顯著的區別嗎？我們來聊聊這個。
Alexander：你來吧。
Josh：我覺得，簡單來說，它就是允許你在 OpenAI 的雲端運行 Codex 智慧體。但我認為，產品形態遠不止是電腦在哪裡運行那麼簡單。它關乎如何與使用者介面結合，如何隨時間擴展，如何管理快取和權限，以及如何實現協作。所以，不知道你是否同意，但我認為產品形態才是核心。
Alexander：老實說，這是一段非常有趣的旅程。前幾天，也可能是昨晚吧，Josh 因為要做直播所以睡了，我不用。總之，我們幾個人回顧了當初規劃要發布什麼功能的文檔，結果發現我們的專案範圍不知不覺擴大不少。但實際上，所有這些範圍的增加都是順理成章的，因為我們越來越深入地認同這樣一個理念：這不僅僅是一個擅長編碼的模型，更是一個擅長獨立完成軟體工程工作的智慧體。我們越是深入這個理念，事情就越發顯得與眾不同。
所以，我們可以先把 Josh 負責的整個計算平台這個話題暫放一邊。單說模型本身，我們不只希望它擅長寫程式碼，也不只希望它能解決 SWeBench 上的任務。SWeBench，給不了解的朋友解釋一下，是一個評估基準，它有特定的方式來對輸出結果進行功能性評分。但如果你去看很多透過 SWeBench 測試的智慧體輸出，它們其實並不是你會合併到程式碼庫的 PR（程式碼合併請求），因為程式碼風格可能迥異。它能用，但風格不對。
因此，我們花了大量時間確保我們的模型非常擅長遵循指令，非常擅長推斷程式碼風格，這樣你就無需明確告知它。但即便如此，假設你拿到了一個程式碼風格良好、也很好地遵循了你指令的 PR，如果模型給出的關於它如何建構的描述冗長無比，這個 PR 可能依然很難合併。而且你很可能需要把它拉到本機電腦上測試更改，驗證其有效性。如果你只運行一個更改，這或許還能接受，但在我們設想的未來世界裡，大部分程式碼實際上可能都由我們委託的智慧體并行完成任務，那麼，作為人類開發者，能否輕鬆整合這些更改就變得至關重要。
舉個例子，我們開始訓練的另一項內容是 PR 描述。我們要真正把「寫出好的、簡潔的、能突出重點的 PR 描述」這件事做到極致。所以，我們的模型實際上會寫出漂亮簡短的 PR 描述，PR 標題也會符合你程式碼倉庫的格式。如果你願意，我們還提供了 agents.md 檔案，讓你可以更細緻地引導它。然後在 PR 描述中，它還會引用它在過程中找到的相關程式碼，或者其 PR 中的相關程式碼，這樣你滑鼠懸停就能看到。
或許我最喜歡的功能是我們處理測試的方式。模型會嘗試測試它的更改，然後會用一種非常友好的方式，就像打勾一樣，告訴你這些測試是否通過。同樣，如果測試通過，它會引用日誌中確定的參考資訊，讓你能夠看到並確信：「好的，我知道這個測試通過了。」如果測試失敗，它會說：「嘿，這個沒成功。我覺得你可能需要安裝 pnpm 之類的」，然後你可以查看日誌，找出問題所在。這些就是我們一直在努力的方向，基本上就是在雲端建構這個軟體工程師智慧體——哎呀，我好像忘了最初的問題是什麼了，但這些就是我們一直在深入鑽研的東西。
Josh：我也覺得感覺非常不一樣。你可以只看功能，但我認為，對我而言，那種感覺是，你得有「信仰之躍」。頭幾次用的時候，你會想：「我真不確定這玩意兒行不行。」然後它就跑了三十分鐘。但當它帶著結果回來時，你會驚嘆：「哇，這個智慧體居然出去了，寫了一堆程式碼，還寫了腳本來輔助程式碼修改它自己的改動，測試了這些，並且真正完整地思考了它想要做的變更。」一開始我完全不相信它能成功。但用過幾次之後，你會覺得：「哇，它居然真的搞定了！」那種長時間獨立工作的能力，很難用語言概括，你必須親自試試。但最終，它給人的感覺截然不同，非常特別。
主持人：我用過了。幾分鐘前我剛給它提了個 PR。我很幸運，是首批 25% 拿到內測資格的用戶之一。非常好用。不過它走了個捷徑，因為它搞不定怎麼在 Rails 環境下運行 RSpec，所以它就只檢查了 Ruby 檔案的語法，然後說：「我看挺好。」但我估計它還沒用上 agents.md。等我把那個配置好，應該就沒問題了。
從 agents.md 到“有意識的命名”
主持人：如果你能列舉一些最佳實踐，那就太好了。我從直播中注意到，他們提到專業用戶會安裝程式碼檢查工具（Linters）和格式化工具（Formatters），這樣智慧體在開發環中就能利用這些驗證器。事實證明，這些也是開發者的最佳實踐，但現在智慧體可以自動使用它們了。提交掛鉤（commit hooks）對人類來說一直是個棘手的問題，因為我待過的團隊裡，有的堅持所有東西都必須有提交掛鉤，也有的團隊覺得這玩意兒礙事，乾脆全刪了。但實際上，對於智慧體來說，提交掛鉤非常好用。
Josh：你把我接下來要說的話都說了。我想說的三點是：第一，agents.md。我們投入了大量精力確保智慧體能理解這種指令層級結構。你可以把它們放在子目錄裡，它能明白哪些指令有更高的優先級。而且，我們現在也開始用 GPT-3 和 GPT-4 來為我們編寫 agents.md 檔案了。
主持人：我喜歡這些技巧。你們實際上把這裡的提示描述開源了。
Josh：是的。
主持人：有什麼值得強調的嗎？
Josh：我覺得可以從簡單入手，別一開始就搞得太複雜。一個簡單的 agents.md 檔案就能帶來很大幫助，遠勝於沒有。然後就是在使用過程中慢慢學習。我們真正希望的是，未來能根據你創建的 PR 和你給出的反饋，自動為你生成這個檔案，但我們還是決定早點發布，而不是追求完美。
主持人：你提到你們也用 GPT-3、GPT-4 來編寫 agents.md。
Josh：我會把整個目錄都給它，然後說：「嘿，生成一個 agents.md。」實際上，這些天我都是用 Code One 來做這件事，哦抱歉，是 Codex One，因為它能遍歷你的目錄樹並生成這些檔案。所以，我建議逐步、漸進地投入到 agents.md 的建設中。然後，就像你說的，配置好最基礎的程式碼檢查和格式化工具。這其實能帶來相當大的收益，因為這和你用 VS Code 打開一個新專案時，能獲得一些開箱即用的檢查功能類似。智慧體一開始，如果比作人類的話，就像是缺少了這種優勢。所以，這樣做就是為了把這種優勢還給智慧體。
Alexander：關於這點我有個類比，然後我還想談談根據我們使用其他編碼智慧體，甚至是任何編碼智慧體的經驗，如何為此做好準備。我喜歡的那個類比是：如果你從一個基礎的推理模型開始，你得到的基本上是一個非常早慧、聰明絕頂、知識淵博，但又有點古靈精怪、天賦異稟的大學畢業生。我們都知道，如果你僱傭這樣的人，讓他們獨立完成軟體工程工作，他們會有很多實踐方面的東西不懂。
所以，我們用 Codex One 做的很多事情，基本上就是賦予它最初幾年的工作經驗。這實際上就是訓練的意義所在，讓它能更懂行。你想想看，寫一份好的 PR 描述就是一個典型的例子，甚至可能包括知道什麼不該寫進去。
然後，你就得到了這個：一個知識淵博得有些詭異、天賦異稟但又有點怪咖、同時擁有幾年工作經驗的大學畢業生。接著，每次你啟動一個任務，都像是它在你公司的第一天。所以，agents.md 基本上就是一種讓你壓縮它必須進行的「入職探索」時間的方法，讓它能了解更多。正如 Josh 所說，我們當然希望——目前它還是研究預覽版，所以你得自己更新——但我們有很多關於如何實現自動化的想法。這只是個有趣的類比。
Josh：或許我最後要說的一點是，讓你的程式碼庫易於被發現。這相當於為新員工維護良好的工程實踐，讓他們能更快地理解你的程式碼庫。我的很多提示都是以「我正在這個子目錄下工作，我想完成這個，能幫我做一下嗎？」這樣的方式開始的。所以，給出這種指導和範圍限定很有幫助。Alexander：我通常會給出三點建議。首先，語言選擇。前幾天我和一個朋友聊天，他算是 AI 領域的後來者，他說：「我想嘗試做一個智慧體產品，我應該用 JavaScript 嗎？」我回答說：「你還在用 JavaScript？難怪了。至少用 TypeScript 吧，給它點類型資訊。」所以，我覺得這是最基本的一點。我相信現在聽我們播客的各位應該不需要我再強調這個了。
另一個是，讓你的程式碼模組化。程式碼越模組化、越容易測試，效果就越好。你甚至不需要自己寫測試，智慧體可以寫，但你得把架構設計得模組化。我最近看到這裡有個人做的一個演示，他基本上——他不是那種憑感覺寫程式碼的，而是專業的軟體工程師——但他在用 Codex 這樣的工具建構一個新系統。他從零開始建構這個系統，有一張圖表顯示了他的程式碼提交速度。然後他的系統有了一定的用戶量，於是就到了「現在我們要把它移植到 ChatGPT 那個龐大的單體程式碼庫裡」的階段，那個程式碼庫經歷了瘋狂的超高速增長，所以可能在架構規劃上不是那麼盡善盡美。結果，同樣一個工程師，用著同樣的工具，甚至 AI 工具還在不斷進步，他的程式碼提交速率卻直線下降。
所以，我認為另一個就是，架構，好的架構比以往任何時候都更加重要。而且有趣的是，目前這還是人類真正擅長的事情。所以，這對軟體工程師做好本職工作來說，挺好也挺重要的。
主持人：千萬別看我的程式碼庫。
Alexander：那我的程式碼庫就更不能看了。但最後一點是個有趣的故事：我們專案的內部代號是 Wham，WHAM。我們選它的時候，我和我們的研究負責人一起，他說：「嘿，選代號之前，記得先在程式碼庫裡搜一下（grep）。」於是，我們搜索了程式碼庫，「Wham」這個字串只出現在少數幾個更長的字串裡，從來沒有單獨作為字串出現過。這意味著，我們寫提示的時候可以非常高效，可以直接說「在 Wham 裡」。然後，無論是我們 Web 程式碼庫、伺服器程式碼庫、共享類型還是其他任何地方的 Wham 程式碼，智慧體都能高效找到。反過來，如果我們當初把產品命名為 ChatGPT Code——不是說沒考慮過啊——那智慧體就很難搞清楚我們想讓它去哪裡找了，我們可能就得提供更多相對檔案夾路徑。所以，當你開始前瞻性地思考：我將來會有一個智慧體，它會用終端來搜索，那麼你就可以開始有意識地命名了。
主持人：你們會開始為了方便智慧體理解而犧牲一些人類可讀性來命名嗎？在你看來，這其中的權衡是什麼？
Josh：這很有意思，因為我剛加入 OpenAI 時，確實帶著一些先入為主看法，但我現在認為，這兩個系統（人類可讀性與智慧體可讀性）實際上是高度趨同的。也許是因為只要你看到人類和 AI 都在編寫它。或許在某個只有 AI 維護程式碼庫的世界裡，假設會改變。但一旦你不得不打破那「第四堵牆」，讓人類介入進行程式碼審查、部署程式碼，你就需要程式碼處處都帶有人類的印記。所以，人類如何向 AI 傳達要在哪裡修改，如何傳達需要修復的 bug，或者如何傳達業務需求，所有這些都不會立刻消失。因此，我認為整個系統實際上仍然非常「人性化」。我知道或許可以說一些更酷的答案，比如它像個外星生物，完全不同，但我認為這些東西始於大型語言模型，其根基深植於人類的交流方式。
Alexander：順便說一句，如果你們想轉換話題，儘管打斷我們，因為我意識到我們倆自顧自聊開了。
agents.md vs. readme.md
主持人：不，我覺得這也和 agents.md 有關。為什麼叫 agents.md 而不是 readme.md？我想在你們看來，智慧體和人類消費資訊的方式存在某些根本性的差異。所以我很好奇，你們認為這種差異是在類命名層面，還是僅僅在指令層面，或者說，界限在哪裡？
Josh：你說吧。
Alexander：這個命名，我們考慮過幾個選項。你可以用 readme.md，也可以用 contributors.md。你還可以用 Codex agent.md，然後可能再來個 Codex CLI.md，作為兩個帶品牌標識的獨立檔案。
主持人：還有像 cursor.rules，Witserf rules，每家都有自己的規則檔案。
Alexander：然後你還可以選擇 agents.md。這裡有幾個權衡點。我想一個是開放性，另一個大概是特異性。所以我們考慮的是，嗯，可能有些東西你想告訴智慧體，但不需要告訴貢獻者。同樣，有些東西你想告訴貢獻者，以便真正幫助他們在你的程式碼庫中進行設置等等，這些則不需要告訴智慧體，智慧體自己就能搞定。所以我們想，這兩者可能會有所不同，而且智慧體反正也會讀取你的 readme，那麼 agents.md 可能就用來存放那些你需要告訴智慧體、但它無法從 readme 中自動獲取的資訊。於是我們就做了這個決定。
然後我們又考慮，智慧體有不同的形態。我們正在建構和發布的這個東西，最特別之處在於它提供了一種開箱即用的方式來使用雲端智慧體，這種智慧體可以并行處理許多任務，可以進行長時間思考，並且可以安全地使用大量工具。於是我們想，那麼，你想給這種智慧體下達的指令集，與你在本地電腦上更具協作性地使用的智慧體所需的指令集，兩者之間到底有多大區別呢？老實說，我們對此進行了相當多的討論。最終我們得出結論，這些指令集之間的差異其實並沒有大到需要為這個檔案設定命名空間的程度。如果確實有什麼需要區分命名空間，你大概可以直接在檔案裡用自然語言說明。
最後我們考慮的是，我們認為你需要給我們的智慧體下達的指令，與你可能給運行在不同模型上或由不同公司建構的智慧體下達的指令，兩者之間的差異有多大？我們只是覺得，如果你必須創建所有這些不同的智慧體檔案什麼的，那體驗會很糟糕。這也是為什麼我們把 Codex CLI 開源的部分原因；很多問題，比如如何安全部署這些東西所涉及的安全問題，都需要解決，而且不應該讓每個人都重複造輪子。所以，這就是我們選擇一個不帶品牌名稱的原因。
Josh：我有一個具體的例子來說明為什麼 readme 和 agent.md 是不同的。對於智慧體，我認為你其實不必告訴它程式碼風格。它會查看你的程式碼庫，然後寫出與之風格一致的程式碼。而人類開發者則不會花時間去通讀程式碼庫並遵循所有約定。這只是一個例子；歸根結底，這兩種「開發者」處理問題的方式是有區別的。
模型即產品？
主持人：我覺得這些建議非常棒。你們剛才說的內容，簡直就是我們這期播客的標題了。我們就叫它「使用 ChatGPT Codex 的最佳實踐」，我想大家肯定都想知道最佳實踐是什麼。
我注意到一個很有意思的現象。在建構智慧體方面，似乎總有兩種思路。一種是試圖更強地控制，讓它更具確定性。另一種則是嘗試直接給提示，然後信任模型。我覺得你們的方法非常傾向於「提示並信任模型」。我看到在 agents.md 的系統提示裡，你們只是提示它按照你們期望的方式行事，然後就指望模型能那樣做。當然，你們能控制模型，所以如果它表現不好，你們可以訓練它。但有一點讓我疑惑的是，你們如何把所有東西都放進上下文裡？如果我的 agents.md 檔案超級長怎麼辦？在你們的直播演示中，你們是在 OpenAI 的那個巨大的單一程式碼庫（monorepo）上進行的。那麼，你們是如何管理快取、上下文窗口這些東西的呢？
Josh：如果我現在告訴你，所有東西都還能塞進上下文窗口，你信嗎？
主持人：OpenAI 的程式碼庫可不行吧。
Josh：不，是智慧體需要的所有東西。
主持人：哦，明白了。所以你們會精簡 agents.md，然後把它放在最前面？就像另一個系統提示一樣。
Josh：不，它是一個檔案，智慧體知道如何去搜索（grep）、查找並讀入上下文，因為可能會有多個這樣的檔案。你其實可以在工作日誌裡看到，它會非常積極地尋找 agents.md。它是被訓練成這樣做的。
我要說的是，加入 OpenAI 之後，我發現當你在思考模型的未來走向以及幾年後 AI 產品會是什麼樣子時，你會用一種不同的方式來設計產品，這真的很有意思。在加入 OpenAI 之前，尤其是當你沒有研究團隊和大量 GPU 資源的時候，你會建構這些確定性的程序，圍繞它的運作方式搭建很多腳手架。但你並沒有真正讓模型發揮其全部潛能。
我剛加入時有個有趣的現象，我經常受到質疑：「嘿，我們為什麼不直接把這個硬編碼進去？聽著，你老是用錯這個工具，我們就在提示裡說『別那麼做』不就行了。」然後研究員們會說：「不不不，我們不那麼做。我們要用正確的方式來做。我們要教會模型為什麼這樣做才是對的。」我覺得這與一個更宏觀的思考有關，那就是：你應該在哪裡設置確定性的「護欄」，又在哪裡真正讓模型去「思考」。
關於規劃階段也是類似的討論。我們是否應該設置一個明確的規劃階段，比如讓它「先大聲思考，寫下你要做什麼，然後再去做」？當然可以，但如果任務很簡單呢？你真的希望它一直思考嗎？如果它在執行過程中需要重新規劃呢？你是否要為此設置各種 if-else 條件和啟發式規則？還是說，你應該訓練一個非常優秀的模型，讓它知道如何在這些思考模式之間切換？所以，這很難。我確實也曾主張在下一次訓練完成之前，設置一些小小的「護欄」。但我認為，我們真正為之建構的是一個未來——在這個未來裡，模型能夠做出所有這些決策。真正重要的是，你為它提供了正確的工具：管理上下文、管理記憶、探索程式碼庫的方法。這些仍然非常重要。
Alexander：是的，說得太好了。我覺得在這裡做產品非常有趣，也很不一樣。模型並非產品的全部，但模型就是產品本身。你多少需要帶著一種謙遜的態度去思考：這裡有三方，有用戶，有開發者，或許還有模型。哪些事情是用戶一開始就需要決定的？然後，哪些事情是我們開發者能比模型做出更好決定的？再然後，哪些事情是模型本身能做出最佳決定的？每一個決策都必須歸於這三者之一。
並非所有事情都由模型決定。例如，我們目前在使用者介面上有兩個按鈕：「提問」和「編碼」。這兩個功能或許可以內聯到模型做出的決策中。但目前來看，一開始就給用戶選擇權是非常合理的，因為我們會根據用戶按下的按鈕，首先為模型啟動一個不同的容器。所以，如果你要求編碼，我們會把所有依賴項都放進去——我這裡簡化了說法。但如果你不要求編碼，只是提問，我們會在模型獲得任何選擇權之前，進行一個快得多的容器設置。所以，這或許是一個用戶決策。
在某些方面，用戶和開發者的決策會在環境層面交匯。但最終，我看到的很多智慧體都令人印象深刻，但其令人印象深刻的部分原因在於，是一群開發者圍繞著一系列簡短的模型調用，建構了一個非常客製化的狀態機。這樣一來，模型能夠解決的問題複雜度的上限，實際上就受限於開發者大腦能容納的程度。而我們希望，隨著時間的推移，這些模型能夠獨立解決越來越複雜的單個任務，應對越來越複雜的問題。最終，你甚至可以想像一個由智慧體組成的團隊協同工作，或許還有一個智慧體來管理這些智慧體。那樣的話，複雜度就會爆炸式增長。
所以，我們真心希望將盡可能多的複雜性，盡可能多的狀態機，都推給模型去處理。於是，你就得到了這兩種建構模式。一方面，你在建構產品使用者介面和規則。另一方面，你仍然需要做工作來讓模型學習某些東西，但你需要做的是弄清楚，這個模型在訓練過程中需要看到哪些正確的東西才能學會。所以，要實現這種改變，仍然需要大量的人力投入，但這是一種截然不同的思考方式：我們要讓模型看到這個。
“編碼” vs “提問”
主持人：但是你們如何建構產品來獲取這些信號呢？如果想想「編碼」和「提問」這兩個按鈕，這幾乎是讓用戶在某種程度上標記提示——因為他們說「提問」，這就是一個提問提示；說「編碼」，這就是一個編碼提示。在你們建構這個產品的過程中，還有其他什麼有趣的產品設計，是基於「我們認為模型可以學習這個，但我們沒有數據，所以我們這樣設計 Codex 來幫助我們收集數據」這種思路的嗎？
Josh：檔案上下文和範圍限定，我們目前還沒有很好的內建功能，但這是我們顯然需要添加的功能之一。這也是這類情況的另一個例子。你可能會，我們通常會驚喜地發現，「哦，它居然找到了我正在想的那個確切檔案」，但這需要一些時間。所以很多時候，你會透過直接說「嘿，我正在這個目錄裡找，你能幫我找點東西嗎？」來縮短一連串的思考過程。所以我認為，在擁有更好的架構化索引和搜索能力之前，這種情況可能會持續一段時間。
主持人：好的，酷。關於 Codex 本身，我們還有幾個事實性問題需要收尾，然後我們想深入探討一下計算平台方面的事情，我想 Josh 你更想多談談這個。我注意到細節裡提到，任務時長在 1 到 30 分鐘之間。這是一個硬性限制嗎？你們有沒有遇到過任務時長更久的情況？對任務時長有什麼評論嗎？
Josh：我在來之前剛查過程式碼庫。其他人也有類似的問題。我們目前的硬性上限是一小時。不過，別太當真，這個隨時可能調整。我見過最長的是兩小時，那是在開發模式下，模型完全失控了。所以，我認為 30 分鐘對於我們試圖解決的這類任務來說，是一個合理的範圍。這些都是硬骨頭任務，需要大量的疊代和測試，模型需要這段時間來思考。
Alexander：我們的平均時長遠低於 30 分鐘，但如果你給它一個艱鉅的任務，確實會耗到 30 分鐘。
主持人：我覺得這裡有幾個可以類比的。一是 Operator 團隊跑過一個基準測試，他們不得不把上限設在兩小時。另一個是 Metr 那篇論文，不知道流傳開沒有，他們估計目前平均的自主運行時間大概是一小時，而且可能每七個月翻一番。所以一小時聽起來差不多，但那也是中位數，所以肯定會有一些任務超過這個時間。
Alexander：完全正確。
主持人：SWeBench 驗證過的例子裡，有 23 個無法運行，這和時長限制有關嗎？還是其他原因？
Alexander：老實說，我不太確定，但我感覺 SWeBench 的一些案例本身，說它們無效可能有點過，但我覺得它們在運行時確實存在一些問題，所以就是跑不起來。
主持人：好的。那麼最大並發數呢？有並發限制嗎？如果我同時運行 5 個、10 個、100 個 Codex 實例呢？
Alexander：5 個、10 個完全沒問題。實際上我們感覺確實為了防止濫用而設置了一個上限。具體是多少，我不清楚。
Josh：我印象中目前是每小時 60 個。
主持人：每分鐘一個。
Josh：但是，聽著，這正是關鍵所在。長遠來看，我們其實不希望你費心去想你是在委派任務給 AI 還是與 AI 協作。想像一下一個 AGI 超級助手，你只管提問，只管和它說話，它就能把事情搞定。需要快速回答時它就快，需要長時間思考時它就慢慢來。而且你也不必只和它對話，它也融入在你的各種工具裡。這是長遠的目標。但短期內，它是一個你用來委派任務的工具。
我們觀察到的最佳使用方式——回到我們這期播客可能的主題「最佳實踐」上來——是你必須抱有「豐足心態」，並且要把它看作是幫你探索事物，而不是消耗你的時間。所以，通常當一個智慧體要在你的電腦上工作時，你會非常仔細地斟酌提示，因為它會佔用你的電腦一段時間，你可能無法做別的事情。但我們看到那些最愛用 Codex 的人，他們並不會這樣；他們思考提示的時間最多也就 30 秒。就是那種：「哦，我有個想法，走起！」「哦，我想做這個，搞定！」「哦，我剛看到這個 bug 或者這個客戶反饋」，然後你就把任務發出去了。所以，你并行運行的任務越多，我們其實越開心，我們也認為用戶看到這種情況會越滿意。這就是這個產品的調性。
主持人：我也分享下我的親身經歷。我曾是這個專案的受信測試員之一，你們倆都很清楚。後來我發現我用錯了方法。我把它當 Cursor 用了，開著聊天窗口，看著它寫程式碼。然後我才意識到，我不該這麼做。我恍然大悟：「哦，你們都是直接把任務扔出去，然後就忙自己的事去了。」這確實是個思維方式的轉變。
Alexander：快速補充一點，我會盡量簡短。一個很有趣的用法是在手機上使用它，因為不知為何，在手機上操作會改變人們的思考方式。所以我們把網站做成了響應式的，最終也會把它整合到 App 裡。試試看，真的非常有趣和令人滿意。
主持人：所以這和其中一個視頻裡展示的行動端工程師在手機上用它程式設計不一樣，它目前還不能在 ChatGPT 的 App 裡用。
Alexander：暫時還不行。
主持人：我從行動端收到的通知有個問題。當它開始任務時，會顯示「開始研究」，和深度研究的通知一樣。它是把深度研究作為一個工具來用了，還是你們只是複用了同一個通知？
Alexander：我們只是用了同一個通知。
智慧體能存取什麼？安全邊界在哪？
主持人：你們提到了計算平台，也提到了你們和強化學習（RL）共享了一些基礎設施。能不能給聽眾們大致介紹一下 Codex 能存取什麼，不能存取什麼？看起來用戶似乎不能自己運行命令，只能指示模型去做。還有其他需要注意的事項嗎？
Josh：這是一個持續演進的討論，我們仍在探索哪些部分可以開放給用戶和智慧體存取，哪些部分目前需要保留。所以我們還在學習，並且非常希望能和人類用戶及智慧體共享盡可能多的存取權限，當然，前提是符合安全和安保的約束。
目前你能做的是，作為人類用戶，設置環境，設置運行腳本。這些腳本通常是為了安裝依賴，我預計這大概會佔到 95% 的使用場景。目的就是把所有正確的二進制檔案準備好，供你的智慧體使用。我們其實也提供了一些環境編輯的體驗，人類用戶可以進入一個互動式直譯器（REPL），嘗試一些東西。所以，請不要濫用它，但你確實有辦法在那裡與環境互動。
Alexander：我們本來沒打算做一個能互動式更新環境的 REPL，但我們試了。Josh 說：「天啊，我們太需要這個了」，所以這就是一個範圍蔓延的例子。感謝你把它做出來了。
Josh：我們確實設置了速率限制，並且會非常仔細地監控。但那裡確實有一些互動式的功能來幫助你上手。一旦智慧體開始運行，我們目前實際做的是——並且希望在這方面有所改進——我們會切斷網際網路存取。因為我們仍然不完全清楚，讓一個智慧體在其自身環境中自由活動會帶來什麼後果。目前為止，所有的安全測試都非常嚴格地表明，它不容易受到某些針對提示注入的竊取企圖的影響，但這個領域仍然存在很多風險，所以我們還不確定。這就是為什麼我們一開始採取了更保守的策略，當智慧體運行時，它沒有完整的網路存取權限。
但我很希望能改變這一點：允許它有限度地存取，比如特定的網域名稱或特定的程式碼倉庫。總而言之，隨著我們建構出支持這些功能的正確系統，這一點也在不斷發展。不確定這是否完全回答了你最初的問題。
不過，我最後還想提一點，就是互動性方面的問題。當智慧體在運行時，有時你會想：「哦，我想糾正它一下，讓它去別的地方」，或者「讓我來填補這部分，然後你再接手」。這些問題我們也還沒有完全解決。我們真正想從一開始就追求的是那種完全獨立、一次性就能交付巨大價值的模式。但我們肯定在思考如何更好地將人類和智慧體結合起來。
主持人：說句公道話，我覺得「一次性搞定」這個角度很好，其他人在拿你們和 Devin、Factory 以及其他競品比較。他們更側重於多次人工反饋。我手頭有個網站正在開發，我給它提了個需求，然後和其他工具都對比了一下，這就是我對 Codex 的測試。它確實一次性搞定了。
這真的非常棒，尤其是當你同時運行 60 個任務的時候。所以我認為這很有道理。但這確實是一個非常宏大的目標，因為人類反饋是我們樂於依賴的「拐杖」。這也迫使我們寫更多測試，這挺煩人的，因為我不喜歡寫測試，但現在我不得不寫了。幸運的是，我現在可以讓 Codex 幫我寫測試了。我還特別喜歡直播裡演示的，你可以直接讓它看你的程式碼庫，然後建議你做些什麼，因為我連想該做什麼的精力都沒有了。
Alexander：授權他人進行授權，我覺得這話說得很好。需要明確的是，我們並不是說某種形態就一定比其他形態更好。我非常喜歡用 Codex CLI，而且我們真正想要的，就像我在 OpenAI 面試時我們聊到的那樣，是兩種模式兼備。但我認為，Codex 在這裡扮演的角色，是真正推動那個「一次性搞定」的自主軟體工程師的邊界。
是的，我有點把這次研究預覽版看作是我們的一個思想實驗。它就像是在探索：一個編碼智慧體，在它最純粹、最能體現 AGI 潛力或規模效應的形態下，會是什麼樣子？然後或許，對我個人而言，在 OpenAI 工作令我興奮的部分原因，不僅僅是為開發者解決問題，更是真正思考 AGI 如何造福全人類，以及非開發者對此會有怎樣的感受。所以，對我來說，真正有趣的是將 Codex 視為一個實驗，看看在其他職能部門工作會是什麼感覺。我為之奮鬥的目標是這樣一個願景：我們做那些模棱兩可、富有創造性或難以自動化的工作，但除此之外，我們把大部分工作都委託給智慧體。而這些智慧體，它們不是那種遙不可及的未來產物，也不是曇花一現的短期工具，而是無處不在、隨時伴你左右的。所以，我們決定從最純粹的形式開始，我們原以為這會是發布範圍最小的東西，但事實可能並非如此。不過，我們最終會將這些不同的東西整合起來。
邁向 AGI 超級助手
主持人：好的，我想我們還有時間問幾個問題。我們再深入聊聊這個研究預覽版。它為什麼是「研究預覽版」？還有哪些不足？你們認為達到什麼標準才能算作正式發布？在直播中，Greg 提到了雲端和 CLI 之間的無縫過渡。是這個原因，還是你們有其他的考慮？
Alexander：老實說，我們之所以如此堅信疊代部署，部分原因在於——我現在可以分享一些我的想法，但我們也真的很好奇最終會怎樣。因為這是一種全新的產品形態。但我目前最關注的幾點包括多模態輸入，我們之前也討論過。
主持人：我知道你喜歡那個。
Alexander：另一個例子是，再給它多一點接觸外部世界的權限。很多人都要求各種形式的網路存取。我還認為，我們目前發布的使用者介面，實際上是我們疊代過的一個版本。這裡面有個有趣的故事，但總的來說，這是一個人們覺得有用的介面，但它肯定不是最終形態，我們非常希望它能更緊密地融入開發者日常使用的工具中。這些是我們正在思考的一些主題。但需要明確的是，我們會不斷疊代並找出答案。
主持人：我擔心的是它正式發布後的定價，但我現在會好好利用這個免費期。何樂而不為呢？
Alexander：關於定價，也請給我們反饋。
主持人：現在談定價是不是太早了？
Alexander：是的，現在還太早。
主持人：好吧。參考 Claude Code 的情況，這確實是大家擔心的一點。Claude 已經開始引入一些固定定價和變動定價了，我覺得這搞得一團糟。沒有標準答案。每個人都只想要他們能得到的最便宜的程式碼處理能力。所以，祝你們好運。
Alexander：謝謝。
Josh：我的看法是，我們的目標是交付巨大的價值，而我們有責任去展示這一點，並真正讓人們意識到：「哇，這東西在為我做非常有經濟價值的工作。」我認為很多定價問題都可以從這一點出發。但我覺對話應該從這裡開始：我們是否真的在交付那種價值？
主持人：太棒了。好吧。非常感謝你們。感謝你們的努力，也感謝你們抽出時間。這一天我們等了很久，但我想大家開始看到，OpenAI 整體上對智慧體越來越認真了。這不僅僅是編碼，但編碼顯然是一個自我加速的閉環，我想你們對此也充滿熱情。看到這些真的很鼓舞人心。
Alexander：非常高興能把這個編碼智慧體帶給大家，並最終將它融入通用的 AGI 超級助手中。感謝邀請我們。
原播客鏈接：https://open.spotify.com/episode/7soF0g9cHqxKaQWWJBtKRI