租用 Mac mini 上的 OpenClaw MCP 子进程残留：退出卫生与 launchd 回收实战（2026-05-19）

如果你在 ProxyMac 香港、日本、韩国、新加坡或美国 节点租用的 Mac mini M4 上把 OpenClaw 与 Model Context Protocol（MCP）stdio 工具跑在一起，却遇到空闲时 RSS 仍持续上涨、node 进程数量异常、或网关升级后工具调用“偶发卡死”，本文给出可复现的排障路径：先区分孤儿进程堆积与JSON 行缓冲卡死，再用五列表决策矩阵对齐信号与动作，最后执行九步 launchd 友好清理。文中与 并行代理并发、stdio 行缓冲、网关重启恢复 互链，便于把单一页面嵌回你们的值班手册。

症状：在换页抖动之前就能看见的“进程漂移”

社区与上游议题里已有案例：某些 CLI/MCP 组合在父进程退出后仍长期占用内存，单个 Node 子进程可能稳定持有数十 MB 级别的常驻集。单租户物理机不像共享容器那样替你“遮丑”，因此问题会直接反映在 top、磁盘 I/O 与 launchd 的 CPU 配额上。

• 进程列表漂移：夜间无人 SSH，但 pgrep -lf mcp / pgrep -lf modelcontextprotocol 行数比冷启动后明显更多。
• 工具延迟阶梯化：首批调用成功，后续排队；根因常是某条管道读端未收到 EOF，因为仍有僵尸读者占着 stdin。
• 版本错位：本机 CLI 已升级，而旧网关仍在监督旧 semver 拉起的子树，信号语义与预期不一致。
• 误判“模型挂了”：供应商延迟正常，但本地 fork 压力飙升；务必先看本机再甩锅给 LLM。

根因：为什么 stdio MCP 容易留下“粘性子树”

stdio 方案避免随意暴露 TCP 端口，但继承了 POSIX 语义：只要写端未关闭，读端就永远等不到 EOF；npx 一类引导器还可能留下脱离中间 shell 的孙进程。OpenClaw 跑在 LaunchAgent 下时，环境比笔记本交互 shell 更“瘦”——HOME、PATH 与 Keychain 上下文若不一致，子进程可能在短循环重启里自我繁殖，看起来像攻击调度器，其实只是自动化脚本的边界条件。

再结合 ulimit 与内存上限：许多 macOS 工作负载上单进程软限制 2560 个文件描述符听起来宽裕，但当并发工具调用把“每调用 × 三根管道”的乘法做起来，中途触顶就会留下半开描述符，为 MCP 兄弟进程并存创造条件。

现场处置矩阵（信号 → 动作）

首要信号	第一反应（顺序敏感）	必须留存的数据	误判回滚	升级责任人
20 分钟内 RSS 无故上涨约 200 MB	先 ps -o pid,ppid,rss,command 快照，再谈重启	PPID 链 CSV + JSONL 时间戳	未标注父 PID 前勿批量 kickstart	平台 SRE
管理端口（如 18999）出现双监听	按 网关恢复 单一监听检查表执行	lsof -nP -iTCP:18999 -sTCP:LISTEN	若两枚 plist 互抢，bootout 错误标签	自动化负责人
429 风暴但本机 CPU 不高	先降并发，参考 并行代理指南	每 5 分钟桶的 429 计数	恢复旧的 maxConcurrentTasks	FinOps + 算法
RSS 平稳但工具卡死	优先查缓冲/PTY，而非 SIGKILL 日	采样级系统调用日志（策略允许时）	撤销无缓冲实验参数	客户端工程

九步清理手册（SSH 登录 ProxyMac mini）

