Hermes Agent：深度技术剖析报告

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

那么，它到底靠什么来解决这个问题？核心创新在于一个叫作

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

背景：Nous Research 与 Hermes 模型家族

开发团队

Nous Research这家实验室，主攻大语言模型的

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

模型技术栈

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

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

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

• 混合推理
  ：模型可以在标准回复和显式的思维链之间自由切换，思维链长度能扩展到16,000 tokens。你可以选择快速模式或者深思模式，模型会根据选择自适应调整，不会对所有问题都搞长篇大论。

• DataForge
  ：一个基于有向无环图的合成数据生成管线。这个管线里的每个节点都会进行结构到结构的转换，比如把维基百科文章变成问答对或者说唱歌曲。一个LLM评判器会对输出进行评估，不断迭代直到样本通过质量门槛。规模提升相当惊人：Hermes 3用了100万样本、12亿tokens；而Hermes 4用了大约

  500万样本、600亿tokens
  ——样本量涨了5倍，token量直接翻了50倍。

Hermes 4的技术报告通过实证验证了混合推理的有效性：在AIME'24数学基准上，过度冗长推理减少了

，而准确率只损失了。在MATH-500上，405B模型在混合模式下达到了的准确率，而标准模式是93.1%。

特别值得一提的是

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

Atropos：强化学习训练框架

所有Hermes模型都是通过

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

核心架构

ReAct 循环基础

Hermes Agent实现了经典的

模式：观察（读取终端输出、文件内容、工具结果）→ 推理（对照目标分析当前状态）→ 行动（执行命令、调用工具）→ 循环。这个核心循环在代码里是作为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暴露这个能力：

工具	功能
honcho_profile	快速对等卡片检索（无LLM调用），返回精选的关键事实
honcho_search	语义记忆搜索，返回按相关性排序的原始摘录
honcho_context	由Honcho的LLM驱动的辩证式问答，从历史中综合答案
honcho_conclude	当用户陈述偏好或更正时，将持久化事实写入Honcho

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

闭环学习回路

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

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

实战数据（来自Nous Research黑客松）表明：

。有独立从业者报告说，在三份自主生成的技能文档辅助下，类似的研究任务。

SOUL.md 人格栈

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

1. ~/.hermes/SOUL.md：全局人格文件，每次会话启动时逐字注入系统提示词。它控制所有交互中的沟通语调、直接程度和风格——如果某种行为应该在所有部署中保持一致，就该放在这里。

2. 人格覆盖
   ：临时会话级模式切换，预设了“technical”、“creative”和“teacher”等模式。

3. AGENTS.md
   ：按工作目录限定的项目级约定。

执行基础设施

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

后端	适用场景	特性
Local	开发、个人使用	直接系统执行，无隔离
Docker	生产环境、安全敏感	只读根文件系统、能力降级、PID限制、命名空间隔离
SSH	远程服务器	跨会话持久化环境
Daytona	云端开发	无服务器开发环境
Singularity	HPC、研究集群	面向计算密集型工作负载的容器编排
Modal	无服务器生产	空闲时休眠，按需唤醒，会话间近乎零成本

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

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

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

MCP 集成（双向）

Hermes Agent中的

集成是的：

• 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 标准

标准定义

技能遵循

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

跨框架可移植性

技能系统最厉害的地方，或许是它的

。截至2026年3月，已经采用了这个标准：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 Agent	Claude Code	CrewAI	LangGraph	AutoGen
架构	单一持久化智能体	IDE嵌入式CLI	多角色智能体	状态机图	对话式多智能体
记忆机制	5级持久化存储	基于会话	基础任务记忆	有限	有限
技能自我进化	自主创建+精炼	agentskills.io（手动）	无	无	无
GitHub星标数	~17,400	不适用（专有）	~47,600	极高	高
开发语言	Python	TypeScript	Python	Python	Python
本地推理支持	Ollama, vLLM, llama.cpp	不支持	不支持	不支持	不支持
消息平台集成	8（统一网关）	不适用	不支持	不支持	不支持
多智能体协作	子智能体委派	不支持	核心特性	核心特性	核心特性
开源协议	MIT	专有	MIT	MIT	MIT
资金背景	社区 / Nous Research	Anthropic	$1800万（Insight Partners, Andrew Ng）	LangChain Inc	Microsoft

Hermes 的制胜之处

如果问Hermes Agent最打动人的点是什么，那一定是它的

——运行时间越长，它对操作员和运行环境的了解就越深入。对于那种希望智能体在数月内积累上下文信息的（而不是由团队向多样化最终用户部署智能体的场景），Hermes的记忆架构在开源替代方案里。

有一个经常被引用的基准测试很有说服力：同一个底层模型（Opus 4.5），仅仅因为

不同，在SWE-bench上就产生了。这说明了一个关键问题：。这也印证了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目前处于

。“伴你成长”这个定位，（技能确实能降低Token开销；会话搜索提供了真实的跨会话召回），但（Honcho的用户建模缺乏实证验证；技能累积还没有剪枝机制）。对于那些运行数月而不是数天的开发者和团队，复合优势在架构层面是真实存在的。但对于那些需要经过实战检验的可靠性、企业级访问控制或原生多智能体编排的组织，这个框架。不过，考虑到Nous Research在模型训练方面的专长，以及连接Agent使用与模型改进的Atropos飞轮，它的发展轨迹指向了。这一点，尤其值得持续关注。