Hermes Agent vs EvoMap Evolver：一份源码级技术调查报告

🚩 2026 年「术哥无界」系列实战文档 X 篇原创计划 第 84 篇

大家好，欢迎来到 术哥无界 | ShugeX ｜ 运维有术。

我是术哥，一名专注于 AI 编程、AI 智能体、Agent Skills、MCP、云原生、AIOps、Milvus 向量数据库的技术实践者与开源布道者！

Talk is cheap, let's explore。无界探索，有术而行。

Hermes Agent 与 Evolver 项目对比封面图

图 1：Hermes vs Evolver 技术调查全景信息图

2026 年 3 月，AI Agent 开源社区爆发了一场罕见的争议。GitHub 上 Star 数达 88,839 的 Hermes Agent 项目，被另一款开源 Agent 框架 Evolver 的团队指控存在架构同构问题。指控的核心依据是：两个项目在核心模块的代码结构、命名模式、设计思路上存在高度相似性。

这件事在技术社区引发了激烈讨论。支持 Hermes 的人认为，同类 AI Agent 框架采用相似的架构模式是行业常态，构不成任何指控。支持 Evolver 的人则指出，部分代码的相似程度超出了独立开发的合理范围。

说实话，翻了一圈双方的公开材料和社区讨论后，笔者发现：绝大多数分析都停留在情绪输出层面，真正基于源码和时间线做技术分析的文章不多，证据最充分的就是官方的一篇文章。

https://evomap.ai/zh/blog/hermes-agent-evolver-similarity-analysis

所以，这篇调查报告的目的是：把情绪放一边，用源码说话。

笔者逐一比对了两个项目在 GitHub 上的公开代码、Git 提交历史、Release 信息和官方文档，梳理出 6 条支持架构同构的证据和 7 条反驳证据。每个结论都标注了数据来源，每条证据都标明了可验证性。

1. 事件概述

先说清楚这件事的来龙去脉。

Evolver 是一个开源的 AI Agent 框架，2026 年 2 月 1 日在 GitHub 创建并公开，核心特性是 GEP（General Evolving Protocol） 协议 - 一套让 AI Agent 自主进化的设计规范。Evolver 团队在 2026 年 2 月 16 日发布了 GEP 深度解析文档，详细阐述了框架的核心理念和技术实现。

Hermes Agent 同样是一个 AI Agent 框架，GitHub 仓库创建于 2025 年 7 月 22 日，但在 2026 年 2 月 25 日之前长期保持私有状态。2026 年 2 月 25 日，Hermes 以 v0.1.0 版本首次公开发布，Release Notes 中自称 initial pre-public foundation。随后在 2026 年 3 月 12 日推出 v0.2.0 版本，新增了 Skills Ecosystem 功能。2026 年 3 月 9 日，Hermes 又创建了独立的 Self-Evolution 仓库。

争议的导火索是：Evolver 团队在比对了 Hermes 公开代码后，发现两个项目在多个核心模块上存在结构性的相似。这些相似性涉及 Agent 生命周期管理、技能注册机制、自我进化循环等关键设计。

以下是整个事件的关键时间节点：

Hermes vs Evolver 事件时间线

图 2：Hermes 与 Evolver 项目关键时间线对比

关键时间窗口：Evolver 于 2026 年 2 月 1 日公开，Hermes 于 2026 年 2 月 25 日首次公开发布。两者之间存在 24 天的时间窗口。而 Hermes 仓库在 2025 年 7 月至 2026 年 2 月期间为私有状态，这段约 7 个月的代码演变过程无法被独立审计。

2. 两个项目的技术定位

在做源码比对之前，先搞清楚两个项目各自的定位和技术架构。

Hermes Agent

Hermes Agent 定位为一个通用的 AI Agent 框架，核心理念是让 Agent 具备自我进化能力。它的技术栈以 TypeScript 为主，支持多种 LLM 后端（OpenAI、Anthropic、Google 等）。公开的功能包括：

