爱马仕Agent精髓解析多数人误解的真正内涵

最近，AI Agent 领域有个项目势头很猛——Hermes Agent（也有人叫它“爱马仕”）。两个月不到，GitHub Star 数冲到了 10.9 万，Hacker News 上也拿了 1064 的高分。社区讨论热度很高，但仔细一看，大家夸的点似乎都集中在表面：支持十几个模型提供商、能接入十八个消息平台、Agent 还能自己学习创建 Skill……

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

这些功能确实不错，但说实话，它们并非 Hermes 真正做对的事情。多 Provider 支持本质上是个凭证管理和流量调度问题，市面上已有成熟的解决方案；而多平台适配，更多是体力活，谈不上架构创新。那么，什么才是它与众不同的内核？

答案是 Curator——一个确保 Agent 知识库不会随时间“腐烂”的自动维护机制。这才是目前 AI Agent 领域最被低估，也最关键的工程挑战，而 Hermes 给出了一份相当优雅的答卷。

那些“不错”但并非核心的卖点

我们先快速过一下那些常被提及的亮点。多模型支持，核心是做了个统一的凭证管理层，能根据策略轮换 API Key，并在遇到限流时自动切换。这在工程上并不复杂，OpenRouter 或 Vercel AI Gateway 这类中转服务已经解决了大部分问题。

至于支持 18 个消息平台，本质是一系列适配器在完成消息格式的转换。这活儿需要耐心，是脏活累活，但确实不涉及底层架构的突破。

这些功能有用吗？当然有用。但它们更像是“及格线”上的配置，而非让 Hermes 与其他 Agent 框架拉开代差的关键。真正的分水岭，藏在它的 Skill 系统，尤其是 Skill 的维护逻辑里。

Skill 自动创建：酷，但并非壁垒

Hermes 有一个后台学习机制：每次对话结束后，它会派一个后台 Agent 复盘这次对话，判断是否有价值被记住，然后将操作经验提炼成 Skill 文件保存下来。

听起来很智能，对吧？但如果你用过 Claude Code，可能会觉得似曾相识。Claude Code 的 Hooks 系统允许你在特定事件（比如对话结束）触发自定义脚本，完全可以用几行配置就让模型总结对话并生成 Markdown 文件存到本地。

所以，让 Agent 自动保存经验这件事，本身技术门槛并不高。任何具备工具调用能力的 Agent 框架理论上都能实现。那么，真正的难题是什么？

真正的挑战：当 Skill 泛滥成灾

想象一下这个场景：一个 Agent 持续运行了半年，自动创建了 200 个 Skill。这 200 个 Skill 里，必然混杂着几种“不良资产”：

一是重复项。比如解决同一个 Docker 网络问题，可能在不同对话中生成了三个相似的 Skill。

二是过时项。半年前总结的某个 API 调用方式，如今接口可能早已变更。

三是低质项。后台 Agent 偶尔会总结出一些模棱两可、步骤不清的 Skill。

如果任由这些 Skill 堆积，会发生什么？Agent 的检索精度会持续下降。因为当新任务到来时，Agent 需要从 Skill 库中寻找最相关的来辅助执行。库里的噪音越大，找到正确 Skill 的概率就越低。更糟糕的是，如果它不幸找到一个过时的 Skill 并执行，结果可能比没有 Skill 还要差。

这就像你的个人笔记库：初期每条都是精华，但一年后翻开，里面充满了重复、过时和未完成的记录，查找效率反而大打折扣。

目前，大多数 Agent 项目只解决了“如何写入记忆”的问题，却完全忽略了“如何&维护记忆”。写入容易，维护才是真正的工程难题。而这，正是 Hermes 的 Curator 机制所要解决的。

Curator：Agent 的“睡眠整理员”

Curator 是 Hermes 的一个后台维护任务，专门负责给 Skill 库做“大扫除”。它的设计智慧，不仅在于“做什么”，更在于“何时做”以及“不做什么”。

触发时机：克制且智能

Curator 并非一个定时任务。它只在满足两个条件时触发：Agent 空闲时间超过 2 小时，且距离上次 Curator 运行已超过 7 天。这个设计非常克制，确保了整理工作不会干扰主对话流程，也不会在系统繁忙时抢占资源，只在真正“闲暇”时默默工作。

这不禁让人联想到人类大脑的“睡眠记忆巩固”过程——白天接收信息，睡眠时自动整理归档。Curator 扮演的正是 Agent 的“睡眠整理”角色。

