Openclaw on 魔都水滴

Mac mini 别吃灰：养双 Agent，Windows 随时接管

Sat, 11 Jul 2026 04:00:00 +0800

先说结论

如果你的日常主力设备都是 Windows，却专门留了一台低功耗 Mac mini 长期开机运行 OpenClaw、HermesAgent 或 macOS 专属自动化任务，那么最省桌面空间的做法，不是再给它配一套显示器和键鼠，而是把它当成一台安静的“Agent 小服务器”。macOS 自带“屏幕共享”，Windows 端安装 RealVNC Viewer 后，需要配置、升级或排障时再远程接管桌面。

这种组合特别适合“平时只用 Windows，Mac mini 负责 24 小时养 Agent”的家庭或个人工作室：Mac mini 功耗相对较低、体积小、运行安静，OpenClaw / HermesAgent 可以持续处理消息、自动化和定时任务；Windows 继续承担日常办公，需要查看 Agent 状态时再打开 RealVNC。

真正容易踩坑的不是“软件不会装”，而是屏幕共享、用户权限、VNC 兼容密码、网络可达性，以及无人值守 Mac 的睡眠和重启恢复。本文按真实排障顺序讲清楚，并提供 Windows 11、Ubuntu 26.04、macOS 26 三套检查脚本。

安全底线也先写在前面：不要把 VNC 常用的 TCP 5900 端口直接暴露到公网。 同一局域网直接连接最简单；跨网络使用时，应先进入自建 VPN、可信内网隧道或其他受控网络，再连接 Mac。

一个 operator.write 把网关干翻：OpenClaw fallback 模型为什么突然全体认证失败？

Fri, 10 Jul 2026 08:00:00 +0800

这次问题表面上很像“模型供应商挂了”：OpenClaw 刚加完 NewAPI 的几个 fallback 模型，命令一跑，直接报 Provider authentication failed；进一步看网关调用，真正的错误是：

missing scope: operator.write

如果只看第一层现象，很容易把锅甩给模型密钥、NewAPI 地址、模型名、网络连通性。但这次真正的问题不在模型，也不在 NewAPI，而在 OpenClaw 走网关调用 fallback 模型时，某个 model override 分支把“设备身份”省掉了。结果服务端虽然看到了一个被授权的请求，却没有把它绑定到那台已经配对、已经拥有 operator.write 的设备上，最终在执行 agent RPC 时被权限系统拦下。

先说结论：这是一个典型的“令牌有了，钥匙串没带上”的问题。 模型直连能成功，网关调用失败；设备列表里明明能看到 operator.write，但真正发起网关请求时没有使用那份已配对设备身份，于是权限检查按未绑定请求处理，报出 missing scope: operator.write。

别再让 Agent 吞掉你的 Token：我把 Headroom 接到 NewAPI、OpenClaw 和 HermesAgent 的完整实战

Sat, 20 Jun 2026 12:30:00 +0800

先说结论

这次我没有替换原来的 NewAPI，也没有让 OpenClaw / HermesAgent 直接改用一个不确定的新网关。真正做法是：在 NewAPI 前面加一层 Headroom 代理，把所有已经使用 OpenAI-compatible 协议的调用改到 http://<headroom-host>:8787/v1，而原来的 NewAPI 入口继续保留。这样 Agent 发来的长上下文先经过 Headroom 压缩，再转发给 NewAPI，最后仍由 NewAPI 统一路由到后端模型。

最关键的原则只有一句：先测试，后修改；只迁移测试通过的 OpenAI-compatible 项；非 OpenAI 协议的 fallback 不碰。 这篇文章既是复盘，也是一份可以直接交给 Agent 或人工照着执行的操作指南。

OpenClaw TUI 变复读机？thinking 和回复重复的临时止血手册

Tue, 02 Jun 2026 10:42:00 +0800

先说结论

如果你在 OpenClaw TUI 里看到同一段 thinking 重复出现、同一段回复正文连续出现两遍，先不要急着清空模型、删除 session 或者怀疑所有 provider 配置都坏了。这个问题很可能不是“历史消息太多”，也不一定是模型真的想复读，而是 OpenAI-compatible 流式响应里同时出现了增量 delta 和额外的完整 message，OpenClaw 某些版本在上层聚合时把两份内容都算进去了。