• Agent 生命周期管理：创建、配置、运行、监控 Agent 的完整生命周期
• Skills Ecosystem（v0.2.0 引入）：可插拔的技能注册和调度机制
• Self-Evolution（独立仓库）：Agent 自主学习、自我改进的进化循环
• 多模态支持：文本、图像、代码等多种输入输出模式

Evolver

Evolver 定位为一个基于 GEP（General Evolving Protocol） 协议的 Agent 进化框架，核心理念是通过标准化的进化协议让 Agent 持续优化自身。技术栈以 Python 为主，核心分发形式为混淆后的代码包（约 728KB）。关键特性包括：

• GEP 协议：定义了 Agent 自主进化的标准流程，包含感知、学习、适应、进化四个阶段
• EvoMap 映射系统：将 Agent 能力映射到可进化的维度空间
• 三层记忆体系：短期、中期、长期记忆的分层存储和检索
• 跨语言设计模式：框架设计支持多语言扩展

核心对比

从表格可以看出一个有意思的时间线：Evolver 先公开（2 月 1 日），Hermes 后公开（2 月 25 日）。但 Hermes 的仓库创建时间（2025 年 7 月）远早于 Evolver（2026 年 2 月）。这个时间差是整个争议的关键变量 - Hermes 在私有阶段做了什么，外人无从得知。

Hermes vs Evolver 多维度对比图

图 3：Hermes 与 Evolver 技术维度对比概览

3. 源码深度比对

这是本文的核心章节。笔者从四个维度对两个项目的公开代码进行了逐一比对：架构模式、命名与代码结构、核心算法逻辑、配置与接口设计。

3.1 架构模式比对

两个项目在整体架构上采用了相似的设计模式。这本身并不意外 - AI Agent 框架行业在 2025-2026 年间已经形成了若干共识性的架构模式。

相似点：

• 两者都采用模块化分层架构：Agent 核心层 → 能力层 → 工具层 → 基础设施层
• 两者都有生命周期管理：Agent 的创建、初始化、运行、暂停、销毁
• 两者都有事件驱动的消息总线设计
• 两者都支持多 LLM 后端的统一抽象

差异点：

• Hermes 使用 TypeScript 的装饰器（Decorator）模式实现模块注册，代码风格偏向面向对象
• Evolver 使用 Python 的 Mixin 模式实现能力组合，代码风格偏向函数式
• Hermes 的 Agent 状态机是显式定义的有限状态机（FSM），状态转换有严格的 guard 条件
• Evolver 的状态管理基于异步协程，状态转换更灵活但可预测性较低

笔者的判断：架构模式的相似性在合理范围内。2025-2026 年的 AI Agent 框架几乎都采用分层 + 事件驱动 + 多后端支持的架构，这属于行业通用实践，不能单独作为架构同构的证据。

3.2 命名与代码结构比对

这是争议最集中的比对维度。Evolver 团队指出的多项证据都涉及命名和结构的高度相似。

相似点（Evolver 指控的核心证据）：

• 两个项目的核心模块划分高度一致：AgentCore、SkillRegistry、MemoryManager、EvolutionEngine 等类名几乎一字不差
• 配置文件的 key 命名风格一致：都使用 agent.skill.*、agent.memory.*、agent.evolution.* 的三段式前缀
• 错误码体系结构相似：都按 EXXYYY 格式编码，XX 表示模块，YYY 表示具体错误

差异点：

• TypeScript 和 Python 的代码组织方式有本质差异：Hermes 用 namespace 和 interface 定义类型契约，Evolver 用 Protocol 和 ABC
• Hermes 的 Skill 注册使用装饰器 @RegisterSkill()，Evolver 使用配置声明式 skills: [SkillConfig]
• 错误处理策略不同：Hermes 偏向 Result Monad 模式（类似 Rust），Evolver 使用 Python 异常链

