一文搞懂Hermes Agent 前世今生

一、Hermes Agent 是怎么长出来的

如果只看它的 GitHub 首页，Hermes Agent 很容易被误读成又一个“AI agent 框架”：一个可以接模型、调工具、跑命令、接消息平台的工程项目。但如果把时间线拉长，你会发现它真正想解决的，并不是“让模型多调用几个工具”，而是一个更野心勃勃的问题：

能不能把 AI agent 从一次性会话工具，变成一种持续存在、会积累、会反思、会迁移的长期系统？

这其实就是 Hermes Agent 从诞生起的主线。

1. 起点：不是从“写代码助手”出发，而是从“长期存在的代理”出发

Hermes Agent 的出身，和很多 AI 应用很不一样。

多数 2023-2025 年涌现出来的 agent 产品，起点是两个方向之一：
一类从 IDE/coding copilot 出发，目标是让模型在代码编辑、调试、终端执行里更顺手；
另一类从 chatbot + tools 出发，核心是让对话系统接 API、能联网、能调用 MCP 或浏览器。

Hermes Agent 的 framing 更激进。官方首页直接把它定义成：

“The agent that grows with you.”¹

这句话不是宣传口号那么简单，它几乎概括了整个产品哲学：
Hermes Agent 不是为了在单次任务里“答得更好”，而是为了在多次任务、跨会话、跨平台的累积中“变得更像你的 agent”。

从文档与官网描述来看，它最初的核心差异点不是单个工具能力，而是三个互相咬合的机制：

Persistent memory：记忆不是上下文窗口里的临时 token，而是跨会话留存的结构化资产；
Auto-generated skills：不是只会调用既有工具，而是会把经验沉淀为技能文档；
Self-improvement loop：技能与记忆相互强化，让 agent 在长期使用中“长出来”。¹²

这意味着 Hermes Agent 的真正竞争对象，从一开始就不只是某个聊天应用，而是整个“会话式 AI 工具范式”。

2. 诞生背景：它踩在两个时代交叉口上

Hermes Agent 出现的时点非常关键。根据公开报道与官方资料，它在 2026 年 2 月 上线，首个公开版本可追溯到 v0.1.0，2026 年 2 月 25 日 左右³⁴。这个时间点背后，其实有三股已经酝酿成熟的力量。

第一股：模型能力终于足够稳定，能支撑“长链条代理”

到 2025 年后期，业界已经逐渐形成共识：
模型不再只是“生成文本”，而是可以稳定完成工具调用、规划、搜索、代码执行、多轮修正等 agentic 工作流。Hermes Agent 文档里显式支持多种 API 模式：

chat_completions
codex_responses
anthropic_messages²

这说明它不是为某一家模型 API 写死的产品，而是在适配“多模型、多协议并存”的现实。换句话说，Hermes Agent 诞生时，外部环境已经不是“哪个模型最强”，而是“不同模型在不同 agent 环节各有所长，编排成为核心能力”。

第二股：用户开始厌倦“一次性聊天”

很多人真正对 agent 产生兴趣，不是因为它回答得更像人，而是因为它终于记得住事、会自己做后续动作、能跨平台继续工作。
Hermes Agent 官方把自己放在服务器、本地和云环境中运行，支持 CLI、Telegram、Discord、Slack、WhatsApp、Signal、Email、Matrix、Mattermost、SMS、DingTalk、Feishu、WeCom 等统一网关¹²。这本质上是在说：

“AI 不该只活在一个聊天框里，它应该像一个长期在线的数字执行体，出现在你真正工作的地方。”

第三股：OpenClaw 之后，市场需要一个“更工程化、更安全、更可长期运营”的替代方向

从迁移文档看，Hermes Agent 官方明确为 OpenClaw 用户提供了完整迁移路径：hermes claw migrate，并能导入 OpenClaw/ClawDBot/Moltbot 的记忆、用户资料、技能、配置与密钥⁵。
这件事很关键。它说明 Hermes 不是在一个真空环境里横空出世，而是有意识地承接已有 agent 用户群。也就是说，它不是从零教育市场，而是在一个已经被更早期 agent 产品点燃的需求面前，给出新的工程答案。

