摘要

过去两年，我用过不少 Agent 框架。

有的擅长编排工作流，有的擅长多智能体协作，有的把工具调用封装得非常漂亮。但真正放到长期运行的业务场景中，问题很快就会暴露出来：

• 换一次会话，之前教过的东西又忘了；

• 对话一长，上下文开始混乱；

• 同一种任务做了十次，第十一次仍然要重新摸索；

• 工具调用失败后，不知道从哪里恢复；

• 所谓“反思”，往往只是让模型再说一遍自己的错误。

Hermes Agent 值得研究的地方，并不是它又发明了一套 Agent 术语，而是它试图解决一个更底层的问题：

如何把一个依赖 Prompt 驱动的大模型，改造成一个能够长期运行、持续积累经验、按需调用能力并安全执行任务的软件系统？

本文将从 Hermes 的整体架构、Agent Loop、分层记忆、Skill 系统、上下文管理、自我改进和安全边界几个方面，拆解它真正有价值的工程思想。

关键词： Hermes Agent、AI Agent、智能体架构、长期记忆、Skill、上下文工程、自我进化

---

一、为什么很多 Agent 看起来聪明，用久了却没有变强？

很多 Agent 项目第一次演示时都很惊艳。

用户提出任务，模型自动拆解步骤、调用搜索工具、执行代码、读取文件，最后生成一份结果。整个过程看起来像一个真正的数字员工。

但连续使用一段时间后，会发现它并没有真正积累能力。

你昨天刚告诉它公司的文件命名规范，今天又要重新解释；上一次调用内部接口踩过的坑，下一次仍然会踩；同一种任务执行了很多遍，它依旧每次从零规划。

这说明它只是完成了一次推理，并没有形成经验。

传统 Agent 通常存在三个问题。

第一，状态没有被系统化保存。

很多系统所谓的记忆，只是把聊天记录重新塞回上下文。一旦对话被截断、服务重启或者换一个会话，之前的信息就很难继续发挥作用。

第二，知识和流程没有分开。

“用户喜欢中文报告”和“如何生成一份面料开发报告”，显然不是同一种信息。

前者是偏好，后者是操作流程。如果全部存进向量数据库，再依靠相似度召回，系统用得越久，信噪比反而越低。

第三，执行结果没有形成可复用资产。

Agent 调用十几个工具完成了一次复杂任务，但任务结束后，执行路径也随对话一起消失。下一次遇到类似任务，模型还得重新规划、重新试错。

Hermes Agent 的核心价值，正是在尝试解决这三个问题。

---

二、理解 Hermes，可以先看“三层骨架”

从能力角度，可以把 Hermes 理解为三层。

1. 感知层：理解当前发生了什么

感知层负责接收用户消息、项目上下文、历史会话和外部工具返回的数据。

它需要判断：

• 用户真正想完成什么；

• 当前处于哪个会话；

• 是否存在可复用的历史信息；

• 当前输入属于新任务，还是已有任务的延续；

• 是否需要加载某个 Skill。

这一层解决的是“看懂当前世界”的问题。

2. 决策层：决定下一步做什么

决策层负责模型推理、工具选择、任务拆解、记忆调用和路径调整。

传统 Agent 常见的做法，是让模型一次性生成一个步骤列表，然后按照列表执行。

Hermes 更接近持续循环：

观察当前状态
→ 选择下一步动作
→ 执行动作
→ 获取结果
→ 根据结果继续决策

计划不是一次性生成后就不能修改的文档，而是随着执行结果不断变化的临时结构。

3. 执行层：真正对外部世界产生影响

执行层负责调用终端、浏览器、文件系统、API、MCP 服务和远程执行环境。

大模型本身不能真正修改文件，也不能访问数据库。

它只能提出一个工具调用请求。真正的动作必须交给受控的执行环境完成。

因此，一个生产级 Agent 必须把“模型建议”和“系统执行”分开。

LLM：建议做什么
Policy：判断能不能做
Runtime：真正执行
Audit：记录做了什么

三层结构适合帮助我们理解 Hermes，但它并不是官方代码的直接模块划分。要看懂 Hermes 的底层实现，还需要继续深入它的运行时架构。

---

三、Hermes 的底层架构，到底是怎么运转的？

从官方架构看，Hermes 更像一套完整的 Agent Runtime，而不只是对 LLM API 的简单封装。

