Hermes Agent架构拆解：记忆、检索与Skill如何构建自进化系统

在人工智能代理领域，大多数AI Agent本质上只是一个“记性不错但缺乏常识的临时工”。它们能够查阅历史对话记录，但内核从未真正成长——任务结束后经验清零，下次交互时对你的习惯依然一无所知。这种局限性严重制约了AI Agent在企业级场景中的应用价值。

传统记忆机制的困境与Hermes的破局之道

Hermes Agent选择了一条截然不同的技术路径：它不仅记住用户说过什么，更将每一次复杂任务执行转化为可复用的“技能”（Skill），随着使用时间的增长变得越来越擅长为用户服务。这一设计的核心突破在于：将信息压缩为结构化知识，将知识转化为可执行的规则体系，让系统能够持续自我优化。

记忆系统：刻意受限的长期记忆设计

过去两年，“有记忆的Agent”几乎成为行业标配，但仔细拆解会发现所谓的“记忆”实现路径极为单一：要么将历史对话不断堆入prompt，要么通过向量数据库做RAG检索。这两种方式本质上只是“存储”，而非真正的“学习”。当系统记住100次“我们使用PostgreSQL“时，一个优秀的设计应该只保留这一条稳定事实，而非在检索时返回100条冗余信息。Hermes选择了第三条路——构建一个会自我压缩、自我演化的认知系统，而非简单地堆积上下文。

检索系统：按需调度的精准知识调用

Hermes的长期记忆实现采用了“反常识“的设计：它并非依赖数据库，而是两个Markdown文件——MEMORY.md记录环境事实和项目经验，USER.md记录用户偏好和行为模式。这两个文件被严格限制在约1300 token的容量内，这一限制并非能力不足，而是刻意设计。无限增长的记忆会导致系统倾向于“全部记录“而非“选择性保留“，最终变得臃肿而非智能。通过容量约束，系统必须完成更高级的操作：信息筛选与压缩。每次会话开始时，这两个文件会被一次性注入系统prompt并在整会话中保持不变，记忆更新采用“延迟生效“策略——这牺牲了实时性，但换取了整体稳定性和可预测的token成本。

在历史对话检索层面，Hermes刻意绕开了主流的向量数据库方案，转而使用SQLite+FTS5进行全文检索。这一选择并非技术保守，而是对问题本质的重新定义。Hermes要解决的并非“找语义相似的内容”，而是“找曾经发生过的具体行为”——例如“上周我们如何修复某个bug”。这类场景更接近日志回溯而非知识匹配，向量检索的模糊性反而可能引入上下文错误。全文检索提供了更强的精确性和可解释性，同时避免了embedding生成和存储的额外成本。

如有侵权，请联系删除。