所以，Hermes Agent 的诞生背景可以概括成一句话：

当“AI agent”从炫技 demo 进入长期使用阶段，Hermes Agent 试图重新定义这个品类的底层操作系统。

3. 初始形态：一个不是 IDE 插件、不是聊天壳、而是“常驻代理系统”的产品

从官网和 GitHub 的最初自我描述看，Hermes Agent 一开始就没有把自己做成一个轻量插件，而是一个相对完整的运行时系统。它的基本骨架包括：

CLI 入口：hermes chat、hermes model、hermes tools⁶
Gateway：统一连接消息平台与外部入口²
Agent 核心：AIAgent 与 run_agent.py²
Session storage：SQLite + FTS5，保存在 ~/.hermes/state.db²
Skills：本地目录化管理，标准文件为 SKILL.md²
Memory：MEMORY.md 与 USER.md 双层长期记忆²
Cron/automation：内置定时机制¹
多 terminal backends：本地、Docker、SSH、Singularity、Modal，文档中还出现 Daytona¹²

这套初始结构透露出一个非常鲜明的产品判断：

Hermes Agent 不认为 agent 的核心只是“调用一个模型”，而是“围绕模型搭一整套长期运行环境”。

这也解释了为什么 Hermes 从一开始就特别强调 profile isolation、日志、安全审批、容器隔离、跨会话隔离等工程特性²。
如果你只是做一个聊天机器人，这些东西都不是第一优先级；
但如果你想让 agent 真正跑在用户机器、服务器、团队工作流里，这些恰恰是最先会出问题的地方。

4. 早期爆发：为什么它一出来就吸引大量关注

Hermes Agent 在上线后很快获得极高关注度。你此前整理的仓库数据里，抓取时 GitHub 已经达到 75k+ stars、10k forks、4000+ commits⁶。外部报道则多次提到它在短时间内迅速攀升、成为 OpenClaw 之外最受关注的 agent 项目之一³⁷。

这波爆发不是偶然，背后有几个叠加因素。

4.1 它精准踩中了用户对“更像系统，而不是应用”的期待

很多 agent 项目给人的第一印象是功能炫，但一落到长期使用就散：
今天能自动浏览网页，明天能跑 shell，后天能调 MCP，听起来都很强；
但用户真正要的是：它能不能持续记得我、替我维持状态、在一周后继续同一个任务？

Hermes Agent 正好把“持久化”做成第一性原理。
MEMORY.md 与 USER.md 的设计并不复杂，甚至有点朴素，但这恰恰说明它优先考虑的是可控性与可调试性：你知道记忆放在哪、上限多大、如何被注入到 session、何时冻结成快照²。
这和很多“黑箱长期记忆”方案不同，它更像工程系统，而不是魔法系统。

4.2 它抓住了“技能沉淀”这个非常上瘾的点

官方把 Skills 设计成显式资产：

存在于 ~/.hermes/skills/
以 SKILL.md 为标准格式
兼容 agentskills.io
支持 browse/search/inspect/install/update/audit/uninstall
支持多种 hub：official、github、clawhub、claude-marketplace、lobehub 等²

这里真正聪明的地方是：Hermes Agent 没有把“经验”封装成不可见的参数优化，而是把它转成可以查看、编辑、迁移、分享、审计的技能文件。
这让用户第一次感到：agent 的成长是可见的、可继承的、可协作的。

4.3 它在“开放性”和“工程感”之间找到了一个平衡

很多 agent 项目在开放性上做得很好，但工程治理弱；另一些则很企业化，但不够开放。
Hermes Agent 的路线是：

MIT License
支持任意 endpoint
支持 Nous Portal / OpenRouter / OpenAI / Ollama / Gemini 等多 provider¹²⁸
同时又重视审批模式、安全隔离、日志、配置校验、恶意软件扫描等²⁹

