深度拆解Hermes Agent，动态Prompt与Learning Loop架构的底层逻辑

在AI Agent领域，很多人对"智能"的理解还停留在"能对话、能执行简单指令"的层面，但真正能实现"长期陪伴、自我进化"的Agent却寥寥无几。Nous Research开源的Hermes Agent，正是打破这一局限的典型代表，它不是一个一次性的聊天工具，而是一个能"跟着用户一起成长"的自改进Agent运行环境。

不同于普通聊天助手只依赖当前对话上下文，Hermes Agent内置了完善的动态Prompt架构和Learning Loop（学习循环）机制，能从每一次任务中沉淀经验、积累技能，甚至形成对用户的跨会话理解。很多开发者在研究Hermes时，容易陷入"模型能力"的误区，却忽略了它最核心的竞争力：一套工程化的上下文管理与经验沉淀系统。

今天，我们就彻底拆解Hermes Agent的动态Prompt设计和Learning Loop架构，用通俗易懂的语言讲清它"自我进化"的底层逻辑，让大家明白：一个能长期可用的AI Agent，真正的核心不是模型有多强，而是如何让模型"记住该记的、学会该会的、做好该做的"。

先搞懂：Hermes Agent到底是什么？

在拆解核心架构前，我们先明确Hermes Agent的定位------它不是单一的聊天机器人，而是一个完整的Agent运行环境。很多人下载源码后会疑惑，为什么它包含了CLI交互界面、消息平台网关、工具系统、记忆系统等一系列组件，其实这正是它和普通聊天助手的本质区别：普通助手是"单一功能工具"，而Hermes是"能承载多种能力、实现长期进化的平台"。

从功能层面，Hermes Agent的核心能力可以分为8大类，其中最关键的是记忆系统（Persistent Memory）和技能系统（Skills System），这也是它动态Prompt和Learning Loop能落地的基础：

Tools & Toolsets（工具系统）：可根据使用平台灵活启用或禁用，比如文件读取、会话搜索、技能管理等工具，是Agent与外部交互的核心载体；
Skills System（技能系统）：不是简单的工具列表，而是可复用的工作流说明，比如GitHub PR流程、代码审查、文档处理等，能让Agent避免重复摸索；
Persistent Memory（持久记忆）：跨会话保存用户偏好、项目细节、环境约定等，让Agent每次对话都不用"从零开始"；
Context Files（项目上下文文件）：自动加载当前工作目录的项目规则，让Agent遵守项目约定，避免犯低级工程错误；
Messaging Gateway（消息网关）：支持将Agent接入Telegram、微信、Slack等多个消息平台，实现多终端同步使用；
Cron Scheduling（定时任务）：支持用自然语言创建定时任务，比如定时复盘经验、定时执行工具操作；
MCP Integration（外部扩展）：可连接外部MCP服务器，进一步扩展工具能力；
子Agent委派与多终端后端：支持将复杂任务委派给子Agent，同时适配不同终端的运行需求。

其中，记忆系统和技能系统是Hermes Agent"自我进化"的核心支撑，我们可以简单理解为：记忆系统是Agent的"笔记本"，记录长期事实和用户偏好；技能系统是Agent的"操作手册"，沉淀可复用的工作方法。而动态Prompt就是将这些"笔记本"和"操作手册"按需组装，让Agent在不同场景下拥有合适的"身份和能力"，Learning Loop则是负责不断更新"笔记本"和"操作手册"的后台机制。

这里有一个关键误区需要澄清：Hermes Agent的"自我进化"不是修改模型参数，也不是拥有了"自我意识"，而是通过工程化的方式，将对话中的有价值信息沉淀到记忆和技能中，再在后续会话中重新注入这些内容，让Agent的行为越来越贴合用户需求和项目场景。这就像我们人类，通过不断学习、总结经验，慢慢变得更擅长某件事，Hermes做的就是模拟这个"总结经验、复用经验"的过程。

核心拆解一：动态Prompt，不是静态文案，是"上下文操作系统"

很多人对System Prompt（系统提示词）的理解，还停留在"一句固定的角色设定"，比如"你是一个有帮助的AI助手"。但在Hermes Agent中，System Prompt完全不是这样------它不是一段写死的文本，而是在运行时动态组装的上下文结构，就像一个"上下文操作系统"，会根据用户、项目、平台、工具等不同场景，自动拼接不同的内容，形成适合当前会话的Agent身份。

在Hermes的源码中，System Prompt由AIAgent\.\_build\_system\_prompt\(\)方法负责组装，整个拼接过程有明确的顺序，每一层都对应Agent的一项核心能力，层层叠加后，形成一个完整的"Agent身份说明书"。接下来，我们逐一拆解这个动态Prompt的每一层结构，看看它到底是如何"动态变化"的。

