Hermes Agent 深度技术评测：性能与架构全解析

Hermes Agent，一个由Nous Research在2026年2月底开源发布的自主AI智能体，最近在圈子里热度挺高。它用MIT许可证，核心是用Python写成的。有趣的是，它诞生的初衷是为了解决一个被其创造者称为“AI失忆症”的麻烦——也就是大语言模型驱动的助手，每次对话结束就忘得一干二净。

那么，它到底靠什么来解决这个问题？核心创新在于一个叫作闭环学习回路的机制。简单说，就是智能体每次做完一项复杂任务后，会自己动手写一份可复用的“技能文档”，为之前的对话建立跨会话的索引，并且不断构建一个持续演进的用户心理模型。这个项目发布后仅四周，GitHub星标就破万了，到2026年3月下旬已经飙到17,400，成了Nous Research有史以来最受欢迎的开源项目。而且，它在五周内迭代了六个主要版本，从最初的概念验证，已经快变成一个具备多平台生产能力的智能体运行时了。

背景：Nous Research 与 Hermes 模型家族

开发团队

Nous Research这家实验室，主攻大语言模型的后训练和微调。他们的拳头产品就是Hermes模型系列——基于Meta的Llama架构进行深度微调，尤其擅长指令遵循、智能体函数调用和复杂推理。Hermes Agent运行时本身是个独立但又互补的项目：它可以在任何兼容OpenAI接口的端点上运行，而Hermes模型系列，恰恰就是为这种高级智能体任务量身打造的。

模型技术栈

先说说模型技术栈，这能帮我们更好地理解整套体系。

Hermes 3（2024年8月发布）是基于Llama 3.1的三个规模（8B、70B、405B）进行微调的。它用了大约3.9亿tokens的合成数据来训练，而不是人类反馈。训练分两步走：先做监督微调，然后做直接偏好优化。它通过Flash Attention 2实现了96%的样本打包效率，序列长度是8,192 tokens。模型采用了ChatML分隔符来兼容OpenAI API，并在特定数据集上训练以提升工具调用的可靠性。它的前代Hermes 2 Pro已经有90%的函数调用准确率，而Hermes 3把这个差距又拉大了一些。

Hermes 4（2025年8月发布）则带来了两个重大创新：

• 混合推理：模型可以在标准回复和显式的思维链之间自由切换，思维链长度能扩展到16,000 tokens。你可以选择快速模式或者深思模式，模型会根据选择自适应调整，不会对所有问题都搞长篇大论。
• DataForge：一个基于有向无环图的合成数据生成管线。这个管线里的每个节点都会进行结构到结构的转换，比如把维基百科文章变成问答对或者说唱歌曲。一个LLM评判器会对输出进行评估，不断迭代直到样本通过质量门槛。规模提升相当惊人：Hermes 3用了100万样本、12亿tokens；而Hermes 4用了大约500万样本、600亿tokens——样本量涨了5倍，token量直接翻了50倍。

Hermes 4的技术报告通过实证验证了混合推理的有效性：在AIME'24数学基准上，过度冗长推理减少了78.4%，而准确率只损失了4.7%。在MATH-500上，405B模型在混合模式下达到了96.3%的准确率，而标准模式是93.1%。

特别值得一提的是Hermes 4.3（36B）。它是在字节跳动的Seed 36B上微调的，而不是Llama。这打破了“所有Hermes模型都基于Llama”的假设，标志着Nous Research正朝着模型无关的后训练方法论迈进。

Atropos：强化学习训练框架

所有Hermes模型都是通过Atropos训练的，这是Nous Research开源的一个分布式强化学习框架。Atropos不是标准的RLHF——它是一个Rollout处理器，负责管理可能上千个分布式工作节点之间的异步协调，专门用来处理LLM输出生成时间不稳定这个难题。在Hermes 4的训练中，Atropos驱动了拒绝采样，通过大约1,000个任务特定的验证器，筛选出高质量的推理轨迹。有意思的是，同一个Atropos集成也出现在Agent运行时中，用于强化学习训练和轨迹捕获——这就构成了从Agent使用直接回流到模型训练的完整数据管道。

核心架构

ReAct 循环基础

