以天為單位革新的AI圈，Harness早已不算什么新詞

2026年2月，OpenAI 在官方博客發表了一篇名為《Harness Engineering: Leveraging Codex in an Agent-First World》的文章。核心內容只有一件事：一個三人工程師小組，用五個月時間，完全依靠 AI Agent 交付了約 100 萬行代碼、1500 個 Pull Request，全程沒有任何人手動寫過一行代碼。

數字本身并不稀奇，真正值得關注的是這件事發生的時間節點，以及它背后折射出來的工程范式轉變。

三個人，五個月，一個不成文的規定

2025年8月，OpenAI 內部一個三人小組承接了一個新產品開發任務。他們給自己設了一條規則：所有代碼必須由 Codex AI Agent 生成，人類工程師不動鍵盤寫代碼。

五個月后，產品上線。代碼庫約 100 萬行，人均每天合并 3.5 個 Pull Request。Martin Fowler 在評價這項實驗時說：“Harness Engineering 包含了上下文工程、架構約束和垃圾回收，是對 AI 賦能軟件開發的一種有價值的框架性闡述。”

這個實驗之所以值得關注，不是因為它證明了 AI 能寫代碼——這一點早已無需證明——而是因為它回答了一個更具體的問題：當 AI 真的可以承擔大部分編碼工作時，工程師究竟該做什么？

“駕馭”是什么意思

Harness，在英文里本義是馬具、挽具——不是讓你騎馬，而是讓馬老老實實拉車。OpenAI 用這個詞，是在描述一種特定的工程師角色：不再生產代碼，而是設計一個讓 AI 能把事做對的環境。

這和“Prompt Engineering”有本質區別。寫提示詞是告訴 AI 怎么做這件事；Harness Engineering 是提前把“這件事的上下文、約束和驗證方式”設計成 AI 可以理解的結構，讓它在這個環境里自主運行。

三人團隊的核心實踐可以拆成幾個具體動作：

他們寫了一份叫 AGENTS.md 的文檔，只有 100 行。這不是使用手冊，而是索引——里面存的是架構圖、設計規范和執行計劃的入口，類似代碼庫的 README，但服務對象是 Agent 而不是人類。規則很嚴格：關鍵知識只能活在代碼庫里，禁止散落在 Slack 消息或口口相傳的討論里。

他們給 Agent 裝上了眼睛。通過集成 Chrome DevTools，Agent 可以自己截圖驗證 UI 渲染結果，不需要人類反復確認頁面對不對。Agent 寫完代碼、運行測試、看截圖、發現問題、自己修，形成一個閉環。

他們刻意選擇“無聊”的技術棧。這條實踐看起來反直覺，但邏輯很清晰：訓練數據里出現越多的庫和框架，Codex 對它的理解就越準確，出錯率越低。用冷門的新庫，等于讓 AI 在沒有地圖的地方開車。

還有一個被他們稱為“垃圾回收”的機制：后臺運行一個周期性 Agent，定期掃描代碼庫里的技術債——過時的依賴、被注釋的死代碼、違反架構約束的模塊——自動提交修復 PR。人類工程師不需要主動觸發這件事，它就在那里自動跑著。

Cursor 的對照實驗

幾乎在同一時期，Cursor 團隊做了一個更極端的實驗：用數百個 Agent 并行運行整整一周，從零開始用 Rust 寫一個瀏覽器引擎，最終產出超過 100 萬行代碼。

這個實驗一開始并不順利。第一版架構讓所有 Agent 地位平等，通過共享狀態文件協調工作。結果 20 個 Agent 的吞吐量退化到相當于 1 至 3 個 Agent。原因是典型的“風險厭惡”：在沒有明確分工的情況下，每個 Agent 都傾向于只做安全的小修改，真正復雜的任務沒有人敢碰。

后來他們試過流水線（Planner-Executor-Worker-Judge），又試過讓 Executor 同時承擔規劃職能——每次都有改進，也有新的瓶頸。最終跑通的方案是“遞歸 Planner 加獨立 Worker”：根 Planner 持有全局視野，當任務可以繼續分解時遞歸生成子 Planner；每個 Worker 只接觸自己負責的那份代碼副本，互不感知，完成后提交交接報告。

Cursor 自己總結這個實驗的核心發現時說：高吞吐量 Agent 開發需要接受“不完美但快速迭代”的哲學，而不是追求一次性完美。允許一個穩定的低錯誤率，讓后續 Agent 快速修復，反而比強制 100% 正確率更有效。