这种组合对开发者很有吸引力。因为它既不像封闭 SaaS 那样把控制权拿走，也不像很多开源项目那样把所有稳定性责任都推给用户。

5. 演进主线：Hermes Agent 不是“加功能”，而是在补齐长期代理的基础设施

如果把 Hermes 的版本演进简单看成“新版本加了哪些功能”，会低估它的发展逻辑。它更像是在快速搭建一座长期代理的城市基础设施：先有道路，再有电力，再有治安系统，再有物流网络。

截至公开资料中的 v0.8.0（v2026.4.8），几个明显的演进方向已经成形。⁹

5.1 第一条主线：从“能跑起来”到“能长期在线”

早期 agent 最常见的问题不是不会做事，而是跑不久：
会话断掉、状态丢失、任务没法异步继续、平台消息不同步、模型切换麻烦。

Hermes 在 v0.8.0 里加入或强化了这些能力：

notify_on_complete：后台任务完成自动通知
inactivity-based timeout：闲置超时控制
centralized logging：统一日志到 ~/.hermes/logs/
config validation：配置校验⁹

这些改动看起来不像“炫技功能”，但对长期运行非常关键。
因为一个常驻 agent 最大的敌人，从来不是“不够聪明”，而是“不够稳定、不够可观测”。

从这个角度看，Hermes 的决策逻辑很清楚：
先把 agent 变成一个可靠服务，再把它变成一个聪明角色。

5.2 第二条主线：从“单模型绑定”到“多 provider 编排”

Hermes Agent 在模型层面明显走的是中立基础设施路线。
它支持：

Nous Portal
OpenRouter
OpenAI
任意 OpenAI-compatible endpoint
Ollama 本地/云模型
新增 Gemini Native Provider¹⁸⁹

而且 /model 支持运行中切换模型，全平台 live model switching 在 v0.8.0 被强调⁹。

这背后的判断其实非常现实：
2026 年的 agent 世界里，不存在一个模型在所有环节都最优。
有的模型擅长长文本规划，有的擅长低成本工具调用，有的更适合本地部署，有的在某些 provider 上更便宜。

所以 Hermes 不押注“唯一最强模型”，而是押注模型切换能力本身成为 agent 的基础能力。
这是一种很像云计算时代的设计思路：
不是把业务绑在某台机器上，而是把调度能力做强。

5.3 第三条主线：从“工具调用”到“代理分工”

Hermes 一个很有辨识度的点，是它不仅能调工具，还能delegate & parallelize，即创建 isolated subagents 来分工处理任务¹。
这让它不只是一个“会用工具的 LLM”，而是开始接近“任务执行系统”。

从架构与 issue 线索看，Hermes 已经把不同 delegation 模式显式化，甚至包括 claude-code、codex、hermes-agent 等代理方式的区分讨论¹⁰。
这说明团队很清楚：
当 agent 任务变复杂时，真正限制性能的不是单次回答质量，而是任务拆分、并行执行、上下文隔离、子任务回收。

这里的决策逻辑也很明显：
如果 Hermes 真想成为长期代理，而不只是会聊天的助手，它必须学会像一个操作系统那样调度，而不是像一个单线程脚本那样硬跑到底。

5.4 第四条主线：安全从附加项变成主产品能力

Hermes 文档里的安全模型相当完整，官方把它分成七层：

user authorization
dangerous command approval
container isolation
MCP credential filtering
context file scanning
cross-session isolation
input sanitization²

再到 v0.8.0 又加上：

MCP OAuth 2.1 PKCE
OSV malware scanning
platform hardening
security hardening pass⁹

这一点非常关键。很多 agent 项目在早期都把安全写成“之后再补”，但 Hermes 明显把它上升到第一层设计。
原因不难理解：
它的目标不是浏览器里的一次性问答，而是能控制终端、接消息平台、长期持有状态、甚至定时执行任务的代理。
这种系统一旦缺安全层，就不是体验问题，而是事故问题。

Hermes 的安全策略不是完全封闭，而是“给你权限，但通过审批模式和隔离层控制风险”：

