1. 痛點拆解：記憶不是「多寫幾段 Markdown」
（1）邊界漂移：把運行日誌、臨時草稿與長期偏好全塞進 MEMORY.md，檢索時會把過期假設當真理；而 workspace 裏的業務文檔若被誤當「系統記憶」，又會污染人格層。（2）檢索噪聲：純關鍵詞或粗粒度分塊會把相似措辭、不同決策混在一起，模型看起來「記得很多」實則召回的是錯片段。（3）Token 膨脹：系統提示、頻道歷史摘要、工具 JSON、MCP schema 與記憶片段同池競爭；你只盯着對話字數時，真正的爆點往往在隱藏前綴。升級後若 doctor 與 channels 正常仍變慢，優先做上下文審計而非換模型（參見《無回復排錯》的診斷階梯）。（4）遠端路徑與權限：Gateway 跑在遠端 Mac 時，~/.openclaw 與 workspace 若與用戶預期不一致，會出現「本機改完、線上沒生效」的假失憶——與《遷移 Runbook》同類。
2. 記憶分層：寫什麼、不寫什麼
| 層級 | 建議承載 | 反模式 |
|---|---|---|
| 長期偏好 / 術語表 | 穩定事實、組織內專有名詞、審批邊界 | 把一次性任務結論當永久真理；不寫版本與日期 |
| 項目 workspace 文檔 | 可版本化的設計說明、接口契約、Runbook | 把密鑰、Cookie、Webhook secret 明文落盤 |
| 會話級 / 短期緩衝 | 當前線程目標、待確認問題、工具中間態 | 無限累積不裁剪，導致同一摘要重複注入 |
3. 落地五步走：把記憶變成可審計工程
- 寫清 MEMORY 契約：規定哪些鍵/段落可自動寫、哪些必須人工審；每條長期記憶帶生效範圍（頻道/項目）與最後驗證日期。
- 固定檢索入口：先過濾頻道與目錄，再向量/關鍵詞；禁止「全庫一把梭」作爲默認路徑。
- 摘要策略版本化：長會話滾動摘要要有代數與哈希，升級後對比是否重複注入舊摘要。
- 工具面收窄：MCP/Skills 只暴露當前任務需要的工具，降低 schema 與示例對前綴的佔用（詳見《MCP 與 Token》）。
- 遠端環境對齊：launchd plist 中顯式寫入
HOME、PATH與密鑰引用路徑；重啓後跑一遍「記憶讀寫自檢」腳本，確認與交互 shell 一致（參閱《onboard 與常駐》）。
4. 可引用閾值（評審向）
可寫進方案書的量級（需用你的日誌複測）：
- 當單次請求裏工具返回 + 記憶片段合計穩定超過約 8k tokens（依模型窗口調整）而 p95 延遲陡升時，應優先裁剪工具面或分段檢索，而不是先加記憶條數。
- 若滾動摘要每輪重複注入導致同一結論在上下文中出現 3 次以上，通常存在摘要去重缺失或兩代摘要並存。
- 團隊每周在「記憶錯亂 / 上下文爆炸 / 升級後失憶」上浪費超過3 小時，應把記憶治理與網關配置升格爲發布門禁，而不是繼續手工改 MEMORY。
5. Token 膨脹：診斷階梯
| 階梯 | 檢查什麼 | 常見根因 |
|---|---|---|
| 1）前綴剖面 | 系統提示、頻道規則、固定免責聲明各佔比例 | 多頻道策略複製粘貼導致重複塊 |
| 2）工具與 MCP | 單次調用返回體積、是否嵌套大 JSON | 未分頁、未字段投影、schema 過寬 |
| 3）記憶檢索 | Top-K 與片段最大長度 | 「多即是好」把低分片段也注入 |
| 4）會話摘要 | 摘要是否隨輪次線性增長 | 無截斷、無合併、無過期策略 |
6. FAQ：自改進、多頻道與遠端 Mac
問：自改進寫入 MEMORY 要不要自動生效？建議默認人工閘門或「低影響自動 / 高影響待審」兩檔；否則錯誤會被固化成「組織記憶」。
問：多頻道共用一份記憶嗎？按合規與噪聲拆分：客戶支持與內部研發不宜共用同一向量空間；至少做 scope 元數據過濾。
問：遠端 Mac 上路徑怎麼驗？以Gateway 進程實際用戶的 HOME 為準，而不是你 SSH 登錄用戶；不一致時表現爲「文件在、讀不到」。
問：升級後失憶？先比對狀態目錄與 workspace是否隨 plist/容器變更；完整清單見《遷移》與《Gateway 回滾》。
7. 深度分析：從「能聊天」到「能運營」
2026 年代理棧的競爭點已從「能不能連上模型」轉向記憶是否可審計、上下文是否可預測。企業內部署時，法務與安全會追問：哪些記憶是個人偏好、哪些是組織知識、是否可刪除與可導出——若在設計階段不把 scope 與保留期限寫進契約，上線後只能打補丁式刪文件。
工程上，記憶與 RAG 的邊界越來越模糊：一邊是 Markdown/筆記，一邊是向量庫。OpenClaw 用戶常犯的錯誤是雙寫不同步——MEMORY 裏改了結論，向量庫未重建，檢索仍拉回舊段落。評審應要求給出單一真源或明確的同步 Runbook。
遠端 Mac 作爲 7×24 Gateway 宿主機時，記憶治理還要疊加磁盤與備份：時間機器或快照策略是否包含 ~/.openclaw 與 workspace；恢復後是否要觸發「記憶重建/重索引」——與《遠端部署》中的穩定性章節同一邏輯。
與下遊模型銜接時，要在網關層約定最大記憶條數、單條上限、失敗降級（檢索超時則只用會話摘要），使尾延遲可解釋；否則運維會把一切慢都歸因爲「模型不行」。
8. 可觀測性：把「偶發胡說」寫成指標
建議在 runbook 固定：每輪注入的記憶條數與總 tokens、檢索空結果率、工具返回 p95 體積、摘要重寫次數。四類同時惡化時優先懷疑配置漂移；僅延遲惡化而記憶條數穩定，優先懷疑工具/MCP 返回。
| 觀測項 | 採集方式 | 異常時優先懷疑 |
|---|---|---|
| 記憶注入 tokens | 每請求結構化日誌 | Top-K 過大、片段過長、去重缺失 |
| 檢索命中率 | 固定問題集小時回歸 | 索引未更新、scope 過濾錯誤 |
| 工具返回體積 | 按工具名分位數 | 未分頁、trace 級別日誌進響應 |
9. 對內評審：你該索要的證據包
除截圖外，應包含：MEMORY 契約版本、檢索參數表、升級前後上下文剖面對比、失敗對話樣本與期望記憶。沒有失敗樣本的評審，往往在真實流量第一周被推翻。
10. 收束：本機聯調輕快，生產要記住「可預測」
（1）當前方案限制：默認記憶策略易噪聲化；工具與 MCP 易撐爆前綴；多頻道與遠端路徑易漂移。
（2）爲什麼遠端 Mac 常更省心：專用節點固定用戶與 plist，睡眠策略與備份可統一；與本站其它 OpenClaw 教程同一 macOS 行爲面。
（3）與 MACGPU 場景：若你希望低門檻試用常駐遠端 Mac 跑 Gateway 並復用 Apple Silicon 工具鏈，而不是維護雜牌 VPS 環境，MACGPU 提供可租賃節點與幫助入口；下文 CTA 直達首頁套餐與幫助（無需登錄）。
11. 實戰補充：與子代理、定時任務的關係
啓用子代理或定時任務時，記憶寫入應明確主會話與分支會話的邊界，避免並行工具把同一 MEMORY 文件寫衝突；重負載時宜把長檢索與批處理遷到專用 worker，Gateway 只保留編排與窄工具面。參閱站內子代理與 Webhook 無人值守文章做組合選型。