Hermes Agent 原理拆解：一个能把经验带到下一次任务的 Agent，究竟怎样工作？

让 Agent 修一次 Bug，和让它长期参与一个项目，是两种不同的工程问题。前者只要能调用模型、读取代码、运行测试；后者还要回答：它下周是否知道项目约定？上次有效的排查步骤放在哪里？换成定时触发或消息触发时，会话怎样接续？高风险动作由谁把关？

Nous Research 的 Hermes Agent 值得看的地方正在这里。它是一个开源 Agent 运行系统，可以连接模型、工具、终端、消息入口和定时任务，并把跨会话有价值的事实与操作方法保存下来。它不是一个叫 Hermes 的新模型，也不是在每次完成任务后自动训练模型参数。 项目所说的“成长”，主要发生在记忆、技能与会话管理这些模型之外的层面。项目仓库

下面先拆原理，再用一个持续排查 CI 构建失败的例子，把这些组件串起来。

先看完整链路：一次任务会经过哪些组件？

Hermes 的核心仍是 Agent 循环。用户或调度器送来任务后，系统读取会话状态，组装提示词，调用当前配置的模型。模型如果请求工具，系统执行相应工具，把结果写回会话，再让模型继续判断；模型给出最终文本后，系统保存会话并交付结果。官方开发文档把提示词组装、提供商适配、工具执行、上下文压缩与会话持久化都归在这一运行链路里。Agent Loop Internals

以图中的 CI 失败为线索看，任务先从消息或定时入口进入；Agent 读取当前项目规则、必要的记忆与技能，再通过模型决定是否查看日志、搜索代码或运行测试。工具结果回到当前会话，直至产生可检查的排查结论。任务结束后，完整过程留在会话记录中；稳定事实和可复用步骤才分别进入记忆与技能。下一次失败到来时，系统可以按需取回它们。这两圈分别是一次任务内的执行循环和跨任务的经验循环，不能混为“模型自己变强”。

为了看清技术分工，可以把系统拆为五部分：

这是一种架构上的分工，不表示每次任务都必须使用所有组件。简单提问可以很快结束；只有涉及真实动作时才需要相应工具；只有值得复用的经验才应该长期保留。

执行循环：模型“决定”，系统“执行”

很多介绍把 Agent 简化成“模型调用工具，直到回答完成”。这个概括没错，但实现时还有几个容易忽略的边界。

首先，模型看到的是系统组装后的输入：当前问题、会话内容、项目上下文、记忆快照、可用技能的索引以及工具定义。它并不天然知道某个仓库在哪里，也不会因为上次聊过就一定记住。相关信息需要被正确保存并在本次运行中重新提供。

其次，模型给出的工具调用只是请求。Hermes 的运行层解析调用、查找工具处理器、执行并返回结果；工具失败也会成为结果，让模型继续判断。官方的工具运行文档说明了注册、分发、异常包装及调用前后钩子的职责。这意味着“模型说已经修好了”与“测试真的通过了”是两回事，后者要有工具输出作为证据。Tools Runtime

最后，任务需要停止条件。若测试持续失败，系统应保留错误输出并报告阻碍，而不能把无限重试当成自主能力。对于开发任务，比较可靠的完成信号通常是预先定义的验收条件、测试结果和可审查的代码差异，而不是一段自信的总结。

跨会话经验：记忆、技能、历史为什么要分开？

Hermes 的长期信息不是一个无限增长的“万能记忆库”。官方的内置设计区分了三种载体：

• 记忆保存需要经常带入新会话的简短事实。内置的 MEMORY.md 偏向环境与项目事实，USER.md 偏向用户习惯。它们有容量限制，在新会话开始时被读入提示词。
• 技能保存“怎样做”的步骤、约束和易错点。Skill 是按需读取的文档：系统先提供简短索引，任务相关时再加载完整内容。
• 会话历史保存“那次到底发生了什么”：消息、工具调用、错误和结果可以在需要时检索，不必把每一条日志塞进常驻记忆。

例如“这个仓库的构建命令是 mvn verify”适合记忆；“排查 CI 失败时先比对工作流环境，再运行相关测试，最后检查差异”的方法适合技能；某一次失败的堆栈、尝试过的修复与测试输出则属于会话历史。把所有内容都写进记忆，会造成空间挤占和过期信息；只保存会话而不提炼方法，下次又要从头阅读大量记录。Persistent Memory、Skills System