可以把它简化成下面这条链路：

CLI / Desktop / Gateway / API
              ↓
        Agent Runtime
              ↓
Prompt Builder + Provider Resolver
              ↓
          LLM 推理
              ↓
        Tool Dispatcher
              ↓
Terminal / Browser / MCP / Files / API
              ↓
        Session Storage

1. 多入口层

Hermes 可以通过命令行、桌面端、API、批处理程序和消息网关接收任务。

入口层并不负责具体推理，而是把不同来源的消息转换成统一的内部格式。

这样做的好处是，核心 Agent 不需要关心任务来自 Telegram、Discord、桌面端还是终端。

官方 Gateway 使用统一的会话键保存不同平台、聊天类型和会话对象之间的路由关系。消息进入网关后，会先完成事件标准化、会话定位、权限检查和消息分发，再进入 Agent Runtime。

2. Prompt Builder

Prompt Builder 是 Hermes 中非常关键、但容易被忽略的模块。

大多数人理解 Prompt，只会想到一段 system prompt。实际上，长期运行的 Agent 需要处理多种不同生命周期的信息：

• 稳定的身份和行为规则；

• 项目级上下文；

• 用户画像；

• 长期记忆；

• Skill 索引；

• 当前会话信息；

• 本轮临时指令。

Hermes 会把这些内容分层组装，而不是简单拼接到一起。

官方设计大致分成三类：

稳定层：
身份、工具说明、模型说明、Skill 索引

上下文层：
项目规则、仓库规范、调用方提供的系统信息

易变层：
MEMORY.md、USER.md、时间、会话和模型信息

此外，一些只对当前调用有效的信息，不会写进缓存的系统提示词，而是在请求 LLM 时临时注入。

这个设计背后的重点不是“Prompt 写得多复杂”，而是保持稳定前缀，减少重复计算，并避免临时信息污染长期上下文。

3. Provider Resolver

Hermes 并不绑定某一种模型接口。

它会根据 Provider、API 模式和地址配置，选择不同的调用方式，再统一转换成内部消息格式。

无论底层使用 OpenAI 兼容接口、Responses API 还是 Anthropic Messages API，最终都会进入统一的 Agent Loop。

这意味着模型是可替换的推理组件，而不是整个系统本身。

4. Tool Dispatcher

模型返回工具调用后，Tool Dispatcher 负责找到对应工具并执行。

这里通常需要处理：

• 参数解析；

• 权限判断；

• 超时控制；

• 异常捕获；

• 执行结果标准化；

• 工具结果回填；

• 日志和审计。

真正决定 Agent 稳定性的，往往不是模型能不能生成正确的工具名，而是工具执行失败后，系统能否给出足够明确的错误信息，让模型进行下一步处理。

5. Session Storage

Hermes 会持久化会话、消息和执行上下文。

这意味着一次任务不再只是内存中的临时对话，而可以在后续被搜索、恢复和引用。

这也是 Agent 从“聊天程序”走向“长期运行系统”的基础。

---

四、Hermes 最值得学习的，是它对记忆的分层

很多 Agent 框架说自己有记忆，实际实现只有两种：

一种是把所有历史消息继续塞进 Context。

另一种是把所有内容向量化，查询时做相似度召回。

这两种方式都不能单独支撑长期运行。

真正的记忆系统，至少要回答四个问题：

1. 什么信息值得保存？

2. 应该保存到哪里？

3. 什么时候读取？

4. 读取后占用多少上下文？

Hermes 没有把所有信息混在一个存储中，而是区分了不同性质的记忆。

1. 核心记忆：保存稳定、长期有效的信息

Hermes 使用 MEMORY.md 和 USER.md 保存跨会话信息。

MEMORY.md 主要保存环境事实、项目规范和 Agent 学到的稳定经验。

USER.md 主要保存用户偏好、沟通方式和长期习惯。

官方对这两个文件设置了明确的字符限制：

MEMORY.md：约 2200 字符
USER.md：约 1375 字符

限制容量并不是缺点，反而是一个非常聪明的设计。

长期记忆如果没有容量约束，最终一定会变成垃圾场。旧信息、临时信息、错误判断和重复规则不断累积，模型每次启动都要读取大量低价值内容。

容量限制迫使系统判断：什么才是真正值得每次会话都带上的信息？

