首页 › 智能体/知识库 › OpenClaw vs Hermes Agent

张连仲 發表於 2026-4-26 21:32:00

OpenClaw vs Hermes Agent

<h2 id="1概述">1.概述</h2>
<p>如果你是刚开始接触 AI Agent 的开发者，最容易踩进一个坑：把“会聊天的大模型”误当成“能持续工作的代理系统”。</p>
<p>这两者不是一回事。</p>
<p>大模型更像一个会推理、会生成文本的“大脑”；而一个真正能落地的 Agent，至少还需要下面几层东西：</p>
<ol>
<li>工具系统：让模型不只是“会说”，还要“会做”，比如读文件、跑命令、搜网页、发消息、调用浏览器。</li>
<li>会话系统：让代理知道当前任务进行到哪一步，而不是每次都像第一次见你。</li>
<li>记忆系统：让代理把长期偏好、项目背景、历史决策存下来。</li>
<li>权限系统：让代理在执行高风险动作前有边界，避免“会做事”变成“乱做事”。</li>
<li>运行时与入口：让代理能在 CLI、网页、Telegram、WhatsApp、Discord 等不同入口稳定工作。</li>
</ol>
<p>OpenClaw 和 Hermes Agent，正是这类“真正能跑起来”的开源 Agent 系统里，近阶段很值得比较的两个项目。</p>
<p>它们的相似之处很多：</p>
<ul>
<li>都是自托管、开源、强调可控性。</li>
<li>都支持多模型接入，而不是把自己绑死在单一厂商上。</li>
<li>都不满足于“问答”，而是强调工具调用、上下文、会话、长期使用。</li>
<li>都支持技能（skills）扩展，并且都和 AgentSkills 生态兼容。</li>
<li>都在朝“常驻型、长期在线、可跨端访问”的代理形态演进。</li>
</ul>
<p>但它们的设计重心并不一样。</p>
<p>用一句最通俗的话概括：</p>
<ul>
<li>OpenClaw 更像“把所有聊天入口接到一个 AI 助理上的网关平台”。</li>
<li>Hermes Agent 更像“一个会持续成长、会自我积累经验的常驻型代理运行时”。</li>
</ul>
<p>这篇文章的目标，不是简单下结论说谁强谁弱，而是帮你把下面几个问题真正想清楚：</p>
<ul>
<li>它们各自解决的核心问题是什么？</li>
<li>它们的架构为什么长成现在这个样子？</li>
<li>初学者到底该先上哪一个？</li>
<li>做个人助理、开发自动化、长期知识代理、消息机器人时，哪个更顺手？</li>
<li>从未来 1 到 2 年的趋势看，它们分别可能走向哪里？</li>
</ul>
<h2 id="2内容">2.内容</h2>
<h3 id="简要介绍为什么-openclaw-和-hermes-agent-会被放在一起比较">简要介绍：为什么 OpenClaw 和 Hermes Agent 会被放在一起比较？</h3>
<p>原因很简单：它们面向的是一批高度重叠的用户。</p>
<p>这批用户通常有下面几类需求：</p>
<ul>
<li>我想要一个随时能从手机上联系到的 AI 助手。</li>
<li>我不只想让它回答问题，还想让它帮我执行任务。</li>
<li>我希望它记住我的习惯、项目、工作流。</li>
<li>我不想被某一家模型厂商锁死。</li>
<li>我希望它能长期跑在我的机器、服务器或 VPS 上。</li>
</ul>
<p>从官方文档能看出，两者虽然切入点不同，但正在覆盖同一片版图。更有意思的是，Hermes 官方甚至直接提供了从 OpenClaw 迁移的命令 <code>hermes claw migrate</code>，这本身就说明：两者并不是毫无交集的两个世界，而是同一赛道上的两种设计哲学。</p>
<p>下面先分别看它们各自是什么，再进入真正有价值的对比。</p>
<h3 id="21-openclaw-是什么">2.1 OpenClaw 是什么？</h3>
<p>按照 OpenClaw 官方仓库与官方文档的描述，它是一个<strong>运行在你自己设备上的个人 AI 助理</strong>，同时也是一个<strong>把多种消息渠道连接到代理运行时的自托管 Gateway</strong>。</p>
<p>OpenClaw 的官方文档里，有几个关键词非常关键：</p>
<ul>
<li>它强调自己是 <code>self-hosted gateway</code>。</li>
<li>它强调你可以继续在现有聊天渠道里和代理对话，而不必重新学习一个新界面。</li>
<li>它强调 Gateway 是“控制平面”，真正的产品是那个始终在线、可跨渠道访问的个人助理。</li>
</ul>
<p>如果把 OpenClaw 用非常白话的话来解释，它更像下面这个模型：</p>
<p>你不是在“打开一个 AI App”；你是在“把 社交软件、Web 控制台、移动节点等入口，全部接到同一个 AI 助理上”。这个 AI 助理后面有工作区、技能、会话、记忆和工具，而 Gateway 负责把这些入口统一起来。</p>
<p>这带来几个非常鲜明的特点：</p>
<ol>
<li>
<p>它是“消息入口优先”的。<br>
你可以把它理解成一个 AI 总机。不同聊天入口、不同账号、不同设备，都可以通过 Gateway 汇到同一套系统里。</p>
</li>
<li>
<p>它是“个人助理优先”的。<br>
OpenClaw 的安全模型官方就明确写了，它默认假设一个 Gateway 对应一个可信的个人边界，而不是拿来做 hostile multi-tenant 的多租户对抗式平台。</p>
</li>
<li>
<p>它非常强调“可见、可编辑、可控”。<br>
比如记忆不是藏在黑盒数据库里，而是直接写成 Markdown 文件；技能也是 <code>SKILL.md</code>；很多配置都能直接在工作区和本地目录里看到。</p>
</li>
<li>
<p>它天然适合“手机里能随时找到的助手”。<br>
你不一定总在终端里，也不一定总在 IDE 里，但你一定经常在消息应用里。OpenClaw 选择先占住这个入口。</p>
</li>
</ol>
<p>对初学者来说，OpenClaw 最好理解的一点是：<strong>它首先是一个把 Agent 带进日常通信渠道的系统，然后才是一个可扩展的代理框架。</strong></p>
<h3 id="22-hermes-agent-是什么">2.2 Hermes Agent 是什么？</h3>
<p>Hermes Agent 的官方定位则明显不同。官方主页第一句话就很直接：它是 Nous Research 构建的 <strong>self-improving AI agent</strong>，也就是“会自我改进的 AI 代理”。</p>
<p>Hermes 最有辨识度的几个关键词是：</p>
<ul>
<li>built-in learning loop：内建学习闭环</li>
<li>persistent memory：持久记忆</li>
<li>session search：跨会话检索</li>
<li>cron：定时任务</li>
<li>subagent delegation：子代理委派</li>
<li>MCP integration：MCP 工具生态接入</li>
</ul>
<p>如果也用一句白话来解释 Hermes：</p>
<p>它不像“一个多消息入口的 AI 助手”，而更像“一个常驻在你机器或服务器上的智能工作体”。你给它任务，它不仅能做，还会逐渐把经验、偏好、上下文和技能沉淀下来，让自己在长期使用中变得更像一个成熟的助手，而不是每次都重新开始。</p>
<p>Hermes 的几个明显特征是：</p>
<ol>
<li>
<p>它是“运行时优先”的。<br>
也就是说，它更关心代理本身如何工作、如何记忆、如何委派、如何自动化、如何跨环境运行。</p>
</li>
<li>
<p>它是“长期在线优先”的。<br>
官方文档反复强调它不需要绑在你的笔记本上，可以运行在 $5 VPS、GPU 集群、Daytona、Modal 等环境里。</p>
</li>
<li>
<p>它是“闭环学习优先”的。<br>
不是只有工具调用，而是强调：做过的事情能不能积累为技能？长期偏好能不能沉淀成记忆？过去会话能不能检索回来？</p>
</li>
<li>
<p>它是“自动化优先”的。<br>
Cron、委派、并行子代理、MCP、外部记忆提供器、上下文文件自动加载，这些都说明它的目标不只是聊天，而是构建一个长期运行的智能工作流系统。</p>
</li>
</ol>
<p>对于初学者，Hermes 最重要的一句话理解是：<strong>它不是先解决“怎么联系到代理”，而是先解决“代理如何长期稳定地成长和工作”。</strong></p>
<h3 id="23-它们为什么值得比较">2.3 它们为什么值得比较？</h3>
<p>因为很多人第一次做 Agent 时，真正纠结的不是“能不能装上”，而是“应该先围绕哪种心智模型去搭系统”。</p>
<p>这两种心智模型分别是：</p>
<ul>
<li>入口优先：先把消息渠道、交互触点、设备接入做对，让代理能随时被叫到。</li>
<li>运行时优先：先把记忆、工具、自动化、委派、长期运行做对，让代理真能持续完成复杂工作。</li>
</ul>
<p>OpenClaw 明显更偏前者，Hermes 明显更偏后者。</p>
<p>为了让这个差异更直观，可以先看一张总表：</p>
<table>
<thead>
<tr>
<th>维度</th>
<th>OpenClaw</th>
<th>Hermes Agent</th>
<th>对初学者意味着什么</th>
</tr>
</thead>
<tbody>
<tr>
<td>设计中心</td>
<td>Gateway 与多渠道接入</td>
<td>AIAgent 运行时与学习闭环</td>
<td>前者更像“入口平台”，后者更像“智能执行内核”</td>
</tr>
<tr>
<td>主要使用姿势</td>
<td>从消息应用、Control UI、节点访问</td>
<td>从 CLI/TUI、Gateway、Cron、子代理访问</td>
<td>OpenClaw 更贴近日常通信，Hermes 更贴近长期自动化</td>
</tr>
<tr>
<td>记忆模型</td>
<td>工作区 Markdown 记忆为主，透明可编辑</td>
<td><code>MEMORY.md</code> + <code>USER.md</code> + Session Search + 外部记忆提供器</td>
<td>OpenClaw 更直观，Hermes 更系统化</td>
</tr>
<tr>
<td>技能模型</td>
<td>AgentSkills 兼容，支持多层目录加载</td>
<td>AgentSkills 兼容，集中在 <code>~/.hermes/skills/</code>，可自动创建和改进</td>
<td>Hermes 在“技能闭环”上更激进</td>
</tr>
<tr>
<td>自动化能力</td>
<td>有路由、多代理、节点、工具体系</td>
<td>有 Cron、子代理、并行委派、代码执行、MCP</td>
<td>Hermes 更像自动化工作平台</td>
</tr>
<tr>
<td>安全思路</td>
<td>单人可信边界、配对白名单、Exec 审批</td>
<td>七层防御、命令审批、容器隔离、MCP 过滤</td>
<td>Hermes 的安全分层更系统化</td>
</tr>
<tr>
<td>最适合的人</td>
<td>想先把 AI 助理接进日常消息入口的人</td>
<td>想搭长期运行、可学习、可自动化代理的人</td>
<td>选错入口，后续维护成本会明显变高</td>
</tr>
</tbody>
</table>
<hr>
<h2 id="3原理架构与核心机制对比">3.原理、架构与核心机制对比</h2>
<h3 id="31-openclaw为什么它会长成一个-gateway-中心架构">3.1 OpenClaw：为什么它会长成一个 Gateway 中心架构？</h3>
<p>OpenClaw 的官方文档里，有一条几乎可以当成“设计宣言”的描述：<strong>Gateway 是 sessions、routing 和 channel connections 的 single source of truth</strong>。</p>
<p>这句话非常关键，因为它决定了 OpenClaw 的整体长相。</p>
<h4 id="311-openclaw-的核心原理">3.1.1 OpenClaw 的核心原理</h4>
<p>OpenClaw 的思路不是“让每个入口各自跑一份代理”，而是“让所有入口都连接到同一个长期运行的 Gateway，再由 Gateway 统一维护会话、路由和连接状态”。</p>
<p>这样做的好处非常现实：</p>
<ol>
<li>
<p>多渠道不会各玩各的。<br>
你可以从 Telegram 找它，也可以从 Web 控制台找它，甚至通过节点设备找它，但对底层系统来说，这些都是同一个总入口体系。</p>
</li>
<li>
<p>统一会话与身份边界。<br>
一旦 Gateway 成为状态中心，谁在和代理说话、消息来自哪个渠道、应该路由给哪个 agent、要不要配对、是否允许执行某类操作，都能在一个中枢做决策。</p>
</li>
<li>
<p>更适合个人助理场景。<br>
个人助理的典型特征不是“单次推理很强”，而是“我随时能找到它，而且它能在多个入口保持一致”。OpenClaw 的架构正是为这个需求定制的。</p>
</li>
</ol>
<h4 id="312-openclaw-的组件关系">3.1.2 OpenClaw 的组件关系</h4>
<p>用图来看会更直观：</p>
<div class="mermaid">flowchart LR
    U1[用户: Telegram / WhatsApp / Discord]
    U2[用户: Web Control UI / CLI]
    N[节点: iOS / Android / macOS]
    G
    A
    W
    T
    M[模型提供商]

    U1 --&gt; G
    U2 --&gt; G
    N --&gt; G
    G --&gt; A
    A --&gt; W
    A --&gt; T
    A --&gt; M
