審查未連結的主張
knowledge_remember 會在主張中沒有任何名稱能精確對應到一個頁面時，將主張儲存而不附加主題頁面。排程維護接著會執行 knowledge_relink，但只連結那些記錄的來源頁面是實體頁面、或其文字中明確指出一個頁面的主張。其餘的主張會保持未連結狀態，無法從它們所關聯的頁面中看到。本技能負責以判斷力處理這些殘留主張。請依此順序進行：先連結，再處理重複和被取代的主張，最後更新頁面內容。
1. 列舉殘留主張
呼叫 knowledge_status 取得目標範圍，並以 knowledge_ontology 取得目前指紋。首先在不開啟 dryRun 的情況下執行 knowledge_relink，以便所有能連結的主張都能被連結。接著用 knowledge_relink 搭配 dryRun: true、include: "all" 和 limit: 10 來列出殘留主張，並跟隨 nextCursor：取得所有目前沒有連結頁面且沒有來源頁面的主張，無論是由哪個工具儲存。每次呼叫最多回報每種結果 10 個範例，因此 limit: 10 會回傳所有它所檢查過的主張。
使用 knowledge_record 搭配 metadataView: "full" 讀取每個主張。其中的 subject_hint（如果有的話）是儲存者自己對主張內容的描述，也是判斷其主題最強的線索。根據這些主張的內容進行分組（可能是某個功能、PR、決策討論串、人或偏好），然後再選擇頁面。大多數主張只有在與其相鄰的主張放在一起時才有意義：關於同一個 PR 的一系列狀態快照，通常會以一個結果主張作結。
2. 選擇主題頁面
針對每個主張群組，使用 knowledge_grep 和 knowledge_lookup 尋找候選頁面，並讀取其「狀態」和「時間軸」。忽略已撤銷的頁面和 fixture 頁面。
- 主要主題是主張所要斷言的對象。只有在主張同時對該實體做出陳述時，才添加次要主題，例如做出決定的人，或產品所屬的公司。簡短的提及並非主題。通常兩個或三個主題就足夠了。
- 由某人陳述的偏好或決定，應放在該人的個人頁面上。請勿將單一人的偏好變成專案或公司政策。
- 根據證據比對身分，而不是根據相似的名稱。當主張中提到某個可能對應到現有頁面的名稱（例如可能是另一個服務的產品名稱）時，應透過配置、URL 或頁面本身的別名等證據來確認。如果不確定，則讓主張保持未連結狀態並回報。
使用 knowledge_annotate 的 entities 參數進行連結，傳入完整的實體清單（它會取代現有的清單）以及主張目前的修訂版和雜湊值。主張的陳述文字、證據和生命週期保持不變。
3. 建立遺漏的頁面
將每個主張都連結到最接近的現有頁面，可能會將真正的埋沒在寬泛頁面的時間軸中。在以下情況下建立新頁面：
- 一個離散的主題（功能、專案、工具或重要的 PR）有大約五個或更多的主張，或者有自己的設計、證據和結果歷史；或者
- 一個人或組織在所屬主張中具有作者、擁有者或決策者身分，沒有自己的頁面，但具有身分證據（例如
gh pr view顯示的 PR 作者）。
請勿為單次提及或時間軸條目已涵蓋的一次性修復創建頁面。使用 knowledge_save_page 搭配本體 type、別名，以及作為 source 的身分證據。人物頁面使用 identity.status: partial，除非身分已完全確立。撰寫一段簡短的狀態，引用這些主張並附上註明日期的時間軸。然後將主張連結到新頁面，保留它們現有的次要主題，並從其父頁面連結到新頁面。
4. 移除重複與被取代的主張
- 重複： 兩個主張對同一事件斷言相同的事實、決定或偏好。保留具有擁有者批准的回憶（owner-approved recall）的那個，否則保留較早的那個，否則保留歸因較完整的那個。使用
knowledge_annotate的addEvidence將倖存者缺少的任何證據複製過去，然後使用knowledge_withdraw撤銷另一個主張，撤銷原因中需指明倖存者的 ID。 - 被取代： 後續主張明確修正了較早的主張（例如助理修正自己的報告）、解決了較早主張未解決的問題，或報告了同一個具體項目（同一 PR、提交或決定）的最終狀態。使用
knowledge_withdraw搭配說明原因（指明取代它的主張 ID）來撤銷較早的主張。請勿在這裡使用knowledge_correct：它會發佈替換主張的新副本，從而產生另一個重複。 - 兩者皆非： 不同時間點的狀態快照（例如 CI 在一個提交失敗，後續合併成功）是歷史，而不是錯誤。請保留它們。僅有矛盾並不足以證明撤銷是正當的。如果不確定，請保留兩者並回報該組。
5. 更新頁面內容
連結只能讓主張從其頁面中可被查閱；它不會改變頁面的內容。僅當主張改變了頁面的持久狀態時才編輯頁面：例如做出決定、建立偏好、功能已落地或已發佈、解決了先前的未決問題，或頁面文字被後續主張證明為錯誤。
- 將一系列進度快照歸納為其最終結果。快照（例如 CI 執行、開啟的 PR、本地提交）最多只能作為標註日期的時間軸條目，永遠不應放入狀態中。
- 在將可變狀態寫入為當前狀態之前，請先即時檢查其狀態（例如使用
gh pr view檢查合併狀態），並說明檢查時間。合併不等於部署，部署也不表示某個特定 Gateway 正在執行該程式碼。 - 當設計或決策頁面與後續的決定矛盾時，應在原文字旁添加一則標註日期的修正說明，而不是直接改寫原文。將已回答的未決問題標記為已解決，並保留原始問題。
- 使用
[[claim-id|label]]形式的連結引用每個新增的句子。
使用 knowledge_edit_body 進行章節層級的編輯。從一次完整的頁面讀取計算 UTF-16 偏移量，並在每次編輯前重新讀取修訂版和雜湊值：其他工作階段可能會同時編輯繁忙的頁面。優先採用插入文字而非取代的方式。只有當整個狀態區段都已過時時，才取代整個區段，並保留其已有的主張連結。
6. 驗證與回報
針對每個已連結的主張，使用 expectedEntities 執行 knowledge_verify；針對每個新增或編輯過的頁面，使用 expectedLinks 執行驗證。再次列舉殘留主張：在您工作期間可能已有新的已記憶主張抵達。以相同方式處理它們，或是進行回報。
回報已檢查和已連結的主張數量、已建立的頁面數量、已撤銷的主張（並為每個撤銷標明存活或被取代的主張）、已編輯的頁面數量，以及尚未連結的主張及其原因。當以無人值守模式執行時，絕不要求決策：將不確定的身分、不確定的重複以及您僅憑猜測才會建立的頁面保持原狀，並將其列在報告中供人員處理。
以排程審查方式執行
知識維護在其夜間重新連結階段之後，當仍有私人的已記憶主張未連結時（maintenance.reviewJobId），會將此審查排入佇列。此執行是無人值守的：
- 首先呼叫
knowledge_status。如果範圍不是private或寫入已停用，請以AUTOMATION_FAILED作為第一行回覆，並在下一行說明原因：工作者已失去擁有者的存取權，需要重新設定。 - 依序執行步驟 1 到 6。在結束前再次檢查殘留主張，因為在執行期間儲存的主張也屬於同一個待處理工作。
- 如果沒有任何事情需要處理，請回覆
NO_REPLY。否則，請回覆步驟 6 的報告內容。
設定排程審查
審查需要擁有者私有的存取權，這只能從擁有者直接對話所衍生的工作階段取得。請從該對話中進行設定：
-
產生一個保留的工作者：使用
sessions_spawn搭配runtime: "subagent"、cleanup: "keep"和context: "isolated"，其任務是呼叫knowledge_status並回報範圍。僅在它回報private且寫入已啟用時才繼續。保留回傳的工作階段金鑰。 -
為該工作者建立自動化任務。它需要一個排程，因此可以設定一個數年後的單次日期；維護會按需執行它。
openclaw automations add --agent <agent> --name knowledge-unlinked-claims-review \ --session "session:<worker-session-key>" --at <date-years-ahead> --keep-after-run \ --model <provider/model> --no-deliver --timeout-seconds 3600 \ --message "遵循 knowledge-unlinked-claims 技能，以排程審查方式執行。"該任務會記錄其建立時所使用的推論帳戶。請選擇一個使用該帳戶的模型（一個具有驗證設定檔的提供商）；否則每次執行在模型被呼叫之前就會失敗。
-
將
plugins.entries.knowledge.config.maintenance.reviewJobId設定為該任務 ID。 -
驗證它：
openclaw automations run <job-id> --wait必須在工作者回報私有範圍後完成，並且maintenance_status在下一次輪詢後回報審查結果。
停用該自動化任務以暫停審查。重設或移除工作者所源自的擁有者對話將會撤銷其存取權；屆時需重新設定此審查。