例如：

用户今天在香港出差

这是一条短期信息，不应该长期保存。

而下面这条信息更适合进入项目记忆：

生产数据库结构变更必须通过 Alembic 迁移，禁止直接修改表结构。

它具有长期有效、重复使用和直接影响执行决策三个特点。

2. 会话档案：保存发生过什么

完整聊天记录和任务轨迹不适合全部进入系统提示词。

Hermes 将会话持久化到 SQLite，并通过 FTS5 进行全文检索。需要引用历史信息时，再按需搜索相关会话。

这类记忆回答的是：

过去发生过什么？

例如：

• 上周讨论过哪个方案；

• 某次任务使用了什么参数；

• 用户之前否决了哪个方向；

• 某个报错第一次出现在哪个会话。

它和长期记忆的区别在于，会话档案保存完整历史，但不会默认全部进入 Context。

3. Skill：保存怎样完成一类任务

Skill 是 Hermes 中最重要的一种记忆。

事实记忆保存“知道什么”，Skill 保存“应该怎样做”。

例如：

服务器使用 Ubuntu 22.04

属于事实。

而下面的内容属于 Skill：

部署生产服务时：
1. 检查配置文件；
2. 执行单元测试；
3. 备份数据库；
4. 执行迁移；
5. 检查健康接口；
6. 失败时回滚。

它不是关于过去发生了什么，而是一套未来可以复用的执行方法。

因此，Skill 更准确的名称应该是：

程序性记忆。

---

五、Skill 为什么不是另一种 Prompt？

如果只把 Skill 理解成一段更长的提示词，就低估了它的价值。

Hermes 的 Skill 是按需加载的知识文档，兼容 Agent Skills 开放标准。Skill 可以包含主说明文件、参考资料、模板、脚本、示例和静态资源。

一个完整的 Skill 可以设计成：

fabric-report/
├── SKILL.md
├── references/
│   ├── fabric-fields.md
│   └── quality-rules.md
├── templates/
│   └── report-template.md
├── scripts/
│   └── validate_report.py
└── examples/
    └── sample-output.md

SKILL.md 只负责描述：

• 什么时候使用这个 Skill；

• 需要哪些输入；

• 应该按照什么步骤执行；

• 哪些情况下必须停止；

• 怎样判断任务完成。

具体字段规则放在 references 中，固定格式放在 templates 中，确定性验证交给 scripts。

这种结构比把所有内容写在一个 Prompt 中更容易维护，也更容易测试。

Skill 的真正价值：把隐性经验变成显性协议

企业内部大量业务流程并不完整存在于 SOP 中。

它们通常存在于熟练员工的经验里：

• 哪种异常需要先找哪个部门；

• 什么数据缺失时不能继续；

• 哪些字段允许使用默认值；

• 哪个接口偶尔会失败；

• 什么情况必须人工审批；

• 输出完成后要检查哪些内容。

Skill 化，就是把这些经验拆解成：

触发条件
→ 输入要求
→ 执行步骤
→ 工具选择
→ 异常处理
→ 验证条件
→ 输出格式

所以企业 Agent 真正应该积累的，不是越来越长的 Prompt，而是一套经过验证的业务 Skill 库。

---

六、渐进式披露：解决 Skill 越多，Agent 越笨的问题

随着系统运行时间增长，Skill 数量会越来越多。

如果每次启动都把所有 Skill 全文放进 Context，最终会产生三个问题：

第一，Token 成本持续上升。

第二，大量无关规则会稀释模型注意力。

第三，不同 Skill 之间可能出现规则冲突。

Hermes 使用渐进式披露来解决这个问题。

简单理解，就是分三步加载：

第一步：只告诉模型有哪些 Skill，以及它们分别做什么。

第二步：模型判断当前任务需要某个 Skill 后，再加载完整 SKILL.md。

第三步：执行过程中需要具体资料时，再读取对应参考文件、脚本或模板。

官方将 Skill 定义为按需知识文档，并明确使用渐进式披露减少 Token 消耗。

这和操作系统的懒加载很像。

应用程序启动时，不会把硬盘上的所有代码全部加载进内存。

Agent 启动时，也不应该把所有知识、规则和流程全部塞进上下文。

一个合理的 Context 应该是：

