Harness 的哲學選擇

1

Addy osmani skill v.s. Matt pocock skill

開始用 Agent 做開發的時候，我是用 Addy Osmani 的 agent-skill，Github 上有 86K 星星，是非常熱門的開發 skill。

不過，前陣子 Matt Pocock 的 skills 突然爆紅，短短時間爆衝到了 213k 星，星星數遠超過經營許久的 Addy 的 agent-skills。

由於 Matt 的 skill 實在太紅了，Addy 還特別寫了一篇兩者的比較，放在自己專案的 github，給大家參考，說他的 skill 更嚴謹、更適合團隊開發工作。

不過看人家講也不準，我自己認真摸 Matt 的 skill 摸了兩個禮拜，結論是... 我決定轉投 Matt 的 Skill。

2

剛開始用 Matt 的 Skill 的時候，很不習慣，因為「簡潔」，Skill 本身很簡潔，輸出也很簡潔，簡潔到讓我感覺...很沒安全感。

之前用 Addy 的 Skill 的開發流程是這樣：寫 Spec、做 Plan、然後依據 Plan 再展開 Tasks。要 Agent 做什麼，文件都寫得清楚。

也就是 Agent 都還沒寫程式，文件已經寫得很澎湃。

像是專案的問題、目標、架構、流程、欄位、繼續選型、資料結構、檔案結構、使用案例、CLI、API 規劃、甚至連 code style、測試計劃（單元測試、整合測試）、最後會有做什麼、不做什麼...洋洋灑灑，不管大小專案，Spec 都非常完整。

Spec 寫完，還會拉出開發階段、Checkpoints、以及所有的 Tasks 跟順序，接著就可以讓你一步一步按部就班開發。就像一個傳統專案一樣嚴謹，身為人類會有很強的掌控感。因為文件基本上什麼都寫了，完全可以預期 Agent 會怎麼做，會做什麼，會用什麼規格、欄位、程式檔案，文件怎麼寫了，Agent 就怎麼做，感受上就不太有意外。

不過 Matt 的 Skill 不是這樣，Spec 非常...簡潔：就是問題100字、方案100字、使用案例（條列式），每一條都 1~2 行，頂多 20 條，結束，沒有規格、沒有設計提案、沒有架構、流程、技術選型、Coding Style，都沒有。

內容超少。一開始還想說，就這樣？這樣...行嗎？

中間還也完全沒有 Plan 的過程，就直接展開 Ticket，Ticket 更簡單，就是 What to build（做什麼 100字）> Acceptance criteria（完成條件...），兩段而已。

也就是雖然目標清楚，但 Agent 實際上會怎麼做，完全不清楚。

Matt 留了非常大的空間給 Agent 。

不只產出這樣、Skill 本身也是這個哲學。

Matt 的每一個 skill 也都惜字如金，不廢話，像 implement 相關的 skill，Addy 的 incremental-implementation skill 總共有 250 行，而 Matt 的 implement skill，只有 5 行。

一直讓我懷疑，就這樣？這樣也行？

不過真正試用起來，還真的行。

而且感覺整個開發過程，清爽很多，我這樣感覺，我感覺 Agent 也這樣感覺。

其實之前用 Addy skill 產生的那些超長文件，雖然感覺很有安全感，但老實說我也沒辦法細看，呼嚕呼嚕就給過了，但那些文件丟給 Agent 後，反而限制了可能性。

而且規矩多、框架限制多，而因為文件長，就常會有前後邏輯隱藏矛盾，在開發階段才跑出來。Agent 為了盡量想辦法遵守規範，結果不得不多做一些動作，造成「過度設計」，程式碼默默地就臃腫起來。

人類想要的掌控感，結果變成限制了 Agent 的能力。

3

這兩個禮拜，使用 Matt Skill 的體悟，也就是我這幾年做主管的體悟。

剛開始當主管的時候，因為怕自己做不好主管、怕同仁做不好事情，結果其實是對內自己缺乏自信，對外就什麼都要掌控，展現出處處都要抓到很細的工作方式。

雖然任務交辦給同仁，但每天都一直問他，你現在在做什麼？做到哪？你怎麼做？然後一直指揮每一個同仁每一個動作，請你跟我這樣做，1, 2, 3...。