这里还有一个很实际的细节：内置记忆在会话开始时作为快照进入提示词。当前会话中新写入的事实会立即落盘，但不会自动改写已经组装好的提示词；新的会话才会拿到更新后的快照。会话内仍可通过工具返回看到写入结果。理解这一点，才能解释“明明刚让它记住了，为什么当前对话没有像重新启动后那样使用它”。

“自我改进”到底发生在哪一步？

Hermes 可以在工作中通过工具写入记忆，或把非平凡、可能重复的流程整理成 Skill；官方文档还描述了运行后的后台复盘与 Skill 维护机制。这个过程的合理目标不是把每次操作都存起来，而是筛选稳定、可复用、能被验证的经验。用户也可以配置技能写入审批，先看变更再决定是否采用。Skills System

因此，自我改进至少要经过三个判断：

所谓“成长”更接近一个可维护的工程知识循环：执行任务 → 留下证据 → 提炼经验 → 下次按需取用 → 用新证据修订旧经验。它不会保证 Agent 从此不犯错，也不是模型权重的在线训练。

一个完整例子：持续排查 CI 构建失败

假设维护者让 Hermes 每天检查某个开源仓库的 CI，并在失败时分析原因、给出可核验的处理建议。下面是架构示例，不是声称已经对某个真实仓库运行过。

第一次失败：建立证据。 定时任务触发后，Agent 查看失败的工作流与日志。它发现单元测试正常，但集成测试在一个时区相关断言处失败。此时正确的动作是读取测试代码、工作流环境及相关依赖配置，比较本地与 CI 的时区设置；不能只凭错误行就断言是时区造成的。若需要修改代码，应在受控工作区中运行针对性测试，并交付差异与结果。

任务结束：决定留下什么。 如果核查确认仓库的集成测试必须显式设置 UTC，那么这条稳定约定可以进入项目记忆。“排查时先区分单元测试与集成测试，再检查运行环境、复现失败、验证修复”的步骤，可以整理成 CI 排障技能。当天的原始日志、失败尝试和最终结果留在会话记录里。

第二次失败：复用但不照搬。 几天后 CI 又失败，Agent 可以加载之前的排障技能，先做环境与测试分类；如果错误发生在依赖下载阶段，旧的时区结论就不适用。技能提供的是调查顺序，当前日志和测试结果才决定当前结论。若旧步骤遗漏了依赖缓存检查，可在证据充分后修订技能。

向维护者交付：保留边界。 Gateway 或定时任务负责把结果送到指定入口。报告应说明失败位置、支持结论的日志、做过的验证、尚未确认的因素以及建议动作。若任务涉及改动仓库、运行高风险命令或对外发布，审批和权限边界必须由运行环境配置，不应只靠提示词中的一句“请小心”。Hermes 官方安全文档列出了用户授权、危险命令审批、文件写入限制与隔离等机制。Security

这个例子说明，Hermes 的价值并不是“第二次自动知道答案”，而是第二次能更快找到该查什么、在哪里查、怎样验证。如果第一次保存的是错误结论，系统也可能更快地重复错误；因此经验的质量比经验的数量重要。

对开发者的启发：重点设计经验的边界

把 Hermes Agent 当作工程系统看，会比只看“能接多少工具”更有收获。实际设计时可以依次问：

• 当前任务的完成证据是什么？是否有测试、日志、差异或其他可检查结果？
• 哪些信息值得每次带入，哪些只应按需查询，哪些仅留作历史记录？
• 一个 Skill 的适用前提是什么？项目变化后谁来修订它？
• 定时或消息触发的任务，以什么身份运行，能访问哪些工具和数据？
• 危险动作如何审批；无人值守时若不能获批，任务怎样安全停止并报告？

Hermes 的思想不是发明了另一种 Agent 循环，而是让一次任务的经验有地方落脚，让后续任务能够受控地复用它。 真正可持续的 Agent，不只会执行，还要能说明依据、保存正确经验，并在条件改变时停止沿用旧方法。

参考资料

• Nous Research：Hermes Agent 项目仓库
• Hermes Agent：架构与 Agent 循环
• Hermes Agent：持久记忆
• Hermes Agent：技能系统
• Hermes Agent：安全机制