稳定系统规则
+ 当前任务状态
+ 当前需要的业务知识
+ 当前激活的 Skill
+ 最近必要的执行结果

而不是：

全部历史对话
+ 全部业务文档
+ 全部 Skill
+ 全部执行日志

上下文工程的核心，从来不是“能塞多少内容”，而是“当前应该让模型看到什么”。

---

七、Agent 的自我进化，不能缺少验证门

Hermes 强调从执行经验中创建和改进 Skill。

这形成了一个学习循环：

执行
→ 评估
→ 提炼
→ 更新 Skill
→ 下一次复用

方向没有问题，但生产级系统不能让一次成功直接变成长期规则。

因为模型非常容易把相关性误认为因果关系。

假设某次接口调用前执行了：

sleep 10

接口随后调用成功。

模型可能总结出：

调用该接口前必须等待 10 秒。

但真实原因可能只是当时网络波动，等待并不是成功的必要条件。

如果没有验证机制，这条偶然经验就会被写进 Skill，之后每次任务都会无意义地等待。

因此，更安全的闭环应该是：

执行任务
→ 保存完整轨迹
→ 识别重复模式
→ 生成候选 Skill
→ 自动测试
→ 人工或策略审核
→ 发布正式版本
→ 监控使用效果
→ 更新、回滚或淘汰

Skill 至少应该记录：

version: 1.3.0
success_count: 8
failure_count: 1
confidence: 0.91
verified_by: human
last_used_at: 2026-07-14
source_session: session_xxx

真正可靠的自我进化，不是让模型随意修改自己，而是让模型提出候选改进，再由验证系统决定能否生效。

任何可以改变 Agent 未来行为的写入，本质上都应该被当作代码变更处理。

---

八、真正的 Planner，不是让模型列出五个步骤

很多 Agent 所谓的规划，本质上只是向模型发送一句话：

请把任务拆成五个步骤。

模型生成一份看起来很完整的计划，然后执行器从第一步开始向下运行。

一旦中间条件发生变化，这份计划很快就会失效。

真正的 Planner 应该管理的是状态，而不是文字列表。

它至少要知道：

• 当前处于什么状态；

• 目标状态是什么；

• 哪些步骤已经完成；

• 下一步的前置条件是什么；

• 如何判断当前步骤完成；

• 失败后应该重试、换路径还是停止；

• 当前还剩多少时间和调用预算；

• 什么情况下必须交给人工。

例如，一个面料开发 PPT 任务，可以拆成以下状态：

资料未收集
→ 白皮书已解析
→ 面料候选已生成
→ 面料已筛选
→ 卖点已生成
→ PPT 已生成
→ 内容已验证

“面料已筛选”不能只是一句话，而应该有明确完成条件：

至少选出 5 块面料；
每块面料包含成分、克重、手感和适用款式；
关键数据有来源；
无法验证的数据标记为 Information Not Available。

这样系统才知道自己到底有没有完成任务。

所以，规划能力的核心不是会不会列步骤，而是：

执行结果发生变化后，系统是否知道应该继续、重试、回滚还是重新规划。

---

九、后台复盘解决了延迟问题，也带来了新的一致性问题

如果每次完成任务后，都同步执行总结、记忆提取和 Skill 更新，用户会明显感受到延迟。

更合理的方式是将主链路和学习链路分开：

主链路：
尽快完成用户当前任务

后台链路：
分析轨迹、提取记忆、生成候选 Skill、评估执行质量

Hermes 的设计中包含持久记忆、Skill 学习和主动知识沉淀机制。

这种旁路学习架构值得借鉴，但异步执行并不意味着问题自然消失。

后台复盘还需要解决：

• 两个任务同时修改同一个 Skill；

• 旧版本覆盖新版本；

• 同一条轨迹被重复处理；

• 后台模型生成了错误经验；

• 用户已经修改规则，后台仍按旧规则总结；

• 写入失败后如何重试；

• Skill 更新后如何回滚。

生产环境至少应该增加：

幂等键
版本号
乐观锁
候选区
Diff 审核
失败队列
回滚记录

否则，“后台学习”很容易变成“后台污染”。

---

十、安全边界：模型只能建议，不能决定一切

Agent 一旦拥有终端、文件、数据库和内部系统权限，安全问题就不能只靠 Prompt 解决。

Prompt 中写一句“不要执行危险操作”，并不能构成真正的安全边界。