临时解决思路很简单：备份本地安装文件，在 OpenClaw 的运行聚合层增加一个非常保守的去重保护；它只处理“同一轮、同一模型、完全重复的 text/thinking 块”，然后重启 gateway，用 marker 测试确认 TUI 和 session 落盘都只剩一份内容。

本文是一份可复用的临时修复记录。所有路径、模型名、网关地址和 Token 都做了脱敏处理，真实环境请用自己的安装路径和模型名替换。不要把本文里的占位符当成真实配置直接复制。

从零开始的 AI Agent 完整迁移实战：踩坑九九八十一难后的通关攻略

Sat, 30 May 2026 08:00:00 +0800

先说结论：

从一个 AI Agent 平台迁移到另一个平台，听起来像是「复制粘贴」的事情，实际上却是一场涉及数据迁移、渠道对接、定时任务、自动启动、代理配置、模块兼容性的系统工程。

这篇文章记录了我从零开始完成一次 AI Agent 完整迁移的全过程：从安装新平台、迁移记忆和技能、配置消息渠道、排查各种诡异问题，到最终实现全自动运行。涉及 9 个踩坑点和对应的解决方案，希望能帮到有类似需求的朋友。

AI 助手为什么把一句话复读四遍：一次 OpenClaw 微信通道排障复盘

Fri, 29 May 2026 11:24:29 +0800

先说结论

这次问题看起来像“微信通道把同一条回复发了四遍”，但真正的重复发生在更早的位置：消息还没有进入微信发送层之前，OpenClaw Agent 的最终可见文本就已经被模型执行链路重复拼接了。排障的关键不是一上来改微信插件，而是把链路拆成发送层、会话层、模型路由层三段，用最小 prompt 复现，再比较“兼容网关路径”和“原生 provider 路径”的输出差异。最后的修复也很朴素：让个人 IM 通道显式走原生 provider，移除容易被误选的故障候选模型路径，重启 Gateway 后复测主会话。

这篇文章不会出现任何真实内网地址、账号、token、会话 ID、个人微信标识或私有路径。所有配置片段都已经脱敏，并用 <PLACEHOLDER> 形式表示。重点是分享一套可复用的排障方法，而不是公开某个具体环境的细节。

OpenClaw 升级指南：从入门到精通的完整攻略

Fri, 29 May 2026 09:00:00 +0800

先说结论

OpenClaw是一款强大的个人 AI 助手，支持多种消息渠道和 AI 模型。升级 OpenClaw 其实非常简单，最推荐的方式是使用 openclaw update 命令。本文将详细介绍各种升级方式，包括从 npm 包安装到 git 源码安装的切换，以及升级后的验证和回滚策略。

本文所有示例都使用公开项目、公开链接和占位符，不包含真实服务器地址、账号、Token、业务配置或任何内网信息。文中配图来自 OpenClaw 官方仓库和文档，内容按其 MIT 授权引用。

从 OpenClaw 迁移到 HermesAgent：一次丝滑的 AI 智能体搬家实战

Fri, 29 May 2026 08:00:00 +0800

前言：为什么我要"搬家"？

2026 年，AI 智能体（Agent）领域的发展速度简直可以用"日新月异"来形容。半年前还在用的工具，可能今天就被更强大的替代品超越了。作为一个深度依赖 AI 智能体来处理日常工作的人，我一直在关注这个领域的最新动态。

最近，我完成了一次从 OpenClaw 到 HermesAgent 的完整迁移。这不是一时冲动的决定，而是在实际使用中感受到两个工具的差异后，做出的深思熟虑的选择。

这篇文章会详细分享：

背景：OpenClaw 和 HermesAgent 分别是什么
迁移原因：为什么我要从 OpenClaw 迁移到 HermesAgent
迁移过程：如何一步步完成迁移，保留所有数据
踩坑记录：迁移过程中遇到的问题和解决方案
迁移后清理：如何彻底移除 OpenClaw 残留文件
迁移后体验：HermesAgent 带来了哪些新能力
Q&A：常见问题解答

80元十年域名买完后，下一步就交给 Cloudflare

Wed, 13 May 2026 08:46:06 +0800

先说结论