Hermes Agent实现了经典的ReAct模式：观察（读取终端输出、文件内容、工具结果）→ 推理（对照目标分析当前状态）→ 行动（执行命令、调用工具）→ 循环。这个核心循环在代码里是作为AIAgent类实现的，负责处理Provider选择、提示词构建、工具执行、重试与回退、回调、上下文压缩以及持久化同步。不过，真正让它与众不同的，并不是这个循环本身有什么魔法，而是围绕它精心设计的五层记忆系统、技能架构和用户建模。

五层记忆系统

Hermes Agent维护了五个截然不同的持久化层，从临时性到永久性依次递进：

1. 短期推理内存：就是当前会话的标准Transformer上下文。重启后不留痕迹，跟所有传统聊天机器人依赖的基线状态一样——说穿了就是无状态的。
2. 持久化内存文件：`MEMORY.md`（大小限制约2,200个字符）和`USER.md`（大小限制约1,375个字符）是跨会话存活的扁平文件。当文件写满时，智能体会进行整合——合并或丢弃低价值的信息，而不是简单粗暴地把新信息丢掉。
3. 技能记忆 / 程序性记忆：放在`~/.hermes/skills/`目录下的`SKILL.md`文件里，专门捕获复杂任务的分步解决方案。这跟标准RAG那种零散检索不一样，Skills能保持对完整工作流的连贯程序性理解。当智能体完成下面这些任务时，它会自主创建技能：涉及5次以上工具调用的任务；从错误中恢复的任务；收到用户修正反馈的任务；或者发现了非平凡工作流的任务。
4. Honcho 辩证式用户建模：这是与Plastic Labs的Honcho用户建模库的集成。Honcho是异步运行的：在会话进行和消息记录的过程中，后台推理模型会推导出关于用户心理的结构化结论——比如偏好、沟通风格、领域专业知识、工作模式，而且完全不存储原始对话转录。核心洞察就一句话：存储结论，而非对话。比如存储“用户偏好TypeScript”，而不是“用户在消息#47里说他偏好TypeScript”。Honcho提供了5个工具：`honcho_profile`（读取/更新对等卡片）、`honcho_search`（语义搜索）、`honcho_context`（会话上下文）、`honcho_reasoning`（LLM合成推理）、`honcho_conclude`（创建/删除结论）。上下文检索延迟大约200毫秒。
5. FTS5 全文搜索：一个基于SQLite的可搜索数据库，涵盖了所有历史交互记录，还有LLM驱动的摘要能力。这让跨会话回忆（比如“我上周二做了什么？”）成为可能——提供了向量检索或扁平文件都搞不定的时间维度上下文。

Honcho 双端对等架构

Honcho把用户和AI智能体看成是具有持久状态的对等端点。有四个工具在运行时向Agent暴露这个能力：

用户和智能体的表征在会话启动时就注入系统提示词，让Hermes既清楚对话对象是谁，也明白自己知道什么。

闭环学习回路

闭环学习回路把所有记忆层串联成一个复合循环：

1. Agent完成任务 → 写入`SKILL.md`
2. 后续相似任务 → 向量存储检索技能 → Agent从经过验证的脚手架起步，而不是从零开始
3. Honcho观察用户 → 推导偏好事实 → 后续会话实现预个性化
4. FTS5索引所有交互 → 跨会话时间线召回可用
5. 周期性内部提示促使Agent在上下文占满前持久化高价值知识

实战数据（来自Nous Research黑客松）表明：技能辅助任务相比冷启动执行，Token消耗能降低30%到85%。有独立从业者报告说，在三份自主生成的技能文档辅助下，类似的研究任务完成速度加快了40%。

SOUL.md 人格栈

Hermes Agent通过三层人格系统，把“它了解你的内容”和“它如何与你对话”分离开了：

1. ~/.hermes/SOUL.md：全局人格文件，每次会话启动时逐字注入系统提示词。它控制所有交互中的沟通语调、直接程度和风格——如果某种行为应该在所有部署中保持一致，就该放在这里。
2. 人格覆盖：临时会话级模式切换，预设了“technical”、“creative”和“teacher”等模式。
3. AGENTS.md：按工作目录限定的项目级约定。

执行基础设施