正确的权限结构应该是：

LLM：提出动作
Policy Engine：判断动作是否允许
Tool Runtime：在隔离环境中执行
Audit Log：记录完整过程
Human：审批高风险操作

Hermes 官方提供多种执行后端，包括本地环境、Docker、SSH、Modal、Daytona 和 Singularity 等。

不同任务应该进入不同权限等级的执行环境。

例如：

读取公开网页：低风险，可以自动执行。

修改普通工作目录文件：中风险，需要限制目录。

执行数据库查询：中高风险，需要只读账号。

执行数据库写入：高风险，需要审批。

修改生产环境配置：极高风险，需要审批、备份和回滚机制。

模型不能同时拥有决策权、权限判断权、凭证访问权、执行权和日志修改权。

否则，只要一次提示词注入或模型误判，就可能直接影响真实系统。

---

十一、企业落地时，应该把数据拆成六类

如果要把 Hermes 的思想应用到企业智能体，我建议至少拆成六类存储。

1. 用户画像

保存长期稳定偏好：

常用语言
报告详细程度
偏好的文件格式
是否允许自动执行
常用业务部门

2. 项目记忆

保存稳定工程事实：

接口地址
数据库规范
部署方式
文件目录
项目约束

3. 业务知识库

保存权威资料：

技术白皮书
产品标准
供应商资料
SOP
培训材料
历史报告

这一层适合使用 RAG。

4. Skill 库

保存经过验证的业务流程：

需求采集 Skill
面料筛选 Skill
白皮书解析 Skill
开发报告生成 Skill
PPT 生成 Skill
知识库入库 Skill

5. 任务状态库

保存当前任务进行到哪里：

{
  "task_id": "fabric-ppt-001",
  "status": "selecting_fabrics",
  "completed_steps": [
    "parse_whitepaper",
    "extract_requirements"
  ],
  "pending_steps": [
    "select_fabrics",
    "generate_ppt",
    "validate_output"
  ],
  "retry_count": 1
}

任务状态不能只存在于聊天记录里。

否则一旦服务重启、上下文压缩或模型切换，系统可能连自己做到哪一步都不知道。

6. 执行轨迹与评估库

保存：

调用了哪些工具
每一步输入和输出是什么
是否成功
失败原因是什么
用户纠正了什么
最终结果是否被接受
使用了哪个 Skill 版本
总耗时和 Token 成本

只有轨迹足够完整，系统才有资格讨论自我改进。

---

十二、Hermes 真正改变了什么？

Hermes 并没有发明一个更聪明的大模型。

它真正做的，是把围绕模型运行的工程结构补完整：

• 用 Agent Runtime 管理模型和工具之间的循环；

• 用 Prompt Builder 管理不同生命周期的上下文；

• 用 Session Storage 保存跨会话状态；

• 用 Memory 保存稳定事实；

• 用 Skill 保存程序性经验；

• 用渐进式披露控制 Token；

• 用异步机制沉淀经验；

• 用隔离和审批控制执行风险。

这背后代表了一种很重要的 Agent 设计变化。

早期 Agent 的重点是：

怎样让模型调用更多工具？

下一阶段 Agent 的重点则是：

怎样让模型长期、稳定、安全地使用工具，并且不会每次从零开始？

前者关注单次任务的惊艳程度。

后者关注系统运行几个月之后，是否仍然可控、可维护、可解释。

---

结语

研究完 Hermes，我最大的感受是：

AI Agent 的竞争，正在从模型能力竞争，转向状态工程和执行工程的竞争。

模型决定一个 Agent 能不能理解任务。

但真正决定它能不能进入生产环境的，是另外一些看起来并不“性感”的问题：

• 状态保存在哪里；

• 哪些信息应该进入 Context；

• 任务失败后从哪里恢复；

• 经验怎样变成 Skill；

• Skill 怎样验证和更新；

• 工具权限如何隔离；

• 每次操作是否可以审计；

• 系统是否能够回滚。

大模型只是大脑。

一个真正能长期工作的 Agent，还需要记忆系统、任务状态、执行器、权限系统、学习机制和审计体系。

这也是 Hermes Agent 最值得学习的地方：

它不再把 Agent 当作一个会调用工具的聊天机器人，而是把它当作一个拥有运行时、状态、记忆、技能和安全边界的软件系统。