3 個工程師、5 個月、100 萬行代碼、零手寫代碼。

可能你會覺得很離譜

但是后來和幾個朋友聊，有個朋友在公司就他 1 個人，2 周，3 萬塊錢，用 Claude Code 做了一個產品上線到了 App Store。

他怎么做到的？，他只是學會了 Harness Engineering。

先說一個真實的對話。

我跟朋友解釋 Harness Engineering，說這是”人給 AI 搭建好運行環(huán)境，來駕馭 AI 更高效地工作”。

她聽完點點頭，問我：那我給電腦插電源、按開機鍵，也算給 AI 搭環(huán)境了？

我愣了一秒。

字面上講，插電源確實是”讓 AI 能運行”的前提。但如果插電源也算，那”做任何準備工作”都叫 Harness Engineering，這個詞就沒有意義了。

這個對話幫我把概念的邊界逼清楚了：

Harness Engineering 不是給人用電腦的基礎設施，而是專門為 AI Agent 自主工作而設計的運行環(huán)境。

區(qū)別在”自主”兩個字。

你開機，是為了讓自己能干活。Harness Engineering 要解決的問題是：當你不在旁邊的時候，AI Agent 也能把任務干好，干對，干完。

這需要三件事到位。

說白了，Harness Engineering 就是給 AI Agent 造一個”能干活的工作間”。工具備齊、信息有序、標準明確，它才能自主工作。

這跟之前流行的 Prompt Engineering 和 Context Engineering 不是同一層次的事。Prompt Engineering 解決的是怎么跟 AI 說話，Context Engineering 解決的是喂給 AI 什么信息，而 Harness Engineering 解決的是給 AI 造一個什么樣的工作環(huán)境。

前兩個是對話層，后一個是系統(tǒng)層。

有個類比我覺得挺貼切的。一個新員工入職，你可以教他怎么跟你匯報（Prompt Engineering），你可以把相關背景材料發(fā)給他看（Context Engineering），但這兩件事加起來，并不等于他能獨立工作。他還需要一個東西：一個配好了工具、定好了流程、說清楚了評判標準的工作環(huán)境。他知道該去哪里找資料，知道手邊有什么工具可以用，知道做完一件事對不對的判斷標準是什么。

這個”工作環(huán)境”，才是 Harness Engineering 做的事。

地圖告訴它方向在哪、路徑怎么走。說明書把每一步都寫死，Agent 讀完要么照本宣科，要么被信息量壓垮。一個真正能自主工作的 Agent，需要的是地圖。

我看完這句話的時候，想到了自己之前在項目里踩的坑。

我們當時也做了一份”說明書”，一份超長的 System Prompt，把所有情況都試圖覆蓋，結果 Agent 一方面會漏看重要約束，另一方面又會在不重要的細節(jié)上糾結太久。

后來才明白，信息不是越多越好，關鍵是在對的時候給到對的信息。

我在真正把 Harness 搭好之前，也經歷過那個階段。

用 AI Agent 做項目，到處是坑。跑一半突然偏，輸出時好時壞，人根本離不開。我當時以為是模型不夠好，換了幾個底模，發(fā)現(xiàn)換完還是一樣的問題。后來才意識到，真正的問題不是模型，是環(huán)境。

模型就像一個能力很強的人。但能力強，不等于給他一個亂成一團的工作環(huán)境，他也能干好活。

沒做好 Harness 的時候，AI Agent 會卡在三個地方。

我遇到過一個很典型的情況。一個 Agent 跑到中途，把最開始給它的格式要求”忘了”，開始按自己的理解輸出，輸出的結果結構完全不對，但它自己不知道，還以為任務完成了。你如果不在旁邊盯著，等它最終輸出以后，你會發(fā)現(xiàn)，根本不能用。

很多任務，Agent 光靠想做不到。要查系統(tǒng)日志，得有查詢接口；要驗證頁面效果，得能打開瀏覽器；要跑自動化測試，得有測試框架。工具沒有提前備好，Agent 就會陷入一種尷尬的狀態(tài)：知道下一步要做什么，但沒有手段執(zhí)行，只調用llm直接回復應付或者干脆跳過。

這是最隱蔽的問題，也是我覺得最值得認真對待的一個。

Agent 完成一個子任務，它自己判斷”好了”，但這個判斷依據是什么？沒有明確定義的話，它可能把一個有明顯 bug 的輸出交給你，因為它認為”能跑起來就算完成”。或者反過來，它會因為某個無關緊要的細節(jié)沒處理好，一直在那里反復跑，浪費了大量時間。

搭好 Harness 之后，這三個困境都有了對應的解法。

