前言：一個全能 bot 很快就會失控

前面幾天，我把 Hermes Agent 接上訊息平台、模型、記憶、知識庫與排程。到了這一步，最直覺的下一個想法通常是：既然同一個 Agent 什麼都會，那就讓它服務整家公司。

這個想法一開始很有效。老闆問財務，它查表；問客戶，它讀聊天紀錄；問工程，它找 SOP。可是當工作量增加，問題也會一起出現：權限邊界模糊、提示詞越堆越長、不同部門的規則互相衝突，最後連「這個回答到底是誰負責的」都說不清楚。

在 ZoneTech 的實作裡，我最後沒有繼續擴充一個全能 bot，而是把它拆成多個部門 bot。這不是為了讓系統看起來更複雜，而是把組織中的責任、資料與風險，映射成可驗證的 Agent 邊界。

一、先看全能 bot 為什麼會失控

一開始所有任務都進同一個 Profile。這個 Profile 同時知道公司的共通原則、財務報告格式、客戶跟進規則、工程交接方式、網站 SEO 流程與社群雷達格式。

短期內它很方便，但有四個結構性問題。

第一，權限會跟著上下文一起膨脹。只要某個工作需要讀取公司財務資料，整個全能 bot 就可能具備接觸財務資料的能力。即使提示詞要求它不要洩漏，也不能把提示詞當成真正的權限控管。

第二，規則會互相干擾。財務報告要求直接引用完成區資料；客服工作則強調先確認客戶語意；工程工作又要求保留原始錯誤訊息。規則全部塞在同一份文件裡，模型要先判斷「現在是哪一種角色」，才知道要套用哪一套規則。

第三，記憶會混流。某個客戶案件的短期資訊、公司長期制度、私人聊天偏好，如果都進入同一個記憶空間，後續每次回答都要花額外成本過濾。

第四，錯誤責任無法定位。當報告出錯時，是資料收集錯、財務規則錯、模型判斷錯，還是全能 bot 的角色切換錯？沒有清楚 owner，就很難修復。

因此，多 bot 的第一個目的不是「多幾個聊天視窗」，而是把責任切開。

二、我的拆分原則：依責任，不依工具

我沒有把 bot 按照「會用哪個 API」來拆。例如，Google Sheets 可能同時被財務、業務與管理工作使用；如果按工具拆，就會得到一個 Sheets bot，但它沒有清楚的業務責任。

比較穩定的切法是依照部門或工作責任拆分：

這個表不是把每個 bot 限制成只會一件事，而是定義它「對什麼結果負責」。例如 engineering 可以查 Google Drive，但它不因此變成財務 bot；finance 可以讀取郵件，但只為了核對收款，不負責處理工程技術問題。

三、每個 bot 都要有自己的身份與邊界

在 Hermes 裡，Profile 不只是模型名稱。它包含自己的設定、SOUL、USER、skills、cron 與記憶。這些檔案組合起來，才形成一個可運作的角色。

我為每個部門 bot 定義五種內容：

1. 身份：它是哪個部門、服務誰、用什麼語氣。
2. 責任：它可以主動完成哪些工作，交付標準是什麼。
3. 資料源：它可以讀哪些資料，哪些資料只能摘要或不可讀取。
4. 禁止事項：哪些事情必須交給人或其他 bot，不能自行決定。
5. 驗證方式：怎麼證明任務真的完成，而不是只產生一段看起來合理的文字。

例如 finance 的核心規則不是「請產生一份漂亮報告」，而是：報告前必須讀取實際 Sheet；收入只採完成區的指定欄位；資料讀不到時要明確標示阻塞，不得用舊資料補上。

engineering 的核心規則也不是「請協助工程師」，而是：客戶回簽資料夾有檔案才放行 Pre-setting；來源與維修單簽名要能追溯；異常要回報 owner 與時限。

把規則寫成這種可驗證的條件，比寫成抽象人格更有用。

四、General 原則與部門規則要分層

多 bot 不代表每個 bot 都從零開始。共通原則仍然需要集中管理，例如：

• 不把推測寫成事實。
• 外部動作前確認範圍，完成後讀回驗證。
• 私人、公司與不同聊天室的資料要隔離。
• 失敗時保留證據，不用 exit code 0 冒充完成。

這些屬於 General 層，所有 bot 都應遵守。但財務的收入口徑、工程的交接規則、行銷的發布格式，就應該留在部門層。