也就是希望照著自己要的步驟 1 ,2 ,3 去做，還常常因為看不下去，忍不住自己動手做給他們看。

最後就是自己痛苦，同仁也痛苦。

其實重要的是「完成專案目標」，而不是「完成專案目標的方法」。

總是會忍不住一直講 How，而不是講清楚 What，甚至說清楚 Why。

要完成一個目標，本來做法就很多種，你最熟悉的方法，不見得是同仁最熟悉的方法，而且甚至也不一定是最棒的方法。

做主管就是講清楚目標，追成果就好，然後讓同仁去發揮。本來每個人的優點都不同，讓同仁用自己最強的優點去找方法，反而因為這樣，常常看到驚喜，自己也因此學習到了新的方法。

這種自己只說清楚目標，讓同仁去發揮的領導方式，同仁會成長，團隊也才會一起成長，甚至反過來，自己也才會成長。

否則，大多時候，主管的能力上限，往往就是整個團隊的能力上限。

其實對待 Agent 原來也可以是這樣。

4

我們講 Harness，駕馭 AI，其實也就是 Agent 團隊的管理問題。

對 Agent 來說，使用 Matt Skill，你就是一個交辦事情很簡潔的主管；而使用 Addy Skill，你就是一個話很多、管很多、還很囉唆的主管。

哲學上，Matt 的設計本質就是「相信」 Agent ，Addy 的設計本質則是「懷疑」Agent 。

也就是 Matt 相信，把目標講清楚就好，怎麼做就交給 Agent，他相信 Agent 會做好。而 Addy 的風格是，為了避免 Agent 搞砸，事先就要在文件裡，把所有設計、細節、規矩都確認好，讓 Agent 照著步驟做，不要給我瞎搞。

Addy 讓 Agent 跟隨人類的方法來做事，而 Matt 讓 Agent 用 Agent 自己的方法去做事。

所以，雖然 Addy 的 SPEC 文件寫的豐富，其實是讓身為人類的我們得到「安全感」，卻因此失去了 Agent 的「可能性」。

如果人類的就像是 Agent 的主管，你一直教他用人類的方法做事，結果你的能力會成為了 Agent 的瓶頸。

Addy 的 skill 花了很大的力氣在教 Agent「how」，而 Matt 的 skill 的重點卻在「What」。

其實把「What」講清楚，文件很簡單、但要把「How」講清楚，文件就會變很複雜。

太澎湃的文件，結果也反而讓 Agent 最後的表現也不好，因為 Agent 的注意力也被豐富的文件內容（過大的 Context）給分散了。

如果說，Attention Is All You Need，結果 Addy 的 Skill 寫出來豐富的文件內容，反而讓 Agent 的注意力分散。

Agent 的注意力應該要放在哪裡？應該是放在「目標」上。所以 Matt 的 Skill，幾乎都在描述目標，或者說「只」描述目標。

甚至連很常在 Skill 或規格中看到的反向命令：不要怎樣、不要怎樣...之類的，在 Matt 的 Skill 以及輸出文件中，幾乎都沒有。因為他認為，那些「不要怎樣」的文字，也是在分散 Agent 注意力，你一直跟他說不要的，他反而一直注意到那些事情。

就像規矩很多的公司，列了一大堆負向規矩，要員工「不要」這樣「不要」那樣，到最後，公司最後到底「要」怎樣？「要」去哪裡，反而大家都不知道了。

5

在 Agent 時代，How 越來越不值錢，因為你以為你很會的方法，Agent 可能知道的方法比你還多。

而 Agent 時代，What 才值錢，你要做什麼？想做什麼？也就是人類的「Purpose」，你想去哪裡？你想做什麼？你想成為誰？那些人之所以成為人的意義，否則我們只知道埋頭不停的做事，那跟機器有什麼不同？更何況，做事、執行，我們還做不贏機器。

想清楚你的「Purpose」，講清楚你的目標，放手讓 Agent 去發揮，讓 Agent 幫你完成你的 Purpsoe。

所謂的 Harness，原來也是一種哲學的選擇，面對 Agent Team，你是要「領導」他們，還是只是「管理」他們？