一個人怎麼管理 13 個 AI 員工？我用 Hermes Kanban 試了一次

前排我做咗件幾傻嘅事。

唔係試邊個新模型，亦唔係學邊個新框架。我想整一個AI做網站嘅工廠。

唔係輸入一句話就生成靜態頁面嗰種demo。亦唔係俾一個Agent由頭到尾硬夾，寫到一半上下文爆曬，畀你一個理論上行得到嘅項目。

我想要一條真正似公司生產線咁嘅流程。

揾詞、PRD、定價、合規、文案、設計、前端、後端、QA、SEO、增長，最後仲有一個覆盤嘅人，負責判斷呢個項目應該繼續做，定係應該殺咗佢。

13個角色。

聽落似玩泥沙。但我真係開始砌喇。

越砌越覺得，呢樣嘢真正難嘅地方，根本唔係俾AI做嘢。

叫AI做嘢太簡單喇。你開任何一個聊天窗口，叫佢寫PRD、寫首頁、改bug，佢都識鬱。

真正難嘅係，當呢件事唔係一個任務，而係一條鏈路嘅時候，邊個嚟保證上一個人做完嘅嘢，可以被下一個人穩定噉接住。

呢個先係多Agent嘅死穴。

我一開始都冇諗得咁複雜。最樸素嘅想法，整個Telegram羣組將幾個Bot拉入嚟，一個叫總管，一個叫揾詞，一個叫PRD，一個叫QA。

我在羣組裡面嗌，總管，開始做一個網站。總管話收到，揾詞話開始揾詞，PRD話等揾詞結果。

幾似一個團隊。

但只要行耐少少，問題即刻出嚟。

羣組聊天係好熱鬧。但羣組聊天唔係事實來源。

今日揾詞Bot發咗一段候選關鍵詞，聽日PRD Bot到底讀邊個版本？設計Bot改咗一個視覺版本，前端Bot冇睇到嗰條訊息係唔係又要重做？QA發現咗問題，修復任務發俾邊個？

更麻煩嘅係，人都會搭嗲。我可能中途講一句，呢個方向暫時唔好做。呢啲嘢全靠聊天記錄保存，過兩日返轉頭睇，基本就變成考古。

你要喺一堆「收到」「完成」「我繼續」入面，揾嗰句真正影響流程嘅說話。

非常痛苦。

所以我後來意識到一件事。

多Agent唔係多幾個Bot喺羣組傾偈。多Agent必須有一個狀態機。

呢個狀態機要知道，任務而家喺邊度，跟邊個，依賴邊個，產物喺邊度，邊度卡住，下一步係乜嘢。

呢個就係我將Kanban搬入做網站流水線嘅原因。

Kanban呢個詞以前我都覺得有啲管理味。但當你真係將佢塞入Agent工作流，佢就唔再只係項目管理工具。

佢變咗做多Agent嘅共享記憶。

更準確啲講，佢變咗做呢班AI員工之間嘅交接記錄。

我後來越嚟越肯定一件事，Telegram只可以當觀察窗，唔可以當數據庫。

Telegram Topic適合俾人睇，Kanban卡片適合俾機器交接。呢兩樣嘢唔可以撈埋。

所以我而家成條鏈路定咗一個原則。

Bot可以匯報，但事實必須寫返入Kanban。

Bot可以講嘢。Kanban先算數。

呢句話我覺得可以貼喺所有多Agent項目門口。

砌落仲有一個反直覺嘅發現。AI團隊唔係人越多越好。

好多人一講多Agent，就想整二三十個，每個改一個好型嘅名，睇落似復仇者聯盟。

但如果你冇任務系統，冇交接規範，冇驗收邊界，Agent越多，混亂越快。

一個Agent亂咁講你都仲盯得住。十個Agent同時自信噉亂咁講，你根本唔知應該信邊個。

羣組入面多個topic 如下圖

多Agent嘅上限，唔係Agent數量決定。係交接質量決定。

所以我而家越嚟越鍾意將每個Agent嘅任務寫成合約。唔係一句幫我優化一下。而係寫清楚輸入、輸出、禁止事項、驗收標準、阻塞條件。

前者係傾偈，後者係工單。

AI做網站要想穩定，必須由傾偈變成工單。

呢句話有啲冷，但係真嘅。

講到呢度，我覺得呢套嘢真正想解決嘅問題，其實唔係自動建網站。

自動建網站只係表面。更深層嘅問題係，未來一個人點樣管理一班AI員工。

以前我哋話一個人公司，更多係講一個人加好多SaaS工具。

而家唔同喇。

你面對嘅唔再係工具按鈕，而係一堆可以主動行動、會寫嘢、會改代碼、會提建議、亦會犯錯嘅Agent。

呢個時候你最需要嘅能力，唔係識唔識寫prompt。

係識唔識設計組織。

邊個負責咩嘢，邊個唔可以越界，邊個驗收邊個，邊度必須人工確認，錯誤點樣回滾。

呢啲聽落唔似AI技巧。更似管理，亦更似工程。

由寫prompt，變成砌流程。

由調模型，變成管團隊。

kanban 狀態機

由同一個AI傾偈，變成帶一班AI做嘢。

呢個就係我呢段時間最真實嘅感受。

唔係曬技，亦唔係教學。就係一個好樸素嘅發現。

當AI員工越嚟越多，最稀缺嘅唔係員工，係秩序。

而Kanban，就係我而家俾呢班AI員工上嘅第一套秩序。

