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

可能你會覺得很離譜

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

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

先說一個(gè)真實(shí)的對話。

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

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

我愣了一秒。

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

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

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

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

你開機(jī)，是為了讓自己能干活。Harness Engineering 要解決的問題是：當(dāng)你不在旁邊的時(shí)候，AI Agent 也能把任務(wù)干好，干對，干完。

這需要三件事到位。

說白了，Harness Engineering 就是給 AI Agent 造一個(gè)”能干活的工作間”。工具備齊、信息有序、標(biāo)準(zhǔn)明確，它才能自主工作。

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

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

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

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

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

我看完這句話的時(shí)候，想到了自己之前在項(xiàng)目里踩的坑。

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

后來才明白，信息不是越多越好，關(guān)鍵是在對的時(shí)候給到對的信息。

我在真正把 Harness 搭好之前，也經(jīng)歷過那個(gè)階段。

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

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

沒做好 Harness 的時(shí)候，AI Agent 會卡在三個(gè)地方。

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

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

這是最隱蔽的問題，也是我覺得最值得認(rèn)真對待的一個(gè)。

Agent 完成一個(gè)子任務(wù)，它自己判斷”好了”，但這個(gè)判斷依據(jù)是什么？沒有明確定義的話，它可能把一個(gè)有明顯 bug 的輸出交給你，因?yàn)樗J(rèn)為”能跑起來就算完成”?；蛘叻催^來，它會因?yàn)槟硞€(gè)無關(guān)緊要的細(xì)節(jié)沒處理好，一直在那里反復(fù)跑，浪費(fèi)了大量時(shí)間。

搭好 Harness 之后，這三個(gè)困境都有了對應(yīng)的解法。

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

這不是因?yàn)樗玫哪Ｐ陀卸嗵貏e。是因?yàn)樗幸粋€(gè)搭得足夠好的 Harness。

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

說完理論，講點(diǎn)實(shí)際的。

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

整個(gè)系統(tǒng)的設(shè)計(jì)是這樣的。

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

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

實(shí)際跑起來，卡了很久，踩了兩個(gè)很典型的坑。

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

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

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

排查起來特別痛苦。因?yàn)槟悴恢朗侵?Agent 的問題、子 Agent 的問題，還是中間傳遞的問題，全鏈路都得看一遍，找那個(gè)到底是哪里斷了。

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

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

字段問題解決之后，下一個(gè)問題來了：輸出質(zhì)量忽高忽低。

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

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

我們試了兩個(gè)方向。

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

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

有時(shí)候基本上是按照日期來定義版本名，System Prompt需要不斷微調(diào)。

兩個(gè)方向結(jié)合起來用，效果明顯好了很多。

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

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

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

講完坑，講方法。

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

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

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

他們團(tuán)隊(duì)意識到，當(dāng) Agent 的吞吐量增加之后，人工 QA 成了瓶頸。人的時(shí)間和注意力有限，每次 Agent 跑完都要人來驗(yàn)證，這件事本身就不可擴(kuò)展。規(guī)模上不去，不是因?yàn)?Agent 能力不夠，是因?yàn)槿祟惖尿?yàn)證能力跟不上。

解決方案是把驗(yàn)證能力也交給 Agent。

這意味著什么？

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

對我們做產(chǎn)品的人來說，遷移過來的邏輯是：你給 Agent 的任務(wù)，要讓它有能力自己檢驗(yàn)結(jié)果。

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

想突破這個(gè)天花板，就要把驗(yàn)證能力也設(shè)計(jì)進(jìn)去，把”對不對”的判斷權(quán)交給 Agent 自己。

這一點(diǎn)聽起來最反直覺，但我覺得也是最值得細(xì)說的一條。

Ryan 團(tuán)隊(duì)給代碼庫設(shè)計(jì)了一套嚴(yán)格的分層架構(gòu)。每個(gè)業(yè)務(wù)域有固定的層級結(jié)構(gòu)，依賴方向經(jīng)過驗(yàn)證，什么模塊可以調(diào)用什么、什么不行，都有明確規(guī)定，并且用自定義 linter 強(qiáng)制執(zhí)行。違反了規(guī)則的代碼，直接報(bào)錯(cuò)，不讓合并。

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

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

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

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

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

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

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

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

后來的做法是，定期跑一組后臺 Agent 任務(wù)，專門掃描偏差、更新質(zhì)量評分、發(fā)起針對性的重構(gòu) PR。大多數(shù) PR 可以在一分鐘內(nèi)審?fù)曜詣雍喜?，人工幾乎不需要參與。

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

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

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

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

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

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

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

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

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

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

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

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

但方向?qū)Σ粚?，目前還是人來判斷。

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

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

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

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

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

寫代碼、寫內(nèi)容、做執(zhí)行，這些會越來越不稀缺。稀缺的是能把 Harness 搭好的人，是能清楚地知道”什么是好結(jié)果”并把這個(gè)標(biāo)準(zhǔn)表達(dá)清楚的人。

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

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

我覺得這個(gè)坦誠很有價(jià)值。Harness Engineering 不是一個(gè)有標(biāo)準(zhǔn)答案的領(lǐng)域，它太新了，所有人都在邊做邊摸索。Ryan 他們在 OpenAI 內(nèi)部的探索，是目前最前沿的實(shí)踐之一，但也只是一種可能性，不是唯一答案。

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

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

這不是一個(gè)技術(shù)問題，是一個(gè)工作方式的問題。