六种终端后端。Hermes Agent通过`BaseEnvironment`接口把Agent运行时与执行环境分离，提供了六种实现：

配置只需要在`~/.hermes/config.yaml`里改一行——切换后端时Agent代码不需要任何改动。

多平台消息网关也很实用。单一网关进程同时路由所有已连接平台间的交互。截至v0.6.0，已经支持Telegram（含Webhook模式）、Discord、Slack（多工作区OAuth）、WhatsApp、Signal、IMAP/SMTP电子邮件、飞书/Lark和企业微信。语音备忘录转录和跨平台对话连续性都已经包含在内。这意味着，你可以从手机上的消息应用跟Agent聊天，同时它在远程云虚拟机上帮你干活。

模型Provider灵活性方面，Agent是Provider无关的——这是Nous Research的明确设计选择。支持的端点包括：Nous Portal（400+个模型）、OpenRouter（200+个模型）、任何OpenAI兼容API，以及通过Ollama、vLLM或llama.cpp进行的本地推理。截至2026年3月，Hugging Face已经被添加为一级推理Provider，提供了按用例组织的28个精选模型。v0.6.0版本还增加了有序回退Provider链：当主Provider返回错误或不可达时，Hermes会自动尝试配置的备用方案。

MCP 集成（双向）

Hermes Agent中的MCP集成是双向的：

• MCP Client模式：启动时连接任何已配置的MCP服务器（本地stdio或远程HTTP），自动发现工具，并将其注册为一级原生工具。自动重连采用指数退避（1s → 2s → 4s → 8s → 16s，最多5次尝试）。
• MCP Server模式（v0.6.0新增）：通过`hermes mcp serve`，把Hermes的对话和会话暴露给任何MCP兼容客户端——Claude Desktop、Cursor、VS Code。客户端可以通过标准协议浏览对话、读取消息、跨会话搜索以及管理附件。

agentskills.io 标准

标准定义

技能遵循agentskills.io开放标准：一个包含`SKILL.md`文件的目录，文件带有YAML前置元数据和Markdown指令。标准规定了最少的必填字段（`name`、`description`）和不受限制的Markdown正文（建议5,000 tokens以下）。可选的子目录（`scripts/`、`references/`、`assets/`）支持更复杂的程序性技能，包含辅助脚本和补充文件。技能实现了渐进式披露：元数据先加载到Agent的上下文索引里；完整内容等技能被激活时才按需加载。这样既保持了技能库的可发现性，又最小化了Token消耗。

跨框架可移植性

技能系统最厉害的地方，或许是它的可移植性。截至2026年3月，超过11款工具已经采用了这个标准：Claude Code、Cursor、GitHub Copilot、Gemini CLI、VS Code、Amp、Goose、Roo Code、Kiro、Codex和OpenCode。为Hermes Agent编写的技能可以直接用在Claude Code上。为Cursor编写的技能也可以直接用回Hermes Agent。这种跨框架兼容性在智能体生态里相当罕见——大多数技能/插件系统都是绑死在自家框架上的。

条件激活

技能还能根据当前会话中的工具可用性，通过前置元数据字段自动显示或隐藏自己：

• fallback_for_toolsets：当高级工具可用时技能隐藏，只在不可用时作为免费/本地替代方案显示。
• requires_toolsets：除非特定工具集存在，否则技能隐藏。

这实现了一种优雅降级——Agent会根据当前部署环境中可用的资源，呈现出不同的技能选项。

研究与训练基础设施

Hermes Agent不仅是一个终端用户工具，更是未来模型训练的数据生成引擎：

• 批量轨迹生成：运行并行工作节点并带有检查点，以规模化收集Agent交互数据。
• Atropos RL集成：用于训练Hermes模型的同一个Atropos框架已嵌入运行时。运行复杂循环和多步RPC任务的Agent，直接从实际使用中生成强化学习训练数据。
• YCBench环境：长时域Agent基准测试集成，用于系统性评估。
• ShareGPT导出：轨迹压缩并导出为ShareGPT格式，用于监督微调管线。

这形成了一个飞轮：Hermes Agent使用后生成训练数据 → Atropos处理 → 训练出更好的Hermes模型 → Hermes Agent变得更强大。