第一层：SOUL.md，Agent的"人格说明书"，可配置、可演化

Hermes Agent的人格设定，不是写死在源码里的，而是来自一个用户可编辑的文件：\~/\.hermes/SOUL\.md。如果这个文件不存在，Agent才会回退到源码中的默认人格提示。这种设计，彻底打破了"Agent人格不可修改"的局限，也为Agent的长期演化留下了入口。

当前版本中，SOUL.md的核心思想非常接地气，完全区别于传统的"友好助手"提示词，它更像是在给Agent定"工作准则"，比如：

你不是一个普通聊天机器人，而是在形成一个持续存在的工作身份。你要真正帮上忙，而不是用客套话表现得很有帮助。你可以有判断、有偏好，也可以直接指出问题。在向用户提问前，先自己查文件、查上下文、查资料。用户给了你访问文件、消息和工具的权限，你要用能力赢得信任。涉及外部动作时要谨慎，涉及内部探索时要主动。私人内容必须保持私密。每次新会话开始时，你都要依靠这些文件和记忆恢复连续性。

这段话看似简单，却包含了Hermes Agent的核心人格逻辑：不敷衍、不盲从、主动探索、注重隐私、保持连续性。和传统Prompt中"你是一个有帮助、友好的AI助手"这种模糊的设定相比，SOUL.md的优势非常明显：

第一，用户可以直接修改SOUL.md，调整Agent的长期风格，比如让Agent更严谨、更简洁，或者更主动，不需要修改任何源码；第二，人格可以跨会话稳定存在，不会因为新的对话而丢失，比如Agent一直保持"主动查资料再回答"的习惯，不会因为换了一个话题就变得敷衍；第三，为Agent的演化留下了入口，未来如果用户希望Agent改变沟通方式、工作边界，只需要修改SOUL.md即可，无需重构整个系统。

这背后体现了一个重要的设计原则：Agent的人格不应该是"固化在代码里的摆设"，而应该是可配置、可迁移、可演化的，这样才能适应不同用户、不同场景的需求。

第二层：工具相关行为指南------按需注入，避免模型幻觉

很多Agent系统会在Prompt中写上"你可以使用浏览器搜索、可以写入记忆"等内容，但实际运行时，这些工具可能被用户禁用、缺少API密钥，或者在当前平台不支持。如果Prompt中一直提到这些不可用的工具，模型就很容易出现"幻觉调用"------明明工具不可用，却仍然尝试调用，导致任务失败。

Hermes Agent的做法非常稳健：工具存在，才注入对应的行为指南；工具不可用，就不提及相关内容，让Prompt和工具系统保持完全一致。这是一个非常细节但至关重要的工程设计，能有效避免模型幻觉，提升Agent的可靠性。

例如，如果memory工具可用，Prompt中就会注入"如何保存长期记忆"的规则；如果session_search工具可用，就会注入"如何回忆历史会话"的规则；如果skill_manage工具可用，就会注入"如何保存和更新技能"的规则。

在当前Hermes的Prompt中，由于memory、session_search、skill_manage这三个核心工具默认可用，所以会明确提示Agent：

你拥有跨会话的持久记忆。只保存未来仍然重要的稳定事实，比如用户偏好、环境细节、工具使用习惯和长期约定。不要把临时任务进度、一次性TODO或完成日志写入长期记忆。当用户提到过去对话，或者你怀疑历史会话里有相关信息时，先用session_search查找。完成复杂任务、修复棘手错误或发现可复用流程后，用skill_manage保存成技能。如果已有技能过时、不完整或错误，要主动修补它。

这段话不仅告诉Agent"可以用什么工具"，更明确了"什么时候用、怎么用"，相当于给Agent制定了一套"工具使用手册"。比如，它明确区分了"长期记忆"和"临时内容"，避免Agent把无关信息写入记忆；明确要求Agent在需要回忆历史时先搜索，避免凭记忆猜测；明确要求Agent在完成任务后沉淀技能，实现经验复用。

这种"工具与Prompt联动"的设计，让Agent的行为更可控、更可靠，也避免了很多不必要的错误。

第三层：Memory与User Profile，让Agent"记住你、记住事"

普通聊天助手的最大局限的是"记不住事"，每次对话都是全新的开始，用户需要反复解释自己的偏好、项目细节。而Hermes Agent通过动态注入Memory（记忆）和User Profile（用户画像），彻底解决了这个问题，它会把长期有价值的信息保存下来，在新会话开始时自动注入Prompt，让Agent每次对话都能"认出你、记得之前的事"。