</div><p>这个图的重点不是“它也有模型、也有工具”，而是：<strong>所有外部入口先汇入 Gateway，再由 Gateway 组织后面的代理能力。</strong></p>
<p>从官方 Gateway 架构文档可以提炼出几条重要事实：</p>
<ul>
<li>单个长期运行的 Gateway 负责所有消息表面。</li>
<li>Control-plane 客户端（macOS app、CLI、Web UI、自动化程序）通过 WebSocket 连到 Gateway。</li>
<li>节点设备也通过 WebSocket 接入，但会带上自己的 <code>role: node</code> 与能力声明。</li>
<li>默认绑定地址是 <code>127.0.0.1:18789</code>。</li>
</ul>
<p>对初学者来说，这意味着一个非常重要的认知：</p>
<p><strong>OpenClaw 的“主语”不是某个聊天窗口，而是 Gateway 这个长期运行的中枢。</strong></p>
<h4 id="313-openclaw-的多代理与工作区隔离">3.1.3 OpenClaw 的多代理与工作区隔离</h4>
<p>很多人一看到“个人助理”会误以为它只能单体使用，但 OpenClaw 官方文档明确支持 Multi-Agent Routing。</p>
<p>它的多代理设计不是在一个上下文里塞很多 persona，而是：</p>
<ul>
<li>每个 agent 有自己的 workspace。</li>
<li>每个 agent 有自己的 <code>agentDir</code>。</li>
<li>每个 agent 有自己的 sessions 存储。</li>
<li>不同渠道、账号、发送者可以通过 bindings 路由到不同 agent。</li>
</ul>
<p>这点很值得肯定，因为它符合工程上的一个基本原则：<strong>隔离比提示词伪装更可靠。</strong></p>
<p>也就是说，OpenClaw 不是靠“你现在假装自己是 A，现在又假装自己是 B”来扮演多个助理，而是给每个 agent 单独的工作区、技能、会话与认证边界。</p>
<p>对初学者的启发是：</p>
<ul>
<li>如果你只想要一个自己的随身助理，默认单 agent 就够了。</li>
<li>如果你想把“生活助理”“工作助理”“内容助理”拆开，OpenClaw 已经提供了比较干净的隔离思路。</li>
</ul>
<h4 id="314-openclaw-的记忆模型为什么对新手友好">3.1.4 OpenClaw 的记忆模型为什么对新手友好？</h4>
<p>OpenClaw 的记忆设计很“朴素”，但这恰恰是它好理解的地方。</p>
<p>官方文档说明它的记忆直接写在工作区的 Markdown 文件里，核心包括：</p>
<ul>
<li><code>MEMORY.md</code>：长期记忆</li>
<li><code>memory/YYYY-MM-DD.md</code>：每日上下文</li>
<li><code>DREAMS.md</code>：可选的 Dream Diary / 总结层</li>
</ul>
<p>这有两个非常大的优点：</p>
<ol>
<li>
<p>可审计。<br>
你能直接打开文件看代理到底记了什么，而不是只能猜。</p>
</li>
<li>
<p>可修正。<br>
如果代理记错了，或者你想重新整理长期背景，直接改 Markdown 即可。</p>
</li>
</ol>
<p>这类设计特别适合刚上手 Agent 的人，因为你能把“记忆”当成真实文件系统来理解，而不是抽象的 embedding 魔法。</p>
<p>当然，它不是没有代价。代价是：</p>
<ul>
<li>需要你更主动地维护工作区质量。</li>
<li>当规模继续扩大时，单纯文件记忆可能不如更系统的检索/外部记忆架构灵活。</li>
</ul>
<p>但对于“先把个人助理跑起来”这件事，它非常实用。</p>
<h4 id="315-openclaw-的工具技能插件三层模型">3.1.5 OpenClaw 的工具、技能、插件三层模型</h4>
<p>OpenClaw 官方文档把能力拆成三层，这个拆法非常清晰：</p>
<ol>
<li>Tools：代理真正调用的能力，比如 <code>exec</code>、<code>browser</code>、<code>web_search</code>、<code>message</code>。</li>
<li>Skills：通过 <code>SKILL.md</code> 教代理“什么时候、如何用工具”。</li>
<li>Plugins：把渠道、工具、技能、搜索、媒体理解等能力打包起来。</li>
</ol>
<p>这个拆分很重要，因为很多初学者会把“工具”和“技能”混成一回事。</p>
<p>实际上：</p>
<ul>
<li>工具决定“能不能做”。</li>
<li>技能决定“知不知道什么时候该这样做”。</li>
<li>插件决定“怎么把多种能力装配成一个可扩展系统”。</li>
</ul>
<p>从工程角度讲，OpenClaw 的这个分层相当健康。它让你可以：</p>
<ul>
<li>不改核心代码，只加技能。</li>
<li>不改技能，只换工具策略。</li>
<li>不改主程序，只通过插件扩渠道或扩能力。</li>
</ul>
<h4 id="316-openclaw-的安全模型为什么它强调个人可信边界">3.1.6 OpenClaw 的安全模型：为什么它强调“个人可信边界”？</h4>
<p>OpenClaw 官方安全文档写得很直白：它默认假设一个 Gateway 对应一个 trusted operator boundary，也就是一个可信的个人边界，而不是面向互相敌对用户的共享多租户安全边界。</p>
<p>这句话很多人会忽略，但它其实是在帮你避免严重误用。</p>
<p>它的意思是：</p>
<ul>
<li>用它给自己搭个人助理，很合适。</li>
<li>用它给一个小团队中彼此信任的人搭工具，也可能可以。</li>
<li>但如果你想让互不信任的多个用户共用同一套代理与凭据，那就超出它的默认安全假设了。</li>
</ul>
<p>OpenClaw 在保护措施上也不是没有动作。它至少有几层关键保护：</p>
<ul>
<li>DM pairing：陌生发送者需要显式配对。</li>
<li>Node pairing：新节点接入需要审批。</li>
<li>Exec approvals：代理要在真实宿主机执行命令时，需要策略、白名单与用户审批共同允许。</li>
<li>Sandboxing：可以把代理运行在隔离的 sandbox runtime 中。</li>
</ul>
<p>这里最值得初学者记住的一点是：</p>
<p><strong>OpenClaw 的安全思路，不是把风险假装不存在，而是承认“个人助理天然高权限”，所以要通过 pairing、审批和沙箱把风险关进笼子里。</strong></p>
<h4 id="317-一句话总结-openclaw-的架构气质">3.1.7 一句话总结 OpenClaw 的架构气质</h4>
<p>如果非要给 OpenClaw 的架构气质下一个定义，我会这样说：</p>
<p><strong>它不是先发明一个最“聪明”的代理大脑，而是先搭一个最适合“让助理真正进入你生活和工作入口”的基础设施。</strong></p>
<p>这也是为什么它对“消息入口”“节点接入”“会话路由”“工作区可见性”如此上心。</p>
<hr>
<h3 id="32-hermes-agent为什么它会长成一个自学习运行时">3.2 Hermes Agent：为什么它会长成一个“自学习运行时”？</h3>
<p>如果说 OpenClaw 的设计起点是“入口与中枢”，那 Hermes Agent 的设计起点几乎相反：它关心的是<strong>代理长期运行时，内部到底如何积累、调用、自动化与扩展</strong>。</p>
<h4 id="321-hermes-的核心原理">3.2.1 Hermes 的核心原理</h4>
<p>Hermes 的设计核心，可以概括为一句话：</p>
<p><strong>代理不是一次性的聊天回合，而是一个会不断沉淀能力、维持状态并自主运行的长期系统。</strong></p>
<p>从 Hermes 官方文档里能看到它非常强调几个能力闭环：</p>
<ul>
<li>长期记忆闭环</li>
<li>技能生成与复用闭环</li>
<li>会话检索闭环</li>
<li>定时任务闭环</li>
<li>子代理委派闭环</li>
<li>MCP 扩展闭环</li>
</ul>
<p>换句话说，Hermes 把 Agent 看成一个长期演化的“软件主体”，而不是简单的消息机器人。</p>
<h4 id="322-hermes-的系统骨架">3.2.2 Hermes 的系统骨架</h4>
<p>Hermes 的官方架构文档给出的核心非常明确：一个统一的 <code>AIAgent</code> 类服务于 CLI、Gateway、ACP、Batch、API Server 等多个入口。</p>
<p>这意味着 Hermes 的重心不是入口本身，而是<strong>把不同入口都接到同一个运行时核心</strong>。</p>
<p>可以用下面这张图来理解：</p>
<div class="mermaid">flowchart LR
    U[用户: CLI / TUI / Telegram / Discord]
    GW
    AI
    PT
    TS
    ENV
    MEM
    SK
    CR[ Cron / Delegation ]
    M[模型提供商]

    U --&gt; GW
    U --&gt; AI
    GW --&gt; AI
    AI --&gt; PT
    AI --&gt; TS
    TS --&gt; ENV
    AI --&gt; MEM
    AI --&gt; SK
    GW --&gt; CR
    CR --&gt; AI
    AI --&gt; M