多智能体与子智能体架构

Hermes Agent把子智能体委派作为原生能力来支持。子智能体拥有自己独立的对话、终端和Python RPC脚本，支持零上下文成本的并行管线。自v0.5.0起，子智能体还有独立的迭代预算——它们不再消耗父智能体的预算，防止了复杂嵌套工作流中的过早终止。通过`execute_code`进行的程序化工具调用，会把多步管线折叠成单次推理调用：在后台运行RPC调用的子智能体直接执行代码，父智能体只需要评估最终输出，极大降低了LLM调用开销。

竞争格局

横向逐项对比

Hermes 的制胜之处

如果问Hermes Agent最打动人的点是什么，那一定是它的复合价值主张——运行时间越长，它对操作员和运行环境的了解就越深入。对于那种希望智能体在数月内积累上下文信息的单个高杠杆操作员（而不是由团队向多样化最终用户部署智能体的场景），Hermes的记忆架构在开源替代方案里确实没有能直接对标的对手。

有一个经常被引用的基准测试很有说服力：同一个底层模型（Opus 4.5），仅仅因为智能体脚手架不同，在SWE-bench上就产生了17道题的得分差距。这说明了一个关键问题：架构比模型选型更重要。这也印证了Hermes在记忆与技能系统上的投入是走对了方向，而不只是提供一个裸模型访问。

Hermes 的不足之处

• 多智能体编排：Hermes本质上是带有子智能体委派的单智能体框架。它缺乏CrewAI那种基于角色的团队结构，也没有LangGraph的状态机控制。对于需要高度定制化协调智能体团队的用例，Hermes可能不是最佳选择。
• 企业就绪度：截至2026年3月，还没有企业版、商业SLA、访问控制。而CrewAI有$1800万融资和企业合同；LangGraph有LangSmith可观测性和生产级检查点。
• 设置复杂度：需要Python运行时、独立的模型服务器、配置文件管理以及跨多个Provider的API Key管理。有些单二进制替代方案在这方面就省心得多。
• 文档缺口：社区反馈比较一致，文档相对于框架的复杂度和快速发布节奏来说，还是有些薄弱。

批判性分析：skeptics 的观点

当然，任何技术方案都不可能是全然的掌声。一份详细的技术审查提出了几个实质性的质疑：

• 技能作为结构化提示注入：有审查者认为，Hermes所宣传的“技能创建”，本质上就是对Markdown文件进行CRUD操作，然后在运行时注入上下文。这被描述为“带有CRUD层的结构化提示注入，而非原生能力”。不过，渐进式披露的设计倒被称赞为真正的优秀工程实践。问题可能出在营销框架上，被认为有些过度延伸。
• 记忆作为结构化笔记：带边界限制的`MEMORY.md`和`USER.md`文件，其实跟Claude Code、OpenCode以及大多数带配置文件的工具用的是同一个思路。实现本身工程做得很扎实（原子写入、文件锁、注入扫描、字符预算），但把“伴你成长”作为一个亮点来宣传，在批评者看来，这不过是对持久化结构化笔记的一种营销包装。
• Llama微调依赖：在该审查发布时，每一款Hermes模型都是Llama的微调版。跟Hermes 4交互的感觉，跟Llama 3.1 405B几乎没区别——因为它本质上就是，只不过做了针对性的指令调优。模型无关的Agent运行时虽然缓解了这个问题，但觉得Llama推理风格受限的开发者，会在任何Hermes模型里都体验到这一点。
• Honcho未经证实的宣称：Honcho的辩证式用户建模在架构上确实新颖，但至今没有发表的A/B测试或基准来对比启用和停用Honcho时Agent的任务表现。理论上的心智模型用户画像，在100次会话标记处能提升任务完成率的说法，仍然是个有待验证的实证问题。
• 无遗忘机制：Agent会无限累积记忆。没有衰减、剪枝或陈旧性检测。为旧工作流模式写的技能，以后跟新做法可能冲突；Honcho推导出的用户事实也可能过时。创造复合价值主张的记忆累积方式，同时也在制造复合一致性问题。

实用用例

根据实践者和社区文档的反馈，Hermes Agent在下面这些场景里回报最明显：

