一個巧妙的“文科生式”隱喻。

作者 | 許有陽

來源 | 盒飯財經（ID：daxiongfan）

頭圖及封面來源 | 即夢制作

還能用AI建一個自己的賽博朝廷？

最近，Github上出現了一個很有意思的開源項目，名字叫“三省六部·Edict”。這個項目套用千年前的唐朝三省六部制，重新設計了AI多Agent協作架構。

這套框架下，主要有12個AI Agent（11個業(yè)務角色+ 1個兼容角色）組成作者的賽博三省六部。這12個 AI Agent分別是太子、三?。ㄖ袝㈤T下、尚書）、七部（戶部、禮部、兵部、刑部、工部、吏部和早朝官），還有一個軍機處Kanban。

來源：Github

這套體系里，大家各司其職，還更好地相互制衡。太子消息分揀，也就是閑聊自動回復，旨意才建任務）；三省負責規(guī)劃、審議、派發(fā)；七部負責專項執(zhí)行。

截至3月10日21:00，Github上，該項目的星標數已達6.5K+。（鏈接在這里，大家有興趣可以圍觀，https://github.com/cft0808/edict）

“讓好漢查好漢，讓英雄查英雄”

想象一下，你作為剛打下江山的皇上，手頭上有一堆十分重要的事要處理。但此時，朝廷體系并未搭建完成，各自都有著不錯的專業(yè)能力，卻沒辦法很好得運作協調。

比如，之前你也有一個智囊團，幫你處理各種文書資料，還能時不時幫你出出主意（比如 ChatGPT、豆包、DeepSeek等）。他們在某些情況下確實很好用，但現在要處理的問題更復雜，也不只是動嘴皮子，還要跨部門調動其他人去落實一些具體的事，顯然超出了他們的能力范圍。

結果呢，它們要么因為工作量太大，“CPU燒了”導致胡言亂語；要么做完了也不檢查，發(fā)給你的報表里全是算錯的數字；最氣人的是，你問他上周交代的事辦得怎么樣了，他可能會說：“陛下，我忘了……”

而這個“三省六部·Edict”的項目，有意思的地方就在這里——將“三省六部”這個歷史中較為成熟的制度體系作為框架，用一群“不可靠的個體”AI Agent，搭建出一個“高可靠的系統”。

該項目中各agent職責截圖，來源：Github

太子的角色，像是沒有決策權，但是級別很高很懂皇帝的秘書。主要負責消息分揀、需求整理，擅長的是閑聊識別、旨意提煉、標題概括。

“三省”則像是一個大中臺，將匯總上來的各類需求和問題進行規(guī)劃、審議和派發(fā)。具體來看：

中書省，負責接旨、規(guī)劃、拆解，擅長的是需求理解、任務分解、方案設計； 門下省，負責審議、把關、封駁，擅長的是質量評審、風險識別、標準把控； 尚書省負責派發(fā)、協調、匯總，擅長的是任務調度、進度跟蹤、結果整合。

“六部”主要負責執(zhí)行。具體來看：

戶部，主要負責數據、資源、核算，擅長數據處理、報表生成、成本分析； 禮部，主要負責文檔、規(guī)范、報告，擅長技術文檔、API 文檔、規(guī)范制定； 兵部，主要負責代碼、算法、巡檢，擅長功能開發(fā)、Bug 修復、代碼審查； 刑部，主要負責安全、合規(guī)、審計，擅長安全掃描、合規(guī)檢查、紅線管控； 工部，主要負責CI/CD、部署、工具，擅長Docker 配置、流水線、自動化； 吏部，主要負責人事、Agent 管理，擅長Agent 注冊、權限維護、培訓。

于是，作為賽博皇帝的你，通過飛書、企微等工具向你的朝廷下旨了。

你的中書省接旨后，規(guī)劃子任務分配方案；你的門下省進行審議中書省的方案，評估后通過或封駁打回重新規(guī)劃；你的尚書省拿到上面兩個部門的方案，批準后分配給了執(zhí)行的六部。

該項目的架構截圖，來源：Github

更妙的是，當六部并行執(zhí)行時，你還能擁有上帝視角，在軍機處看板看他們的實時進度，隨時可以叫停、取消、恢復。最后尚書省將執(zhí)行的結果匯總回奏給你。

這么有意思的項目，在Github的華人程序員圈子里火了后，還被搬運到了很多外部論壇。美卡論壇（US Card Forum) 的技術板塊的評論區(qū)，就非常很精彩。

“所以系統運行的時候，用戶是在cosplay 皇帝嗎？” “讓好漢查好漢，讓英雄查英雄” “附議！ 錦衣衛(wèi)這個絕了，就是Monitoring Agent，專門監(jiān)控各部有沒有發(fā)生Hallucination。如果有Agent 敢亂輸出，直接詔獄伺候：如果有Agent敢亂輸出，直接詔獄伺候：先拖出去打三十大板！！” “每個agent是不是每周還要寫賀表”

有意思的評論，還有很多，還有網友建議出各種朝代和他們國家的版本。

來源：美卡論壇相應評論區(qū)

賽博朝廷，就是要讓“神仙”也打架

過去的Multi-Agent（AI多智能體），很多是相互寒暄后的自查自糾。

如AutoGen這樣早期的Multi-Agent框架，常常采用“群聊模式”（Group Chat），讓幾個 Agent自己商量著辦。這就會產生一個問題，因為沒有職責限定，Agent 之間互相寒暄、偏離主題、甚至陷入死循環(huán)。

什么是Multi-Agent？

直白地說，就是它模仿了人類社會的協作方式——專業(yè)分工、各司其職、協同作戰(zhàn)。當你面對的任務足夠復雜、需要多種能力、或者希望看到清晰的決策過程時，Multi-Agent架構就能比單個超級AI，更能妥善解決問題。