Hermes的内置记忆由两个文件组成，分工非常清晰：

第一个是MEMORY\.md，相当于Agent的"个人笔记"，用来保存长期稳定的事实，比如用户偏好、环境细节、工具使用惯例、稳定约定、反复出现的问题，以及能减少未来重复解释的信息。比如，用户告诉Agent"我习惯用VS Code编辑代码"，这句话就会被写入MEMORY.md，后续Agent在推荐编辑工具时，就会优先推荐VS Code；再比如，Agent发现"每次调用某个工具都需要先激活虚拟环境"，这个经验也会被写入MEMORY.md，避免未来再犯同样的错误。

第二个是USER\.md，相当于Agent的"用户档案"，专门用来保存用户的身份信息和沟通偏好，比如用户的名字、所在时区、关心的项目、喜欢的沟通方式、不喜欢的行为。比如，用户说"我不喜欢太冗长的回复，尽量简洁"，这句话就会被写入USER.md，后续Agent的回复就会自动调整为简洁风格；再比如，用户告诉Agent"我所在的时区是东八区"，Agent就会根据这个信息调整定时任务的时间、回复的时间相关表述。

这里有一个非常关键的细节：不是所有内容都能写入Memory和User Profile。Hermes明确规定，以下内容不适合进入长期记忆：临时任务进度、已完成工作的流水账、一次性TODO、本轮会话中的短期状态。原因很简单，如果把这些无关内容都塞进去，Prompt会越来越冗长，不仅会增加模型的处理成本，还会让模型被无关信息干扰，影响回复质量。

更合理的分工是：长期偏好进入Memory，用户身份信息进入User Profile，历史对话细节通过session_search工具查询，可复用流程沉淀为Skill。这种清晰的信息管理策略，让Agent的"记忆"变得更高效、更纯净。

另外，Memory和User Profile并不是在同一会话的每一轮都实时重新注入。Hermes会在会话开始时，将这两个文件的内容作为"冻结快照"注入System Prompt，在同一会话内复用这个快照，不会每一轮都重新加载。这样做的目的是保护Prompt Cache（提示词缓存），避免因为每一轮Prompt变化而导致缓存失效，从而降低成本、减少延迟。

第四层：Skills------把经验沉淀成"可复用操作手册"

如果说Memory和User Profile解决了Agent"记住事、记住人"的问题，那么Skills系统就解决了Agent"学会方法、复用方法"的问题。Skills是Hermes Agent最核心的设计之一，它不是简单的工具列表，而是Agent可以按需加载的"可复用工作流"，相当于给Agent提供了一套"操作手册"，让Agent不需要每次都重新摸索解决问题的方法。

在Hermes的动态Prompt中，会自动注入当前可用的技能列表，比如GitHub工作流、系统化调试、测试驱动开发、MCP使用、macOS自动化、文档处理、YouTube内容提取、代码审查、多Agent协作等。这些技能的内容非常详细，不仅包含"什么时候用"，还包含"怎么用、注意什么"，比如一个"GitHub PR流程"技能，可能会包含：

什么时候应该使用这个技能：当需要提交代码到GitHub并创建PR时；使用前需要检查什么：代码是否通过测试、是否符合项目编码规范、是否有未解决的冲突；应该调用哪些命令：git add、git commit、git push、创建PR的命令；常见坑点是什么：忘记拉取最新代码导致冲突、提交信息不规范、未关联相关issue；用户偏好的做法是什么：提交信息需要包含issue编号、PR描述需要清晰说明修改内容；完成后如何验证：检查PR是否成功创建、是否通过CI测试、是否有代码审查意见。

Hermes的System Prompt会明确要求Agent：回复前先检查可用技能列表，只要某个技能和当前任务相关，哪怕只是部分相关，也应该先加载该技能，加载后按照技能中的步骤执行；如果技能内容有问题，要主动修补；如果本次任务形成了新的可复用经验，要考虑保存为新技能。

这个设计带来的实际好处非常明显：Agent不需要每次都重新摸索解决问题的方法。比如，用户让Agent帮忙做代码审查，而Hermes已经沉淀了"代码审查"技能，Agent就会直接加载这个技能，按照技能中规定的步骤检查代码，包括代码规范、逻辑漏洞、测试覆盖等，而不是从通用经验重新开始，大大提升了效率和准确性。

更重要的是，Skills不是静态的文档，而是可维护、可更新的。如果Agent在使用某个技能时，发现它已经过时、不完整或错误，就会主动修补这个技能；如果遇到了新的可复用方法，就会创建新的技能。这就让Agent的"能力"能够不断积累、不断优化，真正实现"自我进化"。

其他动态层：让Prompt适配不同场景