便宜域名买完只是第一步。真正能把这个域名玩起来的地方，是把它接到 Cloudflare：DNS 解析、动态 DDNS、企业邮箱验证、邮件转发、证书自动化、甚至让 OpenClaw / HermesAgent 这类 Agent 通过受限 API Token 帮你维护复杂配置，都可以从这里开始。前文已经讲了如何购买最便宜的 10 年 80 元 左右的 .xyz 域名，本文就接着讲：买完以后，怎么把它交给 Cloudflare 这个“互联网大善人”，并且尽量少走弯路。

本文所有截图和示例都使用 example.xyz、203.0.113.10、2001:db8::10 这类公开文档占位符，不包含真实域名、真实 IP、Cloudflare 账号、Zone ID、API Token 或任何内网信息。你照着做时，把占位符替换成自己的域名和服务地址即可。

PVE 8 升 9 别硬刚：一句话交给 Agent，或者按这份清单手工升级

Tue, 12 May 2026 19:00:00 +0800

先说结论

Proxmox VE 8 升级到 9 的本质不是“复制几条命令”，而是一次 Debian Bookworm 到 Trixie、PVE 8.4 到 PVE 9.x、内核与存储网络组件一起变化的系统升级。最省时间的方式，是把检查、备份核对、日志记录、命令执行和升级后验证交给 Codex、Claude、OpenClaw、HermesAgent 这类 Agent；但涉及重启、仓库切换、包删除提示、配置文件覆盖提示时，仍然必须由人确认。想完全手工做也没问题，本文后半部分给出一套可以逐步执行的人工升级清单。

这篇文章写给两类人：一类是已经习惯让 Agent 管理机器，想用一句话把 PVE 8 到 9 的升级流程交给工具跑完；另一类是更喜欢自己敲命令，希望有一份顺序清楚、风险点明确、可以照着核对的手工操作稿。

文中所有主机名、地址、仓库、token、账号都使用占位符，不包含任何真实内网信息。请把 <PVE_NODE>、<BACKUP_TARGET>、<ADMIN_CONSOLE> 这类内容替换成你自己的环境。生产环境升级前，请以 Proxmox 官方文档为准，并先确认备份可以恢复。

Ubuntu 26.04 升级别乱按：Agent 一句话托管，人工路线也一次讲透

Tue, 12 May 2026 07:30:00 +0800

先说结论

Ubuntu 22.04 / 24.04 升级到 26.04，最重要的不是记住某一条命令，而是先搞清楚升级路径。22.04 LTS 不能直接跳到 26.04 LTS，必须先升级到 24.04 LTS，再从 24.04 LTS 进入 26.04 LTS。并且截至 2026-05-12，Ubuntu 26.04 LTS 虽然已经正式发布，但 24.04 LTS 到 26.04 LTS 的常规 LTS 升级提示通常要等 26.04.1 之后才会面向普通 LTS 用户开放；官方计划里的 26.04.1 Point Release 日期是 2026-07-09。生产机器建议等常规升级路径打开，测试机或评估机才考虑显式使用提前升级参数。

如果你已经在使用 Code、Claude、OpenClaw、HermesAgent 这类 Agent，完全可以用一句话把升级任务交出去，让它先做检查、备份、升级和验证，节省大量重复操作时间。但这句话不能只写“帮我升级 Ubuntu”，而要把安全边界、升级路径、备份、业务验证和回滚要求说清楚。本文会给出可以直接复制的 Agent 提示词，也会给出完全人工执行的步骤。

本文不会出现任何真实主机名、内网地址、账号、密钥、Token、业务系统名称或私人路径。所有命令都使用通用占位符，例如 <HOST>、<SERVICE>、<BACKUP_DIR>。你可以把它们替换成自己的环境值。

国产小模型不稳定？别急着换模型，先给你的 Agent 装上 Superpowers

Thu, 07 May 2026 16:43:10 +0800

先说结论

很多 Agent 工作流里所谓“国产模型不稳定”，表面看是模型一会儿聪明、一会儿犯糊涂，真正落到工程现场，常常是两个问题叠在一起：一是模型本身参数规模、训练数据和工具调用稳定性确实不如顶级闭源大模型；二是 Agent 没有稳定的方法论和检查点，导致每一次任务都靠即时发挥。前者短期内不一定能解决，后者可以马上解决：给 OpenClaw、HermesAgent、Codex、Claude、Gemini、OpenCode 这类 Agent 安装一套可复用的 Skill 工作流，例如 Superpowers。