</div><p>这张图里最关键的不是模块多，而是模块之间的职责边界更“运行时化”：</p>
<ul>
<li>Prompt system 负责系统提示构建。</li>
<li>Tool registry 负责工具发现、调度和可用性判定。</li>
<li>Session persistence 负责会话与历史检索。</li>
<li>Gateway 只是一个入口，不是唯一主角。</li>
<li>Cron 与 delegation 都是一等公民，而不是外挂脚本。</li>
</ul>
<h4 id="323-hermes-为什么更像代理操作系统">3.2.3 Hermes 为什么更像“代理操作系统”？</h4>
<p>Hermes 官方架构文档里，有几个设计原则特别能说明问题：</p>
<ul>
<li>Prompt stability：系统提示在会话中途不随意变化，避免破坏缓存与稳定性。</li>
<li>Observable execution：每一次工具调用尽量可观察。</li>
<li>Interruptible：执行过程可中断。</li>
<li>Platform-agnostic core：同一个 AIAgent 核心服务多个平台入口。</li>
<li>Profile isolation：不同 profile 拥有独立的配置、记忆、会话和 gateway PID。</li>
</ul>
<p>这类原则其实已经很接近“操作系统级运行时”的思路了。</p>
<p>一个成熟的 Agent 系统，最终都得面对这些问题：</p>
<ul>
<li>执行中能不能打断？</li>
<li>同一套核心能不能服务多个入口？</li>
<li>多个工作身份能不能隔离？</li>
<li>记忆写入后会不会破坏当前会话稳定性？</li>
<li>工具注册是不是足够规范？</li>
</ul>
<p>Hermes 没有回避这些问题，而是把它们提升成一等设计对象。</p>
<p>这也是为什么很多开发者第一次用 Hermes，会感觉它不像“一个 bot”，而像“一个给 Agent 设计的操作环境”。</p>
<h4 id="324-hermes-的工具系统为什么更适合重自动化">3.2.4 Hermes 的工具系统为什么更适合重自动化？</h4>
<p>官方架构文档里明确提到，Hermes 有 <strong>47 个注册工具、19 个 toolsets</strong>，并且支持 <strong>6 种终端后端</strong>：</p>
<ul>
<li>local</li>
<li>Docker</li>
<li>SSH</li>
<li>Daytona</li>
<li>Singularity</li>
<li>Modal</li>
</ul>
<p>这个数字本身不是重点，重点是它背后的工程含义：</p>
<ol>
<li>
<p>工具不是临时拼接的。<br>
它们通过统一注册表进行发现、调度和错误包装。</p>
</li>
<li>
<p>执行环境是可切换的。<br>
你今天在本地跑，明天切到 Docker，后天切到远端 SSH 或 Modal，不需要重写代理概念层。</p>
</li>
<li>
<p>工具集合可以按场景收缩。<br>
这对安全尤其重要。不是所有场景都该把所有工具开满。</p>
</li>
</ol>
<p>对于初学者，这里要理解的重点不是“47 比 20 更强”，而是：</p>
<p><strong>Hermes 把“代理能做什么”这件事，做成了一个结构化的系统，而不是一堆散装命令。</strong></p>
<h4 id="325-hermes-的记忆系统为什么更分层">3.2.5 Hermes 的记忆系统为什么更“分层”？</h4>
<p>Hermes 的官方文档把记忆明确拆成了几层：</p>
<ol>
<li>
<p><code>MEMORY.md</code><br>
记录环境事实、项目约定、经验教训。</p>
</li>
<li>
<p><code>USER.md</code><br>
记录用户偏好、沟通习惯、身份信息。</p>
</li>
<li>
<p>Session Search<br>
所有 CLI 与消息会话进入 SQLite，并支持 FTS5 全文搜索与总结。</p>
</li>
<li>
<p>External Memory Providers<br>
还可以外挂额外的记忆提供器。</p>
</li>
</ol>
<p>这说明 Hermes 的记忆观不是“只要长期记一点东西就够了”，而是：</p>
<ul>
<li>有些信息必须始终在 prompt 里，属于高价值小体积记忆。</li>
<li>有些信息不该常驻，但应当可检索。</li>
<li>有些信息需要交给更外部化、更结构化的记忆系统处理。</li>
</ul>
<p>同时，Hermes 特别强调一个点：<strong>memory 是 frozen snapshot</strong>。</p>
<p>也就是说：</p>
<ul>
<li>会话开始时，记忆会被注入系统提示。</li>
<li>会话中如果新写入记忆，会马上落盘。</li>
<li>但这段新记忆不会立刻重写当前系统提示，而是留到下一个会话再生效。</li>
</ul>
<p>这背后的目的，是保持 prompt 稳定和缓存收益。</p>
<p>对初学者来说，这种设计虽然比 OpenClaw 的文件记忆更复杂，但它更接近一个成熟代理系统在长期使用中的真实需求：<strong>不是只要“记住”，还要“记得稳”“记得省”“记得可搜索”。</strong></p>
<h4 id="326-hermes-的技能系统为什么更像过程知识库">3.2.6 Hermes 的技能系统为什么更像“过程知识库”？</h4>
<p>Hermes 官方主页和技能文档都反复强调一件事：技能不是装饰，而是代理的<strong>procedural memory</strong>，也就是“过程型记忆”。</p>
<p>什么意思？</p>
<p>举个最简单的例子：</p>
<ul>
<li>记忆告诉代理：这个项目用的是 Rust。</li>
<li>技能告诉代理：在这个项目里，排查构建失败时先跑什么，再看哪里，再如何报告。</li>
</ul>
<p>Hermes 进一步强调：</p>
<ul>
<li>技能按需加载，减少 token 开销。</li>
<li>所有技能集中在 <code>~/.hermes/skills/</code>。</li>
<li>每个技能都可以作为 slash command 使用。</li>
<li>代理可以在解决复杂任务后生成新的技能，后续复用。</li>
</ul>
<p>这就是 Hermes 最有辨识度的地方之一：它想把“今天学到的做事方法”固化下来，而不只是把“今天聊过的内容”存下来。</p>
<h4 id="327-hermes-的-cron-与-delegation为什么它更适合长期自动化">3.2.7 Hermes 的 Cron 与 Delegation：为什么它更适合长期自动化？</h4>
<p>Hermes 的官方 Cron 文档很清楚地说明了两点：</p>
<ol>
<li>Cron 是一等功能，不是外部拼接脚本。</li>
<li>每个 Cron 任务都运行在 fresh agent session 里。</li>
</ol>
<p>这个设计非常成熟。</p>
<p>它避免了很多自动化系统的典型问题：</p>
<ul>
<li>上一次任务残留上下文污染下一次任务。</li>
<li>多次调度叠加成难以解释的行为。</li>
<li>脚本和代理逻辑割裂，维护体验差。</li>
</ul>
<p>Hermes 的 delegation 也同样体现了运行时思维：</p>
<ul>
<li>子代理拿到的是隔离上下文。</li>
<li>子代理有自己的终端会话。</li>
<li>父代理只接收最终摘要，而不是把所有中间过程都塞回主上下文。</li>
<li>最多并行 3 个子代理，控制复杂度。</li>
</ul>
<p>这意味着 Hermes 很适合做这类任务：</p>
<ul>
<li>并行调研多个主题</li>
<li>把大任务拆成多个独立分析流</li>
<li>用新上下文重新审视问题，避免主上下文偏见</li>
<li>把重复性复杂操作变成 Cron + Skills 组合</li>
</ul>
<p>如果你要搭的是“长期跑、持续产出、可调度、可拆分”的代理，Hermes 天生更占优势。</p>
<h4 id="328-hermes-的安全模型为什么更企业化">3.2.8 Hermes 的安全模型为什么更“企业化”</h4>
<p>Hermes 官方安全页把安全分成了七层：</p>
<ol>
<li>用户授权</li>
<li>危险命令审批</li>
<li>容器隔离</li>
<li>MCP 凭据过滤</li>
<li>上下文文件扫描</li>
<li>跨会话隔离</li>
<li>输入净化</li>
</ol>
<p>这是一种非常明显的 defense-in-depth 思路。</p>
<p>它不是假设某一道防线永远不会失败，而是假设：</p>
<ul>
<li>用户可能配错</li>
<li>工具可能被滥用</li>
<li>MCP 可能暴露过宽</li>
<li>工作目录和上下文文件都可能被注入</li>
</ul>
<p>所以需要多层叠加。</p>
<p>对于初学者，这里最重要的启示是：</p>
<p><strong>当一个代理越来越像“自动运行的数字员工”，安全就不再是附加项，而是架构本体。</strong></p>
<h4 id="329-一句话总结-hermes-的架构气质">3.2.9 一句话总结 Hermes 的架构气质</h4>
<p>如果也给 Hermes 下一个定义，我会这样说：</p>
<p><strong>它不是先考虑“你怎么找到代理”，而是先考虑“代理长期活着以后，如何记忆、调度、扩展、委派、复盘和成长”。</strong></p>
<p>这就是为什么 Hermes 看起来更像一个“代理操作系统”。</p>
<hr>
<h3 id="33-记忆技能工具与扩展两者最关键的机制差异">3.3 记忆、技能、工具与扩展：两者最关键的机制差异</h3>
<p>为了避免“看起来都支持，所以差不多”的误判，这里把最关键的机制差异拆开说。</p>
<h4 id="331-入口层差异">3.3.1 入口层差异</h4>
<p>OpenClaw 的入口层更强。</p>
<p>它天然以消息渠道、Control UI、节点设备为第一优先级。对很多人来说，真正的价值不是“这个 Agent 理论上可以做什么”，而是“我能不能在手机上 10 秒内找到它”。OpenClaw 抢的就是这 10 秒体验。</p>
<p>Hermes 的入口层也不弱，官方文档显示它支持 CLI、Telegram、Discord、Slack、WhatsApp、Signal、Email 等多个平台，但它的文档气质明显更偏“先把代理运行时跑稳，再扩入口”。</p>
<p>所以：</p>
<ul>
<li>如果你是交互触点优先，OpenClaw 更顺手。</li>
<li>如果你是运行闭环优先，Hermes 更顺手。</li>
</ul>
<h4 id="332-记忆层差异">3.3.2 记忆层差异</h4>
<p>OpenClaw 的记忆更透明、可手改、工作区导向。</p>
<p>Hermes 的记忆更分层、带容量控制、带会话搜索、还可外挂外部 provider。</p>
<p>这没有绝对优劣，关键看需求：</p>
<ul>
<li>想快速理解、手工修正、直接看文件：OpenClaw 更友好。</li>
<li>想长期积累、可检索、可扩展、可控 token 成本：Hermes 更成熟。</li>
</ul>
<h4 id="333-技能层差异">3.3.3 技能层差异</h4>
<p>两者都支持 AgentSkills，这是一个很大的共同点。</p>
<p>但 OpenClaw 更像“技能是工作区的一部分”；Hermes 更像“技能是代理成长机制的一部分”。</p>
<p>OpenClaw 在技能加载层次上更细，支持：</p>
<ul>
<li>额外目录</li>
<li>bundled skills</li>
<li><code>~/.openclaw/skills</code></li>
<li><code>~/.agents/skills</code></li>
<li>项目级 <code>.agents/skills</code></li>
<li>工作区 <code>skills/</code></li>
</ul>
<p>Hermes 则更集中，默认以 <code>~/.hermes/skills/</code> 为主源，并强调按需加载与 slash command 直达。</p>
<h4 id="334-自动化层差异">3.3.4 自动化层差异</h4>
<p>OpenClaw 擅长把代理变成一个随时可联系、可路由、可多入口访问的个人助理。</p>
<p>Hermes 更擅长把代理变成一个：</p>
<ul>
<li>会定时运行</li>
<li>会并行拆任务</li>
<li>会检索历史</li>
<li>会通过 MCP 扩展外部系统</li>
<li>会从经验中形成技能</li>
</ul>
<p>的长期自动化系统。</p>
<p>对很多工程团队来说，真正影响效率的不是“能不能回答一个问题”，而是“这个系统能不能自己稳定地做掉 30% 的重复工作”。在这一点上，Hermes 的答案更完整。</p>
<h4 id="335-工程心智差异">3.3.5 工程心智差异</h4>
<p>我建议你把它们分别记成两种比喻：</p>
<ul>
<li>OpenClaw = AI 助理总机</li>
<li>Hermes Agent = AI 代理运行时</li>
</ul>
<p>一旦这样记，很多选择就会变得清晰：</p>
<ul>
<li>我要的是“随时能联系到它”还是“长期能自己干活”？</li>
<li>我要的是“对话入口管理”还是“任务生命周期管理”？</li>
<li>我要的是“先上手跑起来”还是“先把长期系统打稳”？</li>
</ul>
<hr>
<h3 id="34-安全权限与风险控制选型时最容易被忽视的一环">3.4 安全、权限与风险控制：选型时最容易被忽视的一环</h3>
<p>很多比较文章喜欢谈模型、速度、功能，却不谈安全。实际上，对 Agent 系统来说，<strong>安全不是附属功能，而是决定它能否长期可用的基础设施。</strong></p>
<h4 id="341-openclaw-的安全哲学">3.4.1 OpenClaw 的安全哲学</h4>
<p>OpenClaw 的安全哲学很清楚：</p>
<ul>
<li>它假设你在做个人助理，而不是公有多租户平台。</li>
<li>它通过 pairing、allowlist、exec approvals、sandboxing 来控制风险。</li>
</ul>
<p>这种哲学的好处是非常务实：</p>
<ul>
<li>新手容易理解。</li>
<li>配置路径清晰。</li>
<li>安全措施和使用场景高度匹配。</li>
</ul>
<p>它的风险点在于：</p>
<ul>
<li>如果你忽略官方信任边界假设，强行把它拿去做复杂多租户共享，就会超出设计预期。</li>
<li>如果你把 Gateway 暴露出去，却没有做好白名单、pairing 和执行审批，风险会上升得很快。</li>
</ul>
<h4 id="342-hermes-的安全哲学">3.4.2 Hermes 的安全哲学</h4>
<p>Hermes 的安全哲学更偏“多层防御”和“长期运行风险控制”。</p>
<p>它关心的不只是：</p>
<ul>
<li>谁能发消息给代理</li>
</ul>
<p>还关心：</p>
<ul>
<li>这个命令是不是危险命令</li>
<li>这个 MCP 子进程能看到哪些环境变量</li>
<li>这个上下文文件是否存在注入问题</li>
<li>这个 cron 任务是否会递归制造更多 cron</li>
<li>这个会话的数据边界有没有被破坏</li>
</ul>
<p>这种设计更适合长期自动化系统，因为代理一旦开始：</p>
<ul>
<li>定时运行</li>
<li>访问外部系统</li>
<li>使用更多工具</li>
<li>和更多平台打通</li>
</ul>
<p>风险面就会迅速变宽。</p>
<h4 id="343-初学者应该如何理解安全成本">3.4.3 初学者应该如何理解“安全成本”？</h4>
<p>一句话：<strong>代理越有行动能力，安全边界就越重要。</strong></p>
<p>所以别只看“能不能自动发消息”“能不能自动跑命令”，还要看：</p>
<ul>
<li>谁批准？</li>
<li>在哪执行？</li>
<li>能访问哪些目录？</li>
<li>会不会误发？</li>
<li>失败了怎么停下来？</li>
</ul>
<p>从这个角度看：</p>
<ul>
<li>OpenClaw 更适合“先在个人边界内把事情跑顺”。</li>
<li>Hermes 更适合“从一开始就按长期自动化系统来治理”。</li>
</ul>
<hr>
<h2 id="4用途实践与前景">4.用途、实践与前景</h2>
<h3 id="41-openclaw-实战把聊天入口变成真正可用的随身-ai-助理">4.1 OpenClaw 实战：把聊天入口变成真正可用的随身 AI 助理</h3>
<p>这一节我们不搞空泛概念，直接给一个适合初学者的最小可行方案。</p>
<p>目标很简单：</p>
<p><strong>在自己的机器上启动 OpenClaw，打开 Control UI，并给它一套最基础的安全限制和博客写作技能。</strong></p>
<h4 id="411-安装与初始化">4.1.1 安装与初始化</h4>
<p>根据 OpenClaw 官方文档，推荐前提是 Node 24，Node 22.14+ 也支持。</p>
<p>你可以按下面的方式安装并初始化：</p>
<pre><code class="language-bash"># 方式一：使用官方安装脚本，适合大多数新手
curl -fsSL https://openclaw.ai/install.sh | bash

