从源码看 Hermes Agent 的两颗大脑:一颗负责远方,一颗负责来路

摘要：很多人谈 Agent 记忆，只盯着“它能不能记住我说过什么”。但 hermes agent 更值得看的地方，不是一个更长的聊天历史，而是一套面向长期使用的双向结构：一颗大脑负责远方，用 LLM Wiki 把外部资料编译成可探索、可审计、会增长的个人 wiki；另一颗大脑负责来路，用 Closed Learning Loop 把做过的任务沉淀成 memory、session 历史与 Skill。前者让 Agent 持续理解世界，后者让 Agent 不再从零开始。

别把 Agent 记忆理解得太窄

你可能有过这种经历。

为了研究一个主题，你让 AI 读了十几篇论文、几个 GitHub 仓库、几份产品文档。它当时整理得很好：概念差异、关键争议、可复用案例，都讲得清清楚楚。

但隔几天你再问同一个主题，它还是像第一次开始工作：重新找资料、重新摘要、重新拼关系。上一次形成的判断，留在了聊天记录里，却没有变成下一次可以继续生长的知识。

另一种情况发生在任务执行里。你和 Agent 一起排查过脚本、修过环境、确认过偏好；下一次相似任务，它仍然需要你重新解释目录、边界和踩过的坑。

这才是长期 Agent 的真正问题。不是会不会保存信息，而是保存的信息能不能在长期工作中产生复利。

如果一次任务结束后，只留下聊天记录，那它只是会回忆。如果系统能更新知识结构、修订工作规程、沉淀错误处理经验，并在下一次相似场景里自动调用，那它才开始具备“成长”的雏形。

这也是 hermes agent 值得拆解的地方。它的核心不是“我有一个记忆功能”，而是把长期 Agent 拆成了两条方向相反的链路：

• • 向前：面对世界，把外部资料编译收录成一个可探索的个人 wiki。
• • 向后：面对自身，把已经做过的事沉淀成 memory、session 历史和 Skill。

这两条链路合在一起，就像两颗大脑。

一颗负责远方，一颗负责来路。

第一颗大脑：向前探索，把资料编译成个人 wiki

第一颗大脑的起点，不是某个知识库功能，而是 hermes agent 对长期运行的要求。

hermes agent 不是一个只回答当前问题的聊天窗口，而是一个会长期运行、会调用工具、会跨会话工作的 Agent。只要它长期运行，就会遇到一个很实际的问题：世界一直在增加新资料，但 Agent 不能每次都只靠临时检索来理解世界。它需要一个面向外部世界的“知识整理器”。

这就是 LLM Wiki 在 hermes agent 里出现的位置。它既不是 memory 系统，也不是普通检索系统，而是给长期 Agent 补上一层外部知识中间层：把资料从“我曾经看过”推进到“我已经整理进自己的知识地图”。

LLM Wiki 的关键，也因此不是“用大模型问文档”，而是“让大模型维护一个知识中间层”。

常见做法里，你收集资料，然后在需要回答问题时再检索。检索增强生成（RAG）的经典定义也是这样：把模型自身已有的知识和外部可检索资料结合起来，在生成答案时找回相关内容，解决知识更新、出处和事实覆盖问题。

这条路线很重要，也仍然是很多企业知识库和文档问答的底座。它更像“接入资料的通道”：资料很多、更新很快、需要带出处回答时，RAG 非常合适。

但个人长期研究还有另一类需求：不是只想在当下找到相关片段，而是希望这一次形成的综合判断能留下来，下一次继续生长。你今天问“LLM Wiki 和 RAG 有什么区别”，系统找资料、拼答案；明天你继续问“它和图谱式检索、长期记忆系统的关系是什么”，如果昨天的综合没有沉淀，今天就很容易重新来一遍。

LLM Wiki 补的是这部分。

它尽量把知识整理前移到“摄取资料”的阶段：当你加入一篇论文、一个 GitHub 仓库、一份会议纪要或一篇产品文档时，Agent 不只是把它存进索引，而是把它读懂、归档、交叉引用、更新已有页面、标注冲突、修订综合判断。

也就是：知识先被“编译”一次，然后持续保值。

个人 wiki 的三层结构

Hermes 仓库里的 llm-wiki Skill 把这套方法固化成了非常清晰的三层结构：

