推荐语
Hermes Agent 突破传统AI记忆局限，构建可自我进化的认知系统，让每一次交互都成为未来服务的优化起点。核心内容： 1. Hermes Agent 与传统AI记忆机制的本质区别 2. 持续运行系统设计带来的体验跃迁 3. 信息压缩与规则转化的核心进化逻辑
杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家
大多数 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文件：
它们通常位于：~/.hermes/memories/。
而最关键的点是：总容量被严格限制在约1300 token。
这不是限制能力，而是刻意设计。
因为一旦允许无限增长，系统最容易做的事情就是“全部记录”，而不是“选择性保留”。最终结果不是更聪明，而是更混乱。
Hermes通过容量约束，强迫系统必须完成一个更高级的操作：信息筛选 + 信息压缩。
4.2 Frozen Snapshot：性能与一致性的经典取舍
每次会话开始时，这两个文件会被一次性注入系统prompt，并在整个会话中保持不变。
即使中途更新记忆，也不会影响当前会话，而是在下一次会话才生效。
这个设计背后有两个核心动机：
第一，是性能。固定前缀意味着可以利用LLM的prefix cache，从而显著降低token成本。
第二，是一致性。如果记忆在会话中动态变化，模型的行为将变得不可预测。
代价也很明确：记忆更新是“延迟生效”的。
这实际上是一个非常典型的系统设计选择：牺牲一点实时性，换取整体稳定性和成本可控。
4.3 代理自己管理记忆：从“存储”变成“知识管理”
Hermes的记忆并不是被动写入的，而是由Agent主动管理。
它通过memory工具支持三种操作：
更关键的是，当记忆接近上限时，系统会主动进行“压缩”，例如把多条零散事实整合成一条结构化描述。
这意味着，Hermes不是在做“日志记录”，而是在做：持续的知识整理。
五、第二层：Session Search——为什么不是RAG
长期记忆解决的是“最重要的信息”，但大量历史对话仍然存在。
Hermes的做法是：
所有对话写入 SQLite
建立 FTS5 全文索引
按需检索，而不是全量加载
5.1 为什么不用向量数据库？
在大多数Agent系统中，“长期记忆”的默认实现路径几乎是统一的：把历史数据embedding化，然后通过向量数据库进行语义检索。这种方式在知识问答类场景中非常有效，但Hermes刻意绕开了这条路径，转而使用SQLite + FTS5进行全文检索，这背后并不是技术保守，而是对问题本质的重新定义。
Hermes这一层要解决的，并不是“找语义相似的内容”，而是“找曾经发生过的具体行为”。例如，“上周我们是如何修复某个bug的”、“某个接口设计当时是怎么讨论的”，这些问题的本质更接近日志回溯，而不是知识匹配。在这种场景下，向量检索的模糊性反而成为负担，因为它可能返回语义接近但上下文错误的结果，而全文检索则可以提供更强的精确性和可解释性。
更重要的是，全文检索避免了embedding生成、更新和存储的额外成本，使得整个系统可以在本地稳定运行，而不会引入额外的基础设施依赖。从工程角度看，这是一种典型的“问题驱动技术选择”，而不是“技术驱动问题设计”。
5.2 核心思想：历史不是上下文，而是工具
Hermes不会把历史对话全部塞进prompt，而是：只有在需要时，才把相关片段调入上下文。这就是按需检索机制。这一点看似简单，但实际上改变了上下文的基本结构。
在传统设计中，历史信息一旦进入上下文，就会持续占用token预算，并在后续推理中不断产生干扰；而Hermes通过按需检索，把历史从“默认参与者”变成“条件参与者”，只有在被判断为有价值时才进入推理链路。
这种机制的核心价值，在于它把上下文从“信息堆积容器”转变为“高密度决策空间”。模型不再被动接收所有历史，而是通过调用工具主动选择需要的信息，从而提升推理质量和稳定性。
这带来两个关键好处：
本质上，它把“记忆”从上下文中剥离出来，变成了一个可调用系统。
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开始在做另一件事：让系统像人一样，形成经验，并改变自己。
粤ICP备14082021号
免费POC，
零成本试错