1. 广播维护窗口：哪怕只回收 90 秒，也要避免 CI 静默踩雷。
2. 导出证据：网关日志尾部 500 行 + launchctl print gui/$UID 过滤 OpenClaw 相关 label。
3. 冻结新任务：暂停调度或 Webhook 入口，避免“边杀边生”。
4. 标注父进程：画清 PPID；在子进程分类完成前，不要对 launchd 托管的网关直接 kill -9。
5. TERM 波：对确认的 MCP 叶进程发 SIGTERM，等待 15 秒再计数。
6. KILL 只给已验证 argv 的顽固分子。
7. 回收网关：使用厂商文档支持的 launchctl kickstart -k 或 bootout/bootstrap 组合。
8. 冒烟：用只读工具连续调用 两次，观察 10 分钟内 RSS 是否回到基线。
9. 复盘工单：若每周复发，附上 PPID CSV 并链接本文，推动配置层修复。

launchd 视角：回收纪律与 ThrottleInterval

LaunchAgent 不是 systemd：ThrottleInterval、KeepAlive、SuccessfulExit 会共同决定 macOS 以多激进策略 respawn 网关。若只重启 Node 二进制却遗留旧 stdio 句柄挂在失效 PTY 上，launchd 仍会认为网关“健康”，工具侧却随机连到半死管道。任何手动 kill 后，都要用 launchctl print 对齐 plist，并确认 EffectiveUserID 与 ~/Library/LaunchAgents 属主一致。

若每次大版本需一次性点 TCC/钥匙串授权，可短期使用 VNC 完成 GUI 步骤，再回到 帮助中心 所述的无头 SSH 流程——把 GUI 审批与无人值守 launchd 周期混在同一台机器上，最容易把 MCP 服务器拉起来两份。

预防：并发、超时与爆炸半径

治理孤儿比事后杀进程便宜：

• 把并行工具调用压在拐点之前，队列心智模型见 并行 OpenClaw。
• 为每个 MCP server 配置硬超时（键名随发行版不同）：网络型工具可先以 120 秒 为上限，只读文件 stat 可尝试 15 秒 量级。
• 每个自动化身份单独工作目录，避免多代理争用 git 与包管理器锁。
• 实验性 MCP 与生产编排分机器——HK/JP/KR/SG/US 多区域让“加一台沙盒 mini”变成采购页勾选，而不是走资本化流程。

常见问题

为什么网关停了，MCP stdio 进程还在？ 网关异常退出、SIGTERM 未层层传递到孙进程，或 npx 拉起的中继 shell 已结束但 Node 孙进程仍存活，都会留下半连接 MCP。launchd 若按 KeepAlive 立刻拉起新网关，旧管道仍被占用时，就会出现工具随机卡住而模型延迟正常的假象。

生产环境可以直接 kill 掉疑似 MCP 孤儿吗？ 先 SIGTERM 并留存 ps/lsof 证据，确认命令行与 argv 属于 MCP 工具后再考虑 SIGKILL。共享自动化主机上务必核对打开文件，避免误杀同事会话。清理后按厂商 LaunchAgent 流程重启网关，并用 lsof 确认管理端口仅有一个监听进程。

这和 stdio 行缓冲卡死有何不同？ 行缓冲问题常表现为 JSON 片段迟迟不完整、CPU 并不飙升；孤儿堆积则常见 RSS 单调上升与多余 node 进程。前者优先查 PTY/无缓冲参数，后者要收紧并发、超时与网关回收纪律。

为什么把 MCP 副作用 containment 放在 ProxyMac Mac mini 上更划算

MCP 放大了操作系统面：每次工具调用都是一次 fork、一组 fd、一次信号传播机会。Apple Silicon M4 在单线程与能效上给 stdio 多进程留足余量；macOS 与桌面脚本栈一致；香港/日本/韩国/新加坡/美国 节点选择让你把自动化放在离 SaaS 与注册表更近的位置。ProxyMac 的租赁模型意味着你可以为高风险 MCP 集成单独开一台可牺牲的沙盒 mini，用同一张 定价 页面说服利益相关方，把机器回收当作软件卫生的一部分，而不是先买硬件再后悔。