我手里有一台 2017 款的 MacBook Pro13 寸8GB 内存开机风扇声音大得能当白噪音用。放在桌上吃灰快一年最近被我翻出来装上了 OpenClaw。跑起来之后我才发现一个反直觉的事实这类 AI 智能体服务压根不需要你手里性能最强的那台机器反而是一台闲置的、稳定的、能长期开机的旧 Mac才是性价比最高的宿主。这篇文章就把我从一块“电子砖头”到 OpenClaw 正常跑通的全过程完整记录下来包括环境判断、安装路径、模型接入、频道打通和几个必踩的坑照着做基本能复现。OpenClaw 本质上是一个常驻运行的 AI 智能体框架它把大模型能力封装成可以主动干活的“数字助理”你通过微信、Telegram、飞书这类聊天渠道给它下指令它可以操作本机文件、执行命令、读写工作区、调用浏览器然后按你的要求把结果返回过来。和那些云端 Agent 服务不同OpenClaw 跑在你自己掌握的硬件上数据和会话完全由你说了算。这也是我决定用闲置 Mac 来跑它的核心理由不占主力机的资源又能获得一台随时在线的“个人 AI 工作站”。1. 闲置 Mac 到底能不能跑先泼盆冷水再给结论1.1 OpenClaw 是什么一句话解释再拆开讲先别急着打开终端。你要先搞清楚 OpenClaw 和普通本地大模型程序的区别。很多人第一次听说 OpenClaw会以为它像 Ollama 那样是个“装完就能聊”的模型运行器。实际上 OpenClaw 更准确的定义是以聊天软件为入口的个人 Agent 运行框架。它本身不产出回答能力真正的“脑子”来自 AI 大模型。OpenClaw 做的事情是把 Telegram、微信、飞书、Discord 这些渠道收到的用户消息统一转成标准指令交给配置好的大模型处理模型得出结果后再通过它内置的工具集去执行——可能是读取本地某个文档可能是跑一段 Python 脚本也可能是调用浏览器查资料最终把结果发回给你。这就像你雇佣了一个“远程实习生”实习生没有专业知识但它有很强的执行力而你负责给它接通电话线频道、配给电脑文件系统、找好专家顾问大模型。OpenClaw 这个框架就是把电话线、电脑、专家顾问之间的协作流程全部串起来的那个“行政助理”。1.2 为什么说“闲置 Mac”是最合适的宿主我见过不少人折腾 OpenClaw用的是高性能 Windows 游戏本或者云服务器。能跑但都不是最优解。闲置 Mac 有四个天然优势功耗低、静音、适合 24 小时开机。一台 2017 款 MacBook Pro 待机功耗大约在 5W 到 15W即使跑着模型服务满载一般也就 40W 上下远比一台游戏本动辄 100W 以上的功耗低得多。macOS 自带类 Unix 环境。OpenClaw 这类 Agent 框架天生偏爱 Unix 系工具链macOS 无需折腾 WSL 就能直接跑原生二进制、执行 shell 脚本、访问文件系统减少一层兼容转换开销。和 iCloud、Apple 生态的联动能力。如果你后续想让 Agent 帮你整理备忘录、处理 Pages/Number 文件macOS 原生环境比云服务器方便太多。零新增成本。闲置机器本来就在吃灰电费和网络都是现成的不需要额外买云主机。这里要泼一盆冷水不是所有闲置 Mac 都适合当这个宿主。我自己列过一个最低门槛硬件条件建议标准备注系统版本macOS 10.15 及以上太老的系统装不了新版本依赖内存8GB 起步16GB 更舒服8GB 建议用 API 模型本地模型会紧张硬盘剩余空间至少 20GB系统镜像依赖模型缓存处理器Intel 或 Apple Silicon 均可Intel 跑起来发热明显但能接受上网条件稳定且有外网访问能力需要拉取依赖和处理通道回调我的建议是2015 年以后、内存不低于 8GB 的机器可以放心折腾如果是 2012 年以前的老古董干脆放弃省下的时间能多陪陪家人。1.3 部署前的灵魂拷问你打算拿它干嘛这一步很多人忽略。我建议你在安装前明确“OpenClaw 主要服务哪个场景”因为后面频道选型完全取决于用途个人知识库助理让它读取指定文件夹里的资料通过 Telegram/微信随时提问。这种场景对频道稳定性要求高配置简单。群聊机器人自动回复群消息、定时发布提醒。这种场景建议走 Telegram/Discord群管理能力成熟。自动化工作流执行器每天定时备份文件、爬取信息生成日报。这种场景不依赖聊天启动后挂着就行。多设备消息中转站把某个频道的消息转发到另一个频道。这种场景对多频道并发稳定性要求非常高需要仔细设计频道配置。想清楚用途再动手能帮你避免后面反复改配置的麻烦。2. 动手第一步给 Mac 补齐环境依赖2.1 安装 Homebrew 前先处理两个常见报错Mac 上的包管理工具主流选择就是 Homebrew。旧 Mac 装 Homebrew 时最容易遇到两个报错一是系统自带 Ruby 版本太老导致安装脚本走不下去二是网络波动导致curl下载中断。如果你的机器系统较老建议先确认系统自带命令行工具是否完整xcode-select --install这条命令会安装 Command Line Tools没有它Homebrew 装完也没法编译软件。装完后重新运行 Homebrew 官方安装命令/bin/bash -c $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)如果中途网络中断不要慌重跑一遍即可它是断点续装的。装完后验证一下brew --version看到版本号输出就说明包管理工具已经可用。后续安装git、docker、ollama都可以用brew install 名称完成。2.2 Docker 与原生二进制别纠结按内存和需求选OpenClaw 的部署有两种主流路径Docker 容器和源码编译后的原生二进制。这里没有绝对的对错只看你机器的资源情况Docker 路径一条命令跑起来隔离性好卸载干净升级简单。但 Docker 容器在 Mac 上运行本身会吃掉 1~2GB 内存对 8GB 老机器来说有点肉疼。源码编译路径生成原生二进制内存占用更小启动更快适合低配机器长挂。但需要安装 Rust 工具链编译过程中发热大、耗时长。我的实测建议是内存 16GB 及以上的机器直接上 Docker8GB 的机器建议走源码编译。下面两个小节分别给步骤。2.3 数据目录与密钥文件的约定越早规划越省心在装 OpenClaw 之前先规划好数据目录。我习惯用一个固定目录来承载所有 Agent 相关数据方便备份和排查mkdir -p ~/openclaw-data/{config,logs,workspace,sessions}config存放 OpenClaw 的配置文件。logs运行日志排查问题时的第一现场。workspaceAgent 的工作目录相当于给它的“办公桌”。sessions会话锁文件和历史对话记录。密钥管理这点我必须重点强调不要把 API 密钥直接写进配置文件再提交到 GitHub 仓库。我见过不少新手为了图省事把ANTHROPIC_API_KEY明文写在配置文件里结果推到公开仓库被人盗刷。正确做法是用环境变量或.env文件加载密钥配置文件只引用变量名。2.4 时间同步旧 Mac 最容易忽略的隐藏问题旧 Mac 如果长时间关机或电池耗尽系统时间可能不准。时间不同步会导致 HTTPS 证书校验失败、OAuth 登录异常、消息回调验签失败等一系列诡异问题而且报错信息往往跟时间毫无关系。部署前先确认时间同步状态sudo systemsetup -getusingnetworktime如果输出不是On就打开自动同步sudo systemsetup -setusingnetworktime On这一步做完再继续否则后面排查问题时会浪费大量时间。3. 两种安装路径Docker 一键起服务 vs 源码编译原生二进制3.1 路径 ADocker 镜像部署完整流程确认 Docker 可用后拉取镜像docker pull openclaw/openclaw:latest启动容器前先想好端口映射和目录挂载。我建议只绑定本地回环地址不要直接暴露到局域网因为 Agent 通常是通过出站连接访问消息服务器不需要外部主动连入docker run -d --name openclaw \ --restart unless-stopped \ -e ANTHROPIC_API_KEY你的密钥 \ -v ~/openclaw-data/config:/app/config \ -v ~/openclaw-data/logs:/app/logs \ -v ~/openclaw-data/workspace:/app/workspace \ -p 127.0.0.1:8527:8527 \ openclaw/openclaw:latest启动后查看日志确认运行状态docker logs -f openclaw如果看到类似started或listening的字样说明容器层面已经没问题了。Docker 路径最大的优势是以后升级只需要docker pull openclaw/openclaw:latest docker restart openclaw非常省心。3.2 路径 B源码构建原生二进制8GB 老机器想省内存就选这条路。先安装 Rust 工具链curl --proto https --tlsv1.2 -sSf https://sh.rustup.rs | sh source $HOME/.cargo/env然后克隆仓库并编译git clone https://github.com/openclaw/openclaw.git cd openclaw cargo build --release这一步编译耗时取决于机器性能老 Mac 可能要十几分钟期间风扇会转得比较厉害属正常现象。编译完成后生成了target/release/openclaw这个可执行文件。把它的路径加入PATH方便全局调用ln -s $(pwd)/target/release/openclaw /usr/local/bin/openclaw openclaw --version源码路径的好处是你能拿到最新的提交、能自己改代码二次开发而且运行时内存占用比 Docker 路径少大约 1.5GB老机器明显更跟手。3.3 初始化工作区装完的第一件事无论哪种路径装完之后都要做一步初始化openclaw init这条命令会生成基础配置文件并创建默认工作区。初始化完成后可以先跑一次环境自检openclaw doctor它会检查系统依赖、密钥环境变量、网络连通性、端口占用等关键项。如果某项标红按提示补齐即可。这一步能省掉后面大量的玄学排查。3.4 让闲置 Mac 真正“无人值守”开机自启配置闲置 Mac 大概率不会插着显示器重启之后要能自己把服务拉起来才算合格。macOS 上最可靠的自启方案是使用 launchd而不是把命令塞进“登录项”。可以创建一个 plist 文件nano ~/Library/LaunchAgents/com.openclaw.serve.plist内容大致如下Docker 路径和原生路径的 ProgramArguments 不同?xml version1.0 encodingUTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd plist version1.0 dict keyLabel/key stringcom.openclaw.serve/string keyProgramArguments/key array string/usr/local/bin/openclaw/string stringserve/string /array keyRunAtLoad/key true/ keyKeepAlive/key true/ keyStandardOutPath/key string/Users/你的用户名/openclaw-data/logs/serve.out.log/string keyStandardErrorPath/key string/Users/你的用户名/openclaw-data/logs/serve.err.log/string /dict /plist然后加载并启动launchctl load ~/Library/LaunchAgents/com.openclaw.serve.plist launchctl start com.openclaw.serve配置了KeepAlive后即使进程崩溃launchd 也会自动拉起基本可以做到“通电即服务”。4. 给 Agent 接上“大脑”大模型配置与模型选型4.1 云端 API 接入Anthropic 和 OpenAI 的配置差异OpenClaw 默认对 Anthropic 系模型支持最完善毕竟它最初就是围绕 Claude 的能力设计的。要接入 Claude只需设置环境变量export ANTHROPIC_API_KEYsk-ant-你的密钥如果要用 OpenAI 的 GPT 系列通常需要设置export OPENAI_API_KEYsk-你的密钥在配置文件里指定 provider 为openai并填写对应模型名即可。这里有个实用小建议不要把多个 provider 的配置堆在一个环境变量里而是把不同的模型配置写成多个 profile方便随时切换。比如{ profile: work, agent: { model: { provider: anthropic, modelName: claude-sonnet-4-5, temperature: 0.4 } } }切换模型时改 profile 名称就行比反复改环境变量优雅得多。4.2 本地模型方案Ollama 部署 Qwen 开源模型不想把对话记录发给云端 API、或者想省 API 费用的可以走本地模型方案。在 Mac 上最省事的本地模型运行环境就是 Ollamabrew install ollama ollama serve新开一个终端窗口拉取模型比如阿里开源的 Qwen 系列也就是中文社区常说的“千问”ollama pull qwen2.5:14b如果你内存只有 8GB别强求 14b 以上可以选更小更快的版本ollama pull qwen2.5:7b拉取完成后确认 Ollama 服务正常运行curl http://127.0.0.1:11434/api/tags把 OpenClaw 的模型配置指向本地 Ollama 服务即可{ agent: { model: { provider: ollama, baseUrl: http://127.0.0.1:11434, modelName: qwen2.5:14b } } }本地模型的响应速度明显比云端 API 慢尤其 8GB 内存的 Intel Mac单次推理可能要十几秒。但隐私性极好所有对话不出本机适合处理私人文档。4.3 本地 DeepSeek 模型也可以当备选除了 QwenDeepSeek 系列的开源模型在中文场景下表现也很强而且和 Ollama 的配合非常顺滑ollama pull deepseek-r1:8b我个人实测下来团队知识库问答、代码片段理解这类任务DeepSeek 8b 的表现比预期好但涉及复杂工具调用、需要严格按照 JSON 格式输出的场景Claude 和 GPT 的稳定性明显更高。所以我的建议是日常对话和本地知识库用开源模型核心工作流切换到云端 API两者不冲突。4.4 Token 成本控制与上下文长度调优用云端 API 时成本控制需要认真对待。特别是“消息回调 Agent 思考 工具调用”的组合单次任务可能产生大量 Token。我一般会做这几件事在配置里限制上下文窗口长度不让 Agent 无限记住历史消息。对高频任务设置max_turns防止 Agent 在工具调用里死循环。给不同 channel 配置不同的模型档位比如 Telegram 私人号用强模型群里自动回复用便宜的轻量模型。这些参数在配置文件里基本都有对应项不同版本叫法略有差异核心思路是“按场景分级不搞一刀切”。5. Channel 选择与渠道打通Telegram、微信、飞书、Discord 全流程5.1 先想清楚使用场景再选 channel“openclaw agent 怎么选择 channel”这个问题被问得非常多。我的建议是先列需求再挑渠道。渠道稳定性上手难度适合场景缺点Telegram高低个人助理、群聊机器人、通知推送国内使用门槛Discord高低社群管理、多频道并行偏技术圈微信中高家人朋友日常使用登录限制多、封号风险飞书中中团队协作、企业内部工具消息长度限制WhatsApp中中海外用户号码风控电子邮件渠道高低异步任务处理、通知归档实时性差如果你是第一次部署强烈建议先用 Telegram 或 Discord 把链路跑通别一开始就挑战微信。微信不是不能接但它是所有渠道里约束最多、最容易出问题的。5.2 Telegram 配置最稳的开局渠道Telegram 接入依赖 BotFather。在 Telegram 里搜索BotFather发送/newbot按提示设置机器人名字和用户名然后会收到一串bot token。把它填到 OpenClaw 配置里{ channels: { telegram: { botToken: 123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11, allowedUserIds: [你的用户ID] } } }配置完成后重启服务给机器人发一条/start看到欢迎消息就代表链路已经通了。allowedUserIds一定要配否则任何知道你 bot 用户名的人都能指挥你的 Agent想都不敢想。5.3 微信接入能发消息但收不到回复的根源分析微信渠道是热门搜索词里出现频率最高的也是问题最多的。先说结论OpenClaw 接微信本质上是通过网页微信协议进行的非官方接入受制于微信官方的风控策略。它和 Telegram 的 webhook 机制完全不同。常见的现象是“openclaw 能发消息微信但微信发消息没回复”。这个问题的排查链路我放到下一节详细讲这里先给配置要点微信接入需要前置完成扫码登录登录状态会存在 sessions 目录里。微信渠道通常是轮询机制不是实时回调所以消息响应有明显延迟。微信对非官方客户端游走政策的容忍度低如果账号是新注册的很容易被限制登录建议用不常用的账号测试。配置好之后从 Agent 主动向微信发一条消息验证单向链路如果单向通了但反向没回复问题九成出在会话轮询或消息事件监听上。5.4 飞书渠道长文截断的解决思路“openclaw 在飞书输出容易被截断”这个问题也很有代表性。飞书开放平台对消息长度有限制Agent 一次回复超长时就会被系统掐断。解决办法有两个方向一是调小 Agent 输出上限强制它把回答控制在飞书允许的长度内{ channels: { feishu: { maxMessageLength: 1024 } } }二是保持长输出但同时启用“分段发送”。OpenClaw 本身对长回复有自动拆分逻辑你只需要确认配置里开启了分段并且飞书应用有足够的消息发送频率配额。两种方案我更推荐第一种让 Agent 学会“先说结论再列细节”不仅飞书不截断人读着也舒服。5.5 多频道同时在线时的消息路由注意事项如果你同时接了 Telegram、微信、飞书要注意会话隔离同一个 Agent 会在不同渠道上建立独立的会话上下文。也就是说你在微信里跟它聊的事它不会默认带到 Telegram 里。这是设计上的刻意选择避免跨渠道上下文串味。但我测试时发现一个反直觉的点如果多个频道同时向同一个工作区发起写操作有可能触发会话锁冲突——也就是下面要讲的 session file locked 问题。避免的办法是给每个渠道分配独立的 workspace 子目录比如~/openclaw-data/workspace/telegram/ ~/openclaw-data/workspace/wechat/ ~/openclaw-data/workspace/feishu/虽然 OpenClaw 默认支持多会话并行但物理隔离更安心尤其 8GB 老机器并发处理多会话本身就容易吃力。6. 跑起来之后一定会遇到的问题完整排查链路6.1 “session file locked (timeout 60000ms)”到底怎么发生的这个报错几乎每个跑过 OpenClaw 的都会遇到一次。完整报错形如agent failed before reply: session file locked (timeout 60000ms) openclaw根因非常直白有两个进程同时想操作同一个会话文件而文件锁被其中一方持有另一方等不到锁释放最终超时。我遇到的一次是openclaw serve已经跑着我又手动执行了一遍openclaw agent --session xxx两个进程同时对同一个会话发起读写锁就撞上了。另外一次是进程崩溃后锁文件没有正常清理遗留在了 sessions 目录里。排查步骤给你完整链路# 1. 确认当前有哪些 openclaw 进程 ps aux | grep openclaw | grep -v grep # 2. 找到疑似僵死的进程 kill -9 PID # 3. 检查 sessions 目录下的锁文件 ls -la ~/openclaw-data/sessions/ # 4. 清理残留锁文件谨慎确认没有其他活跃进程再删 rm -f ~/openclaw-data/sessions/*.lock # 5. 重启服务 openclaw serve核心原则是先杀进程再清锁最后重启。顺序不能反否则清掉的锁可能又被活跃进程重新写回。6.2 微信能发消息但收不到回复一条链路逐层找到底这个问题我在 5.3 提过现在展开讲完整排查思路。先画一条消息从发出到返回的链路你发微信消息 → 微信渠道轮询捕获消息 → OpenClaw 会话调度 → 大模型推理 → 工具执行 → 生成回复 → 微信渠道发送链路很长每一环都可能导致“消息发出去没回复”。按我的经验排查顺序应该是第一步确认微信登录是否有效。网页微信登录过期是最高频的原因。到日志里看有没有类似登录失效、需要重新扫码的警告。如果登录过期重新扫码并确认 sessions 目录里有最新 token 文件。第二步确认消息是否真的被捕获。看日志里有没有收到微信消息的记录。如果没有说明是渠道轮询出了问题而不是 Model 或 Session 的问题。第三步确认大模型是否成功返回。如果日志里显示消息收到了但出现超时、API 报错那就是模型配置的问题。此时可以把日志切换到 debug 级别RUST_LOGdebug openclaw serve第四步确认发送是否被风控。如果日志显示回复已经生成但微信没收到大概率是账号被第三方协议风控了。换号、降温、降低发送频率是唯一办法。一般人卡在第三步但有相当一部分人卡在第四步。微信渠道的脆弱性我建议你提前接受它作为“个人使用通道”体验还好做高频群聊机器人风险极高。6.3 日志怎么看哪些报错可以直接忽略OpenClaw 的日志目录就是之前建的~/openclaw-data/logs/。遇到问题先看日志别急着重启。给你几个识别经验看到ERROR不代表服务崩溃要先看上下文。有些 ERROR 只是某一条消息处理失败Agent 会继续服务后续请求。看到WARN且关键词是rate limit、retry in说明触发了频率限制等一下就好。看到panic或exit code 1才是真正需要处理的致命错误。日志里反复出现时间戳跳动但没实质内容优先检查系统时间同步。我在处理这类 Agent 服务时有一条铁律日志优先级大于报错信息本身。避免揪着一条错误码钻牛角尖要看它周围发生了什么。6.4 快速回血一套标准的清理重启流程日常维护中最常用的回血操作应该固化成肌肉记忆# 停止服务二选一取决于你用的 launchd 还是直接前台跑 launchctl stop com.openclaw.serve # 或 pkill openclaw # 清理会话锁 find ~/openclaw-data/sessions -name *.lock -delete # 清理超大日志 tail -c 5M ~/openclaw-data/logs/serve.out.log /tmp/out.log mv /tmp/out.log ~/openclaw-data/logs/serve.out.log # 启动服务 launchctl start com.openclaw.serve这套流程我每个星期基本要跑一次。尤其是在微信渠道长时间运行后会话锁和日志膨胀是不可避免的定期维护比等出 bug 再救要舒服得多。7. OpenClaw、WorkBuddy 与 Clawdbot到底怎么选7.1 血缘关系与各自定位网上经常看到“openclaw 和 workbuddy 哪个好”的争论。我的理解是这些项目共享相似的技术理念——都试图用聊天渠道包装一个 Agent 框架让大模型能够通过对话指令操作本地环境。但在实现策略上走的路差别很大。OpenClaw 的路线偏“开源社区共建”代码开放、配置自由、渠道扩展依靠社区贡献。它的特点是灵活、可定制、透明适合愿意折腾、对数据主权有要求的用户。WorkBuddy 的路线偏“商业产品化”上手更傻瓜化功能界面更友好但很多能力封闭在商业服务里免费版功能受限重度使用通常需要付费。7.2 替代对比我没有贬低商业产品的意思但从技术人员的角度看关键差异可以用这张表说清楚维度OpenClawWorkBuddy部署方式自托管完全掌控偏托管开箱即用源码开放开放可二次开发闭源为主频道数量多且持续增加核心渠道够用配置灵活性高但学习曲线陡低但上手快数据隐私数据完全自持依赖服务商政策成本硬件模型费用订阅服务费模型费用适合人群技术型玩家、隐私敏感用户效率工具型用户、不想折腾的人群7.3 我的最终建议如果你手里已经有一台闲置 Mac而且你愿意花一个周末时间折腾OpenClaw 几乎是不二之选不花钱、可控性强、跑通之后的成就感也是商业产品给不了的。如果你对技术的耐心有限只想要一个“打开就能用的电子助理”那 WorkBuddy 这类方案更贴合需求。放到我自己的场景里我会继续用 OpenClaw。原因很简单我可以随时看它到底在执行什么可以改它可以自己扩展一个渠道可以把所有数据锁在本机硬盘里。这种掌控感对我来说比开箱即用的便利性重要得多。最后再分享一个实在的小技巧刚开始不要追求配置所有的渠道先用 Telegram 跑通一个简单场景比如“让它每天早上定时读一遍某个文件夹里的日报文件并总结关键词”。把所有环节简化到最少你才能快速分清问题是出在渠道、模型还是框架本身。链路越短踩坑越少。等你把基础跑顺了再逐步加微信、加飞书、加本地模型那时候你对 OpenClaw 的理解已经足以让你自己解决大部分问题了。