除了上述四层核心内容，Hermes的动态Prompt还包含多个辅助层，用来适配不同的模型、平台、环境和项目场景，确保Agent在任何情况下都能"找准自己的定位"：

Nous subscription相关提示：根据当前工具和订阅/环境状态按需加入，比如用户开通了特定订阅，就会注入相关的功能提示；
工具使用强制规则：根据模型、工具和配置按需加入，比如对GPT/Codex类模型，会注入更强的执行纪律，避免模型"只说不做"；
用户或gateway传入的system message：允许用户在会话开始时，临时注入自定义的系统提示，满足个性化需求；
外部memory provider的系统提示块：如果接入了外部记忆服务，就会注入相关的提示内容；
项目上下文文件：自动加载当前工作目录的项目规则，让Agent遵守项目约定；
会话开始时间、Session ID、模型和provider：让Agent知道当前的运行环境和会话信息；
特定provider的模型身份修正：比如接入Alibaba provider时，会注入相关的身份修正提示，确保模型行为符合平台要求；
环境提示：比如当前运行在WSL、Termux等环境中，会注入相关的环境适配提示；
平台特定提示：比如在CLI、Telegram、微信、Slack等不同平台运行时，会注入对应的平台交互提示。

除此之外，Hermes还有一类特殊的提示词------ephemeral_system_prompt（临时系统提示词）。它不会存入缓存的System Prompt，也不会写入SessionDB，而是在每次API调用时，临时拼到最终的System Prompt后面。这样做的好处是，既能临时影响模型的行为，又不会破坏稳定的缓存前缀，比如临时让Agent更注重细节、更简洁，任务完成后就恢复正常，不会影响后续会话。

总结来说，Hermes的动态Prompt不是一段简单的文本，而是由多个独立层组成的"上下文操作系统"。不同用户、不同项目、不同平台、不同模型、不同工具集，最终生成的System Prompt都可能不一样，但每一层都有明确的作用和来源，既保证了Agent的灵活性，又保证了行为的稳定性。

核心拆解二：Learning Loop，后台复盘，让Agent悄悄"成长"

如果说动态Prompt是Hermes Agent的"身份和能力基础"，那么Learning Loop（学习循环）就是它"自我进化"的核心动力。很多人误以为Hermes的"自我进化"是模型本身在学习，其实不然------它的学习过程，更像是一个后台复盘系统：当达到一定阈值时，Hermes会在主回复完成后，后台启动一个临时Agent，回顾刚才的对话，判断是否有内容值得保存到Memory，或者是否应该创建/更新Skill。

这个过程完全是异步的，不会阻塞主回复，也不会向用户发送无关的复盘信息，只会在成功创建或更新Memory、Skill时，显示一条简短的提示，比如"Memory已更新""新Skill已创建"。这种设计，既保证了用户体验，又实现了经验的沉淀，让Agent在"不打扰用户"的情况下悄悄成长。

在Hermes的源码中，这个机制被称为"Background memory/skill review"（后台记忆/技能复盘），它包含三类复盘Prompt，分别对应不同的复盘场景，我们逐一拆解。

6.1 Memory Review Prompt，筛选有价值的"长期事实"

Memory Review（记忆复盘）的核心目的，是从对话中筛选出值得长期保存的事实信息，避免Memory被无关内容污染。当触发Memory复盘时，后台临时Agent会收到这样的指令：

回顾上面的对话，判断是否有适合保存到长期记忆中的内容。重点关注两类信息：第一，用户是否透露了关于自己的稳定信息，比如性格、愿望、偏好或值得以后记住的个人细节。第二，用户是否表达了对你行为方式的期待，比如希望你如何工作、如何沟通、采用什么工作风格。如果发现有价值的信息，就使用memory工具保存。如果没有值得保存的内容，就回答"Nothing to save."并停止。

这段话的核心是"筛选"，而不是"总结"。它不要求Agent总结整个对话的内容，只要求Agent找出"长期有价值"的信息，比如用户说"我以后希望你优先使用Python编写脚本"，这句话就是用户的稳定偏好，会被保存到Memory；再比如用户说"你之前的回复太冗长了，以后尽量简洁"，这句话是用户对Agent行为方式的期待，也会被保存到Memory。

而像"我现在要修改这个文件""这个任务已经完成了"这类临时内容，不会被保存到Memory，因为它们没有长期复用价值。如果没有找到有价值的信息，后台Agent就会回复"Nothing to save."，然后停止复盘，不会做多余的操作。

这种"有价值才保存"的筛选机制，是Hermes Memory系统高效、纯净的关键。一个好的记忆系统，不是"什么都记"，而是"记该记的"，这样才能避免Memory越来越臃肿，也能让Agent在后续会话中快速获取有价值的信息。