兩個團隊，兩套實驗，在同一個時間節點獨立得出了基本相同的結論：人類工程師的核心價值，正在從寫代碼轉向設計 AI 的工作環境。

爆火的“龍蝦”成為這套方法論最佳實例

Harness Engineering 發布的兩周前，另一件事剛剛發生。

奧地利開發者 Peter Steinberger 在2025年11月某個周末寫了一段腳本，讓 Claude 通過 WhatsApp 控制電腦。這個項目最初叫 Clawdbot，發布當天在 Hacker News 上走紅，隨即遭到 Anthropic 的商標律師函（“Clawd”與 Anthropic 產品名“Claude”沖突）。幾小時內改名 Moltbot，Twitter 賬號立即被加密貨幣騙子搶注。三天內第三次定名 OpenClaw，同步完成商標檢索和 34 個安全加固提交。

這場品牌危機意外帶來了更大的曝光。2026年1月底，OpenClaw 的 GitHub Stars 突破 20 萬，成為有記錄以來增長最快的開源 AI Agent。對比：Linux 達到 10 萬 Star 用了 12 年，React 用了 8 年。

Steinberger 后來在博客里寫，OpenClaw 的核心使命是“讓我媽媽這樣的普通用戶也能用上 AI Agent”。它的架構設計和 Harness Engineering 的底層邏輯高度吻合：不是構建一個復雜的 AI 模型，而是設計一套讓人類能夠安全、靈活駕馭 Agent 的接入層——標準化的技能接口、細粒度的權限控制、本地化部署支持。

2026年2月15日，Sam Altman 宣布 Steinberger 加入 OpenAI，負責“下一代個人智能體”研發。項目本身移交獨立基金會，MIT 協議不變，OpenAI 作為贊助方。Steinberger 寫道，加入 OpenAI 是實現這個愿景的“最快路徑”，而且他本質上是一個建造者，不是一個想經營大公司的人。

一個月后的 GTC 大會，NVIDIA CEO 黃仁勛在主會場演講中將 OpenClaw 與 Linux、Kubernetes 并列，發布基于它的企業級安全層 NemoClaw——運行在 OpenClaw 之下，提供內核級沙箱、進程外策略引擎和隱私路由三項能力。目標是讓企業能在自有硬件上安全部署 Agent，同時滿足數據主權要求。

TechCrunch 的標題直接點破了這件事的邏輯：“NVIDIA 的版本能解決 OpenClaw 最大的問題：安全。”

Harness Engineering 談的是工程師如何“駕馭”AI；NemoClaw 回答的是企業如何把這套駕馭建立在可信的基礎設施上。兩件事拼在一起，完整描述了 2026 年上半年硅谷 AI 工程實踐的演變方向。

一個悖論

這套方法論的傳播速度很快，質疑也隨之而來。

Anthropic 做了一項調查，數據顯示 Harness Engineering 風格的工作方式讓工程師生產力提升了 50%。但調查同時發現了一個問題：工程師依賴 AI Agent 的時間越長，獨立判斷 AI 輸出質量的能力就越弱。換句話說，你駕馭得越熟練，你對“馬”的理解反而越模糊。

OpenClaw 社區自己也給這個隱憂提供了具體注腳。CVE-2026-25253 漏洞讓約 4 萬臺 OpenClaw 實例暴露于遠程代碼執行風險；ClawHub 技能平臺遭遇惡意投毒（ClawHavoc事件），Bitdefender 和微軟相繼發出警告，稱不應直接在企業工作站上運行未經審查的 OpenClaw Agent。

“駕馭”并不只是效率問題，也是對風險的感知與控制能力。真正的問題或許不是這套方法論是否有效，而是當工程師越來越擅長設計 AI 的工作環境，卻越來越難以直接審計 AI 的工作結果，這中間的那段信任，究竟該落在哪里。

這個問題，Harness Engineering 的博文里沒有答案，OpenClaw 的代碼庫里也沒有。

參考來源：

• https://openai.com/index/harness-engineering/
  

• https://cursor.com/blog/self-driving-codebases
  

• https://steipete.me/posts/2026/openclaw
  

• https://techcrunch.com/2026/03/16/nvidias-version-of-openclaw-could-solve-its-biggest-problem-security/
  

• https://investor.nvidia.com/news/press-release-details/2026/NVIDIA-Announces-NemoClaw-for-the-OpenClaw-Community/default.aspx

• https://www.cnbc.com/2026/02/15/openclaw-creator-peter-steinberger-joining-openai-altman-says.html