W讀Podcast｜零行人寫程式碼、百萬行產品上線：OpenAI 工程師的 Harness Engineering 實戰紀錄

TL;DR

• OpenAI Frontier 團隊的 Ryan Lopopolo 花五個月、寫零行程式碼，用 Codex agent 產出超過一百萬行 code，交付一個要上線給企業客戶的產品
• 核心哲學是「Harness Engineering」：人類不再寫 code，而是設計環境、約束條件和回饋迴圈，讓 agent 自己把事情做完
• 他們從 GPT-5 一路用到 5.4，每個模型版本的行為差異都迫使團隊重新調整 build system 和工作流程
• Symphony 是他們開源的 Elixir 編排框架，用 Linear 看板驅動 agent 自動認領任務、開 PR、跑 CI、merge，人類只在「要不要 release」時介入
• 最反直覺的觀點：code review 已經移到 post-merge，agent 之間互相 review，人類連看都不一定要看
• 軟體依賴正在消失：中低複雜度的 library 直接讓 agent 重寫一份，比維護上游依賴還省事

---

這集在 2026 年 4 月 7 日播出的 Latent Space Podcast，主持人是 Shawn Wang（swyx）和 Alessio Fanelli。swyx 是 AI Engineer 這個角色定義的推動者，之前待過 AWS 和 Temporal；Alessio 是創投 Decibel Partners 的合夥人兼 CTO-in-residence。這個節目基本上是 AI 工程師圈子的情報站，專門找在第一線建東西的人來聊技術細節，不是那種高來高去的產業趨勢節目。

這集的來賓是 Ryan Lopopolo，OpenAI 的 Member of Technical Staff，隸屬 OpenAI Frontier 團隊裡一個專門做新產品探索的小組。Frontier 是 OpenAI 在 2026 年 2 月推出的企業平台，讓大公司能安全地部署和管理 AI agent。Ryan 之前在 Snowflake、Brex、Stripe、Citadel 都待過，基本上就是他現在要服務的那種企業客戶的工程背景。他寫了一篇叫「Harness Engineering」的文章，在圈子裡引起很大迴響，這集就是圍繞這篇文章和他們後來開源的 Symphony 框架展開的。

五個月、零行程式碼、一百萬行產品

Ryan 一開始就給自己設了一個極端的限制：不寫任何一行 code。

他的邏輯是這樣的：如果 OpenAI Frontier 要賣給企業客戶「agent 可以幫你做事」這個概念，那 agent 應該要能做到他自己能做的所有事情。所以他決定用自己當白老鼠，看看純粹靠 Codex agent 到底能不能交付一個真正的產品。

結果是五個月內，三人團隊（後來擴到七人）用 Codex 產出超過一百萬行 code、1,500 個 PR，平均每位工程師每天 3.5 個 PR。他估計這比純人工快了大約十倍。

但前面一個半月是極度痛苦的。他說那段時間效率大概是自己手寫的十分之一。因為早期的 Codex Mini 模型根本沒辦法把一個完整的產品功能組裝起來，所以他們只能不斷把任務拆小，先建好小的 building block，再讓 agent 把這些積木組合成更大的功能。

這筆「學費」後來證明值得。因為他們等於是幫 agent 建了一整套組裝站，後面每一代模型出來，agent 的生產力就直接跳升。

每個模型版本都在改變工作方式

Ryan 從 GPT-5 一路用到 5.4，每個版本的行為差異都真實影響了他們的開發流程。

最有趣的例子是 5.2 到 5.3 的轉變。5.2 時代，Codex 沒有 background shell（背景執行指令的能力），所以 agent 會乖乖等一個長時間的 build 跑完再繼續。但 5.3 加了 background shell 之後，agent 變得「沒耐心」了，不願意 block 在那邊等，會自己跑去做別的事。

這直接逼他們在一週之內把整個 build system 從 bespoke Makefile 換到 Bazel，再換到 Turbo，最後換到 NX，只為了讓 build 時間壓到一分鐘以內。

一分鐘這個數字聽起來很武斷，但背後的邏輯很實際：agent 的內迴圈（inner loop）越快，產出就越高。如果 build 時間膨脹到五分鐘、十分鐘，agent 就會開始走神，整個系統的可靠性就會下降。

Ryan 說這就像一個棘輪（ratchet）機制。傳統團隊的 build time 會慢慢膨脹，等到受不了了再花兩三週砍回來，然後又慢慢膨脹。但因為 token 便宜又可以大量平行，他們可以讓 agent 持續「園藝」這件事，維持 build time 的紀律。

