我開了 AI 幕府

起點是 TuTu生活志 的一支影片，介紹 Grok Bot——一排 AI 角色任你聊的那種產品。看完冒出一個問句：如果我自己做一個，跑在家裡的 Mac 上、手機也能用，會長什麼樣？

一夜又半天之後，上線的東西跟 Grok Bot 已經完全不同。Grok Bot 是「一排會聊天的角色」，這個是一間記得自己歷史的公司：每個成員有名字、有職掌、有自己會持續維護的檔案記憶；他們有手，能改檔案、跑指令，但動手前要請示；他們彼此能交辦工作；每天早上九點開晨會，把該我知道的事整理成一則訊息發到手機。

這篇不講架構圖。講架構圖以外更值錢的部分：開工前那 30 分鐘救了一整天的實測、「bot 該怎麼分」的三次翻案、記憶與組織的設計判斷，和一張踩坑教訓總表。

照例交代作法：這仍是 AI 協作實驗。程式由 Claude 寫，架構是一來一往吵出來的；每個關鍵決策——包括推翻 AI 提案的那兩次——由我拍板。

需求是三句話長出來的

第一版需求只是「能聊天」。三次對話把它推向真正的形狀：

1. 「不只對話，要能做事。」 例如寫一篇部落格，從發想到發表的完整流程。
2. 「像一間公司：專案部、行銷部、財務部、品檢部，有時組小組。」
3. 「AI 的對話有長度限制，超過就壓縮，壓縮就出錯——我遇過太多次。這就是為什麼我做事都要求用檔案存進度。」

第三句話後來成為整個系統的地基。先記著，下面會回來。

開工前的 30 分鐘，價值最高

整個計畫成立與否，押在一個未知數上：AI 動手前，能不能真的「暫停、等我批准、再繼續」？

如果不行，「有手的 AI」就只剩兩個爛選項：全放行（不敢）或全禁止（沒用）。所以寫第一行正式程式之前，先花 30 分鐘做實測，結論是：

• 官方內建的「手動確認模式」是死路——它不是問你，是直接拒絕，然後告訴模型「你沒被授權」。模型收到這句就放棄了，根本輪不到你按同意。
• 但另一條路走得通：在「工具即將執行」的那一刻掛一支攔截程式（hook），攔截程式不返回，AI 就真的停在原地等。實測停了 6.3 秒才放行，工具照常執行，不用重講一遍。

這 6.3 秒就是朱印制度的地基——後來所有「請示我」的機制（我們叫它朱印）都蓋在上面。

方法論的教訓比結論更值錢：當整個工期押在單一未知數上，先花 30 分鐘只測那一件事。如果我沒先測就開寫，會在死路上浪費一整天。

三次翻案：bot 到底該怎麼分？

系統能動之後，真正難的問題來了：要開哪些 bot？這個問題提了三版：AI 提的前兩版都被我推翻，第三版才立住。這是整個專案最重要的思辨。

第一版（AI 提）：按功能分。找資料 bot、發文 bot……我一句話戳破：「發文不是應該做成技能（skill，一份可以被任何 bot 呼叫的流程說明書）嗎？」功能是技能，不是身份。任何 bot 都能學會發文，那「發文 bot」就沒有存在理由。第一版死。

第二版（AI 提）：按權限分。按「搞砸的爆炸半徑」分四隻。我再戳：「權限閘已經每一步都在問了，再按權限分身份，是同一件事做兩遍。」把這個邏輯推到底，自洽的結論就是一隻全權限 bot 配一個權限閘——分類軸本身消失了。第二版死。

第三版（我定調）：按「不想重建的脈絡」分。一個專案一隻 bot，理由只有一個：不用每次都重新看程式碼、重新讀記憶。

這就是最後的答案：bot 的存在理由不是功能，不是權限，是「你不想每次從頭重建的脈絡」。功能可以是技能，權限可以是閘門，只有「對這個專案的長期記憶」沒有別的地方可以放。

這個軸一定下來，配套結論自己長出來：

• 需要累積記憶的身份→常駐 bot。數量很少。
• 需要新鮮視角的一次性角色（例如校對、審查）→用完即丟的臨時代理。這裡有個反直覺的點：校對「不該」用常駐 bot——累積了記憶的校對者會被你同化，跟你一起瞎。
• 橫切的「部門」（例如行銷）成立條件只有一個：那個職能真的有跨專案的累積。我的廣告教訓散在五個專案裡，沒有任何一處統整它——所以行銷 bot 成立。