# 运行引导流程，自动配置模型提供商、Gateway 和基础环境
openclaw onboard --install-daemon

# 检查 Gateway 是否已经启动
openclaw gateway status

# 打开浏览器控制台，默认是本机 18789 端口
openclaw dashboard
</code></pre>
<p>如果你更习惯 npm 方式，也可以使用：</p>
<pre><code class="language-bash"># 这种方式适合你已经有稳定的 Node 环境
npm install -g openclaw@latest

# 初始化并安装后台服务
openclaw onboard --install-daemon
</code></pre>
<p>这一阶段你应该得到什么结果？</p>
<ul>
<li>本地有一个长期运行的 Gateway。</li>
<li>浏览器能打开 Control UI。</li>
<li>你已经配置好至少一个模型提供商。</li>
<li>你可以先在 Web 控制台里对话，再决定是否接 Telegram、WhatsApp 等渠道。</li>
</ul>
<h4 id="412-一份新手足够用的-openclaw-配置示例">4.1.2 一份新手足够用的 OpenClaw 配置示例</h4>
<p>下面给一份面向“个人助理”场景的最小配置示例：</p>
<pre><code class="language-json5">{
// 这个工作区会存放 AGENTS.md、MEMORY.md、skills 等文件
agents: {
    defaults: {
      workspace: "~/.openclaw/workspace"
    }
},

// 这里用飞书举例：私聊只允许白名单用户，群聊只允许指定群并要求 @ 提及
channels: {
    feishu: {
      // 私聊只允许白名单用户访问
      dmPolicy: "allowlist",
      allowFrom: ["ou_1234567890abcdef"],

      // 群聊只允许白名单群接入
      groupPolicy: "allowlist",
      groupAllowFrom: ["oc_group_chat:topic:om_topic_root"],

      // 群聊默认要求先 @ 机器人，减少误触发
      requireMention: true,

      // 也可以针对具体群单独覆写策略
      groups: {
      "oc_group_chat:topic:om_topic_root": {
          requireMention: true
      }
      }
    }
},

// 群聊里只有命中这些提及模式时才响应
messages: {
    groupChat: {
      // 这里保留统一群聊策略，便于后续扩展其他渠道
      mentionPatterns: ["@openclaw"]
    }
}
}
</code></pre>
<p>这份配置体现了 OpenClaw 的一条最佳实践：<strong>先缩小可触达范围，再逐步放开能力。</strong></p>
<p>很多人第一次玩 Agent，就急着把它接进所有渠道、所有群、所有联系人，最后不是误触发，就是风险不可控。正确做法正好相反：</p>
<ol>
<li>先只给自己用。</li>
<li>先只开一个渠道。</li>
<li>先只用白名单。</li>
<li>先只在明确提及时响应。</li>
</ol>
<h4 id="413-给-openclaw-加一个博客写作技能">4.1.3 给 OpenClaw 加一个博客写作技能</h4>
<p>OpenClaw 支持 AgentSkills 兼容技能。对内容创作者或技术博主来说，最有价值的不是“让代理自由发挥写文章”，而是把写作流程固化成技能。</p>
<p>你可以在工作区下创建：</p>
<p><code>~/.openclaw/workspace/skills/tech-blog-writer/SKILL.md</code></p>
<pre><code class="language-md">---
name: tech-blog-writer
description: 面向初学者整理技术博客，先讲结论，再讲原理，再给代码示例。
---

