技术负责人三连问：1.6G 内存、MCP 分层与多端状态一致
「Hermes + Memory + Nginx 同时跑在 1.6G 内存上，OOM 怎么规避？」「MCP 到底集成在哪一层？」「手机本地模式和远程模式来回切，上下文怎么不丢？」——把 EraHerm 生态当作品展示时最常被追问的三个问题，架构设计与落地细节一次讲透。
技术负责人三连问：1.6G 内存、MCP 分层与多端状态一致
「Hermes + Memory + Nginx 同时跑在 1.6G 内存上，OOM 怎么规避？」「MCP 到底集成在哪一层？」「手机本地模式和远程模式来回切，上下文怎么不丢？」
这是把 EraHerm 个人 AI Agent 生态当作品展示时，技术负责人最常追问的三个问题。这篇把架构设计和落地细节一次讲透。
一、1.6G 内存下的 OOM 生存法则
结论先行：Swap 兜底 + 轻量化选型 + 监控与快速处置 + 构建与运行分离，四层防护。
第一层：Swap 兜底swapfile 由 dd 创建 + fstab 持久化，物理内存不足时内核先把冷页换出，而不是直接 OOM kill。实测 1 核 1.6G 机器上 Hermes（gateway + api_server）+ 身份层代理 + Nginx + 记忆内核 SQLite 常驻，峰值内存压力下系统存活。
第二层：轻量化选型 + systemd 服务管理内存大头先在设计阶段砍掉：embedding 选 fastembed（ONNX 运行时，~50MB，免装 PyTorch 全家桶），而不是 sentence-transformers（~1GB）；Hermes 常驻约 300MB。所有常驻服务用 systemd 单元文件管理，开机自启、崩溃自动重启。进程级内存硬上限（cgroups/systemd MemoryLimit）是后续加固方向——当前靠 swap 兜底 + 轻量化 + 监控处置，生产已稳定运行未发生 OOM。
第三层：监控与快速处置内存水位与进程 RSS 定期巡检，异常时定位并清理。实战案例：一次 Gradle daemon 悄悄吃掉 871MB，把可用内存压到 127M，监控定位后清理，可用内存回到 996M、swap 从 1.2G 降回 381M。
第四层：构建与运行分离APK 构建（Gradle）固定走 OVH 4G 主力机（Java 21 + 2G swap），1.6G 阿里云生产机只跑服务、绝不跑构建——从源头杜绝内存炸弹。
二、MCP 集成在哪一层：数据流一句话点透
手机端不直接碰记忆，远端 Hermes 才是 MCP Host，记忆内核是 MCP Server——记忆能力对上层 Agent 完全透明。
HxSync(手机) --OpenAI兼容API--> 身份层(一人一Key) --> Hermes Agent (MCP Host)
|
remember / recall / impact
v
EraHerm-Memory 记忆内核 (MCP Server)- 云端：Hermes Agent 作为 MCP Host，通过 MCP 工具协议原生调用记忆内核的 remember、recall、impact 工具，零 curl、零外部 API。
- 端侧：HxSync 是纯客户端，经身份层（一人一 Key + 会话 ID 注入）访问云端 Agent，记忆读写全部收敛在 Agent 层。
- 收益：记忆内核和 Agent 框架解耦——以后换任何支持 MCP 的框架，记忆能力直接复用。
三、本地 / 远程切换的"状态飘移"：如何不丢上下文
核心思路：以记忆内核为单一事实源（Single Source of Truth），会话状态不绑死在某一端。
已落地：
- 身份层强制会话 ID：X-Hermes-Session-Id 注入 api-laoda / api-meinv，多用户切换绝不串号。
- 长对话自动开新会话：本地模式累计 ≥20 条消息自动归档并开新会话，根治上下文膨胀导致的流式断连——这是"丢上下文"的另一种形态（不是丢，是撑爆）。
演进方向（架构设计）：
- 摘要压缩回传：端侧切换时，把云端会话摘要压缩写入记忆内核 L2 长期记忆；本地端冷启动通过记忆快照恢复话题，实现"换端不换脑"。
- 会话状态外置：对话进度、待办、用户偏好统一沉淀到记忆内核，本地 Gemma 与远程 Agent 共享同一份"记忆"，状态漂移从设计上消除。
小结
1.6G 不是限制，是约束下的设计题。Swap 兜底、轻量化选型、监控处置、构建运行分离解决生存；MCP 分层让记忆能力跨框架复用；单一事实源让多端切换不丢上下文。用最少的资源，做最完整的生态。