manual
smart
off
YOLO mode 可主动关闭保护²

这说明团队没有天真地认为“用户不需要危险能力”，而是承认现实：
高级用户就会想开大权限。
所以产品要做的不是禁止，而是把风险的边界画清楚。

5.5 第五条主线：从“自己长”到“能迁移、能继承、能兼容生态”

Hermes 很聪明的一步，是没有把自己做成一个孤岛。

在 Skills 上，它兼容 SKILL.md 及多个 hub 来源；
在 Memory 上，它允许接入 Honcho、Mem0、Supermemory 等外部 provider；
在迁移上，它明确支持从 OpenClaw 体系导入记忆、配置、技能和 secrets²⁵。

这意味着 Hermes 的野心不是只做一个“新项目”，而是试图成为一个上层兼容层。
它希望用户不是“重装人生”才能换 agent，而是带着自己的历史、习惯和技能资产迁移过来。

这个决策很重要。因为长期代理的壁垒，不只是模型能力，而是用户积累资产的可携带性。
Hermes 在这点上显然想得很明白：
一旦用户的记忆、技能、路由、平台接入、工作流都沉淀在系统里，迁移成本会越来越高；
但前提是，第一次迁移必须足够丝滑。

6. 关键节点：v0.8.0 为什么是一个阶段性拐点

从版本节奏看，Hermes 在很短时间里快速迭代，而 v0.8.0（2026-04-08） 是一个很典型的“从爆款项目走向平台化”的节点。⁹

这个版本的亮点表面很多，但如果抽象一下，可以归为四个信号：

信号一：它开始正式补后台运行体验

notify_on_complete、timeout、日志集中化——这说明产品不再只围绕“前台对话”，而是在为异步、长期、不可见执行做体验闭环。

信号二：它开始把 provider 管理做成一等公民

Gemini Native Provider、OpenRouter/Nous Portal 定价显示、free-tier 模型入口、live switching——这标志着它把“模型接入”从技术配置变成用户体验层功能。

信号三：它把平台审批和安全治理更深地嵌到消息入口里

Slack/Telegram approval buttons 很能说明问题：
Hermes 不只是把消息平台当输入通道，而是把它们当 agent 治理界面。
用户不一定要回到本地终端批准动作，可以在消息端完成审批，这对真正的长期代理非常关键。

信号四：它开始从一个 agent 项目，长成一个插件平台

plugin system expansion 不只是加插件，而是在暗示：
Hermes 团队逐渐接受一个现实——长期代理的所有需求不可能靠官方核心仓库覆盖，必须把扩展性做出来。⁹

所以，v0.8.0 的意义不是“又多了几个 feature”，而是：
Hermes 从‘有想法的 agent’开始迈向‘有平台气质的 agent runtime’。

7. 源码和架构透露的组织思路：Hermes 想做的更像“Agent OS”

看 Hermes 的源码结构，会发现它并不是那种“把所有能力塞进一个 orchestrator 文件”的实验项目。
关键目录与文件——如 run_agent.py、model_tools.py、toolsets.py、gateway/、cron/、plugins/memory/、plugins/context_engine/、skills/——已经体现出比较明确的边界划分。²

这种划分对应着几个产品层：

Agent brain：推理、规划、工具调用
Execution environment：terminal backends、container、remote execution
Persistence layer：state.db、memory files、sessions
Ingress/egress layer：CLI、gateway、ACP adapter
Learning layer：skills、memory、trajectory export、RL 训练接口
Security/governance layer：approval、scanning、credential filtering、logs

这个结构特别像一个“agent operating environment”，而不是一个单纯应用。
也正因此，它和传统 IDE agent 最大差别之一是：
它的世界不是一个编辑器窗口，而是整个用户环境。

8. 约束与代价：Hermes 为什么没有把一切都做成最简单

Hermes 的路线有明显优势，但也伴随代价。

8.1 它天然更复杂

当一个系统同时拥有：

多模型 provider
多 terminal backend
多消息平台 gateway
memory + skills + cron + plugins
审批、安全、容器、日志

