編輯｜雲昭
相信大家都能感覺到，進入2月以來，「上下文工程」、「Vibe Coding」的熱度已經讓位給了一個新名詞：「harness engineering」。
而將這個名詞帶火的，正是OpenAI Frontier團隊的核心工程師Ryan Lopopolo。
他最近發表了一篇長文，成為了熱門話題，堪稱「harness工程」的定義之作。
在這篇文章中，Ryan揭示了新成立的OpenAI Frontier團隊已經成為OpenAI最大的Codex用戶。整個團隊最開始只有3個人，歷經5個月的極端實驗，最後可以運行著100萬行程式碼的程式庫，其中零行是人類編寫的程式碼。
同時，更讓「黑暗工廠」粉絲著迷的是，整個程式庫在合併之前，完全沒有人類審查程式碼。
那麼，OpenAI Frontier團隊究竟是如何透過「Harness工程」實現0手工程式碼的呢？
就在昨天，Ryan終於出來深度爆料OpenAI這個神秘計畫了！
在昨天最新一期的Latent Space播客訪談中，Ryan表示，實現這個「幽靈庫」Symphony的核心秘訣，就在於：當AI失敗時，不要上來就想著改提示詞，而是問：缺少什麼能力、上下文或結構？
因此，最後的結果就是，這個「幽靈庫」本身不包含任何實際程式碼，但卻提供了讓AI agent自主生成100萬行程式碼所需的所有上下文、規範和工作流程。這種思維轉變讓他們將開發速度提升了10倍，甚至團隊都可以不再審查程式碼，AI寫完就可以直接合併了。
當然，播客中還詳細討論了這個幽靈庫的七層架構設計。感興趣的朋友可以向下翻看。這裡不再贅述。值得關注的是，Ryan個人對MCP持悲觀態度：它已經死了！
因為它會強制往上下文裡注入大量token，還會影響自動壓縮（autocompaction），甚至agent可能忘記怎麼用這些工具。
此外，Ryan作為OpenAI最新成立的團隊的核心工程師，還給出了不少對於未來軟體嚴謹的判斷。
首先，Ryan認為，未來的軟體必須首先對Agent可讀。「如果軟體充滿了隱性上下文，Agent就無法有效工作。」
那怎麼判斷這種可讀性呢？
Ryan透露到，為了追求極致的內循環速度，Ryan的團隊強制實施了「一分鐘建構紀律」。如果建構時間超過一分鐘，他們就會介入重構，以確保Agent的反饋迴路足夠短。在這種模式下，程式碼變得高度模組化、可觀測且「token高效」。
而這也意味著，原有的軟體開發範式中的許多環節和名詞都發生變化。比如，Ryan指出，開源軟體的依賴可能會消失。因為在他看來，幾千行程式碼的中低等複雜度軟體，已經完全可以讓AI來重寫，被模型內化。
再比如，我們原來定義的軟體BUG也會重新定義。Agent時代之下，「BUG就是agent編寫的、由於某個尚未寫下來的非功能性需求而不一致的程式碼。」
再比如，傳統的MVC模式也重新發生了定義，AI原生版本是Model-View-Claw——Claw就是harness。
其次，值得一提的是，OpenAI這種「AI原生」的開發過程也充滿著「幽默感」。
Ryan爆料，「幽默是AGI的一部分。」他們甚至會教Agent理解公司文化，包括生成迷因圖、和Slack互動等等。在他們看來，幽默感是智慧的重要測試指標，而最新的5.4模型在「玩梗」方面，已經表現得很驚人了。
另一個相信大家跟小編一樣好奇的是，OpenAI這個新團隊Frontier究竟想幹嘛？OpenAI這是要往to B賽道上重倉了嗎？
Ryan也很坦誠地將這個團隊的「陽謀」分享了出來。Ryan表示，Frontier最終的願景是：幫助企業安全、大規模地部署Agent。而這個產品本質是一個「分發Spec」的系統，既能介入企業IM、又能整合安全工具、又能接入工作流程工具。
Ryan還透露，Codex應用的週活躍用戶已經突破了200萬，並正在以每週25%的速度成長。這一數字，也能看出OpenAI想要在to B賽道上轉變為一個真正賦能全球企業的AI原生平台的野心。
此外，主持人還觀察到了OpenAI的一個重要擴張訊號：「去舊金山中心化」。Ryan對此解釋到，OpenAI的確正在擴張到西雅圖、紐約、倫敦。「我認識有人因為不想搬去舊金山而拒絕了OpenAI的工作，」Ryan調侃到，「現在他們別無選擇了。」
而Ryan自己也正是西雅圖辦公室的首批工程招募之一，那裡有「瘋狂風格的辦公室氛圍」，而貝爾維尤的新辦公室則是「非常綠，金色裝置，非常有太平洋西北」。
很明顯，這個新設立的西雅圖貝爾維尤辦公室正成為OpenAI這一to B願景的重要支點。
另外，還值得一提的是，現在Ryan表示自己對於目前這種「harness工程」已經上癮了。他承認自己已經餵Agent餵到不可自拔，甚至在飛機上半扣上筆記型電腦寫程式碼。
「很難停止戳機器，因為它讓我想餵它。這種持續反饋循環，看著AI自主工作、不斷生成程式碼，似乎有一種特殊的吸引力。」
Ryan甚至給出了一個驚人的數字：團隊每天使用10億個token（約合2000-3000美元）。他說，如果你不這樣做，就是「疏忽」。吝嗇token，就是吝嗇效率。
篇幅關係，這裡不再一一展開了，整體感受，又是一場阿爾法含量超標的分享。
以下是小編梳理的精彩觀點。
Harness工程定義之作
主持人：
好，現在進入正題。我們現在在錄音室裡，和來自OpenAI的Ryan Lopopolo一起。歡迎你。謝謝你來舊金山，也謝謝你抽時間參與我們節目。你寫了一篇關於harness engineering的爆文，很可能會成為這個新興領域的定義性作品。
Ryan Lopopolo：謝謝，這件事其實挺有意思的——在某種程度上感覺我們定義了這個領域的討論方式。
主持人：我們先補充一點背景資訊。這是你第一次上播客，對吧？那能不能講講你的背景？你在哪個團隊？大概做什麼？
Ryan Lopopolo：我在OpenAI的Frontier團隊，主要做前沿產品探索和新產品開發。Frontier是一個企業平台，核心是讓agent能在企業中安全、大規模地部署，並具備良好的治理能力。我和團隊的職責是，探索如何把模型打包成產品，並以解決方案的形式賣給企業客戶。
主持人：我補充一下你的履歷：Snowflake、Stripe、Citadel，對吧？
Ryan Lopopolo：對，基本都是同一類客戶。
主持人：但我一開始其實沒想到你是這個背景。我看你Twitter的時候，感覺完全相反——全是那種「全力以赴AI coding」的風格，比如把電腦綁在Waymo上之類的內容。然後再看你的履歷，就發現你在傳統企業環境裡也非常「正經」。是一個很有意思的組合。
Ryan Lopopolo：哈哈，做一個「AI最大化主義者」其實挺有趣的。如果你要活成這種人設，那OpenAI是最適合的地方。而且內部沒有速率限制，我可以像你說的那樣「全力衝刺」。
主持人：所以你是在Frontier團隊裡的一個「特種小組」。
Ryan Lopopolo：對，我們被給予了一定的自由空間去嘗試，這也是為什麼我一開始設定了一個比較極端的約束：完全不自己寫程式碼。我的想法是，如果我們要構建可以部署到企業裡的agent，那它們就應該能完成我能做的所有事情。在過去6到8個月裡使用這些coding模型和harness，我確實覺得模型能力已經足夠，harness也足夠成熟，在能力上幾乎和我是同構的。所以我從「不寫程式碼」這個約束出發，逼自己必須透過agent來完成工作。
基本架構思路：模型做不了的任務就拆分
目標：建構時間壓縮到1分鐘
主持人：簡單說一下背景，這其實就是你那篇文章的核心內容：你們花了5個月開發一個內部工具，自己寫的程式碼是0行，但最終程式庫超過100萬行，而且你說效率比人工快了10倍。
Ryan Lopopolo：對，這基本就是當時的思路。一開始我們用的是很早期的Codex CLI和Codeex mini模型，那時候模型能力比現在弱很多。但這反而是個好約束。當你讓模型幫你實現一個功能，它卻拼不起來的時候，這種挫折感非常真實。於是我們形成了一個方法論：當模型做不了的時候，就把任務拆開，構建更小的模組，然後再組合成大的目標。說實話，最開始的一個半月效率非常低，大概是我手寫程式碼的10倍慢。但正是因為付出了這個成本，我們最終構建出了一個「裝配線」，讓agent能完成整套開發流程，效率超過任何一個工程師。
後來我們經歷了GPT-5.1、5.2、5.3、5.4等多個模型版本，每一代模型的行為方式都不同，我們也不得不調整程式庫來適配模型的變化。比如一個很有意思的點是：在5.2時，Codex harness還沒有後台shell，所以我們可以依賴阻塞腳本來執行長任務。但到了5.3，有了後台shell，模型反而變得更不「耐心」，不願意等待阻塞任務。所以我們不得不重構整個建構系統，把建構時間壓縮到1分鐘以內。在一個多人協作、有各種意見的程式庫裡，這幾乎是不可能的。但因為我們的唯一目標是讓agent高效運行，我們在一週內從Makefile切換到Bazel，再到Turbo，再到NX，最終停在NX，因為建構速度已經足夠快。
主持人：你從Turbo切到NX，這很有意思，很多人是反過來的。
Ryan Lopopolo：老實說，我對前端倉庫架構經驗不多。你可以跟Josh聊這個，他才是搭這個系統的人。我認識NX團隊，也了解Turbo（來自Jared Palmer），所以對比很有意思。但我們的核心目標其實很簡單：讓建構變快。我們的應用是一個React + Electron的單體應用，要求建構時間必須控制在1分鐘以內。
主持人：我對「後台shell」其實不太熟。
Ryan Lopopolo：簡單說，就是Codex可以在後台啟動任務，然後繼續做其他事情，比如一邊跑建構，一邊審查程式碼。這可以提高整體時間效率。
主持人：那為什麼一定是1分鐘，而不是5分鐘？
Ryan Lopopolo：我們希望內部循環（inner loop）盡可能快，1分鐘只是一個好記的目標，而且我們能做到。如果超過這個時間，我們就把它當作訊號：說明需要停下來，把任務拆分，最佳化建構圖，再讓agent繼續工作。
主持人：聽起來像一種「棘輪機制」，你在強制建構時間紀律，否則它就會不斷膨脹。
Ryan Lopopolo：沒錯。傳統平台團隊的做法是：允許建構時間慢慢變長，直到不可接受，再花幾週時間最佳化。但現在token很便宜，模型又高度並行，我們可以持續「修剪」系統，保持這些不變量。這讓程式庫更加穩定、可控，也讓我們在開發過程中可以依賴更多確定性。
OpenAI已經不太靠人來做程式碼審查（Review）了
主持人：你在文章裡提到，人類反而成了瓶頸。一開始你們團隊只有三個人。你們產出了接近百萬行程式碼、1500個PR，這背後的思路是什麼？
程式碼本身某種程度上是「可丟棄」的，但你們又做了大量review。你在文章裡提到，要把一切都「prompt化」，凡是agent看不到的東西基本都是垃圾，不應該存在。所以整體來說，你們是怎麼構建這個系統的？以及在人類成為瓶頸之後，人類還如何參與，比如PR review這一層是怎麼做的？
Ryan Lopopolo：其實我們已經不太依賴「人類做程式碼審查」這件事了。現在大多數的人類審查發生在merge之後。甚至說，merge本身也談不上是審查，更像是一種讓自己「安心」的儀式。從根本上講，模型是可以無限並行的，只要我願意投入GPU和token，它就可以無限擴展產能。
唯一真正稀缺的資源，是團隊中人類的同步注意力。一天就那麼多小時，我們要吃飯，也想睡覺，雖然很難停下來不去「逗這台機器」，因為你會忍不住想繼續餵它。
所以你必須退一步，用系統思維去看：agent在哪裡犯錯？我時間花在哪？如何以後不再花這些時間？然後把這些經驗沉澱為自動化，等於你解決了SDLC的一部分問題。
一開始，我們不得不非常仔細地看程式碼，因為agent還沒有足夠好的「構建模組」，無法生成模組化、可拆解、可靠、可觀測的系統，更不用說還能產出一個真正能工作的前端。為了避免整天坐在終端機前、一次只能處理一兩個問題，我們投入大量精力去提升模型的「可觀測性」，也就是你在文章裡看到的那張圖。
主持人：我們來講講這個tracing系統，是先有trace還是先有應用？
Ryan Lopopolo：一開始只有應用，後面從vector到登入、指標、API這些東西，大概花了我半個下午就搭起來了。我們刻意選擇了一些高層、開發效率很高的工具，現在生態已經很好了。比如我們大量使用一個叫MI的工具，可以很輕鬆地把VictoriaMetrics這一整套Go寫的組件拉到本地開發環境裡。再加一點Python glue code把這些服務跑起來，就可以用了。有個很關鍵的設計是，我們盡量「反轉」整個系統：不是先搭好環境再把agent放進去，而是以agent作為入口——直接啟動Codex，然後透過skills和腳本，讓它在需要時自己啟動整套開發環境，並配置環境變數，讓本地應用指向它自己拉起的服務。
我覺得這正是現在的reasoning模型和過去4.1、4o時代模型的根本區別。以前的模型不會「思考」，你必須把它們關在一個有明確狀態機的盒子裡；而現在，我們讓模型和harness成為整個系統本身，給它足夠的選項和上下文，讓它自己做決策。
主持人：聽起來很多東西都在往「scaffold（腳手架）」方向演進。但有意思的是，有了reasoning模型之後，好像反而不需要那麼重的scaffold了。你們用了像spec.md、很短的agent.md這種結構。
Ryan Lopopolo：對，我們確實定義了一套結構，比如一個總的目錄（大概100行），下面是各種「skills」。這種結構的好處是，可以非常低成本地往程式庫裡注入新內容，同時引導人類和agent的行為。
主持人：某種意義上，你們是從零開始「重新發明了agent skills」。
Ryan Lopopolo：確實如此，因為我們開始的時候這個概念還不存在。我們有一個總的目錄文件，然後是各種小的skills，比如core beliefs.md、tech debt tracker等。
其中tech debt tracker和quality score很有意思，它們本質上是一個極簡的scaffold——一個markdown表格，作為Codex的掛鉤。它會去檢查我們定義的業務邏輯，評估是否符合既定的guardrails，然後給自己生成後續任務。在有Jira之類系統之前，我們其實只是把這些後續工作記錄在markdown裡，然後可以定時啟動一個agent去「清債」。
這裡有個很關鍵的洞察：模型「渴望文本」。我們做的很多事情，本質上是在往系統裡注入更多文本。比如某次線上報警，是因為缺少timeout，我可以直接在Slack裡@Codex，說「我要加一個timeout，同時請更新我們的可靠性文件，要求所有網路請求必須有timeout」。這樣我不僅修了一個bug，還把「什麼是好的實踐」永久編碼進系統裡。這個知識會隨著上下文傳遞給後續的coding agent。
你還可以基於這些文本生成測試，或者驅動code review agent，從而縮小程式碼的「可接受空間」。
給模型預留一定的判斷空間，防止過度服從
主持人：但這裡有個問題：你以為你在做一個「長期正確」的規則，但其實可能忽略了例外情況，後面還得回滾。
Ryan Lopopolo：確實，模型有時會「過度服從」。所以我們在設計上給它一定的判斷空間。比如quality score這種工具，不是每次都強制執行，而是由模型自己決定何時調用。
在prompt層面，我們也允許agent「反駁」。一開始我們引入code review agent時，流程是：Codex本地生成程式碼→推PR→觸發review agent→它寫評論→我們要求Codex必須回應這些評論。最初的問題是，寫程式碼的agent太「聽話」，被reviewer「帶著走」，導致系統不收斂。所以後來我們調整了雙方的prompt：review agent被要求偏向通過（只提不高於P2的問題）；而P0是會毀掉整個程式庫的級別。與此同時，我們也允許寫程式碼的agent拒絕或延後處理review意見。現實中也是這樣——有些review只是FYI，不是要求立刻修復。如果不給這種語境，agent就會機械地執行所有指令。
主持人：我想確認一個點：這些agent可以自動merge，對吧？這其實很多人不太能接受。而且你列的範圍幾乎是全端——產品程式碼、測試、CI、發布工具、內部工具、文件、review評論、甚至管理倉庫的腳本，全都是agent在寫。
Ryan Lopopolo：是的，基本上全部都是。而且它們是並行運行的。
主持人：那有沒有一個「緊急剎車」？比如團隊裡誰可以一鍵停掉一切？
Ryan Lopopolo：因為我們做的是原生應用，而不是基礎設施，所以我們沒有做持續部署。發布分支的切割還是需要人類參與，而且上線前必須經過人工批准的smoke test。換句話說，在發布環節還是有人類把關。
主持人：所以你們不是在做那種要求「99.999%可用性」的基礎設施系統。
Ryan Lopopolo：對，是這樣的。而且要強調一點：這一切都是在「全新倉庫」裡完成的。這不意味著它可以直接套用到所有生產環境中。
GPT5.4是第一個將頂級Coding和推理融合的模型
已經開始讓Codex自己寫部落格
主持人：最開始onboarding的一個月基本是在「倒著工作」，你得不斷適應系統；但現在你已經非常自動化了。我很好奇：現在人類在loop裡還占多大比重？還有哪些瓶頸是你希望能繼續自動化的？以及你覺得模型能力接下來會怎麼發展，進一步替代人類？比如我們剛剛有了GPT-5.4，這是個非常強的模型。
Ryan Lopopolo：是的，這是第一個把頂級coding能力和推理能力融合在一起的模型——既有Codex級別的程式碼能力，也有通用推理能力，還支持computer use。現在我甚至可以直接讓Codex寫部落格了，而之前我還得在chat和coding之間切換……說不定我都要失業了（笑）。
主持人：你這話讓我突然想到，可以用5.4做一個完全AI驅動的newsletter。
Ryan Lopopolo：對，這其實就是「閉環」的一個例子。比如你剛提到的dashboard，我們讓Codex去寫Grafana dashboard的JSON、發布它們、同時響應報警。也就是說，當報警觸發時，它知道具體是哪個dashboard、哪個alert、對應程式庫裡的哪一條日誌，因為這些資訊都被統一匯總了。
主持人：也就是說，它必須「擁有一切」。
Ryan Lopopolo：沒錯，這一點非常關鍵。這意味著如果發生了一次沒有觸發報警的故障，它也可以基於現有的dashboard、metrics和日誌，找出監控體系的缺口，並一次性修復。就像一個全端工程師可以從後端一路把功能推到前端一樣。
「對程式碼細節已經沒有執念了」
關鍵是「系統原語」
主持人：聽起來你們做的大量工作，其實是讓軟體更符合「模型的寫作方式」，而不是「人類的可讀性」。也就是從human-legible轉向agent-legible。這對更大規模的團隊意味著什麼？比如在OpenAI內部，或者整個軟體工程行業——是不是意味著大家都要切換？畢竟這是一個非常激進的變化。
Ryan Lopopolo：我的心態其實是：我已經從具體執行中「抽離」出來了。我不會對程式碼的細節有太多意見，更像是在管理一個500人的團隊——這種情況下，你不可能逐個PR深入細節。所以我們用post-merge review作為一個類比：我只抽樣看一些程式碼，從中推斷團隊的問題、瓶頸、哪裡需要支援、哪裡已經很順暢，然後調整我的關注重點。
我對「程式碼具體怎麼寫」沒有太多執念，但我非常關注「系統原語」。比如我們有一個command-based class，用來封裝可復用的業務邏輯，同時自帶tracing、metrics、可觀測性。這類原語才是關鍵——只要程式碼使用了這些原語，就天然具備槓桿效應。所以重點不是程式碼結構，而是是否使用了正確的抽象。
AI時代的MVC：Model-View-Claw
主持人：這又回到你文章裡的系統思維，比如如何強制架構、如何編碼「工程品味」。
Ryan Lopopolo：是的。而且隨著模型能力提升，它們也越來越擅長提出抽象，幫助自己解鎖問題。這讓我可以站得更高，去思考真正阻礙團隊交付的是什麼。
主持人：你這個專案本質上是一個百萬行程式碼的Electron應用，同時還管理自己的服務，有點像BFF（backend for frontend）。
Ryan Lopopolo：對，我們確實有後端，但部署在雲上。而在Electron內部，本身就有main和renderer兩個行程，這天然形成了類似MVC的結構，我們也用同樣嚴格的方式去做分層。
順便說個有趣的梗：傳統MVC是Model-View-Controller，而我覺得AI原生版本是Model-View-Claw——Claw就是harness。
主持人：這個說法挺妙的。
Coding Agent不只是寫程式碼，而是一切
Ryan Lopopolo：我確實覺得Codex + harness作為AI產品構建方式，還有很大的探索空間。現在模型在coding上的進步非常快，每一代都顯著提升任務複雜度。如果你能把產品問題「壓縮」為程式碼問題，那麼用Codex harness去解決就非常自然——它已經幫你完成所有基礎設施，你只需要用prompt驅動它。
而且這是一種對工程師來說非常「可理解」的能力擴展方式：你只需要把你原本就會寫的那些腳本交給模型。
主持人：換句話說，coding agent不只是寫程式碼，它會「吞噬」所有知識工作。很多人以為非編碼任務需要單獨的agent，但其實你是從coding agent往上擴展。
Ryan Lopopolo：對，本質上你只需要把任務定義成程式碼問題，一切都是coding agent。
自曝內部在用的「完全委託」Skill
主持人：那我再問一個現實問題：像ticket系統、PR這種機制，是不是要被徹底重構？因為Git本身對多agent是非常不友好的。
Ryan Lopopolo：我們大量使用worktree，但即便如此，merge conflict仍然存在。不過模型其實非常擅長解決衝突。而且當我不再同步地盯著終端機時，這些衝突對我來來說幾乎是「可忽略的」。
我們有一個叫「dollar land」的skill，會指導Codex完整處理PR生命週期：創建PR、等待人類和agent review、等待CI通過、修復flaky、處理衝突、重新合併、進入merge queue，直到進入主分支。這就是「完全委託」的含義。對人類來說，這是一套非常重的流程，但agent完全可以處理，我基本只需要把電腦開著。
以前我控制慾很強，但現在我反而覺得：它在很多事情上確實比我做得更好——前提是給它足夠的上下文。
關注Agent每一個BUG
主持人：還有什麼是你覺得文章裡沒講清楚，但大家在討論的？
Ryan Lopopolo：有一點我可能沒講清楚：我們寫的文件、測試、review agent，本質上都是在把「非功能性需求」（比如高可用、高品質、可維護性）注入到模型的上下文裡。我們要麼寫成文件，要麼透過lint報錯提示正確做法。整個系統的本質，就是把工程師腦子裡「什麼是好的」的隱性知識，全部顯性化，讓agent可以學習。
所以我們特別關注agent的bug——因為每一個bug，都意味著有某個「尚未被寫下來的規範」。這其實就是系統演進的驅動力。
主持人：所以大家之前誤解的點是？
Ryan Lopopolo：其實不是誤解，而是有人剛好點出了這一點，我就意識到：對，這才是我真正想表達的核心。
一股腦餵給GPT5.4，也很有價值
主持人：我明白了，很有意思。有個很有趣的現像是，很多人直接把你那篇文章的連結丟給像Pi或Codex，然後說「把我的倉庫變成這樣」。相當於實現了一種「完全遞歸」。而且效果居然很好？
Ryan Lopopolo：是的，效果出奇地好。其實我昨天也用5.4試了一下，當時我在外面演講，沒有太多時間，就想著：能不能直接基於這篇文章快速搭一個類似的scaffold（註：模版、腳手架）？我先這麼做了一版，然後又拿一個小的side project，完全沒有寫程式碼，就是隨便用語音TTS拚出來的那種非生產級專案，然後問：如果要把它完全自動化成這種體系，該怎麼改？這個過程特別有價值，因為它不僅能幫你改程式碼，更像是在「分析」你的系統。你把所有程式碼、上下文和文章一起餵給它，它會一步步帶你理解問題和改進方向。
開源軟體依賴或會消失
AI會內部重寫
主持人：我還想提一個點：你們董事會主席Bret Taylor也回應了你的文章。他說軟體依賴可能會消失，未來可以直接「內嵌」（vendored）。你怎麼看？
Ryan Lopopolo：我基本同意。但現實是，你現在還是要為Datadog、Temporal這些服務付費。以當前模型能力來看，我們可以「內化」的依賴大概在低到中等複雜度之間。
主持人：「中等複雜度」具體指什麼？
Ryan Lopopolo：大概是幾千行程式碼的依賴，我們可以在一個下午內輕鬆重寫一份。而且有個關鍵點是：你其實不需要它全部的功能。透過內化依賴，你可以把通用邏輯全部剝離，只保留自己真正需要的部分。
主持人：我一直在說，這是「外掛的終結」。
Ryan Lopopolo：確實。因為開源專案為了通用性，會引入大量冗餘和複雜性。但如果你自己實現，只需要最小集。
還有一個很實際的好處：當我們在倉庫裡部署Codex安全審查時，它可以直接修改這些「內化」的依賴，而不需要走傳統流程——提PR、等上游發布、再拉下來、再處理相容性。這整個流程的摩擦成本會低很多。在token很便宜的前提下，程式碼本身也變得「便宜」了。
主持人：但反對意見也很明顯，比如大規模測試和安全性。像Linux、MySQL這種系統，依賴「群眾外包審查」才能保證品質。如果你自己重寫一遍，很可能會重複別人犯過的錯誤。
Ryan Lopopolo：沒錯。一旦你內化依賴，你就回到了「從零開始」的狀態，必須重新建立對程式碼品質的信心。
所有內部的AI工具都是Codex寫的
放手讓Agent完成，人反而是瓶頸
主持人：回到你最開始說的：整個系統，包括內部工具，都是Codex寫的，對吧？甚至連視覺化工具也是？
Ryan Lopopolo：對，我現在做一些AI相關的內部工具，基本都是prompt出來的。前幾天我給別人展示，他們問我花了多久，我說——我其實沒花時間（笑）。
有個很有意思的例子：我們把應用部署給第一批內部用戶後，遇到效能問題，於是讓他們匯出trace（一個tar包），交給值班工程師。他用Codex做了一個非常漂亮的本地工具（Next.js應用），可以拖放這個文件並視覺化整個trace，做得非常好，花了一個下午。但後來我們意識到，這其實完全沒必要——你可以直接把tar包丟給Codex，讓它分析，幾分鐘就能得到結果。
所以，從「人類可讀性」出發去最佳化除錯流程，其實是錯誤的。這讓人類不必要地參與進來，而agent本可以直接完成。
主持人：這確實需要對抗直覺——過去我們習慣的做法，在這裡反而是低效的。
Ryan Lopopolo：是的。比如傳統上你會部署Jaeger去看trace，但現在你甚至不需要看trace，因為你也不會親自去修程式碼。
主持人：所以核心是：你需要一整套「自洽的系統棧」，並讓agent完全掌控。
Ryan Lopopolo：對，這一點非常關鍵。而且我們之後也會分享更多這方面的內容。
自曝幽靈庫的構建流程：
三個Codex實例不斷循環
主持人：我們稍後會聊到Symphony。你們現在是用「spec」的方式來分發軟體，有人把這叫做「幽靈庫（ghost libraries）」，這個說法挺酷。
Ryan Lopopolo：是的，這種方式讓軟體分發成本大幅降低。你只需要定義一個spec，讓coding agent能根據這個spec在本地重建系統。
流程也很有意思：我們把原有倉庫的scaffold抽出來，新建一個倉庫，然後讓Codex基於原倉庫生成spec；接著讓它啟動一個新的Codex實例去實現這個spec；再啟動另一個Codex去對比實現和原始程式碼，並不斷最佳化spec，讓兩者越來越一致。這個過程會不斷循環，直到spec可以高保真複現整個系統。
人類更適合「複雜+全新」的問題，其他交給Agent就好
主持人：而且這個過程中，你基本沒有引入人類偏見。
Ryan Lopopolo：對。人類寫spec時，往往會帶入自己的想法，比如「我覺得應該這麼做」，但其實agent自己可以找到最優解。
我最近也在想一個問題：agent能不能寫出一個「自己無法實現」的spec？也就是說，它能否想像出超越自身能力的系統？
我覺得這可以用一個二維坐標來看：問題是「簡單/複雜」和「已有/全新」。對於「複雜+全新」的問題，還是需要人類；但其他象限，其實已經可以被解決了。
這意味著，人類可以把時間用在最有價值的地方——那些真正未知的領域，或者需要深度重構的系統設計。
主持人：這其實是在把人類推向更高層的抽象。
Ryan Lopopolo：沒錯，這也是我希望做的事情。
幽靈庫的誕生
主持人：那我們來正式聊聊Symphony。你們選了Elixir，很有意思。
Ryan Lopopolo：對，但其實Elixir只是模型選擇的一個結果。它選擇Elixir，是因為它的行程模型（比如supervision、GenServer）非常適合我們這種任務編排方式。我們本質上是在為每個任務啟動一個小型「守護行程」，並驅動它完成。
這意味著模型可以「免費」獲得很多能力，比如並發、恢復等。我自己還專門去補了一下Elixir和BEAM的知識。雖然大多數人不需要這麼高的並發規模，但它確實提供了一種很好的思維模型。
主持人：那Symphony是怎麼誕生的？
Ryan Lopopolo：去年12月底的時候，我們每個工程師每天大概能做3.5個PR。到了1月初，隨著5.2模型上線，在沒有額外優化的情況下，這個數字直接提升到了每人每天5到10個PR。
Ryan Lopopolo：我不知道你們有沒有類似的感受，但這種頻繁切換上下文其實非常消耗精力。一天結束的時候，我基本已經被榨乾了。所以問題又回來了：人類的時間花在哪裡？其實就是在不同的終端機視窗（T-Mux pane）之間來回切換，去推動agent前進。
所以我們又做了一件事：想辦法把人從這個loop裡移除。這就引出了Symphony——本質上是一次非常「瘋狂」的衝刺，目標就是讓人不需要一直坐在終端機前。我們嘗試了很多方案，比如dev box、自動拉起agent等等。理想狀態其實很簡單：我每天打開電腦兩次，點個「yes/no」，然後去海邊躺著。
這種模式帶來的一個變化是：我對「延遲」不再敏感，也不再執著於程式碼本身。我幾乎沒有參與程式碼的「創作過程」，所以如果生成的東西是垃圾，我可以毫不猶豫地扔掉。在Symphony裡有一個「rework」狀態：當PR被提交並交給人類審核時，這個審核應該非常輕量——要麼能merge，要麼不能。如果不能，就打回rework，然後Elixir服務會直接刪除整個worktree和PR，從頭再來。
這時候關鍵的問題是：為什麼它是垃圾？agent做錯了什麼？先修正這些問題，再重新推進任務。
個人對MCP挺悲觀的
主持人：為什麼這些能力沒有在Codex App裡？
Ryan Lopopolo：我們的團隊其實一直在「跑在產品前面」，盡可能AI-first地探索。很多我們做的東西，後來都會進入正式產品。比如Codex App、skills、自動化能力等等，我們都深度參與過。但我們的優勢在於：不被產品節奏束縛，可以快速試錯，然後再沉澱出可規模化的方案。
這種方式很有趣，但也很混亂。我經常完全不知道程式庫當前的真實狀態，因為我不在loop裡。
舉個例子：有一次團隊把Playwright直接接進Electron應用，透過MCP來驅動。我其實對MCP挺悲觀的，因為它會強制往上下文裡注入大量token，還會影響自動壓縮（autocompaction），甚至agent可能忘記怎麼用這些工具。而實際上，我真正需要的Playwright調用可能就三種。
後來有人直接寫了一個本地daemon，封裝Playwright，再暴露一個極簡CLI。我完全不知道這件事發生過，因為對我來說，我只是運行Codex，然後它變得更強了。
所以在人類層面，我們必須花大量時間做同步資訊共享。我們每天的standup要開45分鐘，因為需要把當前系統狀態「廣播」出去。
「1萬工程師規模」程式碼架構
主持人：這對單人+多agent還好，但多人與多agent的組合，會變得非常複雜。
Ryan Lopopolo：沒錯，這也是為什麼我們在程式碼架構上採用了「10000人規模」的設計。
主持人：這個「10000人規模」是什麼意思？
Ryan Lopopolo：我們的倉庫大概拆成了500個npm package。對於一個7人團隊來說，這種架構是嚴重「過度設計」的。但如果你把每個人看成10到50個agent，那這個產能規模就合理了。這時候，深度拆分、模組隔離、介面邊界就變得非常重要。
OpenAI應該做一個「Slack」
主持人：你們用Linear做issue管理？
Ryan Lopopolo：對，我們也大量用Slack。比如一些低複雜度的修復任務，我們會直接在Slack裡觸發Codex去處理，同時把知識同步進程式庫。
說實話，我最大的一個想法是：OpenAI應該做一個「Slack」。因為如果AI要真正做「有經濟價值的工作」，它必須能和人類自然協作，而這就需要新的協作工具。
整個程式庫只有6個skills
主持人：現在Codex已經從模型→CLI→App，可以並行跑多個agent，但團隊協作還是缺失的。你覺得未來工具會怎麼演進？是每個團隊做自己的一套，還是會有通用方案？
Ryan Lopopolo：現在還沒有一個通用答案。但我有一個傾向：盡量讓「程式碼結構」和「流程結構」保持一致。因為程式碼本身就是上下文，就是prompt。如果不同模組結構完全不同，agent就需要頻繁切換上下文，效率會下降。
同樣的邏輯也適用於skills。我們整個程式庫只有6個skills。如果某個開發流程沒有被覆蓋，我們的第一反應不是新增skill，而是把它整合進已有的skill裡。這樣做的好處是：改變agent行為的成本，比改變人類行為更低。
第0層：Skill蒸餾機制
主持人：你們會讓agent改變自己的行為嗎？比如自我最佳化？
Ryan Lopopolo：會的。我們有一套「skill蒸餾」機制。比如你可以讓Codex回顧自己的session log，然後問它：我該如何更好地使用你？需要哪些新的skills？這其實就是一種「自我反思」。
但更重要的是，我們把這些資料匯總起來：團隊所有人的session、PR評論、失敗建構，全部收集到一起，然後每天跑agent去分析：我們整體可以怎麼做得更好？再把這些改進回饋進程式庫。
換句話說，每個人的經驗都會自動變成團隊的能力。
PR評論、建構失敗，其實都是訊號——說明agent在某個時刻缺少了上下文。我們的工作，就是把這些缺失的資訊補回系統裡。
主持人：我其實也在做類似的事情。每次用AI工具做完任務，我都會問：下次我可以做得更好嗎？這其實就是一種元程式設計式的反思。
Ryan Lopopolo：沒錯，本質上你可以把Symphony看成一個多層級的「反思系統」。有點像「第零層」。所以這六個層級分別是：策略、配置、協調、執行、整合、可觀測性。
我們已經聊過其中幾個了，但第零層更像是在問：我們現在的工作方式運轉得好嗎？能不能改進？比如我能不能修改我自己的workflow.md之類的東西？我也不確定。
主持人：對，當然可以。
Ryan Lopopolo：而且這個系統甚至可以自己創建工單，因為我們給了它完整權限。是的，讓它給自己創建一個「創建工單」的工單。你甚至可以在工單裡寫上，它需要跟進哪些後續工作。自我修改。
所以，不要把agent關在盒子裡。要給它在各自領域內的完全訪問權限。
主持人：你剛說「不要把agent放進盒子裡」，我腦子裡的第一反應其實是：還是應該把它放進盒子裡。只是這個盒子要給它提供一切所需的。
Ryan Lopopolo：對，context和工具。
想Agent形成完整閉環，應該減少對雲的依賴
主持人：沒錯。但我們作為開發者，習慣調用各種外部系統。而在這裡，你會用像Prometheus這樣的開源工具，本地運行，這樣就能形成完整閉環，對吧？
Ryan Lopopolo：對。我認為你應該盡量減少對雲的依賴。同時也要認真思考agent能訪問什麼，對吧？它能看到什麼？這些資訊會不會被重新餵回循環？最基礎的一點，比如你讓它看到自己的調用鏈（call traces），它就可以判斷自己哪裡出錯了。但問題是，你有沒有把這些再回饋回去？所以在最基本層面，你需要清楚看到輸入和輸出——agent能不能訪問這些輸出？
它可以在很多方面自我改進。本質上，這些都是文本，對吧？我的工作就是想辦法把文本從一個agent流轉到另一個agent。有意思的是，在這波AI浪潮剛開始的時候，Andre就說過：「英語是最火的新程式語言。」現在真的成真了。
很多軟體本來是為人設計的，有GUI。但現在我們看到的是CLI的演化：幾乎所有工具都有CLI，而且agent用得很好。
接下來關鍵在於：我們會不會有更好的視覺能力？更好的小型沙盒？但就目前來說，這種方式非常有效。模型很喜歡用工具，喜歡讀文本，所以直接給它一個CLI，讓它自由發揮，這幾乎適用於一切。
非文本內容，OpenAI內部處理方法：混合使用
Ryan Lopopolo：對。我們也在把一些非文本的東西轉成這種形式，以提升模型表現。比如我們希望agent能「看到」UI，但它並不是像人一樣視覺感知。它不會看到一個紅色方塊，而是看到「紅色方塊按鈕」這樣的語義，它是在潛在空間裡理解這些。
所以如果我們真的想讓它理解佈局，有時候反而是把圖像柵格化成ASCII，再餵給它更容易。而且其實可以兩種方式同時用，進一步最佳化模型對操作對象的理解。
協調層特別難做好
主持人：要不要再聊幾個層級？有沒有你特別感興趣的？
Ryan Lopopolo：我覺得「協調層」（coordination layer）特別難做好。
主持人：那就聊這個。
Ryan Lopopolo：這也是Temporal的核心所在。這裡的關鍵在於，當我們把spec轉成Elixir實現時，模型可以「走捷徑」。因為它有一套原語，可以在一個具備原生行程監督的執行環境中使用。我覺得這是一個很優雅的方式，把spec映射到實現上。
就像你做全端Web開發時，會更傾向用TypeScript倉庫，因為前後端可以共享型別，從而降低複雜度。這有點像當年的GraphQL。
而且這裡沒有人類參與，所以我個人會不會寫Elixir，並不會影響我們是否選用最合適的工具，這一點其實挺瘋狂的。
整合層：「MCP已經死了」
主持人：很有意思。我在想，不同語言在這種範式下會不會表現不一樣？可能有些更慢，有些更容易出bug，比如需要偶爾重啟伺服器。
Ryan Lopopolo：有可能。我覺得可觀測性層已經比較成熟了。整合層的話……MCP已經「死了」。但整體來看，這是一套很有意思的層級體系，可以上下穿梭。它給在系統中工作的開發者提供了一種共通語言。
策略層也很酷。你不需要寫很多程式碼去保證系統必須等CI通過，它其實就是你的「機構知識」。你只需要給它GitHub CLI，再加一句「CI必須通過」，就夠了。
CLI的優勢在於「Token高效」
主持人：那你覺得CLI的維護者需要為agent做特別最佳化嗎？
Ryan Lopopolo：其實不用。比如GitHub CLI，當初設計時肯定沒想到今天這種用法，但它已經很好用了。
CLI的優勢在於「token高效」，而且很容易進一步最佳化。比如你去看Buildkite或Jenkins的日誌，通常是一大堆輸出。為了方便人類開發者，你的Dev Productivity團隊往往會寫程式碼，從日誌中提取關鍵異常，放到頁面頂部。
CLI也應該類似這樣設計。比如你不需要告訴agent每個文件都已經格式化了，它只關心「是否已格式化」。這樣它就可以決定是否執行寫入操作。
類似地，我們在用PNPM的分散式腳本時，輸出會非常多，但其實大部分只是測試日誌。我們最後寫了一層封裝，把無關資訊壓掉，只保留失敗部分。
主持人：對，可以把錯誤流單獨pipe出來。
Ryan Lopopolo：對，不過這就有點太工程細節了。我以前也維護過CLI，這塊我很有共鳴。
主持人：還有什麼要補充的嗎？
Ryan Lopopolo：這份spec很長，也有很多強假設。但我覺得重點是：你可以拿它來用，同時也要改造成適合你自己的。
本質上，軟體在能適應部署環境時才更靈活。所以像Linear、GitHub這些雖然寫進spec，但不是必須的。你完全可以換成Jira或Bitbucket。
關鍵在於，它把一些核心東西定義得很清楚，比如ID格式、agent的循環機制。這樣你可以很快跑起來一個完整系統，然後再逐步演化。
我們從沒打算讓它成為一個不能修改的靜態規範，它更像一個藍圖，讓你先跑起來，再慢慢最佳化。而且這裡面很多其實就是prompt，只是一個非常長的prompt。本質上agent很擅長遵循指令，所以你就給它足夠清晰的指令，這樣結果的可靠性會提高。
就像我們用Symphony一樣，我們不希望人類去盯著agent工作。所以我們會非常嚴格地定義成功標準，這樣部署成功率會更高，也減少支援工單。
並行跑4個Codex，把系統設計成自動走在正確路徑上
主持人：這又回到「可丟棄性」這個點。以前跑一個Codex任務可能要兩小時，你會一直盯著，怕它走偏。但現在你可以直接並行跑四個。
Ryan Lopopolo：對，我最喜歡Codex App的就是這個——直接4倍並行。沒問題，總有一個是對的，甚至可能更好。
別過度思考。我最早的例子其實是deep research。剛發布的時候，我問了一個關於LLM的問題，它卻以為是法律問題，花了一個小時寫了一份完全跑偏的報告。當時我想「我得盯著這個東西」，但其實不對——你不應該盯著它。你應該把系統設計成自動走在正確路徑上，而不是自己在那裡babysit。你用deep research得到一個糟糕結果，其實你已經意識到需要微調prompt了，對吧？這就是你回饋進系統的「護欄」，進一步對齊agent的執行。這些思路在這裡也是一樣的。
神級CLI：把人從循環中移除
主持人：
順便問一句，Symphony的客戶回饋怎麼樣？
Ryan Lopopolo：我覺得目前還沒有真正意義上的「客戶」，因為這是一個我們內部使用的東西。只要你滿意，你就是客戶。
主持人：那外部怎麼看？
Ryan Lopopolo：大家對這種以低成本分發軟體和想法的方式非常興奮。對我們這些用戶來說，生產力又提升了5倍。這說明這裡有一種「可持續的模式」：把人從循環中移除，同時建立對輸出結果的信任。
比如這裡展示的影片，其實就是我們期望coding agent在創建PR時附帶的內容。這是構建信任的一部分。從根本上說，這個系統最有意思的地方在於，它讓agent更像一個「與你協作的隊友」。我不會盯著你一週內處理的每一個工單，也不會想要你在Cursor或Claude Code裡的完整螢幕錄製。我只希望你用你認為合適的方式證明程式碼是可靠的、可以合併的，並把這個過程壓縮成一個我作為reviewer能理解的結果。
這點其實很自然。而且你可以做到這一點，因為像Codex這樣的系統真的很強。
主持人：對，像FFmpeg這種就是「神級CLI工具」。
Ryan Lopopolo：對，簡直像瑞士刀一樣。我以前常說，FFmpeg的每一個flag都可以變成一個微型SaaS。你給它套個UI、做成服務，那些不會用FFmpeg的人就會願意付錢。
我們剛開始做這些實驗時，有一種很強烈的「未來感」：螢幕上不斷跳出視窗，文件自動出現在桌面上，系統在控制你的電腦，而且是在做真正有生產力的事情。我基本只是在旁邊保證它別休眠，偶爾動一下滑鼠。
主持人：很多上班族其實也這麼幹，會買個「滑鼠自動移動器」。
Ryan Lopopolo：沒錯。
OpenAI內部如何用Codex Spark模型
主持人：我想問一個問題：既然現在這些東西這麼強，可以非同步丟一堆agent去跑，那你怎麼看Spark這種模型（註：輕量版的Codex模型）？比如5.3 Spark，它更適合快速小修改，比如改一行程式碼、換個顏色。我不想開IDE，但可以讓它幫我做這些。但問題是，我是不是還是瓶頸？為什麼不乾脆也把這些交給系統自動處理？
Ryan Lopopolo：Spark確實是完全不同的一類模型。它架構不同，不支援複雜推理，但速度極快。說實話，我還沒完全摸清怎麼用它。我一開始是拿它做高推理模型的任務，結果它在真正寫程式碼之前就消耗掉了大量上下文。
順便說一下，像5.4這種百萬token上下文，對於agent非常關鍵。你能在壓縮上下文之前運行更久，token越多，效果越好。
至於Spark，我覺得你的直覺是對的：它很適合快速原型、探索想法、更新文件。對我們來說，它在把回饋轉化成lint（比如ESLint規則）方面非常好用，因為我們已經有成熟的基礎設施。這類任務它做得很好，可以快速unblock，也適合做一些「自癒式」的程式碼維護。
現在的模型：還不能真正一步到位生成一個可用產品
複雜任務重構依舊需要人介入
主持人：那你們其實是在把模型推到極限。那現在的模型還有什麼做不好的？
Ryan Lopopolo：它們還做不到從「全新產品想法」直接一步到位生成一個可用原型（zero-to-one）。這是我目前花最多時間「介入」的地方：把一個完全沒有現有介面的想法，轉化成一個可操作的產品。
另外一個難點是「複雜重構」。雖然每次模型更新都有進步，但最複雜的重構任務仍然需要我頻繁介入。我甚至需要為此構建額外工具，去拆解單體系統。
不過我預計這些都會持續改善。短短一個月內，我們已經從只能做低複雜度任務，進展到可以處理「大規模+低複雜度」的任務。這就是為什麼你不應該低估模型——它會不斷擴展到更高複雜度的空間。
所以正確的策略不是「對抗模型能力」，而是「圍繞它設計系統」，讓它去處理越來越複雜的部分，而你逐漸退到更高層的問題。
模型和現有的Agent產品，解決的是兩個問題
主持人：聽起來任務類型本身也不一樣。比如Codex很擅長理解已有程式庫，但像Lovable、Bolt、Replit這些公司，解決的是從0到1的scaffold問題——從想法直接變產品。
Ryan Lopopolo：對，而且這兩類問題是不同的。模型在這方面也在發生「階躍式」進步。但它和現在的軟體工程agent還是不一樣。
我常說，模型在能力上其實和我「同構」，唯一的區別是：我需要想辦法把我腦子裡的東西，轉成模型可以理解的上下文。而在這些「白紙專案」上，其實我自己也不擅長。
所以在agent執行過程中，我經常是走到一半才意識到缺了什麼，這也是為什麼我需要同步互動。但如果有更好的harness或scaffold，能夠引導我、收斂可能性空間，比如強約束框架、提供模板，這些都可以幫助模型獲得更多「非功能性需求」的上下文，從而避免結果發散。
OpenAI的To B產品：Frontier
主持人：最後聊聊Frontier吧。
Ryan Lopopolo：可以，但這裡我恐怕不能詳細展開藍圖。Frontier是我們希望推動企業AI轉型的平台，從大公司到小公司都適用。核心目標是：讓企業可以輕鬆部署那些「高可觀測、安全、可控、可識別」的agent。
它需要能接入企業內部的IM系統，整合安全工具，連接工作流程工具。本質上，你是在「分發spec」。我們預計這裡會有一些harness組件，Agent SDK是核心，它可以讓創業團隊和企業開發者都擁有一個「開箱即用」的執行環境，能充分利用模型能力，比如shell工具、Codex式執行環境、文件附件、容器等等。
我們的目標是把這些能力做到足夠好，同時讓它們可以安全地組合在一起。比如說，像GPT OSS的safeguard模型，有一點很酷，它自帶了和「安全規範」對接的能力。而安全規範往往是企業定製的。
我們有責任幫這些公司，讓他們能夠給企業裡的agent加上控制，防止資料外洩，而且是按照他們自己的關注點來控制，比如識別公司內部代號之類的。所以關鍵在於：既要提供足夠的「掛鉤」讓平台可定製，同時預設情況下又要盡可能「開箱即用」。這就是我們在探索的空間。
Frontier的購買者和兩類用戶
主持人：對，這其實是像Snowflake、Brex、Stripe這類公司剛需的東西。
我想回到你們的demo影片，那其實很好地展示了一個「大規模agent管理」的場景。比如你給用戶一個控制面板，在運行多個agent的時候，可以下鑽到單個實例，看它具體在做什麼。當然可以。但問題是：這個產品的用戶是誰？是CEO、CTO、還是CIO？
Ryan Lopopolo：我個人的看法是，這個產品服務的「購買者」是一類人，但「用戶」是兩類人。第一類是實際在用這些agent提升生產力的員工，他們接觸的是agent出現的介面、可用的連接器等等。
而像這種控制面板，更多是給IT、GRC（治理/風險/合規）、AI創新辦公室、安全團隊這些人用的，也就是公司裡負責把agent安全部署到員工工作環境中的那批人，同時還要確保符合監管要求和客戶合規承諾。
所以這更像是一個「冰山結構」，員工看到的是水面上的部分，底下還有一整層體系。
主持人：對，相當於UI的每一層都對應agent抽象的不同層級。
Ryan Lopopolo：沒錯。而且能夠深入到單個agent的執行軌跡層級，非常關鍵——不僅對安全來說重要，對那些負責開發「技能」的人也很重要。
我們之前還發布過一個內部資料agent，用了很多Frontier的能力，讓agent能理解我們的資料本體，知道資料倉儲裡到底有什麼。
主持人：類似語義層？我之前稍微接觸過這個領域，說實話，人類自己都很難統一定義，比如「收入到底怎麼算」。「什麼算活躍用戶」？公司裡可能五個資料科學家，每個人定義都不一樣。甚至還有內部政治，比如行銷說「這部分是我貢獻的」，銷售說「這是我的」，加起來超過100%。
Ryan Lopopolo：對，完全是這樣。
主持人：而且在初創公司裡，什麼都算ARR（笑）。這確實很有意思。
Ryan Lopopolo：對。我們其實寫過這方面的部落格。
餵給Agent業務資料，甚至公司文化
主持人：那大家可以去看看。總之，「資料作為回饋層」很關鍵。你必須先把這個問題解決，才能閉環產品的回饋機制。
Ryan Lopopolo：沒錯。agent要理解業務，必須知道收入是什麼、用戶分層是什麼、產品線是什麼。就像我們之前說的harness程式庫裡，有一個core_beliefs.md，裡面寫了團隊是誰、產品是什麼、目標客戶是誰、試點客戶是誰、未來12個月的願景是什麼——這些都是構建軟體時的重要上下文。
主持人：那這些也要餵給agent？
Ryan Lopopolo：對。
主持人：而且這些東西是動態變化的吧？不是一個靜態spec。
Ryan Lopopolo：對，它是會不斷迭代的。
還有一個可能更「炸腦」的點是：我們甚至給agent做了「技能」，讓它學會生成深度油炸迷因圖，還有Slack裡的reaction文化。因為透過Slack + ChatGPT + Codex，我可以讓agent代我發訊息。
幽默其實是AGI的一部分。
GPT-5.4已經會玩梗了
幽默是AGI的一部分
主持人：那它好笑嗎？
Ryan Lopopolo：挺不錯的。幽默其實是很難的能力，因為你要在很少的字裡壓縮大量上下文。這也是為什麼5.4這種模型對我們提升很大——在「玩梗」這件事上。
主持人：明白了，結論是：5.4能讓我們更會玩梗（笑）。
你們可以試試讓Codex回顧你們的agent記錄，然後吐槽你們。
Ryan Lopopolo：哈哈，可以試試。
Frontier瞄準的是Agent規模化落地
主持人：回到最後一個問題：我覺得你們做的這套東西，其實是所有公司都應該採用的模式，不管是不是用你們的產品。我看到的第一反應就是：每家公司都需要這個。
Ryan Lopopolo：對。
主持人：雖然聽起來有點「無聊」，比如安全、合規這些，但如果你真的要在大規模上管理agent，這些是必需的。你們這個dashboard，很像我最初理解的Temporal：一個面板，能看到公司所有長時間運行的流程。
Ryan Lopopolo：對，就是這樣。不過它會高度定製化，每家公司關注點不同。但我覺得未來一定會有很多公司專門做這一層服務。
主持人：我現在完全是Frontier的「信徒」了（笑）。之前是先看到Frontier，再看到harness和Symphony，最後才意識到：原來這是你們交付這套能力的方式。
Ryan Lopopolo：對。我們把一系列「構建模組」組裝成這些agent，而這些模組本身也是產品的一部分。比如你可以控制agent的行為、在模型失控時撤銷權限等等，這些都透過Frontier提供。
公司裡會有很多不同角色，他們都能在這個平台上看到自己需要的資訊，從而推動agent的大規模落地。
主持人：這讓我想起OpenAI之前提到的「AGI五個階段」，其中一個階段是「AI組織」。這基本就是那個方向了。
Ryan Lopopolo：是的。比如我們團隊現在就在做一件事：收集Codex的agent執行軌跡，然後進行提煉，形成團隊級知識庫，再回饋進程式庫。但這不一定要綁定在Codex上，我希望ChatGPT也能學會我們的「梗文化」、產品邏輯和工作方式。這樣我去問它時，它就有完整上下文。
我對Frontier能實現這一點非常興奮。
OpenAI內部也在糾結：把這些能力直接訓練進模型
主持人：模型團隊看到你們這樣用，會有什麼回饋？你們有大量使用資料和軌跡。
Ryan Lopopolo：確實存在一個核心張力：我們到底是應該繼續加強harness（系統工程層），還是把這些能力直接訓練進模型，讓模型預設就會做這些事情。
對。我覺得我們現在這種工作方式的「成功」，意味著模型會逐漸形成更好的「品味」，因為我們可以為它指明方向。而且我們構建的這些東西，並不會降低agent的性能——本質上它們只是讓agent去跑測試，而「跑測試」本來就是寫可靠軟體的一部分。
如果我們是圍繞Codex額外搭一整套ROS式的scaffold，去強行限制它的輸出，那這種額外的harness很可能最後會被廢棄。但如果我們能把這些護欄直接構建在Codex原生輸出之上，也就是程式碼本身，那就沒有摩擦，一方面不影響模型持續演化，另一方面這本身也是良好的工程實踐。這才是關鍵。
主持人：我之前也和一些研究科學家討論過類似問題，比如強化學習裡的on-policy和off-policy。你的意思其實是：應該構建一個on-policy的harness，也就是在模型本身分佈內做增強，而不是搞一個偏離分佈的外部系統？
Ryan Lopopolo：沒錯。
一個月一個版本，Codex團隊瘋狂發版中
主持人：很有意思。還有什麼我們沒聊到，但你覺得值得補充的嗎？
Ryan Lopopolo：我一直很興奮能受益於Codex團隊的持續「高強度迭代」。他們的核心工程文化就是「瘋狂發版本」，而且他們真的做到了。從5.3到Spark，再到5.4，感覺幾乎是在一個月內完成的，這個速度非常驚人。
主持人：對，一個月前還是5.3，昨天就已經5.4了。那接下來是不是每個月都來個5.5？
Ryan Lopopolo：哈哈，這種事我不好說，但預測市場的人可能會很激動。
主持人：不過很有意思的一點是，這也和成長同步——他們說已經有200萬用戶了。但某種程度上，你甚至不再只關心Codex本身了，而是更大的圖景：coding只是入口，真正的目標是整個「知識工作」。
Ryan Lopopolo：沒錯，這才是核心方向。這也是我們團隊在努力支援的事情——讓self-hosted harness跑起來。接下來就是：真正去「做事」。
OpenAI正在走出舊金山，向西雅圖、倫敦擴張
主持人：還有什麼想對大家說的嗎？你在西雅圖，對吧？
Ryan Lopopolo：對，我們在Bellevue有新辦公室，錄製前一天剛剛開業。環境很好，我們很高興能在華盛頓州參與建設未來。
我想說的是，在Frontier這塊，為企業客戶提供服務還有大量工作要做，我們正在招聘。如果你還沒試過Codex App，建議去下載試試。我們剛剛突破了200萬週活用戶，而且每週成長25%，速度非常快。歡迎加入我們。
主持人：我有個觀察：OpenAI以前是一個非常「舊金山中心化」的公司。很多人因為不想搬去舊金山而放棄加入。但現在你們開始在倫敦、西雅圖擴張，這會不會改變公司文化？
Ryan Lopopolo：我算是西雅圖辦公室最早的一批工程師之一，所以對我來說這很自然。這也是我一直在推動的方向，而且發展得很好。我們在那裡已經建立了穩定的產品線，同時也有大量從0到1的創新專案。
這其實就是我們做「應用AI」的核心方式：快速衝刺、不斷探索，看模型在哪些場景下能真正落地。
另外我們在紐約也有辦公室，而且工程團隊規模也不小。
主持人：明白，這基本就是我的「AI朝聖地圖」：哪裡招工程師我就去哪。
Ryan Lopopolo：紐約辦公室也不錯，是以前REI的辦公樓。但紐約的空間畢竟有限，很難像西雅圖那樣有大規模辦公室。西雅圖這邊有點像《廣告狂人》那種風格，很漂亮；Bellevue新辦公室則是綠色基調、金屬裝飾，很有太平洋西北的感覺。
主持人：確實，有些人就是喜歡紐約的氛圍。
Ryan Lopopolo：對。我們的辦公環境團隊做得非常好，能在這裡工作是很幸運的。
主持人：好的，非常感謝你今天的分享，內容很紮實，而且你們確實在「瘋狂推進」。
Ryan Lopopolo：很高興交流，祝週五愉快。
主持人：週五愉快。
好了，文章到這裡結束了，也祝各位大佬們週末愉快～
——好文推薦——
OpenAI CEO：現在的AI，就像2020年疫情爆發前夜！超級智慧的臨界點已至！暗示下一代極強模型將發布！OpenAI建議每週工作32小時試點！
優秀工程師會一直供不應求！GoogleCEO自曝押注邏輯：外界嚴重低估了Google！我們處於十倍擴張時代，AI和傳統產品非零和競爭，記憶體成核心瓶頸
OpenAI幾乎不做中期專案，PM也不大需要了！Codex負責人：OpenClaw很大程度上是Codex開發的！設計師寫的程式碼比半年前工程師寫的還多！