避免 Agent 膨脹：何時該用 Task、Board、Skill 或 Profile

新題目不必等於新 Agent。用五個問題判斷該選 Task、Board、workspace、Skill 或 Profile，並理解 Profile 不是安全隔離。

# 避免 Agent 膨脹：何時該用 Task、Board、Skill 或 Profile

當每個新問題都變成一個新 Agent，系統通常不會更清楚，反而會累積名稱相近、權限不明、記憶難以維護的角色。較好的起點是：先判斷這份工作需要什麼持久性，再選擇最小的承載單位。只有責任、記憶、工具或運作週期必須長期分開時，才考慮建立 Profile。

範圍說明：本文依據 Hermes 官方概念提出一套實作框架。這不是 Hermes 官方規則，實際效果仍需透過真實工作持續驗證。

問題不在 Agent 數量，而在持久邊界

研究論文、行銷專案、客戶問題與私人待辦看起來都可以各自交給一個 Agent。但「題目不同」不等於需要一個新的長期身分。若每次都新增角色，日後會很難回答：誰負責什麼？哪裡存了哪些記憶？哪些工具或憑證可使用？一個任務結束後，這個 Agent 還有存在理由嗎？

Hermes 的官方 Profiles 文件把 Profile 說明為獨立的 Hermes state：每個 Profile 有自己的設定、環境變數、SOUL、Memory、Session、Skill、Cron、Gateway state 與資料庫；同一份文件也特別區分 Profile、workspace 與 sandbox。Profile 因此不是單純的提示詞標籤，而是需要治理的持久邊界。[Profiles 文件](https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/profiles.md)

先選最小承載單位

以下是一套可採用的決策梯，不是 Hermes 的官方規則：

  1. 一次性且有明確完成條件的工作，先用 Task。
  2. 一串相關任務需要排隊、追蹤或共同節奏時，建立 Board。
  3. 工作實際需要讀寫檔案、程式或研究材料時，指定 workspace。
  4. 已反覆出現、可教且有固定步驟的做法，萃取為 Skill。
  5. 只有責任、Memory、工具／憑證、排程或運作週期必須長期分開時，才建立 Profile。

| 要問的問題 | 是的話 | 預設選擇 | | --- | --- | --- | | 這是否是一件可完成的交付？ | 有清楚完成條件 | Task | | 是否有一串相關任務與共同節奏？ | 需要持續追蹤 | Board | | 是否需要一個操作場域？ | 需要檔案、程式或材料 | Workspace | | 是否會重複、可教？ | 希望可靠重用 | Skill | | 是否必須永久分開身分、記憶、權限或責任？ | 混在既有角色有風險 | Profile |

官方 Kanban 文件把 Board 與 Task 作為持久工作管理的原語；官方 Skills 指南則把可重複的工作說明留到需要時才載入。這與「每個新任務先補一大段記憶」不同：Memory 保存需要延續的背景；能穩定重做的方法才是 Skill 候選。[Kanban 文件](https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/features/kanban.md) [Working with Skills](https://github.com/NousResearch/hermes-agent/blob/main/website/docs/guides/work-with-skills.md)

例子：開始論文研究時，不必先建研究 Profile

第一週若只是界定研究問題與蒐集初始文獻，先建立一張 Task 即可。當研究形成多個里程碑，才建立 Board 與專屬 workspace。若每週都用相同方式篩選文獻與製作證據表，再把流程寫成 Skill。除非它真的需要不同的機密資料、長期獨立記憶或固定自動運作，否則不必急著建立「論文研究 Profile」。

Profile 不等於安全隔離

Profile 可以分開 Hermes state，卻不會自動限制本機檔案系統存取。官方文件明確指出 workspace 與 sandbox 是另一層概念；若多個角色共用 runtime 或掛載目錄，仍需另外處理存取權、憑證與檔案邊界。把角色指令當成安全邊界，會高估它能保護的範圍。

下一次新增 Agent 前，先回答三句話

寫下：「這件事的完成條件是什麼？它是否會重複？它為何不能由既有角色處理？」若最後一題無法指出持久的責任、記憶或權限邊界，先使用 Task、Board、workspace 或 Skill。讓 Profile 成為最後選項，系統才較容易理解、測試與演進。

限制

這套決策梯只避免概念膨脹，不會自動提高結果品質。採用後仍應觀察 token 成本、誤派率、維護負擔與人類修正量，並透過小範圍、可回復的工作持續檢驗。