到了 5.4，最大的突破是把頂級 coding 能力和通用推理能力合進同一個模型。之前他們得在 Codex 模型和 chat 模型之間切換，現在一個模型就能搞定所有事。而且 5.4 有百萬級 token 的 context window，agent 可以跑更久才需要 compact（壓縮上下文），對長時間任務的品質提升很大。

Agent 互相 Review，人類退到 Post-Merge

這集最讓我震驚的部分是他們對 code review 的態度。

他們已經不做人工 code review 了。

Ryan 的說法是：模型天生可以無限平行化，想花多少 GPU 和 token 就花多少。但人類的注意力是同步且有限的。一天就那麼多小時，還要吃飯、睡覺。所以人類不應該把時間花在逐行看 code 上。

他們的做法是讓 agent 之間互相 review。Codex CLI 在本地寫完 code 推上 PR，PR 同步觸發一個 review agent，review agent 留 comment，然後原本的 coding agent 被指示「至少要回應 review 的回饋」。

一開始這個流程會打架。coding agent 太聽話，review agent 說什麼就改什麼，結果改到最後根本不收斂。他們後來調整了兩邊的 prompt：review agent 被指示「偏向 merge」，只提 P2 以上的問題（P0 是「merge 了會炸掉整個 codebase」）；coding agent 則被給予「推回或延後處理」review 回饋的彈性。

這跟人類團隊的動態一模一樣。你在 review 別人 code 的時候偶爾會順手提一個建議，但你的意思是「放到 backlog 下次再處理」，不是「現在立刻改」。沒有這個 context，agent 就會把每條 comment 都當成 blocking issue 來處理。

人類現在的「review」只是 post-merge 偶爾讀一讀 code，確認大方向沒偏，Ryan 說這比較像是「讓自己開心一下」。

Symphony：把人類從終端機前面解放出來

到了 2025 年 12 月底，團隊的 PR 產出已經到每人每天 3.5 個。2026 年 1 月 GPT-5.2 一出，直接跳到每人每天 5 到 10 個。

問題來了：人類受不了了。不斷在 TMux 視窗之間切換，盯著不同的 agent 跑不同的任務，一天下來腦子是炸的。

所以他們造了 Symphony。

Symphony 是一個用 Elixir 寫的編排框架（現在已經開源），核心概念是：人類只要在 Linear 看板上移動卡片，Symphony 就會自動啟動 Codex agent 去執行任務、開 PR、跑 CI、處理 merge conflict、進 merge queue，一路到 merge 進 main。

為什麼選 Elixir？因為是 agent 自己選的。Elixir 跑在 BEAM 虛擬機上，天生有 process supervision 和 GenServer 這些東西，特別適合同時管理大量獨立任務。Ryan 自己不會寫 Elixir，但因為他的原則是「不自己寫 code」，所以他個人會不會寫根本不重要，agent 選了最適合這個 domain 的工具就好。

這點我覺得很值得想一下。之前在 W讀Podcast｜Codex、Claude Code、Cursor：AI Coding Agent 的三座燈塔，誰會活到最後？ 有聊過不同 coding agent 的能力邊界，但 Symphony 做的事情已經超出「coding agent」的範疇了，它更像是一個 AI 團隊的管理層。

Symphony 有一個 rework 機制：如果 PR 被人類判定不合格，系統會直接把整個 work tree 和 PR 砍掉，從頭開始。但關鍵是，在重新啟動之前，人類要先想清楚「為什麼 agent 做錯了？是不是少了什麼 context？」然後把那個 context 補進去再重跑。

六層反思：Agent 改善自己的工作方式

Ryan 把整個系統的回饋迴圈分成六層：Policy、Configuration、Coordination、Execution、Integration、Observability。

但最有趣的是第零層：agent 能不能改善自己的工作流程？

答案是可以。他們會把整個團隊所有 Codex 的 session log 收集起來，丟到 blob storage，每天跑一個 agent loop 去分析「團隊整體哪裡可以做得更好？」然後把結論反映回 repo 裡。

PR comment、build failure、test failure，這些全部都是信號，代表 agent 在某個時間點缺少了某段 context。系統會想辦法把這些信號「吸」回來，塞進 repo 讓下一次的 agent 不會再犯同樣的錯。

