雖說昨天有講要把知識庫概念補完，但是想想好像先把這個小節講完好像比較完整，不然之後可能忘記

用戶記憶和知識庫的定期整理

增量更新的優點是即時，但每次只看到一個局部。長期運行後，多次局部正確的修改仍可能累積出全局問題：同一事實傘落在多個文件中，新舊說法同時存在，摘要逐漸偏離原始證據，目錄結構也不再適合當前的知識規模。因此系統還需要定期進行依次"全量整理"。
可以把它理解為在知識管理中的具體實現：前台交互期間不斷累積新證據和局部更新，後台則在週期性窗口裡從全局視角重新審視整個知識體系。這也呼應Claude code自動記憶在索引接近上限時，主動合併或移出細節的作法。

這個過程至少包含3個核心工作：
1.去重、去舊與合併：全量掃描當前知識、識別語意重複、已被取代、過度碎片化或只有表述差異的條目，將其刪除、歸併或重寫。同時重新建立文件間的連接、入口頁和索引頁，必要時拆分過大文件、合併過小文件或調整目錄層次。這裡刪除的是可服務的知識表達、不是下層指增不改的原始證據。(畢竟原始證據是要改啥😅)
2.回到原始數據核查：不能只在已有摘要之間互相改寫，否則早期的遺漏與誤讀會一代代傳下去。整理Agent需要逐段對照原始對話、execution trajectory(執行路徑)、業務文件與工具輸出、檢查摘要是否遺漏關鍵事實、丟失否定詞或時間條件，以及是否把推測錯當成了事實。對大型知識庫可按目錄、時間或主題分批掃描，但必須保留覆蓋清單，確保分批處理最終覆蓋全量，而不是隨機抽樣。
3.衝突解決與場景限定：遇到互相矛盾的說法時，不應簡單地"保留最新一條"或讓模型猜哪一條正確，而要追溯各自的原始信息源，檢查它們是否應該分別在不同時間、對象、地域、任務或前置條件下成立。如果兩者都有效，就不是刪除其中一條，而是把各自的是用場景明確寫入知識; 如果證據仍不足，則應保留衝突與待確認狀態，不得強行收斂成一個確定結論。

定期整理雖是全量過程，產物仍不應直接覆蓋主庫。它同樣由proposer agent在分支上提交重組diff，再由異源reviewer agent結合原始證據審核。由於全量重組的diff往往較大，實踐中可以按目錄或主題拆成多個PR，但應共向同一份整理計畫與覆蓋清單。全部PR通過後，除了重建全量派生索引，還應回放一組典型檢索與問答用例，確認新結構沒有讓原本可找到的知識變不可見。整理週期可以按時間(ex.weekly/monthly)觸發，也可以再新增條目數、衝突數或檢索質量下降超過閾值時觸發。

失效內容的檢測與下線： 一篇被新版取代的舊政策若仍留在庫中，檢索時可能與新版一起被召回，讓模型給出自相矛盾甚至過時的答案。生產系統通常給每個分塊附加版本號、生效/失效時間等元數據，在檢索階段就過濾掉已失效的內容，或在提煉摘要時顯著標註"此條於某日已廢止"。這與用戶記憶裡的版本化衝突檢測是同一思路，只是搬到了共享知識酷的尺度上。

多用戶共享的權限與租戶隔離：知識庫面向所有用戶共享，但"所有用戶"不等於"所有內容所有人可見"：不同部門、不同租戶、不同權限等級的用戶，能看到的文件範圍往往不同。關鍵原則是檢索必須按調用者的權限過濾 ，絕不能讓權文件進入某個上下文。把權限過濾下推到檢索層尤其重要：一旦敏感內容進入了LLM的上下文，就很難保證它不以某種形式洩漏到最終回答裡。多租戶系統還須保證租戶之間的向量索引和元數據相互隔離，避免一個租戶的查詢"串味"檢索到一個租戶的私有知識。

anthropics/knowledge-work-plugins 是 Anthropic 維護的 Claude Cowork／Claude Code 外掛集合，將 Claude 預先配置成不同職能的工作助理，例如 Sales、Engineering、Data、Finance、Legal、Marketing、Customer Support 與 Bio Research。它解決的不是傳統軟體功能，而是把職能知識、工作流程、Slash Commands，以及企業工具連接器整合成可直接安裝和客製化的 AI 工作環境。
GitHub： https://github.com/anthropics/knowledge-work-plugins