6.2 Skill Review Prompt，沉淀可复用的"工作方法"

Skill Review（技能复盘）的核心目的，是从任务中沉淀可复用的工作方法，让Agent下次遇到类似任务时，能够直接复用经验，不需要重新摸索。当触发Skill复盘时，后台临时Agent会收到这样的指令：

回顾上面的对话，判断是否应该保存一个新技能，或者更新已有技能。重点关注：这次任务是否使用了非平凡的方法？是否经历了试错？是否因为过程中发现的新情况而改变策略？用户是否期待另一种方法或结果？如果已经存在相关技能，就把这次学到的内容更新进去。如果没有相关技能，但这个方法未来可以复用，就创建一个新技能。如果没有值得保存的内容，就回答"Nothing to save."并停止。

这里的关键是"非平凡的方法"------也就是说，普通的、通用的方法不需要保存，只有那些经过试错、有特殊技巧、可复用性强的方法，才值得沉淀为Skill。比如，用户让Agent调试一个Python脚本，Agent经过多次试错，发现是"虚拟环境未激活导致的模块导入错误"，并且总结出了"先激活虚拟环境、再检查模块安装情况、最后运行脚本"的调试流程，这个流程就属于"非平凡的方法"，会被保存为新的Skill；再比如，Agent发现之前的"GitHub PR流程"技能中，缺少了"关联issue"的步骤，就会把这个步骤更新到已有技能中。

Skill Review关注的不是"用户是谁"，而是"解决问题的方法是什么"，它让Agent的"能力"能够不断积累，比如从不会调试某个服务，到慢慢掌握该服务的调试流程；从不会使用某个工具，到慢慢沉淀出该工具的使用技巧。这种过程性的学习，正是Hermes Agent"自我进化"的核心体现。

6.3 Combined Review Prompt------同时复盘记忆和技能

有些对话中，既包含用户的偏好信息，又包含可复用的工作方法，这时Hermes会触发Combined Review（联合复盘），让后台临时Agent同时检查Memory和Skill，避免遗漏有价值的信息。联合复盘的指令如下：

回顾上面的对话，同时考虑两件事。第一，是否有值得保存到memory的信息：用户是否透露了关于自己的稳定信息？用户是否表达了对你行为方式、工作风格或沟通方式的期待？如果有，就使用memory工具保存。第二，是否有值得保存为skill的方法：本次任务是否使用了非平凡方法？是否经历了试错？是否根据实践发现改变了方向？用户是否期待不同的方法或结果？如果已有相关技能，就更新它。如果没有相关技能，但方法可复用，就创建一个新技能。只有在确实有内容值得保存时才行动。如果没有明显值得保存的内容，就回答"Nothing to save."并停止。

联合复盘的核心是"兼顾"，既不遗漏用户的偏好信息，也不遗漏可复用的工作方法。比如，用户在让Agent处理文档的过程中，既说"我喜欢用Markdown格式的文档"（用户偏好，需保存到Memory），又展示了"如何快速批量转换文档格式"的方法（可复用方法，需保存为Skill），这时后台Agent就会同时处理这两件事，既更新Memory，又创建新Skill。

无论哪种复盘方式，都有一个共同的约束：只有在确实有内容值得保存时才行动，没有价值就停止。这个约束非常重要，它避免了Hermes无脑记录，防止Memory和Skill被无关内容污染，保证了经验沉淀的质量。

关键补充：Learning Loop的触发机制与异步设计

Hermes的Learning Loop不是随时都在运行，而是有明确的触发条件和阈值，并且采用异步后台运行的方式，避免干扰用户的正常使用。我们从触发方式、运行机制两个方面，补充拆解它的设计细节。

7.1 触发方式：达到阈值才启动，避免频繁复盘

Hermes的Learning Loop有明确的触发阈值，默认情况下：

Memory Review（记忆复盘）：每10个用户turn（用户发言次数）触发一次。触发时需要同时满足三个条件：memory.nudge_interval > 0（开启记忆复盘）、当前工具集中包含memory工具、内置memory store已启用并加载。

Skill Review（技能复盘）：每10次工具调用迭代后触发一次。触发时需要同时满足三个条件：skills.creation_nudge_interval > 0（开启技能复盘）、当前工具集中包含skill_manage工具、工具调用迭代计数达到阈值。

这样的设计，避免了每次对话都进行复盘，减少了系统资源消耗，同时也保证了复盘的质量，经过10次用户发言或10次工具调用，往往已经积累了一定的经验和信息，此时复盘更有价值。用户也可以根据自己的需求，修改配置文件中的阈值，比如把Memory Review的阈值改为5次，让Agent更频繁地保存用户偏好。

