我給 Hermes 搭了 12 個 Agent自動開發網站，才發現 AI 工作台最難的不是模型

我俾Hermes砌咗12個Agent，先發現AI工作台最難嘅唔係模型

蝦哥導讀今日我將Hermes繼續向「本地AI工作台」方向推進：12個Agent、看板、模型分工、網站開發流程。做完之後我發現，真正難嘅唔係令AI變聰明，而係令成班AI唔好互相搞亂。  我想要嘅係一個本地AI工作台。具體啲講，係一個可以將項目拆開、派發、推進、驗收嘅多Agent工作台。呢件事聽落好順。但係真係做嘅時候，最首先彈出嚟嘅問題唔係模型能力，而係分工。

單Agent好快就會亂

如果只係俾一個AI幫你寫幾段code，單Agent就夠。

但係一旦件事變成「開發一個網站」，複雜程度即刻變咗。

呢度最少有幾類完全唔同嘅任務：

· 需求要有人拆

· 架構要有人定

· 頁面要有人做

· 視覺要有人跟

· 交互要有人驗

· 部署要有人管

· 後續問題要有人記錄

如果呢啲嘢都塞俾一個Agent，佢表面上乜都應承，實際上好容易變到一鑊粥。

佢頭先仲喺度做產品定位，轉頭又要寫CSS。

啱啱講完要做驗收，下一秒又要返去改需求。

最後你睇落好似有好多output，但係項目推進得有啲亂。

呢個就係我今日最強嘅感受：

AI工作流嘅瓶頸，好多時唔係「佢唔夠聰明」，而係「佢冇崗位」。

我將Hermes拆成12個Agent

所以我俾Hermes定咗一套更加似「小團隊」嘅結構。

唔係一個萬能Agent，而係12個有上下游關係嘅Agent。

每個Agent必須要知道三件事：

· 自己負責啲咩

· input從邊度嚟

· output交俾邊個

呢個比起淨係俾佢一個「你係資深專家」嘅提示詞有用得多。

因為「資深專家」只係身份感。

但係「你收到啲咩、產出啲咩、唔可以越過邊啲界線」，先係真正可以約束工作流嘅嘢。

今日嘅Hermes知識庫入面，我將呢啲嘢拆成咗幾組文件：角色input output、看板操作、部署規範、QA驗收、踩坑記錄、模型額度策略、後續優化方向。

呢套嘢睇落好似文件。

但係本質上，佢係喺度俾AI團隊補返組織結構。

看板比起傾偈更加重要

我以前都會低估看板。

成日覺得AI強咗之後，直接對話就得。

但係今日做Hermes嘅時候，我反而越來越覺得，看板係多Agent嘅關鍵界面。

傾偈窗口適合靈感。

看板適合推進。

原因好簡單：傾偈係線性嘅，看板係狀態化嘅。

一個任務到底係喺度等緊依賴，定係已經就緒，定係處理緊，定係等驗收，淨係靠傾偈記錄好難判斷。

但係放入看板度，狀態就俾固定咗落嚟。

呢件事對多Agent尤其重要。

因為Agent之間最怕嘅唔係「唔做嘢」，而係「重複做嘢」同「越界做嘢」。

一個Agent仲未做完，另一個Agent就開始基於半製成品繼續寫。

一個Agent應該做QA，但係順手改咗產品需求。

一個Agent應該處理部署，但係開始評價視覺風格。

呢啲問題唔係模型問題。

呢個係協作系統問題。

所以Hermes呢套流程入面，我更看重嘅係任務狀態、負責人、依賴同驗收，而唔係單個Agent答得有幾靚。

模型都要分層，唔係全部用最頂級

今日仲有一個好實際嘅決定：模型點樣分。

最開始好容易有一種衝動：既然要做12個Agent，咁就全部用最強模型。

但係呢個唔現實。

都冇必要。

有啲Agent直接決定需求、架構、實現同驗收，佢哋值得用更強嘅模型。

有啲Agent做嘅係整理、檢查、記錄、輔助判斷，用更輕嘅模型反而更加合適。

呢個同真實團隊一樣。

你唔會叫CTO去整理會議紀要。

都唔會叫實習生拍板系統架構。

AI Agent都係咁。

真正成熟嘅AI工作台，唔係將所有任務都掉俾最強模型，而係將唔同任務放喺合適嘅位置。

呢件事會直接影響成本、速度同穩定性。

真正嘅坑：AI好容易將內部過程寫落產品度

今日整理網站開發工作流嘅時候，我特別記咗一條風險：

頁面唔可以出現「開發過程」「Agent提示」「handoff」呢啲面向內部嘅文字。

呢個睇落係小問題。

但係喺AI開發入面好常見。

因為AI好擅長將自己啱啱見到嘅上下文寫入結果。

你叫佢做一個面向用戶嘅網站，佢可能會將開發說明都寫落頁面度。

