你好，我是 Lena。有件事我一直注意到，却一度不知道该怎么称呼。
我会看一个 agent 啃一个问题——真的来回好几轮，走错过几次，最后修到能跑。然后 session 结束。第二天，同一个 agent，同一类问题。又从开头来。同样的弯路。同样的时间。同样的修复，从头再发现一遍。
我问自己，是不是……本来就该这样。是不是预期如此。
我当时大概真是这么以为的。
问题是，我之前见过的大多数工具也没说不是。Memory 往往等于「我们保存你的聊天记录」。这并非毫无价值，但不等于 agent 学到 了什么。学习意味着下一次跟上次不一样。意味着周二晚上 11 点找到的修复，周三还能用。意味着模式被留下，而不只是被记进 log。
于是我开始盯两个似乎从不同方向、不同层上啃这个问题的项目：一个是 Hermes Agent，Nous Research 的开源 agent，在单个 agent 的生命周期里搭 learning loop。另一个是 EvoMap，基础设施层，问的是更大的问题：如果一个 agent 找到的修复，能被网络上其它每个 agent 继承呢？
我还不敢说完全吃透了它们各自在做什么。但两边都看了足够久，有些东西开始对焦。
这是我此刻的理解。
两者都想解决什么
看 agent 干活时，我反复撞上同一件事。
session 结束。下一个开始。agent 重新解释它明明已经有的上下文。它踩上上周踩过的同一个错。第一次花了四十五分钟才修好的东西——还要再来一遍，从零。几乎看不到它曾经发生过。
Hermes Agent 和 EvoMap 似乎都在回应这个。谁都不把它当成注定如此。但回应的层非常不同——我也是在两边都多待了一会儿之后，才慢慢分清哪一层是哪一层。
共同的起点：agent 的经验不该在 session 结束时蒸发。 这是它们都承认的前提。从这里往哪走，才好玩。
Hermes Agent 实际在做什么
持久 memory 与 learning loop
完成复杂任务后——通常是五次或更多次 tool call——Hermes 可以把那段经验合成一份永久、可复用的 skill 文档。这些 skills 存成结构化 Markdown，遵循开放的 agentskills.io 标准，包含流程、坑点和验证步骤。
我停了一下。这不只是存 log。是 agent 在判断：这值得留下。 下次遇到相近任务，它加载 skill，而不是从零开始。
它的 memory system 用 FTS5 对 SQLite 里所有历史 session 做全文检索，再配合 LLM 驱动的摘要。agent 能搜几周前的对话，抽出具体细节，套到当前工作上。
还有一层用户建模——Honcho——会逐渐加深对你工作方式、偏好和沟通习惯的理解。文档里有一点不显眼：Honcho 默认关闭。别在没开它之前就默认它一直在跑。
agentskills.io 标准
Hermes 生成的 skills 遵循 agentskills.io 开放规范。Agent Skills 是一种简单、开放的格式，用来给 agent 新能力——指令、脚本、资源的文件夹，agent 可以发现并在特定任务上用得更好。格式由 Anthropic 维护，Apache 2.0，欢迎社区贡献。
十多家工具已采纳 agentskills.io——包括 Claude Code、Cursor、GitHub Copilot、Gemini CLI、VS Code、Amp、Goose、Roo Code、Kiro、Codex、OpenCode。写给 Hermes Agent 的 skill，在 Claude Code 里也能用。
这块确实让我抬头看了一眼。skill 格式没有锁死在 Hermes。它是为了可迁移。实际有没有人用，取决于搭工作流的人——但选项在那儿。
Hermes 止步的地方
这块我还不确定自己是否读对了。
learning loop 封闭在单个 agent 的生命周期里。 skills 在本地累积。第二个 agent 实例从零开始。没有一个机制让一个 agent 发现的修复自动传播给另一个。agentskills.io 规范 本身也不谈 skill 生命周期管理——没有验证状态、没有 fitness 信号、没有跨 agent 继承。skills 可以手动分享。它们不会自己上路。
这不完全是缺陷。更像设计选择。Hermes 优化的是单个 agent 的 session 深度。我只想把「跟你一起成长」在实践里意味着什么说清楚：是 这个 agent，带着 你的 历史。不是整个网络。
EvoMap / GEP 实际在做什么
Gene 与 Capsule 作为网络级资产
EvoMap 的起点不一样。问题不是「这个 agent 怎么记住？」而是「一个 agent 学到的，怎么让别的继承？」
基因（Gene）是原子能力单元——可复用、已验证的代码或 prompt 片段。基因胶囊（Capsule）是成功的任务执行路径：agent 解决复杂问题时，过程被封装成一个 Capsule。
让我又翻回去看了一遍的是：每个 GEP 资产都有 SHA-256 内容寻址 ID。同一套解法，不论谁发布，ID 都一样，便于去重、防篡改和全局引用。
那不是知识库。那是经证明的解法组成的内容寻址网络。同一修复，在不同环境由不同 agent 发布，会解析到同一个标识符。
GEP 生命周期状态机
这是 Hermes 里没有对应物的一块——也是技术上最关键的分水岭。
GEP 协议里的资产经历四种状态：candidate（刚发布，待审）→ promoted（已验证，可分发）→ rejected（验证或策略检查未过）→ revoked（发布方撤回）。
资产必须达到最低 GDI 分数才能 promoted。低分会被 reject 或隔离改进——没有人工 override，没有橡皮图章。promoted 也不是永久：质量下滑、使用模式提示问题，或社区报告，资产可以被 revoke。
据 GEP 协议文档，GDI 打分权重大致是：内在质量 35%，使用指标 30%，社交信号 20%，新鲜度 15%。
我还在琢磨「带 fitness 分数、还会随时间衰减」的 skill 到底意味着什么。可能比我当下理解的更深。但它确实意味着，和静态 skill 文件不同，Capsule 有活着的状态——可以被 promoted、降级，若无人使用最终也可归档。
「一个 agent 学会，百万个继承」具体指什么
具体场景：一个 agent 花四十分钟 debug 某种 API timeout 模式。修复被封装成 Gene + Capsule bundle，发布到 EvoMap 网络。验证通过后，另一个团队、另一个 model 上的不同 agent 发 POST /a2a/fetch，收到那个 Capsule，继承修复，不必重走发现之路。
GEP 设计上 model-agnostic。GPT-4 agent 发布的方案可以被 Claude agent 继承使用，因为 GEP 资产是行为描述，不是某个 model 的权重。
这条路不在 Hermes 架构里。我想把话说精确——不是 Hermes 更差，是它根本不朝这个方向做。范围完全不同。
核心架构差异
这是我读两边时一直想要的一张表：
```markdown id="n8r4vk"
| Dimension | Hermes Agent | EvoMap / GEP |
|----------------|----------------------------------|--------------------------------------------------|
| Memory scope | Local, single agent | Network-level, cross-agent |
| Skill sharing | Manual, via agentskills.io format | Automatic, via A2A protocol |
| Validation | None built in | candidate → promoted → rejected → revoked |
| Governance | None | GDI scoring + community reports + auto-revoke |
| Network effect | None (closed loop) | Reuse records influence GDI ranking |
| Open standard | agentskills.io (broad adoption) | GEP protocol (open spec, EvoMap reference impl.) |
Hermes 优化单个 agent 生命周期里的深度。EvoMap 优化跨 agent、跨团队的传播。 谈不上谁绝对更好——是不同架构层上的不同问题。
哪种更贴你的情况
适合用 Hermes 的时候
你在用单个 agent，自托管，个人工作流，不需要修复自动跑到别的 agent 上。Hermes MIT 开源，一条命令装好，除了你选的 model backend，不需要额外 API key。
对独立开发者说句实话：Hermes 多半更省事。上手摩擦更低，价值来得快，也不必先搞懂 GEP 协议才能有持久 memory。如果一个人、一个 agent，EvoMap 的网络效应还没转起来——要等其它节点贡献才会转。
适合用 EvoMap 的时候
你在跑多个 agent 或团队级工作流，希望一个 agent 发现的修复不必被另一个重新发现。或者你需要可审计的能力生命周期。或者你想为贡献到网络的解法赚 Credit。
EvoMap A2A 文档 展示了通过 POST /a2a/hello 的连接流程——注册节点不需要 API key。我自己还没跑通完整集成，「这很顺手」的判断留给真做过的人。
能共存吗？
大概可以。它们在不同层。Hermes 兼容 agentskills.io 开放标准，原则上 Hermes agent 也可以接 EvoMap 当网络节点——本地累积 skills，同时发布经验证的 Capsules 供跨 agent 继承。我没测过这种组合。架构上看不出硬冲突。
FAQ
Q：Hermes Agent 这个项目有多成熟？
大约 24.2k GitHub stars，最近刚发 v0.7.0，Hermes 大概是当下开源 agent 圈里技术上最有趣的项目。社区活跃，有第三方 skill 生态，也有 demo 之外的真实生产用法。
Q：agentskills.io 到底是开放标准，还是 Anthropic 自家格式？
Agent Skills 是 Anthropic 维护的开放格式，代码 Apache 2.0，文档 CC-BY-4.0，欢迎社区贡献。微软在 VS Code 和 GitHub 里采纳了；Cursor、Goose、Amp、OpenCode 等常见 coding agent 也跟了。不是围墙花园。
Q：从外部拉来的 EvoMap Capsule，执行安全吗？
通过 A2A 协议 ingest 的外部 Gene/Capsule 会先放在隔离的 candidate 区。要进本地 store，需要显式 --validated——操作者得先验证资产。所有验证命令在 promotion 前都会过安全检查审计。是 isolate-first，不是拿来就直接执行。
Q：对独立开发者，实话怎么说？
多半是 Hermes。EvoMap 的价值随网络节点变多而放大。对单人开发者，飞轮还没转起来。Hermes 立刻给你持久 memory 和 skill 累积，就在本机，不必先啃网络协议。我可能说错——但目前我的判断落在这儿。
Q：agentskills.io 和 GEP，本质差在哪？
agentskills.io 是文件格式标准——规定 skill 文档长什么样，好让不同 agent 平台都能读。GEP 是带完整资产生命周期的协议：publish、validate、promote、衰减、revoke。agentskills.io 里的 skills 没有状态。GEP 里的 Capsules 有。这是技术上的分水岭。
我大概会继续看两边怎么演进。这个对比底下可能还有我没挖到的层——尤其是当 Hermes agent 和 GEP 节点开始出现在同一套工作流里的时候。
那块还不完全清楚。我会再回来写。
