Hermes Agent 架构详解：AI Agent 的神经系统——学习与进化
·
核心定位：Hermes Agent = 自我进化的 AI Agent 框架（Self-Evolving Agent Framework），
一个给 AI 装上自我进化、持续学习神经系统的框架。
它不追求确定性控制，而是追求适应性、进化性和"越用越聪明"。
文章目录
-
- 一、设计哲学：Agent 优先，进化第一
- 二、与 OpenClaw 的根本分野
- 三、七层架构全景
- 四、逐层详解
- 五、技能系统全拆解：会生长的 Skill
- 六、记忆系统全拆解：四层 vs 双文件
- 七、Agent Loop 深度对比：Hermes vs OpenClaw
- 八、功能全景
- 九、安全模型
- 十、局限性与诚实说明
- 十一、ima.copilot 中的映射
- 十二、演进弧线：从激进到克制
- 十三、选型指南
- 十四、总结
一、设计哲学：Agent 优先，进化第一
Hermes 遵循两条底层信念：
| 信念 | 含义 |
|---|---|
| Agent 优先（Agent-First） | 框架的编排层服务于 Agent 的"自我改进循环"，而非约束它 |
| 进化第一（Evolution-First） | 技能不是人写的，是 Agent 从经验中长出来的；记忆不是手动维护的，是 Agent 自己管理的 |
Hermes 问的是：如何给 AI 装上一套自我进化、持续学习的神经系统？
答案是一个不断从实验中总结经验的研究实验室——你只管提需求，技能匹配、记忆分类、上下文压缩，全都在阴影里完成。它的野心不是让你觉得它好用，而是让它在不知不觉中自己越变越好。
二、与 OpenClaw 的根本分野
OpenClaw（骨架） Hermes（神经系统）
┌──────────────────┐ ┌──────────────────┐
│ 网关优先 │ │ Agent 优先 │
│ 确定性编排 │ │ 自主性学习 │
│ 强调控制与可预测 │ │ 强调进化与适应性 │
│ │ │ │
│ 问：如何套缰绳？ │ │ 问：如何装神经？ │
│ │ │ │
│ 技能：人工编写 │ │ 技能：自动生长 │
│ 记忆：结构化配置 │ │ 记忆：Agent 自管 │
│ 进化：无 │ │ 进化：GEPA 引擎 │
│ │ │ │
│ → 7×24 稳定数字员工│ │ → 越用越聪明的同事│
└──────────────────┘ └──────────────────┘
三、七层架构全景
┌─────────────────────────────────────────────────────────┐
│ 交互层（Channels） │
│ Telegram / Discord / Slack / WhatsApp / Signal / CLI │
├─────────────────────────────────────────────────────────┤
│ 网关层（Gateway） │
│ 消息路由 / 单进程多渠道 / 统一记忆 / 统一人格 │
├─────────────────────────────────────────────────────────┤
│ 核心编排层（Agent Loop） │
│ 同步推理引擎 / 工具执行 / 技能创建 / 自我评估 / 反思 │
├─────────────────────────────────────────────────────────┤
│ 闭环学习层（Closed Learning Loop） │
│ Agent-Curated Memory / Skill Auto-Create / FTS5 Recall │
│ Honcho User Modeling / Periodic Nudges / Curator │
├─────────────────────────────────────────────────────────┤
│ 进化引擎层（GEPA Engine） │
│ 反思性变异 / 帕累托前沿选择 / 自然语言反馈 / 人类审查 │
├─────────────────────────────────────────────────────────┤
│ 持久化层（Persistence） │
│ SQLite + FTS5 / MEMORY.md / USER.md / sessions/ skills/ │
├─────────────────────────────────────────────────────────┤
│ 执行沙箱层（6 Terminal Backends） │
│ local / docker / ssh / daytona / modal / singularity │
└─────────────────────────────────────────────────────────┘
四、逐层详解
4.1 交互层——多渠道统一接入
与 OpenClaw 的关键区别：Hermes 原生支持 Signal（隐私优先），OpenClaw 不支持。
Telegram ──┐
Discord ──┤
Slack ──┤
WhatsApp ──┼──→ Gateway ──→ Agent Loop
Signal ──┤ （单进程多渠道）
CLI/TUI ──┘
跨平台上下文保持：在一个通道上开始对话，在另一个通道上继续——Hermes 跨平台保持上下文。
CLI 特色：文本用户界面（TUI），支持多行编辑、自动补全、对话历史，且能在 Agent 执行过程中中断或重定向。
4.2 网关层——轻量路由
Hermes 的 Gateway 比 OpenClaw 轻得多。OpenClaw 的 Gateway 是"大脑和交通警察"，Hermes 的 Gateway 只做消息路由。
OpenClaw Gateway： Hermes Gateway：
┌─────────────────────┐ ┌──────────────────┐
│ 会话管理 │ │ 消息路由 │
│ 实例发现 │ │ 单进程多渠道 │
│ IM 通道连接 │ │ 统一记忆 │
│ 沙盒接入 │ │ 统一人格 │
│ 策略引擎 │ │ │
│ 速率限制 │ │ 核心逻辑在 Agent │
│ 状态管理 │ │ Loop 中，不在 Gateway│
│ 工具注入 │ │ │
│ │ │ │
│ → 重网关，轻Agent │ │ → 轻网关，重Agent │
└─────────────────────┘ └──────────────────┘
4.3 核心编排层——Agent Loop
这是 Hermes 架构的核心，也是与 OpenClaw 最本质的区别。
Agent Loop vs OpenClaw Pipeline
OpenClaw（流水线式）：
Ingestion → Access Control → Context Assembly → Model → Tool → Response
（6 阶段流水线，Gateway 主导，Agent 是执行器）
Hermes（循环式）：
用户消息 → Prompt 组装 → 上下文检查 → LLM 调用 → Tool 执行 → 结果注入 → 循环
（ReAct 循环，Agent 主导，Gateway 只是信使）
Turn Lifecycle（每轮执行循环）
1. 用户消息注入
↓
2. Prompt 组装
├── 加载 MEMORY.md 冻结快照
├── 加载 USER.md 冻结快照
├── 加载 Skill 摘要（渐进式，先 Tier 0）
└── 应用 prompt cache
↓
3. 上下文检查 → 必要时预压缩
↓
4. LLM 调用（支持 reasoning 字段）
↓
5. Tool calls 执行（pre/post hooks）
↓
6. 结果注入 → 循环直到最终响应
↓
7. Post-Execution：
├── 保存会话
├── flush memory
└── 触发背景学习（核心差异！）
学习闭环的精确触发点
触发条件（满足任一即触发）：
├── Tool call ≥ 5 次（复杂任务）
├── 出错后自动恢复（自我纠错）
├── 用户纠正 Agent 输出
└── 非显而易见的工作流
触发后：
后台进程总结执行轨迹（trajectory）
→ 生成/更新 SKILL.md
→ 完全静默，用户无需操作
迭代预算
Hermes：默认 20 轮（可配置）
→ 更大的预算允许 Agent 探索更复杂的任务路径
→ 更多轮次 = 更多学习机会 = 更多技能沉淀
OpenClaw：同样有 Agent Loop 上限
→ 但没有学习闭环嵌入
→ 多出来的轮次只是"更多执行"，不是"更多学习"
4.4 闭环学习层——Closed Learning Loop（灵魂核心）
这是 Hermes 区别于所有其他 Agent 框架的根本所在。
“A closed learning loop — Agent-curated memory with periodic nudges.
Autonomous skill creation after complex tasks.
Skills self-improve during use.
FTS5 session search with LLM summarization for cross-session recall.
Honcho dialectic user modeling.”
五步核心循环
┌─────────────────────────────────────────────────────────┐
│ │
│ ① 执行（Execute） │
│ 完成任务，记录完整执行轨迹（trajectory） │
│ ↓ │
│ ② 评估（Evaluate） │
│ 任务结束时自动反思（后台触发） │
│ ↓ │
│ ③ 提炼（Distill） │
│ 自主创建/更新 SKILL.md + Memory nudge │
│ ↓ │
│ ④ 检索（Recall） │
│ 下次任务时 FTS5 搜索 + LLM 总结历史 │
│ ↓ │
│ ⑤ 优化（Optimize） │
│ Skill 自改进 + Curator 周期性剪枝 │
│ ↓ │
│ 回到 ① ——正反馈循环 │
│ │
└─────────────────────────────────────────────────────────┘
四大核心组件
组件 1：Agent-Curated Memory（Agent 自主管理的持久记忆）
两大文件：
┌──────────────────────────────────────────────┐
│ MEMORY.md │
│ 项目/环境事实、规则、教训 │
│ 上限：约 2200 字符 / 800 tokens │
│ 存储位置：~/.hermes/memories/ │
│ │
│ → Agent 通过 memory tool（add/replace/remove）│
│ 自己写、删、合并 │
│ → 容量接近上限时必须先 curation 才能新增 │
│ → 每次会话开始以冻结快照注入 system prompt │
│ （中途修改不影响当前会话） │
└──────────────────────────────────────────────┘
┌──────────────────────────────────────────────┐
│ USER.md │
│ 你的偏好、风格、背景 │
│ 上限：约 1375 字符 / 500 tokens │
│ │
│ → 跨会话保持用户画像一致性 │
│ → 与 Honcho 建模协同，越用越懂你 │
└──────────────────────────────────────────────┘
周期性 Nudges：任务中或结束后，Agent 收到内部 Prompt——
“最近学到什么值得永久记住？”
→ Agent 主动判断并持久化。这是自发的，不需要用户说"记住这个"。
组件 2：Autonomous Skill Creation & Self-Improvement（自主技能创建与自改进）
触发条件：
├── 复杂任务（≥5 次 tool call）
├── 出错恢复
├── 用户纠正
└── 非显而易见的工作流
存储格式：
~/.hermes/skills/<category>/<skill-name>/SKILL.md
YAML frontmatter + Markdown 步骤
遵循 agentskills.io 标准
自改进机制：
├── 每次调用记录 bump_use() 使用计数
├── 支持 patch（增量修改）而非全量重写
└── v0.12 Curator（2026.4.30 新增）：
每 7 天后台运行
→ 评分、合并、剪枝低效 Skill
→ 自动重写更优版本
Progressive Disclosure（渐进式披露）——关键设计：
Tier 0（目录卡片）：
只加载 Skill 名称和描述
约 3000 tokens 总量
→ 注入系统提示词
→ 判断方向是否匹配
Tier 1（书架取书）：
方向对了 → 展开完整 SKILL.md 内容
→ Agent 开始使用该技能
Tier 2（深入参考）：
需要更多细节 → 加载补充说明
→ 完整的步骤、注意事项、边界条件
效果：即使 200 个 Skill，上下文成本仍接近 40 个
组件 3：FTS5 Cross-Session Recall（跨会话全文检索 + LLM 总结）
存储：全部历史对话存入 SQLite（~/.hermes/state.db）
启用 FTS5 全文索引
检索流程：
需要时查询
→ FTS5 全文搜索匹配相关片段
→ LLM（通常轻量模型）总结相关片段
→ 注入当前上下文
与闭环结合：
episodic memory（发生了什么）── 情景记忆
procedural memory（怎么做） ── 程序性记忆（Skill）
→ 两类记忆分离，避免混淆
作用：让 Agent "记得过去所有对话"，但只注入必要部分
组件 4：Honcho Dialectic User Modeling（辩证用户建模）
可选插件（hermes memory setup 开启）
核心机制：
辩证式建模方法
→ 同时建模用户和 Agent 之间的关系
→ 覆盖 12 个身份维度
维度包括：
├── 偏好（编码风格、沟通方式）
├── 决策风格（激进/保守/折中）
├── 技术水平（初学/中级/专家）
├── 工作习惯（早鸟/夜猫/碎片化）
├── 信息密度偏好（简洁/详细）
├── 幽默感偏好
├── ...等
与其他层协同：
→ 让 Skill 更个性化（不只是"怎么做"，而是"按你的方式做"）
→ 让 Memory 更精准（记住对你重要的事）
v0.7.0 变化：
Honcho 从唯一高级记忆后端降级为可插拔后端之一
与 MEM0、ByteRover 等 6 个第三方服务平起平坐
默认兜底：纯文件 + 全文检索
→ 先行者在撞上社区真实投诉后的战略让步
四大组件如何闭合
记忆（事实层）
"这个项目用 Python 3.12，测试框架是 pytest"
↓ 提炼
技能（流程层）
"遇到 pytest 报错 → 先看 conftest.py → 再检查 fixtures → 最后看 import"
↓ 检索
下次任务：FTS5 搜到历史 + Skill 匹配
↓ 优化
Skill 自改进 + Curator 剪枝 + 记忆更新
↓
正反馈循环：用得越多 → 提炼越多 → 检索越准 → 改进越快
4.5 进化引擎层——GEPA（Genetic-Pareto Prompt Evolution）
Hermes 的"杀手锏"，也是社区最被吹捧的硬核差异。
GEPA 的学术来源
论文：Lakshya Agrawal 等人，ICLR 2026 Oral
标题：《反思性提示词进化可以跑赢强化学习》
（Reflective Prompt Evolution Can Outperform Reinforcement Learning）
独立仓库：NousResearch/hermes-agent-self-evolution
框架：DSPy
核心算法：GEPA
为什么不走 RL 路线？
主流方案（SkillRL / SAGE）：
强化学习 → 梯度更新 → 强化技能库
问题：
├── 数值 reward 颗粒度太粗（跑了得 0.6 分，不知道哪里对哪里错）
├── 需要上万次评估才能收敛
└── 训练成本高
GEPA 的对立路线：
刻意抛弃强化学习
→ 不用梯度更新
→ 靠大模型的反思能力 + 进化算法
→ 论文证明：不仅跑赢 RL，样本利用效率还更高
GEPA 三大底座
底座 1：反思性变异（Reflective Mutation）
不是瞎猜式的随机变异！
流程：
1. 读取之前的执行轨迹（trace）
2. LLM 反思：
"这次为什么做对了？"
"这次为什么做错了？"
"提示词到底该改哪几个字？"
3. 基于反思生成候选变体
vs 传统随机变异：
传统：随机改几个字 → 跑评估 → 留高分
GEPA：先想清楚改什么 → 针对性修改 → 跑评估
→ 变异质量高得多，收敛快得多
底座 2：帕累托前沿选择（Pareto Frontier Selection）
生成了一批候选技能后，怎么选？
传统方法：一刀切，只留全局均分最高的
问题：丢失多样性，可能在边缘场景表现差
GEPA 方法：帕累托前沿
只要某个候选在哪怕一个评估样本上表现最强
→ 它就会被保留下来
示例：
候选 A：平均 85 分，最高 90
候选 B：平均 78 分，但某个边界 case 得分 95
候选 C：平均 82 分，内存占用最低
→ A、B、C 都保留（各有所长）
→ 保证技能探索的多样性和鲁棒性
底座 3：自然语言反馈作为变异信号
传统 RL：
reward = 0.6 ← 一个浮点数
→ 你根本不知道是哪里对哪里错
→ 梯度更新方向模糊
GEPA：
feedback = "这一步没检查边界条件"
feedback = "应该先读配置再写缓存"
feedback = "错误处理逻辑遗漏了超时情况"
← 具体的自然语言反馈
→ LLM 读得懂这种反馈
→ 据此产生下一轮变体
→ 比解读一个浮点数有效得多
GEPA 完整工作流
┌──────────────────────────────────────────────────────┐
│ Step 1：采样评估集 │
│ 系统定期读取现有 SKILL 文件 │
│ 从历史会话中抽样（或合成）搞出评估集 │
└──────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────┐
│ Step 2：GEPA 介入 │
│ 读取执行轨迹 │
│ → 反思提意见（Reflective Mutation） │
│ → 生成候选变体 │
└──────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────┐
│ Step 3：评估与选择 │
│ 跑一轮评估 │
│ → 帕累托前沿算法挑出赢家 │
│ → 保留多样性，不是只留最高分 │
└──────────────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────────────┐
│ Step 4：人类审查（关键安全阀！） │
│ 优化后的 Skill 不会直接覆盖原文件 │
│ → 生成一个 Pull Request │
│ → 必须等人类审核员点头合并 │
│ → 系统永远不会直接提交 │
└──────────────────────────────────────────────────────┘
GEPA 的性能数据
根据 Nous Research 数据：
重复性任务效率提升：40%
vs GRPO 强化学习基线：平均高出 6%，特定任务最高高出 20%
所需试错次数：少 35 倍
收敛所需评估次数：100-500 次（传统 RL 需上万次）
4.6 持久化层——混合存储架构
存储结构
~/.hermes/
├── state.db ← SQLite（会话历史 + FTS5 全文索引）
├── memories/
│ ├── MEMORY.md ← 持久事实（环境、规则、教训）
│ └── USER.md ← 用户偏好（风格、习惯、背景）
├── skills/
│ ├── deployment/
│ │ └── deploy-staging/
│ │ └── SKILL.md ← 自动生成的技能文件
│ ├── devops/
│ │ └── server-monitor/
│ │ └── SKILL.md
│ └── ...
└── sessions/
├── session-001.jsonl
├── session-002.jsonl
└── ...
四层内存分离（Token 控制核心设计）
┌──────────────────────────────────────────────────┐
│ 1. Always-On（常驻内存） │
│ MEMORY.md + USER.md 冻结快照 │
│ 每次会话注入 system prompt │
│ 命中 provider prompt cache → token 成本极低 │
├──────────────────────────────────────────────────┤
│ 2. On-Demand（按需内存） │
│ FTS5 搜索 + LLM 总结 │
│ 需要时才检索，不占默认上下文 │
├──────────────────────────────────────────────────┤
│ 3. Procedural（程序性内存） │
│ SKILL.md 技能文件 │
│ 渐进式披露：Tier 0 概要 → Tier 1 完整 → Tier 2 │
├──────────────────────────────────────────────────┤
│ 4. Passive（被动内存） │
│ Honcho 用户建模 │
│ 可选开启，后台被动构建 │
└──────────────────────────────────────────────────┘
关键设计：缓存感知（Cache-Aware）
→ 会话初始化时冻结快照
→ 高频模型调用可高效使用缓存的上下文窗口
→ 学习过程不会不断增加 Token 费用
上下文压缩前的保护
上下文接近阈值时：
Step 1: Memory Flush
强制 Agent 将关键状态写入磁盘文件
↓
Step 2: 压缩总结
对上下文进行摘要压缩
↓
Step 3: 继续运行
压缩后的上下文 + 持久化文件 = 无损继续
4.7 执行沙箱层——六终端后端
比 OpenClaw 更细粒度的安全与性能权衡：
| 后端 | 执行环境 | 隔离级别 | 适用场景 |
|---|---|---|---|
| local | 宿主机直接运行 | 无 | 日常开发、访问本地文件 |
| docker | Docker 容器 | 完全隔离（Namespaces, cap-drop ALL） | 不受信任代码、CI/CD |
| ssh | 远程服务器 | 网络边界 | 计算密集型任务 |
| daytona | 云端工作空间 | 完全隔离（云容器） | 长期保存状态的云端环境 |
| modal | 无服务器沙盒 | 完全隔离（云 VM） | 突发 GPU 需求、按量付费 |
| singularity | HPC 容器 | Namespaces（–containall） | 学术研究集群 |
灵活性：
从个人笔记本 → 企业服务器 → HPC 集群
在隔离强度与执行效率之间做任务级选择
每个任务可以独立选择后端
不需要全局统一配置
五、技能系统全拆解：会生长的 Skill
Hermes Skill vs 传统 Skill
传统 Skill（OpenClaw 等）：
人工编写 → 安装 → 固定不变 → 过时了手动更新
Hermes Skill：
自动生成 → 自动匹配 → 自动进化 → 自动优化
├── 生命周期劈成两截：
│ 一截：运行时静默生成
│ 一截：离线硬核进化
└── 用户完全无感
SKILL.md 完整格式
---
# Part 1: Frontmatter（元数据）
name: deploy-staging
description: 一键部署到 staging 环境
version: 1.2.0
platforms: [linux, docker]
metadata:
hermes:
tags: [devops]
category: deployment
auto_generated: true # Hermes 自动生成标记
use_count: 23 # 使用计数
last_improved: 2026-05-15 # 上次进化时间
confidence: 0.87 # 自评估置信度
---
# Part 2: Markdown Body（步骤说明）
## 什么时候用
当代码合并到 main 分支后需要部署到 staging 环境时。
## 步骤
1. git pull origin main
2. 检查 conftest.py 配置
3. 运行 pytest --staging
4. docker build -t staging:latest .
5. docker push registry/staging:latest
6. kubectl rollout restart deployment/staging
## 注意事项
- 先检查 conftest.py，再检查 fixtures
- staging 环境变量在 .env.staging 中
- 如果 pytest 失败，不要继续部署
## 错误恢复
- 部署失败 → kubectl rollout undo
- 测试失败 → 检查最近的 commit diff
技能的完整生命周期
┌─────────────────────────────────────────────────────┐
│ Phase 1：静默生成（运行时） │
│ │
│ 用户要求完成复杂任务 │
│ ↓ │
│ Agent 执行任务（tool call ≥ 5 或出错恢复） │
│ ↓ │
│ 硬规则触发：后台进程总结 trajectory │
│ ↓ │
│ 自动打包成 SKILL.md → 存入 ~/.hermes/skills/ │
│ ↓ │
│ 完全静默，用户可能根本不知道 │
└─────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────┐
│ Phase 2：渐进式加载（下次使用） │
│ │
│ Tier 0：名称 + 描述注入 system prompt（~3000 token）│
│ ↓ 方向匹配 │
│ Tier 1：展开完整 SKILL.md 内容 │
│ ↓ 需要更多细节 │
│ Tier 2：加载补充说明 │
└─────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────┐
│ Phase 3：使用中改进（运行时） │
│ │
│ 每次 bump_use() 使用计数 +1 │
│ 支持 patch 增量修改（不全量重写） │
│ 记录成功/失败轨迹 │
└─────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────┐
│ Phase 4：离线进化（GEPA） │
│ │
│ 系统定期读取 SKILL + 历史会话 │
│ ↓ │
│ GEPA：反思性变异 → 帕累托选择 → 评估 │
│ ↓ │
│ 优化后的 Skill → 生成 PR（不直接覆盖！） │
│ ↓ │
│ 人类审核 → 合并 → 新版技能生效 │
└─────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────┐
│ Phase 5：Curator 周期剪枝（v0.12+） │
│ │
│ 每 7 天后台运行 │
│ → 评分：使用频率 × 成功率 × 置信度 │
│ → 合并：相似技能合并 │
│ → 剪枝：低效技能降级或删除 │
│ → 重写：自动生成更优版本 │
└─────────────────────────────────────────────────────┘
六、记忆系统全拆解：四层 vs 双文件
与 OpenClaw 记忆对比
OpenClaw（双文件 + 日志）： Hermes（四层混合）：
┌───────────────────────┐ ┌──────────────────────────┐
│ MEMORY.md │ │ MEMORY.md（事实层） │
│ （长期记忆） │ │ 上限 800 tokens，Agent 自管│
│ │ │ │
│ memory/YYYY-MM-DD.md │ │ USER.md（用户偏好层） │
│ （短期日志） │ │ 上限 500 tokens，Agent 自管│
│ │ │ │
│ sessions.jsonl │ │ skills/（程序性记忆层） │
│ （会话历史） │ │ 自动生成的 SKILL.md │
│ │ │ │
│ │ │ state.db（情景记忆层） │
│ │ │ SQLite + FTS5 全文检索 │
│ │ │ │
│ │ │ Honcho（用户建模层，可选） │
│ │ │ 12 维辩证式用户画像 │
└───────────────────────┘ └──────────────────────────┘
谁决定什么值得记住——最关键的区别
OpenClaw：
→ 人决定。Agent 按规则把关键信息写入 MEMORY.md
→ 规则写在 AGENTS.md 里，开发者配置
→ 确定性强，但不会"主动发现"值得记住的东西
Hermes：
→ Agent 自己决定。通过 Periodic Nudges
→ Agent 自己判断"什么值得持久化"
→ 主动性强，但可能判断不准
→ 社区发现：Hermes 判断自己"是否完成任务"时几乎总觉得自己成功了
→ 所以反思出来的记忆，非常薄弱
程序性记忆——Hermes 独有层
OpenClaw 只有"事实性记忆"：
"文件服务器 IP 是 192.168.1.10" ← 知道"是什么"
Hermes 额外有"程序性记忆"：
"遇到 pytest 报错 → 先看 conftest.py → 再检查 fixtures" ← 知道"怎么做"
这是从"情景记忆"走向"程序性记忆"的质变：
情景记忆：记得发生了什么（episodic）
程序性记忆：知道该怎么做（procedural）
→ 让记忆变成可以读、可以改、可以提交到 Git、可以团队共享的工件
七、Agent Loop 深度对比：Hermes vs OpenClaw
| 维度 | OpenClaw | Hermes |
|---|---|---|
| 调度模型 | Gateway 主导的 Channel 命令队列 | Agent Loop 主导的 ReAct 循环 |
| 提示词构建 | Gateway 统一注入（按渠道动态生成） | Agent 内部组装（加载快照 + Skill 摘要） |
| 工具执行 | Gateway 注入工具链，Pi 执行 | Agent 直接调用，支持 pre/post hooks |
| 学习闭环 | ❌ 无（v0.12 后补 Active Memory） | ✅ 核心架构关切，一等公民 |
| 迭代预算 | 默认上限 | 默认 20 轮，更多轮次 = 更多学习 |
| 核心逻辑位置 | 在 Gateway | 在 Agent Loop |
| 设计取向 | 重网关，轻 Agent | 轻网关，重 Agent |
最本质的区别：学习闭环的嵌入位置。
OpenClaw：执行是执行，学习是学习（两码事）
→ v0.12 后开始补课：Dreaming 做离线记忆整理
→ Active Memory 在主回复前跑记忆子 Agent
Hermes：执行即学习，学习即执行（一码事）
→ 每次复杂任务完成 → 自动提炼技能
→ 每次会话结束 → 自动 nudge 记忆
→ 学习闭环嵌入在 Agent Loop 的每一个 Post-Execution 阶段
八、功能全景
工具系统（40+ 内置工具）
| 类别 | 工具 | 说明 |
|---|---|---|
| 文件管理 | read/write/edit/search | 文件系统全操作 |
| 浏览器 | browser_navigate/click/screenshot | Playwright 语义快照 |
| 终端 | exec/bash | Shell 命令执行 |
| 通信 | email/calendar/contacts | 邮件、日历、通讯录 |
| 子代理 | delegate_task | 单任务/最多 3 个并行子任务 |
| 记忆 | memory_add/replace/remove | Agent 自主管理记忆 |
| 技能 | skill_create/update/search | 技能生命周期管理 |
| 搜索 | web_search/kb_search | 网络和知识库搜索 |
多平台消息网关
Telegram ──┐ ┌── Signal（OpenClaw 不支持）
Discord ──┤ │
Slack ──┼── Gateway ────────┤── CLI/TUI
WhatsApp ──┤ （单进程多渠道）│
Signal ──┘ └── 跨平台上下文保持
LLM 提供商（200+ 模型）
OpenRouter → Claude / GPT / Gemini / Llama / DeepSeek
OpenAI → GPT-5.4 / GPT-5.4 Thinking
Nous Portal → Hermes 模型系列
Ollama → Gemma 4 / Llama 4 / Qwen 3.5 / DeepSeek（本地）
其他 → z.ai / Kimi / MiniMax / GLM / 自定义端点
一条命令切换模型，无需改代码
MCP 双向集成
MCP 客户端：连接外部 MCP 服务器（数据库、API、文件系统）
MCP 服务器模式（v0.6.0+）：将 Hermes 暴露为 MCP 服务器
→ IDE 和其他工具可将 Hermes 用作后端
九、安全模型
安全默认设置
| 机制 | 说明 |
|---|---|
| Docker 沙箱 | 生产部署推荐，只读 root + cap-drop ALL |
| 提示词注入扫描 | v0.7.0 默认开启 |
| 工具权限限制 | 限制 Agent 可在无人监督情况下使用的工具 |
| 凭证过滤 | 防止 API 密钥出现在 Agent 上下文中 |
| 审计日志 | hermes logs --follow 实时监控 |
| 人类在环审查 | GEPA 进化的 Skill 必须人类审核才能合并 |
插件安全设计
Event Hooks 系统 6 种钩子
→ 5 种是触发即忘（fire-and-forget）的看客
→ 系统根本不管返回值
修改 Agent 运行上下文的注入点：
→ 只有 1 个
官方底线：
就算插件代码跑崩了，也绝不拖垮 Agent 的主循环
底层逻辑：
把开发者当成潜在敌人
→ 只开放最小必要接口
→ 确保核心稳定性
十、局限性与诚实说明
┌──────────────────────────────────────────────────────────┐
│ 1. 记忆容量硬上限 │
│ MEMORY.md 800 tokens / USER.md 500 tokens │
│ → 防止 token 爆炸，需要 Agent 主动 curation │
│ → 但 Agent 可能判断不准什么该删 │
├──────────────────────────────────────────────────────────┤
│ 2. Skill 质量依赖 LLM 自评估 │
│ → 早期可能需人工微调 │
│ → 社区反馈：精心调制的技能被自动进化流程覆盖 │
├──────────────────────────────────────────────────────────┤
│ 3. Curator 是周期性而非实时 │
│ → 每 7 天才运行一次 │
│ → 不会即时优化 │
├──────────────────────────────────────────────────────────┤
│ 4. 反思质量存疑 │
│ → Agent 判断"是否完成"时几乎总觉得自己成功了 │
│ → 反思出来的记忆非常薄弱 │
├──────────────────────────────────────────────────────────┤
│ 5. 不适合零容错场景 │
│ → 核心合同、底层代码、财务模型 → 全自动是隐患 │
│ → 容错率高的日常重复任务 → 能站得住 │
├──────────────────────────────────────────────────────────┤
│ 6. 依赖强模型做反思 │
│ → 弱模型执行 routine 可以，但反思质量不够 │
└──────────────────────────────────────────────────────────┘
十一、ima.copilot 中的映射
| Hermes 原版 | ima.copilot 版本 | 作用 |
|---|---|---|
MEMORY.md |
memory_md |
持久化事实与决策 |
USER.md |
user_md |
用户档案 |
skills/ + SKILL.md |
Skill 系统（use_skill） |
技能加载与执行 |
| FTS5 + SQLite | qa 层（会话上下文） |
跨会话检索 |
state.db sessions |
daily 层（日摘要） |
短期记忆 |
| Honcho User Modeling | —（暂无对应） | 用户建模 |
| GEPA 进化引擎 | —（暂无对应） | 技能自动进化 |
| Curator | —（暂无对应） | 技能周期剪枝 |
| Periodic Nudges | memory_write（用户触发） |
记忆持久化 |
ima.copilot 采用了 Hermes 的记忆架构思路（双文件 + 层级分离），但暂未集成 GEPA 进化引擎和 Honcho 用户建模。
十二、演进弧线：从激进到克制
2026.02.25 Hermes 首发
旗号："与你共同成长的 Agent"
路线：主动记忆、自动进化、强行替用户做决定
→ 一口气冲到 57,200 颗星
↓
2026.04.03 v0.7.0 韧性更新
悄悄往回撤了半步：
→ Honcho 从唯一高级后端降级为可插拔后端之一
→ 纯文件 + 全文检索成为默认兜底
→ 把记忆的选择权交还给了用户
↓
先行者在撞上社区真实投诉后的战略让步
→ 觉得现在的规则系统还吃不透所有复杂场景
→ 有些选择不必强行替用户做
同时，OpenClaw 在反方向补课：
2026.04.05 OpenClaw 发布 Dreaming
→ 离线记忆整理：短期流水文档 → 提炼 → 晋升为 MEMORY.md
↓
2026.04.10 OpenClaw 发布 Active Memory
→ 主回复前跑记忆子 Agent
→ 大模型做裁判的主动派打法
→ 粒度比 Hermes 固定 15 轮一次的微调更细
↓
大家全都在往"替你做决定"这条路上靠
Hermes 只不过下注最早、最狠
十三、选型指南
选择 Hermes，如果你需要
✅ 长期陪伴、越用越懂的 AI 伙伴
Honcho 用户建模 + 持续技能生成
数周后 Agent 会记住你的编码规范和决策偏好
✅ 复杂、重复性高的研发任务
代码分析、数据处理、研究流程的"效率复利"
第一次生成技能后，后续速度提升 40%
✅ 深入定制"会学习的 AI"
基于 Python + DSPy 的架构
可以介入学习循环，修改进化算法
作为研究平台使用
不选择 Hermes，如果你需要
❌ 零容错的关键业务
核心合同、底层代码、财务模型
全自动模式本身是隐患
❌ 严格的合规与审计控制
Gateway 的多 Agent 路由、RBAC、策略引擎
金融、医疗等行业的治理要求
❌ 快速搭建、稳定优先
700+ 社区技能几小时连全渠道
不想等 Agent 慢慢学习
十四、总结
Hermes 的"智能"不是功能多，而是闭环正反馈——
- Agent-Curated Memory 把记忆从被动存储变成主动管理
- Skill Auto-Creation 把经验从一次性消耗变成可复用资产
- FTS5 + LLM Recall 把历史从归档文件变成活的检索库
- GEPA 把技能优化从人工调参变成算法驱动的进化
- Honcho 把用户理解从静态配置变成辩证式建模
- Curator 把技能库从无限膨胀变成有序收敛
用得越多 → 提炼越多 → 检索越准 → 改进越快 → 三个月后，你拥有一个真正"共事多年"的 Agent。
但这不是魔法——它是一套精心设计的工程机制，把"越用越聪明"从口号变成系统行为。
每一步都有硬规则兜底，每一次进化都需要人类审查。
Hermes 赌的不是今天能多完美，而是未来模型更强时，它的架构能最先吃到红利。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
20
0- 0
已为社区贡献29条内容
所有评论(0)