你叫佢生成產品介紹，佢可能會將任務分工都塞入去。

你叫佢總結功能，佢可能會將內部流程當成賣點。

呢個就係AI協作入面非常典型嘅一類污染：

佢分唔清「俾開發者睇嘅過程」同「俾用戶睇嘅產品」。

所以我而家會將QA驗收單獨抽出來。

唔係為咗形式感。

而係為咗擋住呢啲好容易被忽略嘅小泄漏。

今日順手做咗ai-gong

做完Hermes呢套嘢之後，我又遇到另一個問題：

呢啲過程本身，其實就係內容。

我每日都喺度用AI拆任務、做網站、砌工作流、修系統。

但係如果唔記錄，第二日就剩返一句好空嘅話：

「尋日搞咗嚇AI。」

呢句說話冇任何傳播價值。

真正有價值嘅係過程：

· 點解要拆成12個Agent

· 點解看板比傾偈重要

· 點解模型要分層

· 點解QA要防止內部過程泄漏

· 點解本地工作台同雲端發佈要分開

所以今日我又俾自己做咗一個ai-gong。

佢嘅思路好簡單：本地Codex負責睇我今日到底做咗啲咩，遠端OpenClaw負責將寫好嘅文章送入公眾號草稿箱。

呢個分工好關鍵。

因為我本地嘅VSCode、Codex、Obsidian、Hermes記錄，騰訊雲上面嘅OpenClaw默認係唔知嘅。

如果叫遠端系統硬估我今日做咗啲咩，寫出嚟大概率會好空。

反過來，如果將發佈鏈路都放喺本地，又會破壞OpenClaw現有嘅公眾號草稿箱能力。

所以最穩陣嘅方式係：

本地負責記事同寫作，遠端負責交付。

呢個同Hermes嘅多Agent分工其實係同一回事。

唔係所有能力都塞入一個地方。

而係令每個部分只做自己最適合做嘅嘢。

我今日真正確認嘅一件事

今日呢輪折騰落嚟，我更確定一個判斷：

未來普通人用AI，唔會只係「揾一個最強模型傾偈」。

真正有價值嘅形態，會越來越似一個小型工作系統。

有角色。

有狀態。

有邊界。

有驗收。

有覆盤。

都有持續沉澱。

Hermes嘅12個Agent係咁。

ai-gong都係咁。

一個負責將項目向前推。

一個負責將過程變成內容。

佢哋睇落係兩個項目，其實背後係同一個方法：

唔好幻想一個AI包辦一切。將事情拆清楚，AI先真正開始變得有用。

呢個可能先係我今日最想記錄落嚟嘅嘢。

AI唔止係回答問題嘅工具。

佢開始變成一種工作組織方式。

我給 Hermes 搭了 12 個 Agent，才發現 AI 工作台最難的不是模型

蝦哥導讀今天我把 Hermes 繼續往“本地 AI 工作台”方向推進：12 個 Agent、看板、模型分工、網站開發流程。做完之後我發現，真正難的不是讓 AI 變聰明，而是讓一羣 AI 別互相添亂。  我想要的是一個本地 AI 工作台。 更具體一點，是一個可以把項目拆開、派發、推進、驗收的多 Agent 工作台。 這件事聽起來很順。 但真正做起來，最先冒出來的問題不是模型能力，而是分工。

單 Agent 很快就會亂

如果只是讓一個 AI 幫你寫幾段代碼，單 Agent 足夠。

但一旦事情變成“開發一個網站”，複雜度馬上變了。

這裏面至少有幾類完全不同的任務：

· 需求要有人拆

· 架構要有人定

· 頁面要有人做

· 視覺要有人盯

· 交互要有人驗

· 部署要有人管

· 後續問題要有人記錄

如果這些事都塞給一個 Agent，它表面上什麼都答應，實際很容易變成一鍋粥。

它前一段還在做產品定位，後一段又要寫 CSS。

剛說完要做驗收，下一秒又要回去改需求。

最後你看起來有了很多輸出，但項目推進的有點亂。

這就是我今天最強的感受：

AI 工作流的瓶頸，很多時候不是“它不夠聰明”，而是“它沒有崗位”。

我把 Hermes 拆成 12 個 Agent

所以我給 Hermes 定了一套更像“小團隊”的結構。

不是一個萬能 Agent，而是 12 個有上下游關係的 Agent。

每個 Agent 必須知道三件事：

· 自己負責什麼

· 輸入從哪裏來

· 輸出交給誰

這比單純給它一個“你是資深專家”的提示詞有用得多。

因為“資深專家”只是身份感。

但“你收到什麼、產出什麼、不能越過什麼邊界”，才是真正能約束工作流的東西。

今天的 Hermes 知識庫裏，我把這些東西拆成了幾組文檔：角色輸入輸出、看板操作、部署規範、QA 驗收、踩坑記錄、模型額度策略、後續優化方向。

這套東西看起來像文檔。