&lt;!-- 这个技能用于规范技术博客的输出流程 --&gt;
# Tech Blog Writer

## 何时使用
- 当用户给出一个技术主题，希望生成完整博客草稿时
- 当主题涉及多个方案对比，需要表格、示例和选型建议时

## 工作步骤
1. 先识别读者是谁：初学者、普通工程师，还是架构师
2. 先给结论，再讲原理，避免一上来堆背景知识
3. 如果涉及对比，必须输出对比表
4. 如果涉及工具或框架，至少给一个可运行示例
5. 结尾给出“适用场景、限制、风险”

## 输出约束
- 关键术语第一次出现时，用一句白话解释
- 避免空话和营销化表达
- 代码示例尽量短，并带必要注释
</code></pre>
<p>这个技能的价值不是“让模型更会写”，而是让代理知道：<strong>写一篇合格的技术博客，应该按什么流程输出。</strong></p>
<p>这也是 Agent 和普通聊天机器人的一个核心差异：</p>
<ul>
<li>普通聊天更像临场发挥。</li>
<li>Agent 技能更像把经验沉淀成可重复执行的方法。</li>
</ul>
<h4 id="414-给-openclaw-准备一份长期记忆">4.1.4 给 OpenClaw 准备一份长期记忆</h4>
<p>既然 OpenClaw 的记忆是工作区文件，那就要善用它的透明性。</p>
<p>你可以在 <code>~/.openclaw/workspace/MEMORY.md</code> 里先写入：</p>
<pre><code class="language-md"># 长期偏好

