最近，Hermes Agent又开始火了，总看到有人把Hermes和之前火热的小龙虾对比。Hermes vs. OpenClaw 的核心区别只有一个：架构设计哲学。

• OpenClaw 是广度优先的任务执行器，Skills是人工编写的静态文件，记忆是基础的Markdown 文件存储。
• Hermes 是深度优先的自学习体，核心是那个闭环：执行 评估 提取 精炼，Skills 由 Agent自动从任务经验中生成，记忆是多层结构（会话/持久/技能），越用越聪明。

这篇文章会展开讲 Hermes Agent 的记忆系统、持续学习和 persona（人设），而这些正是 OpenClaw 缺失设计原则的地方。

Hermes 在 LLM 外面包了一层持久化层，这一层围绕四种不同的知识类型组织，每种类型都有各自的存储、检索和失败模式。最终得到的是一个能够积累事实、教会自己流程、回忆过往经历，并在跨平台和跨时间中维持身份一致性的 agent。

希望你看完以后，能弄清这些火热的智能体的背后原理，而无需慌张，也不用辛苦去追这些热点，因为其背后的技术原理，基本上还算稳定。

1 知识架构

Hermes 把知识拆成四个 store，对应认知科学里一个很有名的分类法：声明式（什么是真的）、程序式（事情怎么做）、情景式（发生过什么）和身份（它是谁）。这种拆分不是比喻，而是一条在系统提示词层面被强制执行的工程约束。

声明式记忆存在两个有边界的纯文本文件里：MEMORY.md（2200 字符）存环境事实，USER.md（1375 字符）存用户画像数据，外加云端持久化用于跨平台保存。这部分由 agent 自己整理，并且始终出现在系统提示词里。

程序式记忆存在 SKILL.md 文件里，**没有大小上限，****由 agent 创建，**按需加载。复杂任务完成之后，agent 会自己写入这部分。

情景式记忆被动记录到 SQLite 中，并带有 FTS5 全文搜索。每条消息都会进去。只有当 agent 需要回忆过去上下文时，才会搜索它。

身份由多层提示词拼出来：SOUL.md、人格预设、平台提示，以及 Honcho 持续演化的 AI peer 表征。始终存在。从不搜索。就在那里。

这些 store 之间的路由是确定性的。当 agent 遇到新信息时，它会走一棵严格的决策树：

这套路由在 _build_system_prompt()（run_agent.py:1825-1966）里强制执行。用户事实 → USER.md（1375 字符）+ Honcho 混合写入。流程 → 如果是 5 次以上工具调用，就走 skill_manage(create)。环境事实 → MEMORY.md（2200 字符）。任务状态 → 不持久化；它已经通过 FTS5 自动触发器存在 SessionDB 里了。所有写入都会经过 tools/memory_tool.py 里的 _scan_memory_content() 扫描。

这是关于用户的吗？→ USER.md。
这是一个可复用流程吗？→ Skill。
这是一个环境事实吗？→ MEMORY.md。
这是任务特定状态吗？→ 不存；它已经在 session DB 里了。

这很重要，因为不同知识类型有不同的经济考量：声明式事实存起来便宜，但保持最新很贵；程序式知识获取起来很贵，但复用起来很便宜。把它们压进同一个 store，就像大多数框架把所有东西都扔进向量数据库那样，会制造随着使用量增长而扩大的检索噪音。

2 本地记忆

两个文件。总共 **3575 个字符。**这就是声明式记忆的全部预算。

**这个约束本身就是设计。**有限 store 强迫 agent 做筛选。它不能记下每一个细节，必须决定什么是重要的，而且这件事受优先级规则支配：先用户纠正，再偏好，再环境事实，最后才是流程备注。每一条 entry 都是精挑细选而来。

三种操作：add（带重复拒绝）、replace（子串匹配 + 预算检查）、remove。**没有 read，**因为记忆始终在系统提示词里可见。

冻结快照模式。记忆会在 session 开始时从磁盘加载一次，并作为冻结快照注入系统提示词。session 中途的写入会进磁盘，但不会更新系统提示词。为什么？因为前缀缓存的稳定性。系统提示词会在每一轮被缓存。你一改它，缓存就失效，后面每次 API 调用都要付完整的重新处理成本。冻结快照用 session 内一致性去交换缓存效率，赌的是：现在存下来的记忆，在未来的 session 里更重要。

这和人类睡眠期间的记忆巩固之间的类比并不只是表面相似。agent 的“白天”就是 session。它的“睡眠”则是 session 之间的间隙，快照会在那个时候解冻。

**nudge interval。**什么会触发主动保存？一个轮次计数器。nudge_interval（默认 10）会定期插入提醒，让 agent 评估最近有没有什么值得持久化。flush_min_turns（默认 6）则防止在很短的 session 里过早 flush。两者组合起来形成一种节奏：工作 → nudge → 评估 → 写盘 → 继续。

