先查 MEMORY 還是先查 Docker 內存？

有 Exit 137 或容器頻繁重啟先查資源與 cgroup；進程穩定但越聊越慢優先查會話上下文與 MEMORY 結構。

MEMORY.md 多大算失控？

無清晰章節時超過約八百到一千二百行通常檢索困難，應分章、摘要或外置知識庫，並設周合併。

與可觀測性文章如何分工？

可觀測性文側重 gateway 探針與 JSONL 階梯；本文側重上下文與記憶文件治理，兩者同一值班手冊並列。

2026 OpenClaw MEMORY.md 與會話上下文治理：Mac 雲 7×24 可復現審計清單與排障順序

你已經能跑通網關，但回覆越來越慢、Token 賬單爬坡、同一句澄清反覆出現時，問題往往不在「換一個更大模型」，而在會話上下文與長期記憶文件是否在無紀律增長。本文說明誰會撞上這類隱性債務、你能得到什麼（可審計的分層策略與值班順序），並給出症狀對照表、至少五步周度治理與 Gateway 對齊、可引用參數與 FAQ；與站內 OpenClaw 可觀測性與 JSONL 巡檢互補——前者盯網關與探針，本文盯上下文與 MEMORY 面。

1. 導語摘要：上下文膨脹與「沒報錯」的假象

2026 年 OpenClaw 常駐 Mac 雲或 Linux 時，進程健康、doctor 通過、端口開放，都不等於上下文經濟健康。每輪仍要把歷史、工具回執與記憶注入拼進提示；MEMORY.md 與摘要無限堆疊時，延遲與費用上升、「上週規則」丟失——實為注入噪聲壓過信號。記憶面要產品化紀律：誰寫長期事實、多久合併、哪些只進日誌。下文給誤判拆解、對照表、五步節奏，並與 JSONL 跟讀銜接。

2. 痛點拆解：四條常見誤判

下列模式在 7×24 場景反覆出現：

把變慢一律歸因模型或網絡：若 p95 延遲與消息輪次強相關、與模型提供商狀態頁弱相關，應優先採樣「本回合注入 token 近似規模」（通過日誌字段或自建計數），而不是先換 endpoint。
把重複提問當成「模型不聰明」：若規則實際寫在過長的 MEMORY.md 中段且從未被摘要或分層，模型可能在上下文中根本未穩定命中該段；需要結構治理而非調 temperature。
周更文件從不收斂：把 MEMORY 當 append-only 日誌，三個月後出現數千行「臨時結論」，合併成本高於重寫——這是流程缺失，不是工具缺陷。
與 Docker OOM、磁盤寫滿混為一談：OOM 常伴隨 Exit 137 與容器重啟；上下文問題常伴隨進程仍存活但單請求耗時飆升。排查順序錯誤會浪費數小時。

                自檢口訣：先判「本輪上下文有多肥」，再判「長期記憶是否可檢索」，最後才動模型與通道。
            

3. 對照表：症狀 vs 記憶面 vs 資源面 vs 網關面

打印下表可縮短值班扯皮時間；與可觀測性文中的探針表並列使用。

外顯症狀	優先懷疑面	快速取證	常見非根因
輪次越多越慢，重啟會話明顯好轉	會話上下文膨脹	對比新會話首條與第十條的耗時；看是否大量工具 JSON 未摺疊	單純「提供商慢」
費用升、輸出仍短	隱性長上下文 / 重複注入	按請求對齊日誌中的模型調用與附件塊；檢查是否重複附全文	模型漲價誤判
「上週規則」頻繁被違反	MEMORY 結構失效 / 未摘要	抽查 MEMORY 行數與章節標題是否仍匹配檢索習慣	模型能力問題
進程間歇消失、容器重啟	資源面 OOM / 磁盤	`dmesg`、容器事件、`df -h`；對照 Docker 文	上下文策略
通道偶發無回、探針失敗	網關與插件面	`gateway status`、channels probe；走可觀測性階梯	MEMORY 清理