- 用户写技术博客时，默认读者是初学者和 1 到 3 年经验工程师。
- 代码示例优先使用 bash、yaml、python。
- 对比类文章必须包含“适用场景”和“不适用场景”。
- 发布前需要检查标题是否足够具体，避免空泛词汇。
</code></pre>
<p>这类内容特别适合放进 OpenClaw 的长期记忆里，因为它们：</p>
<ul>
<li>经常复用</li>
<li>体积不大</li>
<li>对输出风格影响非常稳定</li>
</ul>
<h4 id="415-openclaw-的典型实践场景">4.1.5 OpenClaw 的典型实践场景</h4>
<p>如果你按上面的方法搭好一个最小系统，OpenClaw 特别适合下面几类用法：</p>
<ol>
<li>
<p>随身内容助理<br>
你在手机上把灵感、语音、链接发给它，让它回到工作区里整理。</p>
</li>
<li>
<p>多入口统一助理<br>
在电脑上用 Control UI，在外面用 Telegram 或 WhatsApp，对的是同一个助理体系。</p>
</li>
<li>
<p>项目入口分流<br>
不同 agent 对应不同工作区和人格，把生活、工作、内容创作分开。</p>
</li>
<li>
<p>个人知识工作台<br>
用工作区文件、技能与记忆，把“你自己的工作方法”外化出来。</p>
</li>
</ol>
<h4 id="416-openclaw-对新手最常见的三个误区">4.1.6 OpenClaw 对新手最常见的三个误区</h4>
<p>误区一：把工作区当成默认沙箱。</p>
<p>官方文档明确提醒，工作区默认是代理的 <code>cwd</code>，但不是强制安全沙箱。你要真正限制访问范围，需要结合 sandbox 配置。</p>
<p>误区二：还没做好 allowlist 就把渠道全接进来。</p>
<p>这类配置在演示里看起来很酷，实际是风险放大器。</p>
<p>误区三：技能写得像宣传文案，不像操作说明。</p>
<p>技能不是“写给人看的广告”，而是“写给代理看的做事说明书”。越具体，越有执行价值。</p>
<hr>
<h3 id="42-hermes-agent-实战搭一个会记忆会定时会扩展的常驻型代理">4.2 Hermes Agent 实战：搭一个会记忆、会定时、会扩展的常驻型代理</h3>
<p>下面换到 Hermes Agent。</p>
<p>这一节的目标是：</p>
<p><strong>启动一个适合长期使用的 Hermes 基础环境，让它具备模型配置、持久记忆、MCP 文件系统接入，以及博客巡检类定时任务。</strong></p>
<h4 id="421-安装与初始化">4.2.1 安装与初始化</h4>
<p>Hermes 官方 Quickstart 给出的建议非常直接：</p>
<ul>
<li>用一键安装脚本安装</li>
<li>先用 <code>hermes model</code> 或 <code>hermes setup</code> 把模型配置跑通</li>
<li>再去叠加 gateway、cron、skills、voice、routing</li>
</ul>
<p>基础安装命令如下：</p>
<pre><code class="language-bash"># 官方一键安装方式，适合 Linux / macOS / WSL2 / Termux
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

# 重新加载 shell，让 hermes 命令生效
source ~/.zshrc

# 先走交互式模型配置，这是最关键的一步
hermes model

# 如果你想让 Hermes 一次性帮你完成基础设置
hermes setup
</code></pre>
<p>Hermes 官方文档还特别提醒了一点：<strong>模型上下文至少需要 64K tokens</strong>。</p>
<p>这条提醒非常重要，因为很多新手会直接拿一个小上下文模型来跑，然后得出“Agent 不稳定”“经常忘事”的结论。实际上，这并不一定是系统问题，而是模型窗口根本不够支撑多步工具调用。</p>
<h4 id="422-一份适合长期使用的-hermes-配置示例">4.2.2 一份适合长期使用的 Hermes 配置示例</h4>
<p>Hermes 会把 secrets 存在 <code>~/.hermes/.env</code>，把非敏感配置放在 <code>~/.hermes/config.yaml</code>。这比把一切都塞进一个文件里更工程化。</p>
<p>下面给一份偏“博客与项目工作流”场景的示例：</p>
<pre><code class="language-yaml"># 选择默认模型；这里用 OpenAI 风格命名举例
model: openai/gpt-5.4

terminal:
# 用 Docker 后端跑终端工具，降低直接碰宿主机的风险
backend: docker

memory:
# 开启代理自己的长期记忆
memory_enabled: true

# 开启用户画像，让代理记住你的写作和沟通偏好
user_profile_enabled: true

# 这里沿用官方默认量级，保持记忆紧凑
memory_char_limit: 2200
user_char_limit: 1375

cron:
# 关闭包裹输出，让定时报告更像正常正文
wrap_response: false

mcp_servers:
project_fs:
    # 用 MCP 文件系统服务器，把博客项目目录暴露给 Hermes
    command: npx
    args:
      - -y
      - "@modelcontextprotocol/server-filesystem"
      - /Users/yourname/projects/blog
</code></pre>
<p>这份配置其实体现了 Hermes 的四个关键思想：</p>
<ol>
<li>模型配置是系统级入口。</li>
<li>执行环境要可替换、可隔离。</li>
<li>记忆要有上限，不要无限膨胀。</li>
<li>外部工具生态最好通过 MCP 以标准方式接入。</li>
</ol>
<h4 id="423-先验证一个真实对话再做复杂自动化">4.2.3 先验证一个真实对话，再做复杂自动化</h4>
<p>Hermes 官方文档给的建议非常工程化：先确认普通对话能正常工作，再叠加高级功能。</p>
<p>你可以先在项目目录里启动：</p>
<pre><code class="language-bash"># 经典 CLI 入口
hermes