7.2 运行机制：异步后台执行，不干扰主任务

Hermes的Learning Loop最核心的设计之一，就是"异步后台执行"。它的运行流程大致如下：

主Agent完成用户当前的任务，向用户发送回复；
检查是否达到复盘阈值，如果达到，后台fork一个临时Agent；
临时Agent执行复盘任务，判断是否有内容值得保存到Memory或Skill；
如果有，临时Agent使用memory或skill_manage工具，将内容写入对应的文件（MEMORY.md、USER.md或技能文件）；
复盘完成后，临时Agent自动停止，不向用户发送任何多余回复（除非成功保存了内容，会显示一条简短提示）；
主Agent继续等待用户的下一条指令，不被复盘过程干扰。

同时，后台复盘Agent还有一个限制：最多运行8次迭代，避免因为复盘任务过于复杂而占用过多系统资源。这种"主任务与复盘任务分离"的设计，非常符合真实的产品体验------用户要的是任务结果，而不是看Agent"自我反思"，后台异步复盘既保证了经验沉淀，又不会干扰用户的正常使用。

举个例子：用户让Agent帮忙调试一个代码bug，主Agent很快找到bug并给出修复方案，用户确认问题解决后，主Agent的任务就完成了。此时，如果达到了Skill Review的阈值，后台就会启动临时Agent，回顾整个调试过程，判断是否有可复用的调试方法，如果有，就创建一个新的Skill，这个过程完全不会影响用户，用户甚至不知道后台正在进行复盘，只有当Skill创建成功时，才会看到一条"新Skill已创建"的简短提示。

7.3 Pre-reset Flush：会话清空前的"最后一次整理"

除了周期性的Learning Loop，Hermes还有一个特殊的复盘机制，Pre-reset Flush（重置前刷新），用来解决"会话上下文丢失导致经验遗漏"的问题。

在网关场景下，用户可能在Telegram、微信、Slack等平台进行长时间对话，而这些平台的会话可能会因为长时间不活跃、每日重置等原因被清空，会话上下文一旦清空，里面的有价值信息（比如用户新的偏好、新的工作方法）就可能被遗漏，无法沉淀到Memory或Skill中。

Pre-reset Flush机制就是为了解决这个问题：当会话即将因为空闲或每日重置而清空时，Hermes会触发一次复盘，让临时Agent执行"临终整理"，指令如下：

当前会话即将因为长时间不活跃或定时重置而自动清空。这一轮之后，对话上下文会被清除。请回顾上面的对话，并完成以下检查：1. 如果其中有未来会话仍然有用的重要事实、用户偏好或决定，请保存到memory或user profile。2. 如果你发现了可复用工作流，或者解决了一个非平凡问题，请考虑保存为skill。3. 如果没有值得保存的内容，可以直接跳过。不要回复用户。只在需要时使用memory和skill_manage工具，然后停止。

这次复盘的核心是"查漏补缺"，在上下文丢失前，最后检查一次是否有遗漏的有价值信息。同时，为了避免旧会话的信息覆盖新的记忆，临时Agent会先读取当前的live memory状态（也就是最新的MEMORY.md和USER.md），并被明确要求：不要覆盖或删除已有记忆，除非当前对话确实证明旧内容已经被取代；只添加尚未被记录的新信息。

比如，用户在会话即将清空时，提到"我以后希望你用中文编写注释"，这句话是新的用户偏好，Pre-reset Flush机制就会让临时Agent将这句话保存到Memory中，避免因为会话清空而丢失。这种设计，进一步增强了Hermes的长期连续性，也降低了多会话、定时任务或用户手动更新记忆后，被旧上下文覆盖的风险。

补充拆解：Project Context与工具执行纪律

除了动态Prompt和Learning Loop，Hermes Agent还有两个关键设计，分别是Project Context（项目上下文）和工具执行纪律，它们虽然不是核心架构的一部分，但却是动态Prompt能落地、Learning Loop能有效沉淀经验的重要保障，我们简单拆解一下。

8.1 Project Context：让Agent"遵守项目规则"

对于coding Agent来说，最容易犯的低级错误就是"不遵守项目约定"，比如忘记激活虚拟环境、跑错测试命令、硬编码用户目录、忽略项目已有架构等。Hermes通过自动加载Project Context（项目上下文），彻底解决了这个问题，它会根据当前工作目录，自动加载项目的规则文件，让Agent在进入项目时，先"阅读项目手册"，再开展工作。

Hermes加载项目上下文文件的优先级如下（first found wins，只加载第一个命中的文件，不叠加）：