wiki/  SCHEMA.md        # 规则：命名、标签、页面类型、更新策略  index.md         # 导航：所有页面和一句话摘要  log.md           # 历史：每次摄取、查询、检查的动作日志  raw/             # 原始资料：不可变，只读  entities/        # 人物、组织、产品、模型等实体页  concepts/        # 概念、方法、技术路线页  comparisons/     # 对照分析页  queries/         # 值得保留的查询结果

这不是一个花哨目录，而是一种职责划分。

raw/ 是证据层，保证可追溯。模型可以读，但不应该随手改。wiki/ 里的实体页、概念页、对照页是编译层，承载当前理解。SCHEMA.md 是制度层，规定 Agent 该怎么命名、什么时候创建新页、怎么处理矛盾、怎么更新索引。

真正重要的是：这套结构让个人 wiki 从”资料仓库”变成”可维护系统”。

你不只是把资料存起来，而是不断回答三个问题：

• • 这份新资料改变了哪些旧判断？
• • 它应该更新哪几页，而不是新建一堆重复页面？
• • 这次问答值不值得沉淀成未来可复用的页面？

LLM Wiki 带来的好处，不只是检索更快

第一，信息整合从“临时回答”变成“持续更新”。

RAG 更擅长把相关片段找出来，LLM Wiki 更强调把综合结论留下来。对个人研究、深度写作、竞品分析、课程学习这类长期主题来说，真正有价值的不是某次回答，而是一个不断变厚的判断层。

第二，优先阅读对象从原始资料变成编译后的知识页。

你不再每次都让模型去原文碎片里重新发现关系，而是优先读已经整理好的实体页、概念页和对比页。原始资料仍然在，但它更像源码和证据，而不是每次回答的唯一入口。

第三，个性化不再只靠模型“记住我”，而是靠 wiki 结构体现。

一个创作者的个人 wiki，会有“选题判断”“工具判断”“表达风格”“可复用案例”；一个开发者的架构 wiki，会有“服务边界”“事故复盘”“库选型”；一个研究者的论文 wiki，会有“方法谱系”“实验争议”“未解问题”。个性化不是一句偏好，而是目录、页面、链接和更新策略。

第四，错误更容易被审计。

LLM Wiki 不是让模型随便生成一个“看起来像百科”的结论库。它要求保留原始资料，要求索引和日志，要求冲突显式标记。只要这个纪律没有丢，错误就能通过变更对比、证据回链、健康检查和人工审阅被发现。

第五，它对内容工作流特别友好。

写深度文章时，最耗人的往往不是写句子，而是整理资料、建立对照、维护判断、回收旧素材。LLM Wiki 把这些动作变成可重复流程：新资料进来，更新知识页；新问题问完，留下查询页；新判断成立，写进对比页。

这比“把十个链接丢给模型，让它帮我总结一下”更像长期系统。

RAG 找回资料，LLM Wiki 留住理解

在同一条知识流里，RAG 更靠近”回答现场”：问题出现时，把相关材料找回来；LLM Wiki 更靠近”研究沉淀”：资料摄取后，把反复出现的关系、判断和冲突留下来。

如果你只是临时问一份文档，重点是把相关内容找回来；如果你连续三个月研究同一主题，真正的瓶颈就会从检索转到沉淀：哪些判断被反复验证，哪些关系值得长期保留，哪些过时内容需要清理。

在真实工作流里，它们甚至可以前后相接：先用检索找到材料，再把真正值得复用的理解写进 wiki；先完成一次回答，再决定哪些结论需要沉淀。

从 Skill 源码看：它不是算法，而是纪律

Hermes 的 llm-wiki Skill 本质上不是一个复杂算法包，而是一份写给 Agent 的操作规程。它的关键，不在某个向量模型，而在把 Agent 的行为锁进几个步骤。

用简化后的流程看，大致是这样：

每次进入知识库：  1. 读 SCHEMA.md，理解领域和规则  2. 读 index.md，知道已有页面  3. 读最近 log.md，知道最近做过什么摄取新资料：  1. 保存原始资料  2. 搜索已有实体和概念  3. 创建或更新相关页面  4. 添加交叉引用和来源  5. 更新 index.md  6. 追加 log.md查询问题：  1. 先读 index，再读相关知识页  2. 必要时全文搜索  3. 基于编译知识回答  4. 如果答案有长期价值，回写到 queries/ 或 comparisons/健康检查：  1. 找孤儿页、坏链接、缺失索引  2. 查元数据和标签  3. 标注过期内容与矛盾  4. 输出修复建议并写 log

