Harness Engineering：在以代理為先的世界中利用 Codex

向零手寫程式碼的轉變

OpenAI 成功開發並發布了一款內部軟體產品，使用 零行手寫程式碼。在五個月內，一支小型工程師團隊使用 Codex 代理生成應用程式邏輯、測試、CI 設定、文件以及可觀測性工具，最終產生約一百萬行的程式碼庫。團隊估計，這種以代理為先的方法將開發時間縮短至手動編碼所需時間的約十分之一。

在此模型中，人類不再是程式碼的主要作者，而是充當指導者。工程師的角色已轉向設計系統、指定意圖，以及建立讓代理能執行可靠工作的回饋迴路。

重新定義工程師角色：從編碼到支架建構

當人類停止編寫程式碼時，主要的工程挑戰變成 讓代理能完成有用工作，透過提供必要的工具、抽象層與內部結構。

系統優先開發

實驗初期的進展緩慢，因為環境規格不足。為了解決此問題，工程師採用了深度優先的方法：將大型目標拆解為小型構件，提示代理去構建它們，並利用這些構件解鎖更複雜的任務。當失敗發生時，解決方案不是透過更強硬的提示，而是找出缺少的能力或工具，並提供給代理使用。

代理驅動工作流程

人類主要透過提示與系統互動。典型的工作流程如下：

  1. 工程師描述任務。
  2. 代理執行並開啟 pull request（PR）。
  3. 代理在本地審查自己的變更，並請求額外的代理審查。
  4. 代理根據人類或代理的回饋迭代，直至所有審查者滿意。

隨著時間推移，團隊將幾乎所有的審查工作轉向代理對代理的互動，僅在必要時才由人類審查 PR。

提升應用程式對代理的可讀性

為防止人工 QA 成為瓶頸，OpenAI 專注於讓應用程式及其遙測資料直接對 Codex 代理可讀。

  • UI 可讀性： 透過將 Chrome DevTools Protocol 接入代理執行環境，並使應用程式可依 git worktree 啟動，代理能夠啟動實例、重現錯誤、驗證修復，並使用 DOM 快照與螢幕截圖推理 UI 行為。
  • 可觀測性可讀性： 代理可存取本地的暫時性可觀測性堆疊。他們能透過 LogQL 查詢日誌，透過 PromQL 查詢指標，從而處理如「確保服務啟動在 800 毫秒內完成」等效能相關的提示。

將儲存庫知識作為系統紀錄

有效的代理表現依賴精確的上下文管理。OpenAI 發現，單一巨大的說明手冊適得其反，因為它們會擠佔任務特定的上下文，且很快變得過時。

地圖 vs. 手冊

團隊不使用巨大的說明檔，而是使用一個短的 AGENTS.md 檔案（約 100 行），作為 目錄。此地圖指引代理前往結構化的 docs/ 目錄，該目錄作為系統紀錄。此方法實現 逐步揭露，讓代理從小的入口點開始，並被教導去尋找更深入的資訊。

知識的機械化強制

為防止文件漂移，團隊採取以下措施：

  • 專屬的 linter 與 CI 任務，驗證知識庫是否為最新且相互連結。
  • 文件整理代理，掃描過時的文件，並開啟修正 PR，使文件與實際程式碼行為保持一致。

強制架構與風格

為在百萬行、由代理生成的程式碼庫中維持一致性，OpenAI 強制執行嚴格的架構不變式，而非對個別實作進行微觀管理。

嚴格的架構層級

每個業務領域被劃分為固定的層級，且依賴方向經過嚴格驗證：Types $\rightarrow$ Config $\rightarrow$ Repo $\rightarrow$ Service $\rightarrow$ Runtime $\rightarrow$ UI。跨領域關注（例如認證、遙測）僅能透過明確的「Providers」進入。這些限制透過自訂、由代理生成的 linter 以機械方式強制執行。

編碼「風格」

人類工程的「風格」——例如命名慣例、結構化日誌、檔案大小限制——被編碼成自訂的 lint。當規則被違反時，lint 會直接將修正指示注入代理的上下文。這使得人類的判斷只需一次捕捉，即可在整個程式碼庫中普遍套用。

自主性與熵問題

隨著開發迴路完全被編碼，Codex 達到端對端自主性的門檻。只要給予單一提示，代理現在即可重現錯誤、錄製失敗影片、實作修復、透過操作應用程式驗證、錄製解決影片，並合併 PR。

管理「AI 低效」

完整的自主性帶來代理可能複製儲存庫中其他地方次佳模式的風險。為了對抗此問題，OpenAI 實施了「垃圾回收」流程：

  1. 黃金原則： 在儲存庫中定義具主觀性的機械規則（例如偏好使用共享的工具套件而非自行編寫的輔助程式）。
  2. 定期清理： 背景的 Codex 任務掃描偏離這些原則的情況，並開啟針對性的重構 PR。

社群觀點與批評

雖然 OpenAI 團隊將此視為生產力的飛躍，Hacker News 社群卻提出了多項批評觀點：

「我仍然無法理解的是，為什麼大量產生的程式碼是一種炫耀？……我認為應該盡可能優化產生的行數，而次要的優化則應該是對人類的可讀性。」

批評者質疑這百萬行程式碼庫是效率的示例，還是「臃腫」的表現，認為以人類為主的方式可能以顯著更少的程式碼達成相同結果。其他人則對缺乏透明度持懷疑態度，指出具體建造的產品從未命名，且儲存庫仍為私有。

然而，一些開發者報告了類似的代理工作流程經驗，指出當代理是主要作者時，嚴格的工程最佳實踐（如型別安全與邊界解析）的必要性變得 更 為關鍵，因為這些限制是確保大規模可靠性的唯一方式。

Sources