記憶圖與資產健康

本頁用於檢查和維護獨立 Evolver 的本地記憶圖，並區分記憶圖故障、資產質量問題和事件視圖問題。

這裏的拓撲主要指本地記憶圖與資產之間的關聯結構。它用於發現孤立、重複、陳舊或異常集中的經驗，不是 Hub 調度、信任晉級或發佈的自動決策器。

查看診斷

evolver memory-graph status
evolver asset-health
evolver reuse-report
evolver cycles

關注的問題

• 大量資產沒有可追溯的來源、驗證或複用關係。
• 同類失敗反覆生成新資產，卻沒有收斂或撤銷舊策略。
• 少數陳舊資產佔據大部分召回，新的真實結果沒有進入圖譜。
• 事件存在但物化視圖缺失，或報告中的數量相互矛盾。
• 複用集中在單一環境，跨環境結果長期缺失。

區分源數據、派生視圖與圖狀態

根事件記錄保存已發生的活動，物化視圖是根據這些事件整理出的讀取結果。記憶圖另有自己的當前狀態、壓縮狀態和保留歸檔。診斷時先確定出問題的是哪一種數據，再選擇恢復方法。僅因為某個報告缺少結果，就同時重放事件、清理歸檔和重置圖，會使原問題難以定位。

恢復能夠重建什麼

圖恢復使用保留的當前 epoch 數據重建壓縮狀態；已刪除的源數據不能由維護命令重新生成。歸檔 prune 會減少保留歷史，因此不能把它作為所有圖故障的第一步。reset 則開始新一代本地狀態，即使先生成了備份，也需要明確記錄為什麼選擇放棄當前代狀態。

例如，報告顯示 busy 時應先查正在工作的進程，等待受控任務結束或按維護流程停止相關寫入，再查詢狀態。如果佔用解除後狀態正常，便沒有必要繼續執行恢復或重置。每次動作都應對應一個已確認的問題，後續檢查決定是否還需要下一步。

排查順序

1. 確認當前運行目錄與節點身份，保存故障時的狀態報告；不要混用不同實例的數據。
2. 用 memory-graph status 檢查恢復狀態和佔用狀態。返回失敗時先區分 degraded 與 busy：前者需要調查恢復數據，後者先排查正在寫入或維護的進程。
3. 檢查資產 ID、最近循環與複用證據。關聯缺少驗證結果時補齊驗證，不能靠圖維護命令生成成功證據。
4. 涉及寫入的維護前，暫停相關寫入並備份圖目錄。根據下表選擇一項操作，完成後再查詢狀態。
5. 如果異常位於根事件派生視圖，先核對事件源與備份，再使用 evolver replay；它不負責恢復記憶圖歸檔。

選擇維護操作

epoch 是本地記憶圖的一代狀態。重置不是常規修復步驟，也不等於重建事件視圖。上述維護命令不提供 --dry-run；不要把命令表當作需要逐行執行的腳本。

確認修復結果

檢查狀態不再降級或佔用異常，保留維護報告、備份位置和前後差異，再核對受影響的資產及複用記錄。仍然失敗時停止進一步清理，保存錯誤原因與現有歸檔，交由運行維護負責人處理。

使用邊界

圖密度、重複率或分組關係只能提示需要調查。它們不能單獨提高 Worker 容量、自動晉級資產或認定某個節點異常。

相關頁面

• 質量信號
• 審計軌跡

EvoX 文檔 · 開發者 · 獨立 Evolver 維護