\.hermes\.md / HERMES\.md：从当前目录向上查找到git root（项目根目录）；
AGENTS\.md / agents\.md：只查找当前工作目录；
CLAUDE\.md / claude\.md：只查找当前工作目录；
\.cursorrules / \.cursor/rules/\*\.mdc：只查找当前工作目录。

这些项目上下文文件，会告诉Agent项目的核心规则，比如项目结构是什么、运行Python前必须激活哪个虚拟环境、如何新增工具、如何新增slash command、如何处理profile-safe路径、不要硬编码\~/\.hermes目录、测试应该怎么跑、已知的坑点是什么等。

比如，某个项目的AGENTS\.md文件中写着"运行Python脚本前，必须先激活venv虚拟环境，命令为source venv/bin/activate"，那么Hermes Agent进入这个项目后，就会自动加载这条规则，在运行Python脚本时，先执行激活虚拟环境的命令，避免出现模块导入错误。

这种设计，让Agent能够快速适配不同的项目场景，减少低级错误，也让Learning Loop沉淀的技能更贴合项目实际，提高技能的复用价值。

8.2 工具执行纪律：防止Agent"只说不做"

很多AI Agent的通病是"只说不做"，比如承诺"我会检查这个文件"，但实际上并没有调用文件读取工具；或者"我会调试这个bug"，但并没有调用相关工具查找问题原因。这种"言行不一"的行为，会严重影响Agent的可靠性，尤其是在coding、文档处理等需要实际操作的场景中。

Hermes Agent通过在动态Prompt中注入"工具执行纪律"，彻底解决了这个问题。核心思想很简单：如果你说要做，就必须立刻调用工具做；只要工具能提高正确性、完整性或依据性，就必须使用工具。

对于GPT/Codex类模型，Hermes会注入更强的执行纪律，明确要求：

只要工具能提高正确性、完整性或依据性，就使用工具。如果进一步调用工具能改善结果，不要过早停止。如果工具返回空结果或部分结果，先换查询方式或策略重试。算术、哈希、当前时间、系统状态、文件内容、git diff等都必须通过工具确认。缺少上下文时，优先用工具查找，不要猜测。最终回复前检查结果是否满足要求、是否有依据、格式是否正确、是否存在副作用风险。

这些纪律不是在教模型"更聪明"，而是在约束模型"更像工程师"，工程师在解决问题时，会主动查文件、看日志、跑测试，而不是凭猜测下结论；会反复验证结果，而不是敷衍了事。Hermes的工具执行纪律，就是让Agent模拟这种严谨的工作态度，确保每一个操作都有依据、每一个结论都可靠。

关键细节：为什么System Prompt需要缓存？

前面我们提到，Hermes的动态Prompt是在会话开始时动态生成的，生成后在同一会话内保持稳定，不会每一轮都重新生成。很多人会疑惑，既然是"动态Prompt"，为什么不每一轮都重新组装，反而要缓存起来？其实，这是一个非常重要的工程取舍，核心目的是保护Prompt Cache，降低成本、减少延迟。

如果System Prompt每一轮都变化，比如当前时间每轮更新、Memory每轮重新读取、Skills列表顺序变化、项目上下文重新扫描，那么模型的前缀缓存就会失效。前缀缓存是大语言模型的重要优化手段，它能缓存Prompt的前缀部分，当Prompt重复时，模型不需要重新处理，直接复用缓存结果，从而降低计算成本、减少响应延迟。

如果Prompt每一轮都变化，前缀缓存就失去了意义，会导致两个严重问题：一是成本上升，每一轮都需要重新处理完整的Prompt，计算量大幅增加；二是延迟增加，用户需要等待更长时间才能收到回复。

因此，Hermes采取了"新会话动态生成，同一会话稳定复用"的策略：

新会话：构建一次System Prompt，保存到SessionDB中；
同一会话：复用已保存的System Prompt，不重新生成；
继续旧会话：优先从SessionDB读取旧的System Prompt；
特殊情况：只有在上下文压缩、配置变更等特殊情况下，才重新构建System Prompt；
临时提示：ephemeral_system_prompt只在API调用时临时拼接，不写入缓存快照，避免影响缓存。

这种策略，既保证了不同会话的Prompt能够动态适配场景，又保证了单个会话内Prompt Cache的稳定，实现了"灵活性"和"高效性"的平衡。这也提醒我们，在设计Agent的Prompt架构时，缓存不是"优化细节"，而是架构的一部分，必须提前考虑，否则会导致成本和延迟失控。

架构启示：构建长期可用Agent的7个关键原则