核心工作：四项清理任务

每次运行时，Curator 会执行四件套：

1. 质量评分： 使用 LLM 对每个自动生成的 Skill 进行评估，判断其内容清晰度、步骤可复现性，以及是否与其他 Skill 重复。

2. 合并重复： 发现描述同一件事的 Skill 时，不是简单删除一个，而是提取两者的精华，合并成一个更完整、准确的版本。

3. 归档陈旧： 将超过 90 天未被使用的 Skill 移动到 .archive/ 目录。注意，是“归档”而非“删除”，这意味着随时可以恢复。

4. 生成报告： 每次运行的结果都会保存在 logs/curator/ 目录下，包括一份 REPORT.md 和对应的 JSON 数据。你可以随时查看 Curator 做了什么、修改了什么以及修改的原因。

设计边界：什么不该做

这才是 Curator 设计中最值得借鉴的部分——它为自己设定了清晰的硬性约束：

权限隔离： 只处理 Agent 自动生成的 Skill。对于内置的、从社区下载的、或用户手动创建的 Skill，Curator 一律不动。这划清了自动化系统与人为干预内容的边界。

用户豁免权： 被用户“置顶”（pin）的 Skill 免疫一切自动操作。这给了用户一个明确的最终控制开关。

永不删除： 只归档，不删除。在自动化决策可能出错的前提下，永远选择可逆的操作，这是非常重要的设计哲学。

成本隔离： Curator 使用独立的 LLM 调用，不影响主 Agent 的 Prompt 缓存命中率。后台维护的成本与主对话完全分离。

完整的 Skill 生命周期管理

配合 Curator，Hermes 为 Skill 定义了一套清晰的生命周期状态：

新创建的 Skill 状态为 active。如果 30 天未被使用，则标记为 stale。若 90 天未被使用，Curator 会将其自动归档。但这个过程并非单向的：一个已被标记为 stale 的 Skill 若被重新使用，状态会恢复为 active；归档的 Skill 也可以手动恢复。

还有一个精妙的细节：Skill 在使用中会自我改进。如果 Agent 在执行某个 Skill 时发现了更优的操作方式，它会在后台的复盘阶段更新这个 Skill 的内容。这就好比按照菜谱做菜时，发现“中火改小火”效果更好，于是顺手在菜谱上做了批注。Skill 因此得以持续进化。

所有这些机制共同形成了一个正向飞轮：Agent 用得越多，积累的 Skill 就越多；Curator 定期清理，确保知识库质量；Skill 又在使用中不断自我改进，使得 Agent 越来越好用。而这个飞轮能持续转动的关键，不在于“不断添加”，而在于“持续维护”。没有 Curator，这个系统很快就会被噪音淹没。

为什么这个问题至关重要？

之所以花这么多篇幅探讨 Curator，是因为它直指 AI Agent 领域一个被严重忽视的核心问题：自动化系统产出的内容，谁来负责质量控制？

当前，行业的焦点都集中在扩展 Agent 的“能力”上——能调用多少工具、能集成多少平台、能处理多复杂的任务。但很少有人深入思考：Agent 自身产出的知识、经验和记忆，其质量如何保证？过时了怎么办？出现重复或错误又该如何处理？

这绝非小问题。随着 Agent 自主性增强、运行时间拉长，它自身积累的“知识库”将成为影响其性能的核心因素。如果这个知识库缺乏维护机制，Agent 就会陷入“用得越久，表现越差”的窘境——这与人类组织中“文档/Wiki 腐烂”的问题如出一辙。

Hermes 的 Curator 提供了一套可行的思路：用 LLM 来维护 LLM 产出的知识，同时施加严格的约束——只处理自动生成内容、永不删除只归档、赋予用户覆盖权限、后台运行不影响主线任务。这套设计原则——空闲触发、最小权限、可逆操作、成本隔离——对于任何涉及“长期运行 Agent”的产品，都具有极高的参考价值。

总结

回过头看，Hermes Agent 凭借 10 万以上的 Star 数吸引了大量关注，其多模型支持、多平台接入和 Skill 自动创建功能固然亮眼。但这些，或许并非它最与众不同的地方。

真正的精髓在于 Curator——那个确保 Agent 知识库历久弥新的维护机制。它针对“长期运行”这一根本性挑战，给出了目前看来最为优雅的解决方案。说到底，一个 Agent 能记住东西并不稀奇；能自动忘掉该忘的、整理好该留的，才是真本事。