（系列：《AI 維運實戰：我用 Hermes 把 Agent 變成企業同事的 30 天》）
（主題：將 AI 模型整合進實際系統與產品的工程實踐）

前七天，我把模型、備援、記憶與行為規則逐一補齊。單一 Agent 已經能工作，但當財務、工程、行銷與私人任務都進到同一個入口時，我發現「換一段 Prompt」並不等於角色隔離。

同一個模型可以扮演不同角色，卻仍可能共用記憶、Skills、Cron 與權限。對企業系統來說，這不是角色扮演問題，而是執行邊界問題。Hermes 的 Profile，就是我用來切開這些邊界的工作空間。

────────────────────────────────

Profile 不是聊天分頁

Profile 是一組可獨立運作的設定與資料。每個 Profile 可以有自己的 config、SOUL.md、USER.md、Skills、Cron 與 memories。它決定 Agent 如何做事、能使用哪些流程、會執行哪些排程，以及哪些長期資訊能進入上下文。

聊天室只是使用者送出訊息的位置。Bot 是訊息平台上的身份。Profile 才是 Hermes 內部真正承接工作規則與狀態的單位。

如果兩個 Telegram Bot 最後都路由到同一個 Profile，它們外觀看似兩位員工，實際上卻可能共用同一套工作腦。反過來，同一套 Gateway 可以同時承載多個 Profile，只要路由與授權邊界配置正確。

────────────────────────────────

我為什麼不做一個全能 Agent

IT 委外公司的工作天然帶有不同資料邊界。財務會讀收入與支出，工程會處理客戶環境，行銷會整理公開素材，私人助理則不應自動取得公司內部資訊。

若全部塞進單一 Profile，問題不只是上下文變長。任何一條寬鬆規則，都可能影響其他角色；任何一段錯誤記憶，也可能被帶進不該出現的聊天室。模型愈會推理，邊界模糊的風險反而愈高。

我的做法是讓 General 只保留共通底線，例如繁體中文、外部動作前確認、完成必須驗證。部門使命、資料來源、排程、交接對象與專屬權限，留在各自的 Profile。

這讓隔離不再只靠模型「記得不要越線」，而是從檔案、流程與路由一起約束。

────────────────────────────────

最大的踩雷：把模型工具 Profile 當部門 Bot

系統演進時，我建立過 flash、deep、best 這類 Profile。它們的目的，是依任務成本與推理深度選模型，不是代表財務、客服或工程等組織角色。

兩者混在一起後，治理會立刻失焦。deep 可以回答複雜問題，但它沒有部門 owner；flash 適合高頻工作，但不代表它應持有任何公司資料權限。模型能力是運算策略，部門 Profile 則是責任與授權邊界。

因此我不把 flash、deep、best 算進部門 Bot 數量，也不讓它們取代正式部門角色。否則今天為了省成本換模型，明天可能連角色邊界一起換掉。

────────────────────────────────

Profile 建好，不代表訊息會走對

另一個容易誤判的地方，是看到 Profile 目錄存在，就認為隔離已完成。實際上還要確認 Gateway 是否載入它、Bot 或群組是否路由到它，以及平台授權是否允許該聊天室進入。

我的驗證順序是：

1. 檔案層：確認專屬設定、Skills、Cron 與 memories 位於正確 Profile。
2. 載入層：確認 Gateway 啟動後真的載入目標 Profile。
3. 路由層：確認指定 Bot 或 Chat ID 導向正確 Profile。
4. 行為層：用代表性問題測試角色、資料來源與拒絕越權是否符合預期。

只驗證 Bot 有回話是不夠的。它可能回得很正常，卻是由錯誤 Profile 回答。真正的證據，是入口、路由、工作空間與行為四者一致。

────────────────────────────────

今天的結論

Profile 是企業 Agent 的執行邊界，不是換人格的快捷鍵。聊天室負責入口，Bot 負責平台身份，Profile 才負責設定、規則、能力、排程與記憶。

我最大的教訓是：不要用 Prompt 模擬隔離，也不要用模型名稱代替組織角色。先按責任與資料邊界切 Profile，再把模型當成可替換的運算資源，系統才有機會從「會聊天」走向「可治理的同事」。

下一篇 D9：工作空間切開之後，下一個問題是每個同事到哪裡查資料。我會拆解 Company Brain 的四層知識架構，以及為什麼 Obsidian Markdown 必須是唯一原始資料層。