Ryan 還提到一個手法：在 Slack 收到 page（告警）的時候，他會直接 tag Codex 進 channel，說「我要加一個 timeout 來修這個問題，順便請你更新 reliability 文件，要求所有 network call 都必須有 timeout。」一次動作，同時修了眼前的 bug 也永久編碼了流程知識。

之前在 W讀Podcast｜一個 Google PM 用六個 AI Agent 自動化他的人生，這是他的五步框架 有提過類似的概念，但 Ryan 團隊做的是更系統化的版本，因為他們的 agent 是 24/7 不間斷在跑的。

Ghost Library：軟體分發的新方式

Ryan 團隊還做了一件很有意思的事：他們把 Symphony 不是用傳統方式開源，而是先發布一個 spec（規格書），讓其他人的 Codex agent 自己根據 spec 重新組裝出一個本地版本。

Twitter 上有人把這種方式叫做「Ghost Library」。

流程是這樣的：他們從 proprietary repo 出發，spawn 一個 Codex 去寫 spec，再 spawn 另一個 Codex 根據 spec 實作，再 spawn 第三個 Codex 去比對實作跟原始版本的差異來修正 spec。反覆循環，直到 spec 的保真度夠高。

整個過程人類幾乎沒有介入。Ryan 說很多人寫 spec 的時候會忍不住加入自己的偏好（「我覺得應該用這個方式做」），但 agent 其實可以自己決定最好的實作方式。

有人直接把 Ryan 的 harness engineering 文章丟給 Codex 說「把我的 repo 改成這樣」，結果效果出奇地好。Ryan 自己用 5.4 測試過，確認這條路是通的。

依賴即將消失，Agent 需要擁有一切

Brett Taylor（OpenAI 董事長）看完 Ryan 的文章後在網路上說：「軟體依賴正在消失。」

Ryan 百分之百同意。他估計目前中低複雜度的 dependency（幾千行 code 的那種）可以在一個下午讓 agent 全部 in-house 重寫。好處不只是少了版本管理的痛苦，更重要的是你可以只保留你真正需要的部分，砍掉所有為了通用性而存在的 bloat。

而且 in-house 之後，Codex 的安全掃描可以直接深度 review 你自己的 code，比推 patch 到上游、等 release、確認相容性要低摩擦太多了。

唯一的隱憂是規模測試和安全性。開源社群的「many eyes」效應確實是重要的防線。你把依賴 inline 回來之後，等於從零開始，要自己重新踩過別人已經踩過的坑。

模型還做不好什麼？

Ryan 很坦白地說了兩件事 agent 目前還搞不定：

1. 從零開始的產品原型：沒有現有畫面、沒有 reference 的全新產品，agent 需要大量人類引導。這跟 Lovable、Bolt 等 zero-to-one 工具在解決的問題不同。
2. 最複雜的重構：那種你連 interface 的最終形狀都還不確定的深度重構，agent 還是需要人類的判斷力。

但他強調不要跟模型對賭。一個月前還做不了的 low complexity + big scope 任務，下一個模型版本就能做了。人類的工作就是不斷找到下一個瓶頸在哪裡。

我的觀察

Ryan 這套方法論有一個前提很容易被忽略：這是一個 greenfield（全新開始的）repo。他自己也承認，如果是在一個已經有十年歷史、幾百個工程師有各種「意見」的 codebase 裡，很多做法是行不通的。

但這不代表這些概念沒有參考價值。他講的那個核心迴圈很清楚：觀察 agent 在哪裡犯錯 → 找出缺少的 context → 把 context 編碼進 repo（文件、linter、test、skill） → 讓 agent 下次不再犯同樣的錯。這個迴圈不管你的 repo 是新是舊都適用。

還有一個我覺得很關鍵的 mindset shift：Ryan 說他現在看 code 的心態像是一個「管 500 人工程組織的 Group Tech Lead」。不可能每個 PR 都看，只能看 representative sample，然後從中推斷團隊哪裡需要幫忙。

這跟我們之前在 W讀Podcast｜SaaS 要死了嗎？從 Klarna CEO 砍掉一半員工的故事聊起 討論的邏輯是一致的：AI 正在把「執行」的成本打到接近零，人類的價值在「判斷」和「品味」。

如果這篇對你有幫助，我的部落格 wilsonhuang.xyz 會持續寫這類 AI coding 和 agent 的第一線觀察，訂閱就不會漏掉。