如果把所有規則都放進 General，General 會變成一個巨大、難以維護的中央提示詞；如果完全沒有 General，各 bot 又會各自發展出互相矛盾的安全習慣。

我的做法是：General 定義跨系統原則，部門文件定義角色責任，Skill 定義可重複程序，cron 定義定時觸發。四者分開，修改時才知道影響範圍。

五、架構 bot 不等於全能 bot

在這套架構裡，我另外保留 architect bot。它的工作不是替所有部門做日常工作，而是設計、審查與改善 bot 系統。

這個差異很重要。若 architect 也直接承接所有財務、客服與工程任務，它很快就會退化成另一個全能 bot。它真正應該處理的是：

• 新增一個 bot 前，檢查責任是否和既有 bot 重疊。
• 檢查資料源、權限與外部動作是否合理。
• 審查 bot-to-bot 的交接格式。
• 根據失敗紀錄提出 P0、P1、P2 改善建議。
• 先產生設計提案，核准後才寫入正式設定。

也就是說，architect 負責治理，不直接取代 owner。這讓系統可以演進，又不會把所有決策集中到一個角色裡。

六、拆 bot 後，成本會不會更高？

多 bot 不代表每個 bot 都要使用最貴的模型，也不代表每次任務都要載入整間公司的知識庫。

我會把模型選擇與角色責任分開：固定格式、資料搬運與高頻任務使用成本較低的模型；跨來源推理、制度設計與長文交付才使用高品質模型。每個 bot 也只載入完成工作所需的 Skill 與資料，減少無關上下文。

真正增加的成本，通常不是 bot 數量，而是治理成本：要維護責任表、權限表、交接格式與監控。可是這些成本本來就存在，只是全能 bot 把它們隱藏起來，直到某次錯誤造成更大的返工。

七、一次實際的任務流

以客戶設備建置為例，流程可以拆成：

1. support 收到客戶訊息，確認需求與案件背景。
2. sales 判斷是否涉及報價或追加服務。
3. engineering 檢查回簽資料與設備清單，決定是否放行 Pre-setting。
4. finance 在付款條件符合時更新對帳與收入狀態。
5. operations 追蹤排程、服務與通知是否正常。
6. architect 只在跨部門交接失敗或規則衝突時介入。

每個交接都不應只傳一句「請接手」。至少要包含 owner、背景、輸入資料、已完成事項、待處理事項、驗收標準、截止時間與證據位置。

這樣即使下一個 bot 無法完成，也能把具體缺口交回上一個 owner，而不是讓任務在多 bot 之間無限轉送。

八、驗證：拆分真的改善了什麼

我不把「現在有八個 Profile」當成成功證據。真正要驗證的是：

• 財務 bot 是否不再被客服雜訊干擾。
• 工程 bot 是否能依照簽回資料做出可追溯判斷。
• 每個 bot 的 cron 是否只產出自己負責的報告。
• 跨 bot 任務是否有明確 owner 與交接紀錄。
• 某個 bot 出錯時，能否在不影響其他 bot 的情況下修復。
• 權限收窄後，是否仍能完成必要工作，而不是全部改成人工。

實務上，我會保留原始輸入、工具呼叫結果、產出檔案與外部讀回結果。只有這些證據能串起來，才知道問題發生在哪一層。

結語：多 bot 是組織設計，不是聊天視窗設計

從一個 bot 拆成八個 bot，表面上是架構變複雜，實際上是把原本混在一起的公司責任顯性化。

每個 bot 都應該有清楚的 owner、輸入、輸出、權限、禁止事項與驗收標準。部門 bot 不是越聰明越好，而是越能在自己的邊界內穩定交付越好。

我的下一篇會繼續處理這些 bot 如何同時在線：不同聊天室如何路由到正確的 Profile、哪些設定負責 allowlist，以及為什麼「有設定」不代表訊息一定會抵達正確的 bot。

實際證據清單

• 部門責任表：每個 bot 的責任、資料源與輸出已分開定義。
• 文件分層：General 原則、部門規則、Skill 程序與 cron 觸發分離。
• 交接條件：跨 bot 任務要求 owner、輸入、輸出、驗收標準與證據。
• 停止條件：權限、資料或規則不明時，bot 必須回報阻塞，不自行猜測。