Category: AI

主实例迁移完成，并不意味着 OpenClaw 已经完全恢复到可用状态。 对一个本地 AI 代理系统来说，真正复杂的部分往往不在安装程序本身，而在迁移之后的状态修复：旧路径残留、插件注册状态、SecretRef 引用、消息通道、Dashboard 授权、历史会话索引等，都可能因为主机和路径变化而出现问题。 本篇记录的是 OpenClaw 主实例迁移到新的常驻节点后，如何逐步修复运行状态，并最终确认系统恢复正常。 迁移后最先暴露的问题：路径仍指向旧主机 迁移后，OpenClaw 的主状态目录和工作区已经转移到新主机，但部分内部记录仍然指向旧主机上的路径。 典型表现是：消息通道能够收到请求，但代理长时间卡在处理中，或者表现为“正在输入”，最终没有正常回复。 这类问题的根因通常不是模型不可用，也不是消息平台本身故障，而是 OpenClaw 内部仍然认为工作区位于旧路径。例如： 当 attestation、session snapshot、workspace state 等记录仍然引用旧路径时，OpenClaw 在处理任务时可能会尝试访问一个已经不存在的 workspace，从而导致任务无法继续。 因此，迁移后的第一步不是急着修插件，而是确认： 路径修复完成后，消息通道才恢复正常响应。 插件状态异常：目录存在，但 registry 不认识 迁移后另一个明显问题是插件 warning。 从文件系统看，相关插件目录可能已经随状态目录迁移过来，目录本身存在，权限也正常。但 OpenClaw 启动或进入 TUI 时仍然提示： 这说明问题不一定是插件文件缺失，而可能是插件 registry、host peer link 或 managed npm plugin 状态没有正确恢复。 这类问题比较容易误判。因为目录存在会让人以为插件已经安装完成，但 OpenClaw 运行时真正依赖的是它自己的插件注册和加载状态，而不仅仅是文件是否存在。 处理方式是使用 …

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

OpenClaw 除了可以通过终端、Web UI、LINE、Telegram 等入口使用，也可以接入 Nextcloud Talk。相比依赖外部聊天平台，Nextcloud Talk 更适合成为自托管环境中的私人 AI 控制室：聊天入口、项目文件、任务协作和服务器工作流可以统一放在自己的 Nextcloud 体系中。 这次部署的目标，是在已经运行的 OpenClaw Gateway 基础上，新增一个 Nextcloud Talk 房间，让 Talk 中的机器人能够接收消息、转发给 OpenClaw，并把 OpenClaw 的回复写回 Talk 房间。 整个链路大致如下： 看起来只是“添加一个聊天入口”，实际排查中涉及 Nextcloud、Talk Bot、OpenClaw 通道、反代、防火墙、房间权限和回写 API 等多个环节。 一、Nextcloud Talk Bot 与普通 Webhook 应用不是一回事 Nextcloud 中有一些通用 webhook 相关应用，用于在文件上传、修改、删除等事件发生时通知外部系统。但 OpenClaw 接入 Nextcloud Talk 并不依赖这类通用 webhook 应用。 …

在本地运行 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 …

在给 OpenClaw 配置外部聊天通道时，一个很关键的问题是：消息到底是由 OpenClaw 主动拉取，还是由外部平台反向推送到 OpenClaw Gateway。这个区别会直接影响部署方式、网络要求、安全边界和维护复杂度。 本文以 Nextcloud Talk 与 Telegram 为例，整理两种典型通信模式的差异。 1. OpenClaw 是否支持 Nextcloud Talk OpenClaw 支持 Nextcloud Talk 通道。它属于官方集成的聊天通道之一，工作方式是通过 Nextcloud Talk bot 与 OpenClaw Gateway 之间的 webhook 通信完成消息收发。 也就是说，Nextcloud Talk 端收到用户消息后，会把消息通过 webhook 请求发送到 OpenClaw Gateway；OpenClaw 处理完成后，再把回复返回到对应的 Talk 会话中。 因此，Nextcloud Talk 的关键不只是“OpenClaw 能不能访问 Nextcloud”，还包括“Nextcloud 服务器能不能反向访问 OpenClaw Gateway …