Ryan 團隊的 Codex，單次運行可以在一個任務上持續(xù)工作超過六個小時，通常是在人類睡覺的時候。它自己打開瀏覽器驗證 UI，自己查日志找 bug，自己跑測試，自己修了再驗證，最后打開一個 Pull Request，附上執(zhí)行記錄。整個過程，人類不在場。

這不是因為它用的模型有多特別。是因為它有一個搭得足夠好的 Harness。

對比一下就很清楚了。同樣是 AI Agent，同樣是復雜任務，有 Harness 的跑六個小時自主完成，沒有 Harness 的跑半小時就得人來救火。差距不在模型，在環(huán)境。

說完理論，講點實際的。

去年我在公司做過一個 Multi-Agent 項目，叫 product_demo_video_agent。目標是讓用戶上傳一張商品圖，AI 自動生成一條產品展示視頻。聽起來很直接，但實現(xiàn)起來是一個完整的多 Agent 協(xié)作系統(tǒng)。

整個系統(tǒng)的設計是這樣的。

用戶輸入進來之后，先經過一個主 Agent（product_demo_video_agent）做路由規(guī)劃，子Agent_1（pdv_proposal_agent）這個 Agent 負責理解用戶的商品，分析適合的視頻風格和鏡頭語言，輸出一個完整的視頻制作方案。然后把這個方案交給子 Agent_2（pdv_generate_agent）生成產品分鏡圖，子 Agent_3（pdv_generate_video_agent） 根據分鏡圖產出分鏡片段視頻，并調用合并工具、音頻生成工具合成最終大約20s的視頻。

四個 Agent 各司其職，理論上跑得很順。但只是理論上。

實際跑起來，卡了很久，踩了兩個很典型的坑。

比如兩個 Agent 之間需要傳數據。主 Agent 把分析好的方案傳給子 Agent，子 Agent 再根據用戶需求生成方案。聽起來很自然，但主 Agent 輸出的”方案”是什么格式？是自然語言描述？還是結構化的 JSON？字段名是什么？必填項是哪些？視頻時長、鏡頭數量、風格關鍵詞，這些子 Agent 需要的信息，主 Agent 有沒有都輸出？

這些問題如果沒有提前定義，就會出問題。

我們遇到的情況是，主 Agent 有時候輸出一整段自然語言描述，有時候是半結構化的數據，字段名也不固定，有時候叫style，有時候叫video_style，有時候這個字段直接不出現(xiàn)。子 Agent 拿到這個”方案”，不知道該讀哪里，只能自己猜。猜對了還好，猜錯了就生成出偏差的結果，甚至直接報錯停掉。

排查起來特別痛苦。因為你不知道是主 Agent 的問題、子 Agent 的問題，還是中間傳遞的問題，全鏈路都得看一遍，找那個到底是哪里斷了。

做完之后，兩個 Agent 之間的傳遞幾乎不再出錯了。更重要的是，一旦出錯，我們能很快定位是哪個字段的問題，排查時間從幾小時縮短到幾分鐘。

這其實就是一種 Harness Engineering 的實踐。把 Agent 之間的接口定義清楚，讓每個 Agent 只需要關注自己負責的那一段，輸入是什么、輸出是什么，不需要猜，不需要兼容各種可能的格式變體。

字段問題解決之后，下一個問題來了：輸出質量忽高忽低。

同樣的輸入，有時候主 Agent 給出的視頻方案很精準，描述清晰，鏡頭邏輯合理，子 Agent 照著做出來的效果很好。有時候同樣的輸入，主 Agent 給出的方案很模糊，關鍵信息缺失，子 Agent 只能靠猜，最終生成的視頻就差很多。

這種不穩(wěn)定在 Multi-Agent 項目里最讓人頭疼，因為很難復現(xiàn)，你很難找到一個確定的原因說”因為 XX 所以這次質量差”。

我們試了兩個方向。

一個是模型選型調整。換了更強的底模跑主 Agent，穩(wěn)定性確實提升了不少，輸出質量的方差明顯縮小了。但成本也跟著上去了，而且強模型也不是萬能的，在某些特定場景下還是會飄。

另一個是 System Prompt 微調。這是更精細的調法，也是我覺得更治本的方向。我們把主 Agent 的 Prompt 拆開來分析，哪些指令它容易理解、哪些容易誤解、哪些場景下容易生成質量差的方案。然后針對性地改，把模糊的指令寫具體，把容易出錯的邊界情況加進去，把期望的輸出格式用示例說明，用幾個好的樣本告訴它”這種質量才算及格”。

有時候基本上是按照日期來定義版本名，System Prompt需要不斷微調。

兩個方向結合起來用，效果明顯好了很多。

這個過程讓我意識到一件事：輸出質量不穩(wěn)定，本質是因為 Agent 對”什么是好輸出”沒有明確認知。它不知道什么叫合格，只能靠自己的理解猜測，而不同的請求里這個猜測的結果就會波動。

