OpenClaw + Hermes Agent:Agent 工程开始从＂会调用工具＂走向＂会积累经验＂
当入口网关遇到自进化 Agent,大模型应用的工程边界正在被重新划分。
这两年聊 Agent,大家的注意力其实都被一个问题吸住了:
能查网页吗?能读文件吗?会写代码吗?能跑命令吗?接没接 MCP?
但你把 OpenClaw 和 Hermes Agent 摆在一起看,会发现 Agent 工程真正要解决的事,早就不只是”会不会调用工具”了。
一个 Agent 怎么从各种不同的入口接到任务?长期跑下来怎么保住上下文?做过一遍的事,下次怎么还记得?跑得久了,怎么不踩雷?
OpenClaw 和 Hermes Agent 这两个项目,刚好代表了两个完全不同的方向。
OpenClaw 更像是一个多入口 AI Gateway。它把 Telegram、Slack、Discord、WhatsApp、Signal、iMessage、WebChat、移动端节点这些入口全都统一收进同一个 Gateway,让 Agent 不再只活在一个网页聊天框里,而是可以直接出现在用户每天真正在用的那些消息软件里。它的官方文档把 Gateway 描述成 sessions、routing 和 channel connections 的 single source of truth——说白了就是”所有渠道的总开关”。
Hermes Agent 则更像一个能长期运行的 Agent Runtime。它讲的是自我学习、长期记忆、Skills 自动生成、工具调用、MCP 集成、跨会话经验沉淀。官方文档直接把它定位成 self-improving AI agent——重点是这几个能力:从经验里造 Skills、改 Skills,然后在不同会话之间还能记得你是谁、之前在干嘛。
把这俩叠在一起看,你看到的就不是”一个更大的聊天机器人”了,而是一种更接近真实 Agent 系统的分层架构:
这可能就是下一阶段 Agent 工程最值得盯紧的方向。
Agent 不该只有大脑,还得有神经系统
很多 Agent 项目一开始,几乎都是同一个套路:
挑个强模型,接几个工具,写段系统提示词,套个 Web UI,然后宣布——”我们做了一个 Agent”。
这种系统拿来 demo 是没问题的,但要长期跑起来,基本撑不住。
真实的任务从来不会乖乖坐在输入框里等你
为什么撑不住?因为真实任务从来不会从一个干干净净的输入框出发。它们从四面八方冒出来:消息软件、命令行、Webhook、网页表单、群聊、手机端、定时任务、文件变更、系统告警……什么都有。
所以 Agent 首先要解决的根本就不是”怎么思考”,而是更前面那一步——“从哪里感知到这个世界”。
这一层是被绝大多数 Agent 项目轻视掉的。它没有”自主决策”那种戏剧感,讲起来也不性感,但它直接决定了 Agent 能不能真正进到工作流里。
OpenClaw 想做的,就是那套”外围神经”
OpenClaw 的核心是一个长期运行的 Gateway,负责接各种消息渠道、维护会话、管路由、连设备节点、跑 WebSocket、提供控制界面。官方架构文档里讲得很明白:这个 long-lived Gateway 拥有所有 messaging surfaces;CLI、Web UI、macOS app、automations 通过 WebSocket 接进来,iOS、Android、headless nodes 也都通过 WebSocket 接进来,各自声明自己能干什么。
也就是说,OpenClaw 真不是个”套了壳的聊天界面”,它更像是 Agent 长出来的一套外围神经系统。
为什么这一步特别关键
我们以前习惯说”打开某个 AI 工具,然后输入需求”。
而 Gateway 型 Agent 要做的事,刚好是反过来的:
用户在他原本干活的那个地方就直接发起需求,Agent 在背后悄悄完成接收、判断、执行、再写回去。
这个差别比看起来要大得多。它意味着 Agent 不再要求用户改变工作习惯——而你要让一个企业用户打开一个新 App,那比让他改业务流程还要难。Agent 必须像水一样,自己渗进那些已经存在的沟通入口里。
这也是为什么 OpenClaw 这种入口型项目,在落地阶段的工程价值会越来越大:模型在变,工具在变,但”用户从哪里发起任务”这件事,基本是不变的——一个稳定的 Gateway,等于给上层 Agent 留了一条不会被生态变化冲走的接入面。
Hermes Agent 解决的是另一件事:做完别失忆
OpenClaw 解决的是”任务从哪儿来,结果回哪儿去”。
Hermes Agent 解决的是另一个问题——”这次做完,下回我能不能更熟练?”
普通 Agent 的最大毛病:每次都像第一天上班
很多团队的应对方式,就是不停地堆——堆 Prompt、堆聊天记录、堆模板、堆文档。但堆得越多,你会发现复用率反而越低。
为啥?因为这些东西根本没有进到 Agent 的运行机制里去,它们只是散落在系统外面的”文本仓库”。它们躺在 Confluence 里、躺在 Notion 里、躺在某个工程师本地的 markdown 文件里——只在某个工程师碰巧记得的时候,才会被翻出来,粘进 Prompt。这哪是经验沉淀啊,这叫经验考古。
Skills 这个东西,关键在于它是 procedural memory
Hermes Agent 的设计重点,就是把”经验沉淀”这件事真正嵌进 Agent Runtime 里。
它把 Skills 定义成一种 procedural memory——也就是过程性记忆。Skill 不是泛泛的事实记忆,它要回答的是一个具体得多的问题:这类任务,到底该怎么做?
按官方文档的描述,Hermes 的 Skill 是一个目录,里面有一份SKILL.md,可以再附带 references、templates、scripts、assets;到了需要用的时候,会被注入到对话里。
它和普通的 Prompt 模板,有一个根本性的差别:
一个 Skill 实际上装了什么东西
当 Agent 完成一次任务后,如果发现这次的过程值得复用,就可以把它沉淀成一个 Skill。下一次再遇到类似的任务,就不用再发明一遍轮子了。
这一下,Agent 就从”临时问答器”变成了“经验累积器”——也是它和传统脚本最本质的区别:脚本不会变熟,但 Agent 会。
两者叠在一起的核心思路:入口和大脑得分层
OpenClaw 和 Hermes Agent 都支持多平台消息,也都支持工具和 Skills。
但你要把两者叠起来用,最忌讳的就是让它俩抢同一份活。一抢,你得到的就不是 1+1>2,而是两个系统都在做半截活儿、彼此踩脚的混乱。
Hermes Agent 也不用直接管所有消息入口
安全层不用一次性把所有权限都暴露给入口 Agent
分层的本质,就是让每一层都有权”做不好某件事”——因为那件事压根就不归它管。
这种”该做什么、不该做什么”的清晰边界,比”什么都能做”难得多,但也值得多。
OpenClaw 适合扮演的角色,是”入口层”
OpenClaw 自己的文档里,Tools、Skills、Plugins 这三层划得很清晰。Tools 是 Agent 能调用的 typed function,像exec、browser、web_search、message;Skills 是会被注进系统提示词的SKILL.md,负责告诉 Agent 啥时候用、怎么用工具;Plugins 则可以打包 channels、model providers、tools、skills、speech、voice、media understanding 等一堆能力。
意思是,OpenClaw 自己其实也能做一个完整的 Agent。
但叠在一起的时候,得给它”踩刹车”
当它和 Hermes 一起用的时候,我更建议把它放在入口层,而不是核心认知层。
理由很简单——入口层最重要的三样东西,是稳定、清晰、低权限。
如果你让入口层也去搞复杂推理、长期记忆、自我修改 Skills、执行高危命令——那这个系统的可控性就开始崩了。
入口越多,攻击面越大
这是工程上的一条铁律——入口越多,攻击面越大;攻击面越大,权限越得克制。
OpenClaw 的官方工具文档里也给了tools.allow、tools.deny、tool profiles、tool groups 这一系列控制手段,比如可以拒掉exec,只允许文件、浏览器、搜索、消息这些指定的工具组。这些东西不是装饰品,这是在告诉你:入口层就该被默认配成最小权限。
所以叠在一起的时候,OpenClaw 最适合干的事是这些:
多渠道接入 消息标准化
身份和 session 映射
任务转发 结果回写
轻量状态读取 基础通知
Hermes 适合扮演的角色,是”执行脑”
Hermes Agent 的工程价值,主要在于它对 Agent Loop 实现得比较完整。
Agent Loop 真实的复杂度
它的 Agent Loop 会做这些事:组装系统提示词和工具 schema、选 provider/API mode、处理可中断的模型调用、跑工具、维护 conversation history、上下文压缩、重试、fallback model……官方开发文档里说,它支持多种 API 模式——OpenAI 兼容的 chat completions、Codex/Responses API、Anthropic Messages API,然后统一到内部的 message format。
模型一旦返回工具调用,Hermes 要处理:单工具调用、多工具并发、交互式工具串行、危险命令审批、把工具结果写回 history。官方文档讲得很清楚:多工具调用走ThreadPoolExecutor并发执行,但交互类工具会强制串行,危险命令则会触发 approval callback。
这才是 Agent Runtime 的真面目
每一件听起来都不”性感”,但每一件都决定了 Agent 能不能跑得动复杂任务。
特别是iteration budget这件事——它解决的是”Agent 不会陷在自己制造的死循环里出不来”这个非常真实的问题。一个没有预算控制的 Agent,碰上一个它根本搞不定的任务,就会一直重试、一直调工具、一直思考,直到把 token 烧光,或者人工把它拉下来。这种死法在生产环境里成本极高,但在 demo 里你几乎看不到。
Hermes 在叠加方案里的位置
所以叠在一起的时候,Hermes 适合扛起来的活是:
MCP 是这俩之间最干净的工具边界
工具接入是怎么乱起来的
今天接个 GitHub。明天接个数据库。后天接个浏览器。再过几天又来内部 API、文件系统、CMS、部署平台、表格、对象存储……
要是每个工具都直接焊死在 Agent 框架里,最后你得到的就是一锅工具粥——香气可疑,锅底焦黑。
更糟的是,这种耦合一旦形成,后面想拆都拆不动——工具的权限边界、错误处理、版本升级,全都和 Agent 主体死死缠在一起。
MCP 就是来解这个结的
Hermes Agent 对 MCP 的支持,正好是干这个的。
按官方 MCP 文档的说法,MCP 让 Hermes 能去连接外部的 tool servers——GitHub、数据库、文件系统、浏览器栈、内部 API,等等;同时 local stdio servers 和 remote HTTP MCP servers 都支持,启动时可以自动发现并注册工具,还可以做 per-server filtering,只暴露你想暴露的那些。
在叠加架构里,MCP 该放哪里
在 OpenClaw + Hermes 这套组合里,MCP 适合作为 Hermes 的主要工具扩展层:
这比让入口层直接去碰所有工具,要稳得多。入口层默认就是不可信的——消息可以从任何用户、任何渠道飘进来,你让它直接去查数据库、跑命令,那基本相当于把家门钥匙挂在门把手上等小偷来。
Skills 是 Agent 工程里的”肌肉记忆”
如果说 MCP 解决的是”Agent 能连什么工具”,那 Skills 解决的就是”Agent 该怎么用这些工具”。
MCP 是能力接口,Skill 是操作经验
只有工具,没有 Skill,Agent 就像新员工拿着一堆高级设备,但不知道先按哪个开关。
只有 Skill,没有工具,Agent 又会变成纸上流程专家——讲起来花团锦簇,落地时空气打滑。
在叠加方案里,角色怎么分
OpenClaw 和 Hermes 都支持 Skills,但分工可以不一样:
Hermes 负责生成、改进、沉淀 Skills
OpenClaw 负责加载稳定 Skills,在入口侧做轻量执行
共享 Skills 仓库负责版本管理、审查、分发
Skills 资产化,才是关键
这一整套组合,让 Skills 不再只是几段提示词,而是真正能进入工程生命周期的东西。
这才是 Agent 技能资产化的关键所在。资产意味着可审计、可复用、可演进、可被一整个团队一起维护——这事 Prompt 文件夹永远做不到。
而且这背后还有一层影响:一个团队的”Agent 能力”开始变成可以被衡量、被估值的东西,而不再是几个工程师脑子里的隐性知识。
叠加架构里,最怕的就是权限混乱
OpenClaw 和 Hermes 一叠,能力立马变强。但能力一变强,风险也会跟着变强。
这不是危言耸听:已经出过事
OpenClaw 这类系统,本来就要接消息入口、文件、浏览器、命令执行、第三方 Skills——每一个都是潜在的火药桶。公开的安全报道里就出过:OpenClaw 生态里曾出现过恶意 Skills 的问题,集中在第三方 Skill 诱导用户或 Agent 跑恶意脚本、偷敏感信息这些方向。
这不是某个项目自己的事,这是整个 Agent 系统的通用安全悖论:
Agent 越好用,权限越大;权限越大,边界越不能没有。
更麻烦的是,Agent 还引入了一种新的攻击面——通过消息内容做的提示词注入。OpenClaw 这种多入口系统里,一条来自陌生群的消息、一段网页里的隐藏文字、一封邮件里的引用,都可能变成针对 Agent 的攻击载体。这种东西在传统软件安全里根本没有。
权限必须分层拆开
第一层,入口权限。OpenClaw 作为入口,默认就该是低权限的。它可以接消息、转发任务、回写结果,但不该默认就拥有宿主机 shell、敏感目录、数据库写入、批量发消息这些高危能力。
第二层,执行权限。Hermes 作为执行脑,可以摸到更多工具,但要靠 MCP 白名单、沙箱、审批流、工具分级来管住。
第三层,Skill 权限。第三方 Skills 不能直接进生产。带安装命令、脚本、浏览器操作、读凭据、钱包相关、SSH、系统目录访问的 Skill,全部都得审。
第四层,记忆权限。长期记忆不是垃圾桶,什么都往里塞会出大事。用户隐私、Token、密钥、内部数据、临时敏感信息,这些都不该进可长期复用的 Memory 或 Skill。
一套能落地的六级权限模型
这不是什么理论模型,这是从真实事故里反推出来的最小防御边界。每一级的边界,背后都对应着一个真实发生过、付了代价的失败案例。
Agent 工程里,安全不是事后补的墙纸,它得是地基里的钢筋。
把它们组合起来,是这样一套架构
把 OpenClaw 和 Hermes Agent 叠起来,可以形成这样一整套技术架构:
这套架构最大的好处,就是每一层都只做自己最擅长的那件事:
而且这种分层还有一个被低估的好处——任何一层都可以被换掉。明天出来一个比 Hermes 更猛的 Runtime?把中间那层换了。出来一个比 OpenClaw 更好的 Gateway?把最上面那层换了。MCP 协议演进?换工具层适配。这种可替换性,本身就是工程稳定性的一个重要来源。
真正的变化:Agent 从”工具调用”走向”运行系统”
OpenClaw + Hermes Agent 叠在一起,带来的不是一个”功能更多了”的 Agent,而是Agent 形态本身的变化。
从一个能力点,到一整个系统
早期的 Agent 大概就是模型 + 工具调用 + 聊天界面;现在开始变成入口层 + Runtime + Memory + Skills + MCP + Sandbox + Audit。
这意味着,Agent 工程正在从”写 Prompt”走向”搭系统”。
Prompt 还重要,但它只是其中一层。工具也重要,但工具不是全部。模型能力很关键,但模型替代不了架构。
Agent 工程化真正的门槛
这些问题,才是 Agent 从 Demo 走向工程化真正要迈的门槛。
而且这些问题之间是有优先级的——你可以模型差一点,但不能没审计;可以工具少一点,但不能没权限边界;可以 Skill 少一点,但不能没记忆机制。Agent 工程的成熟度,某种程度上就是看一个团队在这些问题上能答到第几层。
一种新的软件形态,正在浮出水面
OpenClaw 和 Hermes Agent 摆在一起看,真正值得注意的不是”谁更强”。
而是它们刚好代表了 Agent 工程里最关键的两个方向:
OpenClaw 让 Agent 拥有了入口和触达能力。Hermes Agent 让 Agent 拥有了记忆和经验沉淀能力。
这两件事一旦合上,Agent 就不再只是一个会答题的模型,也不再只是一个会调工具的脚本。
一个能长期跑、能接外部事件、能调工具、能沉淀技能、能跨会话复用经验的智能运行系统。
不是又多了一只会说话的机器鸟。而是软件这个东西,终于开始长出一点会记路的神经。
而当我们意识到这件事之后,后面真正值得追问的,也就不再是”哪个框架更强”了,而是:我的团队,接下来要怎么为这种新形态的软件,重新设计自己的工程方法、协作流程,甚至是组织结构。
夜雨聆风