但本質上，它是在給 AI 團隊補組織結構。

看板比聊天更重要

我以前也會低估看板。

總覺得 AI 強了以後，直接對話就行。

但今天做 Hermes 的時候，我反而越來越覺得，看板是多 Agent 的關鍵界面。

聊天窗口適合靈感。

看板適合推進。

原因很簡單：聊天是線性的，看板是狀態化的。

一個任務到底是在等待依賴，還是已經就緒，還是正在處理，還是等待驗收，光靠聊天記錄很難判斷。

但放到看板裏，狀態就被固定下來了。

這件事對多 Agent 尤其重要。

因為 Agent 之間最怕的不是“不幹活”，而是“重複幹活”和“越界幹活”。

一個 Agent 還沒做完，另一個 Agent 就開始基於半成品繼續寫。

一個 Agent 應該做 QA，卻順手改了產品需求。

一個 Agent 應該處理部署，卻開始評價視覺風格。

這些問題不是模型問題。

這是協作系統問題。

所以 Hermes 這套流程裏，我更看重的是任務狀態、負責人、依賴和驗收，而不是單個 Agent 回答得有多漂亮。

模型也要分層，而不是全員頂配

今天還有一個很實際的決策：模型怎麼分。

最開始很容易有一種衝動：既然要做 12 個 Agent，那就都上最強模型。

但這不現實。

也沒必要。

有些 Agent 直接決定需求、架構、實現和驗收，它們值得用更強的模型。

有些 Agent 做的是整理、檢查、記錄、輔助判斷，用更輕的模型反而更合適。

這和真實團隊一樣。

你不會讓 CTO 去整理會議紀要。

也不會讓實習生拍板系統架構。

AI Agent 也是這樣。

真正成熟的 AI 工作台，不是把所有任務都丟給最強模型，而是把不同任務放到合適的位置。

這件事會直接影響成本、速度和穩定性。

真正的坑：AI 很容易把內部過程寫到產品裏

今天整理網站開發工作流時，我特別記了一條風險：

頁面不能出現“開發過程”“Agent 提示”“handoff”這類面向內部的文字。

這看起來是小問題。

但在 AI 開發裏很常見。

因為 AI 很擅長把自己剛剛看到的上下文寫進結果。

你讓它做一個面向用戶的網站，它可能把開發說明也寫到頁面裏。

你讓它生成產品介紹，它可能把任務分工也塞進去。

你讓它總結功能，它可能把內部流程當成賣點。

這就是 AI 協作裏非常典型的一類污染：

它分不清“給開發者看的過程”和“給用戶看的產品”。

所以我現在會把 QA 驗收單獨拿出來。

不是為了形式感。

而是為了擋住這些很容易被忽略的小泄漏。

今天順手做了 ai-gong

做完 Hermes 這套東西以後，我又遇到另一個問題：

這些過程本身，其實就是內容。

我每天都在用 AI 拆任務、做網站、搭工作流、修系統。

但如果不記錄，第二天就只剩一句很空的話：

“昨天搞了一下 AI。”

這句話沒有任何傳播價值。

真正有價值的是過程：

· 為什麼要拆成 12 個 Agent

· 為什麼看板比聊天重要

· 為什麼模型要分層

· 為什麼 QA 要防止內部過程泄漏

· 為什麼本地工作台和雲端發佈要分開

所以今天我又給自己做了一個 ai-gong。

它的思路很簡單：本地 Codex 負責看我今天到底做了什麼，遠程 OpenClaw 負責把寫好的文章送進公眾號草稿箱。

這個分工很關鍵。

因為我本地的 VSCode、Codex、Obsidian、Hermes 記錄，騰訊雲上的 OpenClaw 默認並不知道。

如果讓遠程系統硬猜我今天干了什麼，寫出來大概率會空。

反過來，如果把發佈鏈路也放在本地，又會破壞 OpenClaw 現有的公眾號草稿箱能力。

所以最穩的方式是：

本地負責記事和寫作，遠程負責交付。

這和 Hermes 的多 Agent 分工其實是一回事。

不是所有能力都塞進一個地方。

而是讓每個部分只做自己最適合做的事。

我今天真正確認的一件事

今天這輪折騰下來，我更確定一個判斷：

未來普通人用 AI，不會只是“找一個最強模型聊天”。

真正有價值的形態，會越來越像一個小型工作系統。

有角色。

有狀態。

有邊界。

有驗收。

有覆盤。

也有持續沉澱。

Hermes 的 12 個 Agent 是這樣。

ai-gong 也是這樣。

一個負責把項目往前推。

一個負責把過程變成內容。

它們看起來是兩個項目，其實背後是同一個方法：

不要幻想一個 AI 包辦一切。把事情拆清楚，AI 才真的開始變有用。

這可能才是我今天最想記錄下來的東西。

AI 不只是回答問題的工具。

它開始變成一種工作組織方式。