分層記憶基線怎麼定？

至少兩層：長期事實（少變、需審計）與會話偏好（多變、可丟）。長期層用穩定標題，禁單行巨段；會話層不自動晉升除非「合併評審」。長期層周度合併，會話層按迭代或容量閾值裁剪。

4. 落地步驟：五步固定周節奏與日誌對齊

在 Mac 雲 launchd 或 cron 上掛定時任務前，先人工跑通一遍：

凍結基線：記錄本周 MEMORY.md 行數、最近修改時間、以及網關配置中與上下文相關的開關（若存在長上下文或摘要選項）。寫入工單或 Git issue。
周度合併：用固定模板把「本週新增事實」摺疊進章節，刪除重複與已推翻結論；禁止無標題塊堆積。
審計提示：對代理下發短 prompt，要求列出「當前仍生效的三條硬規則」並與 MEMORY 對照；不一致則標記漂移。
與 Gateway 日誌對齊：在同一時間窗拉取 JSONL（順序見可觀測性文），確認無併發的 rate_limit 或 spawn 異常掩蓋延遲；若日誌乾淨而仍慢，回到上下文肥瘦判斷。
備份與回滾：合併前複製 MEMORY.md 與關鍵 workspace 配置到帶日期的歸檔目錄；回滾只需還原文件並重啟網關加載週期。

可用最小 shell 記錄基線（路徑按部署調整）：

#!/usr/bin/env bash
set -euo pipefail
test -f MEMORY.md && wc -l MEMORY.md | awk '{print "memory_lines",$1}'
date -r MEMORY.md "+%Y-%m-%d %H:%M" 2>/dev/null || stat -f "%Sm" MEMORY.md
openclaw status 2>/dev/null | head -n 20 || true

5. 可引用技術信息：閾值與字段

下列條目可在評審或事故單中直接引用（按組織再調參）：

行數預警：長期記憶文件若無目錄結構超過約 800～1200 行，人工檢索效率通常斷崖下降，應考慮強制分章或外置知識庫。
周合併時長預算：為 MEMORY 治理預留固定 30～45 分鐘值班窗口，比「堆到季度大掃除」便宜。
對照指標：同模型同通道下，新會話首條 p95 與第十輪 p95 若相差超過約 2～3 倍，優先查工具輸出是否在對話中重複全量返回。
磁盤：JSONL 與記憶備份與日誌同盤時，Mac 雲節點仍需保持與構建類負載類似的≥10～15GB可用水位，避免寫日誌時抖動拖累會話落盤。
與 OOM 分界：容器內 Exit 137 或宿主頁故障優先內存 cgroup；單純上下文問題極少以 137 結束。
鏈路位置：治理會話上下文不替代 SSH 隧道、Token 旋轉與通道探針；順序應是資源→網關→記憶，避免倒序。

6. 從治理到穩定底座：為何 Mac 雲更適合 7×24 記憶面

在共享 CPU 激烈、磁盤 IO 方差大的超賣 VPS 上，即使你把 MEMORY 文件寫得再短，仍可能遇到偶發讀盤慢導致「像上下文爆炸」的假象；在不可控的 Windows 或遠程桌面會話裡，常駐代理還面臨會話掛起與圖形棧干擾，排障與可重複歸檔都更痛苦。純容器方案雖能隔離依賴，卻常疊加捲權限、uid 與 DNS 一層抽象，把「記憶文件是否按預期掛載」變成隱性變量。相較之下，專用 Mac 雲主機更接近「一臺你擁有 SSH 與路徑紀律的服務器」：日誌、MEMORY 歸檔與 launchd 週期任務落在清晰路徑上，與 Apple 生態工具鏈共址，也便於與站內多篇 OpenClaw Mac 雲部署、可觀測性與 Docker 排障文交叉驗證。若你需要可預期的 7×24 記憶治理而不是每週救火，優先把代理放在可控算力與磁盤策略明確的 Mac 節點上，再談模型與 prompt 微調。