**安全扫描。记忆文件会跨 session 存活，所以它们是高价值攻击目标。**每次写入之前，_scan_memory_content() 都会检查提示词注入模式、数据外传命令、SSH 后门模式和不可见 Unicode 字符。通过 os.replace() + fsync() 实现的原子写入可以保证并发读者永远看不到一个部分写完的文件。

3 一个真实的 session 长什么样

架构描述是静态的。下面看在一个真实的大约 25 轮 session 里，这些部分是如何按顺序触发的：

第 1 到第 2 轮：用户要一个导航栏，然后纠正了配色方案，“用深色背景，我讨厌浅色主题。” 计数器递增。

第 4 到第 10 轮：又过了 8 轮在调布局。到第 10 轮，nudge 触发。agent 评估对话，决定深色主题偏好值得保留，于是在后台把 “User hates light themes” 写进 USER.md。系统提示词不会变化，**冻结快照继续保持，**但磁盘上的文件从此就会把这个偏好带到未来所有 session 里。

第 11 到第 22 轮：继续工作。token 估算值跨过 50% 阈值。压缩触发。Phase 1：sentinel 触发，辅助模型扫描中间轮次，flush 额外记忆。Phase 2：中间轮次由 Gemini Flash 总结，首尾部分被保护。Phase 3：session 在 SQLite 中分裂，系统提示词从磁盘重新加载，此时同时吸收了 nudge 写入和 Phase 1 flush 的内容，一个新的前缀缓存开始。

第 23 轮及之后：agent 拥有**更少的原始轮次，但拥有更多持久知识。**下一个 session，哪怕是几天后，加载 USER.md 时，深色主题偏好从第一轮开始就已经在那里了。不需要重新解释。

4 双 peer 模型

本地记忆很快，但受平台绑定。为了跨 session 建模，Hermes 集成了 Honcho。

大多数 agent 记忆系统只建模用户。Honcho 建模双方。它有一个 user peer（关于用户是谁的持续演化表征）和一个 AI peer（关于 Hermes 是谁的持续演化表征）。两边都设置了 observe_me=True，Honcho 会观察双方说了什么，并从被观察到的行为中构建表征。

这提供了一个理解其意义的框架：后训练并不会创造一个全新的实体，它只是从预训练学到的人格空间里进一步精炼。Hermes 在应用层把某种版本的这个过程做成了系统。agent 的身份不只是声明在配置文件里，它还会从真实行为中被观察、积累和更新。意图（SOUL.md）给出目标。观察到的行为（Honcho 的 AI peer）反映现实。两者之间的漂移是可见的。

预取循环。拉取 Honcho 上下文需要一次 HTTP 往返。Hermes 会在每轮结束时启动后台 daemon 线程去预取上下文和 dialectic 结果。下一轮会通过 destructive read 把它们消费掉。热路径上没有 HTTP 延迟。只有第一轮要付出冷启动成本。

5 技能系统

**声明式记忆存事实。情景式记忆存 transcript。两者都不存流程。**Hermes 与典型 agent 的最大分歧就出现在这里。

一个 Skill 是一个带 YAML frontmatter 的结构化 SKILL.md，按类别存储在 ~/.hermes/skills/ 下。它的生命周期是一个闭环：

读路径：tools/skills_tool.py（大约 900 行）—— skill_view 带 frontmatter 解析，Tier 1 索引由 agent/prompt_builder.py 里的 build_skills_system_prompt() 构建。
写路径：tools/skill_manager_tool.py（659 行）—— create/patch/edit/delete。失败时通过 patch（定向 find-and-replace）实现**自我改进。**所有写入都受 tools/skills_guard.py（约 350 行）控制：60 多种模式，按信任等级执行策略。被阻断 → 原子回滚。

任务到来 → agent 检查技能索引（始终在系统提示词里，以紧凑列表形式存在）→ 找到匹配项？加载 skill。没找到？从头解决。任务结束后：它复杂吗（5 次以上工具调用）？如果是，就提议保存成 skill。用了一个现有 skill 但失败了？立刻通过 skill_manage(action="patch") 修补它。

这在应用层很像 on-policy distillation。agent 从自己的轨迹中学习，而不是从预先准备好的示例里学，并且通过不断使用来精炼提取出来的流程。失败后立刻 patch 的机制，正是让这个循环收敛而不是振荡的关键。

渐进式披露让 token 成本保持可控。Tier 1：系统提示词里的紧凑索引（每个 skill 大约 2 个 token）。Tier 2：完整 SKILL.md，按需加载。Tier 3：具体的支撑文件。agent 始终知道自己会做什么，而不用为“知道全部细节”支付完整 token 成本。

**安全门。****六大类、**60 多种威胁模式：外传、注入、破坏性命令、持久化、网络、混淆。按信任等级执行安装策略：builtin（全部通过）→ trusted / agent-created（阻断危险项）→ community（阻断危险项 + 谨慎项）。被阻断的发现会触发原子回滚。

6 Persona(人设)

