Category: AI

本地 AI 代理最初往往只是一个“能跑起来”的工具：在桌面机上安装，接入模型，配置几个插件，再接入聊天渠道或浏览器能力。这个阶段的重点是验证可用性，而不是长期运行。 但当一个 AI 代理开始承担更多日常任务，例如消息通道响应、文件处理、浏览器辅助、系统状态检查、项目资料检索，它就不再只是一个临时工具，而会逐渐变成本地基础设施的一部分。此时，运行位置、可用性、状态目录、外部访问入口、权限边界和数据分工都会变得重要。 这次迁移的核心，就是把 OpenClaw 的主安装实例从一台桌面 Linux 主机迁移到一台树莓派上，让树莓派承担长期在线的主服务角色，而桌面机则退回为扩展资源主机。 迁移前的结构 迁移前，OpenClaw 主实例运行在一台日常使用的桌面 Linux 主机上。它同时承担多个角色： 这种结构在早期很方便。所有东西都在同一台机器上，路径简单，浏览器也直接可见，调试成本低。需要排查时，打开终端就能看到服务、配置和日志。 但随着 OpenClaw 逐渐变成一个长期使用的代理系统，这种结构的问题也越来越明显。 首先，桌面机不是理想的 24 小时在线主机。它可能重启、关机、休眠，也可能因为桌面环境、浏览器、图形会话或用户操作影响服务状态。 其次，桌面机上同时有用户日常使用的程序和 OpenClaw 的自动化任务。一旦 AI 代理具备操作浏览器、文件和系统命令的能力，就必须严格区分“代理可管理的资源”和“用户私人使用的资源”。 第三，桌面机上的 OpenClaw 历史安装路径、配置目录、浏览器 profile、systemd user service、shell alias、旧备份目录等内容逐渐混杂。继续在原地修补，会让整个系统越来越难判断边界。 因此，迁移的目标不是单纯“换一台机器运行”，而是重新划分职责。 迁移后的目标架构 迁移后的结构可以概括为： 也就是说，树莓派成为 OpenClaw 的主节点，桌面机只保留少量无法或不适合迁移的能力。 这种设计的好处是，主服务变得更加稳定。树莓派功耗低，适合常驻；桌面机可以继续作为高性能或图形资源节点，但不再承担 OpenClaw 主实例的核心状态。 为什么选择树莓派作为主节点 树莓派并不适合承载所有任务。它的存储容量、CPU 性能和 I/O 能力都有限，尤其不适合大型数据库、大型本地项目和图形浏览器长期高负载运行。 但它很适合承担以下角色： …

在本地运行 AI 代理时，远程聊天入口是一个非常实用的功能。平时可以通过本机终端或网页后台操作，外出时则可以通过手机聊天软件临时发送指令，让 AI 代理执行查询、检查服务状态、处理项目任务，甚至进行一定程度的自动化操作。 不过，聊天软件本身并不是完全透明的通道。不同平台对机器人消息、官方账号、Webhook、API 调用方式都有不同限制。一次 OpenClaw 更新后的排查，正好暴露了 LINE 通道和 Telegram 通道之间的差异。 一、现象：后台能看到回复，但手机 LINE 收不到 OpenClaw 更新后，LINE 聊天通道出现了一个看起来比较奇怪的现象： 用户从 LINE 发送消息后，OpenClaw 能收到消息；网页管理后台也能看到 OpenClaw 生成了回复；但是手机 LINE 端却看不到回复内容。 从表面上看，这很容易让人怀疑是 OpenClaw 更新导致 LINE 插件异常，或者 Gateway、Webhook、认证密钥、KWallet、systemd 服务出了问题。尤其是在更新软件之后出现问题，人会自然地把故障和更新动作联系起来。 但进一步排查后，情况并不是这样。 OpenClaw 的通道状态显示，LINE 通道仍然处于 enabled、configured、running、works 等状态，说明通道本身并没有完全离线。问题集中在外发投递队列中：最近几条外发消息卡在 delivery queue，状态为 pending 或 failed，错误类似 partial delivery failure。也就是说，OpenClaw 内部已经完成了消息处理，但真正发送到 LINE …

问题现象 在一台 Arch Linux + KDE 桌面环境中，OpenClaw 升级后出现了一个问题：终端中的 OpenClaw TUI 可以正常连接 Gateway，Agent 状态也显示为 connected / idle，但执行“打开浏览器”之类的任务时失败。 报错大意如下： 这说明 OpenClaw Gateway 本身并没有崩溃，WebSocket 连接、Agent 会话和后端服务都还在运行。问题集中在一个地方：Gateway 进程无法访问当前 KDE 图形会话，因此不能启动可见浏览器窗口。 初步判断 Linux 桌面环境中，GUI 程序通常依赖一些图形会话环境变量，例如： 在 KDE 终端里执行检查时，当前 shell 环境是正常的： 可以看到类似结果： 但是进一步检查 OpenClaw Gateway 进程环境： 结果只包含： 缺少关键的： 这就确认了问题：OpenClaw Gateway 作为 systemd user service 启动时，没有继承 KDE …

背景 在一次 OpenClaw 日常检查中，执行了如下命令： 检查结果显示 OpenClaw 本体运行正常，Skills 与 Plugins 均无明显异常： Memory search 处于明确关闭状态： 这不是故障，而是配置选择。 真正需要关注的是 Security 部分的两个提醒： 其中第二项表示 Gateway 监听 0.0.0.0，允许局域网访问。对于需要从局域网其他设备访问 OpenClaw 的场景，这属于有意配置，不是错误。 第一项则更值得处理：gateway.auth.password 以明文形式保存在 openclaw.json 中。虽然这不代表密码已经泄露，但如果本地 agent、插件或 workspace 工具可以读取配置文件，就有机会看到该明文密码。因此，本次处理重点是将该字段迁移到 SecretRef，也就是改为从环境变量读取。 当前状态判断 初始检查结果说明： 因此，本次处理目标不是“修复坏掉的服务”，而是“收紧安全配置”。 修改前备份配置文件 在修改配置文件前，应先备份当前配置： 备份完成后，再进行 SecretRef 迁移操作。 配置 Secret Provider 执行： 进入交互式配置后，首先添加 Secret Provider。 界面提示： 选择： Provider source …