它就不可能像一个单文件 CLI 工具那样轻。
官方虽然提供 hermes setup 和安装脚本降低门槛⁶，但 Hermes 本质上仍然是一个可运营系统，不是极简玩具。

8.2 文档和实现还处在快速变化期

你前面已经发现一些口径差异：

工具数量有 47 / 48 两种说法
terminal backends 有 5 / 6 两种口径¹²

这通常不是原则性问题，而是快速迭代项目常见的“文档更新速度追不上实现变化”。
它反过来也说明：Hermes 还远没有进入稳定企业软件阶段，仍然处于高速进化期。

8.3 它的价值高度依赖“长期使用”

Hermes 最强的地方——记忆、技能、自我优化——都不是“5 分钟就能感知”的能力。
这意味着它对新用户的第一印象，反而未必像即时见效的 coding agent 那么炸裂。
它更像一种复利型产品：
用得越久，越能体现差异；但前提是用户愿意先投入搭建和使用习惯。

9. 到今天为止，Hermes Agent 已经成了什么

如果把这段发展史压缩成一句话：

Hermes Agent 从一开始就不是想做“一个更强的 AI 对话工具”，而是在用开源方式搭一套长期存在、可自我积累、可跨平台运行的 agent 基础设施。

截至 2026 年 4 月，它已经表现出几个明确特征：

它是一个模型中立的 agent runtime，而不是某家模型厂商的外壳；
它是一个长期状态系统，而不仅是“更会调用工具的聊天机器人”；
它是一个兼顾开放性与治理能力的工程平台；
它正在从“爆红项目”向“生态平台”过渡；
它和 OpenClaw 并不是简单替代关系，更像是在同一个大方向上给出不同答案：一个更偏广覆盖和外部生态，一个更偏长期成长和系统内化。

二、横向分析：Hermes Agent 在同赛道里处于什么位置

Hermes Agent 所在赛道并不空。它至少同时站在三个竞争面前：

长期自主代理框架：如 OpenClaw
开发者/代码导向 agent：如 Claude Code、Codex 类工具
更通用的 agent 执行系统/多代理框架：如 OpenHands 一类

因此这里属于你定义中的 场景 C：竞品充分。
我选取 4 个最具代表性的参照对象：

OpenClaw
Claude Code
OpenHands
Codex / Codex-style coding agents

其中，OpenClaw 是最核心的正面对手；其余几个更像“相邻生态位”。

1. Hermes Agent vs OpenClaw：最像正面战争，但其实路线不同

如果只看外界舆论，Hermes 最常被贴上的标签就是“OpenClaw 替代品”。这标签不能说错，但不够准确。

1.1 两者最接近的地方：都想把 agent 从聊天框里解放出来

Hermes 与 OpenClaw 的共性很明显：

都是开源 agent 框架
都强调长期运行与跨平台入口
都不满足于“只做代码助手”
都在尝试把 AI 变成一个可以执行真实任务的实体³⁵⁷

这也是为什么 Hermes 官方专门做了 OpenClaw 迁移工具。
因为它们争夺的是同一批已经理解 agent 价值的人：
不是来试玩模型的，而是想让 AI 真正接管部分工作流的用户。

1.2 真正的差异：OpenClaw 更像“连接性平台”，Hermes 更像“成长性系统”

从公开资料与第三方对比来看，OpenClaw 的强项长期在于：

覆盖面广
平台集成多
社区大
上手路径更成熟³⁷

而 Hermes 的差异化在于：

persistent memory 的叙事更核心
auto-generated skills 是产品哲学中心
自我优化/学习闭环被放到第一位
安全与治理被写进系统设计，而非附加模块¹²⁹

简单说：

OpenClaw 的问题意识：怎么让 agent 去更多地方、干更多事
Hermes 的问题意识：怎么让同一个 agent 在时间中越来越有用

这不是小差别，而是路线分岔。

1.3 用户为什么选 OpenClaw