以上，既然睇到呢度，如果覺得唔錯，順手點個讚、睇、轉發三連啦，如果想第一時間收到推送，都可以俾我個星標⭐~

連結我入千人AI交流羣

多謝你睇我嘅文章，我哋，下次再見。

我係俊哥AI，前字節牛馬，萬人社羣AI編程教練

前段時間我幹了件挺神經的事。

不是測哪個新模型,也不是上手哪個新框架。我想搞一個AI做站工廠。

不是輸入一句話生成靜態頁面那種demo。也不是讓一個Agent從頭到尾硬憋,寫到一半上下文爆掉,給你一個理論上能跑的項目。

我想要一條真正像公司生產線一樣的流程。

找詞、PRD、定價、合規、文案、設計、前端、後端、QA、SEO、增長,最後還有一個覆盤的人,負責判斷這項目該繼續做,還是該殺掉。

13個角色。

聽起來像過家家。但我真的開始搭了。

越搭越覺得,這玩意兒真正難的地方,根本不是讓AI幹活。

讓AI幹活太簡單了。你打開任何一個聊天窗口,讓它寫PRD、寫首頁、改bug,它都能動。

真正難的是,當這件事不是一個任務,而是一條鏈路的時候,誰來保證上一個人做完的東西,能被下一個人穩定接住。

這才是多Agent的命門。

我一開始也沒想這麼複雜。最樸素的想法,搞個Telegram羣把幾個Bot拉進來,一個叫總管,一個叫找詞,一個叫PRD,一個叫QA。

我在羣裏喊,總管,開始做一個網站。總管說收到,找詞說開始找詞,PRD說等找詞結果。

挺像一個團隊。

但只要跑長一點,問題立刻出來。

羣聊是熱鬧的。但羣聊不是事實源。

今天找詞Bot發了一段候選關鍵詞,明天PRD Bot到底讀哪一版?設計Bot改了一版視覺,前端Bot沒看到那條消息是不是又要重來?QA發現了問題,修復任務發給誰?

更麻煩的是,人也會插話。我可能中途說一句,這個方向先別做。這些東西全靠聊天記錄保存,過兩天回頭看,基本就變成考古。

你要在一堆「收到」「完成」「我繼續」裏面,找那句真正影響流程的話。

非常痛苦。

所以我後來意識到一件事。

多Agent不是多幾個Bot在羣裏聊天。多Agent必須有一個狀態機。

這個狀態機要知道,任務現在在哪兒,歸誰,依賴誰,產物在哪兒,哪裏卡住,下一步是什麼。

這就是我把Kanban搬進做站流水線的原因。

Kanban這詞以前我也覺得有點管理味。但當你真的把它塞進Agent工作流,它就不再只是項目管理工具。

它變成了多Agent的共享記憶。

更準確點,它變成了這羣AI員工之間的交接班記錄。

我後來越來越確定一件事,Telegram只能當觀察窗,不能當數據庫。

Telegram Topic適合給人看,Kanban卡片適合給機器交接。這兩個東西不能混。

所以我現在給整條鏈路定了一個原則。

Bot可以彙報,但事實必須回寫Kanban。

Bot可以說話。Kanban才算數。

這句話我覺得可以貼在所有多Agent項目門口。

搭下來還有一個反直覺的發現。AI團隊不是人越多越好。

很多人一聊多Agent,就想上來搞二三十個,每個起一個很酷的名字,看起來像復仇者聯盟。

但如果你沒有任務系統,沒有交接規範,沒有驗收邊界,Agent越多,混亂越快。

一個Agent胡說八道你還能盯住。十個Agent同時自信地胡說八道,你根本不知道該信誰。

羣聊裏面多個topic 如下圖

多Agent的上限,不是Agent數量決定的。是交接質量決定的。

所以我現在越來越喜歡把每個Agent的任務寫成合同。不是一句幫我優化一下。而是寫清楚輸入、輸出、禁止事項、驗收標準、阻塞條件。

前者是聊天,後者是工單。

AI做站要想穩定,必須從聊天變成工單。

這句話有點冷,但是真的。

說到這兒,我覺得這套東西真正想解決的問題,其實不是自動建站。

自動建站只是表層。更深層的問題是,未來一個人怎麼管理一羣AI員工。

以前我們說一個人公司,更多是在說一個人加很多SaaS工具。

現在不一樣了。

你面對的不再是工具按鈕,而是一堆能主動行動、會寫東西、會改代碼、會提建議、也會犯錯的Agent。

這時候你最需要的能力,不是會不會寫prompt。

是會不會設計組織。

誰負責什麼,誰不能越界,誰驗收誰,哪裏必須人工確認,錯誤怎麼回滾。

這些聽起來不像AI技巧。更像管理,也更像工程。

從寫prompt,變成搭流程。

從調模型,變成管團隊。

kanban 狀態機

從跟一個AI聊天,變成帶一羣AI幹活。

這就是我這段時間最真實的感受。

不是炫技,也不是教程。就是一個很樸素的發現。

當AI員工越來越多,最稀缺的不是員工，是秩序。

而Kanban,就是我現在給這羣AI員工上的第一套秩序。

以上,既然看到這裏了,如果覺得不錯,隨手點個贊、在看、轉發三連吧,如果想第一時間收到推送,也可以給我個星標⭐~

連結我進千人AI交流羣

謝謝你看我的文章,我們,下次再見。

我是俊哥AI，前字節牛馬，萬人社羣AI編程教練