拆解完Hermes Agent的动态Prompt和Learning Loop架构，我们不难发现，它的核心竞争力不是模型能力，而是一套工程化的上下文管理和经验沉淀系统。这套设计，给我们构建长期可用的AI Agent提供了7个非常有价值的启示，值得每一个开发者借鉴。

1. System Prompt要分层，不要堆成一整段

Hermes的动态Prompt之所以灵活、可维护，核心是采用了分层设计------人格、工具规则、记忆、技能、项目上下文、平台提示、模型约束，每一层都是独立的，有明确的作用和来源。这种设计，比把所有内容堆成一整段Prompt更易维护、易调试、易扩展。比如，要修改Agent的人格，只需要修改SOUL.md；要调整工具规则，只需要修改工具相关的提示层，不会影响其他部分。

2. 动态内容要有清晰来源

Hermes的动态Prompt中，每一部分内容都有明确的来源：SOUL.md来自用户可编辑文件，Memory来自持久记忆文件，Skills来自技能索引，Project Context来自当前项目文件，Model/Provider来自运行时配置。这种"来源清晰"的设计，不仅让Agent的行为更可解释（用户能知道Agent为什么会这样做），也让调试变得更简单------如果Agent出现异常行为，能快速定位到是哪一层内容出了问题。

3. Prompt要和工具系统联动

不要在Prompt中要求模型调用不存在的工具，这是很多Agent系统的常见错误。Hermes的做法是"工具存在，才注入对应规则"，让Prompt和工具系统保持一致，有效避免模型幻觉。同时，Prompt中不仅要告诉模型"可以用什么工具"，还要明确"什么时候用、怎么用"，给模型制定清晰的工具使用规则。

4. 长期记忆要克制，做好信息分工

长期记忆不是"什么都记"，而是要做好信息分工，避免记忆污染。Hermes的分工值得借鉴：长期偏好进Memory，用户画像进User Profile，可复用流程进Skill，历史细节进session_search，临时状态不保存。这样的分工，让每一种信息都有合适的存储载体，既保证了记忆的高效性，又避免了无关信息干扰模型。

5. 自我进化要落到外部状态上

Hermes的"自我进化"没有依赖模型参数更新，而是落到了外部状态的维护上------Memory、User Profile、Skills、Project Context、SessionDB。这种方式，比修改模型参数更可控、更可解释、更易调试，也更适合自托管Agent场景。对于大多数开发者来说，与其追求"模型层面的自我进化"，不如先做好外部知识结构的维护，让Agent通过复用经验实现"进化"。

6. Learning Loop要后台运行，解耦体验和学习

用户使用Agent的核心需求是"完成任务"，而不是"看Agent自我反思"。Hermes将Learning Loop设计为后台异步运行，既保证了经验沉淀，又不干扰用户的正常使用，这种"体验与学习解耦"的设计，非常符合真实的产品需求。在设计Agent时，一定要避免让学习过程阻塞主任务，否则会严重影响用户体验。

7. 缓存是Agent架构的一部分，不是优化细节

当System Prompt包含动态内容时，缓存就成了影响成本和延迟的关键因素。Hermes"新会话动态生成，同一会话稳定复用"的策略，为我们提供了很好的参考------既要保证不同会话的灵活性，又要保证单个会话的高效性。在设计Agent架构时，一定要提前考虑Prompt的缓存策略，否则会导致成本和延迟失控。

总结：Hermes Agent的核心价值的是什么？

拆解完Hermes Agent的动态Prompt和Learning Loop架构，我们可以清晰地看到：它的核心价值，不是"更聪明的模型"，而是"更合理的上下文管理和经验沉淀系统"。

Hermes的System Prompt不是一句简单的角色设定，而是一个动态组装的上下文架构，它让Agent在不同场景下都能拥有合适的身份和能力；它的Learning Loop不是神秘的自我意识，而是一个工程化的后台复盘系统，它让Agent能从每一次任务中沉淀经验、积累技能；它的记忆系统、技能系统、项目上下文系统，共同构成了一个"可长期进化、可适配场景、可信赖"的Agent运行环境。

对于开发者来说，Hermes Agent的设计思路，给我们提供了一个重要的启示：构建一个长期可用的AI Agent，问题不只是"Prompt怎么写"，而是"哪些信息应该长期保存、哪些经验应该沉淀成技能、哪些上下文应该自动加载、哪些规则应该动态注入、什么时候该学习、什么时候该缓存"。

真正优秀的AI Agent，不是"一次性的工具"，而是"能跟着用户一起成长的伙伴"。Hermes Agent用一套工程化的设计，实现了这一点------它不会改变模型本身，但会改变模型每次运行时看到的上下文，而对Agent来说，上下文就是能力的一部分。