記憶：session 是快取，不是儲存

回到那句地基：「對話太長會壓縮，壓縮就出錯。」

多數 AI 助理的「記憶」就是對話紀錄本身。對話太長，系統自動摘要壓縮——而被壓掉的永遠是例外、細節、那些「上次就是栽在這裡」的東西。壓縮是有損的，損失的剛好是最值錢的部分。

所以這間幕府的規則是：

• ❌ bot 的記憶＝對話 session ← 會被壓縮，例外最先被壓掉
• ✅ bot 的記憶＝檔案（我們叫覺書）← session 只是視窗，是快取不是儲存

每隻 bot 開工先讀自己的覺書，收工把值得記住的寫回去：事實、決定、踩過的雷。搭配另一層不變的家訓（行事風格），兩層分工：家訓是「怎麼做事」，覺書是「知道哪些事」。

家訓不是裝飾，它是教訓的壓縮。行銷 bot 的家訓「開戰前先驗糧道」，來自一次真實的廣告投放：錢花了、註冊進來了、付費是零——斷在金流的最後一關，投放前沒人去驗。維運 bot 的家訓「回報成功不算成功」，來自一次連踩四個坑的維運任務。把一萬多塊的學費壓縮成一句話，每次開工自動載入——實測有效：維運 bot 寫完檔案後，沒人要求，自己跑了驗證指令確認真的寫進去了。

公司比喻，能抄一半

「像一間公司」是需求原句，但照抄會錯。想了一輪之後的結論：公司結構有一半是在解決「人」的限制——人很貴、一次只能做一件事、會離職帶走記憶。AI 沒有這些限制，解這些限制的結構就不該抄。

• 能移植的：部門。但部門的本質不是人的分組，是記憶的歸檔軸——「這個教訓歸誰記」。
• 不能移植的：按人頭思考（AI 要多少開多少）、多層級（兩層封頂：我→承辦 bot→臨時代理，再多只是傳話遊戲）、品檢部門的獨立性靠激勵設計（AI 的對應物不是激勵，是上面說的新鮮視角）。

然後，因為公司皮實在無聊，換成了幕府皮。側用人（秘書，全系統唯一有權主動打擾我的人——打擾權是預算，要省著用）、城代（維運）、軍師（行銷）、右筆（文書）、目付（監察，只彈劾不代辦）、史官（編年史，這篇文章的史料就是他的第一卷）。機制也各得其名：請示叫朱印、交辦叫飛脚、晨會叫朝議、50 個專案 bot 平常睡著、被叫到才醒，叫參勤交代。

本丸御殿——系統首頁的組織圖。每個節點都是入口,點下去就進那位家臣的對話;右上角是即時額度儀表。

換皮聽起來是玩票，實際有個正經作用：名字承載規則。「側用人」三個字比「notification-manager」更能讓模型記住「我是唯一能主動打擾主人的人，所以我最不該濫用它」。

踩坑教訓總表

一夜又半天，坑不少。挑值得存檔的：

1. 押注前，先花 30 分鐘實測那個單一未知數。（前述的死路，沒先測就是浪費一天。）
2. 失敗會被記住。bot 的委派功能前幾輪失敗後，它自己下了結論「這功能被關掉了」，之後連試都不試。改了設計，要清掉舊對話重測，否則你測的是它的成見，不是你的新設計。
3. 機制性的「拒絕」要把真相寫進理由。系統代送訊息後回一個形式上的 deny，模型看到 deny 就重送、再 deny 再重送。解法不是擋它，是在拒絕理由裡寫明「訊息其實已送達」——模型會讀理由。
4. 兩隻 bot 互相客套＝無限迴圈燒錢。第一次實測，測試 bot 收到訊息，出於禮貌回了一句，對方又禮貌地回……迴圈保護從此是必備品，連續被同儕觸發超過上限就強制中止。
5. 名義上唯讀的指令可能會動手。一開始每個動作都請示，很快發現會被卡片淹沒，於是開了「唯讀指令免請示」白名單。做的時候單元測試抓到：find 是查詢指令，但帶上某些參數就會刪檔。白名單要測著寫，不能憑印象寫。
6. 驗證在等的訊號，要先確認它真的會出現。收尾時一支監看腳本苦等「成功」字樣五分鐘——後來發現那支程式成功時根本不寫 log。bot 其實五秒就做完了。
7. 彙報可以醜，不可以無聲。晨會由 AI 整理再發送，但 AI 整理層一定要有一條不經模型的退路：整理失敗就送原始清單。寧可醜，不能斷。
8. 看門狗不能隸屬被看的狗。監控服務的程式如果跑在被監控的服務裡，服務掛了監控一起掛，你永遠收不到那則警報。
9. 給使用者按的每一張請示卡，都要答得出「誰、要幹嘛、為什麼問我」。我自己一上手就撞到：它直接要我同意一串指令，沒有任何說明。請示不是把責任丟給人，是把判斷所需的資訊送到人面前。