Superpowers 不能把小模型“魔改”成大模型，也不能保证所有国产模型突然拥有顶级推理能力。它真正有价值的地方，是把 Agent 的行为从“靠灵感输出”拉回“按流程工作”：先澄清目标，再写设计，再拆计划，再测试，再审查，再验证。对参数较少、上下文保持能力较弱、输出波动较大的模型来说，这种外置流程约束往往比继续堆提示词更有效。

这篇文章想聊一个很现实的问题：当我们把 OpenClaw、HermesAgent、Codex、Claude、Gemini、OpenCode 乃至更多 Agent 放进日常工作流之后，为什么某些模型看起来特别不稳定？又为什么我会建议先安装 Superpowers 这样的 Skill，而不是第一反应就去换模型、加提示词、调温度或者把系统提示写成一篇论文。

为了避免泄露任何隐私信息，本文所有环境、路径、主机、账号、项目名都使用通用示例，不包含真实内网地址、密钥、业务系统名称或个人配置。文中的命令也以官方公开文档和通用安装方式为准，实际使用前请结合你自己的 Agent 版本确认。

如何写提示词，让 OpenClaw、HermesAgent、Codex、Claude、Gemini、OpenCode、Droid 自动写文章并发布到微信公众号草稿箱

Tue, 05 May 2026 16:00:00 +0800

先说结论

想让 OpenClaw、HermesAgent、Codex、Claude、Gemini、OpenCode、Droid 这类 Agent 自动写文章、生成博客、转换微信公众号 HTML、检查预览效果，并最终把内容发布到微信公众号草稿箱，提示词不能只写“帮我发一篇文章”。真正有用的提示词要把目标、素材、路径、账号约束、网络白名单、检查项、失败回退、隐私边界和最终验收写清楚。Agent 才能从“写一段内容”升级成“完成一次可验证的发布流程”。

本文整理一套可以复用的写法：如何准备微信公众号草稿箱 API，为什么固定 IP Linux 机器很重要，怎样让 Agent 先直连再走中转，如何使用 Markdown 到公众号 HTML 的转换器，如何让 Agent 检查白字白底、奇怪缩进、图片可访问性，最后如何把整条流程写进一段高质量提示词里。

为了避免泄露任何私人环境信息，本文只使用占位符和抽象示例，不出现真实 AppSecret、内网地址、跳板机地址、仓库地址、主机名、token、cookie 或任何可定位到具体环境的配置。你可以把文中的占位符替换成自己的值，但不要把真实密钥写进公开文章、公开仓库或聊天截图。

给 OpenClaw / HermesAgent 集成群晖操作 SKILL：从一句话到可审计的 NAS 自动化

Tue, 05 May 2026 12:20:00 +0800

我之前已经整理过两篇偏“命令手册”风格的群晖文章：

这两篇文章解决的是“人知道有哪些命令可以用”的问题。本文想解决另一个更实际的问题：如果我已经在使用 OpenClaw / HermesAgent 这类 Agent 工具，能不能把这些群晖命令沉淀成一个操作 SKILL，让我以后用一句话就能让 Agent 帮我检查 NAS、整理状态、生成操作计划，甚至在确认后执行一些维护命令？

我的答案是：可以，但不应该把它做成“Agent 拿到 root 权限以后随便跑”。正确的集成方式应该是：

让群晖 SSH 访问可控、可验证、可撤销。
把常用群晖 CLI 操作写进 SKILL，让 Agent 知道可用命令、风险分级和输出格式。
默认只允许只读诊断命令自动执行。
对重启服务、修改权限、改用户、改网络、删除文件、存储相关操作设置确认门禁。
每次执行后保留命令、输出和结论，方便回看和追责。

如果你只想快速理解整篇文章，看下面这张图就够了。

OpenClaw / HermesAgent 的最佳归宿：Proxmox VE

Wed, 29 Apr 2026 10:00:00 +0800

OpenClaw / HermesAgent 的最佳归宿：Proxmox VE

如果只把 OpenClaw 或 HermesAgent 看成一个“能聊天的机器人”，那它装在哪里似乎都无所谓：实体机可以，VPS 可以，Docker 也可以，甚至日常用的笔记本也能跑起来。