一、AI 代理的重点已经不只是“聊天” 普通大语言模型更多是在对话框中回答问题，而 AI 代理的使用方式明显不同。代理不仅要理解自然语言，还要调用工具、读取文件、执行命令、操作浏览器、控制桌面环境，甚至连接本地服务或外部软件。 在这种场景下，后端模型的角色已经从“聊天模型”变成了“行动系统的大脑”。它需要完成的不只是解释问题，而是持续推进任务： 因此，选择 AI 代理后端模型时，不能只看聊天效果，也不能只看价格。真正重要的是：模型是否适合作为代理的大脑，是否能够稳定地与工具、终端、脚本、接口和真实系统配合。 二、Codex 的价值：强的不只是模型，而是一整套代理体验 Codex 类模型之所以适合 AI 代理，并不是因为它只会写代码，而是因为它比较适合真实操作环境。 在实际使用中，AI 代理经常会遇到这些情况： 普通聊天模型在这种场景中容易出现两个问题：一是给出看似合理、实际不可执行的建议；二是任务一长就丢失上下文，开始偏离目标。 Codex 类模型的优势在于，它更擅长在“边执行、边观察、边修正”的过程中工作。它不只是回答“应该怎么做”，而是更接近于真正帮助完成任务。 这也是为什么在 OpenClaw 这类代理工具中，Codex 往往能给人一种“真的能干活”的感觉。 三、为什么需要寻找 Codex 的替代或补充模型 虽然 Codex 类模型很好用，但 AI 代理的 Token 消耗非常大。 普通聊天中，一次问答可能只消耗少量上下文；但代理任务不同。代理需要不断读取环境信息、工具结果、命令输出、文件内容和错误日志。每一次观察、计划、执行和修正都会消耗 Token。 尤其是下面这些任务，消耗会非常明显： 因此，如果完全依赖高价或有限额度的模型，长期使用成本会比较高。这就引出了一个现实问题： 是否存在更便宜、可以接入 OpenClaw、又能在一定程度上接近 Codex 的模型？ 围绕这个问题，可以重点关注 DeepSeek、Qwen、GLM、MiniMax、Kimi 等模型或平台。 四、便宜模型和 Codex 级模型不是一回事 在选择模型时，需要先区分两个概念： 这两个概念不能混在一起。 …

问题现象 在一台 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 …

本地 AI Agent 的价值，不只在于能够回答问题，更在于它可以直接接触本机环境：读取工作目录、生成文件、调用本地工具、整理资料、执行批量操作。相比完全运行在云端的聊天机器人，本地 Agent 更像是桌面系统里的一个可控助手。 不过，本地运行也带来一个现实问题：如果只能在电脑前通过浏览器访问，它的使用范围仍然受到限制。为了让本地 Agent 能够在手机上随时使用，可以将本机服务通过安全的方式暴露到公网域名，并进一步接入聊天平台。这样一来，手机上的普通消息窗口就可以成为本地 Agent 的控制入口。 这次实践完成的目标，是将一套安装在 Linux 桌面环境中的 OpenClaw，从单机本地访问，扩展为可以通过 HTTPS 域名访问，并最终接入 LINE Messaging API，实现手机 LINE 与本机 OpenClaw 的直接对话。 一、本地服务从回环地址调整为局域网可访问 最初，OpenClaw Gateway 只面向本机访问。这种方式适合纯桌面使用，但反向代理服务器无法从局域网访问该服务。 因此第一步是调整 Gateway 的监听方式，让它从本机回环地址改为局域网可访问。调整后，OpenClaw Gateway 可以监听在所有网卡地址上，局域网内其他主机便能够访问该端口。 同时，Gateway 启用了内置的密码认证。这里没有把认证放在反向代理层，而是让 OpenClaw 自己负责登录与设备配对。这样做的好处是认证逻辑更集中，也更符合 OpenClaw 自身的设计。 整体思路是： 完成配置后，需要重启 OpenClaw Gateway，并确认服务已经监听在局域网地址上。随后还需要在本机防火墙中开放对应端口，使反向代理服务器可以正常连接。 二、通过反向代理提供 HTTPS 域名访问 本地 Gateway 可以被局域网访问后，下一步是在反向代理服务器上增加一个新的站点配置。 反向代理服务器负责处理公网 …