OpenAI 淨靠 Agent 寫出百萬行代碼嘅秘密：Harness 工程五大原則

最近「Harness」呢個詞越嚟越頻繁咁出現。OpenAI 發布嘅一篇博客文章終於為呢個概念落咗清楚嘅定義。喺 Agent 時代，工程師到底要做啲咩？我哋嚟整理一下。

Harness（工具殼）係令 AI Agent 能夠影響現實世界嘅工具外殼。如果推理模型係大腦，咁 Harness 就係手腳。讀取檔案、修改代碼、跑測試、部署上線, , 所有操作都係喺 Harness 入面發生。

OpenAI 內部團隊由 2025 年 8 月尾一個空嘅儲存庫起步，淨靠 Codex Agent 就建構咗一個百萬行嘅新產品。條件係：唔准人類手寫代碼。據報告，耗時只係手工開發嘅十分之一。佢哋喺呢個過程中歸納出以下五條原則。

Agent 睇唔到嘅知識等於唔存在

對 Codex 嚟講，運行期間存取唔到嘅資訊就等於唔存在。Google Docs 入面嘅需求文件、Slack 度達成嘅架構共識、某個人腦入面嘅隱性知識, , 全部都睇唔到。呢個同三個月後先加入嘅新人面對嘅處境一模一樣。

所以團隊將所有決策推入儲存庫入面嘅 Markdown 文件、Schema 同執行計劃（ExecPlan）。

• ExecPlan 係喺 PLANS.md 入面定義嘅自包含設計文件
• 通過標準：新手讀完之後能夠獨立完成實作
• 有 Codex 單次 Prompt 連續工作超過 7 個鐘嘅案例
• 將 matklad 嘅 ARCHITECTURE.md 概念擴展到 Agent 場景

唔好講「再努力啲」，要問「缺咗咩能力」

早期 Agent 嘅速度低過預期。原因唔係模型能力，而係環境準備不足。每次失敗嘅時候，團隊都會問：「缺少咗咩能力？點樣先至可以令 Agent 讀取到、驗證到？」

• 用自研嘅並行 Helper 取代外部函式庫，同 OpenTelemetry 100% 整合
• 業界成日講嘅「悶技術」反而對 Agent 更加有利（API 穩定性高，訓練數據表示度高）

機械化強制而唔係文件嚟保證代碼一致性

淨靠文件冇辦法維持 Agent 生成代碼庫嘅一致性。於是團隊揀咗只機械化強制不變規則，而唔係逐樣逐樣咁指導實作。佢哋要求喺數據邊界必須做解析，但揀邊個函式庫就交畀 Agent 決定。架構固定做分層領域結構，依賴方向由 Linter 驗證。

• 每個業務領域固定層級：Providers → Service → Runtime → UI
• Types、Config、Repo 作為底層共享嘅橫切關注點
• 自訂 Linter 同結構測試喺違規嗰陣即刻中斷建置
• Linter 本身都係由 Codex 撰寫

畀 Agent 裝上眼睛，佢可以獨自做嘢 6 個鐘

團隊將 Chrome DevTools Protocol 接入 Agent 運行時期，為 Codex 提供 DOM 快照、截圖同導覽能力。結構係：對比任務前後嘅快照、觀察運行時期事件，然後喺迴圈入面不斷修復直到一切正常。

可觀測性工具都係用相同方式接入。每個 git worktree 會啟動一個臨時觀測堆疊，做完嘢之後自動銷毀。

• 透過 Victoria Logs（LogQL）同 Victoria Metrics（PromQL），Agent 可以直接查詢日誌同指標
• 「令服務啟動時間控制喺 800ms 以內」呢類 Prompt 變得可以執行
• 單次 Codex 運行專注喺一個任務超過 6 個鐘嘅情況被定期觀測到

畀地圖，唔好畀千頁手冊

上下文管理決定咗 Agent 嘅效能。一開始團隊嘗試將所有內容塞入一個巨大嘅 AGENTS.md，結果失敗咗。matklad 喺 2021 年寫嘅 ARCHITECTURE.md 概念喺呢度大放異彩。原則係：簡短鳥瞰專案整體結構，只收錄唔常變化嘅內容。對 Agent 同樣適用。

• ARCHITECTURE.md 係代碼地圖，唔係代碼圖集
• 架構不變規則往往以「某樣嘢唔存在」嘅形式嚟表達
• 明確聲明邊界（boundary），就可以約束後續所有實作

仲未解答嘅問題

就算係 Codex 團隊，都有仲未解答嘅問題。淨靠 Agent 建構嘅系統能唔能夠喺幾年內保持架構一致性，冇人知道。模型持續進化之後，呢套體系本身會點變化，都係未知數。

有一點係明確嘅：寫好代碼嘅時代正在落幕，設計好環境嘅時代已經開始。