真实用户选择 OpenClaw，往往不是因为它“理念更高级”，而是因为它更像一个已经铺开的世界：
平台多、生态多、参考案例多、社区讨论多。
如果你的第一诉求是“赶紧把 agent 接进一堆平台和自动化流程里”，OpenClaw 的现成度通常更强。

1.4 用户为什么转向 Hermes

而选 Hermes 的用户，往往在意的是另一件事：
这个 agent 会不会随着使用真正变成我的东西。

这也是 Hermes 迁移工具存在的意义。它在对用户说：
你不是要重新换一个玩具，而是把之前积累的“人格、记忆、技能和习惯”迁过来，继续长。

1.5 口碑层面的差别

从第三方报道和讨论看，Hermes 的高频优点包括：

更强调长期记忆
自生成技能更有“成长感”
安全治理叙事更完整
provider 更灵活³⁷

常见顾虑则是：

系统复杂
需要配置与维护
快速迭代带来文档口径差异
真正价值要长期使用后才能显现

OpenClaw 则常被认为：

覆盖广、平台多、声量大
生态成熟
更适合“我先全都接起来”
但弱点在于：
如果用户核心诉求是“长期个体化成长”，Hermes 的故事更打人

1.6 生态位判断

在赛道版图里，OpenClaw 更像一个广覆盖型超级入口；
Hermes 更像一个高复利型长期代理内核。

如果未来 agent 市场分化，这两类产品甚至可能长期共存，而不一定只有一个赢家。
因为它们优化的并不是完全同一个目标函数。

2. Hermes Agent vs Claude Code：一个是“代理系统”，一个是“代码工作界面”

把 Hermes 和 Claude Code 放在一起比较，最容易看出 Hermes 的边界。

2.1 Claude Code 的强项：把 coding agent 体验做到极顺

Claude Code 一类工具的优势很明确：

聚焦软件开发工作流
IDE / repo / shell 场景极强
对开发者来说，反馈快、路径短、结果立竿见影

用户用 Claude Code，往往是为了今天就把一个 bug 修了、一个重构做了、一个 PR 过了。
它的设计目标是把开发活动本身变流畅。

2.2 Hermes 不把自己限制在“开发行为”里

Hermes 当然也能做代码、能进终端、能 delegation、能调工具。
但它真正的目标不是“让开发更高效”，而是“让 agent 成为长期工作实体”。

这意味着 Hermes 的应用范围更广：

日程与消息平台
定时任务
研究任务
跨会话用户模型
多入口通信
记忆与技能沉淀

所以两者不是简单替代关系。更准确的说法是：

Claude Code：把 AI 嵌进开发者的现有工作界面
Hermes Agent：试图把 AI 变成一个独立存在的执行体，再去连接各个界面

2.3 用户真实选择逻辑

如果你是一个纯开发者，目标非常明确：
“我需要一个今天就能提高 coding throughput 的助手。”
Claude Code 通常更直接。

但如果你的需求是：
“我希望有一个长期在线、会记事、能跨平台沟通、还能顺手写代码的 agent。”
Hermes 才会显得更对味。

2.4 短板比较

Hermes 相对 Claude Code 的短板在于：
它不是围绕 IDE 极致打磨出来的体验；
它强在系统性，而不是单一 coding 界面的摩擦最小化。

换句话说，Claude Code 更像一把极锋利的手术刀；
Hermes 更像一整套可以常驻运转的工作站。

3. Hermes Agent vs OpenHands：一个偏“任务执行系统”，一个偏“长期人格化代理”

OpenHands 这类系统，代表的是另一种 agent 方向：
更重任务执行、更强调 benchmark、环境操作、代码修复、自动完成复杂开发任务。

3.1 OpenHands 的世界观

OpenHands 类产品往往把 agent 理解成一个高能力执行器：
你给它任务，它自己去浏览、编码、运行、修复。
它很适合用来展示 agent 在复杂任务链上的能力上限。

3.2 Hermes 的世界观不完全一样

Hermes 也做执行，但它多了一层“长期关系”的设定：