这段逻辑通俗到几乎不像“源码解析”。但恰恰是这种通俗，说明 LLM Wiki 的价值点不在神秘技术，而在工作流约束。

Agent 最容易犯的错，不是不会总结，而是不知道什么时候停、什么时候更新旧页、什么时候不要新建重复页面、什么时候必须承认矛盾。SCHEMA.md、index.md、log.md 和健康检查的存在，就是为了把这些隐性判断显性化。

个人 wiki 因此更像一种“知识编译工程”。

它让 hermes agent 的第一颗大脑向前生长：读更多资料，连更多关系，形成更大的外部世界模型。

第二颗大脑：向后沉淀，把经历变成能力

如果 LLM Wiki 解决的是“我如何理解外部世界”，Closed Learning Loop（闭环学习回路）解决的就是另一个问题：

我如何从自己做过的事里成长？

Hermes README 和官方文档把这套 Closed Learning Loop 放在很核心的位置：从经验生成 Skill，在使用中改进 Skill，提示自己持久化知识，检索过去会话，并逐渐建立对用户的长期模型。

这句话容易被误读成”它有记忆”。但 Closed Learning Loop 不是一个记忆文件，而是一组召回路径，再加上一条判断链。

要看懂这条链，先要把四个东西拆开。

第一是 session。它是当前任务的工作现场：你刚说过的话、Agent 刚调用过的工具、刚读过的文件、刚遇到的报错，都会先在当前上下文里发挥作用。session 的优势是即时、细节丰富；限制是它会随上下文增长被压缩，不适合当长期事实库。

第二是 memory。它是跨会话都应该默认带着的短事实，比如用户偏好、环境事实、项目约定和稳定教训。它不负责保存完整历史，而负责让下一次会话一开始就少问几句。

第三是 session_search。它不是“又一个 memory 文件”，而是过去 session 的检索入口。当前上下文里没有某段历史时，Agent 可以通过它回到会话库里找：“上次为什么这么改？”“那次失败的命令是什么？”“之前为什么放弃这个方案？”

第四是 Skill。它和前三者不是同一类东西。session、memory、session_search 主要回答“发生过什么、应该记住什么”；Skill 回答的是“下次遇到类似任务，应该怎么做”。它更接近程序性能力，而不是历史记录。

所以这套机制的分工不是“把所有东西都记住”，而是让不同经验走不同入口：

• • session 管现在发生的上下文；
• • memory 管未来默认要带着的短事实；
• • session_search 管过去发生过的具体历史；
• • Skill 管下次可以复用的行动方法。

把这四条路径接起来，才是 Closed Learning Loop。

这条链最关键的是生效时机。

session 在当前任务里立刻生效；memory 在下一次会话启动时生效；session_search 在需要追溯历史时按需生效；Skill 在任务触发后按需加载。这样一来，Agent 不需要把全部历史塞进提示词，也不需要把所有经验都写成永久记忆。

memory：短、稳、可注入

Hermes 的 memory 工具源码说明了它的设计取舍。

它不是一个无限向量库，而是两个有边界的 Markdown 文件：MEMORY.md 和 USER.md。前者保存环境事实、项目约定、工具经验；后者保存用户偏好、沟通风格和工作习惯。会话开始时，这两份内容会作为冻结快照注入系统提示；会话中虽然可以写入磁盘，但不会立刻改变当前系统提示，以保持前缀缓存稳定。

可以把源码逻辑简化成这样：

class MemoryStore:    def load_from_disk(self):        self.memory_entries = read("MEMORY.md")        self.user_entries = read("USER.md")        self.snapshot = render_for_system_prompt(...)    def add_or_replace_or_remove(self, target, entry):        scan_for_injection(entry)        lock_file()        update_entries()        atomic_write()    def format_for_system_prompt(self, target):        return self.snapshot  # 会话开始时冻结

这里有几个细节很关键。

第一，文件有长度限制。从源码配置看，MEMORY.md 约 2,200 字符，USER.md 约 1,375 字符；超过 80% 容量时，系统会建议先整合旧条目。这逼迫 Agent 保持克制，不能把每次任务进展都塞进去。记忆越短，越像“稳定事实”；记忆越长，越像垃圾场。

第二，写入前有注入/外泄扫描。因为记忆会进入未来系统提示，一旦里面混入“忽略之前指令”这类内容，风险比普通笔记更高。

