當皇上：用明朝內閣制把 OpenClaw 包成一套多 Agent 協作骨架
Open-source multi-agent collaboration system inspired by Chinese governance — deploy and coordinate specialized AI agents with OpenClaw.
秒懂
- 它是什麼？
- 這個專案把明朝的司禮監、內閣、六部、都察院對應成 OpenClaw 上的 Agent 角色，附一鍵安裝腳本與三種制度切換。它真正解決的是「多 Agent 該怎麼分工與派發」，而不是模型能力問題。
- 適合誰用？
- 如果你已經在用 OpenClaw，而且需要一組現成的角色分工與派發流程，這個專案值得先在本機跑一次 bash scripts/full-install.sh，看產生的設定檔與人設是否符合你的工作習慣。如果你還沒裝 OpenClaw、或不想把 Agent 綁在 Discord 這類 IM 上，先不要導入：它的架構預設了 OpenClaw 的 runtime 與平台接入層，換掉其中一層就要自己重寫派發邏輯。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 116 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它把「多 Agent 怎麼分工」寫成了制度，而不是寫成框架
多 Agent 系統最常見的失敗不是模型不夠強，而是沒有派發規則。三個 Agent 互相對話，任務在誰手上、誰負責收斂、誰負責退回，全靠 prompt 臨場決定。當皇上這個專案選擇的做法，是把組織結構先固定下來：司禮監接旨、內閣優化 Prompt 並產生執行計畫、六部按計畫執行、都察院在程式碼 push 到 GitHub 時自動審查。README 對這條主線的描述是「司禮監接旨 → 內閣優化 → 六部執行」。
它的目標讀者很明確。README 寫「新手請用雲伺服器，不要在個人電腦上安裝」，並導向一份 server-setup 文件，這代表作者預設使用者會把整套朝廷長時間掛在遠端機器上，而不是在筆電上開開關關。另一條線索是安裝流程只要求填入 LLM API Key 與 Discord Bot Token，沒有資料庫、沒有佇列、沒有額外的排程服務。
所以它解決的是編排層的問題：角色邊界、任務流向、審查關卡。模型本身用哪一家，專案不介入。這個定位讓它的價值與其說是「更聰明的 Agent」，不如說是「一組可以直接抄的角色設定與流程範本」。
三種制度共用一套派發骨架，差別在誰先審
專案提供三種制度，README 的對照表寫得很清楚：明朝內閣制是「司禮監接旨 → 內閣優化 → 六部執行」，唐朝三省制是「中書起草 → 門下審核 → 尚書執行」，現代企業制是「CEO 決策 → Board 審議 → CxO 執行」。三者的人數也不同，明朝內閣制對應 18 個 Agent，唐朝三省制與現代企業制各 14 個。
把三張流程圖疊在一起看，會發現它們的差異其實只有一個維度：審核關卡放在生成之前還是之後。內閣制是先把使用者的旨意改寫成可執行的 Prompt 與計畫，再往下派；三省制是先把東西起草出來，再交給下一個角色審。前者偏迭代速度，後者偏事後把關。README 對適用場景的建議也是照這個邏輯寫的：個人專案用內閣制，偏好嚴謹流程的專案用三省制。
這是本專案設計上比較聰明的一點。制度切換不是換一套程式，而是換一組角色定義與派發順序，底層的 Agent 執行、記憶與 Skill 機制不動。反過來說，如果你需要的是與這三種都不同的審核結構，這個骨架給你的彈性就有限，你得自己改角色映射。
Discord 多 Bot 模式下，每個部門都是獨立入口
除了走司禮監的預設路徑，README 另外描述了一條「皇帝直接下旨給任意部門」的路線：在 Discord 多 Bot 模式下，每個部門是獨立 Bot，使用者可以直接 @兵部 寫登入 API、@戶部 查本月開銷、@都察院 審查 PR，跳過司禮監。文件對兩條路線的取捨講得直白：複雜任務走司禮監，會自動經過內閣優化；簡單任務直接 @ 對應部門更快。
這裡有個必須先處理的技術約束，而且 README 用警示框標了出來。多個 Bot 放在同一個頻道會互相觸發，形成訊息風暴。專案的解法是設定 allowBots，新安裝腳本預設為 mentions，也就是 Bot 只在自己被 @ 時才回應其他 Bot。README 明確禁止把這個值設成 true。這段內容對應到 issue #107 與一份 discord-safety 文件。
這是本文最想強調的一點：這個專案的成敗有很大一部分取決於 IM 層的設定，而不是 Agent 的提示詞。舊版設定檔沒有 mentions 這個值的使用者，升級時要手動補上，否則會遇到 Bot 之間來回回應。這種問題在測試環境不容易重現，因為它需要多個 Bot 同時在線。
安裝與切換制度的實際指令
本地安裝是 README 推薦的方式，指令為 git clone 專案後執行 bash scripts/full-install.sh。遠端安裝則是用 curl 取得同一支腳本直接執行，Windows 走 install.ps1。文件中特別註明舊版的 install.sh 不支援遠端執行，會出現 /dev/fd 路徑錯誤，要改用 scripts/full-install.sh 或先 git clone。
如果機器上已經有 OpenClaw，另有 install-lite.sh 這條精簡路徑，只配置範本。還有一條平行的 runtime 選項：install-hermes.sh，用 Nous Research 的 Hermes Agent 跑同一套朝廷設定，README 說兩套 runtime 可以並存，細節放在 EXTERNAL_HERMES.md。
制度切換用 scripts/switch-regime.sh，參數是 ming-neige、tang-sansheng、modern-ceo 三個值。更新方面，README 推薦 scripts/safe-update.sh，它會自動備份並檢查；手動更新的流程是進到 ~/clawd 後依序執行 git stash、git pull、git stash pop，文件提醒 stash pop 可能產生衝突需要手動解決。
備份的邊界文件寫得很清楚：系統會自動備份 ~/.openclaw/openclaw.json，但工作區檔案例如 MEMORY.md 需要使用者自己備份。這是一個容易被忽略的落差，設定檔有保護，Agent 累積的記憶沒有。診斷則用 openclaw doctor 或專案提供的 doctor.sh。
安全修補與原創爭議都寫在首頁，這是雙面刃
README 開頭有一段原創聲明，列出 2025-02-20 的小紅書首發與 2025-02-22 的 GitHub 教學發布時間，並指名 Edict 專案結構高度相似、未註明出處，附上 originality 文件作為證據鏈。同時聲明本專案為 MIT License，歡迎 PR 與 Fork，但要求註明出處並保留 License。
對採用者來說這件事有兩面。正面是授權條款清楚，MIT 允許商用與二次開發，README 也主動說明可以 Fork。需要自己判斷的是社群關係：如果你打算在同一個領域做二次開發或對外發布衍生版本，最好先讀完 originality 那份文件，理解作者在意的是什麼，並在文件裡保留出處標註。這不是法律意見，MIT 的條文本身不要求標註出處，但專案方在 README 中明確表達了這個期待。
安全方面，README 提到 2026-03-22 新增 Webhook 簽名驗證以防止偽造請求，並連到 webhook-security 文件。這代表專案有在處理外部請求的信任邊界，但驗證機制的實作細節本文無法從現有材料確認，需要自行閱讀該文件。
什麼情況下這套朝廷反而是負擔
第一個限制是平台綁定。整個派發模型的入口是 Discord 或飛書的 @ 提及，角色之間的互動也建立在 Bot 訊息上。如果你的團隊不在這兩個平台上，或你希望 Agent 由 CI、排程器或 API 觸發，這套骨架的入口層就不能直接用，得自己接。
第二個限制是角色數量帶來的固定成本。明朝內閣制 18 個 Agent、唐朝三省制與現代企業制各 14 個，加上 README 提到的 60+ Skill。每個 Agent 都是一份人設與一組提示詞，要調整改進就得逐份處理。如果你只有兩三種任務，這層組織圖的維護成本會高於它帶來的秩序。
第三個限制是審查關卡的觸發條件。都察院的職責被描述為「程式碼 push 到 GitHub 時自動審查」，這意味著它的價值集中在有 GitHub 推送流程的專案。如果你的產出不是程式碼，或版本控制不在 GitHub，這個角色基本上是空轉的。
最後是安裝環境。README 直接建議新手用雲伺服器而非個人電腦，這暗示整套系統預期長時間在線、且會執行安裝腳本與修改本機設定。把它裝在日常工作的筆電上，等於讓一個會改 ~/.openclaw 設定的流程常駐在你的開發環境裡。
與 CrewAI、AutoGPT 的差異在於誰決定流程
README 自己列了一張與 ChatGPT、AutoGPT、CrewAI 的對照表，但真正值得展開的差異只有一項：流程是事先寫死的，還是執行時由模型決定。
CrewAI 一類框架給你的是一組抽象：Agent、Task、Crew，流程由你在程式裡定義，或交給框架的協作模式決定。當皇上的做法相反，它把流程當成設定檔交付：司禮監先接旨，內閣再優化，六部照計畫執行，順序不變，你改的是角色人設與制度選擇。
兩種取向的取捨很實際。寫死流程的好處是行為可預期，出問題時知道該看哪一段；壞處是當任務型態超出這三種制度能描述的範圍，你得改派發邏輯而不是改提示詞。CrewAI 的彈性大，但代價是流程正確性要你自己保證。
還有一個結構性差異：當皇上把 IM 平台當成使用者介面與 Agent 之間的匯流排，CrewAI 則通常把 Agent 當成程式庫裡的物件。前者對非工程師友善，後者對需要嵌進既有服務的團隊友善。
編輯結論
如果你已經在用 OpenClaw，而且需要一組現成的角色分工與派發流程，這個專案值得先在本機跑一次 bash scripts/full-install.sh，看產生的設定檔與人設是否符合你的工作習慣。如果你還沒裝 OpenClaw、或不想把 Agent 綁在 Discord 這類 IM 上，先不要導入：它的架構預設了 OpenClaw 的 runtime 與平台接入層，換掉其中一層就要自己重寫派發邏輯。導入前務必確認三件事：Discord 設定中的 allowBots 是否為 mentions、scripts/switch-regime.sh 切換後人設是否完整覆蓋、以及 ~/.openclaw/openclaw.json 之外的 MEMORY.md 等工作區檔案有沒有納入你自己的備份流程。
社群筆記