当前位置：首页 > news >正文

Hermes Agent 为什么突然火了？它和 Claude Code、Codex CLI、Gemini CLI 有什么区别？

news 2026/4/23 4:06:19

关注霍格沃兹测试学院公众号，回复「资料」, 领取人工智能测试开发技术合集

导读

最近 Hermes Agent 被频繁提起，不是因为它只是又多了一个 Agent CLI，而是因为它试图把很多原本分散的能力放进同一套运行时里：长期记忆、技能沉淀、子 Agent、定时任务、多平台消息入口、MCP、多种执行后端，以及开放的模型接入方式。Hermes 官方对自己的定位很直接，核心卖点不是“更会聊天”，而是built-in learning loop、persistent memory、auto-generated skills这一整套持续运行能力。

这也是 Hermes Agent 值得讨论的原因。很多 AI Agent 仍然更像“在终端里工作的助手”，而 Hermes 想做的，是一个可以跨会话、跨平台、跨环境持续运行的 Agent 系统。这个差别，才是它最近热度上来的关键。

一、Hermes Agent 为什么突然被频繁讨论

Hermes Agent 最近被反复提起，最重要的原因，是它把 AI Agent 的讨论从“单轮回答能力”往“长期运行能力”推了一步。官方文档里，它最强调的不是单次对话，而是学习闭环、跨会话记忆、技能自动生成、调度运行和多入口接入。换句话说，Hermes 的目标不是只在当前窗口里帮你完成一次任务，而是让 Agent 在后续任务里继续沿用之前积累下来的经验。

另一个原因，是它把“入口”和“执行环境”拆开了。 Hermes 不只跑在 CLI 里，它还有长期运行的 messaging gateway；同时它的终端执行环境支持 local、Docker、SSH、Modal、Daytona、Singularity 六类 backend。用户入口和任务执行不再强绑定在同一台机器、同一个终端会话里，这一点对自动化、后台任务和跨设备使用都很关键。

再往深一点看，Hermes 还带着比较明显的“研究系统”特征。它的官方文档里不仅有日常使用能力，也有 trajectory generation、RL environments 之类更偏训练与实验的数据闭环能力。这说明它不是单纯在做一个产品壳层，而是在尝试搭一套更完整的 Agent runtime。

二、它和主流 AI Agent 的差别，重点不在“谁功能更多”

写 Hermes Agent 这类文章，最容易写偏的地方，就是把它写成“全面碾压型选手”。这种写法不够稳，因为 Claude Code、Codex CLI、Gemini CLI、Goose 和 Hermes Agent，本来就不完全在解同一个问题。它们有交集，但产品重心并不一样。

Claude Code 的重心仍然非常明确：它是一套围绕代码工作流展开的 agentic coding tool，覆盖 terminal、IDE、desktop、browser，还支持 MCP、hooks、auto memory、agent teams，甚至 Terminal CLI 和 VS Code 也支持 third-party providers。它很强，但更偏研发协同和代码工作流。

Codex CLI 的边界也很清楚：它是 OpenAI 的本地终端 coding agent，强调在选定目录里读、改、跑代码，支持 MCP、subagents、sandbox、web search 和 cloud tasks。它的优势是本地代码任务执行链路很完整，但重点仍然是 coding workflow，而不是消息平台常驻和长期记忆系统。

Gemini CLI 也不能再按早期印象去写成“功能简化版”。官方 README 和命令文档已经明确给出 MCP、GEMINI.md 层级记忆、checkpointing、hooks、subagents、skills、IDE integration 等能力。它依旧是 terminal-first 路线，但已经不是一个只会聊天或只会跑几条命令的轻量工具了。

Goose 则更像开放型、本机优先的通用 agent。官方首页直接写了 Desktop、CLI、API、15+ providers、70+ MCP extensions、skills、recipes、subagents、安全控制等能力。严格说，Goose 才是 Hermes 在“开放生态通用 Agent”这条线上最值得正面对比的对象之一。

所以，Hermes Agent 真正特别的地方，不是“它会的别人都不会”，而是它把学习、记忆、调度、多入口、执行环境切换这些能力，压进了一套统一运行时里。这个设计取向，和“单纯做一个更强的代码助手”不是一回事。

三、一张表看清 5 类主流 Agent 的产品重心

产品	官方重心	典型能力	更偏向的场景
Hermes Agent	持续成长的通用 Agent runtime	learning loop、persistent memory、auto-generated skills、多平台消息入口、cron、6 类 backend、开放 provider	跨会话自动化、多入口常驻 Agent、长期运行任务
Claude Code	面向研发流程的 agentic coding tool	代码库理解、文件编辑、命令执行、MCP、hooks、auto memory、agent teams、Terminal/IDE/Desktop/Web	工程研发、代码协作、PR/CI/CD 相关流程
Codex CLI	本地终端 coding agent	本地读改跑代码、MCP、subagents、sandbox、web search、cloud tasks	本地代码任务、终端开发工作流
Gemini CLI	terminal-first 开发代理	MCP、GEMINI.md、hierarchical memory、checkpoints、hooks、subagents、skills、IDE integration	大上下文代码理解、终端项目自动化
Goose	本机优先的开放通用 Agent	Desktop/CLI/API、15+ providers、70+ MCP extensions、skills、recipes、subagents	通用自动化、本地代理、开放生态接入

这个表更适合帮助读者看清产品边界，而不是制造“谁输谁赢”的情绪。因为这几款工具虽然都在 AI Agent 赛道里，但真正竞争的层面并不完全重合。

四、Hermes Agent 真正值得关注的三层能力

1. 学习闭环被做成了运行时的一部分

Hermes 最有辨识度的一点，是它官方把 learning loop 放在最核心的位置。这里要注意一个技术表达：它的“成长”主要来自技能生成、技能优化、记忆写入、跨会话检索和用户建模，而不是在运行时直接改写底层模型权重。也就是说，它更像是在 runtime 层面形成经验积累，而不是在 model training 层面直接“自动升级”。

2. 多平台入口不是补充功能，而是一等公民

Hermes 的 messaging gateway 不是可有可无的插件层。开发者文档里明确提到，gateway 本身承担长期运行、session routing、cron ticking 和多平台适配等职责。它想解决的问题，不只是“在本机终端里发命令”，而是“人可以从不同消息入口给 Agent 派活，Agent 在后台持续执行”。这和很多只围绕 terminal 或 IDE 展开的工具，设计思路明显不同。

3. 模型和执行环境都被做成了可替换层

Hermes 的 provider 页面明确支持云端 provider、自定义 endpoint，以及 Ollama、vLLM 等自托管路径；FAQ 还提到了 llama.cpp、SGLang 和任何 OpenAI-compatible server。另一边，执行环境也支持 local、Docker、SSH、Modal、Daytona、Singularity。对工程团队来说，这意味着模型来源、算力位置、执行环境、隔离方式都可以独立设计，而不是被某一种产品形态写死。