概述如果你是刚开始接触 AI Agent 的开发者最容易踩进一个坑把“会聊天的大模型”误当成“能持续工作的代理系统”。这两者不是一回事。大模型更像一个会推理、会生成文本的“大脑”而一个真正能落地的 Agent至少还需要下面几层东西工具系统让模型不只是“会说”还要“会做”比如读文件、跑命令、搜网页、发消息、调用浏览器。会话系统让代理知道当前任务进行到哪一步而不是每次都像第一次见你。记忆系统让代理把长期偏好、项目背景、历史决策存下来。权限系统让代理在执行高风险动作前有边界避免“会做事”变成“乱做事”。运行时与入口让代理能在 CLI、网页、Telegram、WhatsApp、Discord 等不同入口稳定工作。OpenClaw 和 Hermes Agent正是这类“真正能跑起来”的开源 Agent 系统里近阶段很值得比较的两个项目。它们的相似之处很多都是自托管、开源、强调可控性。都支持多模型接入而不是把自己绑死在单一厂商上。都不满足于“问答”而是强调工具调用、上下文、会话、长期使用。都支持技能skills扩展并且都和 AgentSkills 生态兼容。都在朝“常驻型、长期在线、可跨端访问”的代理形态演进。但它们的设计重心并不一样。用一句最通俗的话概括OpenClaw 更像“把所有聊天入口接到一个 AI 助理上的网关平台”。Hermes Agent 更像“一个会持续成长、会自我积累经验的常驻型代理运行时”。这篇文章的目标不是简单下结论说谁强谁弱而是帮你把下面几个问题真正想清楚它们各自解决的核心问题是什么它们的架构为什么长成现在这个样子初学者到底该先上哪一个做个人助理、开发自动化、长期知识代理、消息机器人时哪个更顺手从未来 1 到 2 年的趋势看它们分别可能走向哪里2.内容简要介绍为什么 OpenClaw 和 Hermes Agent 会被放在一起比较原因很简单它们面向的是一批高度重叠的用户。这批用户通常有下面几类需求我想要一个随时能从手机上联系到的 AI 助手。我不只想让它回答问题还想让它帮我执行任务。我希望它记住我的习惯、项目、工作流。我不想被某一家模型厂商锁死。我希望它能长期跑在我的机器、服务器或 VPS 上。从官方文档能看出两者虽然切入点不同但正在覆盖同一片版图。更有意思的是Hermes 官方甚至直接提供了从 OpenClaw 迁移的命令hermes claw migrate这本身就说明两者并不是毫无交集的两个世界而是同一赛道上的两种设计哲学。下面先分别看它们各自是什么再进入真正有价值的对比。2.1 OpenClaw 是什么按照 OpenClaw 官方仓库与官方文档的描述它是一个运行在你自己设备上的个人 AI 助理同时也是一个把多种消息渠道连接到代理运行时的自托管 Gateway。OpenClaw 的官方文档里有几个关键词非常关键它强调自己是self-hosted gateway。它强调你可以继续在现有聊天渠道里和代理对话而不必重新学习一个新界面。它强调 Gateway 是“控制平面”真正的产品是那个始终在线、可跨渠道访问的个人助理。如果把 OpenClaw 用非常白话的话来解释它更像下面这个模型你不是在“打开一个 AI App”你是在“把 社交软件、Web 控制台、移动节点等入口全部接到同一个 AI 助理上”。这个 AI 助理后面有工作区、技能、会话、记忆和工具而 Gateway 负责把这些入口统一起来。这带来几个非常鲜明的特点它是“消息入口优先”的。你可以把它理解成一个 AI 总机。不同聊天入口、不同账号、不同设备都可以通过 Gateway 汇到同一套系统里。它是“个人助理优先”的。OpenClaw 的安全模型官方就明确写了它默认假设一个 Gateway 对应一个可信的个人边界而不是拿来做 hostile multi-tenant 的多租户对抗式平台。它非常强调“可见、可编辑、可控”。比如记忆不是藏在黑盒数据库里而是直接写成 Markdown 文件技能也是SKILL.md很多配置都能直接在工作区和本地目录里看到。它天然适合“手机里能随时找到的助手”。你不一定总在终端里也不一定总在 IDE 里但你一定经常在消息应用里。OpenClaw 选择先占住这个入口。对初学者来说OpenClaw 最好理解的一点是它首先是一个把 Agent 带进日常通信渠道的系统然后才是一个可扩展的代理框架。2.2 Hermes Agent 是什么Hermes Agent 的官方定位则明显不同。官方主页第一句话就很直接它是 Nous Research 构建的self-improving AI agent也就是“会自我改进的 AI 代理”。Hermes 最有辨识度的几个关键词是built-in learning loop内建学习闭环persistent memory持久记忆session search跨会话检索cron定时任务subagent delegation子代理委派MCP integrationMCP 工具生态接入如果也用一句白话来解释 Hermes它不像“一个多消息入口的 AI 助手”而更像“一个常驻在你机器或服务器上的智能工作体”。你给它任务它不仅能做还会逐渐把经验、偏好、上下文和技能沉淀下来让自己在长期使用中变得更像一个成熟的助手而不是每次都重新开始。Hermes 的几个明显特征是它是“运行时优先”的。也就是说它更关心代理本身如何工作、如何记忆、如何委派、如何自动化、如何跨环境运行。它是“长期在线优先”的。官方文档反复强调它不需要绑在你的笔记本上可以运行在 $5 VPS、GPU 集群、Daytona、Modal 等环境里。它是“闭环学习优先”的。不是只有工具调用而是强调做过的事情能不能积累为技能长期偏好能不能沉淀成记忆过去会话能不能检索回来它是“自动化优先”的。Cron、委派、并行子代理、MCP、外部记忆提供器、上下文文件自动加载这些都说明它的目标不只是聊天而是构建一个长期运行的智能工作流系统。对于初学者Hermes 最重要的一句话理解是它不是先解决“怎么联系到代理”而是先解决“代理如何长期稳定地成长和工作”。2.3 它们为什么值得比较因为很多人第一次做 Agent 时真正纠结的不是“能不能装上”而是“应该先围绕哪种心智模型去搭系统”。这两种心智模型分别是入口优先先把消息渠道、交互触点、设备接入做对让代理能随时被叫到。运行时优先先把记忆、工具、自动化、委派、长期运行做对让代理真能持续完成复杂工作。OpenClaw 明显更偏前者Hermes 明显更偏后者。为了让这个差异更直观可以先看一张总表维度OpenClawHermes Agent对初学者意味着什么设计中心Gateway 与多渠道接入AIAgent 运行时与学习闭环前者更像“入口平台”后者更像“智能执行内核”主要使用姿势从消息应用、Control UI、节点访问从 CLI/TUI、Gateway、Cron、子代理访问OpenClaw 更贴近日常通信Hermes 更贴近长期自动化记忆模型工作区 Markdown 记忆为主透明可编辑MEMORY.mdUSER.md Session Search 外部记忆提供器OpenClaw 更直观Hermes 更系统化技能模型AgentSkills 兼容支持多层目录加载AgentSkills 兼容集中在~/.hermes/skills/可自动创建和改进Hermes 在“技能闭环”上更激进自动化能力有路由、多代理、节点、工具体系有 Cron、子代理、并行委派、代码执行、MCPHermes 更像自动化工作平台安全思路单人可信边界、配对白名单、Exec 审批七层防御、命令审批、容器隔离、MCP 过滤Hermes 的安全分层更系统化最适合的人想先把 AI 助理接进日常消息入口的人想搭长期运行、可学习、可自动化代理的人选错入口后续维护成本会明显变高3.原理、架构与核心机制对比3.1 OpenClaw为什么它会长成一个 Gateway 中心架构OpenClaw 的官方文档里有一条几乎可以当成“设计宣言”的描述Gateway 是 sessions、routing 和 channel connections 的 single source of truth。这句话非常关键因为它决定了 OpenClaw 的整体长相。3.1.1 OpenClaw 的核心原理OpenClaw 的思路不是“让每个入口各自跑一份代理”而是“让所有入口都连接到同一个长期运行的 Gateway再由 Gateway 统一维护会话、路由和连接状态”。这样做的好处非常现实多渠道不会各玩各的。你可以从 Telegram 找它也可以从 Web 控制台找它甚至通过节点设备找它但对底层系统来说这些都是同一个总入口体系。统一会话与身份边界。一旦 Gateway 成为状态中心谁在和代理说话、消息来自哪个渠道、应该路由给哪个 agent、要不要配对、是否允许执行某类操作都能在一个中枢做决策。更适合个人助理场景。个人助理的典型特征不是“单次推理很强”而是“我随时能找到它而且它能在多个入口保持一致”。OpenClaw 的架构正是为这个需求定制的。3.1.2 OpenClaw 的组件关系用图来看会更直观用户: Telegram / WhatsApp / Discord用户: Web Control UI / CLI节点: iOS / Android / macOSOpenClaw GatewayAgent RuntimeWorkspace\nAGENTS.md / MEMORY.md / skillsTools / Plugins模型提供商这个图的重点不是“它也有模型、也有工具”而是所有外部入口先汇入 Gateway再由 Gateway 组织后面的代理能力。从官方 Gateway 架构文档可以提炼出几条重要事实单个长期运行的 Gateway 负责所有消息表面。Control-plane 客户端macOS app、CLI、Web UI、自动化程序通过 WebSocket 连到 Gateway。节点设备也通过 WebSocket 接入但会带上自己的role: node与能力声明。默认绑定地址是127.0.0.1:18789。对初学者来说这意味着一个非常重要的认知OpenClaw 的“主语”不是某个聊天窗口而是 Gateway 这个长期运行的中枢。3.1.3 OpenClaw 的多代理与工作区隔离很多人一看到“个人助理”会误以为它只能单体使用但 OpenClaw 官方文档明确支持 Multi-Agent Routing。它的多代理设计不是在一个上下文里塞很多 persona而是每个 agent 有自己的 workspace。每个 agent 有自己的agentDir。每个 agent 有自己的 sessions 存储。不同渠道、账号、发送者可以通过 bindings 路由到不同 agent。这点很值得肯定因为它符合工程上的一个基本原则隔离比提示词伪装更可靠。也就是说OpenClaw 不是靠“你现在假装自己是 A现在又假装自己是 B”来扮演多个助理而是给每个 agent 单独的工作区、技能、会话与认证边界。对初学者的启发是如果你只想要一个自己的随身助理默认单 agent 就够了。如果你想把“生活助理”“工作助理”“内容助理”拆开OpenClaw 已经提供了比较干净的隔离思路。3.1.4 OpenClaw 的记忆模型为什么对新手友好OpenClaw 的记忆设计很“朴素”但这恰恰是它好理解的地方。官方文档说明它的记忆直接写在工作区的 Markdown 文件里核心包括MEMORY.md长期记忆memory/YYYY-MM-DD.md每日上下文DREAMS.md可选的 Dream Diary / 总结层这有两个非常大的优点可审计。你能直接打开文件看代理到底记了什么而不是只能猜。可修正。如果代理记错了或者你想重新整理长期背景直接改 Markdown 即可。这类设计特别适合刚上手 Agent 的人因为你能把“记忆”当成真实文件系统来理解而不是抽象的 embedding 魔法。当然它不是没有代价。代价是需要你更主动地维护工作区质量。当规模继续扩大时单纯文件记忆可能不如更系统的检索/外部记忆架构灵活。但对于“先把个人助理跑起来”这件事它非常实用。3.1.5 OpenClaw 的工具、技能、插件三层模型OpenClaw 官方文档把能力拆成三层这个拆法非常清晰Tools代理真正调用的能力比如exec、browser、web_search、message。Skills通过SKILL.md教代理“什么时候、如何用工具”。Plugins把渠道、工具、技能、搜索、媒体理解等能力打包起来。这个拆分很重要因为很多初学者会把“工具”和“技能”混成一回事。实际上工具决定“能不能做”。技能决定“知不知道什么时候该这样做”。插件决定“怎么把多种能力装配成一个可扩展系统”。从工程角度讲OpenClaw 的这个分层相当健康。它让你可以不改核心代码只加技能。不改技能只换工具策略。不改主程序只通过插件扩渠道或扩能力。3.1.6 OpenClaw 的安全模型为什么它强调“个人可信边界”OpenClaw 官方安全文档写得很直白它默认假设一个 Gateway 对应一个 trusted operator boundary也就是一个可信的个人边界而不是面向互相敌对用户的共享多租户安全边界。这句话很多人会忽略但它其实是在帮你避免严重误用。它的意思是用它给自己搭个人助理很合适。用它给一个小团队中彼此信任的人搭工具也可能可以。但如果你想让互不信任的多个用户共用同一套代理与凭据那就超出它的默认安全假设了。OpenClaw 在保护措施上也不是没有动作。它至少有几层关键保护DM pairing陌生发送者需要显式配对。Node pairing新节点接入需要审批。Exec approvals代理要在真实宿主机执行命令时需要策略、白名单与用户审批共同允许。Sandboxing可以把代理运行在隔离的 sandbox runtime 中。这里最值得初学者记住的一点是OpenClaw 的安全思路不是把风险假装不存在而是承认“个人助理天然高权限”所以要通过 pairing、审批和沙箱把风险关进笼子里。3.1.7 一句话总结 OpenClaw 的架构气质如果非要给 OpenClaw 的架构气质下一个定义我会这样说它不是先发明一个最“聪明”的代理大脑而是先搭一个最适合“让助理真正进入你生活和工作入口”的基础设施。这也是为什么它对“消息入口”“节点接入”“会话路由”“工作区可见性”如此上心。3.2 Hermes Agent为什么它会长成一个“自学习运行时”如果说 OpenClaw 的设计起点是“入口与中枢”那 Hermes Agent 的设计起点几乎相反它关心的是代理长期运行时内部到底如何积累、调用、自动化与扩展。3.2.1 Hermes 的核心原理Hermes 的设计核心可以概括为一句话代理不是一次性的聊天回合而是一个会不断沉淀能力、维持状态并自主运行的长期系统。从 Hermes 官方文档里能看到它非常强调几个能力闭环长期记忆闭环技能生成与复用闭环会话检索闭环定时任务闭环子代理委派闭环MCP 扩展闭环换句话说Hermes 把 Agent 看成一个长期演化的“软件主体”而不是简单的消息机器人。3.2.2 Hermes 的系统骨架Hermes 的官方架构文档给出的核心非常明确一个统一的AIAgent类服务于 CLI、Gateway、ACP、Batch、API Server 等多个入口。这意味着 Hermes 的重心不是入口本身而是把不同入口都接到同一个运行时核心。可以用下面这张图来理解用户: CLI / TUI / Telegram / DiscordHermes GatewayAIAgent 核心循环Prompt SystemTool Registry\n47 tools / 19 toolsetsTerminal Backends\nlocal / Docker / SSH / Modal / Daytona / SingularityMemory\nMEMORY.md / USER.md / Session SearchSkills / Plugins / MCPCron / Delegation模型提供商这张图里最关键的不是模块多而是模块之间的职责边界更“运行时化”Prompt system 负责系统提示构建。Tool registry 负责工具发现、调度和可用性判定。Session persistence 负责会话与历史检索。Gateway 只是一个入口不是唯一主角。Cron 与 delegation 都是一等公民而不是外挂脚本。3.2.3 Hermes 为什么更像“代理操作系统”Hermes 官方架构文档里有几个设计原则特别能说明问题Prompt stability系统提示在会话中途不随意变化避免破坏缓存与稳定性。Observable execution每一次工具调用尽量可观察。Interruptible执行过程可中断。Platform-agnostic core同一个 AIAgent 核心服务多个平台入口。Profile isolation不同 profile 拥有独立的配置、记忆、会话和 gateway PID。这类原则其实已经很接近“操作系统级运行时”的思路了。一个成熟的 Agent 系统最终都得面对这些问题执行中能不能打断同一套核心能不能服务多个入口多个工作身份能不能隔离记忆写入后会不会破坏当前会话稳定性工具注册是不是足够规范Hermes 没有回避这些问题而是把它们提升成一等设计对象。这也是为什么很多开发者第一次用 Hermes会感觉它不像“一个 bot”而像“一个给 Agent 设计的操作环境”。3.2.4 Hermes 的工具系统为什么更适合重自动化官方架构文档里明确提到Hermes 有47 个注册工具、19 个 toolsets并且支持6 种终端后端localDockerSSHDaytonaSingularityModal这个数字本身不是重点重点是它背后的工程含义工具不是临时拼接的。它们通过统一注册表进行发现、调度和错误包装。执行环境是可切换的。你今天在本地跑明天切到 Docker后天切到远端 SSH 或 Modal不需要重写代理概念层。工具集合可以按场景收缩。这对安全尤其重要。不是所有场景都该把所有工具开满。对于初学者这里要理解的重点不是“47 比 20 更强”而是Hermes 把“代理能做什么”这件事做成了一个结构化的系统而不是一堆散装命令。3.2.5 Hermes 的记忆系统为什么更“分层”Hermes 的官方文档把记忆明确拆成了几层MEMORY.md记录环境事实、项目约定、经验教训。USER.md记录用户偏好、沟通习惯、身份信息。Session Search所有 CLI 与消息会话进入 SQLite并支持 FTS5 全文搜索与总结。External Memory Providers还可以外挂额外的记忆提供器。这说明 Hermes 的记忆观不是“只要长期记一点东西就够了”而是有些信息必须始终在 prompt 里属于高价值小体积记忆。有些信息不该常驻但应当可检索。有些信息需要交给更外部化、更结构化的记忆系统处理。同时Hermes 特别强调一个点memory 是 frozen snapshot。也就是说会话开始时记忆会被注入系统提示。会话中如果新写入记忆会马上落盘。但这段新记忆不会立刻重写当前系统提示而是留到下一个会话再生效。这背后的目的是保持 prompt 稳定和缓存收益。对初学者来说这种设计虽然比 OpenClaw 的文件记忆更复杂但它更接近一个成熟代理系统在长期使用中的真实需求不是只要“记住”还要“记得稳”“记得省”“记得可搜索”。3.2.6 Hermes 的技能系统为什么更像“过程知识库”Hermes 官方主页和技能文档都反复强调一件事技能不是装饰而是代理的procedural memory也就是“过程型记忆”。什么意思举个最简单的例子记忆告诉代理这个项目用的是 Rust。技能告诉代理在这个项目里排查构建失败时先跑什么再看哪里再如何报告。Hermes 进一步强调技能按需加载减少 token 开销。所有技能集中在~/.hermes/skills/。每个技能都可以作为 slash command 使用。代理可以在解决复杂任务后生成新的技能后续复用。这就是 Hermes 最有辨识度的地方之一它想把“今天学到的做事方法”固化下来而不只是把“今天聊过的内容”存下来。3.2.7 Hermes 的 Cron 与 Delegation为什么它更适合长期自动化Hermes 的官方 Cron 文档很清楚地说明了两点Cron 是一等功能不是外部拼接脚本。每个 Cron 任务都运行在 fresh agent session 里。这个设计非常成熟。它避免了很多自动化系统的典型问题上一次任务残留上下文污染下一次任务。多次调度叠加成难以解释的行为。脚本和代理逻辑割裂维护体验差。Hermes 的 delegation 也同样体现了运行时思维子代理拿到的是隔离上下文。子代理有自己的终端会话。父代理只接收最终摘要而不是把所有中间过程都塞回主上下文。最多并行 3 个子代理控制复杂度。这意味着 Hermes 很适合做这类任务并行调研多个主题把大任务拆成多个独立分析流用新上下文重新审视问题避免主上下文偏见把重复性复杂操作变成 Cron Skills 组合如果你要搭的是“长期跑、持续产出、可调度、可拆分”的代理Hermes 天生更占优势。3.2.8 Hermes 的安全模型为什么更“企业化”Hermes 官方安全页把安全分成了七层用户授权危险命令审批容器隔离MCP 凭据过滤上下文文件扫描跨会话隔离输入净化这是一种非常明显的 defense-in-depth 思路。它不是假设某一道防线永远不会失败而是假设用户可能配错工具可能被滥用MCP 可能暴露过宽工作目录和上下文文件都可能被注入所以需要多层叠加。对于初学者这里最重要的启示是当一个代理越来越像“自动运行的数字员工”安全就不再是附加项而是架构本体。3.2.9 一句话总结 Hermes 的架构气质如果也给 Hermes 下一个定义我会这样说它不是先考虑“你怎么找到代理”而是先考虑“代理长期活着以后如何记忆、调度、扩展、委派、复盘和成长”。这就是为什么 Hermes 看起来更像一个“代理操作系统”。3.3 记忆、技能、工具与扩展两者最关键的机制差异为了避免“看起来都支持所以差不多”的误判这里把最关键的机制差异拆开说。3.3.1 入口层差异OpenClaw 的入口层更强。它天然以消息渠道、Control UI、节点设备为第一优先级。对很多人来说真正的价值不是“这个 Agent 理论上可以做什么”而是“我能不能在手机上 10 秒内找到它”。OpenClaw 抢的就是这 10 秒体验。Hermes 的入口层也不弱官方文档显示它支持 CLI、Telegram、Discord、Slack、WhatsApp、Signal、Email 等多个平台但它的文档气质明显更偏“先把代理运行时跑稳再扩入口”。所以如果你是交互触点优先OpenClaw 更顺手。如果你是运行闭环优先Hermes 更顺手。3.3.2 记忆层差异OpenClaw 的记忆更透明、可手改、工作区导向。Hermes 的记忆更分层、带容量控制、带会话搜索、还可外挂外部 provider。这没有绝对优劣关键看需求想快速理解、手工修正、直接看文件OpenClaw 更友好。想长期积累、可检索、可扩展、可控 token 成本Hermes 更成熟。3.3.3 技能层差异两者都支持 AgentSkills这是一个很大的共同点。但 OpenClaw 更像“技能是工作区的一部分”Hermes 更像“技能是代理成长机制的一部分”。OpenClaw 在技能加载层次上更细支持额外目录bundled skills~/.openclaw/skills~/.agents/skills项目级.agents/skills工作区skills/Hermes 则更集中默认以~/.hermes/skills/为主源并强调按需加载与 slash command 直达。3.3.4 自动化层差异OpenClaw 擅长把代理变成一个随时可联系、可路由、可多入口访问的个人助理。Hermes 更擅长把代理变成一个会定时运行会并行拆任务会检索历史会通过 MCP 扩展外部系统会从经验中形成技能的长期自动化系统。对很多工程团队来说真正影响效率的不是“能不能回答一个问题”而是“这个系统能不能自己稳定地做掉 30% 的重复工作”。在这一点上Hermes 的答案更完整。3.3.5 工程心智差异我建议你把它们分别记成两种比喻OpenClaw AI 助理总机Hermes Agent AI 代理运行时一旦这样记很多选择就会变得清晰我要的是“随时能联系到它”还是“长期能自己干活”我要的是“对话入口管理”还是“任务生命周期管理”我要的是“先上手跑起来”还是“先把长期系统打稳”3.4 安全、权限与风险控制选型时最容易被忽视的一环很多比较文章喜欢谈模型、速度、功能却不谈安全。实际上对 Agent 系统来说安全不是附属功能而是决定它能否长期可用的基础设施。3.4.1 OpenClaw 的安全哲学OpenClaw 的安全哲学很清楚它假设你在做个人助理而不是公有多租户平台。它通过 pairing、allowlist、exec approvals、sandboxing 来控制风险。这种哲学的好处是非常务实新手容易理解。配置路径清晰。安全措施和使用场景高度匹配。它的风险点在于如果你忽略官方信任边界假设强行把它拿去做复杂多租户共享就会超出设计预期。如果你把 Gateway 暴露出去却没有做好白名单、pairing 和执行审批风险会上升得很快。3.4.2 Hermes 的安全哲学Hermes 的安全哲学更偏“多层防御”和“长期运行风险控制”。它关心的不只是谁能发消息给代理还关心这个命令是不是危险命令这个 MCP 子进程能看到哪些环境变量这个上下文文件是否存在注入问题这个 cron 任务是否会递归制造更多 cron这个会话的数据边界有没有被破坏这种设计更适合长期自动化系统因为代理一旦开始定时运行访问外部系统使用更多工具和更多平台打通风险面就会迅速变宽。3.4.3 初学者应该如何理解“安全成本”一句话代理越有行动能力安全边界就越重要。所以别只看“能不能自动发消息”“能不能自动跑命令”还要看谁批准在哪执行能访问哪些目录会不会误发失败了怎么停下来从这个角度看OpenClaw 更适合“先在个人边界内把事情跑顺”。Hermes 更适合“从一开始就按长期自动化系统来治理”。4.用途、实践与前景4.1 OpenClaw 实战把聊天入口变成真正可用的随身 AI 助理这一节我们不搞空泛概念直接给一个适合初学者的最小可行方案。目标很简单在自己的机器上启动 OpenClaw打开 Control UI并给它一套最基础的安全限制和博客写作技能。4.1.1 安装与初始化根据 OpenClaw 官方文档推荐前提是 Node 24Node 22.14 也支持。你可以按下面的方式安装并初始化# 方式一使用官方安装脚本适合大多数新手 curl -fsSL https://openclaw.ai/install.sh | bash # 运行引导流程自动配置模型提供商、Gateway 和基础环境 openclaw onboard --install-daemon # 检查 Gateway 是否已经启动 openclaw gateway status # 打开浏览器控制台默认是本机 18789 端口 openclaw dashboard如果你更习惯 npm 方式也可以使用# 这种方式适合你已经有稳定的 Node 环境 npm install -g openclawlatest # 初始化并安装后台服务 openclaw onboard --install-daemon这一阶段你应该得到什么结果本地有一个长期运行的 Gateway。浏览器能打开 Control UI。你已经配置好至少一个模型提供商。你可以先在 Web 控制台里对话再决定是否接 Telegram、WhatsApp 等渠道。4.1.2 一份新手足够用的 OpenClaw 配置示例下面给一份面向“个人助理”场景的最小配置示例{ // 这个工作区会存放 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] } } }这份配置体现了 OpenClaw 的一条最佳实践先缩小可触达范围再逐步放开能力。很多人第一次玩 Agent就急着把它接进所有渠道、所有群、所有联系人最后不是误触发就是风险不可控。正确做法正好相反先只给自己用。先只开一个渠道。先只用白名单。先只在明确提及时响应。4.1.3 给 OpenClaw 加一个博客写作技能OpenClaw 支持 AgentSkills 兼容技能。对内容创作者或技术博主来说最有价值的不是“让代理自由发挥写文章”而是把写作流程固化成技能。你可以在工作区下创建~/.openclaw/workspace/skills/tech-blog-writer/SKILL.md--- name: tech-blog-writer description: 面向初学者整理技术博客先讲结论再讲原理再给代码示例。 --- !-- 这个技能用于规范技术博客的输出流程 -- # Tech Blog Writer ## 何时使用 - 当用户给出一个技术主题希望生成完整博客草稿时 - 当主题涉及多个方案对比需要表格、示例和选型建议时 ## 工作步骤 1. 先识别读者是谁初学者、普通工程师还是架构师 2. 先给结论再讲原理避免一上来堆背景知识 3. 如果涉及对比必须输出对比表 4. 如果涉及工具或框架至少给一个可运行示例 5. 结尾给出“适用场景、限制、风险” ## 输出约束 - 关键术语第一次出现时用一句白话解释 - 避免空话和营销化表达 - 代码示例尽量短并带必要注释这个技能的价值不是“让模型更会写”而是让代理知道写一篇合格的技术博客应该按什么流程输出。这也是 Agent 和普通聊天机器人的一个核心差异普通聊天更像临场发挥。Agent 技能更像把经验沉淀成可重复执行的方法。4.1.4 给 OpenClaw 准备一份长期记忆既然 OpenClaw 的记忆是工作区文件那就要善用它的透明性。你可以在~/.openclaw/workspace/MEMORY.md里先写入# 长期偏好 - 用户写技术博客时默认读者是初学者和 1 到 3 年经验工程师。 - 代码示例优先使用 bash、yaml、python。 - 对比类文章必须包含“适用场景”和“不适用场景”。 - 发布前需要检查标题是否足够具体避免空泛词汇。这类内容特别适合放进 OpenClaw 的长期记忆里因为它们经常复用体积不大对输出风格影响非常稳定4.1.5 OpenClaw 的典型实践场景如果你按上面的方法搭好一个最小系统OpenClaw 特别适合下面几类用法随身内容助理你在手机上把灵感、语音、链接发给它让它回到工作区里整理。多入口统一助理在电脑上用 Control UI在外面用 Telegram 或 WhatsApp对的是同一个助理体系。项目入口分流不同 agent 对应不同工作区和人格把生活、工作、内容创作分开。个人知识工作台用工作区文件、技能与记忆把“你自己的工作方法”外化出来。4.1.6 OpenClaw 对新手最常见的三个误区误区一把工作区当成默认沙箱。官方文档明确提醒工作区默认是代理的cwd但不是强制安全沙箱。你要真正限制访问范围需要结合 sandbox 配置。误区二还没做好 allowlist 就把渠道全接进来。这类配置在演示里看起来很酷实际是风险放大器。误区三技能写得像宣传文案不像操作说明。技能不是“写给人看的广告”而是“写给代理看的做事说明书”。越具体越有执行价值。4.2 Hermes Agent 实战搭一个会记忆、会定时、会扩展的常驻型代理下面换到 Hermes Agent。这一节的目标是启动一个适合长期使用的 Hermes 基础环境让它具备模型配置、持久记忆、MCP 文件系统接入以及博客巡检类定时任务。4.2.1 安装与初始化Hermes 官方 Quickstart 给出的建议非常直接用一键安装脚本安装先用hermes model或hermes setup把模型配置跑通再去叠加 gateway、cron、skills、voice、routing基础安装命令如下# 官方一键安装方式适合 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 setupHermes 官方文档还特别提醒了一点模型上下文至少需要 64K tokens。这条提醒非常重要因为很多新手会直接拿一个小上下文模型来跑然后得出“Agent 不稳定”“经常忘事”的结论。实际上这并不一定是系统问题而是模型窗口根本不够支撑多步工具调用。4.2.2 一份适合长期使用的 Hermes 配置示例Hermes 会把 secrets 存在~/.hermes/.env把非敏感配置放在~/.hermes/config.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这份配置其实体现了 Hermes 的四个关键思想模型配置是系统级入口。执行环境要可替换、可隔离。记忆要有上限不要无限膨胀。外部工具生态最好通过 MCP 以标准方式接入。4.2.3 先验证一个真实对话再做复杂自动化Hermes 官方文档给的建议非常工程化先确认普通对话能正常工作再叠加高级功能。你可以先在项目目录里启动# 经典 CLI 入口 hermes # 如果你更喜欢现代 TUI可以这样启动 hermes --tui然后直接给一个容易验证的提示词请用 5 个要点概括当前仓库的作用并告诉我最可能的入口文件是什么。这一步的意义非常大因为它能帮助你快速分辨问题到底出在哪一层如果连普通对话都跑不稳先不要急着上 Cron 和 MCP。如果普通对话稳、文件读写稳再继续叠加自动化才是正确顺序。4.2.4 给 Hermes 增加一个博客巡检定时任务Hermes 的 Cron 是它最实用的亮点之一。假设你的博客仓库里经常会出现这些问题新文章没写摘要没加标签标题不具体没有配图占位你可以直接创建一个每日巡检任务# 每天上午 9 点巡检博客目录并把结果保存在本地 cron 输出目录 hermes cron create --schedule every 1d at 09:00 \ --workdir /Users/yourname/projects/blog \ --prompt 检查当前博客项目中的 Markdown 文章找出缺少摘要、缺少标签、标题过于空泛、没有封面占位的文章。请按文件名输出问题列表并给出最短修复建议。这个例子非常能体现 Hermes 的运行时思路任务不是 shell cron Python 脚本拼出来的。它是一个真正的 agent session。这个 session 继承工具体系但会在 fresh context 里运行。输出默认可落到本地也可以再接消息平台分发。如果你已经接好了 Telegram 或其他消息平台也可以通过对话方式直接说每天早上 9 点检查我的博客仓库把缺少摘要和标签的文章汇总后发给我。Hermes 会在内部使用统一的cronjob工具去完成这件事。4.2.5 用子代理并行做技术调研Hermes 的另一个实用点是子代理委派。假设你要写一篇“不同 AI Agent 框架的比较文章”你完全可以让 Hermes 并行跑几个独立调研流。官方文档里的delegate_task用法大致如下# 这个示例展示 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] } ])这段示例不是让你手动去调这个 API而是帮助你理解 Hermes 的做事方式子代理不是共享同一份上下文。每个子代理都要得到明确 goal 和 context。只把最后总结回传给主代理避免主上下文被调研噪音淹没。这对于复杂写作、并行调研、代码审查、方案评估都非常有用。4.2.6 给 Hermes 放一个可复用技能Hermes 的技能默认在~/.hermes/skills/下。下面给一个适合博客场景的技能示例~/.hermes/skills/blog-quality-check/SKILL.md--- name: blog-quality-check description: 审查技术博客草稿重点检查结构、术语解释、示例完整性和结论明确度。 --- !-- 这个技能用于统一博客质检流程 -- # Blog Quality Check ## 何时使用 - 当用户已经有博客草稿希望快速做结构化审查时 ## 检查清单 1. 标题是否具体而不是只有大词 2. 开头是否在 3 段内说明“这篇文章解决什么问题” 3. 术语第一次出现时是否有白话解释 4. 代码示例是否能说明核心逻辑而不是堆无关细节 5. 结尾是否给出适用场景、限制和风险 ## 输出格式 - 先列出严重问题 - 再列出可优化问题 - 最后给一版建议大纲和 OpenClaw 很像技能本身仍然是 Markdown。但 Hermes 对技能的理解更进一步它把技能当成长期过程知识未来还可能由代理自己迭代。4.2.7 Hermes 对新手最常见的四个误区误区一还没把基础对话跑通就急着上 MCP、Cron、子代理。这会让你不知道故障到底出在哪一层。误区二用上下文窗口太小的模型。官方已经明确要求至少 64K不要忽视。误区三Cron 提示词写得过于模糊。Hermes 官方文档也强调了Cron 是 fresh session提示词必须自包含。像“检查那个问题”这种提示几乎肯定会导致结果不稳定。误区四把所有 toolsets 都开满。工具越多风险面越大也越容易让代理分散注意力。先收紧再按需放开。4.3 一个很实用的交叉点同一份 Skill如何同时服务 OpenClaw 与 Hermes这是我认为很多比较文章没讲透但实际很有价值的点。OpenClaw 与 Hermes 虽然设计重心不同但它们都兼容 AgentSkills。也就是说你的“方法论资产”并不会因为换了运行时就完全作废。下面给一个可同时在两边复用的技能模板--- name: compare-tech-options description: 对多个技术方案做面对初学者的结构化对比输出结论、差异、适用场景和风险。 --- !-- 这个技能可以同时放进 OpenClaw 或 Hermes 的技能目录 -- # Compare Tech Options ## 目标 把“多个技术方案的零散信息”整理成读者容易理解的对比结果。 ## 工作步骤 1. 先说明比较对象分别是什么 2. 先给一句话总结再展开细节 3. 必须输出表格至少包含定位、优点、限制、适用场景 4. 对初学者必须补一句白话解释 5. 如果有实践建议要给最小可执行步骤 ## 输出约束 - 不要只说“看场景”要明确举例 - 不要只有优点没有限制 - 不要只比功能要比心智成本和维护成本在 OpenClaw 里你可以把它放进workspace/skills/compare-tech-options/SKILL.md在 Hermes 里你可以把它放进~/.hermes/skills/compare-tech-options/SKILL.md这意味着什么意味着你未来真正值钱的部分不只是“你选了哪个 Agent 框架”而是你积累了哪些高质量技能你把哪些工作流结构化了你把哪些偏好、边界与审查标准沉淀下来了从长期价值看方法论资产往往比某一个具体框架本身更稳定。4.4 典型用途、选型建议与实践路线说了这么多最后还是要落回一个现实问题到底怎么选我给你一个尽量直接的判断表。场景更推荐 OpenClaw更推荐 Hermes Agent原因想把 AI 接进 社交软件 / Web 控制台形成随身助理是也可但不是第一优先OpenClaw 天然是 Gateway 心智想让代理长期跑在 VPS 上做自动化、定时任务、并行调研可做但不是最强项是Hermes 的 Cron、Delegation、运行时更强想要透明可编辑的工作区记忆是也支持但更分层OpenClaw 的 Markdown 记忆最直观想要跨会话搜索、外部记忆 provider、结构化长期沉淀一般是Hermes 的记忆体系更完整想做一个“先能联系到再慢慢增强”的个人助理是也可以OpenClaw 更适合从入口切入想做一个“先把自动化闭环跑稳再扩消息平台”的智能工作体一般是Hermes 更像长期运行时想做多代理、不同 persona、不同工作区隔离是是两者都支持但侧重点不同想把技能当成长期方法资产积累是是且更激进两者都兼容 AgentSkills如果你希望一句话判断你要的是“随时在消息入口找到 AI 助理”优先选 OpenClaw。你要的是“让 AI 长期跑任务、积累能力、做自动化”优先选 Hermes。如果你还是拿不准我建议按下面路线做你是第一次接触 Agent先选更符合你日常使用入口的那个不要一开始追求全能。你主要是内容创作、生活助理、消息触达先上 OpenClaw。你主要是开发、运维、研究、长期自动化先上 Hermes。你后续一定会做复杂工作流就算先上 OpenClaw也要尽早理解 Hermes 这类“运行时优先”的设计。4.5 前景从 2026 年看这两条路线会怎么演进这一部分带一点判断性质我会明确告诉你以下内容不是官方原话而是基于当前官方架构、功能布局和生态方向做出的推断。4.5.1 OpenClaw 的前景从当前文档与产品形态看OpenClaw 很可能会继续强化下面几条路线更多聊天与设备入口整合也就是让 AI 助理真正进入“你已经在用的沟通网络”。更成熟的多代理路由包括不同身份、不同工作区、不同渠道账号的隔离与治理。更强的工作区与节点协同比如移动端节点、Canvas、设备能力和实时消息交互结合。更个人化的长期助手形态不是“给所有人一个统一 AI 产品”而是“给每个人一套自己的 AI 基础设施”。如果这条路线走通OpenClaw 会越来越像一个围绕“个人 AI 助理可达性”构建的操作中枢。4.5.2 Hermes Agent 的前景Hermes 的发展路线看起来更偏向下面几个方向更强的学习闭环技能生成、自我改进、长期记忆、用户建模会继续成为核心。更成熟的自动化运行时Cron、delegation、execute_code、MCP、profiles 这些会越来越像完整平台而不是功能拼盘。更强的代理工程化包括安全分层、执行观察、上下文治理、环境后端、性能与缓存策略。更靠近研究与生产之间的中间层既能做开发自动化也能服务 RL/trajectory/data generation 这类研究工作。如果这条路线继续向前走Hermes 很可能会越来越像一个面向长期运行、自主执行与经验沉淀的 Agent OS。4.5.3 两者共同的趋势