任務流轉圖，制作：即夢

參考“三省六部”后，這樣的問題就會減少。規(guī)劃者和執(zhí)行者分離，相互又是分權制衡。

作者在介紹中強調：大多數 Multi-Agent 框架的套路是，“來，你們幾個AI自己聊，聊完把結果給我。”然后你拿到一坨不知道經過了什么處理的結果，無法復現，無法審計，無法干預。

而這套三省六部制下，因為門下審的出現，增加了一個審核的職能AI Agent。作者認為，這是這套體系中的“殺手锏”。

“三省六部·Edict”項目結構截圖，來源：Github

最近的這股養(yǎng)龍蝦風潮中，企業(yè)的出發(fā)點很明確，借AI解決問題。

解決問題靠的不是AI漫談，而是AI工作流和SOP。而“三省六部”的層級結構，規(guī)定了信息的流向是單向且受控的，確保了復雜任務的執(zhí)行是可預測、可追蹤的。

從結構看，這個項目不比OpenClaw簡單——11個Agent，和一個dashboard?！叭×?· Edict”項目，正是基于OpenClaw底層能力和通訊渠道構建的上層多智能體編排系統。

而越復雜的結構，燒的token越多。可以理解為，流程越復雜、雇傭的下屬

（agent）越多，你要付的工資越多。而這里“多”，是指數級增加。

三個平臺代表的三種截然不同的多Agent系統設計理念圖；制作：OpenClaw

對比Anthropic的Claude Code和OpenAI的Codex，OpenClaw的結構更復雜。

Codex是聲明式的。建立在強大的GPT-5系列模型的基礎上，用戶不需要冗長的提示詞來指導行為。你只需告訴它角色名稱、用什么模型、什么權限級別。

Claude Code屬于指令式。在它的結構中，你該做什么才是要點。

OpenClaw是人格式的，它擁有設定下的“靈魂”。

這個“靈魂”如何搭建？在他的目錄結構中，我們能看到人格（SOUL）、記憶（MEMORY）、身份（IDENTITY）等維度，這里存儲著你對他的定義和它對你的理解。“三省六部·Edict”結構下，都有SOUL的設定。

這也是龍蝦為什么要“養(yǎng)”的原因。

OpenClaw目錄結構，制作：DeepSeek

先當成一次“好玩”的實驗

2025年末，一個奧地利開發(fā)者Peter Steinberger的“周末項目”Clawdbot（后改名OpenClaw）悄然上線。沒人預料到，這個項目會在短短60天內斬獲超過25萬GitHub Star——超越了React花費十余年才達到的里程碑，成為AI歷史上增長最快的開源項目。

它的爆火像一顆投入湖面的巨石，激起了整個行業(yè)的連鎖反應。OpenAI以收購OpenClaw創(chuàng)始人的方式直接入局；Anthropic收購Vercept強化Computer Use。

OpenClaw 爆火后，國內市場迅速涌現出大量的平替方案，將部署門檻降至零。

騰訊云、阿里云、移動云、天翼云、京東云、火山引擎、百度智能云在內的國內云廠商先后宣布接入，小米也宣布要做自己的手機“龍蝦”。月之暗面、MiniMax、智譜AI等AI新勢力，也先后推出了自己的“龍蝦”，Kimi Claw、MaxClaw以及GLM系列Agent。

也是在這樣背景下，因AI產生的焦慮情緒，從企業(yè)和從業(yè)者流向了普通大眾。

3月8日，“工信部已發(fā)布高危風險預警”登上熱搜。據悉，工業(yè)和信息化部網絡安全威脅和漏洞信息共享平臺監(jiān)測發(fā)現，OpenClaw部分實例在默認或不當配置情況下存在較高安全風險，極易引發(fā)網絡攻擊、信息泄露等安全問題。

一次技術性的迭代，逐漸成為一種盲目的、不可控的情緒。原因很簡單，看不懂外界的變化，產生了焦慮，而這種焦慮成了“火”，燒得這只“龍蝦”成了焦慮的投射和載體。

自OpenClaw火爆后，“魔改”的、平替的、強化的，各種“龍蝦”層出不窮。當不同的“龍蝦”接入不同的大模型（大腦）后，哪怕是同一個人養(yǎng)，也會體現參差不齊的水平和能力。而這其中，還有各種需要解決的接口和權限問題。

作為“龍蝦之父”的Peter Steinberger，最初也只是因為財務自由后的“玩心”，做了OpenClaw。

“三省六部·Edict”也是這樣一次“好玩”的實驗?！巴妗钡臅r候，你可能不會去時時刻刻測算Token的投入產出比，也不會焦慮如何和你的組織深度綁定——因為，那些變化，都是自然而然的。

這個項目能直接拿來用在公司的組織中嗎？答案是，再等等。先不提組織的復雜性，僅看其復雜的結構，就知道token的耗費。

現階段，不如將其看成一個社會學與AI結合的實驗——這是一個巧妙的“文科生式”隱喻。

它巧妙地將高中歷史課中學過的“三省六部制”，與現代前沿的Multi-Agent架構結合在一起。這樣一直站在“門外”只能看熱鬧的其他人，就能通過這個熟悉的歷史知識簡化理解工程式的概念和代碼，知道AI Agent到底是怎么工作的。

參考資料：

1.《“龍蝦”上桌，上市公司搶著“養(yǎng)”！OpenClaw引爆科技圈》，財聯社

2.項目鏈接：https://github.com/cft0808/edict?tab=readme-ov-file

歡迎在評論區(qū)留言~如需開白請加微信：YPYP01234567