• 重复性开发工作流：比如每日GitHub Issue分类、自动摘要发布到Slack、每周Changelog生成。FTS5会话召回加上技能复用，意味着Agent会跨会话不断改进自己的分类逻辑。
• 持久化编码助手：跟那些关闭编辑器就丢了上下文的IDE嵌入式Copilot不同，Hermes作为后台进程持续运行，在整个开发生命周期中维护项目上下文。
• 研究与分析管线：带有并行工作节点的批量轨迹生成，让大规模研究任务可以在可控成本下进行，尤其是在空闲时几乎零成本的无服务器后端上。
• 自动化运维：Cron定时任务（备份、每周审计、报告生成）可以直接投递到任何已连接的消息平台。自然语言调度（比如“每周一上午9点，总结上周的提交”），配合投递到Telegram、Slack或电子邮件，非常方便。
• 模型训练数据生成：从事LLM开发的团队，可以以轨迹捕获模式运行Hermes，从真实运维任务中生成高质量训练数据，直接输入Atropos强化学习管线。

开放问题与未来轨迹

有几个未决问题，将决定Hermes Agent的长期发展走向：

• agentskills.io 能否成为通用标准？ 十一款工具采用同一技能格式，确实很厉害。但标准化这东西，在压力下往往会碎片化——当供应商需要标准不支持的特性（比如认证、版本管理、依赖管理）时。`SKILL.md`格式的有意极简主义让采用变得容易，但也让演进变得困难。
• 技能库能否在大规模下保持连贯？ 技能无限累积，旧的可能过时；冲突的技能（一个说“用yarn”，另一个基于用户偏好变更说“用pnpm”）会产生一致性问题。agentskills.io标准对技能生命周期管理或冲突解决，目前没有任何规定。
• Honcho用户建模能否在实际上改善结果？ 理论论证很令人信服，但实证证据还付之阙如。需要在有/无Honcho的情况下，在30/60/90天使用节点上，对任务完成率进行独立评估。这要么会验证该架构的价值，要么会揭示其为一个精心构建但仍需实证的用户面向叙事。
• DataForge的合成数据赌注：Hermes 4使用的训练tokens是Hermes 3的150倍，全部是合成生成的。LLM评判器提供了质量过滤，但合成数据可能放大种子数据中的偏差。600亿tokens的DataForge生成数据，是否比3.9亿tokens的精心策划数据能训练出真正更好的Agent，答案还没完全落地——Hermes 4的基准测试确实令人鼓舞，但底层模型也同时发生了变化，变量控制并不纯粹。
• 企业采用路径：Hermes Agent当前的架构是为单个高杠杆操作员优化的，而不是那种具备访问控制、审计追踪、合规要求以及团队级Agent管理的企业部署。Nous Research是会朝着这些能力方向去构建，还是把这个空间让给资金更充足的竞争对手？这决定了Hermes是保持为一个高级用户工具，还是最终成为一个企业级平台。

结论

总的来说，Hermes Agent可以说是2026年发布的开源Agent框架中，架构最具雄心者。它的闭环学习——五层记忆、自主技能创建、辩证式用户建模和FTS5会话搜索——代表了一个真正的架构押注：持久化、复合增长的上下文，将比无状态算力更具价值。快速的发布节奏（五周六个主要版本）和社区采纳（17,400 Stars），都验证了这一设计方向上确实有真实需求。

客观地评价，Hermes目前处于pre-1.0的高潜力架构论证阶段。“伴你成长”这个定位，部分已经实现了（技能确实能降低Token开销；会话搜索提供了真实的跨会话召回），但部分还属于愿景（Honcho的用户建模缺乏实证验证；技能累积还没有剪枝机制）。对于那些运行数月而不是数天的开发者和团队，复合优势在架构层面是真实存在的。但对于那些需要经过实战检验的可靠性、企业级访问控制或原生多智能体编排的组织，这个框架尚未就绪。不过，考虑到Nous Research在模型训练方面的专长，以及连接Agent使用与模型改进的Atropos飞轮，它的发展轨迹指向了一个不仅能跨会话、甚至能跨模型代际持续优化的系统。这一点，尤其值得持续关注。