关注 霍格沃兹测试学院公众号回复「资料」, 领取人工智能测试开发技术合集导读最近 Hermes Agent 被频繁提起不是因为它只是又多了一个 Agent CLI而是因为它试图把很多原本分散的能力放进同一套运行时里长期记忆、技能沉淀、子 Agent、定时任务、多平台消息入口、MCP、多种执行后端以及开放的模型接入方式。Hermes 官方对自己的定位很直接核心卖点不是“更会聊天”而是built-in learning loop、persistent memory、auto-generated skills这一整套持续运行能力。这也是 Hermes Agent 值得讨论的原因。 很多 AI Agent 仍然更像“在终端里工作的助手”而 Hermes 想做的是一个可以跨会话、跨平台、跨环境持续运行的 Agent 系统。这个差别才是它最近热度上来的关键。目录Hermes Agent 为什么突然被频繁讨论它和主流 AI Agent 的差别重点不在“谁功能更多”一张表看清 5 类主流 Agent 的产品重心Hermes 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 runtimelearning 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 CLIterminal-first 开发代理MCP、GEMINI.md、hierarchical memory、checkpoints、hooks、subagents、skills、IDE integration大上下文代码理解、终端项目自动化Goose本机优先的开放通用 AgentDesktop/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。对工程团队来说这意味着模型来源、算力位置、执行环境、隔离方式都可以独立设计而不是被某一种产品形态写死。五、哪些场景适合用 Hermes Agent如果你的目标只是“在本地仓库里快速改代码”那 Claude Code、Codex CLI、Gemini CLI 这种偏 coding workflow 的产品可能更直接。尤其是当你的核心诉求是 IDE 协同、diff 预览、代码审查、CI/CD 接入、终端执行链路这几类产品已经非常成熟。但如果你的目标变成下面这些Hermes 的优势就会更明显它需要跨会话持续工作。 它需要从不同入口接收任务。 它需要定时跑任务。 它需要把执行环境从本机切到容器、远程机或云端。 它需要把技能、记忆和自动化流程长期积累下来。还有一个实际落地时必须讲清楚的点Hermes 官方 Quickstart 对上下文窗口有要求建议至少 64KWindows 用户通常也会碰到 WSL 相关部署习惯。这说明它更适合愿意把 Agent 当成系统来搭的人而不是只想零配置打开就用的轻量用户。本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容侧重测试实践、工具应用与工程经验整理。