第三，会话中写文件、下次再注入。这是一种工程上的克制：不让系统提示在同一会话里频繁变化，也避免缓存失效和行为漂移。从源码逻辑看，系统会每 10 个用户回合提醒 Agent 考虑保存记忆；在压缩、重置或退出前，如果会话已经足够长，会给 Agent 一个回合先刷新重要记忆，避免上下文丢失。

所以 Hermes 的记忆不是”多记一点”，而是”只把未来每次都值得带上的东西写进去”。

Skill：把经历翻译成程序性记忆

Hermes 更有趣的地方，在于它把 Skill 当作“程序性记忆”。

判断一段经验是不是应该升级成 Skill，不看它听起来重不重要，而看它能不能指导下一次行动。可以看五件事：

• • 它在什么场景触发；
• • 下一次应该先读哪些上下文；
• • 需要调用哪些工具或脚本；
• • 哪些验证不能省；
• • 哪些坑不要再踩。

如果这些问题能写清楚，它就不该只留在聊天记录里，而应该进入 SKILL.md。下一次遇到类似任务，Agent 不需要你重新解释“上次是怎么搞定的”。它只需要加载 Skill。

官方 Skill 文档里有一个重要设计：渐进加载。Agent 先看到 Skill 列表和简短描述；只有需要时，才加载某个 SKILL.md 的全文；如果 Skill 还有参考资料、模板、脚本、素材，也可以按需读取具体文件。

简化成代码结构就是：

skills_list()  -> 只返回名称、描述、类别skill_view(name)  -> 加载 SKILL.md 全文skill_view(name, file_path)  -> 加载参考资料、模板、脚本中的某个文件

这和 LLM Wiki 很像：都在避免“一上来把所有东西塞进上下文”。不同的是，LLM Wiki 维护的是外部知识，Skill 维护的是行动方法。

更关键的是，Hermes 支持 Agent 管理 Skill。从源码解读看，Skill 系统覆盖创建、修改、删除、验证、安全扫描和同步；官方文档也把本地 ~/.hermes/skills/ 作为 Skill 主目录，从 Skill Hub 安装和 Agent 创建的 Skill 都会进入这里。

这就让“成长”不再停留在聊天层。

这就是程序性记忆。

四条路径如何联动

一个真实工作流里，session、memory、session_search 和 Skill 通常这样分工。

假设你让 Hermes 维护一个自部署研究助手：每天抓取指定领域的新论文和项目更新，去重后写入个人 wiki，每周生成一份研究摘要；如果抓取失败、格式变化或摘要质量下降，它要能自己排查并修复流程。一次长任务后，它可能发现三件事：

第一，你偏好短摘要、强引用、少评论，只希望在周报里看到“新增事实、判断变化、待验证问题”。这是用户偏好，应该写入 USER.md。

第二，这套研究助手固定把原始资料放进 raw/，把编译后的页面放进 wiki/，抓取脚本必须先跑去重，再更新索引和日志。这是环境事实和项目约定，应该写入 MEMORY.md。

第三，它摸清了一套“研究资料摄取流程”：先抓取源，校验来源，去重，更新相关 wiki 页，标注冲突，再跑一次链接和索引检查。这不是事实，而是流程。它应该沉淀成 SKILL.md。

下次你说“把本周新增的 Agent 记忆资料并入研究 wiki”，四条路径会同时发挥作用：

• • 当前 session 提供本轮刚抓取的资料、刚出现的报错、刚改过的脚本；
• • USER.md 决定语气；
• • MEMORY.md 决定目录和脚本边界；
• • SKILL.md 决定执行步骤和校验动作。

如果还要追溯“上次为什么把某个项目排除在周报之外”，再用 session_search 查过去 session 的具体历史。

这才构成 Closed Learning Loop。

它的本质，是让不同经验走不同的召回路径，而不是全部塞进同一个文件：session 留住现场，memory 留住短事实，session_search 留住历史入口，Skill 留住做事方法。

这也能区分它和单纯的会话续接层：也就是帮 Agent 找回上一轮项目现场的那类索引层。它关心的是下一次能不能接上过去；Closed Learning Loop 多问一步：这段过去应该只是被检索、写进 memory，还是升级为 Skill。前者解决“接得上”，后者解决“学得会”。

两颗大脑合在一起，才是长期 Agent

两条线合在一起，长期 Agent 的形状才完整。

