我放弃了养虾，开始养马：从 OpenClaw 转向 Hermes 的一次工作流迁移
我最早把 OpenClaw 当成一只可以养在服务器里的“虾”：轻巧、灵活、能夹起一些具体任务。后来真正用了一段时间，我发现自己需要的不是一个偶尔能动的助手，而是一匹能记路、能训练、能陪我跑长途的马。于是我放弃了养虾，开始养 Hermes。
为什么我放弃了养虾
我一开始接触 OpenClaw，是被那种“个人 AI 助手”的想象吸引的：自己部署、自己控制、能接模型、能跑工具，最好还能接到网页或消息平台里。对一个喜欢折腾工作流的人来说，这种东西很容易让人兴奋。它不像单纯的聊天机器人，而像一个真的能伸手去做事的小系统。
但 AI Agent 真正的考验，从来不是第一次跑起来。
第一次部署成功，通常只是新鲜感。真正的问题会出现在几天、几周之后：服务是不是还活着，模型接口有没有变，登录态有没有丢，某个工具为什么突然没有返回，后台有没有吞消息，配置文件是不是又要重新对一遍。
这些问题每一个都不算大，但它们会不断打断我的工作流。到后来，我越来越清楚地感觉到：我不是想再养一个需要我每天盯着的技术玩具。我想要的是一个可以长期陪我工作、能被训练、能复盘、能记住经验的操作伙伴。
这是我放弃 OpenClaw 的第一个原因：维护感太强，而沉淀感不够。
第二个原因，是它给我的感觉更像“当前会话里的助手”，而不是“长期一起进化的助手”。
一个 Agent 如果每次都要重新认识我，那它再聪明也只是临时工。每次排障都要重新告诉它：这台 VPS 是什么系统，哪些服务不能乱动，哪个 profile 不能混，哪些登录态不能删，哪些命令我不喜欢复制很长一串，哪些事情可以直接检查，哪些事情必须先问。这样的助手可以解决眼前问题，但很难真正进入日常工作。
我希望 Agent 能把稳定事实记住，把重复流程沉淀下来。比如一次 Web UI 吞消息的排查，不能下次还从头问起；一次 Cloudflare 登录态处理，不能下次又建议我删浏览器 profile；一次服务器迁移，不能把 memory、auth、sessions、skills 混在一起复制。
第三个原因，是我越来越需要“工作流层”的能力，而不只是工具调用。
很多 AI Agent 都能联网、读文件、跑命令。但真正复杂的任务往往不是一个命令能解决的。它需要先检查状态，再判断风险，再做小范围修改，最后验证结果。失败时不能盲目重试，而要读错误、看日志、追数据流。解决完以后，还要把这次经验变成下次能复用的流程。
这也是我后来转向 Hermes 的核心原因。
OpenClaw 和 Hermes 的差异，不只是名字从虾变成马
如果简单说，OpenClaw 更像一个个人 AI 助手框架，Hermes 更像一个可以长期训练的个人 Agent 操作系统。
这句话听起来有点大，但放到实际使用里，差异很明显。
第一，Hermes 更强调 Skills。
Skills 不是普通提示词，也不是一堆随手写的备忘录。它更像给 Agent 准备的工作手册：什么时候使用、具体步骤是什么、常见坑在哪里、最后要怎么验证。比如 GitHub PR 工作流、VPS 资源审计、Web UI 排障、MCP 配置、浏览器登录栈处理，都可以被写成一个个 SKILL.md。
这件事很重要。因为我不想每次都教它同一套流程。
如果把 OpenClaw 比作虾，它可以伸出钳子帮我夹起一些任务；那 Hermes 更像马。马不是一次性工具，它需要训练。训练过以后，它会记住路线、理解节奏，知道什么时候快跑，什么时候停下来等主人确认。
第二，Hermes 更强调 memory 和边界。
长期使用 Agent，最怕的不是它不会做事，而是它太自信、太积极、太容易忘。Hermes 的 memory 可以记录稳定事实和用户偏好，比如我的服务器环境、常用路径、写作风格、排障习惯、哪些事情必须先确认。
这类记忆不是为了让 Agent 表演“懂我”，而是为了减少沟通成本和危险误判。
更关键的是边界感。读日志、查端口、看配置、做健康检查，这些低风险动作可以直接做；删除数据、重装服务、改防火墙、动账号密钥、清浏览器登录态，就必须先问。一个能长期陪你工作的 Agent，必须知道什么时候主动，什么时候克制。
第三，Hermes 的扩展层更完整。
CLI、Web UI、Gateway、Skills、Memory、MCP、Cron、Subagent、工具集、Profile，这些东西单独看都不稀奇，但组合起来就变成了一个可以慢慢扩展的工作台。
我可以在终端里让它查服务器，也可以在 Web UI 里写文章；可以让它定时阅读信息源，也可以把复杂任务拆给子 Agent；可以为某个项目写 AGENTS.md，也可以把跨项目经验沉淀成 Skill；可以把一次排障变成下次自动加载的流程。
这就是养虾和养马的区别。
虾适合做眼前的小动作，马适合跑长期路线。如果你只是偶尔查一下、点一下、自动化一个小环节，养虾也许够用。但如果你希望 Agent 进入你的个人工作系统，帮你长期管理服务器、研究资料、写文章、做自动化、复盘经验，那我更愿意开始养马。
我真正关心的四件事
迁移到 Hermes 以后，我最关心的不是“功能是不是更多”，而是四件更朴素的事。
第一，能不能少重复解释。
我希望它知道我的环境，不要每次从零开始。比如我的网站在哪里，Hermes 服务监听什么端口，哪些历史工具已经卸载，哪些路径不能乱碰。这些稳定事实应该进入 memory，而不是每次靠我口头补充。
第二，能不能先查证再行动。
一个 Agent 是否可靠，要看它失败时怎么做。差的 Agent 会猜，会重试，会用一个更大的动作掩盖问题。好的 Agent 会先读错误、看日志、检查状态，找到最小修复点，然后验证结果。对 VPS、Web UI、自动化任务来说，这个习惯比模型本身聪不聪明更重要。
第三，能不能把经验沉淀下来。
解决一次问题只是临时收益。把这次问题变成下次可复用的 Skill，才是长期收益。比如“如何处理 linux.do 这类 Cloudflare 页面”“如何排查 Web UI 上下文丢失”“如何给文章后台加回收站”，这些都不应该只存在一次聊天记录里。
第四，能不能保留人的控制权。
我不想要一个什么都敢自动做的 Agent。账号、密钥、删除、迁移、公开发布，这些动作都应该保留确认。好的 Agent 不是替人取消判断，而是把判断前的资料、路径、风险和验证结果整理清楚。
这点和我之前做知识库时的想法类似：读可以自动一点，写要慢一点；整理可以快一点，真正落库要稳一点。
开始养马：我的 Hermes 入门教程
如果你也想从 OpenClaw 转向 Hermes，我不建议一上来就追求全功能。更稳的方式，是先跑通一个最小闭环，再逐步扩展。
第一步，安装并体检
在 Linux 或 VPS 上，可以先用官方安装脚本安装 Hermes：
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash安装完以后，不要急着改一堆配置。先跑：
hermes doctor这个命令会检查依赖、配置和环境。很多问题不要靠猜，先让系统自己体检一遍。
然后进入初始化：
hermes setup这里主要配置模型 provider、API key、默认模型和终端执行方式。我的建议是，先选一个稳定可用的模型，不要一开始就把十几个 provider 都接上。Agent 的稳定性比模型列表好看更重要。
第二步，先用 CLI，不要急着上 Web UI
刚开始可以直接进入命令行对话：
hermes也可以单次提问：
hermes chat -q "帮我检查一下当前系统信息"我建议先在 CLI 里跑通。CLI 的反馈更直接，排障也简单。你可以先让它做几类低风险任务：检查系统版本、查看磁盘空间、列出监听端口、总结某个项目目录结构。
这些任务可以帮你确认三件事：模型是否能正常回答，工具是否能正常调用，Agent 是否会先检查再下结论。
第三步，开启必要工具集
Hermes 的能力来自 toolsets。可以先查看：
hermes tools list我的基础组合通常是：
terminal：查系统、跑命令、部署服务；file：读写文件、搜索内容、打补丁；web：搜索和抓取网页；skills：加载和管理技能；memory：保存稳定偏好和环境事实；session_search：回忆过去会话；delegation：把复杂任务拆给子 Agent。
不要一开始把所有工具都打开。工具越多，Agent 越强，但也越需要边界。先打开你真的会用的部分。
第四步，建立第一批 memory
Memory 不适合当日记用。不要把“今天修了某个 bug”“某个 PR 已提交”这种会过期的信息塞进去。
适合记的，是长期事实：服务器系统版本、常用服务端口、项目路径、个人偏好、风险边界。比如“用户偏好中文技术排障”“用户不喜欢复制很长命令”“OpenClaw 已卸载，不要默认假设相关服务存在”。
一个简单判断标准是：如果这个信息一周后就可能过期，不要进 memory；如果它是一套步骤，应该写成 Skill；如果只是本次任务进度，就留在会话里。
第五步，用 Skills 训练你的马
Skills 是 Hermes 最值得投入的部分。
你可以把常见任务写成技能：VPS 资源审计、Web UI 排障、GitHub PR 工作流、Linux.do 抓取、Obsidian 知识库整理、文章写作风格模板、OpenClaw 清理和迁移检查。
一个好的 Skill 不需要复杂，但要清楚：什么时候使用、具体步骤、常见坑、验证方式。
比如我现在经常写这种偏“真实试用 + 工作流复盘 + 可落地步骤”的文章，就可以沉淀一个网站文章风格 Skill。以后写文章时，Agent 不需要每次重新理解：不要营销腔，不要只写概念，要先讲真实原因，再讲对比，再给教程，最后复盘。
第六步，再接 Web UI 或消息平台
CLI 稳了以后，再考虑 Web UI、Telegram、Discord 等入口。Web UI 适合日常聊天和长文协作，但如果底层 Hermes 没配好，它只会把问题藏起来。
我的顺序是：先 CLI 跑通，再确认工具正常，再确认 memory 正常，再确认 skills 能加载，最后接 Web UI 或消息平台。
如果 Web UI 出现“看起来发出去了但没有回复”“上下文丢了”“上一轮消息没带上”的情况，不要急着重装。先看服务日志、API 健康检查、环境变量和 session 同步。Agent 系统最怕盲目重装，很多问题其实只是一个配置项或会话映射错了。
最后：从工具到工作流
我放弃养虾，不是因为 OpenClaw 完全没用。它代表了一类很有吸引力的个人 AI 助手：开放、可部署、能接平台、能做事。对很多轻量场景，它已经够用。
但我现在需要的东西变了。
我需要的不是一个每次重新认识我的助手，而是一个能长期积累经验的操作伙伴。它要知道我的服务器环境，知道我的文章风格，知道我不喜欢长命令，知道哪些服务不能乱动，知道遇到问题先查证，知道复杂任务要拆开，知道解决完以后要沉淀成技能。
Hermes 更接近这个方向。
养虾像是在水缸里放一个聪明的小东西，它能动、能夹、能带来乐趣。养马则不一样。马需要训练，需要喂养，需要路线，也需要缰绳。但一旦它理解你的节奏，就能陪你跑更远的路。
所以这次迁移对我来说，不只是从 OpenClaw 到 Hermes。
它更像是我对个人 AI Agent 的理解变了：从追求“它能不能自动做事”，变成追求“它能不能和我一起形成稳定、可复盘、可进化的工作流”。
这就是我为什么放弃养虾，开始养马。