SOUL.md 定义了核心身份：“You are Hermes, an AI assistant made by Nous Research.” 它的语气哲学是：“你是一个 peer。你知道很多，但你不表演自己知道。” **反模式：**不要 emoji，不要谄媚，不要 hype 词。发送前检查清单：我回答了真正的问题吗？我还能删掉一句吗？

SOUL.md 可由用户编辑。你可以完全重写它。用户拥有这个 agent 的声音。

完整系统提示词会按严格顺序从 12 层组装出来：

它在 _build_system_prompt()（run_agent.py:1825-1966）中组装。第 1 到第 10 层缓存到 self._cached_system_prompt。第 5 到第 6 层：来自 MemoryStore.load_from_disk()（memory_tool.py:108-123）的冻结快照。第 7 层：skills 索引。第 8 层：SOUL.md + 上下文文件。第 11 到第 12 层是临时层：来自 gateway/session.py:196-320 的 session 上下文 + 来自 honcho_integration/session.py 的 Honcho 预取。缓存策略：system_and_3（agent/prompt_caching.py）。

第 1 到第 10 层会被**缓存：每个 session 构建一次，摊销到后面的每一轮。第 11 到第 12 层是临时的，**会在每次 API 调用时随轮次上下文重建。**一个 12 层的身份，在稳态下的成本大致和一个 2 层身份差不多，**因为其中 10 层已经在前缀缓存里了。

7 上下文压缩

每个 LLM 都有有限的上下文窗口。Hermes 用一个三阶段压缩生命周期来处理溢出：

编排入口在 _compress_context()（run_agent.py:3994-4058），核心逻辑在 agent/context_compressor.py（382 行）。Phase 1：flush_memories()（run_agent.py:3832-3921）—— sentinel 注入，一次辅助模型调用，只开放 memory tool。Phase 2：保护头部 3 条 + 尾部 4 条，中间部分由 Gemini Flash（T=0.3）总结，并做工具边界对齐。Phase 3：session 分裂并建立 parent FK，_invalidate_system_prompt()（run_agent.py:2113-2122）从磁盘重新加载记忆，并重建缓存前缀。上下文长度通过 agent/model_metadata.py 中的分级 probe 发现。

Phase 1：Memory flush。任何上下文丢失之前，sentinel 会触发一句话：“Save anything worth remembering.” 一次 API 调用，只开放 memory tool。模型保存下来的内容都会活下来。

Phase 2：Compress。前 3 条消息和后 4 条消息会被保护。中间轮次由 Gemini Flash（T=0.3）总结。边界对齐保证 tool call / result 对不会被拆开。状态注入会附加 todo 快照和文件读取历史。

Phase 3：Session split + rebuild。旧 session 会以 end_reason: "compression" 结束在 SQLite 中。新 session 获得一个 parent FK。系统提示词从磁盘重新加载，吸收 Phase 1 flush 写入的内容，前缀缓存在 1 到 2 轮内重新建立。

这个结果有点**反直觉：**压缩之后，agent 的原始上下文更少了，但持久知识更多了。压缩不是损失。它是巩固。

Prime Intellect 在相关工作中提供了一个互补视角：让模型通过 Python REPL 和子 LLM 来管理自己的上下文。他们的洞察是：上下文折叠和高效注意力，其实是同一个问题的两面。Hermes 在应用层解决的是同一类问题，因此它对具体模型保持无关。

8 这些系统如何连接

Memory ↔ Skills。**硬边界，通过系统提示词强制执行：**事实去 memory，流程去 skills。一次用户纠正，可能同时写入两个地方：事实进 MEMORY.md，流程修补进 skill。

Skills ↔ Session Search。经验学习机制。agent 遇到任务 → 搜索过去的 session → 找到可行方法 → 结晶成 skill → 下次直接加载。情景式记忆是原始经验。程序式记忆是提炼后的专长。

Persona ↔ Honcho。SOUL.md 播下 AI peer 身份的种子。随着时间推移，这个表征会**从真实行为中演化，**形成声明性意图和观察到的现实之间的张力。

Compression ↔ Memory。压缩前的 flush 把压缩从纯损失变成一次巩固事件。压缩之后，系统提示词会用包含 flush 写入的新快照重新构建。前缀缓存的代价（1 到 2 轮）是真实存在的，但值得。

有限 store 强迫筛选。3575 字符的记忆预算不是妥协。它是一个设计选择，用来保证信号密度。

**被动记录，主动检索。**情景式 store 会捕获 agent 当下并不知道重要的东西。筛选发生在读的时候，而不是写的时候。

每一个持久化边界都有安全检查。每一次从临时上下文跨到持久存储，都会经过一个检查点。对提示词注入做纵深防御。

模型无关。记忆是纯文本。skills 是 markdown。session 是 SQLite。更换底层 LLM，不会丢失知识、技能或身份。

用户所有。SOUL.md 是一个你可以编辑的文本文件。skills 是你可以检查的目录。memory 以本地优先。所有东西都在 ~/.hermes/ 里。它不是一个云服务。它是你可以控制的基础设施。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】