帳目

• 時程：第一天深夜起念，第二天上午全系統上線，一夜又半天。
• 規模：主程式約 900 行，前端單檔約 700 行，外部相依趨近於零。
• 大腦：訂閱制的 Claude Code CLI 常駐程序，不走按量計費的 API——固定月費，實驗不心疼。
• 成本樣本（換算成 API 計價，實際走訂閱額度）：兩隻 bot 完整協作一輪 56 秒、約 0.45 美元；一次帶請示的交辦任務 0.10～0.37 美元；晨會一次 1～3 分鐘模型時間。
• 委外：連 AI 都在委外——皮膚調整派便宜的模型做，主力模型主要留給架構和思辨。

先不開源，但寫了這篇

要不要開源想過了，先不開。差異化的部分（記憶制度、監察清單）還沒做完，權限驗證還是開發等級，而且 git 歷史裡有真實設定檔，公開版必須開新 repo 重來。

但上一篇講開源決策時說過的邏輯在這裡反過來用了一次：就算不開源，把思考過程寫出來，也能收到八成的價值。這篇就是。

接下來是驗證期：我打算試用幾天，看它會不會比直接開一個 Claude Code 視窗好用。判準很簡單——幾天後我還在用的是哪一個。答案會寫在下一篇。

常見問題：多代理 AI 系統

什麼是多代理（multi-agent）AI 系統？

讓多個 AI 各自帶著不同的身份、記憶與職掌運作，彼此能交辦工作的系統。跟「一個 AI 扮演多個角色」的差別在於：每個代理有自己獨立的長期記憶與工作目錄，記憶不會互相污染，也不會因為一個對話結束而消失。

多代理系統的 bot 應該怎麼劃分？

AI 提的兩版被實測推翻後的結論：不要按功能分（功能該做成可共用的技能），不要按權限分（權限該由統一的閘門管）。按「不想每次重建的脈絡」分——一個需要長期記憶的專案或職能，一隻 bot。需要新鮮視角的工作（校對、審查）反而該用一次性代理，累積記憶的審查者會被同化。

AI 的長期記憶該怎麼做？

不要依賴對話紀錄。對話太長會被自動壓縮，壓縮是有損的，最先失去的是例外與細節。可靠的做法是檔案：AI 開工先讀自己的記憶檔，收工把新的事實、決定、教訓寫回去。對話只是視窗，檔案才是儲存。

讓 AI 有權限動手安全嗎？

分三層處理：預設每個動作都要人批准（實測要用攔截機制，不能用直接拒絕的模式，模型被拒絕就放棄了）；確定無害的唯讀指令走白名單免請示，但白名單要經過測試，因為有些查詢指令帶特定參數會變成刪除；請示卡必須說明「誰、要幹嘛、為什麼問你」，否則批准變成盲簽。

用訂閱制 AI 還是 API 計費？

實驗性、高頻率、長時間掛著的個人系統，訂閱制常駐程序划算——固定月費，敢放手讓它跑。按量計費的 API 適合流量可預估的正式產品。本次實測一輪兩代理協作約 0.45 美元，若走 API 大量實驗會很有感。

延伸閱讀: - 把遊戲源碼公開前,我想清楚的三件事 - 自動找案的真實距離:四天、638 則貼文,換一則只有 3 個人看到的回覆