USER.md / MEMORY.md
skills 沉淀
gateway 平台常驻
cron 自动化
profile isolation
session search²

这让 Hermes 更像一个与你共处的长期代理，而不是一个接到任务就开始冲刺的执行引擎。

3.3 用户口碑差异

选择 OpenHands 的用户，通常更看重：

自动完成复杂技术任务的能力
agent benchmark 表现
软件工程任务链上的强执行

选择 Hermes 的用户，则更在意：

是否会记住我和过去
是否能在多入口下保持一个连续身份
是否会沉淀技能和习惯
是否适合长期部署

3.4 生态位

OpenHands 更像“高性能任务机器人”；
Hermes 更像“长期关系型代理”。
如果把 agent 看作未来的软件形态，OpenHands 在强调“能力峰值”，Hermes 在强调“时间复利”。

4. Hermes Agent vs Codex / Codex-style coding agents：不是同一主赛道，但会争夺开发者时间

Codex-style agent 的最大优势，是高度贴近代码生产场景。
它们经常被用于：

代码生成与修复
测试
repo 级上下文理解
shell 操作
PR 辅助

Hermes 当然也可以接这类场景，甚至 issue 中已讨论与 Codex delegation 的结合¹⁰。
但 Hermes 不会在“专用 coding 体验”上天然领先，因为它的注意力分散在更大的系统版图里。

不过，Hermes 对这类工具也并不是纯粹被动竞争。
它有一个聪明的策略：把这类 agent 当成可调用子能力，而不是非要正面打穿。

这意味着 Hermes 完全可能形成一种上层定位：

自己负责长期记忆、任务路由、平台入口、安全治理
把特定 coding 子任务委托给 Claude Code / Codex / 其他 specialized agents

如果这条路走通，Hermes 就不是和所有专业 agent 正面打，而是站在更高一层调度它们。

三、横向对比表：一句话看懂 Hermes 的位置

维度	Hermes Agent	OpenClaw	Claude Code	OpenHands	Codex-style Agents
核心定位	长期成长型自主代理	广覆盖型 agent 平台	开发者代码助手/界面	高执行力任务 agent	专用 coding agent
主叙事	记忆 + 技能 + 自我改进	平台接入 + 生态 + 广覆盖	提升 coding throughput	自动完成复杂技术任务	代码执行与修复
时间维度	强	中-强	中	中	中
跨平台常驻	很强	很强	弱	中	弱
记忆系统	核心卖点	有，但非唯一中心	有限	较弱/非核心	通常非核心
技能沉淀	核心卖点	有生态，但不如 Hermes 强叙事	非核心	非核心	非核心
安全治理	明确系统级设计	视实现而定	相对成熟但场景更窄	偏任务执行治理	偏开发场景治理
上手门槛	中-高	中	低-中	中	低-中
最适合谁	想长期养一个 agent 的用户/团队	想快速铺平台与生态的用户	纯开发者	自动任务导向开发者	以代码产出为第一目标的用户

四、趋势判断：Hermes Agent 接下来最可能怎么走

1. 它最大的机会：把“长期代理”从概念做成真实品类

Hermes 最值钱的地方，不是又多支持几个平台，也不是再多一个模型 provider。
而是它有机会把一个此前很模糊的需求做清楚：

用户要的不是一次性更聪明的 AI，而是一个长期越来越懂自己、越来越能代办事情的数字代理。

如果 Hermes 持续把 memory、skills、delegation、gateway、cron、安全治理整合好，它会成为这个品类最清晰的代表之一。

2. 它最大的风险：复杂度吞掉增长

Hermes 的问题不是没功能，而是功能太容易长成系统复杂度。
当一个产品既想：

做多模型
做多平台
做技能市场
做长期记忆
做插件
做安全治理
做迁移兼容

它很容易进入“每一项都重要，但新用户不知道先感知哪个”的困境。

所以 Hermes 接下来能不能继续扩张，取决于它能否把复杂系统包装成足够顺滑的默认体验。