Prompt 優(yōu)化，其實就是在做 Harness，把驗收標準提前編碼進 Agent 的工作指令里，給它一個更清晰的參照系。讓它在生成內容的時候，有一個具體的”對”的標準可以對照，而不是憑感覺。

字段定義是在規(guī)范接口，Prompt 微調是在規(guī)范品質。前者解決數據怎么傳，后者解決內容怎么對，合在一起，整個 Multi-Agent 系統(tǒng)才跑得穩(wěn)，才能真正減少人工介入的頻率。

講完坑，講方法。

但實際結果是，Agent 一打開就被淹沒，重要信息找不到，過時信息刪不完，維護成本高得離譜。而且更關鍵的是，當你什么都告訴它，它反而不知道什么重要。模型在處理超長 Prompt 時會出現(xiàn)注意力分散的問題，早期的信息容易被后面的覆蓋，重要的約束可能就這樣被漏掉了。

他們后來的做法是把AGENTS.md瘦身到大約 100 行，只做一件事：告訴 Agent”你需要的信息在哪里”

AGENTS.md 是一張地圖，不是一本書。Agent 需要什么，自己去對應位置讀取，不是一次性消化所有內容。

他們團隊意識到，當 Agent 的吞吐量增加之后，人工 QA 成了瓶頸。人的時間和注意力有限，每次 Agent 跑完都要人來驗證，這件事本身就不可擴展。規(guī)模上不去，不是因為 Agent 能力不夠，是因為人類的驗證能力跟不上。

解決方案是把驗證能力也交給 Agent。

這意味著什么？

像”確保服務啟動在 800ms 內完成”、”這四個核心用戶旅程的請求耗時不得超過 2 秒”這樣的指令，Agent 自己就能跑完驗證，不需要人來盯著看。

對我們做產品的人來說，遷移過來的邏輯是：你給 Agent 的任務，要讓它有能力自己檢驗結果。

如果 Agent 只能生成內容，卻無法驗證內容是否符合要求，那驗收這一環(huán)就永遠壓在人身上。你的 Agent 系統(tǒng)的吞吐量天花板，就是你能做 QA 的速度上限。

想突破這個天花板，就要把驗證能力也設計進去，把”對不對”的判斷權交給 Agent 自己。

這一點聽起來最反直覺，但我覺得也是最值得細說的一條。

Ryan 團隊給代碼庫設計了一套嚴格的分層架構。每個業(yè)務域有固定的層級結構，依賴方向經過驗證，什么模塊可以調用什么、什么不行，都有明確規(guī)定，并且用自定義 linter 強制執(zhí)行。違反了規(guī)則的代碼，直接報錯，不讓合并。

為什么要早做？因為 Agent 在有嚴格邊界和可預測結構的環(huán)境里，才能跑得最快、跑得最穩(wěn)。約束越清晰，它越不會往錯誤方向試探，越不會引入不一致的寫法，整個代碼庫也越不會隨著吞吐量增加而悄悄腐爛。

而且有一個細節(jié)特別聰明：他們在自定義 linter 的錯誤信息里，直接寫上修復指令。Agent 觸發(fā)了一條規(guī)則，錯誤信息不只告訴它”這里違規(guī)了”，還告訴它”你應該這樣改”。

這樣的約束對 Agent 來說不是束縛，是引導。它不需要猜測”這里怎么做才對”，規(guī)則本身就包含了答案。一旦規(guī)則到位，Agent 的速度和質量都會提升，而不是因為被約束變慢。

這和我做 Multi-Agent 時候的邏輯是一樣的，給字段下定義、給 Prompt 寫清楚期望格式和示例，都是在做規(guī)則化，把本來需要 Agent 自己猜測的東西，變成清晰可執(zhí)行的約束。

規(guī)則越清晰，Agent 越自由。這句話聽起來矛盾，但確實是真的。

對了，還有一件容易被忽略的事：垃圾要定期回收。

Ryan 提到一個有趣的現(xiàn)象，Agent 會復現(xiàn)代碼庫里已有的模式，包括那些不夠好的模式。因為 Agent 在生成新代碼時，會參考已有的代碼風格和寫法，如果里面有壞的寫法，它就會把壞的寫法繼續(xù)用下去，甚至傳播開來。隨著時間積累，不好的寫法越來越多，代碼庫會慢慢腐爛。

他們一開始靠人工清理，每周五花 20% 的時間專門處理”AI 殘渣”。顯然不可擴展，而且這本身就是一種諷刺，用人力去清理 AI 制造的垃圾。

