個人與工作 AI 系統如何分離：用最小資訊完成必要交接

個人與工作 AI 可採平行入口。了解最小資訊交接、Memory 寫入核准，以及 Profile 不等於完整安全隔離的原因。

# 個人與工作 AI 系統如何分離：用最小資訊完成必要交接

同一個 AI 系統可以處理私人待辦與工作專案，但能存取不代表應放在同一個上下文。較穩健的設計，是把個人與工作設為平行入口；若私人事件確實影響工作，只交接足以改變工作安排的最小資訊，例如不可排程時段，而不是私人原因或完整對話。

隱私邊界：本文討論的是資訊、角色與狀態分離。Profile 分離不等於作業系統級隔離，也不能單獨證明隱私或安全效果。

為何「能混用」不等於「應混用」

私人內容通常不必進入工作規劃；工作系統也不需要完整私人背景才能調整截止日。若所有對話都寫進同一份持久 Memory，日後很難區分哪些資訊與交付有關、哪些只屬於私人脈絡，也更難撤回一段已不該在工作中出現的內容。

Hermes 的 Profiles 文件說明，每個 Profile 有自己的 Memory、Session、設定、憑證與 gateway state；但同一份文件也指出 Profile、workspace 與 sandbox 是不同概念。也就是說，它可以提供狀態與角色區隔，卻不會自動成為檔案系統安全邊界。[Profiles 文件](https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/profiles.md)

平行入口與最小交接

這套模型包含兩個平行入口：個人助理處理 personal Board 與個人 Memory；工作主控處理新工作與既有專家。兩者不自動讀取彼此記憶。當私人事件需要影響工作，只交接「工作影響、有效期間、最小限制、保存許可」，而非交接原因、人物、地點或完整對話。

| 欄位 | 例子 | | --- | --- | | 工作影響 | 指定時段不能安排會議或截止工作 | | 有效期間 | 僅限某日 13:00–17:00 | | 私人原因 | 不交接 | | 保存方式 | 只記入工作排程限制，不寫入工作 Memory | | 核准 | 使用者明確同意後才傳遞 |

工作主控收到後可以重新安排 Task，但不應反向要求個人 Profile 補充理由。若限制取消，交接也應失效，而非留下永久的個人標籤。

三道界線

1. 先分類資料

每次輸入先判斷是私人任務、工作任務、暫時聊天，還是需要跨界的事項。不是每段談話都值得寫入持久 Memory。

2. 限制用途

個人資料只服務個人待辦；工作 Board 只保留交付相關資訊。Hermes 的設定可要求 Memory 寫入前核准，適合作為重要資料寫入前的人工停點。[Configuration 文件](https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/configuration.md)

3. 明示交接

交接必須由人提出，並說明對工作有何影響、持續多久、最小限制是什麼、是否可保存。目的不是同步全部記憶，而是讓工作在不暴露不必要資訊下調整。

安全限制不能被角色名稱掩蓋

若多個 Profile 共用 runtime 或掛載目錄，這個設計只能稱為角色與狀態分離，不能稱為完整隱私隔離。高敏感情境仍需評估 container、data mount、OS identity、憑證與稽核紀錄。官方 Docker 文件也提醒，多個 container 不應同時寫入同一資料目錄。[Docker 文件](https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/docker.md)

限制與下一步

導入時可先使用非敏感的個人事項測試，觀察它是否減少不必要揭露、是否增加操作摩擦，以及需要多少人工修正。先列出「永不自動交接」的資訊類型，再採用四欄交接模板；便利不是讓助理知道更多，而是只在需要時知道剛好的資訊。