3. 它最聪明的战略方向：做 agent runtime，而不是和所有垂直 agent 抢单点体验

Hermes 如果执意在每个子场景都打赢专业工具，成本会非常高。
更好的路可能是：

继续做长期记忆与身份连续性
做多平台入口与治理
做技能沉淀与可迁移资产
把 Claude Code、Codex、OpenHands 一类工具吸纳为 delegation target

这样 Hermes 就不只是一个 agent，而是一个agent 之上的协调层。

4. 对企业与团队市场的潜力

Hermes 现在看上去更像开发者/极客项目，但它的一些特性其实很适合团队化：

profile isolation
centralized logs
approvals
credential filtering
gateway
plugin system
external skills dirs²⁹

如果未来文档、部署、权限管理进一步成熟，它很可能从个人长期代理，延伸到小团队或组织级 agent runtime。

五、横纵交汇：Hermes Agent 现在到底站在哪儿

Hermes Agent 最值得注意的地方，不是它“像谁”，而是它试图修正过去几波 agent 热潮里最根本的缺口。

过去的 AI 工具，大多有两个问题：
一类擅长单次交互，但没有连续人生；
另一类能跑复杂流程，但每次都像失忆后重新开工。
Hermes 想解决的是这个断裂：
让代理既能执行，又能积累；既能跨平台行动，又能保持同一个长期身份。

这也是为什么它的纵向发展和横向竞争，其实指向同一个结论。

从纵向看，Hermes 的每一步演进——记忆、技能、迁移、provider 中立、delegation、安全治理、日志、cron——都不是随机堆 feature，而是在补一套“长期代理基础设施”的骨架。
从横向看，它与 OpenClaw、Claude Code、OpenHands、Codex-style tools 的差别，也不只是功能列表不同，而是优化目标不同：

OpenClaw 更强调广连接和生态铺设；
Claude Code / Codex 更强调单场景产能；
OpenHands 更强调复杂任务执行；
Hermes 最鲜明的目标，是让 agent 在时间里形成复利。

因此，Hermes 当前的真实位置，我会这样判断：

1. 它不是“另一个 coding agent”，而是“长期代理操作层”的候选者

这决定了它的成败标准，不能只看短期 demo 效果，而要看：

长期稳定性
资产沉淀能力
迁移与兼容
用户是否愿意把更多日常工作交给它

2. 它现在已经有了很强的叙事和很快的工程推进，但仍处于高速塑形期

GitHub 热度、版本速度、外界关注，都说明 Hermes 已进入主流开发者视野。
但口径差异、功能快速扩张、复杂度上升，也说明它离“成熟平台”还有路要走。

3. 如果未来 agent 市场真的从“短会话工具”升级到“常驻数字代理”，Hermes 会是非常有代表性的基础设施玩家

尤其是在开源生态中，它已经明确占住了一个位置：
不是最轻、不是最窄、也不是最现成，但可能是最认真在搭长期代理系统的人之一。

4. 最后的判断

Hermes Agent 当前最有价值的，不是某个具体 feature，而是它正在证明一件事：

AI agent 的护城河，不一定来自更强的模型，也可以来自更长的时间维度。

谁能让 agent 真正记住、沉淀、迁移、治理、持续存在，谁就更接近下一代软件形态。
在这条路上，Hermes Agent 现在还谈不上“已经赢了”，但它已经非常清楚自己在打什么仗，而且比很多竞争者更早把战场选对了。

参考来源

来源链接

GitHub: https://github.com/NousResearch/hermes-agent
Releases: https://github.com/NousResearch/hermes-agent/releases
官网: https://hermes-agent.nousresearch.com/
文档: https://hermes-agent.nousresearch.com/docs/
OpenClaw 迁移指南: https://hermes-agent.nousresearch.com/docs/guides/migrate-from-openclaw
OpenRouter 应用页: https://openrouter.ai/apps/hermes-agent
Ollama 集成页: https://docs.ollama.com/integrations/hermes
The New Stack 对比文章: https://thenewstack.io/persistent-ai-agents-compared/