后來的做法是，定期跑一組后臺 Agent 任務，專門掃描偏差、更新質量評分、發(fā)起針對性的重構 PR。大多數 PR 可以在一分鐘內審完自動合并，人工幾乎不需要參與。

技術債像利息，每天還一點，好過攢著等崩。這個道理大家都懂，但真正做到的很少。有了 Agent 做垃圾回收，這件事終于變得可執(zhí)行了。

說到這里，想聊一個更大的問題：這一切最終走向哪里？

人類的角色，已經從”寫代碼的人”變成了”設計系統(tǒng)的人”。

他用一句話總結：人類掌舵，智能體執(zhí)行。

我覺得這不是遙遠的未來，是正在發(fā)生的現(xiàn)在。而且不只是在軟件工程領域，任何依賴 AI Agent 協(xié)作的工作，都在經歷這個轉變。

我自己在做 Multi-Agent 項目的過程中，也明顯感受到了這個變化。我花在”寫 Prompt、定規(guī)范、搭結構”上的時間，比寫任何具體內容都多。有時候一天都在改 System Prompt，在想怎么讓 Agent 更穩(wěn)定，在設計字段定義，在寫 Benchmark 用例。工作重心已經從”產出”移到了”搭環(huán)境”。

一開始我有點不適應，覺得自己好像沒在”干活”。后來才想明白，這本來就是更重要的工作。環(huán)境搭好了，Agent 跑起來，產出是指數級的。環(huán)境搭不好，Agent 再強，也是一個需要人工輔導的實習生。

所以我對人和 AI 協(xié)同的最終狀態(tài)，有三個判斷。

這是最直接的分工變化。寫代碼、生成內容、跑流程、處理數據，這些執(zhí)行層面的事 Agent 會越來越擅長，越來越快，越來越準。而人的工作，是把環(huán)境準備好：信息結構、工具集合、驗收規(guī)則，這些是 Agent 能不能干好活的地基。

地基搭得越好，Agent 干得越穩(wěn)，你能解放的時間就越多。

這個分工不是”人監(jiān)督 AI”，那樣依然很累。而是”人設計系統(tǒng)，AI 運行系統(tǒng)”，設計是一次性的工作，運行是持續(xù)自動的。

給定一個模糊的目標，Agent 可以比任何人更快地探索可能性，發(fā)散方案，生成選項。它不會累，不會說”這個方向我沒試過，不確定”，它可以同時跑十個方向，把每個方向的結果都擺在你面前。

但方向對不對，目前還是人來判斷。

人提方向，AI 鋪開所有可能性，然后人從里面挑。這個節(jié)奏，已經是很多團隊現(xiàn)在的工作模式了。產品經理給一個方向，Agent 生成十個方案，PM 挑選并調整，Agent 繼續(xù)細化。這個循環(huán)跑起來，效率比任何傳統(tǒng)方式都高。

這條說的是更深層的東西，也是我認為最核心的一條。

Agent 在執(zhí)行任務時，本質上是在一套規(guī)則和約束下運作的。這套規(guī)則，要人來定。什么能做，什么不能做，什么算好，什么算壞，什么情況下輸出達標，什么情況下要人介入，這些判斷目前都是人的責任。

AI 能非常嚴格地執(zhí)行規(guī)則，但它不能自己判斷這套規(guī)則是否合理，是否適合當前的場景，是否需要在某個特殊情況下靈活處理。這個判斷力，是人類目前仍然不可替代的核心能力。

所以未來的工程師，或者更廣義地說，未來依靠 AI 協(xié)作工作的人，核心能力會變成：搭好環(huán)境的能力、定義清晰規(guī)則的能力、在關鍵節(jié)點做方向判斷的能力。

寫代碼、寫內容、做執(zhí)行，這些會越來越不稀缺。稀缺的是能把 Harness 搭好的人，是能清楚地知道”什么是好結果”并把這個標準表達清楚的人。

能力的重心在向上移，從執(zhí)行層移到系統(tǒng)設計層。

他在結尾寫，他們還在學習。還不知道一個完全由 Agent 生成的系統(tǒng)在架構連貫性上會如何隨時間演變，還不知道人類的判斷力在哪些地方能發(fā)揮最大作用，還不知道這一切隨著模型能力增長會怎么變化。

我覺得這個坦誠很有價值。Harness Engineering 不是一個有標準答案的領域，它太新了，所有人都在邊做邊摸索。Ryan 他們在 OpenAI 內部的探索，是目前最前沿的實踐之一，但也只是一種可能性，不是唯一答案。

但有一件事是確定的：AI 的能力在增長，但 Agent 能發(fā)揮多少，取決于它工作的環(huán)境有多好。

你搭的環(huán)境有多好，它就能干多好。

這不是一個技術問題，是一個工作方式的問題。