HermesAgent 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。

别再让 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 或人工照着执行的操作指南。

HermesAgent 为什么一直不回微信和企业微信？我最后排到的根因居然是本地 relay 的 3 秒超时

Sun, 31 May 2026 08:00:00 +0800

先说结论这次故障看起来像“模型不行”或者“微信通道坏了”，但真正把消息链路掐断的，是我本地那层 relay 的超时设置。它把整条上游请求的等待窗口限制成了 3 秒，而真实的 WeChat / WeCom 消息 turn 往往需要更久才能从新 API 网关拿到完整回复。结果就是：relay 先断开，HermesAgent 只能看到 Connection error、RemoteProtocolError，然后主模型和 fallback 一起被耗尽。更准确地说，这不是 HermesAgent 核心代码的问题，也不是模型名的问题，而是一个本地外置组件的连接策略问题。把 connect timeout 和 response wait 混成同一个超时，等于给长请求做了一个错误的截止时间。修复方式也不复杂：连接阶段保留短超时，连接成功后把 socket 切回阻塞等待；同时把 relay 做成独立、可持续启动的服务，不再把它绑死在临时 shell 里。问题背景 HermesAgent 这条链路不是单机脚本，而是一条完整的消息生产线。用户从微信或企业微信发出一句话，消息会先进入 Hermes 的通道层，再进入 Gateway，接着经过本地 relay 转发到自建的 NewAPI 网关，最后才到模型服务。模型回来的内容还要经过 Hermes 的消息整理、工具调用处理、最终拼接，再发回原始通道。这种结构的好处是灵活，坏处也很现实：任何一层都可能制造“看起来像模型故障”的表象。你看到的是“没有回复”或者“Connection error”，但根因可能在更外层的 relay、socket、超时、代理或者会话路由里。这次我一开始也走了老路，先怀疑模型配置。因为从表象看，主模型和 fallback 都失败了，日志里反复出现： Primary model failed switching to fallback API failed after 1 retries Connection error Max retries exhausted 如果你只看这一段，很容易得出“模型端不稳定”的结论。但这类结论通常太早。因为同一批模型在别的入口上是能正常工作的，/v1/models 也能返回，简单的 health check 也没有异常。真正出问题的是“真实消息 turn”。

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

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

先说结论：

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

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

从 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 里的专用虚拟机中。