向前的大脑让 Agent 不只是回答眼前问题，而是不断扩展外部知识地图。

向后的大脑让 Agent 不只是完成当下任务，而是把完成任务的方式保存下来。

一个只向前的系统，会越来越会查资料，却不一定越来越会做你的事。它可能拥有一个很漂亮的 wiki，但每次执行具体工作仍然需要你重新解释流程。

一个只向后的系统，会越来越懂你的习惯，却容易困在自己的历史里。它能接上上次任务，却不一定能持续吸收外部世界的新知识。

Hermes 真正值得观察的，是它试图把这两种增长放到同一个长期 Agent 里。

外部知识通过 LLM Wiki 进入系统，内部经验通过 Closed Learning Loop 回到系统。一个解决“世界变大”，一个解决“自己变深”。

个人工作流怎么落地

如果你不是 Hermes 的核心开发者，只是一个想让 AI 工作流更稳的人，可以先不急着追完整系统，而是用四个问题判断自己该建哪一层。

第一，你丢的是资料吗？

如果问题是“我有很多资料，但找不到、问不准、引用不稳”，先用 RAG 或文档检索系统。它解决的是“找得到”。

第二，你丢的是结论吗？

如果问题是“我每次研究都能得到答案，但答案留在聊天里，下次还要重新综合”，你需要 LLM Wiki。它解决的是“留得下”。

第三，你丢的是上下文吗？

如果问题是“上一次会话做了什么、改到哪、为什么这么改，下一次接不上”，你需要会话续接层，比如 session 搜索、项目事件索引或历史观察检索。它解决的是“接得上”。

第四，你丢的是能力吗？

如果问题是“同一类任务做了很多次，但每次还要重新解释流程、重新提醒边界、重新踩坑”，你需要 Hermes 式的 Closed Learning Loop。它解决的是“学得会”。

把这四句话放在一起，就是最小判断框架：

这比把所有东西都叫“AI 记忆”更有用。

因为不同系统要付出的治理成本不同。RAG 要管索引和权限；LLM Wiki 要管规则文件、链接和过时内容；会话续接层要管项目历史和搜索噪音；Hermes 要管 memory 写入、Skill 安全、工具授权和长期运行边界。

没有一条路线是免费的。

长期 Agent 的真正难点，从来不是“能不能记住更多”，而是“能不能知道什么该记、记在哪里、何时召回、何时删除、何时升级成流程”。

最后：一颗负责远方，一颗负责来路

技术系统最动人的地方，有时不在它展示了多少能力，而在它暴露了我们真正想要什么。

我们想要的不是一个永远在线的聊天框。我们想要的是：那些读过的材料不要散落，那些走过的弯路不要白走，那些反复验证过的方法不要在下一次清晨重新归零。

LLM Wiki 像一张向外展开的地图。每一篇论文、每一个仓库、每一次阅读，都在地图上留下新的地名、道路和注释。它让一个人不再只是收藏世界，而是慢慢拥有自己的世界模型。

Closed Learning Loop 像一册向内书写的航海日志。每一次任务、每一次纠错、每一次被用户提醒“下次别这样”，都不只是过去，而是下一次出发前会被重新带上的经验。

这就是 hermes agent 的两颗大脑。

一颗负责来路，替你记住如何抵达这里；一颗负责远方，替你持续追问世界。

一个长期的 AI 工作流，也许就应该这样生长：既不沉迷新工具带来的眩光，也不困在旧经验的回音里。它一边把世界编译成可走的路，一边把走过的路沉淀成更稳的脚步。

当这两件事同时发生，Agent 才不再只是一次性点亮的火花。

它开始像一盏灯，沿着你的工作、你的判断、你的时间，慢慢往前照。

一颗负责来路，让经验不再从下一次清晨归零；一颗负责远方，让世界不断进入你的判断。

参考资料

• • Karpathy, LLM Wiki：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
• • Hermes Agent README：https://github.com/NousResearch/hermes-agent
• • Hermes llm-wiki Skill：https://github.com/NousResearch/hermes-agent/blob/main/skills/research/llm-wiki/SKILL.md
• • Hermes Skills 文档：https://hermes-agent.nousresearch.com/docs/user-guide/features/skills
• • Hermes Persistent Memory 文档：https://hermes-agent.nousresearch.com/docs/user-guide/features/memory/
• • RAG 论文：https://arxiv.org/abs/2005.11401