先查 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 微调。