AI 產出不是知識：用候選層與人工審核守住知識庫

不要把每次 AI 輸出直接寫進知識庫。用候選層保留來源、範圍、不確定性、敏感度與人工接受決定。

# AI 產出不是知識：用候選層與人工審核守住知識庫

AI 可以對話、做研究、產生文件與保存 Memory，但任何一次輸出都不該自動成為正式知識。較安全的做法是在知識庫前加入候選層：先附上來源、適用範圍、不確定性、敏感度與人類審核人，再決定是否接受。這樣可以避免把猜測、過時來源、任務暫記與私人內容一起制度化。

治理邊界：knowledge-outbox 與 main-only gate 是本文提出的候選機制，不是 Hermes 內建知識庫功能，也不會自動把內容同步到正式知識庫。

對話、任務產出、Memory 與正式知識是四種不同東西

Session 是對話與工具活動的歷史，可用來回看來源、判斷與過程；它不是整理完成且能跨情境使用的知識。Hermes 的 Sessions 文件說明它保存訊息、工具呼叫、模型設定與時間資訊，這讓追溯更容易，但不能讓一段紀錄自動變得正確。[Sessions 文件](https://github.com/NousResearch/hermes-agent/blob/main/website/docs/user-guide/sessions.md)

Memory 是給未來 Session 使用的有限持久脈絡；Task 產出則回答某一工作問題，可能有價值但未必可跨情境重用。正式知識需要更高標準：來源可追溯、適用範圍清楚、未知事項可見、敏感度已判斷，且有明確的人類接受決定。

候選閘門：先提出，再接受

本文提出的模型是讓 specialist 回傳任務產物、來源與不確定性；只有 Work Chief of Staff 可以建立 knowledge-outbox 候選封包。建立前要檢查：

1. 這項內容是否具有跨任務重用價值？
2. 原始來源與任務／artifact 在哪裡？
3. 哪些是事實、推論與尚待驗證的假設？
4. 是否包含私人、敏感或不應外流的資訊？
5. 誰將審核、接受、修訂或拒絕它？

outbox 的意思是等待人工審閱的候選，不是知識庫，也不觸發同步。它把產生者與接受者分開，避免速度直接取代判斷。

一份候選知識封包應包含什麼？

以下是虛構的資料結構，不是目前 Hermes runtime 產生的真實封包：

candidate_type: reusable-principle
claim: 對不需要即時協作的狀態更新，先採非同步文字回報，再決定是否開會。
source_task: research-task-example
source_artifacts:
  - literature-summary.md
evidence:
  - 官方或原始研究連結應列於此處
scope: 知識工作團隊的例行狀態同步
uncertainties:
  - 尚未驗證是否適用於緊急事件或高度互賴工作
sensitivity: public
review_status: pending-human-review
proposed_destination: team-collaboration-guidance

審核者可以接受、限縮適用範圍、要求補證據或拒絕。若來源只支持「部分團隊在特定情境下有效」，claim 就不能擴寫成「所有遠距團隊都應如此」。候選層的價值，是讓推理邊界在正式寫入前被看見。

為何不讓每個 worker 直接寫入？

直接寫入少掉的不是一個步驟，而是品質責任。專家最接近工作細節，也最容易把局部結論當成一般規則；研究員的來源清單、寫作者的草稿與執行者的暫時 workaround，都應先留在各自 Task 的證據脈絡。只有通過可重用性與邊界檢查，才值得成為候選。

若要沉澱的是固定程序，Skill 往往比把流程塞進 Memory 或知識庫更合適。官方 Creating Skills 指南提供把可表達程序封裝為 Skill 的做法；它不表示所有工作輸出都該被制度化。[Creating Skills](https://github.com/NousResearch/hermes-agent/blob/main/website/docs/developer-guide/creating-skills.md)

限制與下一步

單一主控閘門可能成為瓶頸，也可能錯過專家的判斷。它需要固定候選格式與定期審閱，否則只是把雜訊移到另一個資料夾。實際採用時，先要求每份候選附上可重用主張、來源、範圍、不確定性、敏感度與審核人，再用少量真實工作評估它的摩擦與品質。