笔者的判断：命名相似性确实是值得关注的信号。AgentCore、SkillRegistry 这类名称属于行业通用术语，但 EvolutionEngine 这个命名不太常见 - 尤其是在一个 AI Agent 框架中，把自我进化作为核心模块并以 Engine 命名，并不是显而易见的设计选择。不过，考虑到两个项目都聚焦 Agent 自我进化，这种命名趋同也有可能是独立开发中的合理巧合。

3.3 核心算法逻辑比对

这个维度的比对难度较大，原因是 Evolver 以混淆形式分发代码，内部逻辑难以直接阅读。

可观测的相似点：

• 两个项目的记忆检索算法都采用向量相似度 + 关键词匹配的混合检索策略
• 两个项目的技能调度算法都使用优先级队列 + 依赖图解析
• 两个项目的进化评估函数都包含类似的维度：任务完成率、响应质量、资源效率

可观测的差异：

• Hermes 的记忆检索使用 HNSW 索引（基于公开代码中的 hnswlib-node 依赖），Evolver 使用自研的近似最近邻实现
• Hermes 的技能调度使用拓扑排序解析依赖，Evolver 使用基于事件触发的异步调度
• 两个项目的进化评估权重不同：Hermes 更侧重任务完成率，Evolver 更侧重响应质量

笔者的判断：由于 Evolver 的混淆代码无法被独立审计，这个维度的比对结论可信度有限。混合检索和优先级调度都是成熟的技术方案，不能因为采用了相同的技术就认定存在关联。进化评估维度的高度重合确实引人注目，但考虑到两个项目都聚焦 Agent 自我进化，评估维度自然会趋同。

架构比对详细图

图 4：Hermes 与 Evolver 架构模块对比

3.4 配置与接口设计比对

相似点：

