大多数 AI Agent 本质上只是"记性不错但没有常识的临时工"。他们能翻看过去的聊天笔记，但内核从未真正成长。任务结束，经验清零；下次再来，它对你的习惯依然一窍不通。Hermes Agent 走了一条截然不同的路：它不仅记住了你说过什么，还把它做过的每一件复杂的事转化为可复用的"技能"，并随着使用时间的增长变得越来越擅长为你服务。
一、Hermes 又火了，但这一次，问题已经变了
最近如果你在关注Agent，很难绕开 Hermes Agent。
但有意思的是，这一波讨论其实出现了一个明显的错位：大多数人仍然在用“工具升级”的视角理解它，比如多了多少工具、支持多少平台、自动化程度有多高，甚至把它当作“下一个 OpenClaw”。
如果你停在这里，会得出一个完全错误的结论。
因为 Hermes 真正解决的，从来不是“Agent能不能更强”，而是一个更底层的问题：Agent到底能不能形成“经验”，而不是反复消耗上下文。
过去两年，“有记忆的Agent”几乎成了行业共识。但如果你仔细拆开，会发现所谓“记忆”其实只有两种实现路径：要么把历史对话不断堆进prompt，要么通过向量数据库做RAG检索。看起来都在“记忆”，但本质上只是“存储”。
问题在于，这两种方式都没有解决一件真正关键的事情：知识有没有被压缩成可复用的结构。
当你让一个Agent记住100次“我们用PostgreSQL”，一个好的系统应该只保留“我们用PostgreSQL”这一条稳定事实，而不是在下一次检索时返回100条冗余信息。否则系统不是在学习，而是在变得越来越臃肿。
Hermes的意义，就在于它选择了第三条路：不堆上下文，而是构建一个会自我压缩、自我演化的认知系统。
二、一个更准确的抽象：Hermes不是Agent，而是“运行中的系统”
理解Hermes，最容易犯的错误，是把它当成一个“更强的Agent”。
但如果你从工程视角看，它更接近一个长期运行的系统，而不是一次性调用的工具。
在传统Agent中，无论是 Claude Code 这样的交互工具，还是 OpenClaw 这种配置型框架，它们的共同点是：每一次执行，本质上是一个独立的推理过程。
上下文可以延续，但系统本身不会发生结构变化。你今天纠正它的错误，并不会改变它明天的默认行为。
而Hermes的设计前提完全不同：系统是持续运行的，状态是可累积的，行为是可以被修改的。
换句话说，它不是在优化“这一次回答”，而是在优化：未来所有类似问题的默认解法。
这就是为什么很多人第一次用Hermes，并不会觉得它“明显更强”，但用几天之后，会出现一个明显的体验跃迁：它开始变得“顺手”。
三、核心主线：Hermes其实在做三件事
如果把整个系统压缩成一句话，Hermes在做的事情其实非常简单：把信息压缩成结构，把结构转化为规则，再让规则反过来约束未来行为。
为了做到这一点，它在工程上拆成了三层：
记忆系统（压缩信息）
检索系统（按需调度信息）
Skill系统（把信息变成规则）
这三层不是功能模块，而是三种不同的“时间尺度”。
四、第一层：记忆系统——不是“记住”，而是“压缩”
4.1 MEMORY.md / USER.md：刻意受限的长期记忆
Hermes的长期记忆实现非常“反常识”：它不是数据库，而是两个Markdown文件：
MEMORY.md：记录环境事实、项目经验、操作规范
USER.md：记录用户偏好、行为模式、沟通风格
它们通常位于：~/.hermes/memories/。
而最关键的点是：总容量被严格限制在约1300 token。
这不是限制能力，而是刻意设计。
因为一旦允许无限增长，系统最容易做的事情就是“全部记录”，而不是“选择性保留”。最终结果不是更聪明，而是更混乱。
Hermes通过容量约束，强迫系统必须完成一个更高级的操作：信息筛选 + 信息压缩。
4.2 Frozen Snapshot：性能与一致性的经典取舍
每次会话开始时，这两个文件会被一次性注入系统prompt，并在整个会话中保持不变。
即使中途更新记忆，也不会影响当前会话，而是在下一次会话才生效。
这个设计背后有两个核心动机：
第一，是性能。固定前缀意味着可以利用LLM的prefix cache，从而显著降低token成本。
第二，是一致性。如果记忆在会话中动态变化，模型的行为将变得不可预测。
代价也很明确：记忆更新是“延迟生效”的。
这实际上是一个非常典型的系统设计选择：牺牲一点实时性，换取整体稳定性和成本可控。
4.3 代理自己管理记忆：从“存储”变成“知识管理”
Hermes的记忆并不是被动写入的，而是由Agent主动管理。
它通过memory工具支持三种操作：
add
replace
remove （没有read，因为记忆已经在prompt中）
更关键的是，当记忆接近上限时，系统会主动进行“压缩”，例如把多条零散事实整合成一条结构化描述。
这意味着，Hermes不是在做“日志记录”，而是在做：持续的知识整理。
五、第二层：Session Search——为什么不是RAG
长期记忆解决的是“最重要的信息”，但大量历史对话仍然存在。
Hermes的做法是：
所有对话写入 SQLite
建立 FTS5 全文索引
按需检索，而不是全量加载
5.1 为什么不用向量数据库？
在大多数Agent系统中，“长期记忆”的默认实现路径几乎是统一的：把历史数据embedding化，然后通过向量数据库进行语义检索。这种方式在知识问答类场景中非常有效，但Hermes刻意绕开了这条路径，转而使用SQLite + FTS5进行全文检索，这背后并不是技术保守，而是对问题本质的重新定义。
Hermes这一层要解决的，并不是“找语义相似的内容”，而是“找曾经发生过的具体行为”。例如，“上周我们是如何修复某个bug的”、“某个接口设计当时是怎么讨论的”，这些问题的本质更接近日志回溯，而不是知识匹配。在这种场景下，向量检索的模糊性反而成为负担，因为它可能返回语义接近但上下文错误的结果，而全文检索则可以提供更强的精确性和可解释性。
更重要的是，全文检索避免了embedding生成、更新和存储的额外成本，使得整个系统可以在本地稳定运行，而不会引入额外的基础设施依赖。从工程角度看，这是一种典型的“问题驱动技术选择”，而不是“技术驱动问题设计”。
5.2 核心思想：历史不是上下文，而是工具
Hermes不会把历史对话全部塞进prompt，而是：只有在需要时，才把相关片段调入上下文。这就是按需检索机制。这一点看似简单，但实际上改变了上下文的基本结构。
在传统设计中，历史信息一旦进入上下文，就会持续占用token预算，并在后续推理中不断产生干扰；而Hermes通过按需检索，把历史从“默认参与者”变成“条件参与者”，只有在被判断为有价值时才进入推理链路。
这种机制的核心价值，在于它把上下文从“信息堆积容器”转变为“高密度决策空间”。模型不再被动接收所有历史，而是通过调用工具主动选择需要的信息，从而提升推理质量和稳定性。
这带来两个关键好处：
token成本稳定
信息密度更高
本质上，它把“记忆”从上下文中剥离出来，变成了一个可调用系统。
5.3 工作记忆 vs 会话检索：两种完全不同的信息职责
Hermes中一个非常容易被忽略，但极其关键的设计，是对“记忆”的职责划分。工作记忆（MEMORY.md / USER.md）承担的是“永远在场的关键事实”，而会话检索承担的是“可能有用的历史上下文”。
前者必须稳定、精炼且高度可靠，因为它直接参与每一次推理；后者则可以是冗余、庞大甚至不完全结构化，因为它只有在必要时才会被调用。这种分工，使得系统既能够保持长期一致性，又不会因为历史积累而逐渐变慢或变乱。
从系统设计角度看，这一步完成的是一次重要的抽象分离：“状态”与“历史”不再混在一起，而是被放入不同的系统中管理。
六、第三层：Skill系统——真正的“进化引擎”
如果说前两层解决的是“记什么”和“怎么找”，那么Skill系统解决的是最关键的问题：如何把经验变成可复用的规则。
6.1 Skill的本质：程序性记忆
在Hermes中，Skill并不是简单的prompt模板，而是一种更接近“程序”的结构化知识单元。一个完整的Skill通常不仅包含任务描述，还包括执行步骤、关键决策点、常见错误以及验证方式，这使得它更像是一份“操作手册”，而不是一段提示词。
这种设计的关键意义在于，它把原本依赖模型即时推理的过程，转化为可以被直接调用的执行路径。换句话说，Skill的存在不是为了让模型“思考得更好”，而是为了让模型“少思考一部分已经被验证过的内容”。这对于复杂任务尤为重要，因为推理路径越长，不确定性就越高，而Skill本质上是在缩短这条路径。
6.2 Skill如何产生：自动经验提炼
Hermes不会依赖开发者手动编写所有Skill，而是通过任务执行过程中的分析，自动判断哪些经验具有复用价值。当一个任务涉及多步操作、具有明确结构，并且在执行过程中经过用户确认或修正时，系统就会倾向于将其抽象为Skill。
这个过程，本质上是在做一件非常关键的事情：把一次性的成功路径，从“偶然事件”转化为“可复用能力”。一旦这一转化完成，后续类似任务就不再需要从零推理，而是可以直接调用已有结构。
从工程角度看，这一步是Hermes区别于大多数Agent的分水岭，因为它意味着系统开始具备“能力积累”的机制，而不是仅仅依赖模型能力。
6.3 Skill自我改进：系统真正开始“学习”
Skill真正的价值，并不在于第一次生成，而在于后续的持续优化。在Hermes中，用户的每一次修正，都有机会被写回到Skill本身，从而改变未来所有类似任务的默认执行方式。
这与传统Agent形成鲜明对比。在大多数系统中，反馈只影响当前结果，而不会改变未来行为；而在Hermes中，反馈会进入系统结构，成为新的约束条件。这意味着系统的行为并不是固定的，而是在不断被“重写”。
从系统角度看，这构成了一个完整闭环：执行 → 反馈 → 规则更新 → 再执行。这个闭环一旦稳定运行，系统的行为就会逐渐收敛到一套对用户最优的路径，而不是每次都重新探索。
6.4 Progressive Disclosure：规模化的关键
随着Skill数量增长，最大问题是上下文爆炸。
Hermes的解决方案是三层加载：
Level 0：Skill索引
Level 1：完整Skill
Level 2：细节文件
只有在相关时才深入加载。
这本质上是在做一件事：把“知识调度”变成模型的一部分能力。
这一设计的关键，不仅在于节省token，更在于把“知识选择权”交给模型本身。系统不再预先决定哪些知识重要，而是让模型在具体任务中动态做出判断，从而提升整体灵活性。
七、Agent Loop：一个持续运行的学习闭环
把前面所有模块串起来，就是Hermes的核心循环：
执行任务
判断：
是否写入记忆
是否生成Skill
是否优化Skill
更新系统结构
下次任务复用
这个循环不是人为触发的，而是持续运行的。
7.1 从“执行任务”到“更新系统”的隐式循环
当记忆系统、检索系统和Skill系统协同工作时，Hermes的执行过程已经不再是简单的“输入-输出”，而是一个持续运行的循环。在每一次任务完成之后，系统都会隐式地进行一系列判断：哪些信息值得进入长期记忆，哪些历史需要被保留但不常驻，当前执行路径是否具有复用价值，以及是否需要生成或更新Skill。
这些判断并不是一次性完成的，而是在多次任务中逐渐收敛，形成稳定的行为模式。换句话说，系统并不是在一次任务中变聪明，而是在一系列任务中逐渐改变自己的结构。
7.2 下一次任务：不是重新开始，而是“带着历史出发”
在下一次任务开始时，Hermes并不是从零开始，而是带着已经压缩过的记忆、可检索的历史以及结构化的Skill进入执行。这意味着系统的初始状态已经发生改变，从而影响整个推理过程。
这种变化并不一定体现在“更高的单次表现”，但会体现在“更低的错误率”和“更稳定的执行路径”上。随着循环不断进行，系统逐渐从“探索状态”过渡到“收敛状态”，这也是用户感知到“越来越顺手”的根本原因。
八、一个关键认知：Hermes为什么“越用越好用”
现在可以回答最核心的问题：Hermes为什么会进化？
不是因为模型更强，而是因为：
8.1 它在压缩信息，而不是堆积信息
传统Agent：历史越来越多。
Hermes：信息越来越精。
Hermes通过容量限制和结构化记忆，持续对信息进行压缩，使得真正重要的事实能够长期保留，而冗余信息被过滤。这种压缩过程，使得系统不会因为历史增长而变得臃肿，反而会逐渐提升信息密度。
8.2 它在把经验变成约束和规则
通过Skill系统，Hermes把一次次成功经验转化为规则，并嵌入系统结构中。这意味着未来的行为不再依赖即时推理，而是优先执行已经验证过的路径，从而减少不确定性。
8.3. 它在减少搜索空间
普通Agent：每次重新推理
Hermes：优先走已验证路径
在传统Agent中，每一次任务都需要在巨大的解空间中重新搜索，而Hermes通过Skill和记忆，将搜索空间逐渐收敛到一组高质量路径上。这不仅提升效率，也提高了结果的稳定性。
九、对比再深化：三类Agent的本质差异
从实现角度看：
Claude Code：实时交互系统。这类系统的核心在于模型能力，每一次输出都是即时推理的结果，优势是灵活，劣势是缺乏长期一致性。
OpenClaw：配置驱动系统。通过人工定义规则，实现一定程度的稳定性，但规则的生成与维护仍然依赖人类，系统本身不会演化。
Hermes Agent：自演化系统。规则可以在运行过程中被系统自身修改，这使得它不再只是执行逻辑，而是逐渐参与逻辑的生成与优化。
本质差异只有一句话：规则是谁在写。
十、最后：Hermes不是AI能力升级，而是系统范式变化
Hermes并没有引入复杂的新技术，而是通过一系列非常克制的工程设计，把“学习”嵌入到系统结构中。文件系统、全文检索、结构化文本，这些基础组件在合理组合之后，形成了一个可以持续演化的系统。
这意味着AI系统第一次具备了时间上的连续性，不再只是一次次独立计算，而是一个可以在使用过程中逐渐改变自身行为的实体。
也正因为如此，Hermes真正的价值，并不在于它当前能做什么，而在于它证明了一种新的可能：AI系统，可以通过运行本身，变得越来越接近“最适合你”的状态。
如果说过去的Agent是在“模拟人类做事”，那么Hermes开始在做另一件事：让系统像人一样，形成经验，并改变自己。
