對照表 · 八步啟用 · 定量閘門 · VNC 15 分鐘核對
自 2026.4.10 前後起，OpenClaw 主線裡出現可選的 Active Memory 插件路徑：在主模型正式回答前，插入一段面向「本會話任務」的記憶子代理工作流，用於把偏好、近期事實與歷史細節主動拉進上下文，減少用戶反覆手動 @記憶。與《Memory Palace / Imported Insights 與上下文膨脹》 側重「可視化召回與導入語料治理」不同，本文只釘 Active Memory 插件：何時啟用、模式如何影響 token 帳單、/verbose 裡該看什麼、以及租用節點上 transcript 與磁碟隱私的硬邊界。讀完你應能複述：與 Palace 的分工表、八步上線順序、四條可寫進變更單的量化閘門、以及十五分鐘內如何在 VNC 與 Gateway 控制臺之間把「記憶成本」對齊到發票行項目。
Active Memory 的本質是多一次（或一段）模型調用/檢索合成，而不是免費緩存。下面五類誤區在遠程 Mac 上更常見，因為磁碟與工作區歸屬往往跨外包、跨客戶，若不寫清，審計時很難解釋「這段記憶是誰的、保留多久」。
與 Palace 混讀日誌：Palace 回答「召回了哪些塊」；Active Memory 回答「在進主模型前額外合成了哪些中間態」。把兩者日誌行混在同一工單模板裡，排障會分叉。
模式全開當默認：message / recent / full（或文檔中的等價命名）對首包時延與 token 上限影響非線性；默認 full 往往是最貴的「演示配置」，不是生產配置。
把 /verbose 當聊天玩具：/verbose 是排障與審計開關，長期開著會改變日誌噪聲與部分中間件的採樣行為；應與《無回復排查》 裡的「觀察窗紀律」一起讀。
忽略 transcript 選項：若開啟與 transcript 相關的調試持久化，租用磁碟上會出現可反查的用戶語句副本；這與《SOUL/MEMORY/IDENTITY》 文件層策略必須交叉評審。
與多模型路由脫節：子代理若走不同 provider，會在 429/超時面上與主鏈解耦失敗；應回到《多模型路由與成本》 把「主備 + Active Memory 側鏈」寫進同一降級表。
用「問誰、付什麼帳、落什麼盤」三列對齊，而不是用產品營銷名對齊。
| 能力 | 主要回答的問題 | 計費與延遲敏感點 | 遠程 Mac 注意 |
|---|---|---|---|
| Active Memory 插件 | 主回復前要不要插入「會話任務向」記憶合成 | 多一段子調用/合成；模式越寬越貴 | 同用戶圖形會話裡核對插件開關與 Gateway 指標；避免與無頭帳戶分叉 |
| Memory Palace | 可視化塊召回是否自洽、是否與磁碟權威衝突 | 索引重建與檢索體積 | 大導入後磁碟與 CPU 峰值；見 Palace 專文 |
| SOUL/MEMORY 文件 | 長期人格與事實的編輯流程 | 人工維護成本 | VNC 下 diff 與權限；與 SecretRef 審計同節奏 |
經驗法則：若你的團隊痛點是「用戶懶得手動維護 MEMORY，但願意多付一點模型費換少打字」，Active Memory 優先級高；若痛點是「導入後索引爆炸、Palace 與文件對不齊」，應先去讀 Palace 專文而不是疊插件。
順序固定為 備份 → doctor 基線 → staging 單通道 → 模式收斂 → 生產灰度 → 觀測 → 審計 → 文檔化。任一步失敗只允許回滾到上一步。
備份工作區與配置：含 openclaw 版本指紋；與《v2026.4.5 升級與 doctor》 同一 tarball 策略。
關閉旁路：確認默認路徑下 Active Memory 未啟用時的 Gateway P99 與錯誤率，作為對照基線。
staging 單 IM 或 WebChat：只開一條通道，避免多通道並發把子代理日誌攪在一起。
模式從窄到寬：先 message 或等價最窄模式，再評估 recent；full 僅留作排障短時窗口。
/verbose 對照：核對子代理是否按預期觸發、是否出現重複合成；與 Gateway request id 對齊。
成本對齊：把子代理 provider 與主鏈寫入同一張「429 與限額」表，見多模型路由長文。
隱私閘門：若啟用 transcript 類選項，寫明保留周期與清除 Runbook，並在 VNC 會話裡抽查目錄體積。
變更單歸檔：八步截圖或日誌片段進 Wiki，避免「只有某位工程師的聊天窗口裡見過」。
P1: 同一 request 能在日誌裡串起「子代理 → 主模型」兩段耗時 P2: 模式從窄到寬每檔都有 24h 指標截圖或導出 P3: /verbose 默認關閉；開啟需 ticket 與時間窗 P4: 磁碟可列出 Active Memory 相關持久化路徑與 owner
下列項假設你已在遠程 Mac 打開與 Gateway 同一用戶的圖形會話，用於點系統權限、看瀏覽器控制臺與對比菜單欄時間。
| 核對 | 要點 | 通過 |
|---|---|---|
| 插件開關可見性 | 配置界面或文檔化環境變量與運行實例一致 | 無「SSH 裡一套、桌面裡一套」 |
| /verbose 窗口 | 短時開啟能復現子代理軌跡 | request id 與 Gateway 對齊 |
| 磁碟抽樣 | 相關目錄無意外超大日誌或 transcript | 路徑與留存策略寫在 Wiki |
| 多模型 | 子代理與主鏈 provider 在 UI 或配置文件中可讀 | 429 時降級順序可執行 |
補充：遠程團隊常把「能 SSH 進去」誤當成「能驗收」。對 Active Memory 這類跨子系統特性，短 VNC 窗口 + 固定對照腳本 比長 SSH tail 更省總工時——這與站內多篇 OpenClaw 圖形化實踐的結論一致。
從業務視角，記憶子系統上線最大的隱性成本往往不是 API 帳單，而是可審計性與回滾故事：當客戶問「你們為什麼記得這句話」時，你能不能在三分鐘內指出是子代理合成、Palace 召回，還是 MEMORY 文件裡的明文。Active Memory 讓「少打字」變容易的同時，也把中間態暴露面變大；治理動作必須跟得上。
與 Active Memory 分工對照閱讀。
閱讀 →磁碟權威與編輯清單。
閱讀 →子鏈路與主鏈 429 協同。
閱讀 →可以，但建議仍從窄模式 + 單通道 staging起步，並寫清「超閾值自動回退」；否則第一個月底就會面對「為什麼 token 翻倍」這類不好回答的財務問題。
主要風險是日誌量與採樣開銷；生產上應 ticket 化、限時、限通道，並與現有日誌輪轉策略對齊。
取決於你是否把狀態落在磁碟與受控目錄；若只存在會話 RAM，關機即失。應在變更單寫清「允許落盤的路徑」與「到期刪」，並與續費/換節點文互讀。
Active Memory 把「記憶」從靜態文件推進到可按會話調度的子代理能力：收益是更少重複提問與更連貫的多輪任務；代價是更複雜的日誌、更高的 token 上限與更敏感的隱私面。沒有 Palace 與文件層紀律兜底，插件只會放大混亂而不是消除混亂。
自有 Mac 上你當然可以慢慢摸配置；但在按小時計費、磁碟與帳號邊界更「公共」的遠程環境裡，任何「多寫一點盤、多打一圈日誌」都會被放大成成本與合規問題。把八步 Runbook 與四條閘門寫進 Wiki，再用短 VNC 窗口做圖形驗收，是更穩妥的落地方式。
若你需要一臺可同時 SSH 配 OpenClaw、又用 VNC 對著 Gateway 與系統彈窗做驗收的 Apple Silicon 環境，可通過 VNCMac 租用遠程 Mac：主按鈕進入 購買頁；連接說明見 遠程連接 與 首頁。把本文與 Memory Palace、SOUL/MEMORY、多模型路由三篇放在同一目錄下，後續升級 OpenClaw 時不容易漏改子鏈路。