但只要它开始接入消息渠道、执行命令、读写文件、调用浏览器、保存长期记忆、定时跑任务，这个问题就不再是“能不能安装”，而是“它应该被放进什么样的运行边界里”。

我的结论很明确：OpenClaw / HermesAgent 这类长期运行的个人智能体，最稳妥的归宿不是直接装在实体机上，而是安装在 Proxmox VE 里的专用虚拟机中。

这里的重点不是 PVE 有多高级，而是它刚好解决了智能体运行时最难缠的三件事：数据隔离、计算资源隔离、备份与恢复。

OpenClaw 备份失效排查与修复实录：从两个机器同时失效到自动备份彻底恢复

Mon, 13 Apr 2026 09:30:00 +0800

我把这次问题写成一篇完整的复盘，不是因为它足够戏剧化，而是因为它足够典型。

这次出问题的不是一个单点，而是两台机器的自动备份同时失效：一台是本地的 macOS 机器，一台是远程的 VPS。两边手动执行都可以成功，备份文件也能写到 NAS，但只要放回定时任务，结果就会变得不稳定，甚至直接失败。表面看像是“定时器没触发”，实际上真正的问题分布在调度、权限、锁、日志、以及验证方式几个不同层面。

对我来说，这类故障最麻烦的地方，不在于它有多难修，而在于它会制造一种很强的错觉：每一部分单独看都像没坏，拼到一起却就是不工作。

使用 WoClaw 解决多智能体共享记忆：让 OpenClaw、Codex、Claude、Gemini 站在同一张桌子上

Sun, 05 Apr 2026 20:10:00 +0800

我一直觉得，多智能体系统最难的不是“谁更聪明”，而是“谁还记得上一次已经讨论到哪里了”。

当你把 OpenClaw、OpenAI Codex、Claude、Gemini 这些工具放进同一个工作流里，最容易出现的问题并不是回答质量不够，而是上下文开始分叉：

OpenClaw 记住了调度顺序，Codex 记住了代码细节，Claude 记住了讨论结论，Gemini 记住了背景资料，但它们彼此并不知道对方知道什么。
每个工具都有自己的会话生命周期，今天说过的话，明天可能就不在同一个上下文里了。
一旦项目进入“多人、多轮、多工具”的阶段，重复解释背景会比真正解决问题更耗时。
如果没有统一的记忆层，最后你得到的不是协作，而是几份彼此相似、又彼此不兼容的局部答案。

这篇文章想讲的就是：我怎么用 WoClaw 把这些工具拉到同一套共享记忆里，让它们从“各说各话”变成“围着同一份状态协作”。

为了避免泄露任何隐私信息，下面所有例子都做了抽象处理，不包含真实机器名、账号、地址、密钥和内部项目代号。

把 OpenClaw 升级到 2026.3.23-2：一次真实的兼容性升级记录与排障手册

Tue, 24 Mar 2026 21:20:00 +0800

这篇文章记录一次真实的 OpenClaw 升级过程：目标不是“把版本号改上去”这么简单，而是在多节点、不同安装形态、外部插件较多的情况下，把 OpenClaw 从 2026.3.8 / 2026.3.13 这一代稳定升级到 2026.3.23-2，同时尽量保证既有消息通道、插件、服务方式、回滚路径都可控。

我最终采用的是“先评估，再金丝雀，再复制已验证产物”的策略。升级过程里真正棘手的部分，不是 OpenClaw 核心包本身，而是插件 SDK 兼容性、JIT 缓存、混合安装路径、边缘节点出网失败、以及不同服务绑定策略对探测命令的影响。这些问题如果不提前识别，线上升级很容易看起来“版本成功了”，实际上通道已经半瘫痪。

OpenClaw 接入 MiniMax 一个月总结：稳定、够快，真正有价值的是可持续

Thu, 19 Mar 2026 10:30:00 +0800

过去一个月，我持续用 MiniMax 作为 OpenClaw 的主模型，覆盖了日常巡检、连接排障、健康检查、安全加固、定时任务治理和博客辅助写作等一整套自动化流程。回头看，这次实践最大的收获并不是“AI 能替我做多少事”，而是我逐渐确认了一个更现实的判断：对于 OpenClaw 这类要长期运行、要和工具链打配合、还要处理大量中文上下文的系统来说，模型最重要的不是纸面能力，而是稳定性、响应速度、接入成本和长期可维护性之间的平衡。