# 如果你更喜欢现代 TUI，可以这样启动
hermes --tui
</code></pre>
<p>然后直接给一个容易验证的提示词：</p>
<pre><code class="language-text">请用 5 个要点概括当前仓库的作用，并告诉我最可能的入口文件是什么。
</code></pre>
<p>这一步的意义非常大，因为它能帮助你快速分辨问题到底出在哪一层：</p>
<ul>
<li>如果连普通对话都跑不稳，先不要急着上 Cron 和 MCP。</li>
<li>如果普通对话稳、文件读写稳，再继续叠加自动化才是正确顺序。</li>
</ul>
<h4 id="424-给-hermes-增加一个博客巡检定时任务">4.2.4 给 Hermes 增加一个博客巡检定时任务</h4>
<p>Hermes 的 Cron 是它最实用的亮点之一。</p>
<p>假设你的博客仓库里经常会出现这些问题：</p>
<ul>
<li>新文章没写摘要</li>
<li>没加标签</li>
<li>标题不具体</li>
<li>没有配图占位</li>
</ul>
<p>你可以直接创建一个每日巡检任务：</p>
<pre><code class="language-bash"># 每天上午 9 点巡检博客目录，并把结果保存在本地 cron 输出目录
hermes cron create --schedule "every 1d at 09:00" \
--workdir /Users/yourname/projects/blog \
--prompt "检查当前博客项目中的 Markdown 文章，找出缺少摘要、缺少标签、标题过于空泛、没有封面占位的文章。请按文件名输出问题列表，并给出最短修复建议。"
</code></pre>
<p>这个例子非常能体现 Hermes 的运行时思路：</p>
<ul>
<li>任务不是 shell cron + Python 脚本拼出来的。</li>
<li>它是一个真正的 agent session。</li>
<li>这个 session 继承工具体系，但会在 fresh context 里运行。</li>
<li>输出默认可落到本地，也可以再接消息平台分发。</li>
</ul>
<p>如果你已经接好了 Telegram 或其他消息平台，也可以通过对话方式直接说：</p>
<pre><code class="language-text">每天早上 9 点检查我的博客仓库，把缺少摘要和标签的文章汇总后发给我。
</code></pre>
<p>Hermes 会在内部使用统一的 <code>cronjob</code> 工具去完成这件事。</p>
<h4 id="425-用子代理并行做技术调研">4.2.5 用子代理并行做技术调研</h4>
<p>Hermes 的另一个实用点，是子代理委派。</p>
<p>假设你要写一篇“不同 AI Agent 框架的比较文章”，你完全可以让 Hermes 并行跑几个独立调研流。</p>
<p>官方文档里的 <code>delegate_task</code> 用法大致如下：</p>
<pre><code class="language-python"># 这个示例展示 Hermes 内部的委派思路：把多个主题分给独立子代理并行处理
delegate_task(tasks=[
    {
      "goal": "调研 OpenClaw 的官方定位与架构特点",
      "context": "重点关注 Gateway、多渠道接入、工作区与安全模型",
      "toolsets": ["web"]
    },
    {
      "goal": "调研 Hermes Agent 的官方定位与架构特点",
      "context": "重点关注 learning loop、memory、cron、delegation、MCP",
      "toolsets": ["web"]
    },
    {
      "goal": "整理两个项目的共同点和差异点",
      "context": "重点关注初学者选型、长期自动化和消息入口差异",
      "toolsets": ["web"]
    }
])
</code></pre>
<p>这段示例不是让你手动去调这个 API，而是帮助你理解 Hermes 的做事方式：</p>
<ul>
<li>子代理不是共享同一份上下文。</li>
<li>每个子代理都要得到明确 goal 和 context。</li>
<li>只把最后总结回传给主代理，避免主上下文被调研噪音淹没。</li>
</ul>
<p>这对于复杂写作、并行调研、代码审查、方案评估都非常有用。</p>
<h4 id="426-给-hermes-放一个可复用技能">4.2.6 给 Hermes 放一个可复用技能</h4>
<p>Hermes 的技能默认在 <code>~/.hermes/skills/</code> 下。下面给一个适合博客场景的技能示例：</p>
<p><code>~/.hermes/skills/blog-quality-check/SKILL.md</code></p>
<pre><code class="language-md">---
name: blog-quality-check
description: 审查技术博客草稿，重点检查结构、术语解释、示例完整性和结论明确度。
---

&lt;!-- 这个技能用于统一博客质检流程 --&gt;
# Blog Quality Check

## 何时使用
- 当用户已经有博客草稿，希望快速做结构化审查时

## 检查清单
1. 标题是否具体，而不是只有大词
2. 开头是否在 3 段内说明“这篇文章解决什么问题”
3. 术语第一次出现时，是否有白话解释
4. 代码示例是否能说明核心逻辑，而不是堆无关细节
5. 结尾是否给出适用场景、限制和风险

## 输出格式
- 先列出严重问题
- 再列出可优化问题
- 最后给一版建议大纲
</code></pre>
<p>和 OpenClaw 很像，技能本身仍然是 Markdown。但 Hermes 对技能的理解更进一步：它把技能当成长期过程知识，未来还可能由代理自己迭代。</p>
<h4 id="427-hermes-对新手最常见的四个误区">4.2.7 Hermes 对新手最常见的四个误区</h4>
<p>误区一：还没把基础对话跑通，就急着上 MCP、Cron、子代理。</p>
<p>这会让你不知道故障到底出在哪一层。</p>
<p>误区二：用上下文窗口太小的模型。</p>
<p>官方已经明确要求至少 64K，不要忽视。</p>
<p>误区三：Cron 提示词写得过于模糊。</p>
<p>Hermes 官方文档也强调了：Cron 是 fresh session，提示词必须自包含。像“检查那个问题”这种提示，几乎肯定会导致结果不稳定。</p>
<p>误区四：把所有 toolsets 都开满。</p>
<p>工具越多，风险面越大，也越容易让代理分散注意力。先收紧，再按需放开。</p>
<hr>
<h3 id="43-一个很实用的交叉点同一份-skill如何同时服务-openclaw-与-hermes">4.3 一个很实用的交叉点：同一份 Skill，如何同时服务 OpenClaw 与 Hermes？</h3>
<p>这是我认为很多比较文章没讲透，但实际很有价值的点。</p>
<p>OpenClaw 与 Hermes 虽然设计重心不同，但它们都兼容 AgentSkills。也就是说，<strong>你的“方法论资产”并不会因为换了运行时就完全作废。</strong></p>
<p>下面给一个可同时在两边复用的技能模板：</p>
<pre><code class="language-md">---
name: compare-tech-options
description: 对多个技术方案做面对初学者的结构化对比，输出结论、差异、适用场景和风险。
---

&lt;!-- 这个技能可以同时放进 OpenClaw 或 Hermes 的技能目录 --&gt;
# Compare Tech Options

## 目标
把“多个技术方案的零散信息”整理成读者容易理解的对比结果。

## 工作步骤
1. 先说明比较对象分别是什么
2. 先给一句话总结，再展开细节
3. 必须输出表格，至少包含定位、优点、限制、适用场景
4. 对初学者必须补一句白话解释
5. 如果有实践建议，要给最小可执行步骤

