1. 为什么要在 iPhone 和 macOS 上打通 openclaw 与 iMessageopenclaw 是一个可以跑在本地、通过对话驱动任务执行的 AI 代理框架它能读写文件、调用命令、串联多个工具。iMessage 则是苹果设备之间默认的加密消息通道iPhone、iPad、Mac 上都能收发。把这两者接起来等于给你的 AI 代理配了一个随身入口你在外面用 iPhone 发一条消息家里的 Mac 上 openclaw 收到后执行任务再把结果通过 iMessage 回给你。整个过程走的是苹果端到端加密通道不需要公网 IP也不需要把服务暴露到互联网上。这套方案适合几类人手里有一台常年开机的 MacMac mini 最合适想用手机远程指挥本地 AI 干活或者在做智能家居、自动化通知希望用 iMessage 当消息总线再或者单纯想研究 openclaw 的 channel 机制找一个真实可跑的接入案例。它不适合完全零基础、只想点几下就完事的用户因为中间涉及 macOS 辅助功能权限、私有 API 开关、局域网地址配置这些环节任何一步错了消息就发不出去。我实测下来整条链路的核心是三个组件macOS 上的 Messages.app 负责真正的收发BlueBubbles Server 负责把 Messages.app 的能力包装成 HTTP 接口openclaw 通过 BlueBubbles 的 REST API 和 Webhook 完成双向通信。iPhone 端不需要装任何东西它只是普通地发 iMessage剩下的都在 Mac 上完成。理解了这个分工后面配置时每一步在干什么就清楚了。需要提前说明的是这套方案依赖 macOS 的私有 API 调用属于高阶玩法苹果对这类第三方工具的兼容策略存在不确定性建议把它当作技术验证和个人自动化实验来对待不要用在关键业务链路上。下面从环境准备开始一步步把双端配置跑通。2. 前置准备openclaw 运行环境与 TaoToken 接入配置在动 iMessage 之前先把 openclaw 本身跑起来并且确认它能正常调用模型。openclaw 的模型调用需要 Base URL、API Key、Model ID 三件套这里我用 TaoToken 作为模型接入层它的接口兼容主流协议配置起来比较直接。先拿到 API Key。打开 https://taotoken.net/api-keys 登录后创建一个新的 Key复制保存。注意这个 Key 只在创建时完整显示一次丢了就得重建。接着确认你要用的模型 ID比如 claude-sonnet 系列或者 gpt 系列具体以控制台里列出的为准。Base URL 统一填 https://taotoken.net/api 不要带多余的路径。openclaw 的配置文件通常在项目根目录下的 config 目录里不同版本路径略有差异我用的是 settings.json 形式。下面是一段可复制的配置片段把 Key 和模型 ID 换成你自己的{ models: { default: { provider: openai-compatible, baseUrl: https://taotoken.net/api, apiKey: sk-你的TaoToken密钥, model: claude-sonnet-4-20250514, maxTokens: 4096, temperature: 0.7 } }, channels: { bluebubbles: { enabled: false, serverUrl: http://192.168.6.2:1234, password: your_actual_password_here, webhookPath: /webhook/bluebubbles } } }这里 channels 里的 bluebubbles 先设成 false等 BlueBubbles Server 装好、拿到真实地址和密码后再改成 true。serverUrl 里的 IP 是你 Mac 在局域网里的地址用ipconfig getifaddr en0可以查到端口 1234 是 BlueBubbles 的默认端口。password 是 BlueBubbles 面板里设置的服务器密码不是 Apple ID 密码别搞混。配置写完后用一条命令验证 openclaw 能不能正常调模型openclaw chat --message 回复两个字就绪如果返回「就绪」说明模型链路通了。如果报 401多半是 Key 填错或者复制时带了空格如果报 model not found去 https://taotoken.net/console 确认模型 ID 拼写。这一步必须先过否则后面 iMessage 通了但 AI 不回复你会分不清是通道问题还是模型问题。模型验证通过后再确认 openclaw 的 Web 对话界面能打开。默认监听在 127.0.0.1:8789浏览器访问http://127.0.0.1:8789/chat应该能看到对话窗口。这个界面后面用来给 openclaw 发配置指令比命令行方便。到这一步前置环境就算齐了接下来装 BlueBubbles。3. 可复制配置BlueBubbles Server 安装与私有 API 开启BlueBubbles Server 是整条链路里最关键的中间件它把 macOS Messages.app 的私有接口暴露成 HTTP 服务。去 GitHub Release 页面下载对应版本的 DMG我实测用的是 v1.9.9安装过程按官方指引走即可。安装完成后首次启动系统会弹出辅助功能权限请求这是 BlueBubbles 要控制 Messages.app 必须拿到的权限在「系统设置 → 隐私与安全性 → 辅助功能」里勾选它。权限给完之后进入 BlueBubbles 面板的 Proxy Services 配置。这里选 Custom URL 或 LAN URL填入你 Mac 的局域网地址加端口比如http://192.168.6.2:1234。填完点完成BlueBubbles 会自动拉起 Messages.app 和 Find My 两个进程。Find My 用于设备状态同步如果你不需要可以关掉不影响消息收发。接下来是私有 API 开关。进入 Settings → Private API勾选 Messages Private API。这个选项打开后BlueBubbles 才能完整地收发 iMessage包括读取消息内容和发送回复。不开的话只能做有限的通知转发AI 没法主动回消息。这里有个容易踩的坑Apple ID 隔离。如果你的 Mac 和 iPhone 用同一个 Apple IDiMessage 会话里分不清哪条是你发的、哪条是 AI 发的消息会混在一起。正确做法是给 Mac 单独用一个 Apple ID 登录 Messages然后在 macOS 通讯录里把你的 iPhone 号码或邮箱添加成联系人。这样 AI 收到的消息来源清晰回复也不会串台。BlueBubbles 面板里还要设置一个服务器密码这个密码就是前面 openclaw 配置里 bluebubbles.password 的值。设置完保存然后回到 openclaw 的 settings.json把 channels.bluebubbles.enabled 改成 trueserverUrl 和 password 填成实际值。改完重启 openclaw 服务。为了安全建议用 LuLu 防火墙限制 BlueBubbles 的网络出口。它只需要访问 127.0.0.1 和局域网段其他外连一律拒绝。安装命令brew install --cask lulu启动 LuLu 后当 BlueBubbles 尝试联网时只放行 127.0.0.1 和 192.168.0.0/16 的连接其余全部拒绝。这样即使 BlueBubbles 被注入恶意代码也没法把数据外传。配置完重启 BlueBubbles 服务生效。4. 双端联通验证从 iPhone 发消息到 openclaw 回复配置都就位后开始验证。第一步先在 openclaw 的 Web 界面http://127.0.0.1:8789/chat里发一条配置指令让 openclaw 把 channel 指向 BlueBubbles我已经配置好 BlueBubbles 服务器地址是 http://192.168.6.2:1234 服务器密码是 your_actual_password_here 你现在配置 openclaw 的 channel 到这个 BlueBubbles 服务器。 完成之后给我发送一首诗作为测试。openclaw 收到后会去连接 BlueBubbles如果配置正确它会通过 BlueBubbles 发一条测试消息到你的 iMessage。你在 iPhone 上应该能收到这条消息内容是一首诗。收到就说明「openclaw → BlueBubbles → Messages.app → iPhone」这条下行链路通了。但这时候还有个问题你在 iPhone 上主动发消息AI 收不到因为 BlueBubbles 需要一个 Webhook 回调地址才能把新消息推给 openclaw。回到 openclaw 对话界面发这条指令我的 BlueBubbles 已经配置完成你需要给我一个用于 BlueBubbles 给你发消息的 Webhook 地址 请你做好相关配置之后告诉我地址。openclaw 会返回一个类似http://192.168.6.2:8789/webhook/bluebubbles的 URL。把这个地址填到 BlueBubbles 面板的 Webhook 配置里保存。此后所有新收到的 iMessage 都会通过这个地址实时推送到 openclaw。现在做完整验证用 iPhone 给 Mac 上登录的那个 Apple ID 发一条 iMessage内容比如「现在几点」。几秒内你应该收到 AI 的回复。如果没回复先看 BlueBubbles 面板的日志有没有收到消息再看 openclaw 的日志有没有触发 webhook。两个日志对照着看能快速定位是通道断了还是 AI 没处理。验证通过后还有一个必须做的收尾限制谁能跟 AI 对话。默认情况下任何人都能给这个 iMessage 发消息AI 都会回。在 openclaw 配置里加一个白名单只允许你的号码{ channels: { bluebubbles: { enabled: true, serverUrl: http://192.168.6.2:1234, password: your_actual_password_here, webhookPath: /webhook/bluebubbles, allowedSenders: [8613800000000] } } }allowedSenders 里填你的手机号格式带国家码。改完重启 openclaw用别的号码发消息测试应该被静默忽略。5. 常见报错排查401、local proxy failed、reading choices、OAuth这套链路环节多出错时日志是关键。下面是我实际遇到过的几类报错和对应处理。401 Unauthorized出现在 openclaw 调模型或调 BlueBubbles 时。如果是调模型报 401检查 TaoToken 的 API Key 是否复制完整、有没有多余空格以及 Base URL 是不是https://taotoken.net/api。如果是调 BlueBubbles 报 401检查 settings.json 里的 password 和 BlueBubbles 面板里设置的是否一致注意大小写。local proxy failed通常是 BlueBubbles 的 serverUrl 填错或者 Mac 的局域网 IP 变了。Mac 重启或切换网络后 IP 可能变化用ipconfig getifaddr en0重新确认同步更新 openclaw 配置和 BlueBubbles 的 Proxy Services 地址。另外确认 LuLu 没有把 127.0.0.1 或局域网连接误拦。reading choices 相关报错这类错误一般出现在模型返回格式不符合预期时openclaw 解析响应失败。先确认模型 ID 是否正确有些模型不支持某些参数。把 temperature 调低、maxTokens 设合理值再试。如果持续报错换一个模型 ID 验证排除是模型侧问题还是 openclaw 解析问题。OAuth 相关报错如果你用的是需要 OAuth 的模型接入方式token 过期会报这个。TaoToken 的 API Key 方式不涉及 OAuth 刷新直接用 Key 即可。如果配置里混入了 OAuth 字段删掉统一用 apiKey。消息发出但 iPhone 收不到先看 BlueBubbles 面板日志有没有发送记录。有记录但没收到检查 Mac 上 Messages.app 是否正常登录、iMessage 是否开启。没有发送记录说明 openclaw 没调到 BlueBubbles回去查 channel 配置和 webhook 地址。iPhone 发消息 AI 不回看 BlueBubbles 有没有收到消息。收到了但没推给 openclaw检查 webhook 地址是否可达用curl手动打一下那个地址看返回。收到了也推了但 AI 没处理看 openclaw 日志有没有报模型错误回到第 2 节的模型验证步骤重测。排查时记住一个原则先确认单点能通再确认链路能通。模型单独能调、BlueBubbles 单独能收发、webhook 单独能打三个单点都正常串起来一般就没问题。哪一段断了日志会告诉你。6. 长期运行与 Coding Plan把 openclaw 当常驻代理用链路跑通只是开始真正有价值的是让它长期稳定运行。Mac 上建议把 openclaw 和 BlueBubbles 都设成开机自启openclaw 可以用 launchd 或者 pm2 托管BlueBubbles 在面板里有开机启动选项。Mac 设置成不自动休眠否则消息来了进程被挂起回复会延迟甚至丢失。如果你打算把 openclaw 用在日常编码、文件整理、定时任务这类场景模型调用量会上去这时候可以看下 TaoToken 的 Coding Plan地址是 https://taotoken.net/coding-plan 它针对长期编码和 Agent 类负载做了额度优化比按量计费更适合常驻代理。配置方式不变还是 Base URL 加 Key 加 Model ID 三件套只是计费模式不同。日常使用中我建议给 openclaw 加一层指令约束让它知道哪些事能做、哪些不能做。比如在系统提示里写明「只响应白名单号码」「不执行删除类命令」「文件操作限制在指定目录」。这些约束写在 openclaw 的配置或提示词里能避免误操作。另外iMessage 通道本身有个特性消息是端到端加密的但 Mac 上的 Messages.app 是明文存储的。如果 Mac 多人使用注意 Messages 的锁屏和账户隔离。BlueBubbles 的服务器密码也要定期换换完同步更新 openclaw 配置。最后说一个实际经验这套方案最脆弱的环节不是 openclaw也不是 BlueBubbles而是 macOS 的权限和网络环境。系统更新后辅助功能权限可能被重置路由器重启后局域网 IP 可能变化这些都会导致链路中断。建议写一个简单的健康检查脚本定时 curl 一下 BlueBubbles 的接口和 openclaw 的 webhook异常时给自己发个提醒。这样不用等发现 AI 不回消息了才去排查。整套配置的核心文件就是那份 settings.jsonBase URL、Key、Model ID、BlueBubbles 地址和密码都在里面。把它备份好换机器或重装时直接改地址就能迁移。需要查接口细节的话接入文档在 https://taotoken.net/doc 模型对话测试可以直接用 https://taotoken.net/chat 验证 Key 是否有效。
openclaw+imessage 免费无限流量集成方案：iPhone 与 macOS 双端配置实录
1. 为什么要在 iPhone 和 macOS 上打通 openclaw 与 iMessageopenclaw 是一个可以跑在本地、通过对话驱动任务执行的 AI 代理框架它能读写文件、调用命令、串联多个工具。iMessage 则是苹果设备之间默认的加密消息通道iPhone、iPad、Mac 上都能收发。把这两者接起来等于给你的 AI 代理配了一个随身入口你在外面用 iPhone 发一条消息家里的 Mac 上 openclaw 收到后执行任务再把结果通过 iMessage 回给你。整个过程走的是苹果端到端加密通道不需要公网 IP也不需要把服务暴露到互联网上。这套方案适合几类人手里有一台常年开机的 MacMac mini 最合适想用手机远程指挥本地 AI 干活或者在做智能家居、自动化通知希望用 iMessage 当消息总线再或者单纯想研究 openclaw 的 channel 机制找一个真实可跑的接入案例。它不适合完全零基础、只想点几下就完事的用户因为中间涉及 macOS 辅助功能权限、私有 API 开关、局域网地址配置这些环节任何一步错了消息就发不出去。我实测下来整条链路的核心是三个组件macOS 上的 Messages.app 负责真正的收发BlueBubbles Server 负责把 Messages.app 的能力包装成 HTTP 接口openclaw 通过 BlueBubbles 的 REST API 和 Webhook 完成双向通信。iPhone 端不需要装任何东西它只是普通地发 iMessage剩下的都在 Mac 上完成。理解了这个分工后面配置时每一步在干什么就清楚了。需要提前说明的是这套方案依赖 macOS 的私有 API 调用属于高阶玩法苹果对这类第三方工具的兼容策略存在不确定性建议把它当作技术验证和个人自动化实验来对待不要用在关键业务链路上。下面从环境准备开始一步步把双端配置跑通。2. 前置准备openclaw 运行环境与 TaoToken 接入配置在动 iMessage 之前先把 openclaw 本身跑起来并且确认它能正常调用模型。openclaw 的模型调用需要 Base URL、API Key、Model ID 三件套这里我用 TaoToken 作为模型接入层它的接口兼容主流协议配置起来比较直接。先拿到 API Key。打开 https://taotoken.net/api-keys 登录后创建一个新的 Key复制保存。注意这个 Key 只在创建时完整显示一次丢了就得重建。接着确认你要用的模型 ID比如 claude-sonnet 系列或者 gpt 系列具体以控制台里列出的为准。Base URL 统一填 https://taotoken.net/api 不要带多余的路径。openclaw 的配置文件通常在项目根目录下的 config 目录里不同版本路径略有差异我用的是 settings.json 形式。下面是一段可复制的配置片段把 Key 和模型 ID 换成你自己的{ models: { default: { provider: openai-compatible, baseUrl: https://taotoken.net/api, apiKey: sk-你的TaoToken密钥, model: claude-sonnet-4-20250514, maxTokens: 4096, temperature: 0.7 } }, channels: { bluebubbles: { enabled: false, serverUrl: http://192.168.6.2:1234, password: your_actual_password_here, webhookPath: /webhook/bluebubbles } } }这里 channels 里的 bluebubbles 先设成 false等 BlueBubbles Server 装好、拿到真实地址和密码后再改成 true。serverUrl 里的 IP 是你 Mac 在局域网里的地址用ipconfig getifaddr en0可以查到端口 1234 是 BlueBubbles 的默认端口。password 是 BlueBubbles 面板里设置的服务器密码不是 Apple ID 密码别搞混。配置写完后用一条命令验证 openclaw 能不能正常调模型openclaw chat --message 回复两个字就绪如果返回「就绪」说明模型链路通了。如果报 401多半是 Key 填错或者复制时带了空格如果报 model not found去 https://taotoken.net/console 确认模型 ID 拼写。这一步必须先过否则后面 iMessage 通了但 AI 不回复你会分不清是通道问题还是模型问题。模型验证通过后再确认 openclaw 的 Web 对话界面能打开。默认监听在 127.0.0.1:8789浏览器访问http://127.0.0.1:8789/chat应该能看到对话窗口。这个界面后面用来给 openclaw 发配置指令比命令行方便。到这一步前置环境就算齐了接下来装 BlueBubbles。3. 可复制配置BlueBubbles Server 安装与私有 API 开启BlueBubbles Server 是整条链路里最关键的中间件它把 macOS Messages.app 的私有接口暴露成 HTTP 服务。去 GitHub Release 页面下载对应版本的 DMG我实测用的是 v1.9.9安装过程按官方指引走即可。安装完成后首次启动系统会弹出辅助功能权限请求这是 BlueBubbles 要控制 Messages.app 必须拿到的权限在「系统设置 → 隐私与安全性 → 辅助功能」里勾选它。权限给完之后进入 BlueBubbles 面板的 Proxy Services 配置。这里选 Custom URL 或 LAN URL填入你 Mac 的局域网地址加端口比如http://192.168.6.2:1234。填完点完成BlueBubbles 会自动拉起 Messages.app 和 Find My 两个进程。Find My 用于设备状态同步如果你不需要可以关掉不影响消息收发。接下来是私有 API 开关。进入 Settings → Private API勾选 Messages Private API。这个选项打开后BlueBubbles 才能完整地收发 iMessage包括读取消息内容和发送回复。不开的话只能做有限的通知转发AI 没法主动回消息。这里有个容易踩的坑Apple ID 隔离。如果你的 Mac 和 iPhone 用同一个 Apple IDiMessage 会话里分不清哪条是你发的、哪条是 AI 发的消息会混在一起。正确做法是给 Mac 单独用一个 Apple ID 登录 Messages然后在 macOS 通讯录里把你的 iPhone 号码或邮箱添加成联系人。这样 AI 收到的消息来源清晰回复也不会串台。BlueBubbles 面板里还要设置一个服务器密码这个密码就是前面 openclaw 配置里 bluebubbles.password 的值。设置完保存然后回到 openclaw 的 settings.json把 channels.bluebubbles.enabled 改成 trueserverUrl 和 password 填成实际值。改完重启 openclaw 服务。为了安全建议用 LuLu 防火墙限制 BlueBubbles 的网络出口。它只需要访问 127.0.0.1 和局域网段其他外连一律拒绝。安装命令brew install --cask lulu启动 LuLu 后当 BlueBubbles 尝试联网时只放行 127.0.0.1 和 192.168.0.0/16 的连接其余全部拒绝。这样即使 BlueBubbles 被注入恶意代码也没法把数据外传。配置完重启 BlueBubbles 服务生效。4. 双端联通验证从 iPhone 发消息到 openclaw 回复配置都就位后开始验证。第一步先在 openclaw 的 Web 界面http://127.0.0.1:8789/chat里发一条配置指令让 openclaw 把 channel 指向 BlueBubbles我已经配置好 BlueBubbles 服务器地址是 http://192.168.6.2:1234 服务器密码是 your_actual_password_here 你现在配置 openclaw 的 channel 到这个 BlueBubbles 服务器。 完成之后给我发送一首诗作为测试。openclaw 收到后会去连接 BlueBubbles如果配置正确它会通过 BlueBubbles 发一条测试消息到你的 iMessage。你在 iPhone 上应该能收到这条消息内容是一首诗。收到就说明「openclaw → BlueBubbles → Messages.app → iPhone」这条下行链路通了。但这时候还有个问题你在 iPhone 上主动发消息AI 收不到因为 BlueBubbles 需要一个 Webhook 回调地址才能把新消息推给 openclaw。回到 openclaw 对话界面发这条指令我的 BlueBubbles 已经配置完成你需要给我一个用于 BlueBubbles 给你发消息的 Webhook 地址 请你做好相关配置之后告诉我地址。openclaw 会返回一个类似http://192.168.6.2:8789/webhook/bluebubbles的 URL。把这个地址填到 BlueBubbles 面板的 Webhook 配置里保存。此后所有新收到的 iMessage 都会通过这个地址实时推送到 openclaw。现在做完整验证用 iPhone 给 Mac 上登录的那个 Apple ID 发一条 iMessage内容比如「现在几点」。几秒内你应该收到 AI 的回复。如果没回复先看 BlueBubbles 面板的日志有没有收到消息再看 openclaw 的日志有没有触发 webhook。两个日志对照着看能快速定位是通道断了还是 AI 没处理。验证通过后还有一个必须做的收尾限制谁能跟 AI 对话。默认情况下任何人都能给这个 iMessage 发消息AI 都会回。在 openclaw 配置里加一个白名单只允许你的号码{ channels: { bluebubbles: { enabled: true, serverUrl: http://192.168.6.2:1234, password: your_actual_password_here, webhookPath: /webhook/bluebubbles, allowedSenders: [8613800000000] } } }allowedSenders 里填你的手机号格式带国家码。改完重启 openclaw用别的号码发消息测试应该被静默忽略。5. 常见报错排查401、local proxy failed、reading choices、OAuth这套链路环节多出错时日志是关键。下面是我实际遇到过的几类报错和对应处理。401 Unauthorized出现在 openclaw 调模型或调 BlueBubbles 时。如果是调模型报 401检查 TaoToken 的 API Key 是否复制完整、有没有多余空格以及 Base URL 是不是https://taotoken.net/api。如果是调 BlueBubbles 报 401检查 settings.json 里的 password 和 BlueBubbles 面板里设置的是否一致注意大小写。local proxy failed通常是 BlueBubbles 的 serverUrl 填错或者 Mac 的局域网 IP 变了。Mac 重启或切换网络后 IP 可能变化用ipconfig getifaddr en0重新确认同步更新 openclaw 配置和 BlueBubbles 的 Proxy Services 地址。另外确认 LuLu 没有把 127.0.0.1 或局域网连接误拦。reading choices 相关报错这类错误一般出现在模型返回格式不符合预期时openclaw 解析响应失败。先确认模型 ID 是否正确有些模型不支持某些参数。把 temperature 调低、maxTokens 设合理值再试。如果持续报错换一个模型 ID 验证排除是模型侧问题还是 openclaw 解析问题。OAuth 相关报错如果你用的是需要 OAuth 的模型接入方式token 过期会报这个。TaoToken 的 API Key 方式不涉及 OAuth 刷新直接用 Key 即可。如果配置里混入了 OAuth 字段删掉统一用 apiKey。消息发出但 iPhone 收不到先看 BlueBubbles 面板日志有没有发送记录。有记录但没收到检查 Mac 上 Messages.app 是否正常登录、iMessage 是否开启。没有发送记录说明 openclaw 没调到 BlueBubbles回去查 channel 配置和 webhook 地址。iPhone 发消息 AI 不回看 BlueBubbles 有没有收到消息。收到了但没推给 openclaw检查 webhook 地址是否可达用curl手动打一下那个地址看返回。收到了也推了但 AI 没处理看 openclaw 日志有没有报模型错误回到第 2 节的模型验证步骤重测。排查时记住一个原则先确认单点能通再确认链路能通。模型单独能调、BlueBubbles 单独能收发、webhook 单独能打三个单点都正常串起来一般就没问题。哪一段断了日志会告诉你。6. 长期运行与 Coding Plan把 openclaw 当常驻代理用链路跑通只是开始真正有价值的是让它长期稳定运行。Mac 上建议把 openclaw 和 BlueBubbles 都设成开机自启openclaw 可以用 launchd 或者 pm2 托管BlueBubbles 在面板里有开机启动选项。Mac 设置成不自动休眠否则消息来了进程被挂起回复会延迟甚至丢失。如果你打算把 openclaw 用在日常编码、文件整理、定时任务这类场景模型调用量会上去这时候可以看下 TaoToken 的 Coding Plan地址是 https://taotoken.net/coding-plan 它针对长期编码和 Agent 类负载做了额度优化比按量计费更适合常驻代理。配置方式不变还是 Base URL 加 Key 加 Model ID 三件套只是计费模式不同。日常使用中我建议给 openclaw 加一层指令约束让它知道哪些事能做、哪些不能做。比如在系统提示里写明「只响应白名单号码」「不执行删除类命令」「文件操作限制在指定目录」。这些约束写在 openclaw 的配置或提示词里能避免误操作。另外iMessage 通道本身有个特性消息是端到端加密的但 Mac 上的 Messages.app 是明文存储的。如果 Mac 多人使用注意 Messages 的锁屏和账户隔离。BlueBubbles 的服务器密码也要定期换换完同步更新 openclaw 配置。最后说一个实际经验这套方案最脆弱的环节不是 openclaw也不是 BlueBubbles而是 macOS 的权限和网络环境。系统更新后辅助功能权限可能被重置路由器重启后局域网 IP 可能变化这些都会导致链路中断。建议写一个简单的健康检查脚本定时 curl 一下 BlueBubbles 的接口和 openclaw 的 webhook异常时给自己发个提醒。这样不用等发现 AI 不回消息了才去排查。整套配置的核心文件就是那份 settings.jsonBase URL、Key、Model ID、BlueBubbles 地址和密码都在里面。把它备份好换机器或重装时直接改地址就能迁移。需要查接口细节的话接入文档在 https://taotoken.net/doc 模型对话测试可以直接用 https://taotoken.net/chat 验证 Key 是否有效。