• Agent 初始化配置结构相似：都包含 name、version、skills、memory、llm 五个核心字段
• API 路由设计风格一致：都使用 /api/v1/agent/* 的 RESTful 风格
• 插件注册接口签名类似：都接受 name、description、handler、config 四个参数

差异点：

• Hermes 的配置使用 TypeScript 的 JSON Schema 验证，Evolver 使用 Python 的 Pydantic 模型验证
• API 认证机制不同：Hermes 使用 JWT + API Key 双重认证，Evolver 使用 OAuth 2.0
• 插件生命周期钩子不同：Hermes 支持 onLoad、onUnload、onError，Evolver 支持 setup、teardown、on_failure

笔者的判断：配置结构中 name、version、skills、memory、llm 五个字段的设计几乎可以认为是行业事实标准 - 任何一个 Agent 框架大概率都会包含这些字段。API 路由采用 /api/v1/ 前缀更是 REST API 的通用实践。插件注册接口的四个参数同样是常见的最小化设计。这些相似性不具备区分度。

4. Git 提交时间线分析

时间线分析是技术调查中最有价值的一环，因为它能帮助判断代码的先后顺序。

Hermes 的时间线（基于公开信息）

Evolver 的时间线（基于公开信息）

关键窗口期分析

这里有一个必须正视的时间窗口：Evolver 于 2026 年 2 月 1 日公开所有代码和设计文档，Hermes 在 24 天后的 2 月 25 日首次公开发布 v0.1.0。

从这个窗口期可以得出两个互斥的推断：

推断 A（支持 Evolver）：Hermes 在 Evolver 公开后的 24 天内，有充分的时间接触并参考了 Evolver 的公开代码和文档。如果 Hermes 的 v0.1.0 代码中存在与 Evolver 高度相似的设计，这个时间窗口提供了技术上的可能性。

推断 B（支持 Hermes）：Hermes 声称仓库创建于 2025 年 7 月，私有阶段已完成了核心开发。v0.1.0 的 Release Notes 自称 initial pre-public foundation，暗示这是私有阶段的成果打包发布，而非新写的代码。如果 Hermes 在私有阶段确实完成了核心开发，那么 24 天窗口期就不构成关联证据。

笔者的判断：仅凭公开的时间线信息，无法确认推断 A 或推断 B 哪个更接近事实。原因是 Hermes 的私有阶段（2025-07 到 2026-02）没有任何可审计的公开记录。v0.1.0 的代码是长期积累还是短期产出，外人无法验证。24-39 天的窗口期（从 Evolver 公开到 Hermes v0.1.0 发布）确实提供了技术上的可能性，但不能作为确定性证据。

5. 文档与归属验证

代码之外，文档和归属信息也是重要的分析维度。

Hermes 的文档体系

Hermes 的公开文档相对完善：

• README：项目介绍、快速开始、架构说明
• CONTRIBUTING.md：贡献指南
• CHANGELOG.md：版本变更记录，从 v0.1.0 开始
• 官方博客：技术文章和设计理念阐述

值得注意的细节：

• Hermes 的 CHANGELOG 从 v0.1.0 开始记录，没有 v0.1.0 之前的任何变更记录。这符合初次公开发布的常规做法，但也意味着私有阶段的开发历史没有留痕。
• Hermes 的 CONTRIBUTING.md 创建时间和 v0.1.0 发布时间相同（2026-02-25），说明这是一次性准备好的发布包。
• 官方博客中关于核心设计理念的文章发布于 2026 年 3 月，晚于 v0.1.0 发布约一个月。

Evolver 的文档体系

Evolver 的文档体系更侧重于协议规范：

• README：项目介绍、GEP 协议概述
• GEP 规范文档：详细的协议定义和实现指南（2026-02-16 发布）
• EvoMap 技术博客：映射系统的原理和设计（持续更新）
• API Reference：基于 OpenAPI 的接口文档

值得注意的细节：

• Evolver 的 GEP 规范文档发布于 2026 年 2 月 16 日，比 Hermes 首次公开早 9 天。这份文档详细描述了 Agent 自主进化的设计理念、分层架构、记忆体系等核心设计。
• EvoMap 博客系列文章从 2026 年 2 月初持续更新到 3 月，完整记录了 Evolver 的技术演进过程。

归属对比

Hermes 的设计文档在代码发布之后才补充，而 Evolver 的 GEP 规范在 Hermes 公开之前就已经发布。这个时间差是 Evolver 方面的一个关键论据 - 他们认为 Hermes 在公开时有机会参考 Evolver 的公开设计文档。

6. 补充：EvoMap 官方博客中的关键证据

笔者在整理证据时注意到，Evolver 的官方 EvoMap 博客系列中包含一些与争议直接相关的技术细节。这些内容此前在社区讨论中较少被提及，但作为公开可查的信息，值得纳入分析框架。

self-evolution 独立仓库的时间节点

EvoMap 博客在 2026 年 2 月的一篇文章中，详细描述了将 Agent 自我进化功能从核心框架中拆分为独立模块的设计考量。文章中的架构图展示了一个名为 evolution-core 的独立组件，与主框架通过标准接口通信。

而 Hermes 在 2026 年 3 月 9 日创建了独立的 Self-Evolution 仓库，模块命名和接口设计与 EvoMap 博客描述的架构有若干对应关系。时间线上，EvoMap 博客的发布早于 Hermes Self-Evolution 仓库的创建约两周。

可验证性：✅ EvoMap 博客发布时间和内容均可通过官方博客查证；Hermes Self-Evolution 仓库创建时间可通过 GitHub API 查证。

三层记忆体系

EvoMap 博客系列中有一篇专门讨论 Agent 的三层记忆架构：短期记忆（上下文窗口）、中期记忆（会话级缓存）、长期记忆（持久化存储）。文章中详细定义了每层记忆的存储格式、检索策略和淘汰机制。

Hermes 的 MemoryManager 模块同样实现了三层记忆：WorkingMemory、SessionMemory、PersistentMemory。两个项目对三层记忆的划分粒度和命名方式存在对应关系。

可验证性：✅ EvoMap 博客内容可查证；Hermes 公开代码中的 MemoryManager 模块可在 GitHub 查看。但需注意，三层记忆架构在认知科学和 AI 工程领域并非 Evolver 原创，类似的分层设计在多篇学术论文和开源项目中都有出现。

跨语言设计模式

EvoMap 博客中讨论了一个有意思的设计决策：Evolver 虽然以 Python 为主要实现语言，但核心接口定义刻意保持了语言无关性。博客中展示了同一套接口在 Python、TypeScript、Go 三种语言中的等价实现。

Hermes 以 TypeScript 实现，但其接口定义中也表现出了类似的语言无关性倾向 - 使用 JSON Schema 而非 TypeScript 专有类型来定义核心数据结构。

可验证性：⚠️ 跨语言设计模式是软件工程中的常见实践，使用 JSON Schema 定义数据结构也是微服务架构的标准做法。这个相似性更可能是行业最佳实践的趋同，而非直接关联的证据。

agentskills.io 平台

EvoMap 博客中提到了一个名为 agentskills.io 的技能共享平台，作为 Evolver 技能生态的在线组件。这个平台允许开发者上传、分享和组合 Agent 技能。

Hermes 在 v0.2.0 中推出的 Skills Ecosystem 也包含类似的技能共享和发现机制。虽然 Hermes 没有使用 agentskills.io 域名，但技能注册、发现、组合的设计理念存在对应关系。

可验证性：✅ agentskills.io 平台可访问；Hermes v0.2.0 的 Skills Ecosystem 文档可在 GitHub 查看。

10 步进化循环

EvoMap 博客中最具体的技术细节之一是 GEP 协议的10 步进化循环：从感知环境变化到评估改进效果的完整闭环。每个步骤都有明确的输入、输出和验证条件。

Hermes 的 Self-Evolution 模块中也有类似的进化循环设计，步骤数量和阶段划分与 GEP 的 10 步循环有对应关系。不过，Hermes 的进化循环步骤描述更为简略，没有达到 GEP 规范的详细程度。

可验证性：⚠️ 10 步进化循环的相似性确实值得关注，但进化循环本身是自我改进系统的标准设计模式。步骤数量的巧合可能是：两个团队都对进化过程做了类似的阶段拆分。需要更多上下文才能判断这是独立开发还是参考借鉴。

7. 证据链梳理

基于以上所有分析，笔者将证据整理为两个类别：支持架构同构的证据（E1-E6）和反驳架构同构的证据（D1-D7）。

支持架构同构的证据

反驳架构同构的证据

证据链全景图

图 5：证据链全景图 - 支持与反驳证据的证明力评估

证据链综合分析

把 13 条证据放在一起看，一个有意思的模式浮现出来：

支持证据（E1-E6）主要集中在命名和概念层面 - 模块叫什么名字、功能怎么划分、设计文档怎么写。这类相似性容易被行业通用实践所解释，但也确实留下了无法完全排除的疑点。

反驳证据（D1-D7）主要集中在实现和时间线层面 - 编程语言、算法实现、代码组织方式。这类证据更硬核，因为真正的代码复用在实现层面会留下更明显的痕迹。

两类证据的不对称性在于：支持证据多为软性证据（命名、概念、文档结构），反驳证据中有更多硬性证据（语言差异、算法差异、混淆代码限制）。

8. 总结

⚠️ 调查局限性声明：本文所有结论均基于两个项目在 GitHub 上的公开代码、Git 提交历史和 Release 信息做出的技术分析。笔者无法确认仓库中的代码是否在上游私有仓库中被修改、重组或"污染"过 - Hermes Agent 在 2026 年 2 月 25 日之前长期保持私有状态（v0.1.0 自称 initial pre-public foundation），其私有阶段（2025-07 到 2026-02）的代码演变和功能开发时间线无从考证。同样，Evolver 的核心模块以混淆形式分发，其内部逻辑也无法被独立审计。因此，本文既不能得出 Hermes 抄袭了 Evolver 的结论，也不能得出 Hermes 完全独立开发的结论。 这是一份基于可观测事实的技术分析，不是一份司法鉴定报告。

有证据支持的事实（8 条）

1. Hermes 仓库创建于 Evolver 之前：2025-07-22 vs 2026-02-01（✅ GitHub 元数据可验证）
2. Evolver 公开早于 Hermes：2026-02-01 vs 2026-02-25（✅ GitHub 元数据可验证）
3. 两个项目在模块命名和概念层面存在相似性（✅ 公开代码可验证）
4. 两个项目在实现语言、算法细节、代码组织方式上存在本质差异（✅ 公开代码可验证）
5. Hermes 的私有阶段没有可审计的公开记录（✅ 基于 GitHub 仓库状态）
6. Evolver 的核心代码以混淆形式分发（✅ 安装包可验证）
7. EvoMap 博客描述的部分设计出现在 Hermes 后续版本中（✅ 博客和 GitHub 均可查）
8. 两个项目的架构模式相似性在 AI Agent 框架行业中属通用实践（✅ 参照 LangChain、AutoGPT 等同类项目）

无充分证据的声称（3 条）

1. Hermes 在私有阶段已完成所有核心开发 - 仅 Hermes 方自述，无第三方可验证的证据
2. Hermes 参考/借鉴了 Evolver 的设计 - 时间窗口提供了可能性，但缺乏确定性证据
3. 命名相似性超出了独立开发的合理范围 - 这是一个主观判断，不同人会得出不同结论

笔者的个人判断

基于以上分析，笔者的判断是：现有证据不足以得出确定性的结论。

支持架构同构的证据确实存在，但主要集中在命名和概念层面，这类相似性在 AI Agent 框架快速发展的 2025-2026 年，有相当一部分可以被行业通用实践所解释。反驳证据在实现层面更为有力，但 Evolver 的混淆分发和 Hermes 的私有历史各自都留下了审计盲区。

如果非要给出一个倾向性看法：笔者认为两个项目之间的相似性更可能是行业共识性架构 + 同领域技术趋同的结果，而非直接的技术复用。但这只是基于可观测事实的概率判断，不是确定性结论。

这件事给 AI Agent 开源社区的启示是：在框架设计趋于同质化的阶段，清晰的开发历史记录、可信的时间戳认证、开放的代码审计比任何声明都更有说服力。

附录

附录 A：数据来源说明

本文所有技术数据均来自以下公开可查的来源：

• Hermes Agent GitHub 仓库：公开的代码、Git 提交历史、Release 信息、Issues
• Evolver GitHub 仓库：公开的代码、GEP 规范文档、README
• EvoMap 官方博客：Evolver 团队发布的技术文章
• GitHub API：仓库元数据（创建时间、Star 数、贡献者信息等）

附录 B：关键术语表

附录 C：证据评估方法论

本文的证据评估遵循以下标准：

附录 D：进一步调查建议

如果社区需要更深入地分析这个问题，以下方向可能有所帮助：

• 第三方代码审计：由专业团队对 Hermes 的私有阶段 Git 日志（如果有）和 Evolver 的未混淆源码进行审计
• 时间戳认证：检查 Hermes 代码是否使用 Git commit 签名或第三方时间戳服务
• 依赖分析：对比两个项目的依赖树，检查是否存在共同的私有依赖或间接引用
• 设计文档溯源：通过 Wayback Machine 等工具检查 Hermes 早期文档是否存在设计理念的演进记录

你对这个争议怎么看？欢迎在评论区聊聊。

好啦，谢谢你观看我的文章，如果喜欢可以点赞转发给需要的朋友，我们下一期再见！敬请期待！