MacOS 虚拟机配置与安全隔离 #
我的安全原则很简单：
- 整个 OpenClaw 运行在完全隔离的环境中。
- 绝对不与 OpenClaw 共享主账号。
因此我大体上是这样配的：
- 使用 Lume 虚拟机，不挂载任何 host 目录。
- OpenClaw 操作的所有密钥都重新生成；GitHub 等账号也单独注册，不跟日常账号混用。
- 在
SOUL.md和MEMORY.md里明确禁止它尝试读取任何 key，避免敏感信息进入 context。
顺着 官方文档 配，基本可以顺利启动。真正的坑主要在 headless 这一节。
OpenClaw Gateway 默认依赖 launchd。问题在于，macOS 的用户级 Launch Agent（类似 Linux 的 systemd --user）只有在 GUI 登录 后才会加载，而 macOS 并不把 SSH 连接算作一次 GUI 登录。所以如果让 Lume VM headless 启动，然后只通过 SSH 连进去，Launch Agent 不会被加载，OpenClaw 也就起不来。
类比到 Linux，可以理解成某些
systemd --user服务被标记成只在图形会话里跑；不开 x11/wayland，它们就不会自动启动。
解决方法很简单：在设置里打开「自动登录」。
网络方面，建议把 host 上的代理改成 tun 模式，这样对 VM 来说就是透明代理，不需要额外配置。这里有一个容易踩的坑：要把 Fake-IP 改成 Redir-Host。因为 Fake-IP 模式会让 DNS resolve 出虚拟地址，然后被 OpenClaw 使用的网络中间件拦截，最终表现成 web_fetch 等工具不能正常工作。
Telegram 配置与 Threaded Mode #
Telegram bot 的申请流程没什么特别的，关键是要开启一个比较新的特性：threaded mode。
它的核心作用是让 bot 优雅地管理多个独立上下文，而不依赖回复链。开启之后，实际体验更接近常规的 GPT 聊天界面，每个话题有独立的对话线程。
这个功能在 BotFather 里藏得比较深。
如果以前用过 Telegram bot，习惯多半是通过传统对话方式管理 BotFather：通过按钮交互，看它实时编辑返回的消息。问题在于，这条路径里根本找不到 threaded mode 的入口。
实际上，这是通过 Telegram 新推出的网页管理入口来设置的：
点击这个入口打开 Telegram 的小程序界面，然后在网页中设置 bot。
如果一直只把 BotFather 当聊天机器人来用，这个入口很容易错过。
视频总结工作流 #
我目前用的视频总结流程如下：
yt_dlp下载视频。虽然名字看起来像专门下载 YouTube 的，但实际上支持上千种数据源，包括 B 站。ffmpeg提取音频。- 本地模型
Qwen3-ASR-1.7B-8bit做语音转文字。 - 再交给 LLM 生成总结。
- 最后清理缓存。
STT 模型目前直接跑在 host 上，通过 HTTP 和 VM 里的 OpenClaw 通信。如果条件允许，当然放到虚拟机里会更符合隔离原则，但暂时懒得折腾推理环境的配置。
这套流程目前用着还行，不过里面写死了一些机器相关的路径和配置，暂时还没整理成可直接复用的版本。