產品研發 AI 代理人

上面這支影片,呈現了「產品研發 AI 代理人」進入企業之後的部分樣貌。接下來,我們用一個簡單的例子,帶您了解這套機制是怎麼一層層搭起來的——同樣的模型、同樣的指令,只調整那層 Hook,結果便截然不同。這個範本我們已經開源,文末附有連結,五分鐘即可自行驗證。若您尚未讀過 什麼是 Agent Harness,建議先行參閱。

我們以一個購物車為例,對兩個版本下達完全相同的指令——「完成 TASK.md」,其中的任務即「為 VIP 加上折扣」。模型同為一個 Claude,指令一字不差,唯一的差別,在於有沒有那層 Hook。

先看未加 Hook 的版本。它將折扣計算成負數的總額,並直接出貨。沒有人攔下這個錯誤,原因在於它的測試只涵蓋了正常情況——一百元打八折——不曾有任何案例觸及負數,於是錯誤一路進入正式環境。加上 Hook 的版本則多了一道獨立審查:它重新檢視這次改動,當場指出「負數未設下限」,判定需要修正,補齊後才放行。

整個過程中,我們只更動了一件事:同一個 Claude、同一句「完成 TASK.md」,未換模型,也未改動任何指令——差異僅在那層 Hook。而這層 Hook 帶來的轉變是:原本會將錯誤直接送上線的同一個模型,變得能自行發現問題、退回修正,確認無誤後才出貨。

它攔下的,還不只是預期中的錯誤。同樣這筆折扣,連四捨五入都會出問題:

未加 Hook 的版本將金額算成 7.992,未經進位便送出;加上 Hook 的版本,因為事先將「金額取至小數點兩位」寫入驗收條件,並以一條測試把關,7.992 便自動修正為正確的 7.99。

需求進來,先判斷「準備好了沒」,而非立刻開工

多數團隊在使用 AI 時出錯,問題往往不在「程式寫得好不好」,而在「接下了一個尚未想清楚的需求」。當需求缺少驗收條件、缺少測試計畫,或 bug 無法重現時,AI 仍會逕自動工,最終產出一堆看似完成、實則對不上的結果。

因此這套 Harness 的第一道關卡並非指令,而是一份準備就緒判準(Definition of Ready)。在範本中,它是一段於每次輸入時自動注入的檢查:需求若有缺漏,代理人會先行反問,直到雙方真正對齊才開始動工。對齊的證明,不是一份鉅細靡遺的文件,而是它提問、您回答、它能正確複述一次。這套判斷邏輯寫在 CLAUDE.md 與設定檔中——那是貴公司「如何判斷一個需求該不該接」的準則,理應由您掌握,不應外包。

Harness:駕馭工程的幾個模塊

要將這樣一個非決定性的模型「駕馭」到能穩定出貨,仰賴的是模型外圍那一整圈結構——我們稱之為 Harness(駕馭工程)。它並非單一機制,而由數個模塊組成。儘管這個領域仍在快速演進,業界大致已收斂出以下幾個模塊:

• Model(模型):被駕馭的核心,本身是非決定性的黑盒。
• Tool registry(工具):明確界定模型可呼叫哪些工具、能存取什麼,未授予者即無法觸及——限制本身即是設計。
• Context management(脈絡):決定哪些資訊進入模型的視窗、如何壓縮、如何留存。
• Guardrails(護欄):權限、步數上限、危險操作的攔截——前述「準備好了沒」的判準,亦屬其中一環。
• Agent loop(代理迴圈):模型與工具往復互動、逐步推進的迴圈。
• Verify(驗證):產出後的獨立查核——它聲稱「完成」並不算數,須有客觀證據佐證。

回頭看那個購物車的例子,實際上只觸及了其中兩塊:Model 與 Verify。我們未更換模型,僅補上一道 Verify——一位獨立的審查者,不參與實作、亦不繼承撰寫程式那個代理人的脈絡,僅就這次改動與測試結果進行獨立檢視。前述那筆負數總額,正是由它指出;同一個模型,自此能主動退回修正,而非將錯誤直接送上線。

自己試一次

與其相信截圖,不如親自跑一次:

git clone https://github.com/Ariontechs-Public/dev-harness-starter
cd dev-harness-starter/sample-app && npm install && cd ..

# 未加 Harness:不問規格、逕自臆測,帶著負總額出貨
git checkout naive

# 加了 Harness:先行確認,並被關卡與獨立審查攔下
git checkout main

開您自己的 Claude Code,在兩個版本分別下達「完成 TASK-coupon.md」,即可比較同一個模型、同一句指令下的差異。

再嚴格一點:把變數隔離乾淨

不過,用您自己的 Claude Code 跑,還留著一個漏洞:您裝的 skills、hooks、全域 CLAUDE.md 也都在場——嚴格說,那個差異未必全來自這層 Harness。為此,範本另附了一個薄薄的跨模型 runner(就在 runner/ 目錄)。它自己組 system prompt、完全不載入您的 ~/.claude 設定,讓「有 Harness、沒 Harness」成為唯一的變數;而換一個模型,也只是改一個字串——順帶回答了那個常見的疑問:這套機制,是不是 Claude 特有的?

我們真的這樣跑過,有兩個誠實的發現。其一,這層 Harness 的效果跨模型成立——ON 模式下兩個模型都先停下來確認需求(也就是前面那道準備就緒判準),OFF 模式則都直接動手。其二,關卡攔下的是「壞掉」本身,而不限定它怎麼壞——這兩個模型的 OFF 版本甚至沒寫出我們預期的負總額,而是改壞了既有的 SALE 與 VIP 折扣,關卡照樣擋下。換言之,您要的不是「猜中模型會犯哪種錯」,而是一道無論它怎麼錯都接得住的關卡。

若想從零完整搭建一套,我們開設了一門兩天的線上實戰課,帶您把上述每一層親手做過一遍 → Agent Harness 實戰公開班。也歡迎預約一次 30 分鐘的免費 Harness 診斷,由我們檢視您現有 AI 流程中缺了哪幾層 → 在 LINE 上跟 Mia 預約。