## 输出约束
- 不要只说“看场景”，要明确举例
- 不要只有优点，没有限制
- 不要只比功能，要比心智成本和维护成本
</code></pre>
<p>在 OpenClaw 里，你可以把它放进：</p>
<ul>
<li><code>&lt;workspace&gt;/skills/compare-tech-options/SKILL.md</code></li>
</ul>
<p>在 Hermes 里，你可以把它放进：</p>
<ul>
<li><code>~/.hermes/skills/compare-tech-options/SKILL.md</code></li>
</ul>
<p>这意味着什么？</p>
<p>意味着你未来真正值钱的部分，不只是“你选了哪个 Agent 框架”，而是：</p>
<ul>
<li>你积累了哪些高质量技能</li>
<li>你把哪些工作流结构化了</li>
<li>你把哪些偏好、边界与审查标准沉淀下来了</li>
</ul>
<p>从长期价值看，<strong>方法论资产往往比某一个具体框架本身更稳定。</strong></p>
<hr>
<h3 id="44-典型用途选型建议与实践路线">4.4 典型用途、选型建议与实践路线</h3>
<p>说了这么多，最后还是要落回一个现实问题：到底怎么选？</p>
<p>我给你一个尽量直接的判断表。</p>
<table>
<thead>
<tr>
<th>场景</th>
<th>更推荐 OpenClaw</th>
<th>更推荐 Hermes Agent</th>
<th>原因</th>
</tr>
</thead>
<tbody>
<tr>
<td>想把 AI 接进 社交软件 / Web 控制台，形成随身助理</td>
<td>是</td>
<td>也可，但不是第一优先</td>
<td>OpenClaw 天然是 Gateway 心智</td>
</tr>
<tr>
<td>想让代理长期跑在 VPS 上，做自动化、定时任务、并行调研</td>
<td>可做，但不是最强项</td>
<td>是</td>
<td>Hermes 的 Cron、Delegation、运行时更强</td>
</tr>
<tr>
<td>想要透明可编辑的工作区记忆</td>
<td>是</td>
<td>也支持，但更分层</td>
<td>OpenClaw 的 Markdown 记忆最直观</td>
</tr>
<tr>
<td>想要跨会话搜索、外部记忆 provider、结构化长期沉淀</td>
<td>一般</td>
<td>是</td>
<td>Hermes 的记忆体系更完整</td>
</tr>
<tr>
<td>想做一个“先能联系到，再慢慢增强”的个人助理</td>
<td>是</td>
<td>也可以</td>
<td>OpenClaw 更适合从入口切入</td>
</tr>
<tr>
<td>想做一个“先把自动化闭环跑稳，再扩消息平台”的智能工作体</td>
<td>一般</td>
<td>是</td>
<td>Hermes 更像长期运行时</td>
</tr>
<tr>
<td>想做多代理、不同 persona、不同工作区隔离</td>
<td>是</td>
<td>是</td>
<td>两者都支持，但侧重点不同</td>
</tr>
<tr>
<td>想把技能当成长期方法资产积累</td>
<td>是</td>
<td>是，且更激进</td>
<td>两者都兼容 AgentSkills</td>
</tr>
</tbody>
</table>
<p>如果你希望一句话判断：</p>
<ul>
<li><strong>你要的是“随时在消息入口找到 AI 助理”</strong>，优先选 OpenClaw。</li>
<li><strong>你要的是“让 AI 长期跑任务、积累能力、做自动化”</strong>，优先选 Hermes。</li>
</ul>
<p>如果你还是拿不准，我建议按下面路线做：</p>
<ol>
<li>
<p>你是第一次接触 Agent：<br>
先选更符合你日常使用入口的那个，不要一开始追求全能。</p>
</li>
<li>
<p>你主要是内容创作、生活助理、消息触达：<br>
先上 OpenClaw。</p>
</li>
<li>
<p>你主要是开发、运维、研究、长期自动化：<br>
先上 Hermes。</p>
</li>
<li>
<p>你后续一定会做复杂工作流：<br>
就算先上 OpenClaw，也要尽早理解 Hermes 这类“运行时优先”的设计。</p>
</li>
</ol>
<hr>
<h3 id="45-前景从-2026-年看这两条路线会怎么演进">4.5 前景：从 2026 年看，这两条路线会怎么演进？</h3>
<p>这一部分带一点判断性质，我会明确告诉你：以下内容不是官方原话，而是<strong>基于当前官方架构、功能布局和生态方向做出的推断</strong>。</p>
<h4 id="451-openclaw-的前景">4.5.1 OpenClaw 的前景</h4>
<p>从当前文档与产品形态看，OpenClaw 很可能会继续强化下面几条路线：</p>
<ol>
<li>
<p>更多聊天与设备入口整合<br>
也就是让 AI 助理真正进入“你已经在用的沟通网络”。</p>
</li>
<li>
<p>更成熟的多代理路由<br>
包括不同身份、不同工作区、不同渠道账号的隔离与治理。</p>
</li>
<li>
<p>更强的工作区与节点协同<br>
比如移动端节点、Canvas、设备能力和实时消息交互结合。</p>
</li>
<li>
<p>更个人化的长期助手形态<br>
不是“给所有人一个统一 AI 产品”，而是“给每个人一套自己的 AI 基础设施”。</p>
</li>
</ol>
<p>如果这条路线走通，OpenClaw 会越来越像：</p>
<p><strong>一个围绕“个人 AI 助理可达性”构建的操作中枢。</strong></p>
<h4 id="452-hermes-agent-的前景">4.5.2 Hermes Agent 的前景</h4>
<p>Hermes 的发展路线看起来更偏向下面几个方向：</p>
<ol>
<li>
<p>更强的学习闭环<br>
技能生成、自我改进、长期记忆、用户建模会继续成为核心。</p>
</li>
<li>
<p>更成熟的自动化运行时<br>
Cron、delegation、execute_code、MCP、profiles 这些会越来越像完整平台，而不是功能拼盘。</p>
</li>
<li>
<p>更强的代理工程化<br>
包括安全分层、执行观察、上下文治理、环境后端、性能与缓存策略。</p>
</li>
<li>
<p>更靠近研究与生产之间的中间层<br>
既能做开发自动化，也能服务 RL/trajectory/data generation 这类研究工作。</p>
</li>
</ol>
<p>如果这条路线继续向前走，Hermes 很可能会越来越像：</p>
<p><strong>一个面向长期运行、自主执行与经验沉淀的 Agent OS。</strong></p>
<h4 id="453-两者共同的趋势">4.5.3 两者共同的趋势</h4>
<p>尽管侧重点不同，但我认为它们最终会在几个大方向上汇合：</p>
<ol>
<li>
<p>标准化工具生态<br>
MCP 会越来越重要。</p>
</li>
<li>
<p>可移植技能生态<br>
AgentSkills 这类标准会越来越值钱。</p>
</li>
<li>
<p>记忆分层化<br>
“长期常驻记忆 + 可检索历史 + 外部知识层”会成为主流组合。</p>
</li>
<li>
<p>更强的安全与审计<br>
真正能进生产的 Agent，必须能解释自己做了什么、为什么能做、谁批准了它做。</p>
</li>
<li>
<p>从“聊天产品”走向“长期工作体”<br>
未来最有价值的代理，不是最会对话的那个，而是最能在长期上下文中稳定完成任务的那个。</p>
</li>
</ol>
<hr>
<h2 id="5总结">5.总结</h2>
<p>如果你把这篇文章读到这里，其实已经能把 OpenClaw 和 Hermes Agent 的本质差异说清楚了：</p>
<p>OpenClaw 的强项，在于它把 AI 助理真正带进了多渠道、可触达、可路由、可工作区化的个人使用场景里。它更像一个以 Gateway 为核心的“AI 助理中枢”，非常适合先从消息入口和个人助理体验切入。</p>
<p>Hermes Agent 的强项，在于它把 Agent 当成一个长期运行、会积累经验、会定时执行、会委派子任务、会接入外部工具生态的运行时系统来设计。它更像一个“会成长的代理操作环境”，非常适合开发自动化、研究助手、长期任务代理和生产级工作流。</p>
<p>所以，问题不是“谁更强”，而是“你的第一性需求是什么”：</p>
<ul>
<li>如果你的第一需求是“我想在手机和聊天工具里随时叫到我的 AI 助理”，选 OpenClaw。</li>
<li>如果你的第一需求是“我想要一个能长期在线、会记忆、会自动跑任务的代理系统”，选 Hermes Agent。</li>
<li>如果你真正想做的是长期 AI 工作流，那么无论你从哪边起步，最终都要理解：入口、记忆、工具、自动化、安全，这五件事缺一不可。</li>
</ul>
<p>从工程角度看，这两个项目都很有代表性。OpenClaw 代表了“AI 助理入口基础设施”这条路线，Hermes Agent 代表了“AI 代理长期运行时”这条路线。理解它们的差异，不只是为了选一个工具，更是为了帮助你理解：<strong>下一代 AI 软件，究竟会以什么方式进入真实世界。</strong></p>
<hr>
<h2 id="6结束语">6.结束语</h2>
<p>这篇博客就和大家分享到这里，如果大家在研究学习的过程当中有什么问题，可以加群进行讨论或发送邮件给我，我会尽我所能为您解答，与君共勉！</p>
<p>另外，博主出新书了《<strong>Hadoop与Spark大数据全景解析</strong>》、同时已出版的《深入理解Hive》、《Kafka并不难学》和《Hadoop大数据挖掘从入门到进阶实战》也可以和新书配套使用，喜欢的朋友或同学， 可以在公告栏那里点击购买链接购买博主的书进行学习，在此感谢大家的支持。关注下面公众号，根据提示，可免费获取书籍的教学视频。</p>


</div>
<div id="MySignature" role="contentinfo">
    <div>
<b class="b1"></b><b class="b2 d1"></b><b class="b3 d1"></b><b class="b4 d1"></b>
<div class="b d1 k">
联系方式：
<br/>
邮箱：smartloli.org@gmail.com
<br/>
<strong style="color: green">QQ群（Hive与AI实战【新群】）：935396818</strong>
<br/>
QQ群（Hadoop - 交流社区1）：424769183
<br/>
QQ群（Kafka并不难学）：825943084
<br/>
温馨提示：请大家加群的时候写上加群理由（姓名＋公司/学校），方便管理员审核，谢谢！
<br/>
<h3>热爱生活，享受编程，与君共勉！</h3>
</div>
<b class="b4b d1"></b><b class="b3b d1"></b><b class="b2b d1"></b><b class="b1b"></b>
</div>
<br>
<div>
<b class="b1"></b><b class="b2 d1"></b><b class="b3 d1"></b><b class="b4 d1"></b>
<div class="b d1 k">
<h3>公众号：</h3>
<h3><img style="width: 8%; margin-left: 10px" src="https://www.cnblogs.com/images/cnblogs_com/smartloli/1324636/t_qr.png"></h3>
</div>
<b class="b4b d1"></b><b class="b3b d1"></b><b class="b2b d1"></b><b class="b1b"></b>
</div>
<br>
<div>
<b class="b1"></b><b class="b2 d1"></b><b class="b3 d1"></b><b class="b4 d1"></b>
<div class="b d1 k">
<h3>作者：哥不是小萝莉 ［关于我］［犒赏］</h3>
<h3>出处：http://www.cnblogs.com/smartloli/</h3>
<h3>转载请注明出处，谢谢合作！</h3>
</div>
<b class="b4b d1"></b><b class="b3b d1"></b><b class="b2b d1"></b><b class="b1b"></b>
</div><br><br>
来源：https://www.cnblogs.com/smartloli/p/19933743

查看完整版本: OpenClaw vs Hermes Agent