2026 年 Agent 最重要的工程概念：「Harness Engineering」
整理版優先睇
Harness Engineering：2026年最重要的Agent工程概念，為智能體搭建可自迭代嘅工作環境
呢篇文章翻譯自OpenAI嘅官方博客，記錄咗一個持續五個月嘅內部實驗：一個由三名工程師組成嘅團隊，用Codex智能體由零開始構建一個真實產品，全程冇一行人手寫嘅代碼。最後個產品有成百萬行代碼，經歷咗完整嘅交付、部署、故障同修復流程，仲有活躍嘅內部用戶。作者想解答嘅問題係：當工程團隊嘅核心工作唔再係寫代碼，而係設計環境、明確意圖同構建反饋迴路嘅時候，軟件開發會變成點樣？
整體結論好清楚：Agent嘅瓶頸已經唔喺模型本身，而係喺你畀佢嗰套工程環境。呢個新概念叫「Harness Engineering」，核心係幫Agent搭建一整套可以自己運行、自己迭代嘅基礎設施，包括代碼倉庫點樣組織、文件點樣寫、反饋迴路點樣閉合。唔似得提示詞工程淨係教模型聽話，或者上下文工程畀模型睇到全貌，Harness Engineering係畀Agent有工具、有規則、有反饋，可以獨立完成成個任務。
對於香港嘅開發者，呢篇文章提供咗一個好實用嘅框架：如果你發現Agent成日做唔到你想佢做嘅嘢，好大機會係你嘅工程環境唔夠清晰。你需要將代碼、文件、架構變成對AI可讀，而唔係對人可讀。文章仲分享咗好多具體做法，例如將AGENTS.md當做目錄而唔係百科全書，用自定義linter強制執行架構規則，同埋定期運行「垃圾回收」任務清理技術債。
- Harness Engineering係2026年最關鍵嘅Agent工程概念，核心係為智能體搭建可自迭代嘅工作環境，而唔係單純優化提示詞或上下文。
- OpenAI內部實驗用三名工程師同Codex智能體，由空倉庫出發，五個月內生成咗百萬行代碼，全程冇人手寫過一行程式碼。
- 傳統開發強調人手寫碼，但Harness Engineering入麪人類嘅角色係設計環境、定義約束同埋反饋迴路，智能體負責執行同迭代。
- 情境管理係最大挑戰：要畀智能體一張地圖（指向性嘅AGENTS.md）而唔係一本千頁說明書，否則會因情境稀缺而失效。
- 可行動點：優先優化代碼對智能體嘅可讀性，用自定義linter強制執行架構規則，並建立定期清理技術債嘅流程，越早開始越能攞到2026年嘅技術紅利。
OpenAI Harness Engineering 原文
記錄OpenAI內部用Codex智能體從零構建真實產品嘅實驗，係Harness Engineering最詳細嘅介紹
內容結構
AGENTS.md
ARCHITECTURE.md
docs/
├── design-docs/
│ ├── index.md
│ ├── core-beliefs.md
│ └── ...
├── exec-plans/
│ ├── active/
│ ├── completed/
│ └── tech-debt-tracker.md
├── generated/
│ └── db-schema.md
├── product-specs/
│ ├── index.md
│ ├── new-user-onboarding.md
│ └── ...
├── references/
│ ├── design-system-reference-llms.txt
│ ├── nixpacks-llms.txt
│ ├── uv-llms.txt
│ └── ...
├── DESIGN.md
├── FRONTEND.md
├── PLANS.md
├── PRODUCT_SENSE.md
├── QUALITY_SCORE.md
├── RELIABILITY.md
└── SECURITY.md從提示詞到Harness：Agent工程嘅進化路線
2024年大家仲係講緊提示詞工程，核心係點樣寫一段好嘅提示詞令模型輸出更可靠。去到2025年，上下文工程開始流行，因為發現模型需要更多資訊：對話歷史、外部工具返回結果、用戶上下文，全部都要塞入去。
最直接嘅理解：提示詞工程係教模型聽得明；上下文工程係令模型睇得曬；Harness Engineering就係幫Agent套返個馬具，等佢有工具、有規則、有反饋，可以獨立完成工作。呢個概念最早由HashiCorp聯創提出，隨後OpenAI嘅文章徹底引爆咗個討論。
OpenAI內部實驗：五人團隊、百萬行代碼、零人手編寫
OpenAI團隊由一個空Git倉庫開始，用Codex CLI配合GPT‑5生成初始架構，包括倉庫結構、CI配置、格式化規則、包管理器設置，甚至連指導智能體點樣工作嘅AGENTS.md都係由Codex自己寫嘅。五個月後，倉庫累積咗大約一百萬行代碼，由應用邏輯到基礎設施、工具、文檔、內部開發者工具，應有盡有。
成個過程開咗大約1,500個Pull Request，而推動Codex嘅只係一個由三名工程師組成嘅小團隊，平均每位工程師每日處理3.5個PRs。隨住團隊擴大到七人，吞吐量仲有增加。重點係：人類從未直接貢獻過任何代碼，呢個成為團隊嘅核心理念。
初期進展比預想慢，原因唔係Codex能力唔夠，而係環境唔夠清晰：智能體缺乏實現高級目標所需嘅工具、抽象層同內部結構。工程師嘅主要任務變成咗協助智能體完成有用嘅工作，方法係深度優先拆解目標，將大任務拆成細模塊，再用呢啲模塊解鎖更複雜嘅任務。
核心教訓：情境管理、智能體可讀性同規範架構
另一個關鍵係優先對智能體可讀：代碼倉庫入面所有嘢，包括代碼、Markdown、模式、可執行計劃，都係智能體可以訪問嘅全部。儲存在Google Docs、聊天記錄或人腦入面嘅知識都係唔存在嘅。團隊將越來越多嘅情境推入倉庫，例如設計決策、技術債務記錄、執行計劃。
為咗保持代碼庫連貫性，團隊引入規範架構：每個業務域劃分為固定嘅層（Types → Config → Repo → Service → Runtime → UI），依賴方向嚴格驗證，橫切關注點透過單一接口進入。呢啲約束由自定義linter強制執行，仲有一小組「品味不變式」，例如結構化日誌、命名約定、文件大小限制。
Harness Engineering帶嚟嘅改變同挑戰
高吞吐量改變咗合併理念：Pull Request生命週期短，測試偶發失敗通常後續重跑，而唔係阻礙進展。喺低吞吐量環境下噉做唔負責任，但喺呢度，糾錯成本低而等待成本高。
「智能體生成」意味住成個代碼庫都係由Codex產生，包括產品代碼、測試、CI配置、文檔、審核評論、內部工具等。人類始終參與，但抽象層次更高：優先處理工作、轉化用戶反饋為驗收標準、驗證結果。團隊仲遇到「熵與垃圾收集」問題：智能體會復現唔均衡嘅模式，導致漂移。解法係將「黃金原則」編碼入倉庫，定期運行後台Codex任務進行重構，類似垃圾回收。
團隊而家最棘手嘅挑戰集中喺設計環境、反饋迴路同控制系統，幫助智能體大規模構建同維護複雜、可靠嘅軟件。佢哋仲未完全清楚耐人尋味嘅架構連貫性會點樣演變，但肯定嘅係：紀律仍然需要，但更多體現喺支撐結構上，而唔係代碼本身。
你可以即時開始嘅行動
讀完呢篇文，最值得反思嘅係：你嘅Agent唔好用，好多時唔係模型問題，而係你嘅工程環境問題。核心問題只有一個：你有冇畀AI提供一個可以自我迭代嘅環境？呢要求你嘅代碼、數據唔係對人可讀，而係對AI可讀。
- 檢查你嘅架構約束係寫喺文檔定係只存在於團隊口頭約定？如果係後者，要立即轉成由linter強制執行。
- 你嘅測試能否被自動運行，定係需要人手動觸發？目標係實現全自動化，甚至由智能體自行觸發。
- 設計決策有冇記錄？定係散落喺三個月前嘅Slack聊天記錄？所有知識要版本化，放入倉庫。
- 建立定期清理技術債嘅流程：每日修復小債，避免累積到無法清算。
Harness Engineering越早開始做，你就可以越早獲得2026年最大嘅技術紅利。OpenAI已經證明咗可行性，而家輪到你喺自己嘅項目度實踐。
最近，AI 圈子入面又彈出一個新詞：Harness Engineering。
唔出意外，佢好大機會會成為 2026 年最熱嘅工程概念之一。
如果你留意 Agent 開發，可能已經喺 X 或者技術 blog 度見過。但第一次見到呢個詞嗰陣，我其實呆咗一下。Harness? 馬具？駕馭？呢啲同寫 code 有咩關係？
要明白佢講咩，首先要睇一條大多數 Agent 開發者都親身行過嘅技術路線：
2024 年，大家講嘅係提示詞工程。
嗰陣時嘅核心問題好簡單：點樣同模型寫一段好嘅提示詞，令佢輸出更可靠嘅結果。
2025 年，剩係靠提示詞已經唔夠。
你會發現模型需要知更多嘢，對話歷史、外部工具嘅返回結果、用戶嘅上下文資訊，呢啲都要塞入去。於是「上下文工程」呢個概念開始流行，本質上係幫模型建立一個更完整嘅資訊環境。
去到 2026，Harness Engineering，係呢條技術路線嘅再一次進化：
佢做嘅嘢唔再只係優化某一次對話嘅輸入，而係幫 Agent 搭建一整套可以運行嘅工程環境。Code 倉庫點樣組織、文檔點樣寫、反饋迴路點樣閉合，所有呢啲加埋，構成咗 Agent 能否真正做嘢嘅基礎設施。
換個講法：提示詞工程係教模型聽得明說話，上下文工程係令模型睇到全貌，Harness Engineering 就係幫 Agent 搭一整套可以自己獨立做嘢嘅工作環境：唔只係叫佢做咩，而係等佢有工具、有規則、有反饋，可以自己完成成件事。
PS：最直接嘅理解：同 Agent（做嘢嘅牛「馬」）套一個 Harness（馬具，令馬可以拉得鬱嘢、真正做嘢嘅整套結構）
呢個概念最早從邊度嚟？
最早係 HashiCorp 聯創喺上個月月初提出，跟住 OpenAI 就發佈咗一篇文章，徹底喺 AI 圈引爆咗呢個概念：
OpenAI 呢篇文章，記錄咗一個持續咗五個月嘅內部實驗：用 Codex 智能體由零開始建立一個真實產品，全程冇一行人手寫嘅 code。而呢篇內容，可能係目前互聯網上對 Harness Engineering 最詳細嘅介紹。
https://openai.com/zh-Hans-CN/index/harness-engineering/
以下係原文精校翻譯。
喺過去五個月裏面，我哋嘅團隊一直進行緊一項實驗：
建立並交付一個軟件產品嘅內部 beta 版，其中冇一行 code 係人手寫嘅。
呢個產品有內部使用嘅日活用戶，亦有外部嘅 Alpha 測試者，經歷咗完整嘅交付、部署、故障同修復流程。關鍵係每一行 code：包括應用邏輯、測試、CI 配置、文檔、可觀測性、內部工具，全部都係 Codex 寫嘅。
粗略估算，成個過程只用咗純人手寫 code 所需時間嘅 1/10。
我哋選擇「人類確定方向，智能體執行」呢種方式，從而將工程速度提升幾個數量級。最終，我哋用咗幾個星期嚟交付最終達到一百萬行 code 嘅項目。
呢個迫使我哋重新思考一個問題：當工程團隊嘅核心工作唔再係寫 code，而係設計環境、明確意圖、建立反饋迴路嘅時候，軟件開發會變成點樣？
呢個 post 要講嘅係，喺我哋同智能體團隊一齊從零開始打造一個全新產品嘅過程中，學到嘅經驗教訓：
邊啲地方出咗問題，邊啲問題互相疊加，同埋點樣最大化利用我哋唯一真正稀缺嘅資源，即係人類嘅時間同注意力。
人類同 AI 點樣互動
「我哋由一個空嘅 Git code 倉庫開始」
第一次提交到一個空嘅 code 倉庫係喺 2025 年 8 月下旬。
初始架構：包括 code 倉庫結構、CI 配置、格式化規則、包管理器設置同應用框架，係喺一小套現有模板嘅指導下，由 Codex CLI 使用 GPT‑5 生成嘅。就連指導智能體點樣喺 code 倉庫入面工作嘅初始 AGENTS.md 檔案本身都係由 Codex 寫嘅。
呢個系統冇預先存任何人手寫嘅 code。由一開始，code 倉庫就由智能體塑造。
五個月後，呢個 code 倉庫已經有大約一百萬行 code，從應用邏輯、基礎設施、工具、文檔到內部開發者工具應有盡有。喺嗰段時間入面，大約有 1,500 個 Pull Request 被打開同合併，而推動 Codex 嘅只係一個由三名工程師組成嘅小團隊。
呢個相當於平均每位工程師每日處理 3.5 個 PRs 嘅吞吐量，而且令人驚訝嘅係，隨住團隊規模擴大到而家嘅七名工程師，吞吐量甚至仲增加咗。重要嘅係，呢個產品已經喺數百名內測用戶嗰度投入使用，其中包括每日都用嘅內測高級用戶。
喺成個開發過程中，人類從未直接貢獻過任何 code。呢個成為咗團隊嘅核心理念：唔手動寫 code。
「重新定義工程師嘅角色」
由於缺乏人工編碼嘅實踐，工程師工作嘅重點轉向咗系統、架構同槓桿作用。
早期進展比預想中慢，但原因唔係 Codex 能力唔夠，而係環境唔夠清晰：嗰個智能體缺乏實現高級目標所需嘅工具、抽象層同內部結構，所以冇辦法取得進展。我哋工程團隊嘅主要任務變成咗協助智能體完成有用嘅工作。
喺實踐入面，呢個意味住採用深度優先嘅工作方式：將更大嘅目標拆解成更細嘅構建模塊（設計、code、評審、測試等），提示智能體去建立呢啲模塊，並使用佢哋去解鎖更複雜嘅任務。
當事情唔順利嗰陣，解法從來唔係「再試一次」或者「換個提示詞」。
工程師要做嘅係退後一步問：智能體欠缺啲咩？係工具、係文檔、定係約束？然後將欠缺嘅嘢補返落 code 倉庫度，令佢變成可發現、可執行嘅。
人類幾乎完全通過提示詞同系統互動：工程師描述任務，執行智能體，並允許佢打開一個 Pull Request。
為咗推動 PR 嘅完成，我哋會指示 Codex 喺本地審核自己嘅更改，喺本地同雲端請求額外嘅特定智能體審查，對任何人工或者智能體畀出嘅反饋作出回應，並循環往復，直到所有智能體審核人員都滿意為止。
Codex 直接使用我哋嘅標準開發工具（本地 script 同嵌入 code 倉庫嘅技能）嚟收集情境，而唔需要人工將內容複製貼上到 CLI 度。
人類可以審核 Pull Request，但唔係一定要咁做。隨住時間推移，我哋已經將幾乎所有審核工作調整為用智能體對智能體嘅方式嚟處理。
「提高應用程式嘅可讀性」
隨住 code 吞吐量嘅增加，我哋嘅瓶頸變成咗人工 QA 能力。由於人類嘅時間同注意力係固定嘅限制因素，我哋一直努力緊通過令應用程式嘅 UI、日誌同應用指標等內容對 Codex 直接可讀，從而為智能體增加更多功能。
例如，我哋令應用程式可以根據 git worktree 啟動，因此 Codex 可以為每次更改啟動並驅動一個實例。我哋仲將 Chrome DevTools 協議接入智能體運行時，並建立咗用嚟處理 DOM 快照、屏幕截圖同導航嘅技能。呢個令 Codex 能夠重現錯誤、驗證修復，並直接推理 UI 嘅行為。
我哋對可觀測性工具都做咗同樣嘅處理。日誌、指標同追蹤記錄會通過一個本地可觀測性堆疊展示畀 Codex，對任何畀定嘅工作樹嚟講，呢個堆疊係臨時嘅。
Codex 喺呢個應用程式嘅一個完全獨立嘅版本上運行，一旦任務完成，呢個版本嘅所有內容，包括日誌同指標，都會被刪除。智能體可以使用 LogQL 查詢日誌，使用 PromQL 查詢指標。
有咗呢啲情境，好似「確保服務啟動喺 800ms 內完成」或者「呢四個關鍵用戶旅程入面嘅任何跨度都唔可以超過兩秒」呢類提示詞就變得可行。
我哋經常見到單次 Codex 運行喺單個任務上持續工作超過六個鐘（通常係喺人類睡眠時間）。
我哋嘅 Harness 工程經驗
「我哋將 code 倉庫設為記錄系統」
情境管理係令智能體喺大型同複雜任務中有效發揮作用嘅最大挑戰之一。
我哋學到嘅最早經驗教訓之一好簡單：要畀 Codex 嘅係一張地圖，而唔係一本 1,000 頁嘅說明書。
我哋嘗試咗一個大型嘅 AGENTS.md 方法。可想而知，呢個係一次失敗嘅嘗試：
情境係一種稀缺資源。一個巨大嘅指令檔案會逼走任務、code 同相關文檔 — 所以智能體要唔係錯過關鍵約束條件，就係開始針對錯誤嘅約束條件進行優化。
太多指導反而變得無效。當所有嘢都重要嗰陣，就咩都唔重要。智能體最終會喺本地做模式匹配，而唔係有意識咁導航。
佢會好快過時。一份龐雜嘅手冊最終會變成過期規則嘅墳場。智能體冇辦法判斷邊啲資訊仍然有效，一旦人類停止維護佢，呢個檔案就會悄然成為一個頗吸引嘅麻煩源頭。
佢冇辦法自動檢查。一個大檔案冇辦法被程式化咁驗證：內容係咪過時、有冇遺漏、各部分仲有冇互相對應。所以偏差只會越積越大。
因此，我哋唔再將 AGENTS.md 視為百科全書，而係將佢視為內容目錄。
code 倉庫嘅知識庫位於一個結構化咗嘅 docs/ 目錄入面，呢個目錄被當作記錄系統嚟用。一份簡短嘅 AGENTS.md（大約 100 行）被注入到情境中，主要用作地圖，並指向其他地方更深層次嘅真實資訊來源。
AGENTS.md
ARCHITECTURE.md
docs/
├── design-docs/
│ ├── index.md
│ ├── core-beliefs.md
│ └── ...
├── exec-plans/
│ ├── active/
│ ├── completed/
│ └── tech-debt-tracker.md
├── generated/
│ └── db-schema.md
├── product-specs/
│ ├── index.md
│ ├── new-user-onboarding.md
│ └── ...
├── references/
│ ├── design-system-reference-llms.txt
│ ├── nixpacks-llms.txt
│ ├── uv-llms.txt
│ └── ...
├── DESIGN.md
├── FRONTEND.md
├── PLANS.md
├── PRODUCT_SENSE.md
├── QUALITY_SCORE.md
├── RELIABILITY.md
└── SECURITY.md
設計文檔已被編目同索引，其中包括驗證狀態同一套核心理念，定義咗智能體優先嘅操作原則。架構文檔提供域同包分層嘅頂層地圖。
一份高質素嘅文檔會對每個產品領域同架構層進行評分，並隨住時間推移追蹤差距。
計劃被視為一等工件。臨時輕量計劃用嚟做小幅變更，而複雜工作就記錄喺執行計劃入面，附帶進度同決策日誌，呢啲日誌會被提交到 code 倉庫。
活躍計劃、已完成計劃同已知嘅技術債務都已經進行版本控制並集中存放，令智能體能夠喺唔依賴外部情境嘅情況下運行。
呢個實現咗漸進式披露：智能體由一個細而穩定嘅切入點開始，並被指導下一步應該去邊度睇，而唔係一開始就被淹沒。
我哋嚴格執行呢一點。專職嘅 linter 同 CI 作業會驗證知識庫嘅更新狀況、係咪已經交叉連結同結構正確。一個定期運行嘅「doc-gardening」智能體會掃描嗰啲唔再反映真實 code 行為嘅過時或廢棄文檔，並發起修復用嘅 Pull Request。
「目標係智能體嘅可讀性」
隨住 code 庫嘅發展，Codex 嘅設計決策框架都需要隨之演變。
由於呢個 code 倉庫完全由智能體生成，因此我哋首先針對 Codex 的可讀性進行優化。就好似團隊會努力提升 code 對新入職工程師嘅可導航性一樣，我哋嘅人類工程師嘅目標都係令智能體能夠直接從 code 倉庫推理出完整嘅業務領域。
由智能體嘅角度嚟睇，佢喺運行時冇辦法喺情境中訪問嘅任何內容都係唔存在嘅。儲存喺 Google Docs、聊天記錄或者人類腦海入面嘅知識都冇辦法俾系統訪問。code 倉庫本地嘅、已版本化嘅工件（例如，code、Markdown、模式、可執行計劃）就係佢所能見到嘅全部。
我哋瞭解到，隨住時間推移，我哋需要將越來越多嘅情境推送返倉庫度。嗰次令團隊喺架構模式上達成一致嘅 Slack 討論？如果智能體冇辦法發現佢，咁佢就好似遲咗三個月入職嘅新員工一樣，對其一無所知。
為 Codex 提供更多情境意味住要組織同展示正確嘅資訊，好等智能體可以基於呢啲資訊進行推理，而唔係用臨時指令令佢負荷過重。就好似你會喺產品原則、工程規範同團隊文化（包括表情符號偏好）方面為新隊友提供引導一樣，將呢啲資訊提供俾智能體會帶嚟更一致嘅輸出。
呢個框架明確咗好多取捨。我哋傾向於選擇嗰啲可以完全內化喺倉庫入面進行推理嘅依賴同抽象。對智能體嚟講，通常被稱為「枯燥」嘅技術，由於其可組合性、API 穩定性同喺訓練集裏面嘅表現，往往更容易建立模型。
喺某啲情況下，令智能體重新實現部分功能子集比起繞過公共庫入面唔透明嘅上游行為更加抵。例如，我哋冇引入通用嘅 p-limit 風格包，反而投入咗使用自己嘅帶併發嘅 map 輔助函數：佢同我哋嘅 OpenTelemetry 儀表緊密集成，具備 100% 嘅測試覆蓋率，而且佢嘅行為完全符合我哋嘅運行時預期。
將系統嘅更多部分轉化為智能體可以檢查、驗證並直接修改嘅形式，可以直接提高槓桿效應 — 呢個唔單止適用於 Codex，亦適用於其他智能體（例如 Aardvark）都有參與 code 庫嘅開發。
「規範架構與品味」
剩係靠文檔本身，係冇辦法保持完全由智能體生成嘅 code 庫嘅連貫性嘅。通過強制執行不變量，而唔係對實施過程進行微觀管理，我哋令智能體能夠快速交付，而且唔會削弱基礎。例如，我哋要求 Codex 喺邊界處解析數據形狀，但唔規定具體實現方式。
智能體喺具有嚴格邊界同可預測結構嘅環境中最為高效，因此我哋圍繞一個嚴格嘅架構模型建立咗呢個應用。每個業務域都劃分為一組固定嘅層，依賴方向經過嚴格驗證，而且只允許有限嘅一組邊。呢啲約束係通過自定義嘅 linter（當然係由 Codex 生成嘅！）同結構測試機械咁強制執行嘅。
下圖展示規則：喺每個業務領域內（例如應用設置），code 只能「向前」依賴於一組固定嘅層（Types → Config → Repo → Service → Runtime → UI）。橫切關注點（認證、連接器、遙測、功能標誌）通過一個單一嘅顯式接口進入：Providers。其他任何內容都唔允許，並會通過自動化方式強制執行。
呢種架構通常要等到你擁有數百名工程師嗰陣先會推遲。對於編碼智能體嚟講，呢個係一個早期嘅先決條件：有咗約束，速度先唔會下降，架構先唔會漂移。
喺實踐入面，我哋通過自定義嘅 code 檢查器同結構測試嚟強制執行呢啲規則，並輔以一小組「品味不變式」。例如，我哋通過自定義 lint 靜態咁強制執行結構化日誌記錄、模式同類型嘅命名約定、檔案大小限制，以及特定平台嘅可靠性要求。由於呢啲 lint 係自定義嘅，我哋寫錯誤信息嗰陣會喺智能體情境中注入修復指令。
喺以人為本嘅工作流程中，呢啲規則可能會令人覺得迂腐或者束縛。有咗智能體，佢哋就變成咗倍增器：一旦編碼，佢哋就能立即應用於所有地方。
同時，我哋仲明確指出咗邊啲地方需要限制，邊啲地方唔需要限制。呢個就好似領導一個大型工程平台組織：喺中央層面強制執行邊界，喺本地層面允許自主權。你好重視界限、正確性同可重複性。喺呢啲邊界入面，你允許團隊或者智能體喺解決方案嘅表達方式上擁有好大嘅自由。
生成嘅 code 唔一定符合人類嘅風格偏好，呢個都冇問題。只要輸出係正確嘅、可維護嘅，而且對未來嘅智能體運行嚟講清晰易讀，就可以算係達標。
人類嘅品味會不斷反饋到系統入面。審查評論、重構嘅 Pull Request 同面向用戶嘅 Bug 會被記錄為文檔更新，或者直接編碼到工具度。當文檔唔夠完善嗰陣，我哋會將規則轉化為 code。
Harness Engineering 改變咗軟件開發
隨住 Codex 嘅吞吐量增加，好多傳統嘅工程規範變得唔再有效。
「吞吐量改變咗合併嘅理念」
呢個 code 倉庫喺運行過程中盡量減少阻塞合併門。Pull Request 嘅生命週期好短。測試偶發失敗通常通過後續重跑嚟解決，而唔係無限期咁阻礙進展。喺一個智能體吞吐量遠超人類注意力嘅系統入面，糾錯成本低，而等待成本高。
喺低吞吐量環境入面，咁做係不負責任嘅。喺呢度，呢個通常係正確嘅選擇。
「「智能體生成」實際上意味住咩」
當我哋話 code 庫係由 Codex 智能體生成嘅，我哋指嘅係成個 code 庫。
智能體嘅產出包括：
產品 code 同測試、CI 配置同發佈工具、內部開發者工具、文檔同設計歷史、評估框架、審閲評論同回覆、管理 code 倉庫本身嘅 script、生產儀錶板定義檔案
人類始終參與其中，但工作嘅抽象層次同過去唔同。
我哋優先處理工作，將用戶反饋轉化為驗收標準，並對結果進行驗證。當智能體遇到困難嗰陣，我哋會將佢視為一個信號：識別缺失嘅內容 — 工具、指導同約束、文檔，並將佢反饋到 code 倉庫度，始終由 Codex 自己寫修復。
智能體可以直接使用我哋嘅標準開發工具。佢哋會拉取審查反饋、喺行內回覆、推送更新，而且經常壓縮並合併自己嘅 Pull Request。
「不斷提高嘅自主水平」
隨住越來越多嘅開發環節被直接編碼到系統入面：包括測試、驗證、審查、反饋處理同恢復。
呢個 code 倉庫最近跨過咗一個重要門檻，令 Codex 能夠端到端咁驅動一個新功能。
畀定一個提示，智能體而家可以：
1、驗證 code 庫嘅當前狀態、重現已報告嘅漏洞、錄製一個演示故障嘅影片、實施修復措施；
2、通過運行應用程式嚟驗證修復、錄製第二個影片，演示解決方案、打開 Pull Request、回應智能體同人類反饋；
3、檢測並修復構建故障、僅喺需要判斷時先交由人工處理、合併更改。
呢種行為喺好大程度上取決於呢個 code 倉庫嘅具體結構同工具，唔應該喺冇類似投入嘅情況下假定佢可以泛化，至少目前仲未得。
我哋遇到嘅問題同展望
完全自主嘅智能體都引入咗新嘅問題。
「熵與垃圾收集」
Codex 會復現 code 倉庫入面已經存在嘅模式，甚至包括嗰啲唔均衡或者唔夠理想嘅模式。隨住時間推移，呢個無可避免咁導致漂移。
最初，人類係手動處理呢個問題嘅。我哋嘅團隊以前每星期五（佔一週嘅 20%）都要花時間清理「AI 殘渣」。唔出所料，呢個唔係 scalable 嘅做法。
相反，我哋開始將我哋稱為「黃金原則」嘅內容直接編碼到 code 倉庫度，並建立咗一個循環清理流程。呢啲原則係帶有主觀意見嘅機械規則，旨在保持 code 庫嘅可讀性同一致性，以便將來運行智能體。
例如：（1）我哋更傾向於使用共享嘅實用程式包，而唔係手工寫嘅輔助工具，以便將不變式集中管理；（2）我哋唔會使用「YOLO 式」探測數據，我哋會驗證邊界，或者依賴類型化嘅 SDK，等智能體唔會意外咁基於猜測嘅結構進行構建。
我哋會定期執行一組後台 Codex 任務，掃描偏差、更新質量等級，並發起有針對性嘅重構 Pull Request。其中大多數都可以喺一分鐘內完成審查並自動合併。
呢個本質上就係 code 庫嘅垃圾回收。技術債就好似高息貸款：每日還少少，遠比積累到還唔起嗰陣被迫清算划算得多。
人類嘅品味一旦被捕捉，就會持續應用於每一行 code。呢個亦令我哋能夠每日發現並解決不良模式，而唔係等佢哋喺 code 庫入面傳播幾日或者幾星期。
「我哋仍在學習嘅內容」
到目前為止，呢個策略喺 OpenAI 嘅內部發布同採納過程中表現良好。為真實用戶打造真實產品，幫助我哋將投資錨定喺現實中，並引導我哋實現長期嘅可維護性。
我哋仲唔清楚嘅係，喺一個完全由智能體生成嘅系統入面，架構連貫性會點樣隨住時間推移而演變。我哋仍在學習人類嘅判斷力喺邊啲方面能夠發揮最大作用，以及點樣對呢種判斷力進行編碼，令佢發揮更大作用。
我哋都唔知道，隨住時間推移，模型嘅功能不斷增強，呢個系統將點樣演變。
顯而易見嘅係：建立軟件仍然需要紀律，但紀律更多體現喺支撐結構上，而唔係 code 上。保持 code 庫一致性嘅工具、抽象同反饋迴路變得越發重要。
我哋當前最棘手嘅挑戰集中喺設計環境、反饋迴路同控制系統方面，幫助智能體實現我哋嘅目標：大規模建立同維護複雜、可靠嘅軟件。
隨住好似 Codex 呢類智能體喺軟件生命週期中佔據越來越大嘅比重，呢啲問題將變得更加重要。
我哋希望通過分享一啲早期嘅經驗教訓，幫助你理清投放精力嘅方向，等你可以直接開始建立。
讀完呢篇文檔，我最大嘅感受係：
Harness Engineering 回答咗一個好多人仲未意識到嘅問題：Agent 唔好用，大多數時候唔係模型嘅問題，係你嘅工程環境嘅問題。
佢嘅核心問題只有一個：你係咪已經畀 AI 提供咗一個佢可以自我迭代嘅環境？
呢個要求你嘅 code、數據唔係對人可讀，而係對 AI 可讀。不妨問嚇自己：
你嘅架構約束係寫喺文檔度，定係只存在於團隊嘅口頭約定入面？
你嘅測試係可以自動運行，定係需要人手動觸發？
你嘅設計決策有記錄，定係散落喺三個月前嘅聊天記錄度？
如果呢啲問題嘅答案大多數係後者，咁你嘅 Agent 就唔會發揮模型嘅最強能力，能力天花板受限於你混亂嘅工程環境。
呢個亦係點解我覺得 Harness Engineering 呢個概念會持續：每一個想令 Agent 真正做嘢嘅團隊，最終都會發現，Agent 嘅瓶頸已經唔喺模型度，而係喺你同模型搭建嘅嗰套環境。
「Harness Engineering」越早開始做，你就可以越早獲得 2026 嘅最大技術紅利。
最近，AI 圈子裏又冒出一個新詞：Harness Engineering。
不出意外，它大概率會成為 2026 年最熱的工程概念之一。
如果你關注 Agent 開發，可能已經在 X 或技術博客裏刷到過。但第一次看到這個詞的時候，我其實愣了一下。Harness? 馬具？駕馭？這跟寫代碼有什麼關係？
要理解它在說什麼，得先看一條大多數 Agent 開發者都親身走過的技術路線：
2024 年，大家聊的是提示詞工程。
那時候的核心問題很簡單：怎麼給模型寫一段好的提示詞，讓它輸出更靠譜的結果。
2025 年，光靠提示詞不夠了。
你發現模型需要知道更多東西，對話歷史、外部工具的返回結果、用戶的上下文信息，這些都得塞進去。於是「上下文工程」這個概念開始流行，本質上是在幫模型構建一個更完整的信息環境。
到了 2026，Harness Engineering，是這條技術路線的再一次進化：
它做的事情不再只是優化某一次對話的輸入，而是給 Agent 搭建一整套可運行的工程環境。代碼倉庫怎麼組織、文檔怎麼寫、反饋迴路怎麼閉合，所有這些加在一起，構成了 Agent 能不能真正幹活的基礎設施。
換個說法：提示詞工程是教模型聽懂話，上下文工程是讓模型看到全貌，Harness Engineering 則是給 Agent 搭一整套能自己幹活的工作環境：不只是告訴它做什麼，而是讓它有工具、有規則、有反饋，能獨立把活兒幹完。
PS：最直白的理解：給 Agent（幹活的牛「馬」）套一個 Harness（馬具，讓馬能拉動東西、真正幹活的整套結構）
這個概念最早從哪來的？
最早是 HashiCorp 聯創在上個月月初提出，隨後 OpenAI 則發佈了一篇文章，徹底在 AI 圈引爆了這個概念：
OpenAI 這篇文章，記錄了一個持續五個月的內部實驗：用 Codex 智能體從零構建一個真實產品，全程沒有一行人工代碼。而這篇內容，可能是目前互聯網上對 Harness Engineering 最詳細的介紹。
https://openai.com/zh-Hans-CN/index/harness-engineering/
以下是原文精校翻譯。
在過去五個月裏，我們的團隊一直在進行一項實驗：
構建並交付一款軟件產品的內部 beta 版，其中沒有一行代碼是人工編寫的。
這個產品有內部在使用的日活用戶，也有外部的 Alpha 測試者，經歷了完整的交付、部署、故障和修復流程。關鍵在於每一行代碼：包括應用邏輯、測試、CI 配置、文檔、可觀測性、內部工具，全都是 Codex 寫的。
粗略估算，整個過程只用了純手寫代碼所需時間的 1/10。
我們選擇「人類確定方向，智能體執行」這樣的方式，從而將工程速度提升數個數量級。最終，我們用了幾周的時間來交付最終達到一百萬行代碼的項目。
這迫使我們重新思考一個問題：當工程團隊的核心工作不再是寫代碼，而是設計環境、明確意圖、構建反饋迴路時，軟件開發會變成什麼樣？
這個帖子要說的是，在我們與智能體團隊一起從零開始打造一款全新產品的過程中，所能學到的經驗教訓：
哪些地方出了問題，哪些問題相互疊加，以及如何最大化利用我們唯一真正稀缺的資源，即人類的時間和注意力。
人類和 AI 如何互動的
「我們從一個空的 Git 代碼倉庫開始」
首次提交到一個空的代碼倉庫是在 2025 年 8 月下旬。
初始架構：包括代碼倉庫結構、CI 配置、格式化規則、包管理器設置和應用框架，是在一小套現有模板的指導下，由 Codex CLI 使用 GPT‑5 生成的。就連指導智能體如何在代碼倉庫中工作的初始 AGENTS.md 文件本身也是由 Codex 編寫的。
該系統沒有預存任何人工編寫的代碼。從一開始，代碼倉庫就由智能體塑造。
五個月後，該代碼倉庫已經擁有約一百萬行代碼，從應用邏輯、基礎設施、工具、文檔到內部開發者工具應有盡有。在那段時間內，大約有 1,500 個 Pull Request 被打開與合併，而推動 Codex 的僅僅是一個由三名工程師組成的小團隊。
這相當於平均每位工程師每天處理 3.5 個 PRs 的吞吐量，而且令人驚訝的是，隨着團隊規模擴大到現在的七名工程師，吞吐量甚至還增加了。重要的是，該產品已在數百名內測用戶那裏投入使用，其中包括每天都在使用的內測高級用戶。
在整個開發過程中，人類從未直接貢獻過任何代碼。這成為團隊的核心理念：不手動編寫代碼。
「重新定義工程師的角色」
由於缺乏人工編碼的實踐，工程師工作的重點轉向了系統、架構和槓桿作用。
早期進展比預想的慢，但原因不是 Codex 能力不夠，而是環境不夠清晰：該智能體缺乏實現高級目標所需的工具、抽象層和內部結構，因而無法取得進展。我們工程團隊的主要任務成了協助智能體完成有用的工作。
在實踐中，這意味着採用深度優先的工作方式：將更大的目標拆解為更小的構建模塊（設計、代碼、評審、測試等），提示智能體去構建這些模塊，並使用它們去解鎖更復雜的任務。
當事情不順利時，解法從來不是「再試一次」或「換個提示詞」。
工程師要做的是退後一步問：智能體缺什麼？是工具、是文檔、還是約束？然後把缺的東西補到代碼倉庫裏，讓它變成可發現、可執行的。
人類幾乎完全通過提示詞與系統交互：工程師描述任務，運行智能體，並允許其打開一個 Pull Request。
為了推動 PR 的完成，我們會指示 Codex 在本地審核其自身的更改，在本地和雲端請求額外的特定智能體審查，對任何人工或智能體給出的反饋做出響應，並循環往復，直到所有智能體審核人員都滿意為止。
Codex 直接使用我們的標準開發工具（本地腳本和嵌入代碼倉庫的技能）來收集情境，而無需人工將內容複製粘貼到 CLI 中。
人類可以審核 Pull Request，但並非必須這樣做。隨着時間的推移，我們已將幾乎所有的審核工作調整為用智能體對智能體的方式來處理。
「提高應用程序的可讀性」
隨着代碼吞吐量的增加，我們的瓶頸變成了人工 QA 能力。由於人類的時間和注意力是固定的限制因素，我們一直在努力通過令應用程序的 UI、日誌和應用指標等內容對 Codex 直接可讀，從而為智能體增加更多功能。
例如，我們令應用程序可以根據 git worktree 啓動，因此 Codex 可以為每次更改啓動並驅動一個實例。我們還將 Chrome DevTools 協議接入智能體運行時，並創建了用於處理 DOM 快照、屏幕截圖和導航的技能。這使 Codex 能夠復現錯誤、驗證修復，並直接推理 UI 的行為。
我們對可觀測性工具也做了同樣的處理。日誌、指標和追蹤記錄會通過一個本地可觀測性堆棧展示給 Codex，對任何給定的工作樹來說，該堆棧都是臨時的。
Codex 在該應用程序的一個完全獨立的版本上運行，一旦任務完成，該版本的所有內容，包括日誌和指標，都會被刪除。智能體可以使用 LogQL 查詢日誌，使用 PromQL 查詢指標。
有了這些情境，像“確保服務啓動在 800ms 內完成”或“這四個關鍵用戶旅程中的任何跨度都不得超過兩秒”這樣的提示就變得可行了。
我們經常看到單次 Codex 運行在單個任務上持續工作超過六個小時（通常是在人類睡眠時間）。
我們的 Harness 工程經驗
「我們將代碼倉庫設為記錄系統」
情境管理是使智能體在大型和複雜任務中有效發揮作用的最大挑戰之一。
我們學到的最早經驗教訓之一很簡單：要給 Codex 的是一張地圖，而不是一本 1,000 頁的說明書。
我們嘗試了一個大型的 AGENTS.md 方法。可想而知，這是一次失敗的嘗試：
情境是一種稀缺資源。一個巨大的指令文件會擠掉任務、代碼和相關文檔 — 因此智能體要麼會錯過關鍵約束條件，要麼開始針對錯誤的約束條件進行優化。
過多的指導反而變得無效。當一切都重要時，一切都不重要了。智能體最終會在本地進行模式匹配，而不是有意識地進行導航。
它會迅速過時。一份龐雜的手冊最終會變成過期規則的墳場。智能體無法判斷哪些信息仍然有效，一旦人類停止維護它，此文件就會悄然成為一個頗具吸引力的麻煩源頭。
它沒法自動檢查。一個大文件無法被程序化地驗證：內容是否過時、是否有遺漏、各部分是否還互相對應。所以偏差只會越積越大。
因此，我們不再將 AGENTS.md 視為百科全書，而是將其視為內容目錄。
代碼倉庫的知識庫位於一個結構化了的 docs/ 目錄中，此目錄被當作記錄系統來使用。一份簡短的 AGENTS.md（大約 100 行）被注入到情境中，主要用作地圖，並指向其他地方更深層次的真實信息來源。
AGENTS.md
ARCHITECTURE.md
docs/
├── design-docs/
│ ├── index.md
│ ├── core-beliefs.md
│ └── ...
├── exec-plans/
│ ├── active/
│ ├── completed/
│ └── tech-debt-tracker.md
├── generated/
│ └── db-schema.md
├── product-specs/
│ ├── index.md
│ ├── new-user-onboarding.md
│ └── ...
├── references/
│ ├── design-system-reference-llms.txt
│ ├── nixpacks-llms.txt
│ ├── uv-llms.txt
│ └── ...
├── DESIGN.md
├── FRONTEND.md
├── PLANS.md
├── PRODUCT_SENSE.md
├── QUALITY_SCORE.md
├── RELIABILITY.md
└── SECURITY.md
設計文檔已被編目和索引，其中包括驗證狀態和一套核心理念，定義了智能體優先的操作原則。架構文檔提供域和包分層的頂層地圖。
一份高質量的文檔會對每個產品領域和架構層進行評分，並隨着時間的推移追蹤差距。
計劃被視為一流的工件。臨時輕量計劃用於小幅變更，而複雜工作則記錄在執行計劃中，並附帶進度和決策日誌，這些日誌會被提交到代碼倉庫。
活躍計劃、已完成計劃和已知的技術債務都已進行版本控制並集中存放，使智能體能夠在不依賴外部情境的情況下運行。
這實現了漸進式披露：智能體從一個小而穩定的切入點開始，並被指導下一步該去哪裏查看，而不是一開始就被淹沒。
我們嚴格執行這一點。專職的 linter 和 CI 作業會驗證知識庫的更新狀況、是否已交叉連結且結構正確。一個定期運行的“doc-gardening”智能體會掃描那些不再反映真實代碼行為的過時或廢棄文檔，併發起修復用的 Pull Request。
「目標是智能體的可讀性」
隨着代碼庫的發展，Codex 的設計決策框架也需要隨之演變。
由於該代碼倉庫完全由智能體生成，因此我們首先針對 Codex 的可讀性進行了優化。就像團隊會努力提升代碼對新入職工程師的可導航性一樣，我們的人類工程師的目標也是讓智能體能夠直接從代碼倉庫推理出完整的業務領域。
從智能體的角度來看，它在運行時無法在情境中訪問的任何內容都是不存在的。存儲在 Google Docs、聊天記錄或人們頭腦中的知識都無法被系統訪問。代碼倉庫本地的、已版本化的工件（例如，代碼、Markdown、模式、可執行計劃）就是它所能看到的全部。
我們瞭解到，隨着時間的推移，我們需要將越來越多的情境推送到倉庫中。那次讓團隊在架構模式上達成一致的 Slack 討論？如果智能體無法發現它，那麼它就會像遲了三個月入職的新員工一樣，對其一無所知。
為 Codex 提供更多情境意味着要組織和展示正確的信息，好令智能體能夠基於這些信息進行推理，而不是用臨時指令使其不堪重負。就像你會在產品原則、工程規範和團隊文化（包括表情符號偏好）方面為新隊友提供引導一樣，將這些信息提供給智能體會帶來更一致的輸出。
這一框架明確了許多取捨。我們傾向於選擇那些可以完全內化於在倉庫中進行推理的依賴項和抽象。對智能體來說，通常被稱為“枯燥”的技術，由於其可組合性、API 穩定性和在訓練集裏的表現，往往更容易建立模型。
在某些情況下，讓智能體重新實現部分功能子集比繞過公共庫中不透明的上游行為更便宜。例如，我們沒有引入通用的 p-limit 風格包，而是投入使用了我們自己的帶併發的 map 輔助函數：它與我們的 OpenTelemetry 儀表緊密集成，具備 100% 的測試覆蓋率，並且其行為完全符合我們的運行時預期。
將系統的更多部分轉化為智能體可以檢查、驗證並直接修改的形式，可以直接提高槓杆效應 — 這不僅適用於 Codex，也適用於其他智能體（例如 Aardvark） 也在參與代碼庫的開發。
「規範架構與品味」
僅靠文檔本身，是沒法保持完全由智能體生成的代碼庫的連貫性的。通過強制執行不變量，而非對實施過程進行微觀管理，我們令智能體能夠快速交付，而且不會削弱基礎。例如，我們要求 Codex 在邊界處解析數據形狀，但不規定具體實現方式。
智能體在具有嚴格邊界和可預測結構的環境中最為高效，因此我們圍繞一個嚴格的架構模型構建了該應用。每個業務域都劃分為一組固定的層，依賴方向經過嚴格驗證，並且僅允許有限的一組邊。這些約束是通過自定義的 linter（當然是由 Codex 生成的！）和結構測試機械地強制執行的。
下圖展示了規則：在每個業務領域內（例如應用設置），代碼只能“向前”依賴於一組固定的層（Types → Config → Repo → Service → Runtime → UI）。橫切關注點（認證、連接器、遙測、功能標誌）通過一個單一的顯式接口進入：Providers。其他任何內容都不被允許，並將通過自動化方式強制執行。
這種架構通常要等到你擁有數百名工程師時才會推遲。對於編碼智能體來說，這是一個早期的先決條件：有了約束，速度才不會下降，架構才不會漂移。
在實踐中，我們通過自定義的代碼檢查器和結構測試來強制執行這些規則，並輔以一小組“品味不變式”。例如，我們通過自定義 lint 靜態地強制執行結構化日誌記錄、模式和類型的命名約定、文件大小限制，以及特定平台的可靠性要求。由於這些 lint 是自定義的，我們編寫錯誤信息時會在智能體情境中注入修復指令。
在以人為本的工作流程中，這些規則可能會讓人感到迂腐或束縛。有了智能體，它們就成了倍增器：一旦編碼，它們就能立即應用於所有地方。
同時，我們還明確指出了哪些地方需要限制，哪些地方不需要限制。這類似於領導一個大型工程平台組織：在中央層面強制執行邊界，在本地層面允許自主權。你非常重視界限、正確性和可重複性。在這些邊界內，你允許團隊或智能體在解決方案的表達方式上擁有很大的自由。
生成的代碼不總是符合人類的風格偏好，這也沒關係。只要輸出是正確的、可維護的，並且對未來的智能體運行而言清晰易讀，就可以算作達標。
人類的品味會不斷反饋到系統中。審查評論、重構的 Pull Request 和麪向用戶的 Bug 會被記錄為文檔更新，或直接編碼到工具中。當文檔不夠完善時，我們會將規則轉化為代碼。
Harness Engineering 改變了軟件開發
隨着 Codex 的吞吐量增加，許多傳統的工程規範變得不再有效。
「吞吐量改變了合併的理念」
該代碼倉庫在運行過程中儘量減少阻塞合併門。Pull Request 的生命週期很短。測試偶發失敗通常通過後續重跑來解決，而不是無限期地阻礙進展。在一個智能體吞吐量遠超人類注意力的系統中，糾錯成本低，而等待成本高。
在低吞吐量環境中，這樣做是不負責任的。而在這裏，這通常是正確的選擇。
「“智能體生成”實際上意味着什麼」
當我們說代碼庫是由 Codex 智能體生成的，我們指的是整個代碼庫。
智能體的產出包括：
產品代碼與測試、CI 配置和發佈工具、內部開發者工具、文檔和設計歷史、評估框架、審閲評論和回覆、管理代碼倉庫本身的腳本、生產儀表板定義文件
人類始終參與其中，但工作的抽象層次與過去不同。
我們優先處理工作，將用戶反饋轉化為驗收標準，並對結果進行驗證。當智能體遇到困難時，我們將其視為一個信號：識別缺失的內容 — 工具、指導與約束、文檔，並將其反饋到代碼倉庫中，始終由 Codex 自己編寫修復。
智能體可以直接使用我們的標準開發工具。他們會拉取審查反饋、在行內回覆、推送更新，並且經常壓縮併合並他們自己的 Pull Request。
「不斷提高的自主水平」
隨着越來越多的開發環節被直接編碼到系統中：包括測試、驗證、審查、反饋處理和恢復。
該代碼倉庫最近跨過了一個重要門檻，使 Codex 能夠端到端地驅動一個新功能。
給定一個提示，智能體現在可以：
1、驗證代碼庫的當前狀態、重現已報告的漏洞、錄製一個演示故障的視頻、實施修復措施；
2、通過運行應用程序來驗證修復、錄製第二個視頻，演示解決方案、打開 Pull Request、回應智能體和人類反饋；
3、檢測並修復構建故障、僅在需要判斷時才交由人工處理、合併更改。
此行為在很大程度上取決於此代碼倉庫的具體結構和工具，不應在沒有類似投入的情況下假定它可以泛化，至少目前還不行。
我們遇到的問題和展望
完全自主的智能體也引入了新的問題。
「熵與垃圾收集」
Codex 會復現代碼倉庫中已存在的模式，甚至包括那些不均衡或不夠理想的模式。隨着時間的推移，這不可避免地導致漂移。
最初，人類是手動處理這個問題的。我們的團隊過去每週五（佔一周的 20%）都要花時間清理“AI 殘渣”。不出所料，那並不具備可擴展性。
相反，我們開始將我們稱為“黃金原則”的內容直接編碼到代碼倉庫中，並建立了一個循環清理流程。這些原則是帶有主觀意見的機械規則，旨在保持代碼庫的可讀性和一致性，以便將來運行智能體。
例如：（1）我們更傾向於使用共享的實用程序包，而不是手工編寫的輔助工具，以便將不變式集中管理；（2）我們不會使用“YOLO 式”探測數據，我們會驗證邊界，或依賴類型化的 SDK，這樣智能體就不會意外地基於猜測的結構進行構建。
我們會定期運行一組後台 Codex 任務，掃描偏差、更新質量等級，併發起有針對性的重構 Pull Request。其中大多數都可以在一分鐘內完成審查並自動合併。
這本質上就是代碼庫的垃圾回收。技術債就像高息貸款：每天還一點，遠比攢到還不起時被迫清算划算得多。
人類的品味一旦被捕捉，就會持續應用於每一行代碼。這也使我們能夠每天發現並解決不良模式，而不是讓它們在代碼庫中傳播數天或數週。
「我們仍在學習的內容」
到目前為止，這一策略在 OpenAI 的內部發布和採納過程中表現良好。為真實用戶打造真實產品，幫助我們將投資錨定在現實中，並引導我們實現長期的可維護性。
我們尚不清楚的是，在一個完全由智能體生成的系統中，架構連貫性會如何隨着時間的推移而演變。我們仍在學習人類的判斷力在哪些方面能發揮最大作用，以及如何對這種判斷力進行編碼，使其發揮更大作用。
我們也不知道，隨着時間的推移，模型的功能不斷增強，這一系統將如何演變。
顯而易見的是：構建軟件仍然需要紀律，但紀律更多地體現在支撐結構上，而不是代碼上。保持代碼庫一致性的工具、抽象和反饋迴路變得越發重要。
我們當前最棘手的挑戰集中在設計環境、反饋迴路和控制系統方面，幫助智能體實現我們的目標：大規模構建和維護複雜、可靠的軟件。
隨着像 Codex 這樣的智能體在軟件生命週期中佔據越來越大的比重，這些問題將變得更加重要。
我們希望通過分享一些早期的經驗教訓，幫助你理清投入精力的方向，以便你可以直接開始構建。
讀完這篇文檔，我最大的感受是：
Harness Engineering 回答了一個很多人還沒意識到的問題：Agent 不好用，大多數時候不是模型的問題，是你的工程環境的問題。
它的核心問題只有一個：你是否給 AI 提供了一個它可以自我迭代的環境？
這要求你的代碼、數據不是對人可讀，是對 AI 可讀。不妨自問一下：
你的架構約束是寫在文檔裏，還是隻存在於團隊的口頭約定中？
你的測試能被自動運行，還是需要人手動觸發？
你的設計決策有記錄，還是散落在三個月前的聊天裏？
如果這些問題的答案大多是後者，那你的 Agent 就不會發揮模型的最強能力，能力天花板受限於你混亂的工程環境。
這也是為什麼我覺得 Harness Engineering 這個概念會持續：每一個想讓 Agent 真正幹活的團隊，最終都會發現，Agent 的瓶頸已經不在模型了，而在你給模型搭的那套環境。
「Harness Engineering」越早開始做，你就可以越早獲得 2026 的最大技術紅利。